# 802.1X and the EAP methods: the port, the envelope, and the choice that carries the security

> Port-based network access control from the frame up: the supplicant, authenticator and server, EAPOL and the controlled port, the four EAP codes of RFC 3748, and then the decision that actually matters, which method runs inside the envelope. EAP-TLS, PEAP, EAP-TTLS, EAP-FAST, TEAP, EAP-pwd, EAP-SIM and EAP-AKA compared on what each authenticates with, what it protects, and what it needs on the client, with the one setting that undoes most of them, the VLAN assignment the server returns, and the fallbacks for devices that cannot do any of it.

Source: https://ronutz.com/en/learn/802-1x-and-eap-methods  
Updated: 2026-10-06

---

## What the standard decides, and what it leaves to you

IEEE 802.1X is, in the encyclopaedia's words, "an IEEE Standard for port-based network access control": a switch port or a wireless association carries nothing until an identity has been presented and accepted. The standard defines who talks to whom and how the frames are carried. It does not define how identity is proved. That is delegated to EAP (the Extensible Authentication Protocol), and inside EAP to a method, and the method is where almost all of the security lives. A deployment described as "802.1X" could be certificates on every device or a password sent through a tunnel to an unverified server, and the two have nothing in common except the frame format. This article covers the frame format briefly and the methods at length, because that is where the decisions are.

## Three parties, two ports, one address

The model has three roles. The supplicant is the software on the device asking for access. The authenticator is the switch or access point whose port the device is attached to; the encyclopaedia says it "acts like a security guard". The authentication server, almost always a RADIUS (Remote Authentication Dial-In User Service) server, decides. On the authenticator, 802.1X-2001 defines two logical ports on each physical one: an uncontrolled port that always passes the frames the authentication itself needs, and a controlled port that forwards traffic only once authentication has succeeded, with a Port Access Entity running the state machine.

The carriage is EAP over LAN, EAPOL, defined for wired 802 networks in 802.1X-2001 (Ethernet, Token Ring and FDDI), extended to 802.11 wireless in 802.1X-2004, and revised in 802.1X-2010 to work with 802.1AE MACsec and 802.1AR device identity. The conversation starts with the authenticator periodically sending an EAP-Request Identity frame to the group address 01:80:C2:00:00:03; the supplicant answers with an EAP-Response Identity; the authenticator wraps that in a RADIUS Access-Request, and the server replies with an Access-Challenge proposing a method. From then on the switch relays EAP packets it never interprets, inside the EAP-Message attributes of RFC 3579, and acts on the final Access-Accept or Access-Reject. The companion article on RADIUS end to end walks that side packet by packet.

## The envelope: four codes and a type

RFC 3748, published in June 2004, defines EAP as a packet of Code, Identifier, Length and Data with four codes: 1 Request, 2 Response, 3 Success and 4 Failure. Requests and Responses carry a Type octet, and the Type names the method. The base RFC assigns 1 Identity, 2 Notification, 3 Nak (the peer declining a method and listing what it supports), 4 MD5-Challenge, 5 One-Time Password, 6 Generic Token Card, 254 Expanded Types and 255 Experimental; every method below is a Type assigned in its own document. Two properties of the envelope matter for design. EAP "typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP", which is why it can authenticate a device that has no address. And it is "a 'lock step' protocol", one Request outstanding at a time, so a method that needs many round trips, as every TLS-based method does, is slow on a lossy or distant path and shows up as authentication timeouts.

## The methods

The table below is the decision. Each row states what the method authenticates the client with, how the server proves itself, whether a tunnel protects the exchange, and the document it comes from. The paragraphs after it carry the detail from each specification.

