IEEE 802.1X and EAP – Part 1: The Basics

IEEE 802.1X plays an essential role in network security. This blog post gives a basic introduction to the elements used in 802.1X. This content is mainly taken from my WLAN security workshop to introduce 802.1X before moving to more complex authentication scenarios. If you want to learn WLAN security or attend a CWNA training, contact me (ki at iwen dot de).

This is a two part blog post:
Part 1: The basics of IEEE 802.1X
Part 2: A look into the communication in Wireshark

The name

Before going to the basics, we have to clarify a little bit about the naming. Small letters (like in IEEE 802.11ax) are used for amendments to a standard, but capital letters are used for the standards themselves. So if we want to be accurate, we should use 802.1X because it is a standard, although 802.1x is quite common and accepted.

The Goal of 802.1X

The abstract of the standard summarizes the purpose of 802.1X very well. The following quote is from the 2004 version:

Port-based network access control makes use of the physical access characteristics of IEEE 802® Local Area Networks (LAN) infrastructures in order to provide a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics, and of preventing access to that port in cases in which the authentication and authorization process fails.

IEEE Std 802.1X™- 2004

The building blocks of 802.1X

In 802.1X we have three relevant components, which are named system roles in the standard:

• The Authenticator is a port that controls access to the network. In switched networks, this is the physical port to the client, in wireless networks, this is a virtual port that is defined by the wreless association. Authentication is enforced here before allowing access to the network.
• The Supplicant is the port that wants to access the network. This is typically the clients’ ethernet or wireless NIC.
• The Authentication Server (AS) performs the authentication by checking the Supplicants’ credentials on behalf of the Authenticator.

Controlled and Uncontrolled ports

The standard defines two virtual port roles which are typically used on the authenticator ports:

• The Controlled Port:
  General data traffic uses this port. While the client is not authorized, the controlled port discards all frames. After the authorization, this port allows client traffic.
• The Uncontrolled Port:
  Even without authorization, the authentication traffic needs to be processed. The uncontrolled port handles this traffic and relays it to the authentication server.

This picture is again from the 2004 version of the standard.

The Authentication

802.1X itself does not do the authentication. Instead, it defines the authentication framework and the L2 transport between the supplicant and the authenticator.

EAP is used for the authentication, which is defined in RFC 3748.

The following is a definition of EAP from the RFC:

[…] Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.

https://datatracker.ietf.org/doc/html/rfc3748

EAP runs between the Supplicant and the Authentication Server. The Authenticator is a kind of “Proxy” to convert the L2 communication between the Supplicant and the Authenticator to an IP communication between the Authenticator and the Authentication Server. While the authentication is happening, the Supplicant device is not expected to have an IP address. Therefore, L2 communication is all that can be done. This communication is “EAP over LAN” or EAPoL which is defined in the 802.1X standard. The transport between the Authenticator and the Authentication Server is typically RADIUS, although the standard does not specify that it has to be RADIUS. The EAP RFC also mentions Diameter as a valid AAA protocol.
EAP is designed to support different methods of authentication. One benefit of EAP over legacy methods like PAP and CHAP that were implemented on Access Servers is that the Authenticator does not need to understand the EAP communication. It only needs to forward the EAP packets between the Supplicant and Authentication Server.

Some of the EAP Methods used in wired and wireless LANs are:

• PEAP
• EAP-TTLS
• EAP-TLS
• EAP-FAST
• TEAP

Not common anymore, but perfect for a first look at EAP is EAP-MD5 because it is simple. We will use EAP-MD5 in the next part of this Blog post to look at every packet in the communication.

After the authentication between the Supplicant and the Authentication Server (1), the AS has to inform the Authenticator device of the result (2). This is typically done in a RADIUS Access-Accept message which causes the Authenticator to enable communication on the Controlled Port.

EAP-MD5

In the next part, we look at an EAP-MD5 authentication. Here are some properties of EAP-MD5:

• It is defined in RFC 3748 as a mandatory implementation: „EAP peer and EAP server implementations MUST support the MD5-Challenge mechanism.“
•  It’s a non-tunneled authentication. In many other EAP methods, a (TLS) tunnel is built first to protect the authentication. This is not done with EAP-MD5.
•  Only the client is authenticated. In all real-world methods, the client first authenticates the Authentication Server (we do not want to provide our credentials to the MitM attacker). After that, the AS authenticates the client.
•  No certificates are used. Most other methods use at least a certificate on the Authentication Server to allow the client to authenticate the server. Without this server authentication, the certificate is not needed.
•  The authentication is subject to brute-force or dictionary attacks.

With these drawbacks, we probably will not see any EAP-MD5 in our networks, but it is the perfect method to learn how authentication works.