]>
Commit | Line | Data |
---|---|---|
354242c5 MW |
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 |