RFC 1994

PPP Challenge Handshake Authentication Protocol (CHAP) 💖

okay bestie, so this is RFC 1994 ✨ It's by W. Simpson from DayDreamer, dated August 1996, and it's a Standards Track doc 📜 It obsoletes RFC 1334, so 1334 is officially retired and this one is the new it-girl 👑

Status of This Memo 📜

this doc specifies an Internet standards track protocol for the Internet community, and it's basically asking for discussion and suggestions for improvements 🫶 for the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share away 💅

Abstract ✨

okay so the Point-to-Point Protocol (PPP) [1] gives us a standard way to carry multi-protocol datagrams over point-to-point links 🦋

PPP also has an extensible Link Control Protocol. it lets the two ends negotiate an Authentication Protocol, so one end can authenticate its peer before any Network Layer protocols are allowed to transmit over the link 🔐

this document defines a PPP authentication method that uses a random Challenge and a cryptographically hashed Response. the Response depends on both the Challenge and a secret key, so it's giving security 🔥

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

1. Introduction ✨

okay so before two ends can talk over a point-to-point link, each end has to send LCP packets to configure the data link during the Link Establishment phase 🧚 once the link is up, PPP gives you an optional Authentication phase before it moves on to the Network-Layer Protocol phase 💜

by default, authentication is not mandatory 🙈 but if you want the link authenticated, an implementation MUST specify the Authentication-Protocol Configuration Option during the Link Establishment phase. no skipping this one, bestie 💀

these authentication protocols are mainly meant for hosts and routers that dial into a PPP network server over switched circuits or dial-up lines. they could also be used on dedicated links 🌈 the server can use the identity of whoever is connecting to pick its network layer negotiation options, which is so smart 🧠

this document defines one PPP authentication protocol. the Link Establishment and Authentication phases, plus the Authentication-Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [1] 📖

1.1. Specification of Requirements

in this doc, a few words are used to signal the requirements of the spec. they're often capitalized, so look for them 👀

• MUST: this word, or the adjective "required", means the definition is an absolute requirement of the specification 💅
• MUST NOT: this phrase means the definition is an absolute prohibition of the specification 🚫
• SHOULD: this word, or the adjective "recommended", means there may be valid reasons in particular circumstances to ignore this item. but the full implications have to be understood and carefully weighed before picking a different course 🤔
• MAY: this word, or the adjective "optional", means this item is one of an allowed set of alternatives. an implementation that doesn't include this option MUST be prepared to interoperate with another implementation that does include it 🦋

1.2. Terminology

this doc keeps coming back to these terms 🎀

• authenticator: the end of the link that requires the authentication. it names the authentication protocol to use in the Configure-Request during the Link Establishment phase 👑
• peer: the other end of the point-to-point link, the one being authenticated by the authenticator 💖
• silently discard: the implementation drops the packet without any further processing. it SHOULD be able to log the error (including the contents of the silently discarded packet) and SHOULD record the event in a statistics counter 📊

2. Challenge-Handshake Authentication Protocol 🌈

okay so the Challenge-Handshake Authentication Protocol (CHAP) checks the peer's identity periodically using a 3-way handshake 🤝 it happens when the link is first established, and it MAY be repeated any time after that 🔁

1. once the Link Establishment phase is done, the authenticator sends a "challenge" message to the peer 📣
2. the peer answers with a value calculated with a "one-way hash" function 🔐
3. the authenticator checks that response against its own calculation of the expected hash value. if they match, the authentication is acknowledged. if not, the connection SHOULD be terminated 💀
4. at random intervals, the authenticator sends a new challenge to the peer and repeats steps 1 to 3 🎲

2.1. Advantages

CHAP protects against a playback attack by the peer, using an incrementally changing identifier and a variable challenge value 🛡️ repeated challenges limit how long any single attack has to work, and the authenticator is the one in control of how often and when the challenges happen ✨

this method depends on a "secret" that only the authenticator and the peer know 🤫 the secret is never sent over the link 🙅‍♀️

the authentication is only one-way, but if you negotiate CHAP in both directions, the same secret set can easily be used for mutual authentication 🫶

since CHAP can authenticate lots of different systems, name fields can act as an index to find the right secret in a big table of secrets. this also means you can have more than one name/secret pair per system, and change the secret in use at any time during the session 🔑

2.2. Disadvantages

CHAP requires the secret to be available in plaintext form, so irreversably encrypted password databases that are commonly around can't be used 😭

it isn't as useful for large installations, since every possible secret has to be 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 at 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. 🔒

2.3. Design Requirements

the CHAP algorithm requires that the secret MUST be at least 1 octet long. the secret SHOULD be at least as large and as unguessable as a well-chosen password 🔑 it's preferred that the secret be at least the length of the hash value for the chosen hashing algorithm (16 octets for MD5). that makes sure there's a big enough range for the secret to protect against exhaustive search attacks 💪

the one-way hash algorithm is chosen so that it's computationally infeasible to work out the secret from the known challenge and response values 🧮

each challenge value SHOULD be unique. repeating a challenge value with the same secret would let an attacker reply with a previously intercepted response, and that's a big nope 🙅‍♀️ the same secret MAY be used to authenticate with servers in very different geographic regions, so the challenge SHOULD be globally and temporally unique 🌍

each challenge value SHOULD also be unpredictable. otherwise an attacker could trick a peer into responding to a predicted future challenge, then use that response to masquerade as the peer to an authenticator 🎭

protocols like CHAP can't protect against realtime active wiretapping attacks. but generating unique, unpredictable challenges protects against a wide range of active attacks 🛡️

