PPP Extensible Authentication Protocol (EAP)
obsoleted by
- rfc-3748 — Extensible Authentication Protocol (EAP)
updated by
- rfc-2484 — PPP LCP Internationalization Configuration Option
Extracted elements (28)
EAP does not select a specific authentication mechanism at Link Control Phase but postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific mechanism, and permits a back-end server to implement various mechanisms while the PPP authenticator acts as a passthrough.
EAP requires adding a new authentication type to LCP, meaning existing PPP implementations must be modified to use it. This strays from the previous PPP model of negotiating a specific authentication mechanism during LCP, which was a recognized disadvantage accepted in exchange for extensibility.
The suggested retransmission timer is 6 seconds with a maximum of 10 retransmissions as default, with longer timeouts recommended when Token Cards are involved. This guidance exists because the authentication process will often involve user input, requiring care in retransmission strategies.
Success and Failure packets are not acknowledged and may be lost. A peer MUST allow for this circumstance. The peer can use receipt of a Network Protocol packet as an alternative indication of Success, and a LCP Terminate-Request as an indication of Failure.
There is no requirement that authentication be full-duplex or that the same protocol be used in both directions. Different authentication protocols MAY be used in each direction, depending on what is negotiated.
All EAP implementations MUST support Types 1 (Identity), 2 (Notification), 3 (Nak), and 4 (MD5-Challenge). The Nak Type MUST NOT be sent in a Request; it MUST only be sent in response to a Request that uses an authentication Type code.
Displayable messages used in EAP (such as in Identity Requests and Notifications) MUST follow the UTF-8 transformation format (RFC 2044) and MUST NOT affect operation of the protocol.
If a peer receives a duplicate Request for which it has already sent a Response, it MUST resend its Response. If a peer receives a duplicate Request before sending a Response (i.e., waiting for user input), it MUST silently discard the duplicate Request.
If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase.
The authenticator MUST transmit an EAP Request (Code=1) and MUST continue sending additional Requests until a valid Response is received or an optional retry counter expires. Retransmitted Requests MUST use the same Identifier value to distinguish them from new Requests.
The authenticator MUST transmit Code=3 (Success) on successful authentication and MUST transmit Code=4 (Failure) if it cannot authenticate the peer. An authenticator MAY issue multiple Requests before sending Failure to allow for human typing mistakes.
The peer MUST send a Response packet in reply to a Request. Responses MUST only be sent in reply to a received Request and MUST never be retransmitted on a timer. The Identifier field of the Response MUST match that of the Request.
EAP Code values are: 1=Request, 2=Response, 3=Success, 4=Failure. Exactly one EAP packet is encapsulated in the PPP Data Link Layer frame where the protocol field is type hex C227.
The Generic Token Card type (6) supports token card devices requiring user input. The Request contains an ASCII text message; the Response contains the token card information needed for authentication. Both Request and Response Type-Data lengths are derived from the EAP Length field and MUST NOT be null-terminated.
The Identity type (1) is used to query the identity of the peer, typically issued as the initial Request. The Request MAY include an optional displayable message; the Response MUST be Type 1 and contains the peer's identity (zero-length if unknown). The field MUST NOT be null-terminated.
The initial EAP Request/Response Type codes are: 1=Identity, 2=Notification, 3=Nak (Response only), 4=MD5-Challenge, 5=One-Time Password (OTP, RFC 1938), 6=Generic Token Card. Types 1-3 are special-case; Types 4-6 define authentication exchanges.
The MD5-Challenge type (4) is analogous to PPP CHAP with MD5. The Request contains a challenge; the Response MUST be either Type 4 (MD5-Challenge) or Type 3 (Nak). All EAP implementations MUST support MD5-Challenge. Type-Data contains Value-Size (1 octet), Value, and Name.
The Nak type (3) is valid only in Response messages and is sent when the requested authentication Type is unacceptable. The Type-Data field MUST contain a single octet indicating the peer's desired authentication type. Authentication Types are numbered 4 and above.
The Notification type (2) conveys a displayable message from authenticator to peer (e.g., password expiration warnings). The peer SHOULD display or log it. A Response MUST be sent immediately with Type=2 and zero-length Type-Data, independent of how the message is displayed.
The One-Time Password type (5) uses the OTP system defined in RFC 1938. The Request contains a displayable OTP challenge; the Response MUST be Type 5 (OTP) or Type 3 (Nak). The Response Type-Data contains the 6 words from the OTP dictionary. Messages MUST NOT be null-terminated.
Counters used for authentication failure SHOULD NOT be reset until after successful authentication or subsequent termination of the failed link, to prevent brute-force circumvention via repeated renegotiation.
There is no provision for retries of failed authentication within EAP itself, but the LCP state machine can renegotiate the authentication protocol at any time, allowing a new attempt. Implementations vary in whether they terminate the link on failure; some limit Network-Layer traffic to a filtered subset instead.
To prevent downgrade attacks, each named user SHOULD be authenticated by exactly one method. Allowing multiple methods makes the user vulnerable to negotiation of the least secure option (e.g., PAP instead of EAP). If a user needs different methods under different circumstances, distinct identities SHOULD be employed.
MD5-Challenge Type-Data encoding: Value-Size (1 octet), followed by the MD5 Value of that length, followed by the Name. This mirrors the PPP CHAP (RFC 1994) field layout.
Request and Response packets extend the base EAP header with a Type field (1 octet, indicating the request/response type) and Type-Data (variable, format determined by Type). The Length field covers Code, Identifier, Length, Type, and Type-Data.
Success and Failure packets contain only Code (3 for Success, 4 for Failure), Identifier (1 octet, MUST match the Identifier of the Response it acknowledges), and Length (fixed value of 4). There is no Data field.
The base EAP packet format contains: Code (1 octet, identifies packet type), Identifier (1 octet, matches requests to responses), Length (2 octets, total packet length including Code/Identifier/Length/Data), and Data (variable). Octets outside the Length range are treated as Data Link Layer padding and ignored.
The EAP LCP Configuration Option has Type=3, Length=4, and Authentication-Protocol=C227 (hex). This 4-octet option is carried in a PPP LCP Configure-Request to negotiate EAP as the authentication protocol.