TLS Certificates from EAP Network Traffic

Joff Thyer //

A network can authenticate a client workstation using the 802.1X and Extensible Authentication Protocol (EAP) using multiple different methods.  EAP is used both in a wired network context as well as a wireless network context.   It is fairly common for EAP-PEAP to be used for most authentication in enterprise networks, although EAP-TLS can be used also.

EAP-PEAP (EAP-PEAPv0) is the most common form of EAP in use whereby MSCHAPv2 encoded credentials are protected inside of a TLS tunnel.   The TLS tunnel is established using a server presented certificate delivered using RADIUS protocol to the authenticator (switch or wireless controller), and then delivered using EAP to the 802.1x client/supplicant.  The client/supplicant must then validate the certificate chain of trust before establishing the TLS tunnel.   Once the tunnel is established, MSCHAPv2 is used to send username, and password credentials to the RADIUS server.

EAP-TLS is very similar to EAP-PEAP only that mutual TLS certificate authentication is performed.  The client supplicant presents a client certificate which is validated by the server, and then the RADIUS server presents a server certificate which is validated by the client.  After the certificate exchange process completes with an appropriate chain of trust validation, authentication credentials may be presented across the TLS tunnel.  In some organizations, credentials are not even validated and the mere exchange of mutually signed certificates is sometimes considered sufficient.

In the Wireless network context using WPA2-Enterprise mode, all of the EAP transactions occur in cleartext as the pairwise master key calculation for AES based encryption cannot be completed before authentication credentials are exchanged.

This means that when using a sniffer on a wired port, or in the wireless airspace, the certificates that are exchanged can be captured.   This might be useful information if (as some organizations implement) mutual certificate exchange is deemed sufficient for machine-based authentication.

Note: In the world of 802.1x, and Microsoft Windows, the 802.1x supplicant is implemented with a dual-level authentication.  A machine credential can be presented upon machine boot, and a user credential presented when the user logs into the machine after the boot phase.

In order to capture the bytes of X.509 certificates during an EAP-TLS exchange, either configure wireshark to monitor a wired interface that represents a passive network tap between a client workstation and network switch, or configure a monitor mode wireless network interface.   A wireless command-line example is:

# iw dev wlan0 interface add wlan0mon type monitor

In order to capture EAP traffic in Wireshark, it is simplest to enable a display filter by using the keyword of “eap”.

After enabling the display filter, perform the login sequence on the client workstation in question by rebooting the machine, and re-authenticating, or even by simply disconnecting and reconnecting the wired network interface.

Assuming a full authentication sequence is successful, you should see a packet capture similar to the diagram below.

The authenticator (Wireless AP, or network switch) sends an EAP “Request Identity” message and assuming the client workstation is configured correctly, it will respond with a “Response Identity” message.

Assuming things are configured correctly, the authenticator will then request EAP-TLS protocol as seen in packet 188 listed above.

What is of interest to us starts at packet 192 whereby the actual certificates are exchanged.  In this exchange, we should be able to export the certificate both presented by the client as well as the certificate presented by the server.  In addition, RADIUS servers will often send the Certifying Authority (CA) certificate along with the RADIUS server certificate itself.  Altogether we may extract three total certificates.

Note that EAP packets are OSI layer 2 and thus limited to the MTU of the transmission medium which will most often be 1500 bytes or less.  Thus the EAP protocol will fragment the certificate data over multiple frames.  Having said that, Wireshark is kind enough to reassemble these fragments.

Looking at frame 192 in the wireshark capture, we can see that the protocol dissector shows us two different certificates in the “SERVER HELLO” packet, one of which has the common name of “living.thyer.org” (the RADIUS server), and the other has the common name of “ROOT-CA” (the certifying authority).

To save the certificate, a simple byte export is required by highlighting the “Certificate” field in the protocol dissector window, right-clicking, and selecting “Export Selected Packet Bytes”.

This can be repeated for ALL certificates in the EAP packet exchange.  After this has been completed, you should successfully have a binary certificate (DER) representation of either two or three certificates contained within the EAP traffic.

The diagram below shows the client-side certificate starting in packet number 207.

In order to validate the certificate format and information, you can use OpenSSL on the command line to read the certificate.

# openssl x509 -inform DER -in cert.der -text

To convert back to PEM (base64) format, you can specify the OpenSSL “-out” flag with a new filename.

# openssl x509 -inform DER -in cert.der -out cert.pem