PEAP Exchange
This section includes a reference file.
To illustrate the authentication in WPA Enterprise,
we will look at a packet capture of a client using PEAP
connecting to a network called “Playtronics”.
This is the perspective from a 3rd party observing the exchange
on the wireless network.
The first frame is a beacon, and we can see it offers WPA1 and WPA2.
It supports CCMP and TKIP as we can see in the
Pairwise Cipher Suite and Unicast Cipher Suite.
In the Auth Key Management, we can see it supports WPA,
which means WPA Enterprise.
We will skip over the next few frames, the probe request and response
and both authentication frames,
since they don’t contain anything meaningful for us.
In the association frame, we can see it will be authenticating with WPA2 CCMP.
It also indicates WPA Enterprise for Auth Key Management.
The association response is uneventful.
If this was PSK, this would be when the 4-way handshake happens.
In this case however, since the client mentioned WPA Enterprise
in the association request, a different authentication happens.
It spans over 19 EAP frames, going back and forth between the AP and client,
where the AP sends EAP Requests, and the client EAP Responses.
The first EAP frame is sent by the AP,
requesting the identity of the client or supplicant.
This marks the start of the EAP type proposal and outer authentication.
The latter is also known as phase 1 of the authentication.
The next EAP frame, from the client, indicates its identity.
The first part is the domain, Playtronics,
and is followed by a separator then the username, cosmo.
Depending on the EAP method used, this may be what the client device
refers to as anonymous identity when setting up the connection.
It’s worth noting that we don’t know what EAP method is used yet.
If the field is left empty, the device will use the identity provided.
This is the case for PEAP or EAP-TTLS, for example.
With these methods, a TLS tunnel is created first,
and the real authentication is done within the tunnel.
While the RADIUS server may use this value to determine where to send
the authentication or what methods to use within the tunnel,
it can be filled with anonymous or another value, concealing the actual identity.
It’s important to note that even if it’s not immediately useful to us now,
gathering usernames may be a useful action as part of a broader pentest.
In this EAP frame, the AP offers the client to connect with PEAP.
We are only now choosing the EAP method to use to protect the authentication,
after an identity has been provided.
If the client refused, it would send a Legacy Nak along with the desired method.
If this is acceptable for the RADIUS server, it will proceed,
and send another request with the desired method.
The client sends Client Hello in the next frame, which means it accepted PEAP.
It is now starting the TLS (1.2) tunnel set-up,
as we can see by the Version field.
Although the EAP type proposal is done, we’re still in phase 1.
The next frame is the Server Hello, along with the certificate
and the Diffie-Hellman key exchange.
Because the content is too large to fit in a single frame, it is split in two frames.
Part of it is sent in frame 12, and the rest is sent in frame 14,
where Wireshark has reassembled both frames.
Since EAP is a Request/Response protocol, the client has to acknowledge each frame,
which is done with frame 13, an empty response.
Following these two frames coming from the AP,
the client now sends its Diffie-Hellman response,
and switches to the symmetric keys they negotiated.
It’s now the server’s turn to switch to the symmetric keys.
The client acknowledges it in frame 17, which now concludes the successful
TLS tunnel set-up, as well as phase 1 or the outer authentication.
The next frame, 18, starts the inner authentication,
also known as phase 2.
It spans over a number of frames, where the authentication occurs.
It finishes with frame 26,
indicating a successful authentication.
Although we can’t see the algorithm chosen in the inner authentication
due to the encryption, the client was set-up to use MS-CHAPv2.
This is the most common type of inner authentication inside of PEAP,
in part because the combination is well supported by recent OSs.
Inside this TLS tunnel, we note a familiar sequence with the
EAP request/response identity, and the MS-CHAPv2 challenge wrapped in EAP frames.
It’s done this way is because MS-CHAPv2 is no longer a secure way to authenticate
on wireless networks without any protection
since it was broken a number of years ago.
It’s wrapped in a TLS session for protection, which we know is secure
because of the Diffie-Hellman key exchange.
After this EAP Success, keying material has been distributed,
and the client and AP can now do the 4-way handshake.