Summary

  • RFC 1994 replaced transmission of a reusable password with an authenticator-led challenge and a response calculated from the Identifier, shared secret and changing Challenge Value.
  • Success recorded a local equality test for that exchange. Mutual authentication required a separate negotiation in the other direction, while authorization, NCP state and delivered traffic remained outside the result.

In August 1996, RFC 1994 isolated CHAP from the earlier combined PPP authentication specification. Its exchange began only after PPP had established the data link and negotiated an authentication protocol. The authenticator sent Code 1, Challenge. The peer returned Code 2, Response. The authenticator calculated what it expected and sent Code 3, Success, or Code 4, Failure.

The response was not a password sent through the link. Its value was the one-way hash of three concatenated inputs: the Challenge Identifier, the secret known at both ends, and the Challenge Value. The Response copied the Challenge Identifier; Success or Failure copied the Response Identifier. The Challenge Value and Identifier had to change for each new challenge. These rules made a captured response answer a particular question rather than become a standing credential.

That protection depended on the question being genuinely new. RFC 1994 recommended challenge values that were unique and unpredictable. Reusing a challenge with the same secret could make an intercepted response reusable. Predictability could let an attacker obtain an answer to a future question in advance. The RFC nevertheless did not promise protection against real-time active wiretapping.

The authenticator owned the clock. It could challenge after link establishment and again at random intervals, including during the Network-Layer Protocol phase. Repeated challenges reduced the period during which one successful attack could remain useful. They did not turn the first Success into a continuous attestation: each later challenge created a new comparison with its own Identifier and value.

Direction was equally strict. The RFC states that CHAP authentication is one-way. Negotiating CHAP in both directions could provide mutual authentication, but those were two acts. PPP did not require full-duplex authentication or even the same protocol in both directions, and the RFC advised against using the same secret both ways.

Success therefore had a precise evidentiary meaning. The authenticator received a Response Value equal to its expected value for that challenge. It did not independently identify a natural person, prove an account entitlement, show how the secret was stored, guarantee continuing custody, encrypt the link, or validate the human-readable Message field. That Message was explicitly forbidden from affecting protocol operation.

Loss also exposed the boundary. If Success disappeared, the peer could repeat the same Response. The authenticator had to return the same reply Code previously used for that current Challenge Identifier. Delivery repair was not a new authentication decision.

RFC 1661 kept the next receipts separate. After authentication, every network-layer protocol still required its own NCP, and only an Opened NCP could carry its packets. A CHAP Success did not prove an IP address, route, packet arrival or application result.

Sources: RFC 1994; RFC Editor record; RFC 1661; RFC 1334; IANA PPP numbers.