doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc2433.txt b/doc/rfc/rfc2433.txt
new file mode 100644
index 0000000..3536e72
--- /dev/null
+++ b/doc/rfc/rfc2433.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                            G. Zorn
+Request for Comments: 2433                                       S. Cobb
+Category: Informational                            Microsoft Corporation
+                                                            October 1998
+
+
+                     Microsoft PPP CHAP Extensions
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+IESG Note
+
+   The protocol described here has significant vulnerabilities.  People
+   planning on implementing or using this protocol should read section
+   12, "Security Considerations".
+
+1.  Abstract
+
+   The Point-to-Point Protocol (PPP) [1] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.  PPP
+   defines an extensible Link Control Protocol and a family of Network
+   Control Protocols (NCPs) for establishing and configuring different
+   network-layer protocols.
+
+   This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which
+   extends the user authentication functionality provided on Windows
+   networks to remote workstations.  MS-CHAP is closely derived from the
+   PPP Challenge Handshake Authentication Protocol described in RFC 1994
+   [2], which the reader should have at hand.
+
+   The algorithms used in the generation of various MS-CHAP protocol
+   fields are described in an appendix.
+
+2.  Introduction
+
+   Microsoft created MS-CHAP to authenticate remote Windows
+   workstations, providing the functionality to which LAN-based users
+   are accustomed while integrating the encryption and hashing
+   algorithms used on Windows networks.
+
+
+
+
+Zorn & Cobb                  Informational                      [Page 1]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+   Where possible, MS-CHAP is consistent with standard CHAP.  Briefly,
+   the differences between MS-CHAP and standard CHAP are:
+
+      * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
+        option 3, Authentication Protocol.
+
+      * The MS-CHAP Response packet is in a format designed for
+        compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and
+        Windows95 networking products.  The MS-CHAP format does not
+        require the authenticator to store a clear-text or reversibly
+        encrypted password.
+
+      * MS-CHAP provides authenticator-controlled authentication retry
+        and password changing mechanisms.
+
+      * MS-CHAP defines a set of reason-for-failure codes returned in
+        the Failure packet Message field.
+
+3.  Specification of Requirements
+
+   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+   "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
+   described in [2].
+
+4.  LCP Configuration
+
+   The LCP configuration for MS-CHAP is identical to that for standard
+   CHAP, except that the Algorithm field has value 0x80, rather than the
+   MD5 value 0x05.  PPP implementations which do not support MS-CHAP,
+   but correctly implement LCP Config-Rej, should have no problem
+   dealing with this non-standard option.
+
+5.  Challenge Packet
+
+   The MS-CHAP Challenge packet is identical in format to the standard
+   CHAP Challenge packet.
+
+   MS-CHAP authenticators send an 8-octet challenge Value field.  Peers
+   need not duplicate Microsoft's algorithm for selecting the 8-octet
+   value, but the standard guidelines on randomness [1,2,7] SHOULD be
+   observed.
+
+   Microsoft authenticators do not currently provide information in the
+   Name field.  This may change in the future.
+
+
+
+
+
+
+
+Zorn & Cobb                  Informational                      [Page 2]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+6.  Response Packet
+
+   The MS-CHAP Response packet is identical in format to the standard
+   CHAP Response packet.  However, the Value field is sub-formatted
+   differently as follows:
+
+      24 octets: LAN Manager compatible challenge response
+      24 octets: Windows NT compatible challenge response
+       1 octet : "Use Windows NT compatible challenge response" flag
+
+   The LAN Manager compatible challenge response is an encoded function
+   of the password and the received challenge as output by the routine
+   LmChallengeResponse() (see section A.1, below).  LAN Manager
+   passwords are limited to 14 case-insensitive OEM characters.  Note
+   that use of the LAN Manager compatible challenge response has been
+   deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be
+   zero-filled.  The algorithm used in the generation of the LAN Manager
+   compatible challenge response is described here for informational
+   purposes only.
+
+   The Windows NT compatible challenge response is an encoded function
+   of the password and the received challenge as output by the routine
+   NTChallengeResponse() (see section A.5, below).  The Windows NT
+   password is a string of 0 to (theoretically) 256 case-sensitive
+   Unicode [8] characters.  Current versions of Windows NT limit
+   passwords to 14 characters, mainly for compatibility reasons; this
+   may change in the future.
+
+   The "use Windows NT compatible challenge response" flag, if 1,
+   indicates that the Windows NT response is provided and should be used
+   in preference to the LAN Manager response.  The LAN Manager response
+   will still be used if the account does not have a Windows NT password
+   hash, e.g.  if the password has not been changed since the account
+   was uploaded from a LAN Manager 2.x account database.  If the flag is
+   0, the Windows NT response is ignored and the LAN Manager response is
+   used.  Since the use of LAN Manager authentication has been
+   deprecated, this flag SHOULD always be set (1) and the LAN Manager
+   compatible challenge response field SHOULD be zero-filled.
+
+   The Name field identifies the peer's user account name.  The Windows
+   NT domain name may prefix the user's account name (e.g.
+   "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the
+   user account "john-doe").  If a domain is not provided, the backslash
+   should also be omitted, (e.g. "johndoe").
+
+
+
+
+
+
+
+Zorn & Cobb                  Informational                      [Page 3]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+7.  Success Packet
+
+   The Success packet is identical in format to the standard CHAP
+   Success packet.
+
+8.  Failure Packet
+
+   The Failure packet is identical in format to the standard CHAP
+   Failure packet.  There is, however, formatted text stored in the
+   Message field which, contrary to the standard CHAP rules, affects the
+   protocol.  The Message field format is:
+
+         "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"
+
+      where
+
+         The "eeeeeeeeee" is the decimal error code (need not be 10
+         digits) corresponding to one of those listed below, though
+         implementations should deal with codes not on this list
+         gracefully.
+
+            646 ERROR_RESTRICTED_LOGON_HOURS
+            647 ERROR_ACCT_DISABLED
+            648 ERROR_PASSWD_EXPIRED
+            649 ERROR_NO_DIALIN_PERMISSION
+            691 ERROR_AUTHENTICATION_FAILURE
+            709 ERROR_CHANGING_PASSWORD
+
+         The "r" is a flag set to "1" if a retry is allowed, and "0" if
+         not.  When the authenticator sets this flag to "1" it disables
+         short timeouts, expecting the peer to prompt the user for new
+         credentials and resubmit the response.
+
+         The "cccccccccccccccc" is 16 hexadecimal digits representing an
+         ASCII representation of a new challenge value.  This field is
+         optional.  If it is not sent, the authenticator expects the
+         resubmitted response to be calculated based on the previous
+         challenge value plus decimal 23 in the first octet, i.e. the
+         one immediately following the Value Size field.  Windows 95
+         authenticators may send this field.  Windows NT authenticators
+         do not, but may in the future.  Both systems implement peer
+         support of this field.
+
+         The "vvvvvvvvvv" is the decimal version code (need not be 10
+         digits) indicating the MS-CHAP protocol version supported on
+         the server.  Currently, this is interesting only in selecting a
+         Change Password packet type.  If the field is not present the
+         version should be assumed to be 1; since use of the version 1
+
+
+
+Zorn & Cobb                  Informational                      [Page 4]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+         Change Password packet has been deprecated, this field SHOULD
+         always contain a value greater than or equal to 2.
+
+   Implementations should accept but ignore additional text they do not
+   recognize.
+
+9.  Change Password Packet (version 1)
+
+   The version 1 Change Password packet does not appear in standard
+   CHAP.  It allows the peer to change the password on the account
+   specified in the previous Response packet.  The version 1 Change
+   Password packet should be sent only if the authenticator reports
+   ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to one
+   in the Message field of the Failure packet.
+
+   The use of the Change Password Packet (version 1) has been
+   deprecated; the format of the packet is described here for
+   informational purposes, but peers SHOULD NOT transmit it.
+
+   The format of this packet is as follows:
+
+       1 octet : Code (=5)
+       1 octet : Identifier
+       2 octets: Length (=72)
+      16 octets: Encrypted LAN Manager Old password Hash
+      16 octets: Encrypted LAN Manager New Password Hash
+      16 octets: Encrypted Windows NT Old Password Hash
+      16 octets: Encrypted Windows NT New Password Hash
+       2 octets: Password Length
+       2 octets: Flags
+
+      Code
+         5
+
+      Identifier
+         The Identifier field is one octet and aids in matching requests
+         and replies.  The value is the Identifier of the received
+         Failure packet to which this packet responds plus 1.
+
+      Length
+         72
+
+      Encrypted LAN Manager New Password Hash
+      Encrypted LAN Manager Old Password Hash
+         These fields contain the LAN Manager password hash of the new
+         and old passwords encrypted with the last received challenge
+         value, as output by the routine LmEncryptedPasswordHash() (see
+         section A.8, below).
+
+
+
+Zorn & Cobb                  Informational                      [Page 5]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+      Encrypted Windows NT New Password Hash
+      Encrypted Windows NT Old Password Hash
+         These fields contain the Windows NT password hash of the new
+         and old passwords encrypted with the last received challenge
+         value, as output by the pseudo-code routine
+         NtEncryptedPasswordHash() (see section A.10, below).
+
+      Password Length
+         The length in octets of the LAN Manager compatible form of the
+         new password.  If this value is greater than or equal to zero
+         and less than or equal to 14 it is assumed that the encrypted
+         LAN Manager password hash fields are valid.  Otherwise, it is
+         assumed these fields are not valid, in which case the Windows
+         NT compatible passwords MUST be provided.
+
+      Flags
+         This field is two octets in length.  It is a bit field of
+         option flags where 0 is the least significant bit of the 16-bit
+         quantity:
+
+            Bit 0
+               If this bit is set (1), it indicates that the encrypted
+               Windows NT hashed passwords are valid and should be used.
+               If this bit is cleared (0), the Windows NT fields are not
+               used and the LAN Manager fields must be provided.
+
+            Bits 1-15
+               Reserved, always clear (0).
+
+10.  Change Password Packet (version 2)
+
+   The version 2 Change Password packet does not appear in standard
+   CHAP.  It allows the peer to change the password on the account
+   specified in the preceding Response packet.  The version 2 Change
+   Password packet should be sent only if the authenticator reports
+   ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in the
+   Message field of the Failure packet.
+
+   This packet type is supported by Windows NT 3.51, 4.0 and recent
+   versions of Windows 95.  It is not supported by Windows NT 3.5 or
+   early versions of Windows 95.
+
+      The format of this packet is as follows:
+
+           1 octet  : Code
+           1 octet  : Identifier
+           2 octets : Length
+         516 octets : Password Encrypted with Old NT Hash
+
+
+
+Zorn & Cobb                  Informational                      [Page 6]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+          16 octets : Old NT Hash Encrypted with New NT Hash
+         516 octets : Password Encrypted with Old LM Hash
+          16 octets : Old LM Hash Encrypted With New NT Hash
+          24 octets : LAN Manager compatible challenge response
+          24 octets : Windows NT compatible challenge response
+           2-octet  : Flags
+
+      Code
+         6
+
+      Identifier
+         The Identifier field is one octet and aids in matching requests
+         and replies.  The value is the Identifier of the received
+         Failure packet to which this packet responds plus 1.
+
+      Length
+         1118
+
+      Password Encrypted with Old NT Hash
+         This field contains the PWBLOCK form of the new Windows NT
+         password encrypted with the old Windows NT password hash, as
+         output by the NewPasswordEncryptedWithOldNtPasswordHash()
+         routine (see section A.11, below).
+
+      Old NT Hash Encrypted with New NT Hash
+         This field contains the old Windows NT password hash encrypted
+         with the new Windows NT password hash, as output by the
+         OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see
+         section A.14, below).
+
+      Password Encrypted with Old LM Hash
+         This field contains the PWBLOCK form of the new Windows NT
+         password encrypted with the old LAN Manager password hash, as
+         output by the NewPasswordEncryptedWithOldLmPasswordHash()
+         routine described in section A.15, below.  Note, however, that
+         the use of this field has been deprecated: peers SHOULD NOT
+         generate it, and this field SHOULD be zero-filled.
+
+      Old LM Hash Encrypted With New NT Hash
+         This field contains the old LAN Manager password hash encrypted
+         with the new Windows NT password hash, as output by the
+         OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see
+         section A.16, below).  Note, however, that the use of this
+         field has been deprecated: peers SHOULD NOT generate it, and
+         this field SHOULD be zero-filled.
+
+
+
+
+
+
+Zorn & Cobb                  Informational                      [Page 7]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+      LAN Manager compatible challenge response
+      Windows NT compatible challenge response
+         The challenge response field (as described in the Response
+         packet description), but calculated on the new password and the
+         same challenge used in the last response.  Note that use of the
+         LAN Manager compatible challenge response has been deprecated;
+         peers SHOULD NOT generate it, and the field SHOULD be zero-
+         filled.
+
+      Flags
+         This field is two octets in length.  It is a bit field of
+         option flags where 0 is the least significant bit of the 16-bit
+         quantity.  The format of this field is illustrated in the
+         following diagram:
+
+                   1
+         5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         |                           | |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+            Bit 0
+               The "use Windows NT compatible challenge response" flag
+               as described in the Response packet.
+
+            Bit 1
+               Set (1) indicates that the "Password Encrypted with Old
+               LM Hash" and "Old LM Hash Encrypted With New NT Hash"
+               fields are valid and should be used.  Clear (0) indicates
+               these fields are not valid.  This bit SHOULD always be
+               clear (0).
+
+            Bits 2-15
+               Reserved, always clear (0).
+
+11.  Security Considerations
+
+   As an implementation detail, the authenticator SHOULD limit the
+   number of password retries allowed to make brute-force password
+   guessing attacks more difficult.
+
+   Because the challenge value is encrypted using the password hash to
+   form the response and the challenge is transmitted in clear-text
+   form, both passive known-plaintext and active chosen-plaintext
+   attacks against the password hash are possible.  Suitable precautions
+   (i.e., frequent password changes) SHOULD be taken in environments
+   where eavesdropping is likely.
+
+
+
+
+Zorn & Cobb                  Informational                      [Page 8]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+   The Change Password (version 1) packet is vulnerable to a passive
+   eavesdropping attack which can easily reveal the new password hash.
+   For this reason, it MUST NOT be sent if eavesdropping is possible.
+
+12.  References
+
+   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+       1661, July 1994.
+
+   [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol
+       (CHAP)", RFC 1994, August 1996.
+
+   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [4] "Data Encryption Standard (DES)", Federal Information Processing
+       Standard Publication 46-2, National Institute of Standards and
+       Technology, December 1993.
+
+   [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992.
+
+   [6] RC4 is a proprietary encryption algorithm available under license
+       from RSA Data Security Inc.  For licensing information, contact:
+       RSA Data Security, Inc.
+       100 Marine Parkway
+       Redwood City, CA 94065-1031
+
+   [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
+       Recomnendations for Security", RFC 1750, December 1994.
+
+   [8] "The Unicode Standard, Version 2.0", The Unicode Consortium,
+       Addison-Wesley, 1996. ISBN 0-201-48345-9.
+
+   [9] "DES Modes of Operation", Federal Information Processing
+       Standards Publication 81, National Institute of Standards and
+       Technology, December 1980
+
+13.  Acknowledgements
+
+   Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com),
+   Bill Palter (palter@network-alchemy.com), Bruce Johnson
+   (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit
+   Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com)
+   for useful suggestions and feedback.
+
+
+
+
+
+
+
+Zorn & Cobb                  Informational                      [Page 9]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+14.  Chair's Address
+
+   The PPP Extensions Working Group can be contacted via the current
+   chair:
+
+   Karl Fox
+   Ascend Communications
+   3518 Riverside Drive
+   Suite 101
+   Columbus, OH 43221
+
+   Phone: +1 614 326 6841
+   EMail: karl@ascend.com
+
+15.  Authors' Addresses
+
+   Questions about this memo can also be directed to:
+
+   Glen Zorn
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, Washington 98052
+
+   Phone: +1 425 703 1559
+   Fax:   +1 425 936 7329
+   EMail: glennz@microsoft.com
+
+
+   Steve Cobb
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, Washington 98052
+
+   EMail: stevec@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn & Cobb                  Informational                     [Page 10]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+Appendix A - Pseudocode
+
+   The routines mentioned in the text are described in pseudocode below.
+
+A.1 LmChallengeResponse()
+
+   LmChallengeResponse(
+   IN  8-octet          Challenge,
+   IN  0-to-14-oem-char Password,
+   OUT 24-octet         Response )
+   {
+      LmPasswordHash( Password, giving PasswordHash )
+      ChallengeResponse( Challenge, PasswordHash, giving Response )
+   }
+
+
+A.2 LmPasswordHash()
+
+   LmPasswordHash(
+   IN  0-to-14-oem-char Password,
+   OUT 16-octet         PasswordHash )
+   {
+      Set UcasePassword to the uppercased Password
+      Zero pad UcasePassword to 14 characters
+
+      DesHash( 1st 7-octets of UcasePassword,
+               giving 1st 8-octets of PasswordHash )
+
+      DesHash( 2nd 7-octets of UcasePassword,
+               giving 2nd 8-octets of PasswordHash )
+   }
+
+
+A.3 DesHash()
+
+   DesHash(
+   IN  7-octet Clear,
+   OUT 8-octet Cypher )
+   {
+      /*
+       * Make Cypher an irreversibly encrypted form of Clear by
+       * encrypting known text using Clear as the secret key.
+       * The known text consists of the string
+       *
+       *              KGS!@#$%
+       */
+
+      Set StdText to "KGS!@#$%"
+
+
+
+Zorn & Cobb                  Informational                     [Page 11]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+      DesEncrypt( StdText, Clear, giving Cypher )
+   }
+
+
+A.4 DesEncrypt()
+
+   DesEncrypt(
+   IN  8-octet Clear,
+   IN  7-octet Key,
+   OUT 8-octet Cypher )
+   {
+      /*
+       * Use the DES encryption algorithm [4] in ECB mode [9]
+       * to encrypt Clear into Cypher such that Cypher can
+       * only be decrypted back to Clear by providing Key.
+       * Note that the DES algorithm takes as input a 64-bit
+       * stream where the 8th, 16th, 24th, etc.  bits are
+       * parity bits ignored by the encrypting algorithm.
+       * Unless you write your own DES to accept 56-bit input
+       * without parity, you will need to insert the parity bits
+       * yourself.
+       */
+   }
+
+
+A.5 NtChallengeResponse()
+
+   NtChallengeResponse(
+   IN  8-octet               Challenge,
+   IN  0-to-256-unicode-char Password,
+   OUT 24-octet              Response )
+   {
+      NtPasswordHash( Password, giving PasswordHash )
+      ChallengeResponse( Challenge, PasswordHash, giving Response )
+   }
+
+
+A.6 NtPasswordHash()
+
+   NtPasswordHash(
+   IN  0-to-256-unicode-char Password,
+   OUT 16-octet              PasswordHash )
+   {
+      /*
+       * Use the MD4 algorithm [5] to irreversibly hash Password
+       * into PasswordHash.  Only the password is hashed without
+       * including any terminating 0.
+       */
+
+
+
+Zorn & Cobb                  Informational                     [Page 12]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+   }
+
+
+A.7 ChallengeResponse()
+
+   ChallengeResponse(
+   IN  8-octet  Challenge,
+   IN  16-octet PasswordHash,
+   OUT 24-octet Response )
+   {
+      Set ZPasswordHash to PasswordHash zero-padded to 21 octets
+
+      DesEncrypt( Challenge,
+                  1st 7-octets of ZPasswordHash,
+                  giving 1st 8-octets of Response )
+
+      DesEncrypt( Challenge,
+                  2nd 7-octets of ZPasswordHash,
+                  giving 2nd 8-octets of Response )
+
+      DesEncrypt( Challenge,
+                  3rd 7-octets of ZPasswordHash,
+                  giving 3rd 8-octets of Response )
+   }
+
+
+A.8 LmEncryptedPasswordHash()
+
+   LmEncryptedPasswordHash(
+   IN  0-to-14-oem-char Password,
+   IN  8-octet          KeyValue,
+   OUT 16-octet         Cypher )
+   {
+      LmPasswordHash( Password, giving PasswordHash )
+
+      PasswordHashEncryptedWithBlock( PasswordHash,
+                                      KeyValue,
+                                      giving Cypher )
+   }
+
+
+A.9 PasswordHashEncryptedWithBlock()
+
+   PasswordHashEncryptedWithBlock(
+   IN  16-octet PasswordHash,
+   IN  8-octet  Block,
+   OUT 16-octet Cypher )
+   {
+
+
+
+Zorn & Cobb                  Informational                     [Page 13]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+      DesEncrypt( 1st 8-octets PasswordHash,
+                  1st 7-octets Block,
+                  giving 1st 8-octets Cypher )
+
+      DesEncrypt( 2nd 8-octets PasswordHash,
+                  1st 7-octets Block,
+                  giving 2nd 8-octets Cypher )
+   }
+
+
+A.10 NtEncryptedPasswordHash()
+
+   NtEncryptedPasswordHash(  IN   0-to-14-oem-char  Password IN  8-octet
+   Challenge OUT 16-octet         Cypher ) {
+      NtPasswordHash( Password, giving PasswordHash )
+
+      PasswordHashEncryptedWithBlock( PasswordHash,
+                                      Challenge,
+                                      giving Cypher )
+   }
+
+
+A.11 NewPasswordEncryptedWithOldNtPasswordHash()
+
+   datatype-PWBLOCK
+   {
+      256-unicode-char Password
+      4-octets         PasswordLength
+   }
+
+   NewPasswordEncryptedWithOldNtPasswordHash(
+   IN  0-to-256-unicode-char NewPassword,
+   IN  0-to-256-unicode-char OldPassword,
+   OUT datatype-PWBLOCK      EncryptedPwBlock )
+   {
+      NtPasswordHash( OldPassword, giving PasswordHash )
+
+      EncryptPwBlockWithPasswordHash( NewPassword,
+                                      PasswordHash,
+                                      giving EncryptedPwBlock )
+   }
+
+
+A.12 EncryptPwBlockWithPasswordHash()
+
+   EncryptPwBlockWithPasswordHash(
+   IN  0-to-256-unicode-char Password,
+   IN  16-octet              PasswordHash,
+
+
+
+Zorn & Cobb                  Informational                     [Page 14]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+   OUT datatype-PWBLOCK      PwBlock )
+   {
+
+      Fill ClearPwBlock with random octet values
+      PwSize = lstrlenW( Password ) * sizeof( unicode-char )
+      PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
+      Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password
+      ClearPwBlock.PasswordLength = PwSize
+      Rc4Encrypt( ClearPwBlock,
+                  sizeof( ClearPwBlock ),
+                  PasswordHash,
+                  sizeof( PasswordHash ),
+                  giving PwBlock )
+   }
+
+
+A.13 Rc4Encrypt()
+
+   Rc4Encrypt(
+   IN  x-octet Clear,
+   IN  integer ClearLength,
+   IN  y-octet Key,
+   IN  integer KeyLength,
+   OUT x-octet Cypher )
+   {
+      /*
+       * Use the RC4 encryption algorithm [6] to encrypt Clear of
+       * length ClearLength octets into a Cypher of the same length
+       * such that the Cypher can only be decrypted back to Clear
+       * by providing a Key of length KeyLength octets.
+       */
+   }
+
+
+A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash()
+
+   OldNtPasswordHashEncryptedWithNewNtPasswordHash(
+   IN  0-to-256-unicode-char NewPassword,
+   IN  0-to-256-unicode-char OldPassword,
+   OUT 16-octet              EncryptedPasswordHash )
+   {
+      NtPasswordHash( OldPassword, giving OldPasswordHash )
+      NtPasswordHash( NewPassword, giving NewPasswordHash )
+      NtPasswordHashEncryptedWithBlock( OldPasswordHash,
+                                        NewPasswordHash,
+                                        giving EncryptedPasswordHash )
+   }
+
+
+
+
+Zorn & Cobb                  Informational                     [Page 15]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+A.15 NewPasswordEncryptedWithOldLmPasswordHash()
+
+   NewPasswordEncryptedWithOldLmPasswordHash(
+   IN  0-to-256-unicode-char NewPassword,
+   IN  0-to-256-unicode-char OldPassword,
+   OUT datatype-PWBLOCK      EncryptedPwBlock )
+   {
+      LmPasswordHash( OldPassword, giving PasswordHash )
+
+      EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash,
+                                      giving EncryptedPwBlock )
+   }
+
+
+A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash()
+
+   OldLmPasswordHashEncryptedWithNewNtPasswordHash(
+   IN  0-to-256-unicode-char NewPassword,
+   IN  0-to-256-unicode-char OldPassword,
+   OUT 16-octet              EncryptedPasswordHash )
+   {
+      LmPasswordHash( OldPassword, giving OldPasswordHash )
+
+      NtPasswordHash( NewPassword, giving NewPasswordHash )
+
+      NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash,
+                                      giving EncrytptedPasswordHash )
+   }
+
+
+A.17 NtPasswordHashEncryptedWithBlock()
+
+   NtPasswordHashEncryptedWithBlock(
+   IN  16-octet PasswordHash,
+   IN  16-octet Block,
+   OUT 16-octet Cypher )
+   {
+      DesEncrypt( 1st 8-octets PasswordHash,
+                  1st 7-octets Block,
+                  giving 1st 8-octets Cypher )
+
+      DesEncrypt( 2nd 8-octets PasswordHash,
+                  2nd 7-octets Block,
+                  giving 2nd 8-octets Cypher )
+   }
+
+
+
+
+
+
+Zorn & Cobb                  Informational                     [Page 16]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+Appendix B - Examples
+
+B.1 Negotiation Examples
+
+   Here are some examples of typical negotiations.  The peer is on the
+   left and the authenticator is on the right.
+
+   The packet sequence ID is incremented on each authentication retry
+   Response and on the change password response.  All cases where the
+   packet sequence ID is updated are noted below.
+
+   Response retry is never allowed after Change Password.  Change
+   Password may occur after Response retry.  The implied challenge form
+   is shown in the examples, though all cases of "first challenge+23"
+   should be replaced by the "C=cccccccccccccccc" challenge if
+   authenticator supplies it in the Failure packet.
+
+B.1.1 Successful authentication
+
+            <- Challenge
+        Response ->
+            <- Success
+
+
+B.1.2 Failed authentication with no retry allowed
+
+            <- Challenge
+        Response ->
+            <- Failure (E=691 R=0)
+
+
+B.1.3 Successful authentication after retry
+
+            <- Challenge
+        Response ->
+            <- Failure (E=691 R=1), disable short timeout
+        Response (++ID) to first challenge+23 ->
+            <- Success
+
+
+B.1.4 Failed hack attack with 3 attempts allowed
+
+            <- Challenge
+        Response ->
+            <- Failure (E=691 R=1), disable short timeout
+        Response (++ID) to first challenge+23 ->
+            <- Failure (E=691 R=1), disable short timeout
+        Response (++ID) to first challenge+23+23 ->
+
+
+
+Zorn & Cobb                  Informational                     [Page 17]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+            <- Failure (E=691 R=0)
+
+
+B.1.5 Successful authentication with password change
+
+            <- Challenge
+        Response ->
+            <- Failure (E=648 R=0 V=2), disable short timeout
+        ChangePassword (++ID) to first challenge ->
+            <- Success
+
+
+B.1.6 Successful authentication with retry and password change
+
+            <- Challenge
+        Response ->
+            <- Failure (E=691 R=1), disable short timeout
+        Response (++ID) to first challenge+23 ->
+            <- Failure (E=648 R=0 V=2), disable short timeout
+        ChangePassword (++ID) to first challenge+23 ->
+            <- Success
+
+B.2 Hash Example
+
+Intermediate values for password "MyPw".
+
+   8-octet Challenge:
+   10 2D B5 DF 08 5D 30 41
+
+   0-to-256-unicode-char NtPassword:
+   4D 00 79 00 50 00 77 00
+
+   16-octet NtPasswordHash:
+   FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
+
+   24-octet NtChallengeResponse:
+   4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C
+   A4 C3 51 AB 40 9A 3D 61
+
+B.3 Example of DES Key Generation
+
+DES uses 56-bit keys, expanded to 64 bits by the insertion of parity
+bits.  After the parity of the key has been fixed, every eighth bit is a
+parity bit and the number of bits that are set (1) in each octet is odd;
+i.e., odd parity.  Note that many DES engines do not check parity,
+however, simply stripping the parity bits.  The following example
+illustrates the values resulting from the use of the 16-octet
+NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys
+
+
+
+Zorn & Cobb                  Informational                     [Page 18]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+(e.g., for use in the NtPasswordHashEncryptedWithBlock() described in
+Appendix A.17).
+
+   16-octet NtPasswordHash:
+   FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
+
+   First "raw" DES key (initial 7 octets of password hash):
+   FC 15 6A F7 ED CD 6C
+
+   First parity-corrected DES key (eight octets):
+   FD 0B 5B 5E 7F 6E 34 D9
+
+   Second "raw" DES key (second 7 octets of password hash)
+   0E DD E3 33 7D 42 7F
+
+   Second parity-corrected DES key (eight octets):
+   0E 6E 79 67 37 EA 08 FE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn & Cobb                  Informational                     [Page 19]
+
+RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn & Cobb                  Informational                     [Page 20]
+