PPP Challenge Handshake Authentication Protocol (CHAP)
obsoletes
- rfc-1334 — PPP Authentication Protocols
updated by
- rfc-2484 — PPP LCP Internationalization Configuration Option
Extracted elements (26)
CHAP provides protection against replay attacks through an incrementally changing Identifier and a variable Challenge Value. Repeated challenges limit the time of exposure to any single attack, with the authenticator controlling the frequency and timing.
CHAP requires the secret in plaintext form, meaning irreversibly encrypted password databases cannot be used. This is an inherent disadvantage that makes CHAP less suitable for large installations where every secret must be maintained at both ends.
The Name field is used as an index to locate the correct secret in a large table, enabling support for multiple name/secret pairs per system and allowing secrets to be changed at any time during the session.
To avoid sending secrets over other network links, it is recommended that challenge and response values be examined at a central server rather than at each network access server. If the secret must be forwarded to such a server, it SHOULD be sent in reversibly encrypted form.
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 of a PPP link, depending on what was negotiated.
Each challenge value SHOULD also be unpredictable, lest an attacker trick a peer into responding to a predicted future challenge and use that response to masquerade as the peer to an authenticator.
Each challenge value SHOULD be unique, since repetition of a challenge value with the same secret permits an attacker to replay a previously intercepted response. The challenge SHOULD exhibit global and temporal uniqueness.
If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase.
If the Response Value matches the expected value, the implementation MUST transmit a Success packet (Code=3). If it does not match, it MUST transmit a Failure packet (Code=4) and SHOULD take action to terminate the link.
The authenticator MUST allow repeated Response packets during the Network-Layer Protocol phase after completing Authentication, because a Success reply may have been lost in transit.
The authenticator MUST transmit a Challenge packet (Code=1) and MUST continue sending additional Challenge packets until a valid Response is received or an optional retry counter expires.
The Identifier field MUST be changed each time a Challenge is sent. The Challenge Value MUST also be changed each time a Challenge is sent.
The length of the secret MUST be at least 1 octet. The secret SHOULD be at least as large and unguessable as a well-chosen password, and is preferred to be at least the length of the hash value (16 octets for MD5) to protect against exhaustive search attacks.
The Message field in Success and Failure packets MUST NOT affect operation of the protocol; it is intended to be human readable only and its content is implementation dependent.
To prevent discovery of alternative Names and Secrets, any Response packet received bearing the current Challenge Identifier MUST return the same reply Code previously returned for that specific Challenge; only the Message portion MAY differ.
Whenever a Challenge packet is received, the peer MUST transmit a Response packet (Code=2). The Response Identifier MUST be copied from the Identifier field of the Challenge that triggered the Response.
CHAP uses a 3-way handshake: the authenticator sends a Challenge, the peer responds with a one-way hash computed over the Identifier, secret, and Challenge Value, and the authenticator verifies the hash and sends Success or Failure. After initial link establishment, CHAP MAY be repeated at any time to re-verify peer identity.
The Response Value is the one-way MD5 hash computed over the concatenation of: Identifier (1 octet), the shared secret, and the Challenge Value. The resulting Response Value is 16 octets for MD5.
For each user name there should be exactly one authentication method. Allowing multiple methods makes the user vulnerable to downgrade attacks (e.g., negotiating PAP instead of CHAP), and if the same secret is shared, PAP would reveal it for subsequent CHAP attacks. Distinct user names SHOULD be employed when different methods are required.
Secrets should be stored at each end with access as limited as possible, ideally accessible only to the process performing authentication. The distribution mechanism should minimize the number of entities that gain knowledge of the secret.
The secret SHOULD NOT be the same in both directions of a CHAP exchange. If the same secret is used bidirectionally, an attacker can replay the peer's Challenge, accept the computed Response, and use it to authenticate to the original authenticator.
After Link Establishment, the authenticator sends a Challenge; the peer responds with a Response; the authenticator evaluates and sends Success (advancing to Network-Layer Protocol phase) or Failure (link SHOULD be terminated). During Network-Layer phase, new Challenges MAY be issued at random intervals, restarting the handshake.
All CHAP packets share a common header: Code (1 octet identifying packet type — 1=Challenge, 2=Response, 3=Success, 4=Failure), Identifier (1 octet), and Length (2 octets, inclusive of the entire packet). Octets beyond the Length field are treated as Data Link Layer padding and ignored.
Challenge and Response packets extend the common header with: Value-Size (1 octet indicating length of the Value field), Value (variable — the challenge octet stream or the MD5 hash response), and Name (variable — system identification with no NUL or CR/LF termination).
Success and Failure packets extend the common header with only a Message field (zero or more octets of human-readable ASCII characters 32–126). The Identifier is copied from the triggering Response. Message size is determined from the Length field.
The LCP Authentication-Protocol Configuration Option for CHAP is 5 octets: Type (1 octet, value 3), Length (1 octet, value 5), Authentication-Protocol (2 octets, value 0xc223), and Algorithm (1 octet; value 5 = CHAP with MD5).