diff options
Diffstat (limited to 'rfc/rfc1994.txt')
| -rw-r--r-- | rfc/rfc1994.txt | 732 |
1 files changed, 732 insertions, 0 deletions
diff --git a/rfc/rfc1994.txt b/rfc/rfc1994.txt new file mode 100644 index 0000000..e4a553e --- /dev/null +++ b/rfc/rfc1994.txt @@ -0,0 +1,732 @@ + + + + + + +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] + + |