idnits 2.17.1 draft-ietf-pppext-mschap-v2-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 79 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...This document...' == Line 12 has weird spacing: '...as, and its...' == Line 17 has weird spacing: '...and may be ...' == Line 18 has weird spacing: '...ference mater...' == Line 21 has weird spacing: '...To learn the...' == (74 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1998) is 9349 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '39' is mentioned on line 482, but not defined == Missing Reference: '41' is mentioned on line 488, but not defined == Unused Reference: '3' is defined on line 283, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1320 (ref. '5') (Obsoleted by RFC 6150) ** Obsolete normative reference: RFC 1750 (ref. '7') (Obsoleted by RFC 4086) Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Microsoft Corporation 4 Category: Informational September 1998 5 7 Microsoft PPP CHAP Extensions, Version 2 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working doc- 14 uments as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. The distribution of 28 this memo is unlimited. It is filed as and expires March 23, 1999. Please send comments to the PPP 30 Extensions Working Group mailing list (ietf-ppp@merit.edu) or to the 31 author (glennz@microsoft.com). 33 2. Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. PPP 37 defines an extensible Link Control Protocol and a family of Network Con- 38 trol Protocols (NCPs) for establishing and configuring different net- 39 work-layer protocols. 41 This document describes version two of Microsoft's PPP CHAP dialect (MS- 42 CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP ver- 43 sion one (MS-CHAP-V1, described in [9]). In particular, certain proto- 44 col fields have been deleted or reused but with different semantics. In 45 addition, MS-CHAP-V2 features mutual authentication. 47 The algorithms used in the generation of various MS-CHAP-V2 protocol 48 fields are described in an appendix. 50 3. Introduction 52 Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and stan- 53 dard CHAP. Briefly, the differences between MS-CHAP-V2 and MS-CHAP-V1 54 are: 56 * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP 57 option 3, Authentication Protocol. 59 * MS-CHAP-V2 provides mutual authentication between peers by 60 piggybacking a peer challenge on the Response packet and an 61 authenticator reponse on the Success packet. 63 * The calculation of the "Windows NT compatible challenge 64 response" sub-field in the Response packet has been changed 65 to include the peer challenge and the user name. 67 * In MS-CHAP-V1, the "LAN Manager compatible challenge response" 68 sub-field was always sent in the Response packet. This field 69 has been replaced in MS-CHAP-V2 by the Peer-Challenge field. 71 * The format of the Message field in the Failure packet has 72 been changed. 74 * The Change Password (version 1) and Change Password (version 2) 75 packets are no longer supported. They have been replaced with a 76 single Change-Password packet. 78 4. Specification of Requirements 80 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 81 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 82 described in [2]. 84 5. LCP Configuration 86 The LCP configuration for MS-CHAP-V2 is identical to that for standard 87 CHAP, except that the Algorithm field has value 0x81, rather than the 88 MD5 value 0x05. PPP implementations which do not support MS-CHAP-V2, 89 but correctly implement LCP Config-Rej, should have no problem dealing 90 with this non-standard option. 92 6. Challenge Packet 94 The MS-CHAP-V2 Challenge packet is identical in format to the standard 95 CHAP Challenge packet. 97 MS-CHAP-V2 authenticators send an 16-octet challenge Value field. Peers 98 need not duplicate Microsoft's algorithm for selecting the 16-octet 99 value, but the standard guidelines on randomness [1,2,7] SHOULD be 100 observed. 102 Microsoft authenticators do not currently provide information in the 103 Name field. This may change in the future. 105 7. Response Packet 107 The MS-CHAP-V2 Response packet is identical in format to the standard 108 CHAP Response packet. However, the Value field is sub-formatted differ- 109 ently as follows: 111 24 octets: Peer-Challenge 112 24 octets: NT-Response 113 1 octet : Flags 115 The Peer-Challenge field is a 16-octet random number. As the name 116 implies, it is generated by the peer and is used in the calculation of 117 the NT-Response field, below. Peers need not duplicate Microsoft's 118 algorithm for selecting the 16-octet value, but the standard guidelines 119 on randomness [1,2,7] SHOULD be observed. 121 The NT-Response field is an encoded function of the password, the user 122 name, the contents of the Peer-Challenge field and the received chal- 123 lenge as output by the routine GenerateNTResponse() (see section A.1, 124 below). The Windows NT password is a string of 0 to (theoretically) 256 125 case-sensitive Unicode [8] characters. Current versions of Windows NT 126 limit passwords to 14 characters, mainly for compatibility reasons; this 127 may change in the future. When computing the NT-Response field con- 128 tents, only the user name is used, without any associated Windows NT 129 domain name. This is true regardless of whether a Windows NT domain 130 name is present in the Name field (see below). 132 The Flag field is reserved for future use and MUST be zero. 134 The Name field is a string of 0 to (theoretically) 256 case-sensitive 135 ASCII characters which identifies the peer's user account name. The 136 Windows NT domain name may prefix the user's account name (e.g. 137 "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the user 138 account "johndoe"). If a domain is not provided, the backslash should 139 also be omitted, (e.g. "johndoe"). 141 8. Success Packet 143 The Success packet is identical in format to the standard CHAP Success 144 packet. However, the Message field contains a 42-octet authenticator 145 response string of the form 147 "S=" 149 where is a 20 octet number encoded in ASCII as 40 hexadec- 150 imal digits. The hexadecimal digits A-F (if present) MUST be uppercase. 151 This number is derived from the challenge from the Challenge packet, the 152 Peer-Challenge and NT-Response fields from the Response packet, and the 153 peer password as output by the routine GenerateAuthenticatorResponse() 154 (see section A.6, below). The authenticating peer MUST verify the 155 authenticator response when a Success packet is received. The method 156 for verifying the authenticator is described in section A.7, below. If 157 the authenticator response is either missing or incorrect, the peer MUST 158 end the session. 160 9. Failure Packet 162 The Failure packet is identical in format to the standard CHAP Failure 163 packet. There is, however, formatted text stored in the Message field 164 which, contrary to the standard CHAP rules, does affect the operation of 165 the protocol. The Message field format is: 167 "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv" 169 where 171 The "eeeeeeeeee" is the ASCII representation of a decimal error 172 code (need not be 10 digits) corresponding to one of those listed 173 below, though implementations should deal with codes not on this 174 list gracefully. 176 646 ERROR_RESTRICTED_LOGON_HOURS 177 647 ERROR_ACCT_DISABLED 178 648 ERROR_PASSWD_EXPIRED 179 649 ERROR_NO_DIALIN_PERMISSION 180 691 ERROR_AUTHENTICATION_FAILURE 181 709 ERROR_CHANGING_PASSWORD 183 The "r" is an ASCII flag set to '1' if a retry is allowed, and '0' 184 if not. When the authenticator sets this flag to '1' it disables 185 short timeouts, expecting the peer to prompt the user for new cre- 186 dentials and resubmit the response. 188 The "cccccccccccccccccccccccccccccccc" is the ASCII representation 189 of a hexadecimal challenge value. This field MUST be exactly 32 190 octets long and MUST be present. 192 The "vvvvvvvvvv" is the ASCII representation of a decimal version 193 code (need not be 10 digits) indicating the password changing pro- 194 tocol version supported on the server. For MS-CHAP-V2, this value 195 SHOULD always be 3. 197 Implementations should accept but ignore additional text they do not 198 recognize. 200 10. Change-Password Packet 202 The Change-Password packet does not appear in either standard CHAP or 203 MS-CHAP-V1. It allows the peer to change the password on the account 204 specified in the preceding Response packet. The Change-Password packet 205 should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED 206 (E=648) in the Message field of the Failure packet. 208 This packet type is supported by recent versions of Windows NT 4.0, Win- 209 dows 95 and Windows 98. It is not supported by Windows NT 3.5, Windows 210 NT 3.51, or early versions of Windows NT 4.0, Windows 95 and Windows 98. 212 The format of this packet is as follows: 214 1 octet : Code 215 1 octet : Identifier 216 2 octets : Length 217 516 octets : Encrypted-Password 218 16 octets : Encrypted-Hash 219 24 octets : Peer-Challenge 220 24 octets : NT-Response 221 2-octet : Flags 223 Code 224 7 226 Identifier 227 The Identifier field is one octet and aids in matching requests 228 and replies. The value is the Identifier of the received Failure 229 packet to which this packet responds plus 1. 231 Length 232 586 234 Encrypted-Password 235 This field contains the PWBLOCK form of the new Windows NT pass- 236 word encrypted with the old Windows NT password hash, as output by 237 the NewPasswordEncryptedWithOldNtPasswordHash() routine (see sec- 238 tion A.8, below). 240 Encrypted-Hash 241 This field contains the old Windows NT password hash encrypted 242 with the new Windows NT password hash, as output by the OldNtPass- 243 wordHashEncryptedWithNewNtPasswordHash() routine (see section 244 A.11, below). 246 Peer-Challenge 247 A 16-octet random quantity, as described in the Response packet 248 description. 250 NT-Response 251 The NT-Response field (as described in the Response packet 252 description), but calculated on the new password and the challenge 253 received in the Failure packet. 255 Flags 256 This field is two octets in length. It is a bit field of option 257 flags where 0 is the least significant bit of the 16-bit quantity. 258 The format of this field is illustrated in the following diagram: 260 1 261 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Bits 0-15 267 Reserved, always clear (0). 269 11. Security Considerations 271 As an implementation detail, the authenticator SHOULD limit the number 272 of password retries allowed to make brute-force password guessing 273 attacks more difficult. 275 12. References 277 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 278 July 1994 280 [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol 281 (CHAP)", RFC 1994, August 1996 283 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 284 Levels", BCP 14, RFC 2119, March 1997 286 [4] "Data Encryption Standard (DES)", Federal Information Processing 287 Standard Publication 46-2, National Institute of Standards and 288 Technology, December 1993 290 [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992. 292 [6] RC4 is a proprietary encryption algorithm available under license 293 from RSA Data Security Inc. For licensing information, contact: 294 RSA Data Security, Inc. 295 100 Marine Parkway 296 Redwood City, CA 94065-1031 298 [7] Eastlake, D., et. al., "Randomness Recomnendations for Security", 299 RFC 1750, December 1994 301 [8] "The Unicode Standard, Version 2.0", The Unicode Consortium, Addi- 302 son-Wesley, 1996. ISBN 0-201-48345-9. 304 [9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", draft-ietf- 305 pppext-mschap-00.txt (work in progress), March 1998 307 [10] "DES Modes of Operation", Federal Information Processing Standards 308 Publication 81, National Institute of Standards and Technology, 309 December 1980 311 [11] "Secure Hash Standard", Federal Information Processing Standards 312 Publication 180-1, National Institute of Standards and Technology, 313 April 1995 315 13. Acknowledgements 317 Thanks (in no particular order) to Bruce Johnson (bjohn- 318 son@microsoft.com), Tony Bell (tonybe@microsoft.com), Paul Leach 319 (paulle@microsoft.com, Terence Spies (terences@microsoft.com), Dan Simon 320 (dansimon@microsoft.com), Narendra Gidwani (nareng@microsoft.com), Gur- 321 deep Singh Pall (gurdeep@microsoft.com), Jody Terrill 322 (jodyt@extendsys.com) and Joe Davies (josephd@microsoft.com) for useful 323 suggestions and feedback. 325 14. Chair's Address 327 The PPP Extensions Working Group can be contacted via the current chair: 329 Karl Fox 330 Ascend Communications 331 3518 Riverside Drive 332 Suite 101 333 Columbus, OH 43221 335 Phone: +1 614 326 6841 336 Email: karl@ascend.com 338 15. Author's Address 340 Questions about this memo can also be directed to: 342 Glen Zorn 343 Microsoft Corporation 344 One Microsoft Way 345 Redmond, Washington 98052 347 Phone: +1 425 703 1559 348 FAX: +1 425 936 7329 349 EMail: glennz@microsoft.com 351 16. Expiration Date 353 This memo is filed as and expires 354 on March 23, 1999. 356 Appendix A - Pseudocode 358 The routines mentioned in the text are described in pseudocode below. 360 A.1 GenerateNTResponse() 362 GenerateNTResponse( 363 IN 16-octet AuthenticatorChallenge, 364 IN 16-octet PeerChallenge, 365 IN 0-to-256-char UserName, 366 IN 0-to-256-unicode-char Password, 367 OUT 24-octet Response ) 368 { 369 8-octet Challenge 370 16-octet PasswordHash 372 ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, 373 giving Challenge) 375 NtPasswordHash( Password, giving PasswordHash ) 376 ChallengeResponse( Challenge, PasswordHash, giving Response ) 377 } 379 A.2 ChallengeHash() 381 ChallengeHash( 382 IN 16-octet PeerChallenge, 383 IN 16-octet AuthenticatorChallenge, 384 IN 0-to-256-char UserName, 385 OUT 8-octet Challenge 386 { 388 /* 389 * SHAInit(), SHAUpdate() and SHAFinal() functions are an 390 * implementation of Secure Hash Algorithm (SHA-1) [11]. These are 391 * available in public domain or can be licensed from 392 * RSA Data Security, Inc. 393 */ 395 SHAInit(Context) 396 SHAUpdate(Context, PeerChallenge, 16) 397 SHAUpdate(Context, AuthenticatorChallenge, 16) 399 /* 400 * Only the user name (as presented by the peer and 401 * excluding any prepended domain name) 402 * is used as input to SHAUpdate(). 403 */ 405 SHAUpdate(Context, UserName, strlen(Username)) 406 SHAFinal(Context, Digest) 407 memcpy(Challenge, Digest, 8) 408 } 410 A.3 NtPasswordHash() 411 NtPasswordHash( 412 IN 0-to-256-unicode-char Password, 413 OUT 16-octet PasswordHash ) 414 { 415 /* 416 * Use the MD4 algorithm [5] to irreversibly hash Password 417 * into PasswordHash. Only the password is hashed without 418 * including any terminating 0. 419 */ 420 } 422 A.4 ChallengeResponse() 424 ChallengeResponse( 425 IN 8-octet Challenge, 426 IN 16-octet PasswordHash, 427 OUT 24-octet Response ) 428 { 429 Set ZPasswordHash to PasswordHash zero-padded to 21 octets 431 DesEncrypt( Challenge, 432 1st 7-octets of ZPasswordHash, 433 giving 1st 8-octets of Response ) 435 DesEncrypt( Challenge, 436 2nd 7-octets of ZPasswordHash, 437 giving 2nd 8-octets of Response ) 439 DesEncrypt( Challenge, 440 3rd 7-octets of ZPasswordHash, 441 giving 3rd 8-octets of Response ) 442 } 444 A.5 DesEncrypt() 446 DesEncrypt( 447 IN 8-octet Clear, 448 IN 7-octet Key, 449 OUT 8-octet Cypher ) 450 { 451 /* 452 * Use the DES encryption algorithm [4] in ECB mode [10] 453 * to encrypt Clear into Cypher such that Cypher can 454 * only be decrypted back to Clear by providing Key. 455 * Note that the DES algorithm takes as input a 64-bit 456 * stream where the 8th, 16th, 24th, etc. bits are 457 * parity bits ignored by the encrypting algorithm. 458 * Unless you write your own DES to accept 56-bit input 459 * without parity, you will need to insert the parity bits 460 * yourself. 461 */ 462 } 464 A.6 GenerateAuthenticatorResponse() 466 GenerateAuthenticatorResponse( 467 IN 0-to-256-unicode-char Password, 468 IN 24-octet NT-Response, 469 IN 16-octet PeerChallenge, 470 IN 16-octet AuthenticatorChallenge, 471 IN 0-to-256-unicode-char UserName, 472 OUT 42-octet AuthenticatorResponse ) 473 { 474 16-octet PasswordHash 475 16-octet PasswordHashHash 476 8-octet Challenge 478 /* 479 * "Magic" constants used in response generation 480 */ 482 Magic1[39] = 483 {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, 484 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, 485 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, 486 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74}; 488 Magic2[41] = 489 {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, 490 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, 491 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, 492 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, 493 0x6E}; 495 /* 496 * Hash the password with MD4 497 */ 499 NtPasswordHash( Password, giving PasswordHash ) 501 /* 502 * Now hash the hash 503 */ 505 HashNtPasswordHash( PasswordHash, giving PasswordHashHash) 507 SHAInit(Context) 508 SHAUpdate(Context, PasswordHashHash, 16) 509 SHAUpdate(Context, NTResponse, 24) 510 SHAUpdate(Context, Magic1, 45) 511 SHAFinal(Context, Digest) 513 ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, 514 giving Challenge) 516 SHAInit(Context) 517 SHAUpdate(Context, Digest, 20) 518 SHAUpdate(Context, Challenge, 8) 519 SHAUpdate(Context, Magic2, 48) 520 SHAFinal(Context, Digest) 522 /* 523 * Encode the value of 'Digest' as "S=" followed by 524 * 40 ASCII hexadecimal digits and return it in 525 * AuthenticatorResponse. 526 * For example, 527 * "S=0123456789ABCDEF0123456789ABCDEF01234567" 528 */ 530 } 532 A.7 CheckAuthenticatorResponse() 534 CheckAuthenticatorResponse( 535 IN 0-to-256-unicode-char Password, 536 IN 24-octet NtResponse, 537 IN 16-octet PeerChallenge, 538 IN 16-octet AuthenticatorChallenge, 539 IN 0-to-256-unicode-char UserName, 540 IN 42-octet ReceivedResponse 541 OUT Boolean ResponseOK ) 542 { 544 20-octet MyResponse 546 set ResponseOK = FALSE 547 GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge, 548 AuthenticatorChallenge, UserName, 549 giving MyResponse) 551 if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE 552 return ResponseOK 553 } 555 A.8 NewPasswordEncryptedWithOldNtPasswordHash() 557 datatype-PWBLOCK 558 { 559 256-unicode-char Password 560 4-octets PasswordLength 561 } 563 NewPasswordEncryptedWithOldNtPasswordHash( 564 IN 0-to-256-unicode-char NewPassword, 565 IN 0-to-256-unicode-char OldPassword, 566 OUT datatype-PWBLOCK EncryptedPwBlock ) 567 { 568 NtPasswordHash( OldPassword, giving PasswordHash ) 570 EncryptPwBlockWithPasswordHash( NewPassword, 571 PasswordHash, 572 giving EncryptedPwBlock ) 573 } 575 A.9 EncryptPwBlockWithPasswordHash() 577 EncryptPwBlockWithPasswordHash( 578 IN 0-to-256-unicode-char Password, 579 IN 16-octet PasswordHash, 580 OUT datatype-PWBLOCK PwBlock ) 581 { 583 Fill ClearPwBlock with random octet values 584 PwSize = lstrlenW( Password ) * sizeof( unicode-char ) 585 PwOffset = sizeof( ClearPwBlock.Password ) - PwSize 586 Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password 587 ClearPwBlock.PasswordLength = PwSize 588 Rc4Encrypt( ClearPwBlock, 589 sizeof( ClearPwBlock ), 590 PasswordHash, 591 sizeof( PasswordHash ), 592 giving PwBlock ) 593 } 595 A.10 Rc4Encrypt() 596 Rc4Encrypt( 597 IN x-octet Clear, 598 IN integer ClearLength, 599 IN y-octet Key, 600 IN integer KeyLength, 601 OUT x-octet Cypher ) 602 { 603 /* 604 * Use the RC4 encryption algorithm [6] to encrypt Clear of 605 * length ClearLength octets into a Cypher of the same length 606 * such that the Cypher can only be decrypted back to Clear 607 * by providing a Key of length KeyLength octets. 608 */ 609 } 611 A.11 OldNtPasswordHashEncryptedWithNewNtPasswordHash() 613 OldNtPasswordHashEncryptedWithNewNtPasswordHash( 614 IN 0-to-256-unicode-char NewPassword, 615 IN 0-to-256-unicode-char OldPassword, 616 OUT 16-octet EncryptedPasswordHash ) 617 { 618 NtPasswordHash( OldPassword, giving OldPasswordHash ) 619 NtPasswordHash( NewPassword, giving NewPasswordHash ) 620 NtPasswordHashEncryptedWithBlock( OldPasswordHash, 621 NewPasswordHash, 622 giving EncryptedPasswordHash ) 623 } 625 A.12 NtPasswordHashEncryptedWithBlock() 627 NtPasswordHashEncryptedWithBlock( 628 IN 16-octet PasswordHash, 629 IN 16-octet Block, 630 OUT 16-octet Cypher ) 631 { 632 DesEncrypt( 1st 8-octets PasswordHash, 633 1st 7-octets Block, 634 giving 1st 8-octets Cypher ) 636 DesEncrypt( 2nd 8-octets PasswordHash, 637 2nd 7-octets Block, 638 giving 2nd 8-octets Cypher ) 639 } 641 Appendix B - Examples 642 B.1 Negotiation Examples 644 Here are some examples of typical negotiations. The peer is on the left 645 and the authenticator is on the right. 647 The packet sequence ID is incremented on each authentication retry 648 Response and on the change password response. All cases where the 649 packet sequence ID is updated are noted below. 651 Response retry is never allowed after Change Password. Change Password 652 may occur after Response retry. 654 B.1.1 Successful authentication 656 <- Challenge 657 Response -> 658 <- Success 660 B.1.2 Failed authentication with no retry allowed 662 <- Challenge 663 Response -> 664 <- Failure (E=691 R=0) 666 B.1.3 Successful authentication after retry 668 <- Challenge 669 Response -> 670 <- Failure (E=691 R=1), disable short timeout 671 Response (++ID) to challenge in failure message -> 672 <- Success 674 B.1.4 Failed hack attack with 3 attempts allowed 676 <- Challenge 677 Response -> 678 <- Failure (E=691 R=1), disable short timeout 679 Response (++ID) to challenge in Failure message -> 680 <- Failure (E=691 R=1), disable short timeout 681 Response (++ID) to challenge in Failure message -> 682 <- Failure (E=691 R=0) 684 B.1.5 Successful authentication with password change 685 <- Challenge 686 Response -> 687 <- Failure (E=648 R=0 V=3), disable short timeout 688 ChangePassword (++ID) to challenge in Failure message -> 689 <- Success 691 B.1.6 Successful authentication with retry and password change 693 <- Challenge 694 Response -> 695 <- Failure (E=691 R=1), disable short timeout 696 Response (++ID) to first challenge+23 -> 697 <- Failure (E=648 R=0 V=2), disable short timeout 698 ChangePassword (++ID) to first challenge+23 -> 699 <- Success 701 B.2 Hash Example 703 Intermediate values for user name "User" and password "clientPass". All 704 numeric values are hexadecimal. 706 0-to-256-char UserName: 707 55 73 65 72 709 0-to-256-unicode-char Password: 710 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 712 16-octet AuthenticatorChallenge: 713 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 715 16-octet PeerChallenge: 716 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 718 8-octet Challenge: 719 D0 2E 43 86 BC E9 12 26 721 16-octet PasswordHash: 722 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 724 24 octet NT-Response: 725 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 727 16-octet PasswordHashHash: 728 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 730 42-octet AuthenticatorResponse: 732 "S=407A5589115FD0D6209F510FE9C04566932CDA56" 734 B.3 Example of DES Key Generation 736 DES uses 56-bit keys, expanded to 64 bits by the insertion of parity 737 bits. After the parity of the key has been fixed, every eighth bit is a 738 parity bit and the number of bits that are set (1) in each octet is odd; 739 i.e., odd parity. Note that many DES engines do not check parity, how- 740 ever, simply stripping the parity bits. The following example illus- 741 trates the values resulting from the use of the password "MyPw" to gen- 742 erate a pair of DES keys (e.g., for use in the NtPasswordHashEncrypted- 743 WithBlock() described in Appendix A.12). 745 0-to-256-unicode-char Password: 746 4D 79 50 77 748 16-octet PasswordHash: 749 FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC 751 First "raw" DES key (initial 7 octets of password hash): 752 FC 15 6A F7 ED CD 6C 754 First parity-corrected DES key (eight octets): 755 FD 0B 5B 5E 7F 6E 34 D9 757 Second "raw" DES key (second 7 octets of password hash) 758 0E DD E3 33 7D 42 7F 760 Second parity-corrected DES key (eight octets): 761 0E 6E 79 67 37 EA 08 FE