PPP Authentication Protocols
obsoleted by
- rfc-1994 — PPP Challenge Handshake Authentication Protocol (CHAP)
Extracted elements (30)
CHAP requires the secret in plaintext form at each end, but to avoid transmitting the secret over other network links, the RFC recommends examining challenge and response values at a central server rather than each network access server, or sending the secret in reversibly encrypted form.
CHAP's use of an incrementally changing Identifier and variable Challenge Value provides protection against playback attacks; repeated re-challenges during Network-Layer phase limit the window of exposure to any single attack, with the authenticator in control of challenge frequency.
The PAP plaintext password exposure can be limited to the PPP link by storing passwords as one-way transformed values; the SHOULD recommendation is to transform locally before comparison rather than sending plaintext further into the network.
Any implementation that includes a stronger authentication method such as CHAP MUST offer to negotiate that method prior to PAP.
Because CHAP Success might be lost, the authenticator MUST allow repeated Response packets after completing Authentication phase; responses with the current Challenge Identifier MUST return the same reply Code as when authentication completed. Response packets during any other phase MUST be silently discarded.
Because the Authenticate-Ack might be lost, the authenticator MUST allow repeated Authenticate-Request packets after completing the Authentication phase and MUST return the same reply Code as when authentication completed. Any Authenticate-Request packets received during any other phase MUST be silently discarded.
If the Peer-ID/Password pair is recognizable and acceptable, the authenticator MUST transmit an Authenticate-Ack (Code 2). If not, the authenticator MUST transmit an Authenticate-Nak (Code 3) and SHOULD take action to terminate the link.
The CHAP authenticator MUST transmit a Challenge packet (Code 1) and MUST send additional Challenges until a valid Response is received or a retry counter expires. Whenever a Challenge is received, the peer MUST respond with a Response packet (Code 2).
The CHAP Challenge Identifier MUST be changed each time a Challenge is sent. The Response Identifier MUST be copied from the Identifier field of the Challenge which caused the Response.
The CHAP Challenge Value MUST be changed each time a Challenge is sent. The Challenge Value SHOULD satisfy uniqueness and unpredictability criteria; each value SHOULD exhibit global and temporal uniqueness.
The CHAP secret MUST be at least 1 octet in length and SHOULD be at least as large and unguessable as a well-chosen password; preferably at least 16 octets (the MD5 hash length) to resist exhaustive search attacks.
The Identifier field in PAP Authenticate-Request MUST be changed each time an Authenticate-Request packet is issued.
The link peer MUST transmit a PAP Authenticate-Request packet during the Authentication phase and MUST repeat it until a valid reply is received or an optional retry counter expires.
The PAP/CHAP Message field MUST NOT affect operation of the protocol; it is intended to be human-readable and it is recommended to contain displayable ASCII characters 32 through 126 decimal.
Upon comparing the CHAP Response Value, the authenticator MUST send a Success packet (Code 3) if values match, or a Failure packet (Code 4) if they do not, and SHOULD terminate the link on failure.
The Challenge-Handshake Authentication Protocol (CHAP) uses a 3-way handshake with a one-way hash function to verify peer identity. The authenticator sends a Challenge; the peer responds with a hash of the Identifier, secret, and Challenge Value. CHAP MAY be repeated at any time after link establishment to ensure the connection has not been altered.
The Password Authentication Protocol (PAP) provides a simple 2-way handshake for peer identity establishment at initial link setup only. The peer repeatedly sends an Id/Password pair until authentication is acknowledged or the connection is terminated. Passwords are transmitted in cleartext with no replay protection.
The CHAP Algorithm field values are assigned via the IANA Assigned Numbers RFC. Current assignment: values 0–4 are reserved/unused; value 5 = MD5.
Authentication need not be full duplex; different protocols MAY be used in each direction. Failure counters should not be reset until after successful authentication or subsequent termination of the failed link.
Each named user should be associated with exactly one authentication method to prevent downgrade attacks. If a user requires different methods under different circumstances, distinct user names SHOULD be employed rather than permitting negotiation of the least-secure method.
PAP is not a strong authentication method: passwords are sent in cleartext with no protection against playback or repeated trial-and-error attacks, and the peer controls the frequency and timing of attempts.
Secrets should be stored with access limited to the process performing authentication, and distributed via mechanisms that minimize the number of entities with knowledge of the secret (e.g., SNMP Security Protocols).
CHAP packets carry a 1-octet Code (1=Challenge, 2=Response, 3=Success, 4=Failure), 1-octet Identifier, 2-octet Length, and variable Data field. Octets beyond the Length field are treated as Data Link Layer padding.
PAP packets carry a 1-octet Code (1=Authenticate-Request, 2=Authenticate-Ack, 3=Authenticate-Nak), 1-octet Identifier, 2-octet Length, and variable Data field. Octets beyond the Length field are treated as Data Link Layer padding.
The CHAP Challenge/Response Data field carries: Value-Size (1 octet), Value (variable; MD5 response is 16 octets), and Name (variable, no NUL/CRLF terminator). The Response Value is MD5(Identifier || secret || ChallengeValue).
The CHAP LCP Configuration Option has Type=3, Length=5, a 2-octet Authentication-Protocol field set to 0xc223, and a 1-octet Algorithm field (value 5 = MD5; values 0–4 reserved).
The CHAP Success/Failure packet carries Code (3 or 4), Identifier copied from the Response, Length, and a variable Message field that MUST NOT affect protocol operation.
The PAP Authenticate-Ack/Nak Data field carries Msg-Length (1 octet) and Message (variable octets). The Identifier is copied from the corresponding Authenticate-Request.
The PAP Authenticate-Request Data field carries: Peer-ID-Length (1 octet), Peer-ID (variable), Passwd-Length (1 octet), and Password (variable octets). Both length fields are required; either content field may be zero-length.
The PAP LCP Configuration Option has Type=3, Length=4, and a 2-octet Authentication-Protocol field set to 0xc023. There is no Data field.