7
Network Working Group W. Simpson
8
Request for Comments: 1994 DayDreamer
9
Obsoletes: 1334 August 1996
10
Category: Standards Track
13
PPP Challenge Handshake Authentication Protocol (CHAP)
18
This document specifies an Internet standards track protocol for the
19
Internet community, and requests discussion and suggestions for
20
improvements. Please refer to the current edition of the "Internet
21
Official Protocol Standards" (STD 1) for the standardization state
22
and status of this protocol. Distribution of this memo is unlimited.
26
The Point-to-Point Protocol (PPP) [1] provides a standard method for
27
transporting multi-protocol datagrams over point-to-point links.
29
PPP also defines an extensible Link Control Protocol, which allows
30
negotiation of an Authentication Protocol for authenticating its peer
31
before allowing Network Layer protocols to transmit over the link.
33
This document defines a method for Authentication using PPP, which
34
uses a random Challenge, with a cryptographically hashed Response
35
which depends upon the Challenge and a secret key.
39
1. Introduction .......................................... 1
40
1.1 Specification of Requirements ................... 1
41
1.2 Terminology ..................................... 2
42
2. Challenge-Handshake Authentication Protocol ........... 2
43
2.1 Advantages ...................................... 3
44
2.2 Disadvantages ................................... 3
45
2.3 Design Requirements ............................. 4
46
3. Configuration Option Format ........................... 5
47
4. Packet Format ......................................... 6
48
4.1 Challenge and Response .......................... 7
49
4.2 Success and Failure ............................. 9
50
SECURITY CONSIDERATIONS ...................................... 10
51
ACKNOWLEDGEMENTS ............................................. 11
52
REFERENCES ................................................... 12
53
CONTACTS ..................................................... 12
60
RFC 1994 PPP CHAP August 1996
65
In order to establish communications over a point-to-point link, each
66
end of the PPP link must first send LCP packets to configure the data
67
link during Link Establishment phase. After the link has been
68
established, PPP provides for an optional Authentication phase before
69
proceeding to the Network-Layer Protocol phase.
71
By default, authentication is not mandatory. If authentication of
72
the link is desired, an implementation MUST specify the
73
Authentication-Protocol Configuration Option during Link
76
These authentication protocols are intended for use primarily by
77
hosts and routers that connect to a PPP network server via switched
78
circuits or dial-up lines, but might be applied to dedicated links as
79
well. The server can use the identification of the connecting host
80
or router in the selection of options for network layer negotiations.
82
This document defines a PPP authentication protocol. The Link
83
Establishment and Authentication phases, and the Authentication-
84
Protocol Configuration Option, are defined in The Point-to-Point
88
1.1. Specification of Requirements
90
In this document, several words are used to signify the requirements
91
of the specification. These words are often capitalized.
93
MUST This word, or the adjective "required", means that the
94
definition is an absolute requirement of the specification.
96
MUST NOT This phrase means that the definition is an absolute
97
prohibition of the specification.
99
SHOULD This word, or the adjective "recommended", means that there
100
may exist valid reasons in particular circumstances to
101
ignore this item, but the full implications must be
102
understood and carefully weighed before choosing a
105
MAY This word, or the adjective "optional", means that this
106
item is one of an allowed set of alternatives. An
107
implementation which does not include this option MUST be
108
prepared to interoperate with another implementation which
109
does include the option.
116
RFC 1994 PPP CHAP August 1996
121
This document frequently uses the following terms:
124
The end of the link requiring the authentication. The
125
authenticator specifies the authentication protocol to be
126
used in the Configure-Request during Link Establishment
129
peer The other end of the point-to-point link; the end which is
130
being authenticated by the authenticator.
133
This means the implementation discards the packet without
134
further processing. The implementation SHOULD provide the
135
capability of logging the error, including the contents of
136
the silently discarded packet, and SHOULD record the event
137
in a statistics counter.
142
2. Challenge-Handshake Authentication Protocol
144
The Challenge-Handshake Authentication Protocol (CHAP) is used to
145
periodically verify the identity of the peer using a 3-way handshake.
146
This is done upon initial link establishment, and MAY be repeated
147
anytime after the link has been established.
149
1. After the Link Establishment phase is complete, the
150
authenticator sends a "challenge" message to the peer.
152
2. The peer responds with a value calculated using a "one-way
155
3. The authenticator checks the response against its own
156
calculation of the expected hash value. If the values match,
157
the authentication is acknowledged; otherwise the connection
158
SHOULD be terminated.
160
4. At random intervals, the authenticator sends a new challenge to
161
the peer, and repeats steps 1 to 3.
172
RFC 1994 PPP CHAP August 1996
177
CHAP provides protection against playback attack by the peer through
178
the use of an incrementally changing identifier and a variable
179
challenge value. The use of repeated challenges is intended to limit
180
the time of exposure to any single attack. The authenticator is in
181
control of the frequency and timing of the challenges.
183
This authentication method depends upon a "secret" known only to the
184
authenticator and that peer. The secret is not sent over the link.
186
Although the authentication is only one-way, by negotiating CHAP in
187
both directions the same secret set may easily be used for mutual
190
Since CHAP may be used to authenticate many different systems, name
191
fields may be used as an index to locate the proper secret in a large
192
table of secrets. This also makes it possible to support more than
193
one name/secret pair per system, and to change the secret in use at
194
any time during the session.
199
CHAP requires that the secret be available in plaintext form.
200
Irreversably encrypted password databases commonly available cannot
203
It is not as useful for large installations, since every possible
204
secret is maintained at both ends of the link.
206
Implementation Note: To avoid sending the secret over other links
207
in the network, it is recommended that the challenge and response
208
values be examined at a central server, rather than each network
209
access server. Otherwise, the secret SHOULD be sent to such
210
servers in a reversably encrypted form. Either case requires a
211
trusted relationship, which is outside the scope of this
228
RFC 1994 PPP CHAP August 1996
231
2.3. Design Requirements
233
The CHAP algorithm requires that the length of the secret MUST be at
234
least 1 octet. The secret SHOULD be at least as large and
235
unguessable as a well-chosen password. It is preferred that the
236
secret be at least the length of the hash value for the hashing
237
algorithm chosen (16 octets for MD5). This is to ensure a
238
sufficiently large range for the secret to provide protection against
239
exhaustive search attacks.
241
The one-way hash algorithm is chosen such that it is computationally
242
infeasible to determine the secret from the known challenge and
245
Each challenge value SHOULD be unique, since repetition of a
246
challenge value in conjunction with the same secret would permit an
247
attacker to reply with a previously intercepted response. Since it
248
is expected that the same secret MAY be used to authenticate with
249
servers in disparate geographic regions, the challenge SHOULD exhibit
250
global and temporal uniqueness.
252
Each challenge value SHOULD also be unpredictable, least an attacker
253
trick a peer into responding to a predicted future challenge, and
254
then use the response to masquerade as that peer to an authenticator.
256
Although protocols such as CHAP are incapable of protecting against
257
realtime active wiretapping attacks, generation of unique
258
unpredictable challenges can protect against a wide range of active
261
A discussion of sources of uniqueness and probability of divergence
262
is included in the Magic-Number Configuration Option [1].
284
RFC 1994 PPP CHAP August 1996
287
3. Configuration Option Format
289
A summary of the Authentication-Protocol Configuration Option format
290
to negotiate the Challenge-Handshake Authentication Protocol is shown
291
below. The fields are transmitted from left to right.
293
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
294
| Type | Length | Authentication-Protocol |
295
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
307
Authentication-Protocol
309
c223 (hex) for Challenge-Handshake Authentication Protocol.
313
The Algorithm field is one octet and indicates the authentication
314
method to be used. Up-to-date values are specified in the most
315
recent "Assigned Numbers" [2]. One value is required to be
340
RFC 1994 PPP CHAP August 1996
345
Exactly one Challenge-Handshake Authentication Protocol packet is
346
encapsulated in the Information field of a PPP Data Link Layer frame
347
where the protocol field indicates type hex c223 (Challenge-Handshake
348
Authentication Protocol). A summary of the CHAP packet format is
349
shown below. The fields are transmitted from left to right.
351
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
352
| Code | Identifier | Length |
353
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
359
The Code field is one octet and identifies the type of CHAP
360
packet. CHAP Codes are assigned as follows:
369
The Identifier field is one octet and aids in matching challenges,
370
responses and replies.
374
The Length field is two octets and indicates the length of the
375
CHAP packet including the Code, Identifier, Length and Data
376
fields. Octets outside the range of the Length field should be
377
treated as Data Link Layer padding and should be ignored on
382
The Data field is zero or more octets. The format of the Data
383
field is determined by the Code field.
396
RFC 1994 PPP CHAP August 1996
399
4.1. Challenge and Response
403
The Challenge packet is used to begin the Challenge-Handshake
404
Authentication Protocol. The authenticator MUST transmit a CHAP
405
packet with the Code field set to 1 (Challenge). Additional
406
Challenge packets MUST be sent until a valid Response packet is
407
received, or an optional retry counter expires.
409
A Challenge packet MAY also be transmitted at any time during the
410
Network-Layer Protocol phase to ensure that the connection has not
413
The peer SHOULD expect Challenge packets during the Authentication
414
phase and the Network-Layer Protocol phase. Whenever a Challenge
415
packet is received, the peer MUST transmit a CHAP packet with the
416
Code field set to 2 (Response).
418
Whenever a Response packet is received, the authenticator compares
419
the Response Value with its own calculation of the expected value.
420
Based on this comparison, the authenticator MUST send a Success or
421
Failure packet (described below).
423
Implementation Notes: Because the Success might be lost, the
424
authenticator MUST allow repeated Response packets during the
425
Network-Layer Protocol phase after completing the
426
Authentication phase. To prevent discovery of alternative
427
Names and Secrets, any Response packets received having the
428
current Challenge Identifier MUST return the same reply Code
429
previously returned for that specific Challenge (the message
430
portion MAY be different). Any Response packets received
431
during any other phase MUST be silently discarded.
433
When the Failure is lost, and the authenticator terminates the
434
link, the LCP Terminate-Request and Terminate-Ack provide an
435
alternative indication that authentication failed.
452
RFC 1994 PPP CHAP August 1996
455
A summary of the Challenge and Response packet format is shown below.
456
The fields are transmitted from left to right.
458
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459
| Code | Identifier | Length |
460
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
461
| Value-Size | Value ...
462
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
464
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
474
The Identifier field is one octet. The Identifier field MUST be
475
changed each time a Challenge is sent.
477
The Response Identifier MUST be copied from the Identifier field
478
of the Challenge which caused the Response.
482
This field is one octet and indicates the length of the Value
487
The Value field is one or more octets. The most significant octet
488
is transmitted first.
490
The Challenge Value is a variable stream of octets. The
491
importance of the uniqueness of the Challenge Value and its
492
relationship to the secret is described above. The Challenge
493
Value MUST be changed each time a Challenge is sent. The length
494
of the Challenge Value depends upon the method used to generate
495
the octets, and is independent of the hash algorithm used.
497
The Response Value is the one-way hash calculated over a stream of
498
octets consisting of the Identifier, followed by (concatenated
499
with) the "secret", followed by (concatenated with) the Challenge
500
Value. The length of the Response Value depends upon the hash
501
algorithm used (16 octets for MD5).
508
RFC 1994 PPP CHAP August 1996
513
The Name field is one or more octets representing the
514
identification of the system transmitting the packet. There are
515
no limitations on the content of this field. For example, it MAY
516
contain ASCII character strings or globally unique identifiers in
517
ASN.1 syntax. The Name should not be NUL or CR/LF terminated.
518
The size is determined from the Length field.
521
4.2. Success and Failure
525
If the Value received in a Response is equal to the expected
526
value, then the implementation MUST transmit a CHAP packet with
527
the Code field set to 3 (Success).
529
If the Value received in a Response is not equal to the expected
530
value, then the implementation MUST transmit a CHAP packet with
531
the Code field set to 4 (Failure), and SHOULD take action to
534
A summary of the Success and Failure packet format is shown below.
535
The fields are transmitted from left to right.
537
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538
| Code | Identifier | Length |
539
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
541
+-+-+-+-+-+-+-+-+-+-+-+-+-
551
The Identifier field is one octet and aids in matching requests
552
and replies. The Identifier field MUST be copied from the
553
Identifier field of the Response which caused this reply.
564
RFC 1994 PPP CHAP August 1996
569
The Message field is zero or more octets, and its contents are
570
implementation dependent. It is intended to be human readable,
571
and MUST NOT affect operation of the protocol. It is recommended
572
that the message contain displayable ASCII characters 32 through
573
126 decimal. Mechanisms for extension to other character sets are
574
the topic of future research. The size is determined from the
579
Security Considerations
581
Security issues are the primary topic of this RFC.
583
The interaction of the authentication protocols within PPP are highly
584
implementation dependent. This is indicated by the use of SHOULD
585
throughout the document.
587
For example, upon failure of authentication, some implementations do
588
not terminate the link. Instead, the implementation limits the kind
589
of traffic in the Network-Layer Protocols to a filtered subset, which
590
in turn allows the user opportunity to update secrets or send mail to
591
the network administrator indicating a problem.
593
There is no provision for re-tries of failed authentication.
594
However, the LCP state machine can renegotiate the authentication
595
protocol at any time, thus allowing a new attempt. It is recommended
596
that any counters used for authentication failure not be reset until
597
after successful authentication, or subsequent termination of the
600
There is no requirement that authentication be full duplex or that
601
the same protocol be used in both directions. It is perfectly
602
acceptable for different protocols to be used in each direction.
603
This will, of course, depend on the specific protocols negotiated.
605
The secret SHOULD NOT be the same in both directions. This allows an
606
attacker to replay the peer's challenge, accept the computed
607
response, and use that response to authenticate.
609
In practice, within or associated with each PPP server, there is a
610
database which associates "user" names with authentication
611
information ("secrets"). It is not anticipated that a particular
612
named user would be authenticated by multiple methods. This would
613
make the user vulnerable to attacks which negotiate the least secure
614
method from among a set (such as PAP rather than CHAP). If the same
620
RFC 1994 PPP CHAP August 1996
623
secret was used, PAP would reveal the secret to be used later with
626
Instead, for each user name there should be an indication of exactly
627
one method used to authenticate that user name. If a user needs to
628
make use of different authentication methods under different
629
circumstances, then distinct user names SHOULD be employed, each of
630
which identifies exactly one authentication method.
632
Passwords and other secrets should be stored at the respective ends
633
such that access to them is as limited as possible. Ideally, the
634
secrets should only be accessible to the process requiring access in
635
order to perform the authentication.
637
The secrets should be distributed with a mechanism that limits the
638
number of entities that handle (and thus gain knowledge of) the
639
secret. Ideally, no unauthorized person should ever gain knowledge
640
of the secrets. Such a mechanism is outside the scope of this
646
David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
647
handshake at SDC when designing one of the protocols for a "secure"
648
network in the mid-1970s. Tom Bearson built a prototype Sytek
649
product ("Poloneous"?) on the challenge-response notion in the 1982-
650
83 timeframe. Another variant is documented in the various IBM SNA
651
manuals. Yet another variant was implemented by Karl Auerbach in the
652
Telebit NetBlazer circa 1991.
654
Kim Toms and Barney Wolff provided useful critiques of earlier
655
versions of this document.
657
Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
658
Steve Kent, for their extensive explanations and suggestions. Now,
659
if only we could get them to agree with each other.
676
RFC 1994 PPP CHAP August 1996
681
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
682
51, RFC 1661, DayDreamer, July 1994.
684
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
685
1700, USC/Information Sciences Institute, October 1994.
687
[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
688
MIT Laboratory for Computer Science and RSA Data Security,
689
Inc., RFC 1321, April 1992.
695
Comments should be submitted to the ietf-ppp@merit.edu mailing list.
697
This document was reviewed by the Point-to-Point Protocol Working
698
Group of the Internet Engineering Task Force (IETF). The working
699
group can be contacted via the current chair:
702
Ascend Communications
703
3518 Riverside Drive, Suite 101
710
Questions about this memo can also be directed to:
712
William Allen Simpson
714
Computer Systems Consulting Services
716
Madison Heights, Michigan 48071
719
wsimpson@GreenDragon.com (preferred)
added
removed
doc/standards/rfc1994.txt