there's a discussion of sources of uniqueness and the probability of divergence in the Magic-Number Configuration Option [1] 📖

3. Configuration Option Format 🎀

here's a summary of the Authentication-Protocol Configuration Option format used to negotiate the Challenge-Handshake Authentication Protocol. the fields go from left to right 👉

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Authentication-Protocol   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm   |
+-+-+-+-+-+-+-+-+

• Type: 3
• Length: 5
• Authentication-Protocol: c223 (hex) for Challenge-Handshake Authentication Protocol 🧚
• Algorithm: a one-octet field that says which authentication method to use. up-to-date values are in the most recent "Assigned Numbers" [2]. one value is required to be implemented:

   5       CHAP with MD5 [3]

4. Packet Format 💅

okay so exactly one Challenge-Handshake Authentication Protocol packet is encapsulated in the Information field of a PPP Data Link Layer frame, where the protocol field says type hex c223 (Challenge-Handshake Authentication Protocol) ✨ here's the CHAP packet format, read left to right 👀

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+

• Code: one octet that identifies the type of CHAP packet. the codes are:

   1       Challenge
   2       Response
   3       Success
   4       Failure

• Identifier: one octet that helps match challenges, responses and replies together 🧩
• Length: two octets that show 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: zero or more octets. the format of the Data field is determined by the Code field 💜

4.1. Challenge and Response ✨

Description 🎀

Okay so the Challenge packet is how the whole CHAP handshake gets kicked off 🦋. The authenticator MUST transmit a CHAP packet with the Code field set to 1 (Challenge). And it doesn't stop at one! 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, just to make sure the connection hasn't been messed with 👀.

The peer SHOULD expect Challenge packets during the Authentication phase and the Network-Layer Protocol phase 🌸. Whenever a Challenge packet shows up, the peer MUST transmit a CHAP packet with the Code field set to 2 (Response) 💖.

Whenever a Response packet arrives, the authenticator compares the Response Value with its own calculation of the expected value. Based on that comparison, the authenticator MUST send a Success or Failure packet (more on those in a sec) ✨.

Implementation Notes 🧠

Because the Success might get lost, the authenticator MUST allow repeated Response packets during the Network-Layer Protocol phase after it finishes the Authentication phase. 🔁

To stop anyone from sniffing out alternative Names and Secrets, any Response packets that have 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 give you an alternative way to tell that authentication failed 💀.

Here's the summary of the Challenge and Response packet format. The fields go 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. It MUST be changed each time a Challenge is sent 🔄.

The Response Identifier MUST be copied from the Identifier field of the Challenge that caused the Response. It's giving matching energy 💜.

Value-Size 📏

This field is one octet and tells you the length of the Value field.

Value 💎

The Value field is one or more octets, and 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 how it connects to the secret is described above ✨. The Challenge Value MUST be changed each time a Challenge is sent. Its length depends on the method used to generate the octets, and it's independent of the hash algorithm used 🌈.

The Response Value is the one-way hash calculated over a stream of octets made of the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value 🔐. Its length depends on the hash algorithm used (16 octets for MD5) 💅.

Name 🪞

The Name field is one or more octets that represent the identification of the system transmitting the packet. There are no limitations on the content of this field, so it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. Iconic flexibility 👑.

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, the implementation MUST transmit a CHAP packet with the Code field set to 3 (Success). Bestie, we did it 🎊.

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. Not me being sad about this 😭.

Here's the summary of the Success and Failure packet format. Again, fields go left to right 🌸.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

Code 🏁

• 3 for Success;
• 4 for Failure.

Identifier 🆔

The Identifier field is one octet and helps match requests and replies. The Identifier field MUST be copied from the Identifier field of the Response that caused this reply 🫶.

Message 💬

The Message field is zero or more octets, and what's in it is implementation dependent. It's intended to be human readable, and it MUST NOT affect operation of the protocol. So it's just vibes for the humans 🙃.

It is recommended that the message contain displayable ASCII characters 32 through 126 decimal. Extending to other character sets is the topic of future research 🔬. The size is determined from the Length field 📏.

---

Security Considerations 🔒

Okay, this part is seriously important 🚨. Security issues are the primary topic of this RFC, so pay attention, bestie 💀.

The interaction of the authentication protocols within PPP is highly implementation dependent. This is indicated by the use of SHOULD throughout the document 🫠.

For example, upon failure of authentication, some implementations don't terminate the link. Instead, they limit the kind of traffic in the Network-Layer Protocols to a filtered subset. That gives the user a chance to update secrets or send mail to the network administrator to flag 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, which allows 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 🦋. Of course, this depends on which specific protocols get negotiated 🤷‍♀️.

🚨 The secret SHOULD NOT be the same in both directions. If it were, an attacker could replay the peer's challenge, accept the computed response, and use that response to authenticate. Big no-no, periodt 🙅‍♀️.

In practice, within or associated with each PPP server, there's a database that links "user" names with authentication information ("secrets"). It's not anticipated that a particular named user would be authenticated by multiple methods 🗂️. That would leave the user open to attacks that negotiate the least secure method from among a set (such as PAP rather than CHAP). If the same secret were 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 use different authentication methods under different circumstances, then distinct user names SHOULD be employed, and each one should identify exactly one authentication method 🪪✨.

Passwords and other secrets should be stored at the respective ends so that access to them is as limited as possible. Ideally, the secrets should only be accessible to the process that needs them to perform the authentication 🔑.

The secrets should be distributed with a mechanism that limits the number of entities that handle (and therefore 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 😂💅.

---

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)