Monitoring 802.1X EAP: What You Need to Know

First Thing’s First

As we’ve written about previously, the standard authentication protocol used on encrypted networks is Extensible Authentication Protocol (EAP), which provides a secure method to send identifying information for network authentication. 802.1x is the standard that is used for passing EAP over wired and wireless Local Area Networks (LAN), as it provides an encrypted EAP tunnel that prevents outside users from intercepting information. The EAP protocol can be configured for credential (EAP-TTLS/PAP and PEAP-MSCHAPv2) and digital certificate (EAP-TLS) authentication and is a highly secure method for protecting the authentication process.

Throughout this article, we will look at how to monitor 802.1X EAP and why doing so is important from a network security perspective.

 

MAC Authentication Bypass (MAB)

MAB enables port-based access control using the MAC address of the endpoint. A MAB-enabled port can be dynamically enabled or disabled based on the MAC address of the device that connects to it. The below diagram illustrates the default behavior of a MAB-enabled port.

Session Initiation

From the switch’s perspective, the authentication session begins when the switch detects link-up on a port. The switch will initiate authentication by sending an EAP Request-Identity message to the endpoint. If the switch does not receive a response, the switch will retransmit the request at periodic intervals. If no response is received after the maximum number of retries, the switch will let IEEE 802.1X time out and proceed to MAB.

 

MAC Address Learning

During the MAC address learning stage, the switch begins MAB by opening the port to accept a single packet from which it will learn the source MAC address of the endpoint. Packets sent before the port has fallen back to MAB (that is, during the IEEE 802.1X timeout phase) are discarded immediately and cannot be used to learn the MAC address.

The switch can use almost any Layer 2 and 3 packets to learn MAC addresses, with the exception of bridging frames such as Link Layer Discovery Protocol (LLDP), Spanning Tree Protocol, and Dynamic Trunking Protocol (DTP). 1

After the switch learns the source MAC address, it discards the packet. Then the switch crafts a RADIUS Access-Request packet. A sample MAB RADIUS Access-Request packet is shown in the snapshot below.

By default, the Access-Request message is a Password Authentication Protocol (PAP) authentication request, The request includes the source MAC address in three attributes: Attribute 1 (Username), Attribute 2 (Password), and Attribute 31 (Calling-Station-Id). Although the MAC address is the same in each attribute, the format of the address differs. This feature is important because different RADIUS servers may use different attributes to validate the MAC address. Some RADIUS servers may look at only Attribute 31 (Calling-Station-Id), while others will actually verify the username and password in Attributes 1 and 2.

Because MAB uses the MAC address as a username and password, you should make sure that the RADIUS server can differentiate MAB requests from other types of requests for network access. This precaution will prevent other clients from attempting to use a MAC address as a valid credential. Cisco switches uniquely identify MAB requests by setting Attribute 6 (Service-Type) to 10 (Call-Check) in a MAB Access-Request message. Therefore, you can use Attribute 6 to filter MAB requests at the RADIUS server.

 

Session Authorization

If the MAC address is valid, the RADIUS server will return a RADIUS Access-Accept message. This message indicates to the switch that the endpoint should be allowed access to the port. Optionally, the RADIUS server may include dynamic network access policy instructions (for example, a dynamic VLAN or access control list [ACL]) in the Access-Accept message. In the absence of dynamic policy instructions, the switch will simply open the port. No further authentication methods will be tried if MAB succeeds.

If the MAC address is not valid or is not allowed to access the network for policy reasons, the RADIUS server will return a RADIUS Access-Reject message. This message indicates to the switch that the endpoint should not be allowed access to the port based on the MAC address.

If no fallback authentication or authorization methods are configured, the switch will stop the authentication process and the port will remain unauthorized.

 

Session Accounting

If the switch can successfully apply the authorization policy, the switch can send a RADIUS Accounting-Request message to the RADIUS server with details about the authorized session.

In the diagram above, the first frame sent is an EAPOL-Start frame. This frame is not critical, and the process can be started by the authenticator sending the EAP-Request Frame.

