Unable to decipher what's coming back via a PEAP tunnel

classic Classic list List threaded Threaded
3 messages Options
| Threaded
Open this post in threaded view
|

Unable to decipher what's coming back via a PEAP tunnel

Joe Garcia
I'm working with a third-party app that authenticates to a FreeRADIUS server
via MSCHAPv2 over PEAP and need up update a few parts of it, but I can't
figure out what FreeRADIUS is sending over the PEAP tunnel when it's not
sending MSCHAPv2 data.  The current code doesn't try and break down the
messages, possibly because my predecessor also couldn't figure out what they
were, but there's now a requirement to do this.

The initial Identity Request sent by FreeRADIUS over the PEAP tunnel is:

  01       // Identity-Request
  06       // ?
  00 05    // length = 5
  01       // ?

The Identity Request sent by FreeRADIUS over the PEAP tunnel in response to an
incorrect identity in the MSCHAPv2 process, i.e. what you get instead of an
MSCHAPv2 response, is:

  01       // Identity-Request
  08       // ?
  00 0B    // length = 11
  21 80 03 00 02 00 02 // ?

Problem is I can't translate these messages into anything useful (the field
names I've used above are guesswork), this doesn't correspond to any message
format that I can identify, RADIUS, EAP, DIAMETER, PEAP, there are bits and
pieces in there that could correspond to various things like EAP and RADIUS,
and the byte string starting 0x21 could be a MS-Authentication-TLV but what
follows doesn't match draft-hiller-eap-tlv-01.txt, and it also doesn't work as
an EAP-Request, also 0x21.

Can anyone tell me what format this is?

JG.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Unable to decipher what's coming back via a PEAP tunnel

Alan DeKok-2
On Jan 10, 2020, at 3:22 AM, Joe Garcia <[hidden email]> wrote:

>
> I'm working with a third-party app that authenticates to a FreeRADIUS server
> via MSCHAPv2 over PEAP and need up update a few parts of it, but I can't
> figure out what FreeRADIUS is sending over the PEAP tunnel when it's not
> sending MSCHAPv2 data.  The current code doesn't try and break down the
> messages, possibly because my predecessor also couldn't figure out what they
> were, but there's now a requirement to do this.
>
> The initial Identity Request sent by FreeRADIUS over the PEAP tunnel is:
>
>  01       // Identity-Request
>  06       // ?
>  00 05    // length = 5
>  01       // ?

  That's EAP.  See RFC 3748.

Q: How do you know that 0x01 is an identity request?
A:  Because it's EAP.  0x01 is an EAP identity request...

> The Identity Request sent by FreeRADIUS over the PEAP tunnel in response to an
> incorrect identity in the MSCHAPv2 process, i.e. what you get instead of an
> MSCHAPv2 response, is:
>
>  01       // Identity-Request
>  08       // ?
>  00 0B    // length = 11
>  21 80 03 00 02 00 02 // ?

  That's EAP.  Mostly... MS does stupid things inside of the PEAP tunnel.

> Problem is I can't translate these messages into anything useful (the field
> names I've used above are guesswork), this doesn't correspond to any message
> format that I can identify, RADIUS, EAP, DIAMETER, PEAP, there are bits and
> pieces in there that could correspond to various things like EAP and RADIUS,
> and the byte string starting 0x21 could be a MS-Authentication-TLV but what
> follows doesn't match draft-hiller-eap-tlv-01.txt, and it also doesn't work as
> an EAP-Request, also 0x21.
>
> Can anyone tell me what format this is?

  It's EAP.  The EAP header is only 4 bytes.  And while the code in FreeRADIUS isn't perfect, you should be able to follow it.  It's well commented, and described exactly what it's doing.

  Just look for "0x21" or "33" in peap.c is informative:

        /*
         *  Since the full EAP header is sent for the EAP Extensions type (Type 33),
        ...

  That code is extensively commented.  It describes what each byte is, and what it means.

  I don't look at the PEAP implementation every day, so I'm not 100% up to speed with it.  But simply searching for relevant text will get you the right information, 99% of the time.  I know, because that's what *I* do.  I can't be bothered to remember everything about the code.  Instead, I just search for keywords, and find the right information.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Unable to decipher what's coming back via a PEAP tunnel

Joe Garcia
On Mon, 13 Jan 2020 at 02:59, Alan DeKok <[hidden email]> wrote:

>That's EAP.  See RFC 3748.

Ah, of course, thanks!  The second byte, which I thought was a subtype or
something since it was always 6 in the request, looks like it's just the
Identifier coming up from the EAP layer below the TLS tunnel.  So for a valid
Identity I see:

Read Access-Challenge (11) RADIUS packet, length 113, packet ID 5.
  Read EAP-Message (79) RADIUS TLV packet, length 75.
    Read Request (1) EAP packet, subtype PEAP (25), length 70.
  Read Message-Authenticator (80) RADIUS TLV packet, length 16.
  Read State (24) RADIUS TLV packet, length 16.

with the tunnelled EAP message being:

    byte    code = 1            // Request
    byte    ident = 6           // 5 + 1
    uint16  length = 5          // Including header
    byte    type = 1            // Identity

For in incorrect Identity I get:

Read Access-Challenge (11) RADIUS packet, length 113, packet ID 7.
  Read EAP-Message (79) RADIUS TLV packet, length 75.
    Read Request (1) EAP packet, subtype PEAP (25), length 70.
  Read Message-Authenticator (80) RADIUS TLV packet, length 16.
  Read State (24) RADIUS TLV packet, length 16.

with the tunnelled EAP message being:

    byte    code = 1            // Request
    byte    ident = 8           // 7 + 1
    uint16  length = 11 / 0x0B // Including header
    byte[]  data = 0x21 0x80 0x03 0x00 0x02 0x00 0x02.

which is defined on line 37 of src/modules/rlm_eap/types/rlm_eap_peap/peap.c:

    tlv_packet[0] = FR_EAP_CODE_REQUEST;
    tlv_packet[1] = eap_session->this_round->response->id +1;
    tlv_packet[2] = 0;
    tlv_packet[3] = 11; /* length of this packet */
    tlv_packet[4] = FR_PEAP_EXTENSIONS_TYPE;
    tlv_packet[5] = 0x80;
    tlv_packet[6] = EAP_TLV_ACK_RESULT;
    tlv_packet[7] = 0;
    tlv_packet[8] = 2; /* length of the data portion */
    tlv_packet[9] = 0;
    tlv_packet[10] = EAP_TLV_FAILURE;

The reason why I was trying to trace it back to an RFC is because I wasn't
sure if this was something specific to FreeRADIUS or not, i.e. whether
J.Random RADIUS server will respond in the same way to an incorrect Identity,
but the main thing for now is to be able to interpret what FreeRADIUS is
sending.

JG.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html