added RADIUS, RADIUS-EAP and EAP-MD5 (CHAP) RFCs
[strongswan.git] / doc / standards / rfc1994.txt
1
2
3
4
5
6
7 Network Working Group                                         W. Simpson
8 Request for Comments: 1994                                    DayDreamer
9 Obsoletes: 1334                                              August 1996
10 Category: Standards Track
11
12
13          PPP Challenge Handshake Authentication Protocol (CHAP)
14
15
16 Status of this Memo
17
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.
23
24 Abstract
25
26    The Point-to-Point Protocol (PPP) [1] provides a standard method for
27    transporting multi-protocol datagrams over point-to-point links.
28
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.
32
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.
36
37 Table of Contents
38
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
54
55
56
57
58 Simpson                                                         [Page i]
59 \f
60 RFC 1994                        PPP CHAP                     August 1996
61
62
63 1.  Introduction
64
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.
70
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
74    Establishment phase.
75
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.
81
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
85    Protocol (PPP) [1].
86
87
88 1.1.  Specification of Requirements
89
90    In this document, several words are used to signify the requirements
91    of the specification.  These words are often capitalized.
92
93    MUST      This word, or the adjective "required", means that the
94              definition is an absolute requirement of the specification.
95
96    MUST NOT  This phrase means that the definition is an absolute
97              prohibition of the specification.
98
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
103              different course.
104
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.
110
111
112
113
114 Simpson                                                         [Page 1]
115 \f
116 RFC 1994                        PPP CHAP                     August 1996
117
118
119 1.2.  Terminology
120
121    This document frequently uses the following terms:
122
123    authenticator
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
127              phase.
128
129    peer      The other end of the point-to-point link; the end which is
130              being authenticated by the authenticator.
131
132    silently discard
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.
138
139
140
141
142 2.  Challenge-Handshake Authentication Protocol
143
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.
148
149    1.    After the Link Establishment phase is complete, the
150          authenticator sends a "challenge" message to the peer.
151
152    2.    The peer responds with a value calculated using a "one-way
153          hash" function.
154
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.
159
160    4.    At random intervals, the authenticator sends a new challenge to
161          the peer, and repeats steps 1 to 3.
162
163
164
165
166
167
168
169
170 Simpson                                                         [Page 2]
171 \f
172 RFC 1994                        PPP CHAP                     August 1996
173
174
175 2.1.  Advantages
176
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.
182
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.
185
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
188    authentication.
189
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.
195
196
197 2.2.  Disadvantages
198
199    CHAP requires that the secret be available in plaintext form.
200    Irreversably encrypted password databases commonly available cannot
201    be used.
202
203    It is not as useful for large installations, since every possible
204    secret is maintained at both ends of the link.
205
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
212       specification.
213
214
215
216
217
218
219
220
221
222
223
224
225
226 Simpson                                                         [Page 3]
227 \f
228 RFC 1994                        PPP CHAP                     August 1996
229
230
231 2.3.  Design Requirements
232
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.
240
241    The one-way hash algorithm is chosen such that it is computationally
242    infeasible to determine the secret from the known challenge and
243    response values.
244
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.
251
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.
255
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
259    attacks.
260
261    A discussion of sources of uniqueness and probability of divergence
262    is included in the Magic-Number Configuration Option [1].
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282 Simpson                                                         [Page 4]
283 \f
284 RFC 1994                        PPP CHAP                     August 1996
285
286
287 3.  Configuration Option Format
288
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.
292
293    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
294    |     Type      |    Length     |     Authentication-Protocol   |
295    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
296    |   Algorithm   |
297    +-+-+-+-+-+-+-+-+
298
299    Type
300
301       3
302
303    Length
304
305       5
306
307    Authentication-Protocol
308
309       c223 (hex) for Challenge-Handshake Authentication Protocol.
310
311    Algorithm
312
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
316       implemented:
317
318          5       CHAP with MD5 [3]
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338 Simpson                                                         [Page 5]
339 \f
340 RFC 1994                        PPP CHAP                     August 1996
341
342
343 4.  Packet Format
344
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.
350
351    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
352    |     Code      |  Identifier   |            Length             |
353    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
354    |    Data ...
355    +-+-+-+-+
356
357    Code
358
359       The Code field is one octet and identifies the type of CHAP
360       packet.  CHAP Codes are assigned as follows:
361
362          1       Challenge
363          2       Response
364          3       Success
365          4       Failure
366
367    Identifier
368
369       The Identifier field is one octet and aids in matching challenges,
370       responses and replies.
371
372    Length
373
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
378       reception.
379
380    Data
381
382       The Data field is zero or more octets.  The format of the Data
383       field is determined by the Code field.
384
385
386
387
388
389
390
391
392
393
394 Simpson                                                         [Page 6]
395 \f
396 RFC 1994                        PPP CHAP                     August 1996
397
398
399 4.1.  Challenge and Response
400
401    Description
402
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.
408
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
411       been altered.
412
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).
417
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).
422
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.
432
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.
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450 Simpson                                                         [Page 7]
451 \f
452 RFC 1994                        PPP CHAP                     August 1996
453
454
455    A summary of the Challenge and Response packet format is shown below.
456    The fields are transmitted from left to right.
457
458    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459    |     Code      |  Identifier   |            Length             |
460    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
461    |  Value-Size   |  Value ...
462    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
463    |  Name ...
464    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
465
466    Code
467
468       1 for Challenge;
469
470       2 for Response.
471
472    Identifier
473
474       The Identifier field is one octet.  The Identifier field MUST be
475       changed each time a Challenge is sent.
476
477       The Response Identifier MUST be copied from the Identifier field
478       of the Challenge which caused the Response.
479
480    Value-Size
481
482       This field is one octet and indicates the length of the Value
483       field.
484
485    Value
486
487       The Value field is one or more octets.  The most significant octet
488       is transmitted first.
489
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.
496
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).
502
503
504
505
506 Simpson                                                         [Page 8]
507 \f
508 RFC 1994                        PPP CHAP                     August 1996
509
510
511    Name
512
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.
519
520
521 4.2.  Success and Failure
522
523    Description
524
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).
528
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
532       terminate the link.
533
534    A summary of the Success and Failure packet format is shown below.
535    The fields are transmitted from left to right.
536
537    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538    |     Code      |  Identifier   |            Length             |
539    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
540    |  Message  ...
541    +-+-+-+-+-+-+-+-+-+-+-+-+-
542
543    Code
544
545       3 for Success;
546
547       4 for Failure.
548
549    Identifier
550
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.
554
555
556
557
558
559
560
561
562 Simpson                                                         [Page 9]
563 \f
564 RFC 1994                        PPP CHAP                     August 1996
565
566
567    Message
568
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
575       Length field.
576
577
578
579 Security Considerations
580
581    Security issues are the primary topic of this RFC.
582
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.
586
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.
592
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
598    failed link.
599
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.
604
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.
608
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
615
616
617
618 Simpson                                                        [Page 10]
619 \f
620 RFC 1994                        PPP CHAP                     August 1996
621
622
623    secret was used, PAP would reveal the secret to be used later with
624    CHAP.
625
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.
631
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.
636
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
641    specification.
642
643
644 Acknowledgements
645
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.
653
654    Kim Toms and Barney Wolff provided useful critiques of earlier
655    versions of this document.
656
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.
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674 Simpson                                                        [Page 11]
675 \f
676 RFC 1994                        PPP CHAP                     August 1996
677
678
679 References
680
681    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
682          51, RFC 1661, DayDreamer, July 1994.
683
684    [2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
685          1700, USC/Information Sciences Institute, October 1994.
686
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.
690
691
692
693 Contacts
694
695    Comments should be submitted to the ietf-ppp@merit.edu mailing list.
696
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:
700
701       Karl Fox
702       Ascend Communications
703       3518 Riverside Drive, Suite 101
704       Columbus, Ohio 43221
705
706           karl@MorningStar.com
707           karl@Ascend.com
708
709
710    Questions about this memo can also be directed to:
711
712       William Allen Simpson
713       DayDreamer
714       Computer Systems Consulting Services
715       1384 Fontaine
716       Madison Heights, Michigan  48071
717
718           wsimpson@UMich.edu
719           wsimpson@GreenDragon.com (preferred)
720
721
722
723
724
725
726
727
728
729
730 Simpson                                                        [Page 12]
731 \f
732