Unable to decipher what's coming back via a PEAP tunnel
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.
On Jan 10, 2020, at 3:22 AM, Joe Garcia <joe27256@gmail.com> 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.
On Mon, 13 Jan 2020 at 02:59, Alan DeKok <aland@deployingradius.com> 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.
participants (2)
-
Alan DeKok -
Joe Garcia