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