doc/rfc/rfc2759.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            G. Zorn
   8 Request for Comments: 2759                         Microsoft Corporation
   9 Category: Informational                                     January 2000
  10
  11
  12                 Microsoft PPP CHAP Extensions, Version 2
  13
  14
  15 Status of this Memo
  16
  17    This memo provides information for the Internet community.  It does
  18    not specify an Internet standard of any kind.  Distribution of this
  19    memo is unlimited.
  20
  21 Copyright Notice
  22
  23    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  24
  25 Abstract
  26
  27    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  28    transporting multi-protocol datagrams over point-to-point links.  PPP
  29    defines an extensible Link Control Protocol and a family of Network
  30    Control Protocols (NCPs) for establishing and configuring different
  31    network-layer protocols.
  32
  33    This document describes version two of Microsoft's PPP CHAP dialect
  34    (MS-CHAP-V2).  MS-CHAP-V2 is similar to, but incompatible with, MS-
  35    CHAP version one (MS-CHAP-V1, described in [9]).  In particular,
  36    certain protocol fields have been deleted or reused but with
  37    different semantics.  In addition, MS-CHAP-V2 features mutual
  38    authentication.
  39
  40    The algorithms used in the generation of various MS-CHAP-V2 protocol
  41    fields are described in section 8.  Negotiation and hash generation
  42    examples are provided in section 9.
  43
  44 Specification of Requirements
  45
  46    In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
  47    "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
  48    described in [3].
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Zorn                         Informational                      [Page 1]
  59 \f
  60 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
  61
  62
  63 Table of Contents
  64
  65    1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
  66    2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . .  3
  67    3. Challenge Packet  . . . . . . . . . . . . . . . . . . . . . . .  3
  68    4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . .  4
  69    5. Success Packet  . . . . . . . . . . . . . . . . . . . . . . . .  4
  70    6. Failure Packet  . . . . . . . . . . . . . . . . . . . . . . . .  5
  71    7. Change-Password Packet  . . . . . . . . . . . . . . . . . . . .  6
  72    8. Pseudocode  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
  73    8.1. GenerateNTResponse()  . . . . . . . . . . . . . . . . . . . .  7
  74    8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . .  8
  75    8.3. NtPasswordHash()  . . . . . . . . . . . . . . . . . . . . . .  9
  76    8.4. HashNtPasswordHash()  . . . . . . . . . . . . . . . . . . . .  9
  77    8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . .  9
  78    8.6. DesEncrypt()  . . . . . . . . . . . . . . . . . . . . . . . . 10
  79    8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10
  80    8.8. CheckAuthenticatorResponse()  . . . . . . . . . . . . . . . . 12
  81    8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12
  82    8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13
  83    8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13
  84    8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash()  . . . . . 14
  85    8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14
  86    9. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  87    9.1. Negotiation Examples  . . . . . . . . . . . . . . . . . . . . 14
  88    9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15
  89    9.1.2. Authenticator authentication failure  . . . . . . . . . . . 15
  90    9.1.3. Failed authentication with no retry allowed . . . . . . . . 15
  91    9.1.4. Successful authentication after retry . . . . . . . . . . . 15
  92    9.1.5. Failed hack attack with 3 attempts allowed  . . . . . . . . 15
  93    9.1.6. Successful authentication with password change  . . . . . . 16
  94    9.1.7. Successful authentication with retry and password change. . 16
  95    9.2. Hash Example  . . . . . . . . . . . . . . . . . . . . . . . . 16
  96    9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17
  97    10. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
  98    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
  99    12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
 100    13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
 101    14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Zorn                         Informational                      [Page 2]
 115 \f
 116 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 117
 118
 119 1.  Introduction
 120
 121    Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and
 122    standard CHAP.  Briefly, the differences between MS-CHAP-V2 and MS-
 123    CHAP-V1 are:
 124
 125    *  MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP
 126       option 3, Authentication Protocol.
 127
 128    *  MS-CHAP-V2 provides mutual authentication between peers by
 129       piggybacking a peer challenge on the Response packet and an
 130       authenticator response on the Success packet.
 131
 132    *  The calculation of the "Windows NT compatible challenge response"
 133       sub-field in the Response packet has been changed to include the
 134       peer challenge and the user name.
 135
 136    *  In MS-CHAP-V1, the "LAN Manager compatible challenge response"
 137       sub-field was always sent in the Response packet.  This field has
 138       been replaced in MS-CHAP-V2 by the Peer-Challenge field.
 139
 140    *  The format of the Message field in the Failure packet has been
 141       changed.
 142
 143    *  The Change Password (version 1) and Change Password (version 2)
 144       packets are no longer supported. They have been replaced with a
 145       single Change-Password packet.
 146
 147 2.  LCP Configuration
 148
 149    The LCP configuration for MS-CHAP-V2 is identical to that for
 150    standard CHAP, except that the Algorithm field has value 0x81, rather
 151    than the MD5 value 0x05.  PPP implementations which do not support
 152    MS-CHAP-V2, but correctly implement LCP Config-Rej, should have no
 153    problem dealing with this non-standard option.
 154
 155 3.  Challenge Packet
 156
 157    The MS-CHAP-V2 Challenge packet is identical in format to the
 158    standard CHAP Challenge packet.
 159
 160    MS-CHAP-V2 authenticators send an 16-octet challenge Value field.
 161    Peers need not duplicate Microsoft's algorithm for selecting the 16-
 162    octet value, but the standard guidelines on randomness [1,2,7] SHOULD
 163    be observed.
 164
 165    Microsoft authenticators do not currently provide information in the
 166    Name field.  This may change in the future.
 167
 168
 169
 170 Zorn                         Informational                      [Page 3]
 171 \f
 172 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 173
 174
 175 4.  Response Packet
 176
 177    The MS-CHAP-V2 Response packet is identical in format to the standard
 178    CHAP Response packet.  However, the Value field is sub-formatted
 179    differently as follows:
 180
 181    16 octets: Peer-Challenge
 182     8 octets: Reserved, must be zero
 183    24 octets: NT-Response
 184     1 octet : Flags
 185
 186    The Peer-Challenge field is a 16-octet random number.  As the name
 187    implies, it is generated by the peer and is used in the calculation
 188    of the NT-Response field, below.  Peers need not duplicate
 189    Microsoft's algorithm for selecting the 16-octet value, but the
 190    standard guidelines on randomness [1,2,7] SHOULD be observed.
 191
 192    The NT-Response field is an encoded function of the password, the
 193    user name, the contents of the Peer-Challenge field and the received
 194    challenge as output by the routine GenerateNTResponse() (see section
 195    8.1, below).  The Windows NT password is a string of 0 to
 196    (theoretically) 256 case-sensitive Unicode [8] characters.  Current
 197    versions of Windows NT limit passwords to 14 characters, mainly for
 198    compatibility reasons; this may change in the future.  When computing
 199    the NT-Response field contents, only the user name is used, without
 200    any associated Windows NT domain name.  This is true regardless of
 201    whether a Windows NT domain name is present in the Name field (see
 202    below).
 203
 204    The Flag field is reserved for future use and MUST be zero.
 205
 206    The Name field is a string of 0 to (theoretically) 256 case-sensitive
 207    ASCII characters which identifies the peer's user account name.  The
 208    Windows NT domain name may prefix the user's account name (e.g.
 209    "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the
 210    user account "johndoe").  If a domain is not provided, the backslash
 211    should also be omitted, (e.g. "johndoe").
 212
 213 5.  Success Packet
 214
 215    The Success packet is identical in format to the standard CHAP
 216    Success packet.  However, the Message field contains a 42-octet
 217    authenticator response string and a printable message.  The format of
 218    the message field is illustrated below.
 219
 220    "S=<auth_string> M=<message>"
 221
 222
 223
 224
 225
 226 Zorn                         Informational                      [Page 4]
 227 \f
 228 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 229
 230
 231    The <auth_string> quantity is a 20 octet number encoded in ASCII as
 232    40 hexadecimal digits.  The hexadecimal digits A-F (if present) MUST
 233    be uppercase.  This number is derived from the challenge from the
 234    Challenge packet, the Peer-Challenge and NT-Response fields from the
 235    Response packet, and the peer password as output by the routine
 236    GenerateAuthenticatorResponse() (see section 8.7, below).  The
 237    authenticating peer MUST verify the authenticator response when a
 238    Success packet is received.  The method for verifying the
 239    authenticator is described in section 8.8, below.  If the
 240    authenticator response is either missing or incorrect, the peer MUST
 241    end the session.
 242
 243    The <message> quantity is human-readable text in the appropriate
 244    charset and language [12].
 245
 246 6.  Failure Packet
 247
 248    The Failure packet is identical in format to the standard CHAP
 249    Failure packet.  There is, however, formatted text stored in the
 250    Message field which, contrary to the standard CHAP rules, does affect
 251    the operation of the protocol.  The Message field format is:
 252
 253       "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv
 254 M=<msg>"
 255
 256       where
 257
 258       The "eeeeeeeeee" is the ASCII representation of a decimal error
 259       code (need not be 10 digits) corresponding to one of those listed
 260       below, though implementations should deal with codes not on this
 261       list gracefully.
 262
 263          646 ERROR_RESTRICTED_LOGON_HOURS
 264          647 ERROR_ACCT_DISABLED
 265          648 ERROR_PASSWD_EXPIRED
 266          649 ERROR_NO_DIALIN_PERMISSION
 267          691 ERROR_AUTHENTICATION_FAILURE
 268          709 ERROR_CHANGING_PASSWORD
 269
 270       The "r" is an ASCII flag set to '1' if a retry is allowed, and '0'
 271       if not.  When the authenticator sets this flag to '1' it disables
 272       short timeouts, expecting the peer to prompt the user for new
 273       credentials and resubmit the response.
 274
 275       The "cccccccccccccccccccccccccccccccc" is the ASCII representation
 276       of a hexadecimal challenge value.  This field MUST be exactly 32
 277       octets long and MUST be present.
 278
 279
 280
 281
 282 Zorn                         Informational                      [Page 5]
 283 \f
 284 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 285
 286
 287       The "vvvvvvvvvv" is the ASCII representation of a decimal version
 288       code (need not be 10 digits) indicating the password changing
 289       protocol version supported on the server.  For MS-CHAP-V2, this
 290       value SHOULD always be 3.
 291
 292       <msg> is human-readable text in the appropriate charset and
 293       language [12].
 294
 295 7.  Change-Password Packet
 296
 297    The Change-Password packet does not appear in either standard CHAP or
 298    MS-CHAP-V1.  It allows the peer to change the password on the account
 299    specified in the preceding Response packet.  The Change-Password
 300    packet should be sent only if the authenticator reports
 301    ERROR_PASSWD_EXPIRED (E=648) in the Message field of the Failure
 302    packet.
 303
 304    This packet type is supported by recent versions of Windows NT 4.0,
 305    Windows 95 and Windows 98.  It is not supported by Windows NT 3.5,
 306    Windows NT 3.51, or early versions of Windows NT 4.0, Windows 95 and
 307    Windows 98.
 308
 309    The format of this packet is as follows:
 310
 311         1 octet  : Code
 312         1 octet  : Identifier
 313         2 octets : Length
 314       516 octets : Encrypted-Password
 315        16 octets : Encrypted-Hash
 316        16 octets : Peer-Challenge
 317         8 octets : Reserved
 318        24 octets : NT-Response
 319         2-octet  : Flags
 320
 321    Code
 322       7
 323
 324    Identifier
 325       The Identifier field is one octet and aids in matching requests
 326       and replies.  The value is the Identifier of the received Failure
 327       packet to which this packet responds plus 1.
 328
 329    Length
 330       586
 331
 332
 333
 334
 335
 336
 337
 338 Zorn                         Informational                      [Page 6]
 339 \f
 340 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 341
 342
 343    Encrypted-Password
 344       This field contains the PWBLOCK form of the new Windows NT
 345       password encrypted with the old Windows NT password hash, as
 346       output by the NewPasswordEncryptedWithOldNtPasswordHash() routine
 347       (see section 8.9, below).
 348
 349    Encrypted-Hash
 350       This field contains the old Windows NT password hash encrypted
 351       with the new Windows NT password hash, as output by the
 352       OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see
 353       section 8.12, below).
 354
 355    Peer-Challenge
 356       A 16-octet random quantity, as described in the Response packet
 357       description.
 358
 359    Reserved
 360       8 octets, must be zero.
 361
 362    NT-Response
 363       The NT-Response field (as described in the Response packet
 364       description), but calculated on the new password and the challenge
 365       received in the Failure packet.
 366
 367    Flags
 368       This field is two octets in length.  It is a bit field of option
 369       flags where 0 is the least significant bit of the 16-bit quantity.
 370       The format of this field is illustrated in the following diagram:
 371
 372                     1
 373           5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
 374          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 375          |                               |
 376          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 377
 378          Bits 0-15
 379             Reserved, always clear (0).
 380
 381 8.  Pseudocode
 382
 383    The routines mentioned in the text above are described in pseudocode
 384    in the following sections.
 385
 386 8.1.  GenerateNTResponse()
 387
 388    GenerateNTResponse(
 389    IN  16-octet              AuthenticatorChallenge,
 390    IN  16-octet              PeerChallenge,
 391
 392
 393
 394 Zorn                         Informational                      [Page 7]
 395 \f
 396 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 397
 398
 399    IN  0-to-256-char         UserName,
 400
 401    IN  0-to-256-unicode-char Password,
 402    OUT 24-octet              Response )
 403    {
 404       8-octet  Challenge
 405       16-octet PasswordHash
 406
 407       ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName,
 408                      giving Challenge)
 409
 410       NtPasswordHash( Password, giving PasswordHash )
 411       ChallengeResponse( Challenge, PasswordHash, giving Response )
 412    }
 413
 414 8.2.  ChallengeHash()
 415
 416    ChallengeHash(
 417    IN 16-octet               PeerChallenge,
 418    IN 16-octet               AuthenticatorChallenge,
 419    IN  0-to-256-char         UserName,
 420    OUT 8-octet               Challenge
 421    {
 422
 423       /*
 424        * SHAInit(), SHAUpdate() and SHAFinal() functions are an
 425        * implementation of Secure Hash Algorithm (SHA-1) [11]. These are
 426        * available in public domain or can be licensed from
 427        * RSA Data Security, Inc.
 428        */
 429
 430       SHAInit(Context)
 431       SHAUpdate(Context, PeerChallenge, 16)
 432       SHAUpdate(Context, AuthenticatorChallenge, 16)
 433
 434       /*
 435        * Only the user name (as presented by the peer and
 436        * excluding any prepended domain name)
 437        * is used as input to SHAUpdate().
 438        */
 439
 440       SHAUpdate(Context, UserName, strlen(Username))
 441       SHAFinal(Context, Digest)
 442       memcpy(Challenge, Digest, 8)
 443    }
 444
 445
 446
 447
 448
 449
 450 Zorn                         Informational                      [Page 8]
 451 \f
 452 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 453
 454
 455 8.3.  NtPasswordHash()
 456
 457    NtPasswordHash(
 458    IN  0-to-256-unicode-char Password,
 459    OUT 16-octet              PasswordHash )
 460    {
 461       /*
 462        * Use the MD4 algorithm [5] to irreversibly hash Password
 463        * into PasswordHash.  Only the password is hashed without
 464        * including any terminating 0.
 465        */
 466    }
 467
 468 8.4.  HashNtPasswordHash()
 469
 470    HashNtPasswordHash(
 471    IN  16-octet PasswordHash,
 472    OUT 16-octet PasswordHashHash )
 473    {
 474       /*
 475        * Use the MD4 algorithm [5] to irreversibly hash
 476        * PasswordHash into PasswordHashHash.
 477        */
 478    }
 479
 480 8.5.  ChallengeResponse()
 481
 482    ChallengeResponse(
 483    IN  8-octet  Challenge,
 484    IN  16-octet PasswordHash,
 485    OUT 24-octet Response )
 486    {
 487       Set ZPasswordHash to PasswordHash zero-padded to 21 octets
 488
 489       DesEncrypt( Challenge,
 490                   1st 7-octets of ZPasswordHash,
 491                   giving 1st 8-octets of Response )
 492
 493       DesEncrypt( Challenge,
 494                   2nd 7-octets of ZPasswordHash,
 495                   giving 2nd 8-octets of Response )
 496
 497       DesEncrypt( Challenge,
 498                   3rd 7-octets of ZPasswordHash,
 499                   giving 3rd 8-octets of Response )
 500    }
 501
 502
 503
 504
 505
 506 Zorn                         Informational                      [Page 9]
 507 \f
 508 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 509
 510
 511 8.6.  DesEncrypt()
 512
 513    DesEncrypt(
 514    IN  8-octet Clear,
 515    IN  7-octet Key,
 516    OUT 8-octet Cypher )
 517    {
 518       /*
 519        * Use the DES encryption algorithm [4] in ECB mode [10]
 520        * to encrypt Clear into Cypher such that Cypher can
 521        * only be decrypted back to Clear by providing Key.
 522        * Note that the DES algorithm takes as input a 64-bit
 523        * stream where the 8th, 16th, 24th, etc.  bits are
 524        * parity bits ignored by the encrypting algorithm.
 525        * Unless you write your own DES to accept 56-bit input
 526        * without parity, you will need to insert the parity bits
 527        * yourself.
 528        */
 529    }
 530
 531 8.7.  GenerateAuthenticatorResponse()
 532
 533    GenerateAuthenticatorResponse(
 534    IN  0-to-256-unicode-char Password,
 535    IN  24-octet              NT-Response,
 536    IN  16-octet              PeerChallenge,
 537    IN  16-octet              AuthenticatorChallenge,
 538    IN  0-to-256-char         UserName,
 539    OUT 42-octet              AuthenticatorResponse )
 540    {
 541       16-octet              PasswordHash
 542       16-octet              PasswordHashHash
 543       8-octet               Challenge
 544
 545       /*
 546        * "Magic" constants used in response generation
 547        */
 548
 549       Magic1[39] =
 550          {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76,
 551           0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65,
 552           0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67,
 553           0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74};
 554
 555
 556
 557
 558
 559
 560
 561
 562 Zorn                         Informational                     [Page 10]
 563 \f
 564 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 565
 566
 567       Magic2[41] =
 568          {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B,
 569           0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F,
 570           0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E,
 571           0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F,
 572           0x6E};
 573
 574       /*
 575        * Hash the password with MD4
 576        */
 577
 578       NtPasswordHash( Password, giving PasswordHash )
 579
 580       /*
 581        * Now hash the hash
 582        */
 583
 584       HashNtPasswordHash( PasswordHash, giving PasswordHashHash)
 585
 586       SHAInit(Context)
 587       SHAUpdate(Context, PasswordHashHash, 16)
 588       SHAUpdate(Context, NTResponse, 24)
 589       SHAUpdate(Context, Magic1, 39)
 590       SHAFinal(Context, Digest)
 591
 592       ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName,
 593                      giving Challenge)
 594
 595       SHAInit(Context)
 596       SHAUpdate(Context, Digest, 20)
 597       SHAUpdate(Context, Challenge, 8)
 598       SHAUpdate(Context, Magic2, 41)
 599       SHAFinal(Context, Digest)
 600
 601       /*
 602        * Encode the value of 'Digest' as "S=" followed by
 603        * 40 ASCII hexadecimal digits and return it in
 604        * AuthenticatorResponse.
 605        * For example,
 606        *   "S=0123456789ABCDEF0123456789ABCDEF01234567"
 607        */
 608
 609    }
 610
 611
 612
 613
 614
 615
 616
 617
 618 Zorn                         Informational                     [Page 11]
 619 \f
 620 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 621
 622
 623 8.8.  CheckAuthenticatorResponse()
 624
 625    CheckAuthenticatorResponse(
 626    IN  0-to-256-unicode-char Password,
 627    IN  24-octet              NtResponse,
 628    IN  16-octet              PeerChallenge,
 629    IN  16-octet              AuthenticatorChallenge,
 630    IN  0-to-256-char         UserName,
 631    IN  42-octet              ReceivedResponse,
 632    OUT Boolean               ResponseOK )
 633    {
 634
 635       20-octet MyResponse
 636
 637       set ResponseOK = FALSE
 638       GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge,
 639                                      AuthenticatorChallenge, UserName,
 640                                      giving MyResponse)
 641
 642       if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE
 643       return ResponseOK
 644    }
 645
 646 8.9.  NewPasswordEncryptedWithOldNtPasswordHash()
 647
 648    datatype-PWBLOCK
 649    {
 650       256-unicode-char Password
 651       4-octets         PasswordLength
 652    }
 653
 654    NewPasswordEncryptedWithOldNtPasswordHash(
 655    IN  0-to-256-unicode-char NewPassword,
 656    IN  0-to-256-unicode-char OldPassword,
 657    OUT datatype-PWBLOCK      EncryptedPwBlock )
 658    {
 659       NtPasswordHash( OldPassword, giving PasswordHash )
 660
 661       EncryptPwBlockWithPasswordHash( NewPassword,
 662                                       PasswordHash,
 663                                       giving EncryptedPwBlock )
 664    }
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Zorn                         Informational                     [Page 12]
 675 \f
 676 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 677
 678
 679 8.10.  EncryptPwBlockWithPasswordHash()
 680
 681    EncryptPwBlockWithPasswordHash(
 682    IN  0-to-256-unicode-char Password,
 683    IN  16-octet              PasswordHash,
 684    OUT datatype-PWBLOCK      PwBlock )
 685    {
 686
 687       Fill ClearPwBlock with random octet values
 688
 689          PwSize = lstrlenW( Password ) * sizeof( unicode-char )
 690          PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
 691          Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from
 692    Password
 693          ClearPwBlock.PasswordLength = PwSize
 694          Rc4Encrypt( ClearPwBlock,
 695                      sizeof( ClearPwBlock ),
 696                      PasswordHash,
 697                      sizeof( PasswordHash ),
 698                      giving PwBlock )
 699       }
 700
 701 8.11.  Rc4Encrypt()
 702
 703    Rc4Encrypt(
 704    IN  x-octet Clear,
 705    IN  integer ClearLength,
 706    IN  y-octet Key,
 707    IN  integer KeyLength,
 708    OUT x-octet Cypher )
 709    {
 710       /*
 711        * Use the RC4 encryption algorithm [6] to encrypt Clear of
 712        * length ClearLength octets into a Cypher of the same length
 713        * such that the Cypher can only be decrypted back to Clear
 714        * by providing a Key of length KeyLength octets.
 715        */
 716    }
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Zorn                         Informational                     [Page 13]
 731 \f
 732 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 733
 734
 735 8.12.  OldNtPasswordHashEncryptedWithNewNtPasswordHash()
 736
 737    OldNtPasswordHashEncryptedWithNewNtPasswordHash(
 738    IN  0-to-256-unicode-char NewPassword,
 739    IN  0-to-256-unicode-char OldPassword,
 740    OUT 16-octet              EncryptedPasswordHash )
 741    {
 742       NtPasswordHash( OldPassword, giving OldPasswordHash )
 743       NtPasswordHash( NewPassword, giving NewPasswordHash )
 744       NtPasswordHashEncryptedWithBlock( OldPasswordHash,
 745                                         NewPasswordHash,
 746                                         giving EncryptedPasswordHash )
 747    }
 748
 749 8.13.  NtPasswordHashEncryptedWithBlock()
 750
 751    NtPasswordHashEncryptedWithBlock(
 752    IN  16-octet PasswordHash,
 753    IN  16-octet Block,
 754    OUT 16-octet Cypher )
 755    {
 756       DesEncrypt( 1st 8-octets PasswordHash,
 757                   1st 7-octets Block,
 758                   giving 1st 8-octets Cypher )
 759
 760       DesEncrypt( 2nd 8-octets PasswordHash,
 761                   2nd 7-octets Block,
 762                   giving 2nd 8-octets Cypher )
 763    }
 764
 765 9.  Examples
 766
 767    The following sections include protocol negotiation and hash
 768    generation examples.
 769
 770 9.1.  Negotiation Examples
 771
 772    Here are some examples of typical negotiations.  The peer is on the
 773    left and the authenticator is on the right.
 774
 775    The packet sequence ID is incremented on each authentication retry
 776    response and on the change password response.  All cases where the
 777    packet sequence ID is updated are noted below.
 778
 779    Response retry is never allowed after Change Password.  Change
 780    Password may occur after response retry.
 781
 782
 783
 784
 785
 786 Zorn                         Informational                     [Page 14]
 787 \f
 788 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 789
 790
 791 9.1.1.  Successful authentication
 792
 793                          <- Authenticator Challenge
 794        Peer Response/Challenge ->
 795                          <- Success/Authenticator Response
 796
 797    (Authenticator Response verification succeeds, call continues)
 798
 799 9.1.2.  Authenticator authentication failure
 800
 801                          <- Authenticator Challenge
 802        Peer Response/Challenge ->
 803                          <- Success/Authenticator Response
 804
 805    (Authenticator Response verification fails, peer disconnects)
 806
 807 9.1.3.  Failed authentication with no retry allowed
 808
 809                          <- Authenticator Challenge
 810        Peer Response/Challenge ->
 811                          <- Failure (E=691 R=0)
 812
 813    (Authenticator disconnects)
 814
 815 9.1.4.  Successful authentication after retry
 816
 817                          <- Authenticator Challenge
 818        Peer Response/Challenge ->
 819                          <- Failure (E=691 R=1), disable short timeout
 820        Response (++ID) to challenge in failure message ->
 821                          <- Success/Authenticator Response
 822
 823    (Authenticator Response verification succeeds, call continues)
 824
 825 9.1.5.  Failed hack attack with 3 attempts allowed
 826
 827                          <- Authenticator Challenge
 828        Peer Response/Challenge ->
 829                          <- Failure (E=691 R=1), disable short timeout
 830        Response (++ID) to challenge in Failure message ->
 831                          <- Failure (E=691 R=1), disable short timeout
 832        Response (++ID) to challenge in Failure message ->
 833                          <- Failure (E=691 R=0)
 834
 835
 836
 837
 838
 839
 840
 841
 842 Zorn                         Informational                     [Page 15]
 843 \f
 844 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 845
 846
 847 9.1.6.  Successful authentication with password change
 848
 849                          <- Authenticator Challenge
 850        Peer Response/Challenge ->
 851                          <- Failure (E=648 R=0 V=3), disable short
 852    timeout
 853        ChangePassword (++ID) to challenge in Failure message ->
 854                          <- Success/Authenticator Response
 855
 856    (Authenticator Response verification succeeds, call continues)
 857
 858 9.1.7.  Successful authentication with retry and password change
 859
 860                          <- Authenticator Challenge
 861        Peer Response/Challenge ->
 862                          <- Failure (E=691 R=1), disable short timeout
 863        Response (++ID) to first challenge+23 ->
 864                          <- Failure (E=648 R=0 V=2), disable short
 865    timeout
 866        ChangePassword (++ID) to first challenge+23 ->
 867                          <- Success/Authenticator Response
 868
 869    (Authenticator Response verification succeeds, call continues)
 870
 871 9.2.  Hash Example
 872
 873    Intermediate values for user name "User" and password "clientPass".
 874    All numeric values are hexadecimal.
 875
 876 0-to-256-char UserName:
 877 55 73 65 72
 878
 879 0-to-256-unicode-char Password:
 880 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00
 881
 882 16-octet AuthenticatorChallenge:
 883 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28
 884
 885 16-octet PeerChallenge:
 886 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
 887
 888 8-octet Challenge:
 889 D0 2E 43 86 BC E9 12 26
 890
 891 16-octet PasswordHash:
 892 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
 893
 894
 895
 896
 897
 898 Zorn                         Informational                     [Page 16]
 899 \f
 900 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 901
 902
 903 24 octet NT-Response:
 904 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF
 905
 906 16-octet PasswordHashHash:
 907 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
 908
 909 42-octet AuthenticatorResponse:
 910 "S=407A5589115FD0D6209F510FE9C04566932CDA56"
 911
 912 9.3.  Example of DES Key Generation
 913
 914    DES uses 56-bit keys, expanded to 64 bits by the insertion of parity
 915    bits.  After the parity of the key has been fixed, every eighth bit
 916    is a parity bit and the number of bits that are set (1) in each octet
 917    is odd; i.e., odd parity.  Note that many DES engines do not check
 918    parity, however, simply stripping the parity bits.  The following
 919    example illustrates the values resulting from the use of the password
 920    "MyPw" to generate a pair of DES keys (e.g., for use in the
 921    NtPasswordHashEncryptedWithBlock() described in section 8.13).
 922
 923    0-to-256-unicode-char Password:
 924    4D 79 50 77
 925
 926    16-octet PasswordHash:
 927    FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
 928
 929    First "raw" DES key (initial 7 octets of password hash):
 930    FC 15 6A F7 ED CD 6C
 931
 932    First parity-corrected DES key (eight octets):
 933    FD 0B 5B 5E 7F 6E 34 D9
 934
 935    Second "raw" DES key (second 7 octets of password hash)
 936    0E DD E3 33 7D 42 7F
 937
 938    Second parity-corrected DES key (eight octets):
 939    0E 6E 79 67 37 EA 08 FE
 940
 941 10.  Security Considerations
 942
 943    As an implementation detail, the authenticator SHOULD limit the
 944    number of password retries allowed to make brute-force password
 945    guessing attacks more difficult.
 946
 947
 948
 949
 950
 951
 952
 953
 954 Zorn                         Informational                     [Page 17]
 955 \f
 956 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
 957
 958
 959 11.  References
 960
 961    [1]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
 962         1661, July 1994.
 963
 964    [2]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
 965         (CHAP)", RFC 1994, August 1996.
 966
 967    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 968         Levels", BCP 14, RFC 2119, March 1997.
 969
 970    [4]  "Data Encryption Standard (DES)", Federal Information Processing
 971         Standard Publication 46-2, National Institute of Standards and
 972         Technology, December 1993.
 973
 974    [5]  Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April
 975         1992.
 976
 977    [6]  RC4 is a proprietary encryption algorithm available under
 978         license from RSA Data Security Inc.  For licensing information,
 979         contact:
 980
 981              RSA Data Security, Inc.
 982              100 Marine Parkway
 983              Redwood City, CA 94065-1031
 984
 985    [7]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
 986         Recommendations for Security", RFC 1750, December 1994.
 987
 988    [8]  "The Unicode Standard, Version 2.0", The Unicode Consortium,
 989         Addison-Wesley, 1996. ISBN 0-201-48345-9.
 990
 991    [9]  Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC
 992         2433, October 1998.
 993
 994    [10] "DES Modes of Operation", Federal Information Processing
 995         Standards Publication 81, National Institute of Standards and
 996         Technology, December 1980.
 997
 998    [11] "Secure Hash Standard", Federal Information Processing Standards
 999         Publication 180-1, National Institute of Standards and