| Method | EAP Type | Client credential | Server authenticated by | Tunnel | Specification |
|---|---|---|---|---|---|
| EAP-TLS | 13 | Certificate | Certificate | TLS handshake is the method | RFC 5216, Standards Track |
| PEAP | 25 | Inner EAP method, usually EAP-MSCHAPv2 (password) | Certificate | TLS, inner EAP only | draft-josefsson-pppext-eap-tls-eap-10, expired |
| EAP-TTLS | 21 | Inner method: EAP, or PAP, CHAP, MS-CHAP, MS-CHAP-V2 | Certificate | TLS, inner legacy allowed | RFC 5281, Informational |
| EAP-FAST | 43 | Inner method via TLVs; PAC may replace certificate | Certificate or PAC | TLS | RFC 4851, Informational |
| TEAP | 55 | Zero or more inner EAP methods, chained | Certificate | TLS, with Crypto-Binding | RFC 7170, Standards Track |
| EAP-pwd | 52 | Password, by password-authenticated key exchange | Shared password | None needed | RFC 5931, Informational |
| EAP-SIM / EAP-AKA | 18 / 23 | GSM SIM / UMTS USIM | Operator's authentication centre | None (AKA is mutual) | RFC 4186 / RFC 4187, Informational |
| MD5-Challenge | 4 | Password hash response | Not authenticated | None | RFC 3748 (base) |

**EAP-TLS** (RFC 5216, Simon, Aboba and Hurst, March 2008) is a TLS handshake carried in EAP packets: the server presents a certificate, the client presents one too, and the exchange derives keying material by a fixed recipe, the TLS pseudo-random function with the label "client EAP encryption", 64 octets of MSK and 64 of EMSK. Because a handshake with certificates does not fit one EAP packet, the RFC defines fragmentation with an L bit (a four-octet length is present) and an M bit (more fragments follow), each fragment acknowledged with a packet of Type EAP-TLS "and no data". It is the only method here with no password anywhere, and its cost is a certificate on every client, with issuance, renewal and revocation.

**PEAP** (the draft of 15 October 2004 by Palekar, Simon, Salowey, Zhou, Zorn and Josefsson, an expired Internet-Draft) builds a TLS tunnel in which the server is authenticated by certificate, then runs "zero or more EAP methods" inside it. Its stated goals are to "protect against rogue authenticators, protect against various attacks on the confidentiality and integrity of the inner EAP method exchange and provide EAP peer identity privacy", and it makes a Crypto-Binding TLV mandatory. In practice the inner method is EAP-MSCHAPv2, and the pairing with a Windows domain made it the default for password-based enterprise Wi-Fi.

**EAP-TTLS** (RFC 5281, Funk and Blake-Wilson, August 2008) also builds a server-authenticated TLS tunnel, but the inner authentication "may itself be EAP, or it may be a legacy protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2". PAP inside the tunnel delivers the password to the server in a form any directory can verify, which is why EAP-TTLS/PAP is the usual answer when the user store is an LDAP (Lightweight Directory Access Protocol) directory without the NT hashes MSCHAPv2 needs. The RFC tells the client that the outer identity "SHOULD NOT include the actual name of the user", and lets the TTLS server proxy the inner authentication to the user's home server, which is how roaming federations work.

**EAP-FAST** (RFC 4851, Cam-Winget, McGrew, Salowey and Zhou of Cisco, May 2007) is a TLS tunnel followed by TLVs, with the twist of the Protected Access Credential: a 32-octet PAC-Key, an opaque PAC-Opaque ticket the server can decode and the peer cannot, and PAC-Info with the issuer and lifetime. A peer holding a PAC can re-establish the tunnel without a certificate exchange and without server-side state. Its design goals are mutual authentication, immunity to passive dictionary attacks, man-in-the-middle protection and efficiency for constrained devices; its operational problem was always how the first PAC reaches a device.

**TEAP** (RFC 7170, Zhou, Cam-Winget and Salowey of Cisco and Hanna of Infineon, May 2014) is the standards-track successor, "a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel". It runs "zero or more EAP methods within the protected tunnel", which is the chaining that lets a machine certificate and a user credential be proven in one conversation; it can provision a PAC or a certificate inside the tunnel; and it builds in the Crypto-Binding TLV and EAP channel binding. The RFC records that EAP-FAST "has been widely adopted" and was the working group's basis.