Next, the supplicant responds with an EAP-Response. Messages from the Authenticator to the Radius server use the radius protocol (UDP 1812 for Authentication)When the authenticator receives an Access-Accept packet from the radius server it will authorize the port and allow access to the supplicant. If access is denied by the Radius server an Access-Reject message will be sent to the authenticator and the port will stay unauthorized.

The supplicant can terminate the authentication of the port by sending an EAPOL-logoff frame to the authenticator.

 

Supplicant to Authenticator (EAPoL)

This is the communication method utilized that provides the Authenticator and the Client a line of communication prior to network access. This is what the capture will look like:

The EAPoL portion of communication will vary depending on the authentication type. In my examples, we are using EAP-PEAP w/EAP-MsCHAPv2. This is a fairly standard form of authentication.

The useful portions that can usually be derived from a pcap are:

In this frame, you can see the Client’s (Supplicant) Identity being used of “Vova.Halimon“. This can be extremely useful when trying to determine if the supplicant is going to authenticate as the user or the machine account as well as what the user could be typing into the username prompt.

For more information on EAP types, visit the IANA EAP registry.

EAP-TLS (Certificate Example)

EAP Auth Method Negotiation and Credential Exchange:

The first message in the above screenshot is the server’s proposal of EAP-PEAP (EAP-TLS, EAP-TTLS EAP-FAST, EAP-LEAP, EAP-MD5) then the client’s response with, “EAP-PEAP good for me” In some situations, depending on the RADIUS server configuration, the client may try to propose a method that is not permitted or supported by the server. This is where you would see that negotiation fail, and ultimately an Access-Reject / EAP-Failure.

EAP Success (Wired & Wireless) & 4-Way Handshake (Wireless):

 

EAP Code	Type
1	Request
2	Response
3	Success
4	Failure

Once the client has been successfully authenticated and authorized, there is an EAP Success message sent back to signify the end of the process. If this is a wired client, the process is over, and the client is able to start transmitting and receiving data frames. If this is a wireless client, the station will utilize a few EAP attributes and the AP will utilize two MPPE (Microsoft Point-to-Point Encryption – key attributes in the RADIUS Access-Accept response to perform the 4-way handshake and create the encryption keys for secure communication.

 

Extensible Authentication Protocol (EAP) Authentication Types

• MD5 isn’t typically used as it only does a one-way authentication, and perhaps even more importantly doesn’t support automatic distribution and rotation of WEP keys so does nothing to relieve the administrative burden of manual WEP key maintenance.
• TLS, while very secure, requires client certificates to be installed on each Wi-Fi workstation. Maintenance of a PKI infrastructure requires additional administrative expertise and time in addition to that of maintaining the WLAN itself.
• TTLS addresses the certificate issue by tunneling TLS, and thus eliminating the need for a certificate on the client side. Making this an often preferred option. Funk Software* is the primary promoter of TTLS, and there’s a charge for supplicant and authentication server software.
• LEAP has the longest history, and while previously Cisco proprietary (works with Cisco Wi-Fi adapters only), Cisco has licensed LEAP to a variety of other manufacturers through their Cisco Compatible Extensions program. A strong password policy should be enforced when LEAP is used for authentication.
• EAP-FAST is now available for enterprises that can’t enforce a strong password policy and don’t want to deploy certificates for authentication.

The more recent PEAP works similarly to EAP-TTLS in that it doesn’t require a certificate on the client side. PEAP is backed by Cisco and Microsoft and is available at no additional cost from Microsoft. If desired to transition from LEAP to PEAP, Cisco’s ACS authentication server will run both.

 

EAP-TLS Example

However, in this graphic, you can see the client and server negotiate EAP-PEAP. Once that is completed, the server will present the client with its certificate. If the client does not trust the certificate from the server, and the user does not accept the certificate(The end-user might be presented with a dialog to trust this certificate), the exchange will fail after the first frame or two of the handshake.

In this situation, however, the client trusts the server certificate, and the two endpoints secure the medium with a TLS tunnel. Once secured you should notice that the protocol becomes purely TLS and since the traffic is encrypted, we can only see that the frames are “Application Data”. This is the point at which the client and server are exchanging inner authentication data such as EAP-MsCHAPv2 or EAP-TLS.