An overview of 802.1X authentication methods and EAP

How 802.1X and EAP work

The 802.1X protocol uses the three following components for authentication:

1. Supplicant, or peer, such as a wireless client trying to access the network.
2. Authenticator, such as a wireless access point (AP), which initiates a request to authenticate the supplicant.
3. Authentication server, such as a RADIUS server, which acts as a database and permits devices to connect to the network.

802.1X uses EAP on encrypted point-to-point networks to send information between a supplicant and authentication server. Unlike other authentication protocols in which a client requests authentication, EAP is designed so the authenticator initiates the request to grant access to a client. The authenticator acts as the mediator between the supplicant and server throughout the authentication process.

When an authenticator initiates a request, the supplicant provides its identifying information and waits for permission from the authentication server. The server then replies to the supplicant with an EAP request and specifies which EAP method the device should use. Once the authentication server responds with a successful authentication, the supplicant has access to the network port.

EAP usually runs over Layer 2 of the OSI model, the data link layer, and doesn't require Layer 3 IP connectivity. Wireless security protocols, such as Wired Equivalent Privacy (WEP), Wi-Fi Protected Access, WPA2 and WPA3, support EAP as well.

Enterprises can choose which EAP type devices should use based on security requirements, desired features and staff expertise.

Below are some EAP types used for authentication:

• EAP-Message Digest 5 (EAP-MD5).
• Lightweight EAP (LEAP).
• Protected EAP (PEAP).
• EAP-Subscriber Identity Module (EAP-SIM).
• EAP-Authentication and Key Agreement (EAP-AKA).
• EAP-Transport Layer Security (EAP-TLS).
• EAP-Microsoft Challenge Handshake Authentication Protocol (EAP-MS-CHAPv2).
• EAP-Tunneled TLS (EAP-TTLS).
• EAP-Flexible Authentication via Secure Tunneling (EAP-FAST).
• EAP-Generic Token Card (EAP-GTC).

EAP-MD5

The MD5 challenge was one of the first EAP authentication methods mentioned in the 1995 Internet Engineering Task Force (IETF) draft that eventually published as RFC 2284. EAP-MD5 provides one-way client authentication. The server sends the client a random challenge, and the client proves its identity by hashing the challenge and its password with MD5.

EAP-MD5 offers little security and is susceptible to many types of attacks. Because a man in the middle could see both the challenge and response, EAP-MD5 is vulnerable to a dictionary attack when used over an open medium. Additionally, with no server authentication, the protocol is vulnerable to spoofing. Finally, EAP-MD5 cannot deliver keys. As a result, EAP-MD5 can be used over wired connections but should not be used over a wireless LAN (WLAN).

Due to vulnerabilities with EAP-MD5, Microsoft deprecated support for the EAP type after its release of Windows Vista.

LEAP

Lightweight EAP, also known as EAP-Cisco Wireless, provides mutual client and server authentication over Cisco WLANs. As with EAP-MD5, a LEAP server sends the client a random challenge, which the client uses to return a hashed password. The authenticated client challenges the server for its password, followed by a key exchange using dynamic WEP keys.

Because LEAP is a proprietary protocol, it can only be used in corporate WLANs with Cisco APs and Cisco-compatible cards. Like EAP-MD5, LEAP is vulnerable to dictionary attacks. Attackers can use many tools to crack LEAP-authenticated passwords, and new WLANs should avoid LEAP. Organizations with LEAP in place should ensure all clients and servers use long, random passwords and upgrade to a stronger EAP type as soon as possible.

PEAP

Protected EAP provides mutual authentication, using server certificates, a TLS tunnel and client authentication through that encrypted tunnel. Essentially, PEAP encapsulates EAP with a TLS tunnel for added encryption and security.

Cisco, Microsoft and RSA Security worked together to develop PEAP, which has two primary versions: PEAPv0 and PEAPv1. Microsoft products support PEAPv0, while Cisco products support PEAPv0 and PEAPv1. While IETF released a PEAPv2 draft, that PEAP version didn't take off.

PEAP provides outer authentication with the TLS tunnel during the information exchange between client and server. It requires the client to use another EAP type, like EAP-MS-CHAPv2, EAP-TLS or EAP-GTC, for inner authentication. For example, PEAPv0 is usually paired with EAP-MS-CHAPv2, while PEAPv1 typically works with EAP-GTC.

A PEAP authentication server must parse both EAP and the contained authentication protocols. It's critical to use the same version of PEAP on clients and servers.

EAP-SIM

The 3rd Generation Partnership Project (3GPP) developed and defined EAP-SIM in RFC 4186. EAP-SIM provides mutual authentication based on the SIM card found in devices sold by carriers that have Global System for Mobile Communications (GSM) networks. A SIM might be a small chip inserted into in a cellphone, a wireless data card or a USB stick. That smart card implements the authentication algorithm normally used by cellular devices to authenticate to GSM networks.

802.1X requests carrying EAP-SIM are relayed through the carrier's roaming gateway to a GSM authentication server. This EAP type can be used to authenticate devices like smartphones that roam between commercial 802.11 hotspots and GSM networks.

EAP-AKA

3GPP developed the EAP-AKA protocol under IETF RFC 4187. The protocol is used for communication between an identity module, such as Universal Mobile Telecommunications System (UMTS) SIM (USIM), within a mobile device or smart card and an operator's network infrastructure. The two entities use predetermined secret keys to exchange verification information and acknowledge authentication.

With the advancement of mobile networks, operators typically use different generations of standards to build their network infrastructure. For example, a mobile operator might have a second-generation network based on the GSM standard. Another operator might use a third-generation UMTS network or a fourth-generation LTE network.