**EAP-pwd** (RFC 5931, Harkins and Zorn, August 2010) replaces the tunnel with mathematics: "a robust authentication method that is secure even when used with a weak password in the presence of a strong adversary". The two sides fix "an element in the negotiated group called the Password Element" from the password and prove in Commit and Confirm exchanges that they share it; the RFC's requirement is that "any advantage an adversary can gain must be directly related to the number of interactions she makes with an honest protocol participant and not through computation", and "the best advantage an attacker can gain in a single active attack is to determine whether a single guess at the password was correct". No certificates, no PKI (public key infrastructure), no validation setting to be left off; the limits are server support for the password form and narrower client support.

**EAP-SIM and EAP-AKA** (RFC 4186 and RFC 4187, Arkko and Haverinen, January 2006) let a mobile operator's SIM authenticate a device: the operator's authentication centre issues the challenge, the (U)SIM answers, and in AKA the device also verifies the network. RFC 4187 states the differences from EAP-SIM as "substantially longer key lengths and mutual authentication", and both offer pseudonyms for identity privacy and fast re-authentication. These are the methods under operator Wi-Fi offload, and the visited network is an ordinary pass-through authenticator.

**MD5-Challenge** (Type 4, in RFC 3748 itself) is listed for completeness and as a warning: the RFC's own security claims for it are "Mutual authentication: No" and "Key derivation: No", which rules it out anywhere the link needs keys from the authentication, as every wireless link does.

## The one setting that undoes most of the table

Every method whose server is authenticated by a certificate depends on the client checking that certificate against a trusted authority and an expected name. The tunnel of PEAP, EAP-TTLS, EAP-FAST and TEAP protects the inner credential only against parties outside the tunnel; a supplicant configured to accept any certificate will build its tunnel with an impostor access point and deliver its inner exchange, a PAP password in the clear inside the attacker's tunnel or an MSCHAPv2 challenge-response to be attacked offline. EAP-TLS gives such an impostor no password, but still gives it an authenticated client on a hostile network. The setting lives on the client, is enforced only by device management, and is most often missing on exactly the personal devices whose users will click through any warning. RFC 2759's advice that the authenticator "SHOULD limit the number of password retries" is the server-side control; certificate validation on every client is the one that matters, and EAP-pwd is the only password method that removes the question.

## What the server returns, and why the port behaves

The Access-Accept that ends a successful method carries the policy, and RFC 3580, the IEEE 802.1X RADIUS Usage Guidelines, names the attributes. VLAN (virtual local area network) assignment is three attributes together: Tunnel-Type set to VLAN (13), Tunnel-Medium-Type set to 802 (6), and Tunnel-Private-Group-ID carrying the VLAN identifier as a string. Session-Timeout with Termination-Action set to RADIUS-Request gives "the maximum number of seconds of service provided prior to re-authentication". NAS-Port-Type tells the server whether the request came from Ethernet (15) or Wireless-IEEE 802.11 (19), so one policy can treat the two differently. Calling-Station-Id carries the device's MAC in upper-case hyphenated form and Called-Station-Id the port's or access point's, with the SSID after a colon on wireless. The RADIUS article shows these in a full exchange; here the point is that the method proves identity and the attributes turn identity into network position.

## The devices that cannot do any of it

Printers, cameras, badge readers, phones from before the standard and the long tail of embedded things have no supplicant. The industry's fallback is MAC Authentication Bypass: when 802.1X times out on a port, the switch submits the device's MAC address as its identity. Cisco's configuration guide describes it as "a MAC-address-based authentication mechanism" for "platforms with no supplicant or not under administrative control", with cash registers, fax machines and printers as the examples, and specifies the request: "a RADIUS request with a MAC address in the Calling-Station-Id (attribute 31) and Service-Type (attribute 6) with a value of 10", Call Check. The encyclopaedia describes the same sequence, the port trying 802.1X first and then authenticating with the MAC as username and password. A MAC address is not a secret, so MAB is an admission policy for things, to be paired with a restricted VLAN or filter and with profiling that withdraws the session, by RADIUS Change of Authorization, when the thing stops behaving like what it claimed to be. For people on devices without a supplicant there is a third door, web authentication, which the companion article covers; the usual port configuration tries the three in order.

## The known limits of the standard