1000         Technology, April 1995.
1001
1002    [12] Zorn, G., "PPP LCP Internationalization Configuration Option",
1003         RFC 2484, January 1999.
1004
1005
1006
1007
1008
1009
1010 Zorn                         Informational                     [Page 18]
1011 \f
1012 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
1013
1014
1015 12.  Acknowledgements
1016
1017    Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul
1018    Leach, Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh
1019    Pall, Jody Terrill, Brad Robel-Forrest, and Joe Davies for useful
1020    suggestions and feedback.
1021
1022 13.  Author's Address
1023
1024    Questions about this memo can also be directed to:
1025
1026    Glen Zorn
1027    Microsoft Corporation
1028    One Microsoft Way
1029    Redmond, Washington 98052
1030
1031    Phone: +1 425 703 1559
1032    Fax:   +1 425 936 7329
1033    EMail: gwz@acm.org
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066 Zorn                         Informational                     [Page 19]
1067 \f
1068 RFC 2759                  Microsoft MS-CHAP-V2              January 2000
1069
1070
1071 14.  Full Copyright Statement
1072
1073    Copyright (C) The Internet Society (2000).  All Rights Reserved.
1074
1075    This document and translations of it may be copied and furnished to
1076    others, and derivative works that comment on or otherwise explain it
1077    or assist in its implementation may be prepared, copied, published
1078    and distributed, in whole or in part, without restriction of any
1079    kind, provided that the above copyright notice and this paragraph are
1080    included on all such copies and derivative works.  However, this
1081    document itself may not be modified in any way, such as by removing
1082    the copyright notice or references to the Internet Society or other
1083    Internet organizations, except as needed for the purpose of
1084    developing Internet standards in which case the procedures for
1085    copyrights defined in the Internet Standards process must be
1086    followed, or as required to translate it into languages other than
1087    English.
1088
1089    The limited permissions granted above are perpetual and will not be
1090    revoked by the Internet Society or its successors or assigns.
1091
1092    This document and the information contained herein is provided on an
1093    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1094    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1095    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1096    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1097    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1098
1099 Acknowledgement
1100
1101    Funding for the RFC Editor function is currently provided by the
1102    Internet Society.
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122 Zorn                         Informational                     [Page 20]
1123 \f