| blob | f009400bbf8e806395f585672dbf8a8ff724e2e4 |
1 \r
2 \r
3 \r
4 \r
5 \r
6 \r
7 Network Working Group S. Cobb\r
8 Informational Memo Microsoft\r
9 Revision 1.3 March 1997\r
10 \r
11 \r
12 Microsoft PPP CHAP Extensions\r
13 \r
14 \r
15 Status of this Memo\r
16 \r
17 This document has no official Internet Engineering Task Force\r
18 status. It is submitted as an example of one vendor's working\r
19 solution to several authentication issues not yet standardized by\r
20 the Point-to-Point Working Group.\r
21 \r
22 The protocol described is implemented in Microsoft Windows NT 3.5\r
23 and 3.51 and in Microsoft Windows95. Differences between the\r
24 platforms are noted in the text. This information, plus that in\r
25 the references, is believed sufficient to implement an\r
26 interoperating peer.\r
27 \r
28 Distribution of this memo is unlimited.\r
29 \r
30 \r
31 Abstract\r
32 \r
33 The Point-to-Point Protocol (PPP) [1] provides a standard method\r
34 for transporting multi-protocol datagrams over point-to-point\r
35 links. PPP defines an extensible Link Control Protocol and a\r
36 family of Network Control Protocols (NCPs) for establishing and\r
37 configuring different network-layer protocols.\r
38 \r
39 This document describes Microsoft's PPP CHAP dialect (MS-CHAP),\r
40 which extends the user authentication functionality provided on\r
41 Windows networks to remote workstations. MS-CHAP is closely\r
42 derived from the PPP Challenge/Handshake Authentication Protocol\r
43 described in RFC 1334 [2], which the reader should have at hand.\r
44 \r
45 \r
46 History\r
47 \r
48 Rev 1.21: (Sect 6) Fix error in implicit challenge description\r
49 Rev 1.22: (Sect 7) Fix error in sub-field table ordering\r
50 Rev 1.3: (Sect 10) Added hash example section\r
51 \r
52 \r
53 \r
54 \r
55 \r
56 \r
57 \r
58 \r
59 Cobb [Page 1]\r
61 Memo Microsoft PPP CHAP Extensions March 1997\r
62 \r
63 \r
64 Table Of Contents\r
65 \r
66 1. Introduction................................................3\r
67 2. LCP Configuration...........................................4\r
68 3. Challenge Packet............................................4\r
69 4. Response Packet.............................................4\r
70 5. Success Packet..............................................8\r
71 6. Failure Packet..............................................8\r
72 7. Change Password Packet (version 1)..........................9\r
73 8. Change Password Packet (version 2).........................12\r
74 9. Negotiation Examples.......................................16\r
75 10. Hash Example...............................................16\r
76 \r
77 REFERENCES.....................................................18\r
78 CHAIR'S ADDRESS................................................19\r
79 AUTHOR'S ADDRESS...............................................19\r
80 \r
81 \r
82 \r
83 \r
84 \r
85 \r
86 \r
87 \r
88 \r
89 \r
90 \r
91 \r
92 \r
93 \r
94 \r
95 \r
96 \r
97 \r
98 \r
99 \r
100 \r
101 \r
102 \r
103 \r
104 \r
105 \r
106 \r
107 \r
108 \r
109 \r
110 \r
111 \r
112 \r
113 \r
114 \r
115 \r
116 \r
117 \r
118 \r
119 Cobb [Page 2]\r
121 Memo Microsoft PPP CHAP Extensions March 1997\r
122 \r
123 \r
124 1. Introduction\r
125 \r
126 Microsoft created MS-CHAP to authenticate remote Windows\r
127 workstations, providing the functionality to which LAN-based users\r
128 are accustomed.\r
129 \r
130 The closest fit available in standard PPP is CHAP which is\r
131 primarily used for mutual secure authentication between WAN-aware\r
132 routers. Unfortunately, CHAP is not widely used in support of\r
133 remote workstations where providers commonly require an insecure\r
134 text login session in place of PPP authentication protocols. To\r
135 date, several remote workstation issues have not been adequately\r
136 addressed in CHAP. MS-CHAP addresses these issues and also\r
137 integrates the encryption and hashing algorithms used on Windows\r
138 networks.\r
139 \r
140 Where possible, MS-CHAP is consistent with standard CHAP, and the\r
141 differences are easily modularized. Microsoft implements MS-CHAP\r
142 as extensions to it's standard CHAP code base. Briefly,\r
143 differences between MS-CHAP and standard CHAP are:\r
144 \r
145 * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP\r
146 option 3, Authentication Protocol.\r
147 \r
148 * The MS-CHAP Response packet is in a format designed for\r
149 compatibility with Microsoft Windows NT 3.5 and 3.51,\r
150 Microsoft Windows95, and Microsoft LAN Manager 2.x networking\r
151 products. The MS-CHAP format does not require the\r
152 authenticator to store a clear or reversibly encrypted\r
153 password.\r
154 \r
155 * MS-CHAP provides an authenticator controlled authentication\r
156 retry mechanism.\r
157 \r
158 * MS-CHAP provides an authenticator controlled change password\r
159 mechanism.\r
160 \r
161 * MS-CHAP defines a set of reason-for-failure codes returned in\r
162 the Failure packet Message field.\r
163 \r
164 \r
165 \r
166 \r
167 \r
168 \r
169 \r
170 \r
171 \r
172 \r
173 \r
174 \r
175 \r
176 \r
177 \r
178 \r
179 Cobb [Page 3]\r
181 Memo Microsoft PPP CHAP Extensions March 1997\r
182 \r
183 \r
184 2. LCP Configuration\r
185 \r
186 The LCP configuration for MS-CHAP is identical to that for\r
187 standard CHAP, except that the Algorithm field has value 0x80,\r
188 rather than the MD5 value 0x05. Non-MS-CHAP-aware implementations\r
189 that correctly implement LCP Config-Rej have no problem dealing\r
190 with this non-standard option.\r
191 \r
192 Microsoft currently negotiates authentication only on the\r
193 server->workstation configuration. Mutual authentication may be\r
194 supported in the future.\r
195 \r
196 \r
197 3. Challenge Packet\r
198 \r
199 The MS-CHAP Challenge packet is identical in format to the\r
200 standard CHAP Challenge packet.\r
201 \r
202 MS-CHAP authenticators send an 8-octet challenge Value field. It\r
203 is not necessary for peers to duplicate Microsoft's algorithm for\r
204 selecting the 8-octet value, but the CHAP guidelines on randomness\r
205 should be observed.\r
206 \r
207 Microsoft authenticators do not currently provide information in\r
208 the Name field. This may change in the future.\r
209 \r
210 \r
211 4. Response Packet\r
212 \r
213 The MS-CHAP Response packet is identical in format to the standard\r
214 CHAP Response packet. However, the Value field is sub-formatted\r
215 differently as follows:\r
216 \r
217 24 octets: LAN Manager compatible challenge response\r
218 24 octets: Windows NT compatible challenge response\r
219 1 octet : "Use Windows NT compatible challenge response" flag\r
220 \r
221 The LAN Manager compatible challenge response is an encoded\r
222 function of the password and the received challenge as output by\r
223 the pseudo-code routine LmChallengeResponse below. LAN Manager\r
224 passwords are limited to 14 case-insensitive OEM characters.\r
225 \r
226 \r
227 \r
228 \r
229 \r
230 \r
231 \r
232 \r
233 \r
234 \r
235 \r
236 \r
237 \r
238 \r
239 Cobb [Page 4]\r
241 Memo Microsoft PPP CHAP Extensions March 1997\r
242 \r
243 \r
244 LmChallengeResponse(\r
245 IN 8-octet Challenge,\r
246 IN 0-to-14-oem-char Password,\r
247 OUT 24-octet Response )\r
248 {\r
249 LmPasswordHash(\r
250 Password,\r
251 giving PasswordHash )\r
252 \r
253 ChallengeResponse(\r
254 Challenge,\r
255 PasswordHash,\r
256 giving Response )\r
257 }\r
258 \r
259 LmPasswordHash(\r
260 IN 0-to-14-oem-char Password,\r
261 OUT 16-octet PasswordHash )\r
262 {\r
263 Set UcasePassword to the uppercased Password\r
264 Zero pad UcasePassword to 14 characters\r
265 \r
266 DesHash(\r
267 1st 7-octets of UcasePassword,\r
268 giving 1st 8-octets of PasswordHash )\r
269 \r
270 DesHash(\r
271 2nd 7-octets of UcasePassword,\r
272 giving 2nd 8-octets of PasswordHash )\r
273 }\r
274 \r
275 DesHash(\r
276 IN 7-octet Clear,\r
277 OUT 8-octet Cypher )\r
278 {\r
279 Make Cypher an irreversibly encrypted form of Clear by\r
280 encrypting known text [6] using Clear as the secret key,\r
281 that is...\r
282 \r
283 DesEncrypt(\r
284 StdText,\r
285 Clear,\r
286 giving Cypher )\r
287 }\r
288 \r
289 \r
290 \r
291 \r
292 \r
293 \r
294 \r
295 \r
296 \r
297 \r
298 \r
299 Cobb [Page 5]\r
301 Memo Microsoft PPP CHAP Extensions March 1997\r
302 \r
303 \r
304 DesEncrypt(\r
305 IN 8-octet Clear,\r
306 IN 7-octet Key,\r
307 OUT 8-octet Cypher )\r
308 {\r
309 Use the DES encryption algorithm [3] to encrypt Clear into\r
310 Cypher such that Cypher can only be decrypted back to\r
311 Clear by providing Key. Note that the DES algorithm takes\r
312 as input a 64-bit stream where the 8th, 16th, 24th, etc\r
313 bits are parity bits ignored by the encrypting algorithm.\r
314 Unless you write your own DES to accept 56-bit input\r
315 without parity, you will need to insert the parity bits\r
316 yourself.\r
317 }\r
318 \r
319 ChallengeResponse(\r
320 IN 8-octet Challenge,\r
321 IN 16-octet PasswordHash,\r
322 OUT 24-octet Response )\r
323 {\r
324 Set ZPasswordHash to PasswordHash zero padded to 21 octets\r
325 \r
326 DesEncrypt(\r
327 Challenge,\r
328 1st 7-octets of ZPasswordHash,\r
329 giving 1st 8-octets of Response )\r
330 \r
331 DesEncrypt(\r
332 Challenge,\r
333 2nd 7-octets of ZPasswordHash,\r
334 giving 2nd 8-octets of Response )\r
335 \r
336 DesEncrypt(\r
337 Challenge,\r
338 3rd 7-octets of ZPasswordHash,\r
339 giving 3rd 8-octets of Response )\r
340 }\r
341 \r
342 \r
343 The Windows NT compatible challenge response is an encoded\r
344 function of the password and the received challenge as output by\r
345 the NtChallengeResponse routine below. The Windows NT password is\r
346 a string of 0 to (theoretically) 256 case-sensitive Unicode\r
347 characters. Current versions of Windows NT limit passwords to 14\r
348 characters, mainly for compatibility reasons, though this may\r
349 change in the future.\r
350 \r
351 \r
352 \r
353 \r
354 \r
355 \r
356 \r
357 \r
358 \r
359 Cobb [Page 6]\r
361 Memo Microsoft PPP CHAP Extensions March 1997\r
362 \r
363 \r
364 NtChallengeResponse(\r
365 IN 8-octet Challenge,\r
366 IN 0-to-256-unicode-char Password,\r
367 OUT 24-octet Response )\r
368 {\r
369 NtPasswordHash(\r
370 Password,\r
371 giving PasswordHash )\r
372 \r
373 ChallengeResponse(\r
374 Challenge,\r
375 PasswordHash,\r
376 giving Response )\r
377 }\r
378 \r
379 NtPasswordHash(\r
380 IN 0-to-256-unicode-char Password,\r
381 OUT 16-octet PasswordHash )\r
382 {\r
383 Use the MD4 algorithm [4] to irreversibly hash Password\r
384 into PasswordHash. Only the password is hashed without\r
385 including any terminating 0.\r
386 }\r
387 \r
388 The "use Windows NT compatible challenge response" flag, if 1,\r
389 indicates that the Windows NT response is provided and should be\r
390 used in preference to the LAN Manager response. The LAN Manager\r
391 response will still be used if the account does not have a Windows\r
392 NT password hash, e.g. if the password has not been changed since\r
393 the account was uploaded from a LAN Manager 2.x account database.\r
394 The LAN Manager response need not be provided (set to 0's) if the\r
395 implementation expects all user accounts to be stored only in\r
396 fresh Windows NT account databases or ones where all uploaded\r
397 passwords have been changed. However, doing so may sacrifice\r
398 downward compatibility with non-Windows-NT servers.\r
399 \r
400 If the flag is 0, the Windows NT response is ignored and the LAN\r
401 Manager response is used. If the password is LAN Manager\r
402 compatible, interoperability may be achieved without providing the\r
403 Windows NT challenge response (set to 0's), and providing only the\r
404 LAN Manager response. This is what Microsoft Windows95 does,\r
405 though this may change in the future. Doing so may sacrifice\r
406 interoperability with OEM-specific versions of Windows NT designed\r
407 for maximum security in Windows-NT-only networks.\r
408 \r
409 Implementors seeking the broadest possible interoperability are\r
410 advised to supply both responses when the password is LAN Manager\r
411 compatible. This is what Microsoft Windows NT does.\r
412 \r
413 \r
414 \r
415 \r
416 \r
417 \r
418 \r
419 Cobb [Page 7]\r
421 Memo Microsoft PPP CHAP Extensions March 1997\r
422 \r
423 \r
424 The Name field identifies the authenticatee's user account name.\r
425 The Windows NT domain name may prefix the user's account name in\r
426 the typical Windows NT format, e.g. "redmond\stevec" where\r
427 "redmond" is a Windows NT domain containing the user account\r
428 "stevec". If a domain is not provided, the backslash should also\r
429 be omitted, e.g. "stevec".\r
430 \r
431 \r
432 5. Success Packet\r
433 \r
434 The Success packet is identical in format to the standard CHAP\r
435 Success packet.\r
436 \r
437 \r
438 6. Failure Packet\r
439 \r
440 The Failure packet is identical in format to the standard CHAP\r
441 Failure packet. There is, however, formatted text stored in the\r
442 Message field which, contrary to the standard CHAP rules, does\r
443 affect the protocol. The Message field format is:\r
444 \r
445 "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"\r
446 \r
447 where\r
448 \r
449 The "eeeeeeeeee" is the decimal error code (need not be 10\r
450 digits) corresponding to one of those listed below, though\r
451 implementations should deal with codes not on this list\r
452 gracefully.\r
453 \r
454 646 ERROR_RESTRICTED_LOGON_HOURS\r
455 647 ERROR_ACCT_DISABLED\r
456 648 ERROR_PASSWD_EXPIRED\r
457 649 ERROR_NO_DIALIN_PERMISSION\r
458 691 ERROR_AUTHENTICATION_FAILURE\r
459 709 ERROR_CHANGING_PASSWORD\r
460 \r
461 The "r" is a flag set to "1" if a retry is allowed, and "0" if\r
462 not. When authenticator sets this flag to "1" it disables\r
463 short timeouts, expecting the authenticatee to prompt the user\r
464 for new credentials and resubmit the response.\r
465 \r
466 The "cccccccccccccccc" is 16 hex digits representing an ASCII\r
467 representation of a new challenge value. This field is\r
468 optional. If it is not sent, authenticator expects the\r
469 resubmitted response to be calculated based on the previous\r
470 challenge value plus decimal 23 in the first octet, i.e. the\r
471 one immediately following the Value Size field. Windows95\r
472 authenticators may send this field. Windows NT authenticators\r
473 do not, but may in the future. Both systems implement\r
474 authenticatee support of this field.\r
475 \r
476 \r
477 \r
478 \r
479 Cobb [Page 8]\r
481 Memo Microsoft PPP CHAP Extensions March 1997\r
482 \r
483 \r
484 The "vvvvvvvvvv" is the decimal version code (need not be 10\r
485 digits) indicating the MS-CHAP protocol version supported on\r
486 the server. Currently, this is interesting only in selecting\r
487 a Change Password packet type. If the field is not present\r
488 the version should be assumed 1.\r
489 \r
490 Implementations should accept but ignore additional text they do\r
491 not recognize.\r
492 \r
493 \r
494 7. Change Password Packet (version 1)\r
495 \r
496 The version 1 Change Password packet does not appear in standard\r
497 CHAP. It allows the authenticatee to change the password on the\r
498 account specified in the previous Response packet. The version 1\r
499 Change Password packet should be sent only if the authenticator\r
500 reports ERROR_PASSWD_EXPIRED (E=648) in the Message field of the\r
501 Failure packet.\r
502 \r
503 This packet type is supported by Windows NT 3.5 and 3.51. It is\r
504 not supported by Windows95, though this may change in the future.\r
505 See also Change Password Packet (version 2).\r
506 \r
507 The format of this packet is as follows:\r
508 \r
509 1 octet : Code (=5)\r
510 1 octet : Identifier\r
511 2 octets: Length (=72)\r
512 16 octets: Encrypted LAN Manager Old password Hash\r
513 16 octets: Encrypted LAN Manager New Password Hash\r
514 16 octets: Encrypted Windows NT Old Password Hash\r
515 16 octets: Encrypted Windows NT New Password Hash\r
516 2 octets: Password Length\r
517 2 octets: Flags\r
518 \r
519 \r
520 Code\r
521 \r
522 5\r
523 \r
524 \r
525 Identifier\r
526 \r
527 The Identifier field is one octet and aids in matching\r
528 requests and replies. The value is the Identifier of the\r
529 received Failure packet to which this packet responds plus 1.\r
530 \r
531 \r
532 Length\r
533 \r
534 72\r
535 \r
536 \r
537 \r
538 \r
539 Cobb [Page 9]\r
541 Memo Microsoft PPP CHAP Extensions March 1997\r
542 \r
543 \r
544 Encrypted LAN Manager New Password Hash\r
545 Encrypted LAN Manager Old Password Hash\r
546 \r
547 These fields contain the LAN Manager password hash of the new\r
548 and old passwords encrypted with an 8-octet key value [6], as\r
549 output by the pseudo-code routine LmEncryptedPasswordHash\r
550 below.\r
551 \r
552 LmEncryptedPasswordHash(\r
553 IN 0-to-14-oem-char Password,\r
554 IN 8-octet KeyValue,\r
555 OUT 16-octet Cypher )\r
556 {\r
557 LmPasswordHash(\r
558 Password,\r
559 giving PasswordHash )\r
560 \r
561 PasswordHashEncryptedWithBlock(\r
562 PasswordHash,\r
563 KeyValue,\r
564 giving Cypher )\r
565 }\r
566 \r
567 PasswordHashEncryptedWithBlock(\r
568 IN 16-octet PasswordHash,\r
569 IN 7-octet Block,\r
570 OUT 16-octet Cypher )\r
571 {\r
572 DesEncrypt(\r
573 1st 8-octets PasswordHash,\r
574 1st 7-octets Block,\r
575 giving 1st 8-octets Cypher )\r
576 \r
577 DesEncrypt(\r
578 2nd 8-octets PasswordHash,\r
579 1st 7-octets Block,\r
580 giving 2nd 8-octets Cypher )\r
581 }\r
582 \r
583 \r
584 Encrypted Windows NT New Password Hash\r
585 Encrypted Windows NT Old Password Hash\r
586 \r
587 These fields contain the Windows NT password hash of the new\r
588 and old passwords encrypted with an 8-octet key value [6], as\r
589 output by the pseudo-code routine NtEncryptedPasswordHash\r
590 below.\r
591 \r
592 \r
593 \r
594 \r
595 \r
596 \r
597 \r
598 \r
599 Cobb [Page 10]\r
601 Memo Microsoft PPP CHAP Extensions March 1997\r
602 \r
603 \r
604 NtEncryptedPasswordHash(\r
605 IN 0-to-14-oem-char Password\r
606 IN 8-octet Challenge\r
607 OUT 16-octet Cypher )\r
608 {\r
609 NtPasswordHash(\r
610 Password,\r
611 giving PasswordHash )\r
612 \r
613 PasswordHashEncryptedWithBlock(\r
614 PasswordHash,\r
615 Challenge,\r
616 giving Cypher )\r
617 }\r
618 \r
619 \r
620 Password Length\r
621 \r
622 The length in octets of the LAN Manager compatible form of the\r
623 new password. If this value is less than or equal to 14 it is\r
624 assumed that the encrypted LAN Manager password hash fields\r
625 are valid. Otherwise, it is assumed these fields are not\r
626 valid, in which case the Windows NT compatible passwords must\r
627 be provided.\r
628 \r
629 \r
630 Flags\r
631 \r
632 Bit field of option flags where 0 is the least significant bit\r
633 of the 16-bit quantity:\r
634 \r
635 0 : Set 1 indicates that the encrypted Windows NT\r
636 hashed passwords are valid and should be used. If\r
637 0, the Windows NT fields are not used and the LAN\r
638 Manager fields must be provided.\r
639 \r
640 For the broadest possible interoperability,\r
641 implementations are encouraged to provide both the\r
642 Windows NT and LAN Manager fields when the password\r
643 is LAN Manager compatible. This is what Windows NT\r
644 does.\r
645 \r
646 1-15 : Reserved, always set 0.\r
647 \r
648 \r
649 \r
650 \r
651 \r
652 \r
653 \r
654 \r
655 \r
656 \r
657 \r
658 \r
659 Cobb [Page 11]\r
661 Memo Microsoft PPP CHAP Extensions March 1997\r
662 \r
663 \r
664 8. Change Password Packet (version 2)\r
665 \r
666 The version 2 Change Password packet does not appear in standard\r
667 CHAP. It allows the authenticatee to change the password on the\r
668 account specified in the previous Response packet. The version 2\r
669 Change Password packet should be sent only if the authenticator\r
670 reports ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or more in\r
671 the Message field of the Failure packet.\r
672 \r
673 This packet type is supported by Windows NT 3.51. It is not\r
674 supported by Windows NT 3.5 or Windows95, though the latter may\r
675 change in the future. The version 2 change password packet type\r
676 is preferable to the version 1 type and should be offered and\r
677 accepted where possible.\r
678 \r
679 The format of this packet is as follows:\r
680 \r
681 1 octet : Code (=6)\r
682 1 octet : Identifier\r
683 2 octet : Length (=1070)\r
684 516 octets : Password Encrypted with Old NT Hash\r
685 16 octets : Old NT Hash Encrypted with New NT Hash\r
686 516 octets : Password Encrypted with Old LM Hash\r
687 16 octets : Old LM Hash Encrypted With New NT Hash\r
688 24 octets : LAN Manager compatible challenge response\r
689 24 octets : Windows NT compatible challenge response\r
690 2-octet : Flags\r
691 \r
692 \r
693 Code\r
694 \r
695 6\r
696 \r
697 \r
698 Identifier\r
699 \r
700 The Identifier field is one octet and aids in matching\r
701 requests and replies. The value is the Identifier of the\r
702 received Failure packet to which this packet responds plus 1.\r
703 \r
704 \r
705 Length\r
706 \r
707 1118\r
708 \r
709 \r
710 Password Encrypted with Old NT Hash\r
711 \r
712 This field contains the PWBLOCK form of the new Windows NT\r
713 password encrypted with the old Windows NT password hash, as\r
714 output by the NewPasswordEncryptedWithOldNtPasswordHash\r
715 routine below:\r
716 \r
717 \r
718 \r
719 Cobb [Page 12]\r
721 Memo Microsoft PPP CHAP Extensions March 1997\r
722 \r
723 \r
724 datatype-PWBLOCK\r
725 {\r
726 256-unicode-char Password\r
727 4-octets PasswordLength\r
728 }\r
729 \r
730 NewPasswordEncryptedWithOldNtPasswordHash(\r
731 IN 0-to-256-unicode-char NewPassword,\r
732 IN 0-to-256-unicode-char OldPassword,\r
733 OUT datatype-PWBLOCK EncryptedPwBlock )\r
734 {\r
735 NtPasswordHash(\r
736 OldPassword,\r
737 giving PasswordHash )\r
738 \r
739 EncryptPwBlockWithPasswordHash(\r
740 NewPassword,\r
741 PasswordHash,\r
742 giving EncryptedPwBlock )\r
743 }\r
744 \r
745 EncryptPwBlockWithPasswordHash(\r
746 IN 0-to-256-unicode-char Password,\r
747 IN 16-octet PasswordHash,\r
748 OUT datatype-PWBLOCK PwBlock )\r
749 {\r
750 Fill ClearPwBlock with random octet values\r
751 lstrcpyW( to ClearPwBlock.Password, from Password )\r
752 ClearPwBlock.PasswordLength = lstrlenW( Password )\r
753 \r
754 Rc4Encrypt(\r
755 ClearPwBlock,\r
756 sizeof( ClearPwBlock ),\r
757 PasswordHash,\r
758 sizeof( PasswordHash ),\r
759 giving PwBlock )\r
760 }\r
761 \r
762 Rc4Encrypt(\r
763 IN x-octet Clear,\r
764 IN integer ClearLength,\r
765 IN y-octet Key,\r
766 IN integer KeyLength,\r
767 OUT x-octet Cypher )\r
768 {\r
769 Use the RC4 encryption algorithm [5] to encrypt Clear of\r
770 length ClearLength octets into a Cypher of the same length\r
771 such that the Cypher can only be decrypted back to Clear\r
772 by providing a Key of length KeyLength octets.\r
773 }\r
774 \r
775 \r
776 \r
777 \r
778 \r
779 Cobb [Page 13]\r
781 Memo Microsoft PPP CHAP Extensions March 1997\r
782 \r
783 \r
784 Old NT Hash Encrypted with New NT Hash\r
785 \r
786 This field contains the old Windows NT password hash encrypted\r
787 with the new Windows NT password hash, as output by the\r
788 OldNtPasswordHashEncryptedWithNewNtPasswordHash routine below:\r
789 \r
790 OldNtPasswordHashEncryptedWithNewNtPasswordHash(\r
791 IN 0-to-256-unicode-char NewPassword,\r
792 IN 0-to-256-unicode-char OldPassword,\r
793 OUT 16-octet EncryptedPasswordHash )\r
794 {\r
795 NtPasswordHash(\r
796 OldPassword,\r
797 giving OldPasswordHash )\r
798 \r
799 NtPasswordHash(\r
800 NewPassword,\r
801 giving NewPasswordHash )\r
802 \r
803 PasswordHashEncryptedWithBlock(\r
804 OldPasswordHash,\r
805 NewPasswordHash,\r
806 giving EncrytptedPasswordHash )\r
807 }\r
808 \r
809 \r
810 Password Encrypted with Old LM Hash\r
811 \r
812 This field contains the PWBLOCK form of the new Windows NT\r
813 password encrypted with the old LAN Manager password hash, as\r
814 output by the NewPasswordEncryptedWithOldLmPasswordHash\r
815 routine below:\r
816 \r
817 NewPasswordEncryptedWithOldLmPasswordHash(\r
818 IN 0-to-256-unicode-char NewPassword,\r
819 IN 0-to-256-unicode-char OldPassword,\r
820 OUT datatype-PWBLOCK EncryptedPwBlock )\r
821 {\r
822 LmPasswordHash(\r
823 OldPassword,\r
824 giving PasswordHash )\r
825 \r
826 EncryptPwBlockWithPasswordHash(\r
827 NewPassword,\r
828 PasswordHash,\r
829 giving EncryptedPwBlock )\r
830 }\r
831 \r
832 \r
833 \r
834 \r
835 \r
836 \r
837 \r
838 \r
839 Cobb [Page 14]\r
841 Memo Microsoft PPP CHAP Extensions March 1997\r
842 \r
843 \r
844 Old LM Hash Encrypted with New NT Hash\r
845 \r
846 This field contains the old LAN Manager password hash encrypted\r
847 with the new Windows NT password hash, as output by the\r
848 OldLmPasswordHashEncryptedWithNewNtPasswordHash routine below:\r
849 \r
850 OldLmPasswordHashEncryptedWithNewNtPasswordHash(\r
851 IN 0-to-256-unicode-char NewPassword,\r
852 IN 0-to-256-unicode-char OldPassword,\r
853 OUT 16-octet EncryptedPasswordHash )\r
854 {\r
855 LmPasswordHash(\r
856 OldPassword,\r
857 giving OldPasswordHash )\r
858 \r
859 NtPasswordHash(\r
860 NewPassword,\r
861 giving NewPasswordHash )\r
862 \r
863 PasswordHashEncryptedWithBlock(\r
864 OldPasswordHash,\r
865 NewPasswordHash,\r
866 giving EncrytptedPasswordHash )\r
867 }\r
868 \r
869 \r
870 LAN Manager compatible challenge response\r
871 Windows NT compatible challenge response\r
872 \r
873 The challenge response fields as described in the Response\r
874 packet description, but calculated on the new password and the\r
875 same challenge used in the last response.\r
876 \r
877 \r
878 Flags\r
879 \r
880 Bit field of option flags:\r
881 \r
882 0 : The "use Windows NT compatible challenge response"\r
883 flag as described in the Response packet.\r
884 \r
885 1 : Set 1 indicates that the "Password Encrypted with\r
886 Old LM Hash" and "Old LM Hash Encrypted With New NT\r
887 Hash" fields are valid and should be used. Set 0\r
888 indicates these fields are not valid.\r
889 \r
890 For the broadest possible interoperability,\r
891 implementations are encouraged to provide both the\r
892 Windows NT and LAN Manager fields when the password\r
893 is LAN Manager compatible. This is what Windows NT\r
894 does.\r
895 \r
896 2-15 : Reserved, always set 0.\r
897 \r
898 \r
899 Cobb [Page 15]\r
901 Memo Microsoft PPP CHAP Extensions March 1997\r
902 \r
903 \r
904 9. Negotiation Examples\r
905 \r
906 Here are some examples of typical negotiations. The authenticatee\r
907 is on the left and the authenticator is on the right.\r
908 \r
909 The packet sequence ID is incremented on each authentication retry\r
910 Response and on the change password response. All cases where the\r
911 packet sequence ID is updated are noted below.\r
912 \r
913 Response retry is never allowed after either Change Password.\r
914 Change Password may occur after Response retry. The implied\r
915 challenge form is shown in the examples, though all cases of\r
916 "first challenge+23" should be replaced by the\r
917 "C=cccccccccccccccc" challenge if authenticator supplies it in the\r
918 Failure packet.\r
919 \r
920 \r
921 Successful authentication\r
922 \r
923 <- Challenge\r
924 Response ->\r
925 <- Success\r
926 \r
927 \r
928 Failed authentication with no retry allowed\r
929 \r
930 <- Challenge\r
931 Response ->\r
932 <- Failure (E=691 R=0)\r
933 \r
934 \r
935 Successful authentication after retry\r
936 \r
937 <- Challenge\r
938 Response ->\r
939 <- Failure (E=691 R=1), disable short timeout\r
940 Response (++ID) to first challenge+23 ->\r
941 <- Success\r
942 \r
943 \r
944 Failed hack attack with 3 attempts allowed\r
945 \r
946 <- Challenge\r
947 Response ->\r
948 <- Failure (E=691 R=1), disable short timeout\r
949 Response (++ID) to first challenge+23 ->\r
950 <- Failure (E=691 R=1), disable short timeout\r
951 Response (++ID) to first challenge+23+23 ->\r
952 <- Failure (E=691 R=0)\r
953 \r
954 \r
955 \r
956 \r
957 \r
958 \r
959 Cobb [Page 16]\r
961 Memo Microsoft PPP CHAP Extensions March 1997\r
962 \r
963 \r
964 Successful authentication with password change\r
965 \r
966 <- Challenge\r
967 Response ->\r
968 <- Failure (E=648 R=0), disable short timeout\r
969 ChangePassword (++ID) to first challenge ->\r
970 <- Success\r
971 \r
972 Successful authentication with retry and password change\r
973 \r
974 <- Challenge\r
975 Response ->\r
976 <- Failure (E=691 R=1), disable short timeout\r
977 Response (++ID) to first challenge+23 ->\r
978 <- Failure (E=648 R=0), disable short timeout\r
979 ChangePassword (++ID) to first challenge+23 ->\r
980 <- Success\r
981 \r
982 \r
983 10. Hash Example\r
984 \r
985 Intermediate values for password "MyPw".\r
986 \r
987 8-octet Challenge:\r
988 10 2D B5 DF 08 5D 30 41\r
989 \r
990 0-to-14-oem-char LmPassword:\r
991 4D 59 50 57\r
992 \r
993 16-octet LmPasswordHash:\r
994 75 BA 30 19 8E 6D 19 75 AA D3 B4 35 B5 14 04 EE\r
995 \r
996 24-octet LmChallengeResponse:\r
997 91 88 1D 01 52 AB 0C 33 C5 24 13 5E C2 4A 95 EE\r
998 64 E2 3C DC 2D 33 34 7D\r
999 \r
1000 0-to-256-unicode-char NtPassword:\r
1001 4D 00 79 00 50 00 77 00\r
1002 \r
1003 16-octet NtPasswordHash:\r
1004 FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC\r
1005 \r
1006 24-octet NtChallengeResponse:\r
1007 4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C\r
1008 A4 C3 51 AB 40 9A 3D 61\r
1009 \r
1010 \r
1011 \r
1012 \r
1013 \r
1014 \r
1015 \r
1016 \r
1017 \r
1018 \r
1019 Cobb [Page 17]\r
1021 Memo Microsoft PPP CHAP Extensions March 1997\r
1022 \r
1023 \r
1024 REFERENCES\r
1025 \r
1026 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,\r
1027 Daydreamer, May 1992\r
1028 \r
1029 [2] LLoyd, B and Simpson, W., "PPP Authentication Protocols",\r
1030 RFC 1334, L&A and Daydreamer respectively, Octobet 1992\r
1031 \r
1032 [3] "Data Encryption Standard (DES)" is Federal Information\r
1033 Processing Standard publication 46, National Institute of\r
1034 Standard and Techology.\r
1035 \r
1036 [4] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, MIT\r
1037 Laboratory for Computer Science and RSA Data Security, Inc.,\r
1038 April 1992.\r
1039 \r
1040 [5] RC4 is an encryption standard available from RSA Data Security\r
1041 Inc.\r
1042 \r
1043 [6] The 8-octet StdText string used in the LAN Manager compatible\r
1044 password hashing and the 8-octet KeyValue used in the Change\r
1045 Password (version 1) packet are not available for public\r
1046 distribution at this time. Contact the Microsoft Developer\r
1047 Relations group (at time of writing dbeaver@microsoft.com) for\r
1048 details on obtaining these values. On this particular point\r
1049 the author can't help you.\r
1050 \r
1051 \r
1052 \r
1053 \r
1054 \r
1055 \r
1056 \r
1057 \r
1058 \r
1059 \r
1060 \r
1061 \r
1062 \r
1063 \r
1064 \r
1065 \r
1066 \r
1067 \r
1068 \r
1069 \r
1070 \r
1071 \r
1072 \r
1073 \r
1074 \r
1075 \r
1076 \r
1077 \r
1078 \r
1079 Cobb [Page 18]\r
1081 Memo Microsoft PPP CHAP Extensions March 1997\r
1082 \r
1083 \r
1084 CHAIR'S ADDRESS\r
1085 \r
1086 The working group can be contacted via the current chair:\r
1087 \r
1088 Fred Baker\r
1089 Email: fred@cisco.com\r
1090 \r
1091 \r
1092 \r
1093 AUTHOR'S ADDRESS\r
1094 \r
1095 The author is a developer in Microsoft's Windows NT\r
1096 Internetworking group, which monitors the ietf-ppp@merit.edu\r
1097 discussions. Questions can also be directed as below, where email\r
1098 is preferred.\r
1099 \r
1100 Steve Cobb\r
1101 Microsoft Corporation\r
1102 One Microsoft Way\r
1103 Redmond, WA 98052-6399\r
1104 \r
1105 Email: stevec@microsoft.com\r
1106 \r
1107 The author maintains an informal mailing list of persons\r
1108 interested in MS-CHAP and other news regarding Windows NT support\r
1109 for PPP authentication protocols. Send email if interested.\r
1110 \r
1111 \r
1112 \r
1113 \r
1114 \r
1115 \r
1116 \r
1117 \r
1118 \r
1119 \r
1120 \r
1121 \r
1122 \r
1123 \r
1124 \r
1125 \r
1126 \r
1127 \r
1128 \r
1129 \r
1130 \r
1131 \r
1132 \r
1133 \r
1134 \r
1135 \r
1136 \r
1137 \r
1138 \r
1139 Cobb [Page 19]\r