Extensible Authentication Protocol (EAP)
Extracted elements (29)
EAP authentication is initiated by the server (authenticator) rather than the client, unlike many authentication protocols. This design allows the authenticator to request more information before selecting an authentication method, and permits pass-through to a backend server that implements the actual methods.
EAP does not include fragmentation and reassembly at the EAP layer; individual methods must provide it if needed. This simplifies the lock-step protocol and avoids duplicating functionality in lower layers (e.g., IP-level fragmentation); an implementation may advertise an artificially large EAP MTU to delegate fragmentation to the lower layer.
EAP methods originally designed for PPP (which guarantees a 1500-octet MTU for control frames per RFC 1661) may lack fragmentation and reassembly. When EAP is transported over a lower layer supporting fragmentation such as IP, it may be preferable to provide an artificially large EAP MTU so that fragmentation occurs at the lower layer rather than within the EAP method.
Within IEEE 802.1X it is not possible to negotiate non-EAP authentication mechanisms such as PAP or CHAP, because EAP over IEEE 802 does not involve PPP link or network layer negotiations. AAA protocols such as RADIUS (RFC 3579) and Diameter EAP only support pass-through authenticator operation; pass-through peer operation is unsupported.
After the authenticator sends a failure result indication to the peer, it MUST subsequently send a Failure packet regardless of the peer's response. After exchanging success result indications, the authenticator MUST send a Success packet. On the peer side, once the method completes unsuccessfully, the peer MUST terminate the conversation and indicate failure to the lower layer.
All EAP implementations MUST support Types 1–4 (Identity, Notification, Legacy Nak, MD5-Challenge) and SHOULD support Type 254 (Expanded Types). EAP peer and EAP server implementations MUST support the MD5-Challenge mechanism; a pass-through authenticator MUST allow communication with a backend server capable of MD5-Challenge.
By default, an EAP peer MUST silently discard a 'canned' Success packet (one sent immediately upon connection without a completed EAP method exchange). This prevents a rogue authenticator from bypassing mutual authentication by sending an unsolicited Success.
Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type. When acting as pass-through, the authenticator MUST determine the authentication outcome solely based on the Accept/Reject indication sent by the backend authentication server, not by the contents of an encapsulated EAP packet.
EAP is a lock-step protocol supporting only a single packet in flight. Other than the initial Request, a new Request MUST NOT be sent prior to receiving a valid Response. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation.
EAP methods SHOULD include fragmentation and reassembly support if their payloads can exceed the minimum EAP MTU of 1020 octets. EAP itself does not support path MTU discovery, and the basic method types (Identity, Notification, Nak, MD5-Challenge, OTP, GTC, Expanded Nak) do not provide fragmentation.
EAP packets with Code values other than 1–4 MUST be silently discarded by both authenticators and peers. Success and Failure packets MUST NOT contain additional data beyond the 4-octet header.
Lower layer transports for EAP MUST preserve ordering between a source and destination at a given priority level. Running EAP over raw IP or UDP transport is NOT RECOMMENDED because reordering will typically result in EAP authentication failure.
Only one authentication method (Type 4 or greater) MUST be utilized within an EAP conversation, after which the authenticator MUST send a Success or Failure packet. An authenticator MUST NOT send a Request for an additional method after completion of the initial authentication method; a peer receiving such a Request MUST treat it as invalid and silently discard it.
The authenticator MUST retransmit Request packets until a valid Response is received, a retry counter expires, or a lower layer failure indication is received. Retransmitted Requests MUST carry the same Identifier value; any new Request MUST use a different Identifier value.
The Identifier field of a Response MUST match that of the currently outstanding Request. An authenticator receiving a Response with a non-matching Identifier MUST silently discard it. A peer receiving a valid duplicate Request for which it has already sent a Response MUST resend its original Response without reprocessing.
Use of EAP for purposes other than network access authentication, such as bulk data transport, is NOT RECOMMENDED. EAP is a lock-step protocol that cannot efficiently transport bulk data and provides only enough support for reliable transport of authentication protocols.
Where EAP runs over an unreliable lower layer, the retransmission timer SHOULD be dynamically estimated using RFC 2988 algorithms (SRTT, RTTVAR, RTO) with Karn's algorithm and jitter. A maximum of 3–5 retransmissions is suggested. Over a reliable lower layer, the retransmission timer SHOULD be set to infinite.
The EAP multiplexing model uses the Code field (analogous to IP protocol number) to demultiplex to peer vs. authenticator layers, and the Type field (analogous to TCP/UDP port) to demultiplex to specific EAP method implementations. Legacy Nak (Type 3) and Expanded Nak (Type 254) are used exclusively for method negotiation and MUST NOT carry data destined for other EAP methods.
IANA maintains a registry of EAP Method Types. Types 1–6 and 254–255 are defined by RFC 3748. Types 1–191 require IETF consensus; Types 192–253 are available for vendor-specific allocation by IANA; Type 254 is Expanded Types; Type 255 is Experimental use.
IANA maintains a registry of EAP Packet Codes. Codes 1–4 are defined by RFC 3748 (Request, Response, Success, Failure). Assignment of new Codes requires IETF consensus.
EAP methods supporting key derivation export a Master Session Key (MSK, at least 64 octets) and an Extended Master Session Key (EMSK, at least 64 octets). The EMSK MUST NOT be shared with the authenticator or any third party. Keys derived for different purposes must be cryptographically separate such that knowledge of one does not allow computation of another.
EAP methods that transmit cleartext passwords (e.g., GTC) MUST NOT be used outside a protected tunnel with server authentication, as passwords would be exposed to eavesdroppers. The EAP GTC method is explicitly restricted from supporting cleartext passwords in the absence of such a tunnel.
EAP methods that use passwords or shared secrets without dictionary attack protection (such as MD5-Challenge) are vulnerable to offline dictionary attacks by an eavesdropper who captures the exchange. Methods intended for use in hostile environments SHOULD provide dictionary attack resistance.
Multiple authentication methods within a single EAP conversation are prohibited because they are vulnerable to man-in-the-middle attacks: an attacker could interpose itself between peer and authenticator, using one method toward the peer while completing a different method toward the authenticator. Tunneled methods that present a single Type to EAP are exempt but MUST protect against MitM attacks.
The EAP Identity Request and Response are sent in cleartext, allowing an attacker to snoop, modify, or spoof the peer identity. It is RECOMMENDED that the Identity Response be used primarily for routing, and that EAP methods include a method-specific identity exchange with per-packet authentication, integrity protection, replay protection, and confidentiality.
Request (Code=1) and Response (Code=2) packets extend the base EAP header with a 1-octet Type field and variable-length Type-Data field. The Type field of a Response MUST either match the Request Type or be a Legacy Nak (Type 3) or Expanded Nak (Type 254).
Success (Code=3) and Failure (Code=4) packets are exactly 4 octets: Code, Identifier, and Length=4 with no Data field. The Identifier MUST match the Identifier of the Response packet that triggered the Success or Failure.
The EAP packet header consists of a 1-octet Code field, a 1-octet Identifier field, a 2-octet Length field (total packet length including Code, Identifier, Length, and Data), and a variable-length Data field. Octets outside the Length range MUST be ignored as Data Link Layer padding; a packet with Length larger than received octets MUST be silently discarded.
The Expanded Type format (Type=254) uses an 8-octet structure: 1-octet Type=254, 3-octet Vendor-Id, and 4-octet Vendor-Type. Vendor-Id of 0 denotes IETF types. This format supports both Expanded method requests and Expanded Nak responses.