idnits 2.17.1 draft-ietf-pppext-mschap-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-25) 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 110 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [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...' == (105 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 (March 1998) is 9538 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 ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 391, 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 (~~), 8 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 S. Cobb 4 Category: Informational Microsoft Corporation 5 March 1998 7 Microsoft PPP CHAP Extensions 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 ds.internic.net (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 September 13, 1998. Please send comments to 30 the PPP Extensions Working Group mailing list (ietf-ppp@merit.edu) or to 31 the authors (stevec@microsoft.com and 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 Microsoft's PPP CHAP dialect (MS-CHAP), which 42 extends the user authentication functionality provided on Windows net- 43 works to remote workstations. MS-CHAP is closely derived from the PPP 44 Challenge Handshake Authentication Protocol described in RFC 1994 [2], 45 which the reader should have at hand. 47 The algorithms used in the generation of various MS-CHAP protocol fields 48 are described in an appendix. 50 3. Introduction 52 Microsoft created MS-CHAP to authenticate remote Windows workstations, 53 providing the functionality to which LAN-based users are accustomed 54 while integrating the encryption and hashing algorithms used on Windows 55 networks. 57 Where possible, MS-CHAP is consistent with standard CHAP. Briefly, the 58 differences between MS-CHAP and standard CHAP are: 60 * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP 61 option 3, Authentication Protocol. 63 * The MS-CHAP Response packet is in a format designed for 64 compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and 65 Windows95 networking products. The MS-CHAP format does not require 66 the authenticator to store a clear- text or reversibly encrypted 67 password. 69 * MS-CHAP provides authenticator-controlled authentication retry and 70 password changing mechanisms. 72 * MS-CHAP defines a set of reason-for-failure codes returned in the 73 Failure packet Message field. 75 4. Specification of Requirements 77 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 78 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 79 described in [2]. 81 5. LCP Configuration 83 The LCP configuration for MS-CHAP is identical to that for standard 84 CHAP, except that the Algorithm field has value 0x80, rather than the 85 MD5 value 0x05. PPP implementations which do not support MS-CHAP, but 86 correctly implement LCP Config-Rej, should have no problem dealing with 87 this non-standard option. 89 6. Challenge Packet 91 The MS-CHAP Challenge packet is identical in format to the standard CHAP 92 Challenge packet. 94 MS-CHAP authenticators send an 8-octet challenge Value field. Peers 95 need not duplicate Microsoft's algorithm for selecting the 8-octet 96 value, but the standard guidelines on randomness [1,2,7] SHOULD be 97 observed. 99 Microsoft authenticators do not currently provide information in the 100 Name field. This may change in the future. 102 7. Response Packet 104 The MS-CHAP Response packet is identical in format to the standard CHAP 105 Response packet. However, the Value field is sub-formatted differently 106 as follows: 108 24 octets: LAN Manager compatible challenge response 109 24 octets: Windows NT compatible challenge response 110 1 octet : "Use Windows NT compatible challenge response" flag 112 The LAN Manager compatible challenge response is an encoded function of 113 the password and the received challenge as output by the routine LmChal- 114 lengeResponse() (see section A.1, below). LAN Manager passwords are 115 limited to 14 case-insensitive OEM characters. Note that use of the LAN 116 Manager compatible challenge response has been deprecated; peers SHOULD 117 NOT generate it, and the sub-field SHOULD be zero-filled. The algorithm 118 used in the generation of the LAN Manager compatible challenge response 119 is described here for informational purposes only. 121 The Windows NT compatible challenge response is an encoded function of 122 the password and the received challenge as output by the routine NTChal- 123 lengeResponse() (see section A.5, below). The Windows NT password is a 124 string of 0 to (theoretically) 256 case-sensitive Unicode [8] charac- 125 ters. Current versions of Windows NT limit passwords to 14 characters, 126 mainly for compatibility reasons; this may change in the future. 128 The "use Windows NT compatible challenge response" flag, if 1, indicates 129 that the Windows NT response is provided and should be used in prefer- 130 ence to the LAN Manager response. The LAN Manager response will still 131 be used if the account does not have a Windows NT password hash, e.g. 132 if the password has not been changed since the account was uploaded from 133 a LAN Manager 2.x account database. If the flag is 0, the Windows NT 134 response is ignored and the LAN Manager response is used. Since the use 135 of LAN Manager authentication has been deprecated, this flag SHOULD 136 always be set (1) and the LAN Manager compatible challenge response 137 field SHOULD be zero-filled. 139 The Name field identifies the peer's user account name. The Windows NT 140 domain name may prefix the user's account name (e.g. "BIGCO\johndoe" 141 where "BIGCO" is a Windows NT domain containing the user account "john- 142 doe"). If a domain is not provided, the backslash should also be omit- 143 ted, (e.g. "johndoe"). 145 8. Success Packet 147 The Success packet is identical in format to the standard CHAP Success 148 packet. 150 9. Failure Packet 152 The Failure packet is identical in format to the standard CHAP Failure 153 packet. There is, however, formatted text stored in the Message field 154 which, contrary to the standard CHAP rules, affects the protocol. The 155 Message field format is: 157 "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv" 159 where 161 The "eeeeeeeeee" is the decimal error code (need not be 10 digits) 162 corresponding to one of those listed below, though implementations 163 should deal with codes not on this list gracefully. 165 646 ERROR_RESTRICTED_LOGON_HOURS 166 647 ERROR_ACCT_DISABLED 167 648 ERROR_PASSWD_EXPIRED 168 649 ERROR_NO_DIALIN_PERMISSION 169 691 ERROR_AUTHENTICATION_FAILURE 170 709 ERROR_CHANGING_PASSWORD 172 The "r" is a flag set to "1" if a retry is allowed, and "0" if 173 not. When the authenticator sets this flag to "1" it disables 174 short timeouts, expecting the peer to prompt the user for new cre- 175 dentials and resubmit the response. 177 The "cccccccccccccccc" is 16 hexadecimal digits representing an 178 ASCII representation of a new challenge value. This field is 179 optional. If it is not sent, the authenticator expects the resub- 180 mitted response to be calculated based on the previous challenge 181 value plus decimal 23 in the first octet, i.e. the one immediately 182 following the Value Size field. Windows 95 authenticators may 183 send this field. Windows NT authenticators do not, but may in the 184 future. Both systems implement peer support of this field. 186 The "vvvvvvvvvv" is the decimal version code (need not be 10 dig- 187 its) indicating the MS-CHAP protocol version supported on the 188 server. Currently, this is interesting only in selecting a Change 189 Password packet type. If the field is not present the version 190 should be assumed to be 1; since use of the version 1 Change Pass- 191 word packet has been deprecated, this field SHOULD always contain 192 a value greater than or equal to 2. 194 Implementations should accept but ignore additional text they do not 195 recognize. 197 10. Change Password Packet (version 1) 199 The version 1 Change Password packet does not appear in standard CHAP. 200 It allows the peer to change the password on the account specified in 201 the previous Response packet. The version 1 Change Password packet 202 should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED 203 (E=648) and V is either missing or equal to one in the Message field of 204 the Failure packet. 206 The use of the Change Password Packet (version 1) has been deprecated; 207 the format of the packet is described here for informational purposes, 208 but peers SHOULD NOT transmit it. 210 The format of this packet is as follows: 212 1 octet : Code (=5) 213 1 octet : Identifier 214 2 octets: Length (=72) 215 16 octets: Encrypted LAN Manager Old password Hash 216 16 octets: Encrypted LAN Manager New Password Hash 217 16 octets: Encrypted Windows NT Old Password Hash 218 16 octets: Encrypted Windows NT New Password Hash 219 2 octets: Password Length 220 2 octets: Flags 222 Code 223 5 225 Identifier 226 The Identifier field is one octet and aids in matching requests 227 and replies. The value is the Identifier of the received Failure 228 packet to which this packet responds plus 1. 230 Length 231 72 233 Encrypted LAN Manager New Password Hash 234 Encrypted LAN Manager Old Password Hash 235 These fields contain the LAN Manager password hash of the new and 236 old passwords encrypted with the last received challenge value, as 237 output by the routine LmEncryptedPasswordHash() (see section A.8, 238 below). 240 Encrypted Windows NT New Password Hash 241 Encrypted Windows NT Old Password Hash 242 These fields contain the Windows NT password hash of the new and 243 old passwords encrypted with the last received challenge value, as 244 output by the pseudo-code routine NtEncryptedPasswordHash() (see 245 section A.10, below). 247 Password Length 248 The length in octets of the LAN Manager compatible form of the new 249 password. If this value is greater than or equal to zero and less 250 than or equal to 14 it is assumed that the encrypted LAN Manager 251 password hash fields are valid. Otherwise, it is assumed these 252 fields are not valid, in which case the Windows NT compatible 253 passwords MUST be provided. 255 Flags 256 This field is two octets in length. 257 It is a bit field of option flags where 0 is the least significant bit 258 of the 16-bit quantity: 260 Bit 0 261 If this bit is set (1), it indicates that the encrypted Windows NT 262 hashed passwords are valid and should be used. 263 If this bit is cleared (0), the Windows NT fields are not used and 264 the LAN Manager fields must be provided. 266 Bits 1-15 267 Reserved, always clear (0). 269 11. Change Password Packet (version 2) 271 The version 2 Change Password packet does not appear in standard CHAP. 272 It allows the peer to change the password on the account specified in 273 the preceding Response packet. The version 2 Change Password packet 274 should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED 275 (E=648) and a version of 2 or greater in the Message field of the Fail- 276 ure packet. 278 This packet type is supported by Windows NT 3.51, 4.0 and recent ver- 279 sions of Windows 95. It is not supported by Windows NT 3.5 or early 280 versions of Windows 95. 282 The format of this packet is as follows: 284 1 octet : Code 285 1 octet : Identifier 286 2 octets : Length 287 516 octets : Password Encrypted with Old NT Hash 288 16 octets : Old NT Hash Encrypted with New NT Hash 289 516 octets : Password Encrypted with Old LM Hash 290 16 octets : Old LM Hash Encrypted With New NT Hash 291 24 octets : LAN Manager compatible challenge response 292 24 octets : Windows NT compatible challenge response 293 2-octet : Flags 295 Code 296 6 298 Identifier 299 The Identifier field is one octet and aids in matching requests 300 and replies. The value is the Identifier of the received Failure 301 packet to which this packet responds plus 1. 303 Length 304 1118 306 Password Encrypted with Old NT Hash 307 This field contains the PWBLOCK form of the new Windows NT pass- 308 word encrypted with the old Windows NT password hash, as output by 309 the NewPasswordEncryptedWithOldNtPasswordHash() routine (see sec- 310 tion A.11, below). 312 Old NT Hash Encrypted with New NT Hash 313 This field contains the old Windows NT password hash encrypted 314 with the new Windows NT password hash, as output by the OldNtPass- 315 wordHashEncryptedWithNewNtPasswordHash() routine (see section 316 A.14, below). 318 Password Encrypted with Old LM Hash 319 This field contains the PWBLOCK form of the new Windows NT pass- 320 word encrypted with the old LAN Manager password hash, as output 321 by the NewPasswordEncryptedWithOldLmPasswordHash() routine 322 described in section A.15, below. Note, however, that the use of 323 this field has been deprecated: peers SHOULD NOT generate it, and 324 this field SHOULD be zero-filled. 326 Old LM Hash Encrypted With New NT Hash 327 This field contains the old LAN Manager password hash encrypted 328 with the new Windows NT password hash, as output by the OldLmPass- 329 wordHashEncryptedWithNewNtPasswordHash() routine (see section 330 A.16, below). Note, however, that the use of this field has been 331 deprecated: peers SHOULD NOT generate it, and this field SHOULD be 332 zero-filled. 334 LAN Manager compatible challenge response 335 Windows NT compatible challenge response 336 The challenge response field (as described in the Response packet 337 description), but calculated on the new password and the same 338 challenge used in the last response. Note that use of the LAN 339 Manager compatible challenge response has been deprecated; peers 340 SHOULD NOT generate it, and the field SHOULD be zero-filled. 342 Flags 343 This field is two octets in length. It is a bit field of option 344 flags where 0 is the least significant bit of the 16-bit quantity. 345 The format of this field is illustrated in the following diagram: 347 1 348 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Bit 0 354 The "use Windows NT compatible challenge response" flag as 355 described in the Response packet. 357 Bit 1 358 Set (1) indicates that the "Password Encrypted with Old LM 359 Hash" and "Old LM Hash Encrypted With New NT Hash" fields 360 are valid and should be used. Clear (0) indicates these 361 fields are not valid. This bit SHOULD always be clear (0). 363 Bits 2-15 364 Reserved, always clear (0). 366 12. Security Considerations 368 As an implementation detail, the authenticator SHOULD limit the number 369 of password retries allowed to make brute-force password guessing 370 attacks more difficult. 372 Because the challenge value is encrypted using the password hash to form 373 the response and the challenge is transmitted in clear-text form, both 374 passive known-plaintext and active chosen-plaintext attacks against the 375 password hash are possible. Suitable precautions (i.e., frequent pass- 376 word changes) SHOULD be taken in environments where eavesdropping is 377 likely. 379 The Change Password (version 1) packet is vulnerable to a passive eaves- 380 dropping attack which can easily reveal the new password hash. For this 381 reason, it MUST NOT be sent if eavesdropping is possible. 383 13. References 385 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 386 July 1994 388 [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol 389 (CHAP)", RFC 1994, August 1996 391 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 392 Levels", BCP 14, RFC 2119, March 1997 394 [4] "Data Encryption Standard (DES)", Federal Information Processing 395 Standard Publication 46-2, National Institute of Standards and 396 Technology, December 1993 398 [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992. 400 [6] RC4 is a proprietary encryption algorithm available under license 401 from RSA Data Security Inc. For licensing information, contact: 402 RSA Data Security, Inc. 403 100 Marine Parkway 404 Redwood City, CA 94065-1031 406 [7] Eastlake, D., et. al., "Randomness Recomnendations for Security", 407 RFC 1750, December 1994 409 [8] "The Unicode Standard, Version 2.0", The Unicode Consortium, Addi- 410 son-Wesley, 1996. ISBN 0-201-48345-9. 412 [9] "DES Modes of Operation", Federal Information Processing Standards 413 Publication 81, National Institute of Standards and Technology, 414 December 1980 416 14. Acknowledgements 418 Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com), Bill 419 Palter (palter@network-alchemy.com), Bruce Johnson (bjohn- 420 son@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit Martin 421 (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com) for useful 422 suggestions and feedback. 424 15. Chair's Address 426 The PPP Extensions Working Group can be contacted via the current chair: 428 Karl Fox 429 Ascend Communications 430 3518 Riverside Drive 431 Suite 101 432 Columbus, OH 43221 434 Phone: +1 614 326 6841 435 Email: karl@ascend.com 437 16. Authors' Addresses 439 Questions about this memo can also be directed to: 441 Glen Zorn 442 Microsoft Corporation 443 One Microsoft Way 444 Redmond, Washington 98052 446 Phone: +1 425 703 1559 447 FAX: +1 425 936 7329 448 EMail: glennz@microsoft.com 450 Steve Cobb 451 Microsoft Corporation 452 One Microsoft Way 453 Redmond, Washington 98052 455 EMail: stevec@microsoft.com 457 17. Expiration Date 459 This memo is filed as and expires on 460 September 13, 1998. 462 Appendix A - Pseudocode 464 The routines mentioned in the text are described in pseudocode below. 466 A.1 LmChallengeResponse() 468 LmChallengeResponse( 469 IN 8-octet Challenge, 470 IN 0-to-14-oem-char Password, 471 OUT 24-octet Response ) 472 { 473 LmPasswordHash( Password, giving PasswordHash ) 474 ChallengeResponse( Challenge, PasswordHash, giving Response ) 475 } 477 A.2 LmPasswordHash() 479 LmPasswordHash( 480 IN 0-to-14-oem-char Password, 481 OUT 16-octet PasswordHash ) 482 { 483 Set UcasePassword to the uppercased Password 484 Zero pad UcasePassword to 14 characters 486 DesHash( 1st 7-octets of UcasePassword, 487 giving 1st 8-octets of PasswordHash ) 489 DesHash( 2nd 7-octets of UcasePassword, 490 giving 2nd 8-octets of PasswordHash ) 491 } 493 A.3 DesHash() 495 DesHash( 496 IN 7-octet Clear, 497 OUT 8-octet Cypher ) 498 { 499 /* 500 * Make Cypher an irreversibly encrypted form of Clear by 501 * encrypting known text using Clear as the secret key. 502 * The known text consists of the string 503 * 504 * KGS!@#$% 505 */ 507 Set StdText to "KGS!@#$%" 509 DesEncrypt( StdText, Clear, giving Cypher ) 510 } 512 A.4 DesEncrypt() 514 DesEncrypt( 515 IN 8-octet Clear, 516 IN 7-octet Key, 517 OUT 8-octet Cypher ) 518 { 519 /* 520 * Use the DES encryption algorithm [4] in ECB mode [9] 521 * to encrypt Clear into Cypher such that Cypher can 522 * only be decrypted back to Clear by providing Key. 523 * Note that the DES algorithm takes as input a 64-bit 524 * stream where the 8th, 16th, 24th, etc. bits are 525 * parity bits ignored by the encrypting algorithm. 526 * Unless you write your own DES to accept 56-bit input 527 * without parity, you will need to insert the parity bits 528 * yourself. 529 */ 530 } 532 A.5 NtChallengeResponse() 534 NtChallengeResponse( 535 IN 8-octet Challenge, 536 IN 0-to-256-unicode-char Password, 537 OUT 24-octet Response ) 538 { 539 NtPasswordHash( Password, giving PasswordHash ) 540 ChallengeResponse( Challenge, PasswordHash, giving Response ) 541 } 543 A.6 NtPasswordHash() 544 NtPasswordHash( 545 IN 0-to-256-unicode-char Password, 546 OUT 16-octet PasswordHash ) 547 { 548 /* 549 * Use the MD4 algorithm [5] to irreversibly hash Password 550 * into PasswordHash. Only the password is hashed without 551 * including any terminating 0. 552 */ 553 } 555 A.7 ChallengeResponse() 557 ChallengeResponse( 558 IN 8-octet Challenge, 559 IN 16-octet PasswordHash, 560 OUT 24-octet Response ) 561 { 562 Set ZPasswordHash to PasswordHash zero-padded to 21 octets 564 DesEncrypt( Challenge, 565 1st 7-octets of ZPasswordHash, 566 giving 1st 8-octets of Response ) 568 DesEncrypt( Challenge, 569 2nd 7-octets of ZPasswordHash, 570 giving 2nd 8-octets of Response ) 572 DesEncrypt( Challenge, 573 3rd 7-octets of ZPasswordHash, 574 giving 3rd 8-octets of Response ) 575 } 577 A.8 LmEncryptedPasswordHash() 579 LmEncryptedPasswordHash( 580 IN 0-to-14-oem-char Password, 581 IN 8-octet KeyValue, 582 OUT 16-octet Cypher ) 583 { 584 LmPasswordHash( Password, giving PasswordHash ) 586 PasswordHashEncryptedWithBlock( PasswordHash, 587 KeyValue, 588 giving Cypher ) 589 } 591 A.9 PasswordHashEncryptedWithBlock() 593 PasswordHashEncryptedWithBlock( 594 IN 16-octet PasswordHash, 595 IN 8-octet Block, 596 OUT 16-octet Cypher ) 597 { 598 DesEncrypt( 1st 8-octets PasswordHash, 599 1st 7-octets Block, 600 giving 1st 8-octets Cypher ) 602 DesEncrypt( 2nd 8-octets PasswordHash, 603 1st 7-octets Block, 604 giving 2nd 8-octets Cypher ) 605 } 607 A.10 NtEncryptedPasswordHash() 609 NtEncryptedPasswordHash( IN 0-to-14-oem-char Password IN 8-octet 610 Challenge OUT 16-octet Cypher ) { 611 NtPasswordHash( Password, giving PasswordHash ) 613 PasswordHashEncryptedWithBlock( PasswordHash, 614 Challenge, 615 giving Cypher ) 616 } 618 A.11 NewPasswordEncryptedWithOldNtPasswordHash() 620 datatype-PWBLOCK 621 { 622 256-unicode-char Password 623 4-octets PasswordLength 624 } 626 NewPasswordEncryptedWithOldNtPasswordHash( 627 IN 0-to-256-unicode-char NewPassword, 628 IN 0-to-256-unicode-char OldPassword, 629 OUT datatype-PWBLOCK EncryptedPwBlock ) 630 { 631 NtPasswordHash( OldPassword, giving PasswordHash ) 633 EncryptPwBlockWithPasswordHash( NewPassword, 634 PasswordHash, 635 giving EncryptedPwBlock ) 636 } 638 A.12 EncryptPwBlockWithPasswordHash() 640 EncryptPwBlockWithPasswordHash( 641 IN 0-to-256-unicode-char Password, 642 IN 16-octet PasswordHash, 643 OUT datatype-PWBLOCK PwBlock ) 644 { 646 Fill ClearPwBlock with random octet values 647 PwSize = lstrlenW( Password ) * sizeof( unicode-char ) 648 PwOffset = sizeof( ClearPwBlock.Password ) - PwSize 649 Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password 650 ClearPwBlock.PasswordLength = PwSize 651 Rc4Encrypt( ClearPwBlock, 652 sizeof( ClearPwBlock ), 653 PasswordHash, 654 sizeof( PasswordHash ), 655 giving PwBlock ) 656 } 658 A.13 Rc4Encrypt() 660 Rc4Encrypt( 661 IN x-octet Clear, 662 IN integer ClearLength, 663 IN y-octet Key, 664 IN integer KeyLength, 665 OUT x-octet Cypher ) 666 { 667 /* 668 * Use the RC4 encryption algorithm [6] to encrypt Clear of 669 * length ClearLength octets into a Cypher of the same length 670 * such that the Cypher can only be decrypted back to Clear 671 * by providing a Key of length KeyLength octets. 672 */ 673 } 675 A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash() 677 OldNtPasswordHashEncryptedWithNewNtPasswordHash( 678 IN 0-to-256-unicode-char NewPassword, 679 IN 0-to-256-unicode-char OldPassword, 680 OUT 16-octet EncryptedPasswordHash ) 681 { 682 NtPasswordHash( OldPassword, giving OldPasswordHash ) 683 NtPasswordHash( NewPassword, giving NewPasswordHash ) 684 NtPasswordHashEncryptedWithBlock( OldPasswordHash, 685 NewPasswordHash, 686 giving EncryptedPasswordHash ) 687 } 689 A.15 NewPasswordEncryptedWithOldLmPasswordHash() 691 NewPasswordEncryptedWithOldLmPasswordHash( 692 IN 0-to-256-unicode-char NewPassword, 693 IN 0-to-256-unicode-char OldPassword, 694 OUT datatype-PWBLOCK EncryptedPwBlock ) 695 { 696 LmPasswordHash( OldPassword, giving PasswordHash ) 698 EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash, 699 giving EncryptedPwBlock ) 700 } 702 A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash() 704 OldLmPasswordHashEncryptedWithNewNtPasswordHash( 705 IN 0-to-256-unicode-char NewPassword, 706 IN 0-to-256-unicode-char OldPassword, 707 OUT 16-octet EncryptedPasswordHash ) 708 { 709 LmPasswordHash( OldPassword, giving OldPasswordHash ) 711 NtPasswordHash( NewPassword, giving NewPasswordHash ) 713 NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash, 714 giving EncrytptedPasswordHash ) 715 } 717 A.17 NtPasswordHashEncryptedWithBlock() 719 NtPasswordHashEncryptedWithBlock( 720 IN 16-octet PasswordHash, 721 IN 16-octet Block, 722 OUT 16-octet Cypher ) 723 { 724 DesEncrypt( 1st 8-octets PasswordHash, 725 1st 7-octets Block, 726 giving 1st 8-octets Cypher ) 728 DesEncrypt( 2nd 8-octets PasswordHash, 729 2nd 7-octets Block, 730 giving 2nd 8-octets Cypher ) 731 } 733 Appendix B - Examples 735 B.1 Negotiation Examples 737 Here are some examples of typical negotiations. The peer is on the left 738 and the authenticator is on the right. 740 The packet sequence ID is incremented on each authentication retry 741 Response and on the change password response. All cases where the 742 packet sequence ID is updated are noted below. 744 Response retry is never allowed after Change Password. Change Password 745 may occur after Response retry. The implied challenge form is shown in 746 the examples, though all cases of "first challenge+23" should be 747 replaced by the "C=cccccccccccccccc" challenge if authenticator supplies 748 it in the Failure packet. 750 B.1.1 Successful authentication 752 <- Challenge 753 Response -> 754 <- Success 756 B.1.2 Failed authentication with no retry allowed 758 <- Challenge 759 Response -> 760 <- Failure (E=691 R=0) 762 B.1.3 Successful authentication after retry 764 <- Challenge 765 Response -> 766 <- Failure (E=691 R=1), disable short timeout 767 Response (++ID) to first challenge+23 -> 768 <- Success 770 B.1.4 Failed hack attack with 3 attempts allowed 772 <- Challenge 774 Response -> 775 <- Failure (E=691 R=1), disable short timeout 776 Response (++ID) to first challenge+23 -> 777 <- Failure (E=691 R=1), disable short timeout 778 Response (++ID) to first challenge+23+23 -> 779 <- Failure (E=691 R=0) 781 B.1.5 Successful authentication with password change 783 <- Challenge 784 Response -> 785 <- Failure (E=648 R=0 V=2), disable short timeout 786 ChangePassword (++ID) to first challenge -> 787 <- Success 789 B.1.6 Successful authentication with retry and password change 791 <- Challenge 792 Response -> 793 <- Failure (E=691 R=1), disable short timeout 794 Response (++ID) to first challenge+23 -> 795 <- Failure (E=648 R=0 V=2), disable short timeout 796 ChangePassword (++ID) to first challenge+23 -> 797 <- Success 799 B.2 Hash Example 801 Intermediate values for password "MyPw". 803 8-octet Challenge: 804 10 2D B5 DF 08 5D 30 41 806 0-to-256-unicode-char NtPassword: 807 4D 00 79 00 50 00 77 00 809 16-octet NtPasswordHash: 810 FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC 812 24-octet NtChallengeResponse: 813 4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C 814 A4 C3 51 AB 40 9A 3D 61 816 B.3 Example of DES Key Generation 818 DES uses 56-bit keys, expanded to 64 bits by the insertion of parity 819 bits. After the parity of the key has been fixed, every eighth bit is a 820 parity bit and the number of bits that are set (1) in each octet is odd; 821 i.e., odd parity. Note that many DES engines do not check parity, how- 822 ever, simply stripping the parity bits. The following example illus- 823 trates the values resulting from the use of the 16-octet NTPasswordHash 824 shown in Appendix B.2 to generate a pair of DES keys (e.g., for use in 825 the NtPasswordHashEncryptedWithBlock() described in Appendix A.17). 827 16-octet NtPasswordHash: 828 FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC 830 First "raw" DES key (initial 7 octets of password hash): 831 FC 15 6A F7 ED CD 6C 833 First parity-corrected DES key (eight octets): 834 FD 0B 5B 5E 7F 6E 34 D9 836 Second "raw" DES key (second 7 octets of password hash) 837 0E DD E3 33 7D 42 7F 839 Second parity-corrected DES key (eight octets): 840 0E 6E 79 67 37 EA 08 FE