CHAP, Challenge Handshake Authentication Protocol

Protocol suite:	PPP.
Protocol type:	PPP link control protocol, authentication.
PPP protocol:	0xC223.
SNMP MIBs:
Working groups:	pppext, Point-to-Point Protocol Extensions.
Links:	PPP Assigned numbers.

CHAP is used to periodically verify the identity of the peer using a 3-way handshake. This is done upon initial link establishment, and MAY be repeated anytime after the link has been established.

After the Link Establishment phase is complete, the authenticator sends a "challenge" message to the peer.
The peer responds with a value calculated using a "one-way hash" function.
The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged; otherwise the connection SHOULD be terminated.
At random intervals, the authenticator sends a new challenge to the peer, and repeats steps 1 to 3.

RFC 1994, pages 1 - 3, and 7:

In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase.

By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase.

These authentication protocols are intended for use primarily by hosts and routers that connect to a PPP network server via switched circuits or dial-up lines, but might be applied to dedicated links as well. The server can use the identification of the connecting host or router in the selection of options for network layer negotiations.

This document defines a PPP authentication protocol. The Link Establishment and Authentication phases, and the Authentication Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP).

CHAP provides protection against playback attack by the peer through the use of an incrementally changing identifier and a variable challenge value. The use of repeated challenges is intended to limit the time of exposure to any single attack. The authenticator is in control of the frequency and timing of the challenges. This authentication method depends upon a "secret" known only to the authenticator and that peer. The secret is not sent over the link. Although the authentication is only one-way, by negotiating CHAP in both directions the same secret set may easily be used for mutual authentication. Since CHAP may be used to authenticate many different systems, name fields may be used as an index to locate the proper secret in a large table of secrets. This also makes it possible to support more than one name/secret pair per system, and to change the secret in use at any time during the session.

CHAP requires that the secret be available in plaintext form. Irreversably encrypted password databases commonly available cannot be used. It is not as useful for large installations, since every possible secret is maintained at both ends of the link.

The Challenge packet is used to begin the Challenge-Handshake Authentication Protocol. The authenticator MUST transmit a CHAP packet with the Code field set to 1 (Challenge). Additional Challenge packets MUST be sent until a valid Response packet is received, or an optional retry counter expires.

A Challenge packet MAY also be transmitted at any time during the Network-Layer Protocol phase to ensure that the connection has not been altered.

The peer SHOULD expect Challenge packets during the Authentication phase and the Network-Layer Protocol phase.

Whenever a Challenge packet is received, the peer MUST transmit a CHAP packet with the Code field set to 2 (Response). Whenever a Response packet is received, the authenticator compares the Response Value with its own calculation of the expected value. Based on this comparison, the authenticator MUST send a Success or Failure packet.

PPP header

CHAP header

Data :::

CHAP header:

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Code								Identifier								Length
Data :::

Code. 8 bits.
Specifies the function to be performed.

Code	Description	References
1	Challenge.	RFC 1994
2	Response.	RFC 1994
3	Success.	RFC 1994
4	Failure.	RFC 1994

Identifier. 8 bits.
Used to match challenges, responses and replies.

Length. 16 bits.
Size of the CHAP packet including the Code, Identifier, Length and Data fields. Bytes outside of this range should be treated as Data Link Layer padding and should be ignored on reception.

Data. Variable length.
Zero or more bytes of data as indicated by the Length.

Glossary:

Authenticator.
(RFC 1994) The end of the link requiring the authentication. The authenticator specifies the authentication protocol to be used in the Configure-Request during the Link Establishment phase.

Peer.
(RFC 1994) The other end of the point-to-point link; the end which is being authenticated by the authenticator.

Silently discard.
The implementation SHOULD discard the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.

RFCs:

[RFC 1994] PPP Challenge Handshake Authentication Protocol (CHAP).

Obsoletes: RFC 1334.

Publications:

Obsolete RFCs:

[RFC 1334] PPP Authentication Protocols.

Obsoleted by: RFC 1994.