These generations also require different EAP types. GSM networks that rely on SIM cards -- not USIM -- typically use EAP-SIM for authentication. Meanwhile, non-GSM carriers with UMTS or LTE networks can use EAP-AKA, as it supports USIMs employed by devices on those networks. Although a carrier's network determines which EAP type a smartphone must use, the permanent authentication keys used by EAP-AKA are considered stronger than the derived authentication keys used by EAP-SIM.

IETF defined an updated version of EAP-AKA in RFC 5448, dubbed EAP-AKA', to support interoperability between 3GPP and non-3GPP mobile networks. EAP-AKA' adds an additional layer of security by updating how session keys are generated and using Secure Hash Algorithm-256 instead of SHA-1.

As 5G technology develops, IETF has focused on an extension to EAP-AKA', known as EAP-AKA-Perfect Forward Secrecy (EAP-AKA'-PFS), defined in the RFC 9048 draft. EAP-AKA'-PFS is expected to provide better support for 5G networks, while adding forward secrecy to prevent attackers from accessing pre-shared secrets and decrypting old data.

EAP-TLS

The EAP-TLS protocol is defined in RFC 5216. It provides mutual digital certificate authentication between client and server, using the TLS protocol to secure the data. A digital certificate verifies an entity's identity and proves it owns a public key. Most enterprises obtain digital certificates for their clients and servers from a certificate authority, which is a third-party organization responsible for issuing and maintaining certificates.

The EAP server uses TLS to demonstrate that it holds a digital certificate, requesting the same from the client. The client uses its certificate to prove its identity, and the two entities exchange keying material. The TLS tunnel ends once authentication has been completed, but the keys delivered by EAP-TLS can be used to encrypt data with Advanced Encryption Standard, Temporal Key Integrity Protocol or WEP.

EAP-TLS is generally regarded as the strongest EAP and the most expensive to deploy, as it requires certificates for authentication instead of credentials. The protocol is a good fit in WLANs where clients already have digital certificates or where high security needs to justify the investment in a public key infrastructure to manage those certificates.

EAP-MS-CHAPv2

EAP-MS-CHAPv2 wraps Microsoft CHAP inside EAP. This EAP type can also be used inside the TLS tunnel created by PEAP, called PEAP-MS-CHAPv2.

EAP-MS-CHAPv2 uses mutual authentication and key derivation, following the traditional challenge, response and authentication process among the client, authenticator and authentication server. It requires a certificate from the authentication server but only requests a password for clients. As such, the protocol is more susceptible to vulnerabilities, such as dictionary, evil twin and man-in-the-middle attacks.

The protocol can be a good fit for companies that want to reuse Microsoft user credentials and servers, such as Active Directory, for wireless authentication. But experts recommend transitioning to a more secure EAP type, such as EAP-TLS.

EAP-TTLS

EAP-TTLS, defined under RFC 5281, encapsulates data exchanges between client and server with TLS. The protocol requires the server to authenticate itself by a certificate and establish a TLS tunnel through which it challenges the client. Unlike in EAP-TLS, which uses both server and client digital certificates, EAP-TTLS requires clients to respond with passwords, which are obscured by the TLS tunnel.

EAP-TTLS balances security versus deployment cost by replacing client-side certificates with legacy password authentication methods, such as Password Authentication Protocol, CHAP and MS-CHAPv2. While the EAP method is still vulnerable to attacks because of its credentials-based client authentication, the TLS encryption does increase security during the exchange of credentials.

To avoid exposing the client's name, EAP-TTLS should be configured to send an anonymous identity when 802.1X starts and then send the actual identity through the TLS tunnel. That tunnel ends when authentication is completed and keys are delivered.

EAP-TTLS can work in WLANs that reuse legacy user authentication databases in a secure fashion. The protocol is similar to PEAP but uses different client authentication protocols. Like PEAP, it provides mutual authentication and uses server certificates and a TLS tunnel to authenticate the client.

EAP-FAST

Cisco created EAP-FAST as a replacement for LEAP, available under RFC 5422. Like PEAP and EAP-TTLS, FAST provides TLS tunnels for mutual authentication. However, EAP-FAST makes it optional for servers to authenticate with a digital certificate, while clients exchange credentials. Instead, a one-time provisioning exchange establishes a shared secret, called a Protected Access Credential (PAC) key. That PAC key is used for all subsequent authentications.

EAP-FAST caters to clients with small footprints that would be noticeably slowed by digital certificate signature verification. The protocol is proprietary to Cisco, but enterprises can obtain a Cisco module to use EAP-FAST in Windows. Apple devices also support EAS-FAST.

EAP-GTC

EAP-GTC, first defined in RFC 2284, is an inner authentication method that uses a security token. The protocol is often used within a TLS tunnel created by PEAP, known as PEAPv1/EAP-GTC. EAP-GTC defines an EAP envelope to carry one-time passwords generated by token cards and requires the server to authenticate with a certificate.

EAP-GTC is a good fit for companies that use two-factor authentication to avoid common password compromises, such as shared passwords or improper password hygiene.

Check for EAP compatibility

Network teams should double-check which EAP types their products support. Those that work with multivendor WLANs should ensure their devices use compatible EAP types.

Organizations that choose to use credentials-based EAP types should ensure their employees and devices follow proper password hygiene, while those that opt for digital certification methods should carefully document installed certificates and keep systems updated.

Editor's note: This article was updated to reflect the evolution of 802.1X authentication and EAP types.