| |
| |
| |
| |
| |
| |
| 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. The |
| authenticator specifies the authentication protocol to be |
| used in the Configure-Request during Link Establishment |
| phase. |
| |
| peer The other end of the point-to-point link; the end which is |
| being authenticated by the authenticator. |
| |
| silently discard |
| This means the implementation discards 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. |
| |
| |
| |
| |
| 2. Challenge-Handshake Authentication Protocol |
| |
| The Challenge-Handshake Authentication Protocol (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. |
| |
| 1. After the Link Establishment phase is complete, the |
| authenticator sends a "challenge" message to the peer. |
| |
| 2. The peer responds with a value calculated using a "one-way |
| hash" function. |
| |
| 3. 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. |
| |
| 4. At random intervals, the authenticator sends a new challenge to |
| the peer, and repeats steps 1 to 3. |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 2] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| 2.1. Advantages |
| |
| 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. |
| |
| |
| 2.2. Disadvantages |
| |
| 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. |
| |
| Implementation Note: To avoid sending the secret over other links |
| in the network, it is recommended that the challenge and response |
| values be examined at a central server, rather than each network |
| access server. Otherwise, the secret SHOULD be sent to such |
| servers in a reversably encrypted form. Either case requires a |
| trusted relationship, which is outside the scope of this |
| specification. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 3] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| 2.3. Design Requirements |
| |
| The CHAP algorithm requires that 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. It is preferred that the |
| secret be at least the length of the hash value for the hashing |
| algorithm chosen (16 octets for MD5). This is to ensure a |
| sufficiently large range for the secret to provide protection against |
| exhaustive search attacks. |
| |
| The one-way hash algorithm is chosen such that it is computationally |
| infeasible to determine the secret from the known challenge and |
| response values. |
| |
| Each challenge value SHOULD be unique, since repetition of a |
| challenge value in conjunction with the same secret would permit an |
| attacker to reply with a previously intercepted response. Since it |
| is expected that the same secret MAY be used to authenticate with |
| servers in disparate geographic regions, the challenge SHOULD exhibit |
| global and temporal uniqueness. |
| |
| Each challenge value SHOULD also be unpredictable, least an attacker |
| trick a peer into responding to a predicted future challenge, and |
| then use the response to masquerade as that peer to an authenticator. |
| |
| Although protocols such as CHAP are incapable of protecting against |
| realtime active wiretapping attacks, generation of unique |
| unpredictable challenges can protect against a wide range of active |
| attacks. |
| |
| A discussion of sources of uniqueness and probability of divergence |
| is included in the Magic-Number Configuration Option [1]. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 4] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| 3. Configuration Option Format |
| |
| A summary of the Authentication-Protocol Configuration Option format |
| to negotiate the Challenge-Handshake Authentication Protocol is shown |
| below. The fields are transmitted from left to right. |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Type | Length | Authentication-Protocol | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Algorithm | |
| +-+-+-+-+-+-+-+-+ |
| |
| Type |
| |
| 3 |
| |
| Length |
| |
| 5 |
| |
| Authentication-Protocol |
| |
| c223 (hex) for Challenge-Handshake Authentication Protocol. |
| |
| Algorithm |
| |
| The Algorithm field is one octet and indicates the authentication |
| method to be used. Up-to-date values are specified in the most |
| recent "Assigned Numbers" [2]. One value is required to be |
| implemented: |
| |
| 5 CHAP with MD5 [3] |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 5] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| 4. Packet Format |
| |
| Exactly one Challenge-Handshake Authentication Protocol packet is |
| encapsulated in the Information field of a PPP Data Link Layer frame |
| where the protocol field indicates type hex c223 (Challenge-Handshake |
| Authentication Protocol). A summary of the CHAP packet format is |
| shown below. The fields are transmitted from left to right. |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Code | Identifier | Length | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Data ... |
| +-+-+-+-+ |
| |
| Code |
| |
| The Code field is one octet and identifies the type of CHAP |
| packet. CHAP Codes are assigned as follows: |
| |
| 1 Challenge |
| 2 Response |
| 3 Success |
| 4 Failure |
| |
| Identifier |
| |
| The Identifier field is one octet and aids in matching challenges, |
| responses and replies. |
| |
| Length |
| |
| The Length field is two octets and indicates the length of the |
| CHAP packet including the Code, Identifier, Length and Data |
| fields. Octets outside the range of the Length field should be |
| treated as Data Link Layer padding and should be ignored on |
| reception. |
| |
| Data |
| |
| The Data field is zero or more octets. The format of the Data |
| field is determined by the Code field. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 6] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| 4.1. Challenge and Response |
| |
| Description |
| |
| 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 (described below). |
| |
| Implementation Notes: Because the Success might be lost, the |
| authenticator MUST allow repeated Response packets during the |
| Network-Layer Protocol phase after completing the |
| Authentication phase. To prevent discovery of alternative |
| Names and Secrets, any Response packets received having the |
| current Challenge Identifier MUST return the same reply Code |
| previously returned for that specific Challenge (the message |
| portion MAY be different). Any Response packets received |
| during any other phase MUST be silently discarded. |
| |
| When the Failure is lost, and the authenticator terminates the |
| link, the LCP Terminate-Request and Terminate-Ack provide an |
| alternative indication that authentication failed. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 7] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| A summary of the Challenge and Response packet format is shown below. |
| The fields are transmitted from left to right. |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Code | Identifier | Length | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Value-Size | Value ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Name ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Code |
| |
| 1 for Challenge; |
| |
| 2 for Response. |
| |
| Identifier |
| |
| The Identifier field is one octet. The Identifier field 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. |
| |
| Value-Size |
| |
| This field is one octet and indicates the length of the Value |
| field. |
| |
| Value |
| |
| The Value field is one or more octets. The most significant octet |
| is transmitted first. |
| |
| The Challenge Value is a variable stream of octets. The |
| importance of the uniqueness of the Challenge Value and its |
| relationship to the secret is described above. The Challenge |
| Value MUST be changed each time a Challenge is sent. The length |
| of the Challenge Value depends upon the method used to generate |
| the octets, and is independent of the hash algorithm used. |
| |
| The Response Value is the one-way hash calculated over a stream of |
| octets consisting of the Identifier, followed by (concatenated |
| with) the "secret", followed by (concatenated with) the Challenge |
| Value. The length of the Response Value depends upon the hash |
| algorithm used (16 octets for MD5). |
| |
| |
| |
| |
| Simpson [Page 8] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| Name |
| |
| The Name field is one or more octets representing the |
| identification of the system transmitting the packet. There are |
| no limitations on the content of this field. For example, it MAY |
| contain ASCII character strings or globally unique identifiers in |
| ASN.1 syntax. The Name should not be NUL or CR/LF terminated. |
| The size is determined from the Length field. |
| |
| |
| 4.2. Success and Failure |
| |
| Description |
| |
| If the Value received in a Response is equal to the expected |
| value, then the implementation MUST transmit a CHAP packet with |
| the Code field set to 3 (Success). |
| |
| If the Value received in a Response is not equal to the expected |
| value, then the implementation MUST transmit a CHAP packet with |
| the Code field set to 4 (Failure), and SHOULD take action to |
| terminate the link. |
| |
| A summary of the Success and Failure packet format is shown below. |
| The fields are transmitted from left to right. |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Code | Identifier | Length | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Message ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+- |
| |
| Code |
| |
| 3 for Success; |
| |
| 4 for Failure. |
| |
| Identifier |
| |
| The Identifier field is one octet and aids in matching requests |
| and replies. The Identifier field MUST be copied from the |
| Identifier field of the Response which caused this reply. |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 9] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| Message |
| |
| The Message field is zero or more octets, and its contents are |
| implementation dependent. It is intended to be human readable, |
| and MUST NOT affect operation of the protocol. It is recommended |
| that the message contain displayable ASCII characters 32 through |
| 126 decimal. Mechanisms for extension to other character sets are |
| the topic of future research. The size is determined from the |
| Length field. |
| |
| |
| |
| Security Considerations |
| |
| Security issues are the primary topic of this RFC. |
| |
| The interaction of the authentication protocols within PPP are highly |
| implementation dependent. This is indicated by the use of SHOULD |
| throughout the document. |
| |
| For example, upon failure of authentication, some implementations do |
| not terminate the link. Instead, the implementation limits the kind |
| of traffic in the Network-Layer Protocols to a filtered subset, which |
| in turn allows the user opportunity to update secrets or send mail to |
| the network administrator indicating a problem. |
| |
| There is no provision for re-tries of failed authentication. |
| However, the LCP state machine can renegotiate the authentication |
| protocol at any time, thus allowing a new attempt. It is recommended |
| that any counters used for authentication failure not be reset until |
| after successful authentication, or subsequent termination of the |
| failed link. |
| |
| There is no requirement that authentication be full duplex or that |
| the same protocol be used in both directions. It is perfectly |
| acceptable for different protocols to be used in each direction. |
| This will, of course, depend on the specific protocols negotiated. |
| |
| The secret SHOULD NOT be the same in both directions. This allows an |
| attacker to replay the peer's challenge, accept the computed |
| response, and use that response to authenticate. |
| |
| In practice, within or associated with each PPP server, there is a |
| database which associates "user" names with authentication |
| information ("secrets"). It is not anticipated that a particular |
| named user would be authenticated by multiple methods. This would |
| make the user vulnerable to attacks which negotiate the least secure |
| method from among a set (such as PAP rather than CHAP). If the same |
| |
| |
| |
| Simpson [Page 10] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| secret was used, PAP would reveal the secret to be used later with |
| CHAP. |
| |
| Instead, for each user name there should be an indication of exactly |
| one method used to authenticate that user name. If a user needs to |
| make use of different authentication methods under different |
| circumstances, then distinct user names SHOULD be employed, each of |
| which identifies exactly one authentication method. |
| |
| Passwords and other secrets should be stored at the respective ends |
| such that access to them is as limited as possible. Ideally, the |
| secrets should only be accessible to the process requiring access in |
| order to perform the authentication. |
| |
| The secrets should be distributed with a mechanism that limits the |
| number of entities that handle (and thus gain knowledge of) the |
| secret. Ideally, no unauthorized person should ever gain knowledge |
| of the secrets. Such a mechanism is outside the scope of this |
| specification. |
| |
| |
| Acknowledgements |
| |
| David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge |
| handshake at SDC when designing one of the protocols for a "secure" |
| network in the mid-1970s. Tom Bearson built a prototype Sytek |
| product ("Poloneous"?) on the challenge-response notion in the 1982- |
| 83 timeframe. Another variant is documented in the various IBM SNA |
| manuals. Yet another variant was implemented by Karl Auerbach in the |
| Telebit NetBlazer circa 1991. |
| |
| Kim Toms and Barney Wolff provided useful critiques of earlier |
| versions of this document. |
| |
| Special thanks to Dave Balenson, Steve Crocker, James Galvin, and |
| Steve Kent, for their extensive explanations and suggestions. Now, |
| if only we could get them to agree with each other. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 11] |
| |
| RFC 1994 PPP CHAP August 1996 |
| |
| |
| References |
| |
| [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD |
| 51, RFC 1661, DayDreamer, July 1994. |
| |
| [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC |
| 1700, USC/Information Sciences Institute, October 1994. |
| |
| [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", |
| MIT Laboratory for Computer Science and RSA Data Security, |
| Inc., RFC 1321, April 1992. |
| |
| |
| |
| Contacts |
| |
| Comments should be submitted to the ietf-ppp@merit.edu mailing list. |
| |
| This document was reviewed by the Point-to-Point Protocol Working |
| Group of the Internet Engineering Task Force (IETF). The working |
| group can be contacted via the current chair: |
| |
| Karl Fox |
| Ascend Communications |
| 3518 Riverside Drive, Suite 101 |
| Columbus, Ohio 43221 |
| |
| karl@MorningStar.com |
| karl@Ascend.com |
| |
| |
| Questions about this memo can also be directed to: |
| |
| William Allen Simpson |
| DayDreamer |
| Computer Systems Consulting Services |
| 1384 Fontaine |
| Madison Heights, Michigan 48071 |
| |
| wsimpson@UMich.edu |
| wsimpson@GreenDragon.com (preferred) |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Simpson [Page 12] |
| |
| |
