EAP
acronymStands for: Extensible Authentication Protocol (RFC 3748)
The Extensible Authentication Protocol of RFC 3748: a framework of four packet codes that carries any of dozens of authentication methods between a peer and an authenticator, usually over PPP or Ethernet, without needing IP.
EAP is not an authentication method; it is the envelope the methods travel in. RFC 3748 (June 2004) defines four codes, Request, Response, Success and Failure, and a Type octet on Requests and Responses that names the method: 1 Identity, 2 Notification, 3 Nak, 4 MD5-Challenge, 5 One-Time Password, 6 Generic Token Card, 254 Expanded Types and 255 Experimental. Everything an enterprise actually deploys, EAP-TLS, PEAP, EAP-TTLS, EAP-FAST, TEAP, EAP-pwd, EAP-SIM and EAP-AKA, is a Type carried inside that envelope. The RFC calls it a lock-step protocol (one Request, one Response, no pipelining) that typically runs directly over data link layers such as PPP or IEEE 802, which is why a device can be authenticated before it has an address. The authenticator, a switch, access point or dial-in server, may act as a pass-through agent, relaying each EAP packet to a backend server inside RADIUS EAP-Message attributes (RFC 3579) and acting only on the final Success or Failure. 802.1X is EAP over LAN; the method inside is a separate decision, and the hardest one in a Wi-Fi design.
The Extensible Authentication Protocol was written so that the link layer would not have to be rewritten every time somebody invented a new way to prove identity. RFC 3748, published in June 2004 by Aboba, Blunk, Vollbrecht, Carlson and Levkowetz, obsoleting RFC 2284, defines a packet of four fields, Code, Identifier, Length and Data, and four codes: 1 Request, 2 Response, 3 Success and 4 Failure. Requests and Responses carry a Type octet in the first position of the Data field, and the Type is where the methods live. The base document itself assigns only the plumbing types: 1 Identity, 2 Notification, 3 Nak (the peer's way of saying it does not support the proposed method and listing the ones it does), 4 MD5-Challenge, 5 One-Time Password, 6 Generic Token Card, 254 Expanded Types for vendor-specific methods and 255 Experimental. Every method that matters in a network today, EAP-TLS at Type 13, EAP-TTLS at 21, PEAP at 25, EAP-FAST at 43, EAP-pwd at 52, TEAP at 55, EAP-SIM at 18 and EAP-AKA at 23, is specified in a document of its own and rides in that Type field.
Two properties of the envelope explain where EAP shows up. The RFC states that EAP "typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP", which is the whole reason it can gate a switch port or a wireless association: the device has no address yet, may never get one, and still has to be identified. And the RFC describes it as a "lock step" protocol, one Request outstanding at a time, each answered by exactly one Response, with retransmission handled by the authenticator and no pipelining. That simplicity costs round trips (a TLS-based method needs many) and it is why EAP conversations over slow or lossy links feel sluggish, but it keeps the state machine small enough to live in a switch ASIC's companion CPU.
The third design decision is the one that created the AAA industry as it exists. The authenticator, the device the peer is physically attached to, does not have to understand the method at all. RFC 3748 allows it to act as a pass-through agent for a backend authentication server, and RFC 3579 (Aboba and Calhoun, September 2003) specifies how: the switch or access point forwards each EAP packet to a RADIUS server encapsulated in EAP-Message attributes (type 79), and every RADIUS packet that carries an EAP-Message must also carry a Message-Authenticator attribute (type 80) to protect it. Where an EAP packet is larger than one attribute, several EAP-Message attributes are placed in order, consecutively, and concatenated at the far end. The switch therefore sees a conversation it cannot read between the supplicant and the server, and acts only on the final Access-Accept or Access-Reject, which carries the EAP Success or Failure. Changing the authentication method in an estate is a change on the server and the clients; the hundreds of switches in between do not care.
That separation is also where the arguments start. Because the methods are independent documents, they differ in what they protect: MD5-Challenge (Type 4, in the base RFC) is a bare challenge-response whose security claims the RFC lists as "Mutual authentication: No" and "Key derivation: No", which rules it out wherever the link needs keys from the authentication, as a wireless link does; the TLS-based methods authenticate the server with a certificate and derive keying material; the tunnelled methods (PEAP, EAP-TTLS, EAP-FAST, TEAP) run a weaker legacy exchange inside a TLS tunnel so that a password can be used without exposing it to the air. The practical consequence for a designer is that "we use 802.1X" says nothing about security until the method is named, and that the common failure in deployments, a client that does not validate the server's certificate inside the chosen method, is a method-level setting that the framework cannot enforce.
The entries on each method in this glossary carry their own RFC facts: EAP-TLS and its certificate on both sides, PEAP and its expired draft, EAP-TTLS and the legacy methods inside it, EAP-FAST and the Protected Access Credential, TEAP and its chaining, EAP-pwd and its password-only exchange, EAP-SIM and EAP-AKA and the operator's SIM. The 802.1X entry covers the LAN carriage (EAPOL), and the RADIUS entry covers the other side of the pass-through.
Also known as: extensible authentication protocol, eap method, eap methods, eapol, eap over lan