idnits 2.17.1 draft-ietf-pppext-mschap-v2-02.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 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: ---------------------------------------------------------------------------- == 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 (November 1998) is 9293 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 399, but not defined == Missing Reference: '41' is mentioned on line 405, but not defined == Unused Reference: '3' is defined on line 694, 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: 14 errors (**), 0 flaws (~~), 4 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 November 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 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents 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 May 20, 1999. Please send comments to the PPP 30 Extensions Working Group mailing list (ietf-ppp@merit.edu) or to the 31 author (gwz@acm.org). 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 38 Control Protocols (NCPs) for establishing and configuring different 39 network-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 43 version one (MS-CHAP-V1, described in [9]). In particular, certain 44 protocol fields have been deleted or reused but with different 45 semantics. In 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 53 standard CHAP. Briefly, the differences between MS-CHAP-V2 and MS-CHAP- 54 V1 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 109 differently as follows: 111 16 octets: Peer-Challenge 112 8 octets: Reserved, must be zero 113 24 octets: NT-Response 114 1 octet : Flags 116 The Peer-Challenge field is a 16-octet random number. As the name 117 implies, it is generated by the peer and is used in the calculation of 118 the NT-Response field, below. Peers need not duplicate Microsoft's 119 algorithm for selecting the 16-octet value, but the standard guidelines 120 on randomness [1,2,7] SHOULD be observed. 122 The NT-Response field is an encoded function of the password, the user 123 name, the contents of the Peer-Challenge field and the received 124 challenge as output by the routine GenerateNTResponse() (see section 125 A.1, below). The Windows NT password is a string of 0 to 126 (theoretically) 256 case-sensitive Unicode [8] characters. Current 127 versions of Windows NT limit passwords to 14 characters, mainly for 128 compatibility reasons; this may change in the future. When computing 129 the NT-Response field contents, only the user name is used, without any 130 associated Windows NT domain name. This is true regardless of whether a 131 Windows NT domain name is present in the Name field (see below). 133 The Flag field is reserved for future use and MUST be zero. 135 The Name field is a string of 0 to (theoretically) 256 case-sensitive 136 ASCII characters which identifies the peer's user account name. The 137 Windows NT domain name may prefix the user's account name (e.g. 138 "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the user 139 account "johndoe"). If a domain is not provided, the backslash should 140 also be omitted, (e.g. "johndoe"). 142 8. Success Packet 144 The Success packet is identical in format to the standard CHAP Success 145 packet. However, the Message field contains a 42-octet authenticator 146 response string of the form 148 "S=" 150 where is a 20 octet number encoded in ASCII as 40 151 hexadecimal digits. The hexadecimal digits A-F (if present) MUST be 152 uppercase. This number is derived from the challenge from the Challenge 153 packet, the Peer-Challenge and NT-Response fields from the Response 154 packet, and the peer password as output by the routine 155 GenerateAuthenticatorResponse() (see section A.6, below). The 156 authenticating peer MUST verify the authenticator response when a 157 Success packet is received. The method for verifying the authenticator 158 is described in section A.7, below. If the authenticator response is 159 either missing or incorrect, the peer MUST end the session. 161 9. Failure Packet 163 The Failure packet is identical in format to the standard CHAP Failure 164 packet. There is, however, formatted text stored in the Message field 165 which, contrary to the standard CHAP rules, does affect the operation of 166 the protocol. The Message field format is: 168 "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv" 170 where 172 The "eeeeeeeeee" is the ASCII representation of a decimal error 173 code (need not be 10 digits) corresponding to one of those listed 174 below, though implementations should deal with codes not on this 175 list gracefully. 177 646 ERROR_RESTRICTED_LOGON_HOURS 178 647 ERROR_ACCT_DISABLED 179 648 ERROR_PASSWD_EXPIRED 180 649 ERROR_NO_DIALIN_PERMISSION 181 691 ERROR_AUTHENTICATION_FAILURE 182 709 ERROR_CHANGING_PASSWORD 184 The "r" is an ASCII flag set to '1' if a retry is allowed, and '0' 185 if not. When the authenticator sets this flag to '1' it disables 186 short timeouts, expecting the peer to prompt the user for new 187 credentials and resubmit the response. 189 The "cccccccccccccccccccccccccccccccc" is the ASCII representation 190 of a hexadecimal challenge value. This field MUST be exactly 32 191 octets long and MUST be present. 193 The "vvvvvvvvvv" is the ASCII representation of a decimal version 194 code (need not be 10 digits) indicating the password changing 195 protocol version supported on the server. For MS-CHAP-V2, this 196 value SHOULD always be 3. 198 Implementations should accept but ignore additional text they do not 199 recognize. 201 10. Change-Password Packet 203 The Change-Password packet does not appear in either standard CHAP or 204 MS-CHAP-V1. It allows the peer to change the password on the account 205 specified in the preceding Response packet. The Change-Password packet 206 should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED 207 (E=648) in the Message field of the Failure packet. 209 This packet type is supported by recent versions of Windows NT 4.0, 210 Windows 95 and Windows 98. It is not supported by Windows NT 3.5, 211 Windows NT 3.51, or early versions of Windows NT 4.0, Windows 95 and 212 Windows 98. 214 The format of this packet is as follows: 216 1 octet : Code 217 1 octet : Identifier 218 2 octets : Length 219 516 octets : Encrypted-Password 220 16 octets : Encrypted-Hash 221 24 octets : Peer-Challenge 222 24 octets : NT-Response 223 2-octet : Flags 225 Code 226 7 228 Identifier 229 The Identifier field is one octet and aids in matching requests 230 and replies. The value is the Identifier of the received Failure 231 packet to which this packet responds plus 1. 233 Length 234 586 236 Encrypted-Password 237 This field contains the PWBLOCK form of the new Windows NT 238 password encrypted with the old Windows NT password hash, as 239 output by the NewPasswordEncryptedWithOldNtPasswordHash() routine 240 (see section A.8, below). 242 Encrypted-Hash 243 This field contains the old Windows NT password hash encrypted 244 with the new Windows NT password hash, as output by the 245 OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see 246 section A.11, below). 248 Peer-Challenge 249 A 16-octet random quantity, as described in the Response packet 250 description. 252 NT-Response 253 The NT-Response field (as described in the Response packet 254 description), but calculated on the new password and the challenge 255 received in the Failure packet. 257 Flags 258 This field is two octets in length. It is a bit field of option 259 flags where 0 is the least significant bit of the 16-bit quantity. 260 The format of this field is illustrated in the following diagram: 262 1 263 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Bits 0-15 269 Reserved, always clear (0). 271 11. Pseudocode 273 The routines mentioned in the text above are described in pseudocode in 274 the following sections. 276 11.1. GenerateNTResponse() 278 GenerateNTResponse( 279 IN 16-octet AuthenticatorChallenge, 280 IN 16-octet PeerChallenge, 281 IN 0-to-256-char UserName, 282 IN 0-to-256-unicode-char Password, 283 OUT 24-octet Response ) 284 { 285 8-octet Challenge 286 16-octet PasswordHash 288 ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, 289 giving Challenge) 291 NtPasswordHash( Password, giving PasswordHash ) 292 ChallengeResponse( Challenge, PasswordHash, giving Response ) 293 } 295 11.2. ChallengeHash() 297 ChallengeHash( 298 IN 16-octet PeerChallenge, 299 IN 16-octet AuthenticatorChallenge, 300 IN 0-to-256-char UserName, 301 OUT 8-octet Challenge 302 { 304 /* 305 * SHAInit(), SHAUpdate() and SHAFinal() functions are an 306 * implementation of Secure Hash Algorithm (SHA-1) [11]. These are 307 * available in public domain or can be licensed from 308 * RSA Data Security, Inc. 309 */ 311 SHAInit(Context) 312 SHAUpdate(Context, PeerChallenge, 16) 313 SHAUpdate(Context, AuthenticatorChallenge, 16) 315 /* 316 * Only the user name (as presented by the peer and 317 * excluding any prepended domain name) 318 * is used as input to SHAUpdate(). 319 */ 321 SHAUpdate(Context, UserName, strlen(Username)) 322 SHAFinal(Context, Digest) 323 memcpy(Challenge, Digest, 8) 324 } 326 11.3. NtPasswordHash() 328 NtPasswordHash( 329 IN 0-to-256-unicode-char Password, 330 OUT 16-octet PasswordHash ) 331 { 332 /* 333 * Use the MD4 algorithm [5] to irreversibly hash Password 334 * into PasswordHash. Only the password is hashed without 335 * including any terminating 0. 336 */ 337 } 339 11.4. ChallengeResponse() 341 ChallengeResponse( 342 IN 8-octet Challenge, 343 IN 16-octet PasswordHash, 344 OUT 24-octet Response ) 345 { 346 Set ZPasswordHash to PasswordHash zero-padded to 21 octets 348 DesEncrypt( Challenge, 349 1st 7-octets of ZPasswordHash, 350 giving 1st 8-octets of Response ) 352 DesEncrypt( Challenge, 353 2nd 7-octets of ZPasswordHash, 354 giving 2nd 8-octets of Response ) 356 DesEncrypt( Challenge, 357 3rd 7-octets of ZPasswordHash, 358 giving 3rd 8-octets of Response ) 359 } 361 11.5. DesEncrypt() 363 DesEncrypt( 364 IN 8-octet Clear, 365 IN 7-octet Key, 366 OUT 8-octet Cypher ) 367 { 368 /* 369 * Use the DES encryption algorithm [4] in ECB mode [10] 370 * to encrypt Clear into Cypher such that Cypher can 371 * only be decrypted back to Clear by providing Key. 372 * Note that the DES algorithm takes as input a 64-bit 373 * stream where the 8th, 16th, 24th, etc. bits are 374 * parity bits ignored by the encrypting algorithm. 375 * Unless you write your own DES to accept 56-bit input 376 * without parity, you will need to insert the parity bits 377 * yourself. 378 */ 379 } 381 11.6. GenerateAuthenticatorResponse() 383 GenerateAuthenticatorResponse( 384 IN 0-to-256-unicode-char Password, 385 IN 24-octet NT-Response, 386 IN 16-octet PeerChallenge, 387 IN 16-octet AuthenticatorChallenge, 388 IN 0-to-256-char UserName, 389 OUT 42-octet AuthenticatorResponse ) 390 { 391 16-octet PasswordHash 392 16-octet PasswordHashHash 393 8-octet Challenge 395 /* 396 * "Magic" constants used in response generation 397 */ 399 Magic1[39] = 400 {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, 401 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, 402 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, 403 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74}; 405 Magic2[41] = 406 {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, 407 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, 408 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, 409 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, 410 0x6E}; 412 /* 413 * Hash the password with MD4 414 */ 416 NtPasswordHash( Password, giving PasswordHash ) 418 /* 419 * Now hash the hash 420 */ 422 HashNtPasswordHash( PasswordHash, giving PasswordHashHash) 424 SHAInit(Context) 425 SHAUpdate(Context, PasswordHashHash, 16) 426 SHAUpdate(Context, NTResponse, 24) 427 SHAUpdate(Context, Magic1, 39) 428 SHAFinal(Context, Digest) 430 ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, 431 giving Challenge) 433 SHAInit(Context) 434 SHAUpdate(Context, Digest, 20) 435 SHAUpdate(Context, Challenge, 8) 436 SHAUpdate(Context, Magic2, 41) 437 SHAFinal(Context, Digest) 439 /* 440 * Encode the value of 'Digest' as "S=" followed by 441 * 40 ASCII hexadecimal digits and return it in 442 * AuthenticatorResponse. 443 * For example, 444 * "S=0123456789ABCDEF0123456789ABCDEF01234567" 445 */ 447 } 449 11.7. CheckAuthenticatorResponse() 451 CheckAuthenticatorResponse( 452 IN 0-to-256-unicode-char Password, 453 IN 24-octet NtResponse, 454 IN 16-octet PeerChallenge, 455 IN 16-octet AuthenticatorChallenge, 456 IN 0-to-256-char UserName, 457 IN 42-octet ReceivedResponse, 458 OUT Boolean ResponseOK ) 459 { 461 20-octet MyResponse 462 set ResponseOK = FALSE 463 GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge, 464 AuthenticatorChallenge, UserName, 465 giving MyResponse) 467 if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE 468 return ResponseOK 469 } 471 11.8. NewPasswordEncryptedWithOldNtPasswordHash() 473 datatype-PWBLOCK 474 { 475 256-unicode-char Password 476 4-octets PasswordLength 477 } 479 NewPasswordEncryptedWithOldNtPasswordHash( 480 IN 0-to-256-unicode-char NewPassword, 481 IN 0-to-256-unicode-char OldPassword, 482 OUT datatype-PWBLOCK EncryptedPwBlock ) 483 { 484 NtPasswordHash( OldPassword, giving PasswordHash ) 486 EncryptPwBlockWithPasswordHash( NewPassword, 487 PasswordHash, 488 giving EncryptedPwBlock ) 489 } 491 11.9. EncryptPwBlockWithPasswordHash() 493 EncryptPwBlockWithPasswordHash( 494 IN 0-to-256-unicode-char Password, 495 IN 16-octet PasswordHash, 496 OUT datatype-PWBLOCK PwBlock ) 497 { 499 Fill ClearPwBlock with random octet values 500 PwSize = lstrlenW( Password ) * sizeof( unicode-char ) 501 PwOffset = sizeof( ClearPwBlock.Password ) - PwSize 502 Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password 503 ClearPwBlock.PasswordLength = PwSize 504 Rc4Encrypt( ClearPwBlock, 505 sizeof( ClearPwBlock ), 506 PasswordHash, 507 sizeof( PasswordHash ), 508 giving PwBlock ) 509 } 511 11.10. Rc4Encrypt() 513 Rc4Encrypt( 514 IN x-octet Clear, 515 IN integer ClearLength, 516 IN y-octet Key, 517 IN integer KeyLength, 518 OUT x-octet Cypher ) 519 { 520 /* 521 * Use the RC4 encryption algorithm [6] to encrypt Clear of 522 * length ClearLength octets into a Cypher of the same length 523 * such that the Cypher can only be decrypted back to Clear 524 * by providing a Key of length KeyLength octets. 525 */ 526 } 528 11.11. OldNtPasswordHashEncryptedWithNewNtPasswordHash() 530 OldNtPasswordHashEncryptedWithNewNtPasswordHash( 531 IN 0-to-256-unicode-char NewPassword, 532 IN 0-to-256-unicode-char OldPassword, 533 OUT 16-octet EncryptedPasswordHash ) 534 { 535 NtPasswordHash( OldPassword, giving OldPasswordHash ) 536 NtPasswordHash( NewPassword, giving NewPasswordHash ) 537 NtPasswordHashEncryptedWithBlock( OldPasswordHash, 538 NewPasswordHash, 539 giving EncryptedPasswordHash ) 540 } 542 11.12. NtPasswordHashEncryptedWithBlock() 544 NtPasswordHashEncryptedWithBlock( 545 IN 16-octet PasswordHash, 546 IN 16-octet Block, 547 OUT 16-octet Cypher ) 548 { 549 DesEncrypt( 1st 8-octets PasswordHash, 550 1st 7-octets Block, 551 giving 1st 8-octets Cypher ) 553 DesEncrypt( 2nd 8-octets PasswordHash, 554 2nd 7-octets Block, 555 giving 2nd 8-octets Cypher ) 556 } 558 12. Examples 560 12.1. Negotiation Examples 562 Here are some examples of typical negotiations. The peer is on the left 563 and the authenticator is on the right. 565 The packet sequence ID is incremented on each authentication retry 566 Response and on the change password response. All cases where the 567 packet sequence ID is updated are noted below. 569 Response retry is never allowed after Change Password. Change Password 570 may occur after Response retry. 572 12.1.1. Successful authentication 574 <- Challenge 575 Response -> 576 <- Success 578 12.1.2. Failed authentication with no retry allowed 580 <- Challenge 581 Response -> 582 <- Failure (E=691 R=0) 584 12.1.3. Successful authentication after retry 586 <- Challenge 587 Response -> 588 <- Failure (E=691 R=1), disable short timeout 589 Response (++ID) to challenge in failure message -> 590 <- Success 592 12.1.4. Failed hack attack with 3 attempts allowed 594 <- Challenge 595 Response -> 596 <- Failure (E=691 R=1), disable short timeout 597 Response (++ID) to challenge in Failure message -> 598 <- Failure (E=691 R=1), disable short timeout 599 Response (++ID) to challenge in Failure message -> 600 <- Failure (E=691 R=0) 602 12.1.5. Successful authentication with password change 604 <- Challenge 605 Response -> 606 <- Failure (E=648 R=0 V=3), disable short timeout 607 ChangePassword (++ID) to challenge in Failure message -> 608 <- Success 610 12.1.6. Successful authentication with retry and password change 612 <- Challenge 613 Response -> 614 <- Failure (E=691 R=1), disable short timeout 615 Response (++ID) to first challenge+23 -> 616 <- Failure (E=648 R=0 V=2), disable short timeout 617 ChangePassword (++ID) to first challenge+23 -> 618 <- Success 620 12.2. Hash Example 622 Intermediate values for user name "User" and password "clientPass". All 623 numeric values are hexadecimal. 625 0-to-256-char UserName: 626 55 73 65 72 628 0-to-256-unicode-char Password: 629 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 631 16-octet AuthenticatorChallenge: 632 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 634 16-octet PeerChallenge: 635 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E 636 8-octet Challenge: 637 D0 2E 43 86 BC E9 12 26 639 16-octet PasswordHash: 640 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 642 24 octet NT-Response: 643 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF 645 16-octet PasswordHashHash: 646 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 648 42-octet AuthenticatorResponse: 649 "S=407A5589115FD0D6209F510FE9C04566932CDA56" 651 12.3. Example of DES Key Generation 653 DES uses 56-bit keys, expanded to 64 bits by the insertion of parity 654 bits. After the parity of the key has been fixed, every eighth bit is a 655 parity bit and the number of bits that are set (1) in each octet is odd; 656 i.e., odd parity. Note that many DES engines do not check parity, 657 however, simply stripping the parity bits. The following example 658 illustrates the values resulting from the use of the password "MyPw" to 659 generate a pair of DES keys (e.g., for use in the 660 NtPasswordHashEncryptedWithBlock() described in Appendix A.12). 662 0-to-256-unicode-char Password: 663 4D 79 50 77 665 16-octet PasswordHash: 666 FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC 668 First "raw" DES key (initial 7 octets of password hash): 669 FC 15 6A F7 ED CD 6C 671 First parity-corrected DES key (eight octets): 672 FD 0B 5B 5E 7F 6E 34 D9 674 Second "raw" DES key (second 7 octets of password hash) 675 0E DD E3 33 7D 42 7F 677 Second parity-corrected DES key (eight octets): 678 0E 6E 79 67 37 EA 08 FE 680 13. Security Considerations 682 As an implementation detail, the authenticator SHOULD limit the number 683 of password retries allowed to make brute-force password guessing 684 attacks more difficult. 686 14. References 688 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 689 July 1994 691 [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol 692 (CHAP)", RFC 1994, August 1996 694 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 695 Levels", BCP 14, RFC 2119, March 1997 697 [4] "Data Encryption Standard (DES)", Federal Information Processing 698 Standard Publication 46-2, National Institute of Standards and 699 Technology, December 1993 701 [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992. 703 [6] RC4 is a proprietary encryption algorithm available under license 704 from RSA Data Security Inc. For licensing information, contact: 705 RSA Data Security, Inc. 706 100 Marine Parkway 707 Redwood City, CA 94065-1031 709 [7] Eastlake, D., et. al., "Randomness Recomnendations for Security", 710 RFC 1750, December 1994 712 [8] "The Unicode Standard, Version 2.0", The Unicode Consortium, 713 Addison-Wesley, 1996. ISBN 0-201-48345-9. 715 [9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", draft-ietf- 716 pppext-mschap-00.txt (work in progress), March 1998 718 [10] "DES Modes of Operation", Federal Information Processing Standards 719 Publication 81, National Institute of Standards and Technology, 720 December 1980 722 [11] "Secure Hash Standard", Federal Information Processing Standards 723 Publication 180-1, National Institute of Standards and Technology, 724 April 1995 726 15. Acknowledgements 728 Thanks (in no particular order) to Bruce Johnson 729 (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Paul Leach 730 (paulle@microsoft.com, Terence Spies (terences@microsoft.com), Dan Simon 731 (dansimon@microsoft.com), Narendra Gidwani (nareng@microsoft.com), 732 Gurdeep Singh Pall (gurdeep@microsoft.com), Jody Terrill 733 (jodyt@extendsys.com), Brad Robel-Forrest (brad@watchguard.com) and Joe 734 Davies (josephd@microsoft.com) for useful suggestions and feedback. 736 16. Chair's Address 738 The PPP Extensions Working Group can be contacted via the current chair: 740 Karl Fox 741 Ascend Communications 742 3518 Riverside Drive 743 Suite 101 744 Columbus, OH 43221 746 Phone: +1 614 326 6841 747 Email: karl@ascend.com 749 17. Author's Address 751 Questions about this memo can also be directed to: 753 Glen Zorn 754 Microsoft Corporation 755 One Microsoft Way 756 Redmond, Washington 98052 758 Phone: +1 425 703 1559 759 FAX: +1 425 936 7329 760 EMail: gwz@acm.org 762 18. Expiration Date 764 This memo is filed as and expires 765 on May 20, 1999.