{"id":17930,"date":"2020-08-17T15:07:32","date_gmt":"2020-08-17T07:07:32","guid":{"rendered":"https:\/\/version-2.com.tw\/?p=17930"},"modified":"2020-10-07T10:55:52","modified_gmt":"2020-10-07T02:55:52","slug":"monitoring-802-1x-eap-what-you-need-to-know","status":"publish","type":"post","link":"https:\/\/version-2.com\/zh\/2020\/08\/monitoring-802-1x-eap-what-you-need-to-know\/","title":{"rendered":"Monitoring 802.1X EAP: What You Need to Know"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

First Thing\u2019s First<\/strong><\/span><\/h2>

As we\u2019ve written about previously, the standard authentication protocol used on encrypted networks is Extensible Authentication Protocol (EAP)<\/a>, 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.<\/p>

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

MAC Authentication Bypass (MAB)<\/strong><\/span><\/h2>

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.<\/p>

\"EAP<\/p>

Session Initiation<\/strong><\/span><\/h2>

From the switch\u2019s 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.<\/p>

MAC Address Learning<\/strong><\/span><\/h2>

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.<\/p>

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<\/p>

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.<\/p>

\"RADIUS<\/p>

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.<\/p>

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.<\/p>

Session Authorization<\/strong><\/span><\/h2>

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.<\/p>

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.<\/p>

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

Session Accounting<\/strong><\/span><\/h2>

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.<\/p>

\"EAP<\/p>

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.<\/p>

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.<\/p>

The supplicant can terminate the authentication of the port by sending an EAPOL-logoff frame to the authenticator.<\/p>

Supplicant to Authenticator (EAPoL)<\/strong><\/span><\/h2>

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:<\/p>

\"EAPoL<\/p>

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.<\/p>

The useful portions that can usually be derived from a pcap are:<\/p>

\"EAP-Identity<\/p>

In this frame, you can see the Client\u2019s (Supplicant) Identity being used of \u201cVova.Halimon<\/strong>\u201c. 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.<\/p>

For more information on EAP types, visit the IANA EAP registry<\/a>.<\/p>

EAP-TLS (Certificate Example)<\/strong><\/span><\/h2>

<\/p>

EAP Auth Method Negotiation and Credential Exchange:<\/span><\/strong><\/h2>

\"EAP<\/p>

The first message in the above screenshot is the server\u2019s proposal of EAP-PEAP (EAP-TLS, EAP-TTLS EAP-FAST, EAP-LEAP, EAP-MD5) then the client\u2019s response with, \u201cEAP-PEAP good for me\u201d 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.<\/p>

EAP Success (Wired & Wireless) & 4-Way Handshake (Wireless):<\/strong><\/span><\/h2>

\"EAP<\/p>
EAP Code<\/strong><\/td>Type<\/strong><\/td><\/tr>
1<\/td>Request<\/td><\/tr>
2<\/td>Response<\/td><\/tr>
3<\/td>Success<\/td><\/tr>
4<\/td>Failure<\/td><\/tr><\/tbody><\/table>

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 \u2013 key attributes in the RADIUS Access-Accept response to perform the 4-way handshake and create the encryption keys for secure communication.<\/p>

Extensible Authentication Protocol (EAP) Authentication Types<\/strong><\/span><\/h2>