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

[Joe Garcia]

On Mon, 13 Jan 2020 at 02:59, Alan DeKok <aland at 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.