The encyclopaedia records the limits that were documented early and remain. In 2005 Steve Riley, drawing on research by Svyatoslav Pidgorny, described a man-in-the-middle attack in which an attacker shares an authenticated port through a hub after the legitimate device has authenticated, because the port, once open, does not re-check each frame; IPsec was the suggested mitigation then, and 802.1X-2010's integration with MACsec, which authenticates and encrypts every frame on the link, is the standard's own answer. EAPOL-Logoff frames travel in the clear and can be trivially spoofed to knock a device off a port. Neither changes the design conclusion; both argue for MACsec where the wire is not trusted and for treating 802.1X as admission control rather than per-frame security.

## Choosing

The decision follows from the table. Devices that can hold a certificate get EAP-TLS, which today means managed laptops, phones and tablets and a growing share of printers and controllers. Where machine and user must both be proven, or credentials provisioned on first contact, TEAP. Where a password back end is the constraint, PEAP with EAP-MSCHAPv2 for a Windows domain and EAP-TTLS with PAP for other directories, in both cases with server certificate validation enforced on every client by policy and verified per device class. EAP-pwd where both ends support it and no PKI is wanted. MAB for the things, web authentication for the people without supplicants, and MACsec where the cable itself is in doubt. Every one of those sentences is a method, and none of them is "802.1X".

## Sources

- [Wikipedia, IEEE 802.1X: the definition, the 2001, 2004 and 2010 editions, EAPOL and the group address, the three roles and the security-guard line, controlled and uncontrolled ports, MAB, the 2005 Riley and Pidgorny analysis and the EAPOL-Logoff weakness (read 2026-10-06)](https://en.wikipedia.org/wiki/IEEE_802.1X)
- [RFC 3748, Extensible Authentication Protocol (EAP), Aboba, Blunk, Vollbrecht, Carlson, Levkowetz, June 2004: the codes and types, lock step, data-link transport without IP, the pass-through authenticator, the MD5-Challenge security claims (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc3748)
- [RFC 5216, The EAP-TLS Authentication Protocol, Simon, Aboba, Hurst, March 2008: Type 13, fragmentation, the key material recipe (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc5216)
- [draft-josefsson-pppext-eap-tls-eap-10, Protected EAP Protocol (PEAP) Version 2, 15 October 2004, expired: Type 25, the two parts, the goals, the Crypto-Binding TLV (read 2026-10-06)](https://datatracker.ietf.org/doc/html/draft-josefsson-pppext-eap-tls-eap-10)
- [RFC 5281, EAP-TTLSv0, Funk and Blake-Wilson, August 2008: Type 21, the inner legacy methods, the anonymous outer identity, proxying to the home server (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc5281)
- [RFC 4851, EAP-FAST, Cam-Winget, McGrew, Salowey, Zhou, May 2007: Type 43, the PAC and the design goals (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc4851)
- [RFC 7170, Tunnel EAP Method (TEAP) Version 1, Zhou, Cam-Winget, Salowey, Hanna, May 2014: Type 55, chained inner methods, provisioning, Crypto-Binding and channel binding, EAP-FAST as the basis (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc7170)
- [RFC 5931, EAP Authentication Using Only a Password, Harkins and Zorn, August 2010: Type 52, the Password Element, the dictionary-attack requirement and the single-guess bound (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc5931)
- [RFC 4187, EAP-AKA, Arkko and Haverinen, January 2006: Type 23, the AKA exchange, the differences from EAP-SIM, pseudonyms and fast re-authentication (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc4187)
- [RFC 2759, Microsoft PPP CHAP Extensions, Version 2, Zorn, January 2000: the mutual authentication and the retry limit (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc2759)
- [RFC 3579, RADIUS Support For EAP, September 2003: the EAP-Message relay (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc3579)
- [RFC 3580, IEEE 802.1X RADIUS Usage Guidelines, September 2003: VLAN assignment, Session-Timeout, NAS-Port-Type and the station identifiers (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc3580)
- [Cisco IOS configuration guide, Configuring MAC Authentication Bypass: the definition, the examples and the RADIUS request MAB builds (read 2026-10-06)](https://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_aaa/configuration/15-2mt/sec-config-mab.html)