doc/rfc/rfc2433.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            G. Zorn
   8 Request for Comments: 2433                                       S. Cobb
   9 Category: Informational                            Microsoft Corporation
  10                                                             October 1998
  11
  12
  13                      Microsoft PPP CHAP Extensions
  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 (1998).  All Rights Reserved.
  24
  25 IESG Note
  26
  27    The protocol described here has significant vulnerabilities.  People
  28    planning on implementing or using this protocol should read section
  29    12, "Security Considerations".
  30
  31 1.  Abstract
  32
  33    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  34    transporting multi-protocol datagrams over point-to-point links.  PPP
  35    defines an extensible Link Control Protocol and a family of Network
  36    Control Protocols (NCPs) for establishing and configuring different
  37    network-layer protocols.
  38
  39    This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which
  40    extends the user authentication functionality provided on Windows
  41    networks to remote workstations.  MS-CHAP is closely derived from the
  42    PPP Challenge Handshake Authentication Protocol described in RFC 1994
  43    [2], which the reader should have at hand.
  44
  45    The algorithms used in the generation of various MS-CHAP protocol
  46    fields are described in an appendix.
  47
  48 2.  Introduction
  49
  50    Microsoft created MS-CHAP to authenticate remote Windows
  51    workstations, providing the functionality to which LAN-based users
  52    are accustomed while integrating the encryption and hashing
  53    algorithms used on Windows networks.
  54
  55
  56
  57
  58 Zorn & Cobb                  Informational                      [Page 1]
  59 \f
  60 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  61
  62
  63    Where possible, MS-CHAP is consistent with standard CHAP.  Briefly,
  64    the differences between MS-CHAP and standard CHAP are:
  65
  66       * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
  67         option 3, Authentication Protocol.
  68
  69       * The MS-CHAP Response packet is in a format designed for
  70         compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and
  71         Windows95 networking products.  The MS-CHAP format does not
  72         require the authenticator to store a clear-text or reversibly
  73         encrypted password.
  74
  75       * MS-CHAP provides authenticator-controlled authentication retry
  76         and password changing mechanisms.
  77
  78       * MS-CHAP defines a set of reason-for-failure codes returned in
  79         the Failure packet Message field.
  80
  81 3.  Specification of Requirements
  82
  83    In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
  84    "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
  85    described in [2].
  86
  87 4.  LCP Configuration
  88
  89    The LCP configuration for MS-CHAP is identical to that for standard
  90    CHAP, except that the Algorithm field has value 0x80, rather than the
  91    MD5 value 0x05.  PPP implementations which do not support MS-CHAP,
  92    but correctly implement LCP Config-Rej, should have no problem
  93    dealing with this non-standard option.
  94
  95 5.  Challenge Packet
  96
  97    The MS-CHAP Challenge packet is identical in format to the standard
  98    CHAP Challenge packet.
  99
 100    MS-CHAP authenticators send an 8-octet challenge Value field.  Peers
 101    need not duplicate Microsoft's algorithm for selecting the 8-octet
 102    value, but the standard guidelines on randomness [1,2,7] SHOULD be
 103    observed.
 104
 105    Microsoft authenticators do not currently provide information in the
 106    Name field.  This may change in the future.
 107
 108
 109
 110
 111
 112
 113
 114 Zorn & Cobb                  Informational                      [Page 2]
 115 \f
 116 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 117
 118
 119 6.  Response Packet
 120
 121    The MS-CHAP Response packet is identical in format to the standard
 122    CHAP Response packet.  However, the Value field is sub-formatted
 123    differently as follows:
 124
 125       24 octets: LAN Manager compatible challenge response
 126       24 octets: Windows NT compatible challenge response
 127        1 octet : "Use Windows NT compatible challenge response" flag
 128
 129    The LAN Manager compatible challenge response is an encoded function
 130    of the password and the received challenge as output by the routine
 131    LmChallengeResponse() (see section A.1, below).  LAN Manager
 132    passwords are limited to 14 case-insensitive OEM characters.  Note
 133    that use of the LAN Manager compatible challenge response has been
 134    deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be
 135    zero-filled.  The algorithm used in the generation of the LAN Manager
 136    compatible challenge response is described here for informational
 137    purposes only.
 138
 139    The Windows NT compatible challenge response is an encoded function
 140    of the password and the received challenge as output by the routine
 141    NTChallengeResponse() (see section A.5, below).  The Windows NT
 142    password is a string of 0 to (theoretically) 256 case-sensitive
 143    Unicode [8] characters.  Current versions of Windows NT limit
 144    passwords to 14 characters, mainly for compatibility reasons; this
 145    may change in the future.
 146
 147    The "use Windows NT compatible challenge response" flag, if 1,
 148    indicates that the Windows NT response is provided and should be used
 149    in preference to the LAN Manager response.  The LAN Manager response
 150    will still be used if the account does not have a Windows NT password
 151    hash, e.g.  if the password has not been changed since the account
 152    was uploaded from a LAN Manager 2.x account database.  If the flag is
 153    0, the Windows NT response is ignored and the LAN Manager response is
 154    used.  Since the use of LAN Manager authentication has been
 155    deprecated, this flag SHOULD always be set (1) and the LAN Manager
 156    compatible challenge response field SHOULD be zero-filled.
 157
 158    The Name field identifies the peer's user account name.  The Windows
 159    NT domain name may prefix the user's account name (e.g.
 160    "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the
 161    user account "john-doe").  If a domain is not provided, the backslash
 162    should also be omitted, (e.g. "johndoe").
 163
 164
 165
 166
 167
 168
 169
 170 Zorn & Cobb                  Informational                      [Page 3]
 171 \f
 172 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 173
 174
 175 7.  Success Packet
 176
 177    The Success packet is identical in format to the standard CHAP
 178    Success packet.
 179
 180 8.  Failure Packet
 181
 182    The Failure packet is identical in format to the standard CHAP
 183    Failure packet.  There is, however, formatted text stored in the
 184    Message field which, contrary to the standard CHAP rules, affects the
 185    protocol.  The Message field format is:
 186
 187          "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"
 188
 189       where
 190
 191          The "eeeeeeeeee" is the decimal error code (need not be 10
 192          digits) corresponding to one of those listed below, though
 193          implementations should deal with codes not on this list
 194          gracefully.
 195
 196             646 ERROR_RESTRICTED_LOGON_HOURS
 197             647 ERROR_ACCT_DISABLED
 198             648 ERROR_PASSWD_EXPIRED
 199             649 ERROR_NO_DIALIN_PERMISSION
 200             691 ERROR_AUTHENTICATION_FAILURE
 201             709 ERROR_CHANGING_PASSWORD
 202
 203          The "r" is a flag set to "1" if a retry is allowed, and "0" if
 204          not.  When the authenticator sets this flag to "1" it disables
 205          short timeouts, expecting the peer to prompt the user for new
 206          credentials and resubmit the response.
 207
 208          The "cccccccccccccccc" is 16 hexadecimal digits representing an
 209          ASCII representation of a new challenge value.  This field is
 210          optional.  If it is not sent, the authenticator expects the
 211          resubmitted response to be calculated based on the previous
 212          challenge value plus decimal 23 in the first octet, i.e. the
 213          one immediately following the Value Size field.  Windows 95
 214          authenticators may send this field.  Windows NT authenticators
 215          do not, but may in the future.  Both systems implement peer
 216          support of this field.
 217
 218          The "vvvvvvvvvv" is the decimal version code (need not be 10
 219          digits) indicating the MS-CHAP protocol version supported on
 220          the server.  Currently, this is interesting only in selecting a
 221          Change Password packet type.  If the field is not present the
 222          version should be assumed to be 1; since use of the version 1
 223
 224
 225
 226 Zorn & Cobb                  Informational                      [Page 4]
 227 \f
 228 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 229
 230
 231          Change Password packet has been deprecated, this field SHOULD
 232          always contain a value greater than or equal to 2.
 233
 234    Implementations should accept but ignore additional text they do not
 235    recognize.
 236
 237 9.  Change Password Packet (version 1)
 238
 239    The version 1 Change Password packet does not appear in standard
 240    CHAP.  It allows the peer to change the password on the account
 241    specified in the previous Response packet.  The version 1 Change
 242    Password packet should be sent only if the authenticator reports
 243    ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to one
 244    in the Message field of the Failure packet.
 245
 246    The use of the Change Password Packet (version 1) has been
 247    deprecated; the format of the packet is described here for
 248    informational purposes, but peers SHOULD NOT transmit it.
 249
 250    The format of this packet is as follows:
 251
 252        1 octet : Code (=5)
 253        1 octet : Identifier
 254        2 octets: Length (=72)
 255       16 octets: Encrypted LAN Manager Old password Hash
 256       16 octets: Encrypted LAN Manager New Password Hash
 257       16 octets: Encrypted Windows NT Old Password Hash
 258       16 octets: Encrypted Windows NT New Password Hash
 259        2 octets: Password Length
 260        2 octets: Flags
 261
 262       Code
 263          5
 264
 265       Identifier
 266          The Identifier field is one octet and aids in matching requests
 267          and replies.  The value is the Identifier of the received
 268          Failure packet to which this packet responds plus 1.
 269
 270       Length
 271          72
 272
 273       Encrypted LAN Manager New Password Hash
 274       Encrypted LAN Manager Old Password Hash
 275          These fields contain the LAN Manager password hash of the new
 276          and old passwords encrypted with the last received challenge
 277          value, as output by the routine LmEncryptedPasswordHash() (see
 278          section A.8, below).
 279
 280
 281
 282 Zorn & Cobb                  Informational                      [Page 5]
 283 \f
 284 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 285
 286
 287       Encrypted Windows NT New Password Hash
 288       Encrypted Windows NT Old Password Hash
 289          These fields contain the Windows NT password hash of the new
 290          and old passwords encrypted with the last received challenge
 291          value, as output by the pseudo-code routine
 292          NtEncryptedPasswordHash() (see section A.10, below).
 293
 294       Password Length
 295          The length in octets of the LAN Manager compatible form of the
 296          new password.  If this value is greater than or equal to zero
 297          and less than or equal to 14 it is assumed that the encrypted
 298          LAN Manager password hash fields are valid.  Otherwise, it is
 299          assumed these fields are not valid, in which case the Windows
 300          NT compatible passwords MUST be provided.
 301
 302       Flags
 303          This field is two octets in length.  It is a bit field of
 304          option flags where 0 is the least significant bit of the 16-bit
 305          quantity:
 306
 307             Bit 0
 308                If this bit is set (1), it indicates that the encrypted
 309                Windows NT hashed passwords are valid and should be used.
 310                If this bit is cleared (0), the Windows NT fields are not
 311                used and the LAN Manager fields must be provided.
 312
 313             Bits 1-15
 314                Reserved, always clear (0).
 315
 316 10.  Change Password Packet (version 2)
 317
 318    The version 2 Change Password packet does not appear in standard
 319    CHAP.  It allows the peer to change the password on the account
 320    specified in the preceding Response packet.  The version 2 Change
 321    Password packet should be sent only if the authenticator reports
 322    ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in the
 323    Message field of the Failure packet.
 324
 325    This packet type is supported by Windows NT 3.51, 4.0 and recent
 326    versions of Windows 95.  It is not supported by Windows NT 3.5 or
 327    early versions of Windows 95.
 328
 329       The format of this packet is as follows:
 330
 331            1 octet  : Code
 332            1 octet  : Identifier
 333            2 octets : Length
 334          516 octets : Password Encrypted with Old NT Hash
 335
 336
 337
 338 Zorn & Cobb                  Informational                      [Page 6]
 339 \f
 340 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 341
 342
 343           16 octets : Old NT Hash Encrypted with New NT Hash
 344          516 octets : Password Encrypted with Old LM Hash
 345           16 octets : Old LM Hash Encrypted With New NT Hash
 346           24 octets : LAN Manager compatible challenge response
 347           24 octets : Windows NT compatible challenge response
 348            2-octet  : Flags
 349
 350       Code
 351          6
 352
 353       Identifier
 354          The Identifier field is one octet and aids in matching requests
 355          and replies.  The value is the Identifier of the received
 356          Failure packet to which this packet responds plus 1.
 357
 358       Length
 359          1118
 360
 361       Password Encrypted with Old NT Hash
 362          This field contains the PWBLOCK form of the new Windows NT
 363          password encrypted with the old Windows NT password hash, as
 364          output by the NewPasswordEncryptedWithOldNtPasswordHash()
 365          routine (see section A.11, below).
 366
 367       Old NT Hash Encrypted with New NT Hash
 368          This field contains the old Windows NT password hash encrypted
 369          with the new Windows NT password hash, as output by the
 370          OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see
 371          section A.14, below).
 372
 373       Password Encrypted with Old LM Hash
 374          This field contains the PWBLOCK form of the new Windows NT
 375          password encrypted with the old LAN Manager password hash, as
 376          output by the NewPasswordEncryptedWithOldLmPasswordHash()
 377          routine described in section A.15, below.  Note, however, that
 378          the use of this field has been deprecated: peers SHOULD NOT
 379          generate it, and this field SHOULD be zero-filled.
 380
 381       Old LM Hash Encrypted With New NT Hash
 382          This field contains the old LAN Manager password hash encrypted
 383          with the new Windows NT password hash, as output by the
 384          OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see
 385          section A.16, below).  Note, however, that the use of this
 386          field has been deprecated: peers SHOULD NOT generate it, and
 387          this field SHOULD be zero-filled.
 388
 389
 390
 391
 392
 393
 394 Zorn & Cobb                  Informational                      [Page 7]
 395 \f
 396 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 397
 398
 399       LAN Manager compatible challenge response
 400       Windows NT compatible challenge response
 401          The challenge response field (as described in the Response
 402          packet description), but calculated on the new password and the
 403          same challenge used in the last response.  Note that use of the
 404          LAN Manager compatible challenge response has been deprecated;
 405          peers SHOULD NOT generate it, and the field SHOULD be zero-
 406          filled.
 407
 408       Flags
 409          This field is two octets in length.  It is a bit field of
 410          option flags where 0 is the least significant bit of the 16-bit
 411          quantity.  The format of this field is illustrated in the
 412          following diagram:
 413
 414                    1
 415          5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
 416          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 417          |                           | |
 418          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 419
 420             Bit 0
 421                The "use Windows NT compatible challenge response" flag
 422                as described in the Response packet.
 423
 424             Bit 1
 425                Set (1) indicates that the "Password Encrypted with Old
 426                LM Hash" and "Old LM Hash Encrypted With New NT Hash"
 427                fields are valid and should be used.  Clear (0) indicates
 428                these fields are not valid.  This bit SHOULD always be
 429                clear (0).
 430
 431             Bits 2-15
 432                Reserved, always clear (0).
 433
 434 11.  Security Considerations
 435
 436    As an implementation detail, the authenticator SHOULD limit the
 437    number of password retries allowed to make brute-force password
 438    guessing attacks more difficult.
 439
 440    Because the challenge value is encrypted using the password hash to
 441    form the response and the challenge is transmitted in clear-text
 442    form, both passive known-plaintext and active chosen-plaintext
 443    attacks against the password hash are possible.  Suitable precautions
 444    (i.e., frequent password changes) SHOULD be taken in environments
 445    where eavesdropping is likely.
 446
 447
 448
 449
 450 Zorn & Cobb                  Informational                      [Page 8]
 451 \f
 452 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 453
 454
 455    The Change Password (version 1) packet is vulnerable to a passive
 456    eavesdropping attack which can easily reveal the new password hash.
 457    For this reason, it MUST NOT be sent if eavesdropping is possible.
 458
 459 12.  References
 460
 461    [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
 462        1661, July 1994.
 463
 464    [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol
 465        (CHAP)", RFC 1994, August 1996.
 466
 467    [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
 468        Levels", BCP 14, RFC 2119, March 1997.
 469
 470    [4] "Data Encryption Standard (DES)", Federal Information Processing
 471        Standard Publication 46-2, National Institute of Standards and
 472        Technology, December 1993.
 473
 474    [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992.
 475
 476    [6] RC4 is a proprietary encryption algorithm available under license
 477        from RSA Data Security Inc.  For licensing information, contact:
 478        RSA Data Security, Inc.
 479        100 Marine Parkway
 480        Redwood City, CA 94065-1031
 481
 482    [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
 483        Recomnendations for Security", RFC 1750, December 1994.
 484
 485    [8] "The Unicode Standard, Version 2.0", The Unicode Consortium,
 486        Addison-Wesley, 1996. ISBN 0-201-48345-9.
 487
 488    [9] "DES Modes of Operation", Federal Information Processing
 489        Standards Publication 81, National Institute of Standards and
 490        Technology, December 1980
 491
 492 13.  Acknowledgements
 493
 494    Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com),
 495    Bill Palter (palter@network-alchemy.com), Bruce Johnson
 496    (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit
 497    Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com)
 498    for useful suggestions and feedback.
 499
 500
 501
 502
 503
 504
 505
 506 Zorn & Cobb                  Informational                      [Page 9]
 507 \f
 508 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 509
 510
 511 14.  Chair's Address
 512
 513    The PPP Extensions Working Group can be contacted via the current
 514    chair:
 515
 516    Karl Fox
 517    Ascend Communications
 518    3518 Riverside Drive
 519    Suite 101
 520    Columbus, OH 43221
 521
 522    Phone: +1 614 326 6841
 523    EMail: karl@ascend.com
 524
 525 15.  Authors' Addresses
 526
 527    Questions about this memo can also be directed to:
 528
 529    Glen Zorn
 530    Microsoft Corporation
 531    One Microsoft Way
 532    Redmond, Washington 98052
 533
 534    Phone: +1 425 703 1559
 535    Fax:   +1 425 936 7329
 536    EMail: glennz@microsoft.com
 537
 538
 539    Steve Cobb
 540    Microsoft Corporation
 541    One Microsoft Way
 542    Redmond, Washington 98052
 543
 544    EMail: stevec@microsoft.com
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Zorn & Cobb                  Informational                     [Page 10]
 563 \f
 564 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 565
 566
 567 Appendix A - Pseudocode
 568
 569    The routines mentioned in the text are described in pseudocode below.
 570
 571 A.1 LmChallengeResponse()
 572
 573    LmChallengeResponse(
 574    IN  8-octet          Challenge,
 575    IN  0-to-14-oem-char Password,
 576    OUT 24-octet         Response )
 577    {
 578       LmPasswordHash( Password, giving PasswordHash )
 579       ChallengeResponse( Challenge, PasswordHash, giving Response )
 580    }
 581
 582
 583 A.2 LmPasswordHash()
 584
 585    LmPasswordHash(
 586    IN  0-to-14-oem-char Password,
 587    OUT 16-octet         PasswordHash )
 588    {
 589       Set UcasePassword to the uppercased Password
 590       Zero pad UcasePassword to 14 characters
 591
 592       DesHash( 1st 7-octets of UcasePassword,
 593                giving 1st 8-octets of PasswordHash )
 594
 595       DesHash( 2nd 7-octets of UcasePassword,
 596                giving 2nd 8-octets of PasswordHash )
 597    }
 598
 599
 600 A.3 DesHash()
 601
 602    DesHash(
 603    IN  7-octet Clear,
 604    OUT 8-octet Cypher )
 605    {
 606       /*
 607        * Make Cypher an irreversibly encrypted form of Clear by
 608        * encrypting known text using Clear as the secret key.
 609        * The known text consists of the string
 610        *
 611        *              KGS!@#$%
 612        */
 613
 614       Set StdText to "KGS!@#$%"
 615
 616
 617
 618 Zorn & Cobb                  Informational                     [Page 11]
 619 \f
 620 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 621
 622
 623       DesEncrypt( StdText, Clear, giving Cypher )
 624    }
 625
 626
 627 A.4 DesEncrypt()
 628
 629    DesEncrypt(
 630    IN  8-octet Clear,
 631    IN  7-octet Key,
 632    OUT 8-octet Cypher )
 633    {
 634       /*
 635        * Use the DES encryption algorithm [4] in ECB mode [9]
 636        * to encrypt Clear into Cypher such that Cypher can
 637        * only be decrypted back to Clear by providing Key.
 638        * Note that the DES algorithm takes as input a 64-bit
 639        * stream where the 8th, 16th, 24th, etc.  bits are
 640        * parity bits ignored by the encrypting algorithm.
 641        * Unless you write your own DES to accept 56-bit input
 642        * without parity, you will need to insert the parity bits
 643        * yourself.
 644        */
 645    }
 646
 647
 648 A.5 NtChallengeResponse()
 649
 650    NtChallengeResponse(
 651    IN  8-octet               Challenge,
 652    IN  0-to-256-unicode-char Password,
 653    OUT 24-octet              Response )
 654    {
 655       NtPasswordHash( Password, giving PasswordHash )
 656       ChallengeResponse( Challenge, PasswordHash, giving Response )
 657    }
 658
 659
 660 A.6 NtPasswordHash()
 661
 662    NtPasswordHash(
 663    IN  0-to-256-unicode-char Password,
 664    OUT 16-octet              PasswordHash )
 665    {
 666       /*
 667        * Use the MD4 algorithm [5] to irreversibly hash Password
 668        * into PasswordHash.  Only the password is hashed without
 669        * including any terminating 0.
 670        */
 671
 672
 673
 674 Zorn & Cobb                  Informational                     [Page 12]
 675 \f
 676 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 677
 678
 679    }
 680
 681
 682 A.7 ChallengeResponse()
 683
 684    ChallengeResponse(
 685    IN  8-octet  Challenge,
 686    IN  16-octet PasswordHash,
 687    OUT 24-octet Response )
 688    {
 689       Set ZPasswordHash to PasswordHash zero-padded to 21 octets
 690
 691       DesEncrypt( Challenge,
 692                   1st 7-octets of ZPasswordHash,
 693                   giving 1st 8-octets of Response )
 694
 695       DesEncrypt( Challenge,
 696                   2nd 7-octets of ZPasswordHash,
 697                   giving 2nd 8-octets of Response )
 698
 699       DesEncrypt( Challenge,
 700                   3rd 7-octets of ZPasswordHash,
 701                   giving 3rd 8-octets of Response )
 702    }
 703
 704
 705 A.8 LmEncryptedPasswordHash()
 706
 707    LmEncryptedPasswordHash(
 708    IN  0-to-14-oem-char Password,
 709    IN  8-octet          KeyValue,
 710    OUT 16-octet         Cypher )
 711    {
 712       LmPasswordHash( Password, giving PasswordHash )
 713
 714       PasswordHashEncryptedWithBlock( PasswordHash,
 715                                       KeyValue,
 716                                       giving Cypher )
 717    }
 718
 719
 720 A.9 PasswordHashEncryptedWithBlock()
 721
 722    PasswordHashEncryptedWithBlock(
 723    IN  16-octet PasswordHash,
 724    IN  8-octet  Block,
 725    OUT 16-octet Cypher )
 726    {
 727
 728
 729
 730 Zorn & Cobb                  Informational                     [Page 13]
 731 \f
 732 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 733
 734
 735       DesEncrypt( 1st 8-octets PasswordHash,
 736                   1st 7-octets Block,
 737                   giving 1st 8-octets Cypher )
 738
 739       DesEncrypt( 2nd 8-octets PasswordHash,
 740                   1st 7-octets Block,
 741                   giving 2nd 8-octets Cypher )
 742    }
 743
 744
 745 A.10 NtEncryptedPasswordHash()
 746
 747    NtEncryptedPasswordHash(  IN   0-to-14-oem-char  Password IN  8-octet
 748    Challenge OUT 16-octet         Cypher ) {
 749       NtPasswordHash( Password, giving PasswordHash )
 750
 751       PasswordHashEncryptedWithBlock( PasswordHash,
 752                                       Challenge,
 753                                       giving Cypher )
 754    }
 755
 756
 757 A.11 NewPasswordEncryptedWithOldNtPasswordHash()
 758
 759    datatype-PWBLOCK
 760    {
 761       256-unicode-char Password
 762       4-octets         PasswordLength
 763    }
 764
 765    NewPasswordEncryptedWithOldNtPasswordHash(
 766    IN  0-to-256-unicode-char NewPassword,
 767    IN  0-to-256-unicode-char OldPassword,
 768    OUT datatype-PWBLOCK      EncryptedPwBlock )
 769    {
 770       NtPasswordHash( OldPassword, giving PasswordHash )
 771
 772       EncryptPwBlockWithPasswordHash( NewPassword,
 773                                       PasswordHash,
 774                                       giving EncryptedPwBlock )
 775    }
 776
 777
 778 A.12 EncryptPwBlockWithPasswordHash()
 779
 780    EncryptPwBlockWithPasswordHash(
 781    IN  0-to-256-unicode-char Password,
 782    IN  16-octet              PasswordHash,
 783
 784
 785
 786 Zorn & Cobb                  Informational                     [Page 14]
 787 \f
 788 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 789
 790
 791    OUT datatype-PWBLOCK      PwBlock )
 792    {
 793
 794       Fill ClearPwBlock with random octet values
 795       PwSize = lstrlenW( Password ) * sizeof( unicode-char )
 796       PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
 797       Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password
 798       ClearPwBlock.PasswordLength = PwSize
 799       Rc4Encrypt( ClearPwBlock,
 800                   sizeof( ClearPwBlock ),
 801                   PasswordHash,
 802                   sizeof( PasswordHash ),
 803                   giving PwBlock )
 804    }
 805
 806
 807 A.13 Rc4Encrypt()
 808
 809    Rc4Encrypt(
 810    IN  x-octet Clear,
 811    IN  integer ClearLength,
 812    IN  y-octet Key,
 813    IN  integer KeyLength,
 814    OUT x-octet Cypher )
 815    {
 816       /*
 817        * Use the RC4 encryption algorithm [6] to encrypt Clear of
 818        * length ClearLength octets into a Cypher of the same length
 819        * such that the Cypher can only be decrypted back to Clear
 820        * by providing a Key of length KeyLength octets.
 821        */
 822    }
 823
 824
 825 A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash()
 826
 827    OldNtPasswordHashEncryptedWithNewNtPasswordHash(
 828    IN  0-to-256-unicode-char NewPassword,
 829    IN  0-to-256-unicode-char OldPassword,
 830    OUT 16-octet              EncryptedPasswordHash )
 831    {
 832       NtPasswordHash( OldPassword, giving OldPasswordHash )
 833       NtPasswordHash( NewPassword, giving NewPasswordHash )
 834       NtPasswordHashEncryptedWithBlock( OldPasswordHash,
 835                                         NewPasswordHash,
 836                                         giving EncryptedPasswordHash )
 837    }
 838
 839
 840
 841
 842 Zorn & Cobb                  Informational                     [Page 15]
 843 \f
 844 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 845
 846
 847 A.15 NewPasswordEncryptedWithOldLmPasswordHash()
 848
 849    NewPasswordEncryptedWithOldLmPasswordHash(
 850    IN  0-to-256-unicode-char NewPassword,
 851    IN  0-to-256-unicode-char OldPassword,
 852    OUT datatype-PWBLOCK      EncryptedPwBlock )
 853    {
 854       LmPasswordHash( OldPassword, giving PasswordHash )
 855
 856       EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash,
 857                                       giving EncryptedPwBlock )
 858    }
 859
 860
 861 A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash()
 862
 863    OldLmPasswordHashEncryptedWithNewNtPasswordHash(
 864    IN  0-to-256-unicode-char NewPassword,
 865    IN  0-to-256-unicode-char OldPassword,
 866    OUT 16-octet              EncryptedPasswordHash )
 867    {
 868       LmPasswordHash( OldPassword, giving OldPasswordHash )
 869
 870       NtPasswordHash( NewPassword, giving NewPasswordHash )
 871
 872       NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash,
 873                                       giving EncrytptedPasswordHash )
 874    }
 875
 876
 877 A.17 NtPasswordHashEncryptedWithBlock()
 878
 879    NtPasswordHashEncryptedWithBlock(
 880    IN  16-octet PasswordHash,
 881    IN  16-octet Block,
 882    OUT 16-octet Cypher )
 883    {
 884       DesEncrypt( 1st 8-octets PasswordHash,
 885                   1st 7-octets Block,
 886                   giving 1st 8-octets Cypher )
 887
 888       DesEncrypt( 2nd 8-octets PasswordHash,
 889                   2nd 7-octets Block,
 890                   giving 2nd 8-octets Cypher )
 891    }
 892
 893
 894
 895
 896
 897
 898 Zorn & Cobb                  Informational                     [Page 16]
 899 \f
 900 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 901
 902
 903 Appendix B - Examples
 904
 905 B.1 Negotiation Examples
 906
 907    Here are some examples of typical negotiations.  The peer is on the
 908    left and the authenticator is on the right.
 909
 910    The packet sequence ID is incremented on each authentication retry
 911    Response and on the change password response.  All cases where the
 912    packet sequence ID is updated are noted below.
 913
 914    Response retry is never allowed after Change Password.  Change
 915    Password may occur after Response retry.  The implied challenge form
 916    is shown in the examples, though all cases of "first challenge+23"
 917    should be replaced by the "C=cccccccccccccccc" challenge if
 918    authenticator supplies it in the Failure packet.
 919
 920 B.1.1 Successful authentication
 921
 922             <- Challenge
 923         Response ->
 924             <- Success
 925
 926
 927 B.1.2 Failed authentication with no retry allowed
 928
 929             <- Challenge
 930         Response ->
 931             <- Failure (E=691 R=0)
 932
 933
 934 B.1.3 Successful authentication after retry
 935
 936             <- Challenge
 937         Response ->
 938             <- Failure (E=691 R=1), disable short timeout
 939         Response (++ID) to first challenge+23 ->
 940             <- Success
 941
 942
 943 B.1.4 Failed hack attack with 3 attempts allowed
 944
 945             <- Challenge
 946         Response ->
 947             <- Failure (E=691 R=1), disable short timeout
 948         Response (++ID) to first challenge+23 ->
 949             <- Failure (E=691 R=1), disable short timeout
 950         Response (++ID) to first challenge+23+23 ->
 951
 952
 953
 954 Zorn & Cobb                  Informational                     [Page 17]
 955 \f
 956 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
 957
 958
 959             <- Failure (E=691 R=0)
 960
 961
 962 B.1.5 Successful authentication with password change
 963
 964             <- Challenge
 965         Response ->
 966             <- Failure (E=648 R=0 V=2), disable short timeout
 967         ChangePassword (++ID) to first challenge ->
 968             <- Success
 969
 970
 971 B.1.6 Successful authentication with retry and password change
 972
 973             <- Challenge
 974         Response ->
 975             <- Failure (E=691 R=1), disable short timeout
 976         Response (++ID) to first challenge+23 ->
 977             <- Failure (E=648 R=0 V=2), disable short timeout
 978         ChangePassword (++ID) to first challenge+23 ->
 979             <- Success
 980
 981 B.2 Hash Example
 982
 983 Intermediate values for password "MyPw".
 984
 985    8-octet Challenge:
 986    10 2D B5 DF 08 5D 30 41
 987
 988    0-to-256-unicode-char NtPassword:
 989    4D 00 79 00 50 00 77 00
 990
 991    16-octet NtPasswordHash:
 992    FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
 993
 994    24-octet NtChallengeResponse:
 995    4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C
 996    A4 C3 51 AB 40 9A 3D 61
 997
 998 B.3 Example of DES Key Generation
 999
1000 DES uses 56-bit keys, expanded to 64 bits by the insertion of parity
1001 bits.  After the parity of the key has been fixed, every eighth bit is a
1002 parity bit and the number of bits that are set (1) in each octet is odd;
1003 i.e., odd parity.  Note that many DES engines do not check parity,
1004 however, simply stripping the parity bits.  The following example
1005 illustrates the values resulting from the use of the 16-octet
1006 NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys
1007
1008
1009
1010 Zorn & Cobb                  Informational                     [Page 18]
1011 \f
1012 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
1013
1014
1015 (e.g., for use in the NtPasswordHashEncryptedWithBlock() described in
1016 Appendix A.17).
1017
1018    16-octet NtPasswordHash:
1019    FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
1020
1021    First "raw" DES key (initial 7 octets of password hash):
1022    FC 15 6A F7 ED CD 6C
1023
1024    First parity-corrected DES key (eight octets):
1025    FD 0B 5B 5E 7F 6E 34 D9
1026
1027    Second "raw" DES key (second 7 octets of password hash)
1028    0E DD E3 33 7D 42 7F
1029
1030    Second parity-corrected DES key (eight octets):
1031    0E 6E 79 67 37 EA 08 FE
1032
1033
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 & Cobb                  Informational                     [Page 19]
1067 \f
1068 RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
1069
1070
1071 Full Copyright Statement
1072
1073    Copyright (C) The Internet Society (1998).  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
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122 Zorn & Cobb                  Informational                     [Page 20]
1123 \f