PPP Challenge Handshake Authentication Protocol (CHAP)
RFC 1994
Document | Type |
RFC - Draft Standard
(August 1996; No errata)
Updated by RFC 2484
Obsoletes RFC 1334
|
|
---|---|---|---|
Author | William Simpson | ||
Last updated | 2013-03-02 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1994 (Draft Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group W. Simpson Request for Comments: 1994 DayDreamer Obsoletes: 1334 August 1996 Category: Standards Track PPP Challenge Handshake Authentication Protocol (CHAP) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. Table of Contents 1. Introduction .......................................... 1 1.1 Specification of Requirements ................... 1 1.2 Terminology ..................................... 2 2. Challenge-Handshake Authentication Protocol ........... 2 2.1 Advantages ...................................... 3 2.2 Disadvantages ................................... 3 2.3 Design Requirements ............................. 4 3. Configuration Option Format ........................... 5 4. Packet Format ......................................... 6 4.1 Challenge and Response .......................... 7 4.2 Success and Failure ............................. 9 SECURITY CONSIDERATIONS ...................................... 10 ACKNOWLEDGEMENTS ............................................. 11 REFERENCES ................................................... 12 CONTACTS ..................................................... 12 Simpson [Page i] RFC 1994 PPP CHAP August 1996 1. Introduction 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) [1]. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. Simpson [Page 1] RFC 1994 PPP CHAP August 1996 1.2. Terminology This document frequently uses the following terms: authenticator The end of the link requiring the authentication. TheShow full document text