diff options
| author | Kozlov Dmitry <dima@server> | 2010-10-06 16:43:14 +0400 |
|---|---|---|
| committer | Kozlov Dmitry <dima@server> | 2010-10-06 16:43:14 +0400 |
| commit | b6a1268714671904e96a49b88680dc3ff07aaa1c (patch) | |
| tree | 60424372b94312710b9f583b1bcc641de4020316 /rfc/ms-chap.txt | |
| parent | 5cf93f33f2350ed3b92f73ead1d2829a6883810a (diff) | |
| download | accel-ppp-xebd-b6a1268714671904e96a49b88680dc3ff07aaa1c.tar.gz accel-ppp-xebd-b6a1268714671904e96a49b88680dc3ff07aaa1c.zip | |
project cleanup and prepare to release
Diffstat (limited to 'rfc/ms-chap.txt')
| -rw-r--r-- | rfc/ms-chap.txt | 1139 |
1 files changed, 1139 insertions, 0 deletions
diff --git a/rfc/ms-chap.txt b/rfc/ms-chap.txt new file mode 100644 index 0000000..f009400 --- /dev/null +++ b/rfc/ms-chap.txt @@ -0,0 +1,1139 @@ +
+
+
+
+
+
+Network Working Group S. Cobb
+Informational Memo Microsoft
+Revision 1.3 March 1997
+
+
+ Microsoft PPP CHAP Extensions
+
+
+Status of this Memo
+
+ This document has no official Internet Engineering Task Force
+ status. It is submitted as an example of one vendor's working
+ solution to several authentication issues not yet standardized by
+ the Point-to-Point Working Group.
+
+ The protocol described is implemented in Microsoft Windows NT 3.5
+ and 3.51 and in Microsoft Windows95. Differences between the
+ platforms are noted in the text. This information, plus that in
+ the references, is believed sufficient to implement an
+ interoperating peer.
+
+ Distribution of this memo is unlimited.
+
+
+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 1334 [2], which the reader should have at hand.
+
+
+History
+
+ Rev 1.21: (Sect 6) Fix error in implicit challenge description
+ Rev 1.22: (Sect 7) Fix error in sub-field table ordering
+ Rev 1.3: (Sect 10) Added hash example section
+
+
+
+
+
+
+
+
+Cobb [Page 1]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+Table Of Contents
+
+ 1. Introduction................................................3
+ 2. LCP Configuration...........................................4
+ 3. Challenge Packet............................................4
+ 4. Response Packet.............................................4
+ 5. Success Packet..............................................8
+ 6. Failure Packet..............................................8
+ 7. Change Password Packet (version 1)..........................9
+ 8. Change Password Packet (version 2).........................12
+ 9. Negotiation Examples.......................................16
+ 10. Hash Example...............................................16
+
+ REFERENCES.....................................................18
+ CHAIR'S ADDRESS................................................19
+ AUTHOR'S ADDRESS...............................................19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 2]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+1. Introduction
+
+ Microsoft created MS-CHAP to authenticate remote Windows
+ workstations, providing the functionality to which LAN-based users
+ are accustomed.
+
+ The closest fit available in standard PPP is CHAP which is
+ primarily used for mutual secure authentication between WAN-aware
+ routers. Unfortunately, CHAP is not widely used in support of
+ remote workstations where providers commonly require an insecure
+ text login session in place of PPP authentication protocols. To
+ date, several remote workstation issues have not been adequately
+ addressed in CHAP. MS-CHAP addresses these issues and also
+ integrates the encryption and hashing algorithms used on Windows
+ networks.
+
+ Where possible, MS-CHAP is consistent with standard CHAP, and the
+ differences are easily modularized. Microsoft implements MS-CHAP
+ as extensions to it's standard CHAP code base. Briefly,
+ 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 Windows NT 3.5 and 3.51,
+ Microsoft Windows95, and Microsoft LAN Manager 2.x networking
+ products. The MS-CHAP format does not require the
+ authenticator to store a clear or reversibly encrypted
+ password.
+
+ * MS-CHAP provides an authenticator controlled authentication
+ retry mechanism.
+
+ * MS-CHAP provides an authenticator controlled change password
+ mechanism.
+
+ * MS-CHAP defines a set of reason-for-failure codes returned in
+ the Failure packet Message field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 3]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+2. 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. Non-MS-CHAP-aware implementations
+ that correctly implement LCP Config-Rej have no problem dealing
+ with this non-standard option.
+
+ Microsoft currently negotiates authentication only on the
+ server->workstation configuration. Mutual authentication may be
+ supported in the future.
+
+
+3. 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. It
+ is not necessary for peers to duplicate Microsoft's algorithm for
+ selecting the 8-octet value, but the CHAP guidelines on randomness
+ should be observed.
+
+ Microsoft authenticators do not currently provide information in
+ the Name field. This may change in the future.
+
+
+4. 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 pseudo-code routine LmChallengeResponse below. LAN Manager
+ passwords are limited to 14 case-insensitive OEM characters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 4]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 )
+ }
+
+ 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 )
+ }
+
+ DesHash(
+ IN 7-octet Clear,
+ OUT 8-octet Cypher )
+ {
+ Make Cypher an irreversibly encrypted form of Clear by
+ encrypting known text [6] using Clear as the secret key,
+ that is...
+
+ DesEncrypt(
+ StdText,
+ Clear,
+ giving Cypher )
+ }
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 5]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ DesEncrypt(
+ IN 8-octet Clear,
+ IN 7-octet Key,
+ OUT 8-octet Cypher )
+ {
+ Use the DES encryption algorithm [3] 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.
+ }
+
+ 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 )
+ }
+
+
+ The Windows NT compatible challenge response is an encoded
+ function of the password and the received challenge as output by
+ the NtChallengeResponse routine below. The Windows NT password is
+ a string of 0 to (theoretically) 256 case-sensitive Unicode
+ characters. Current versions of Windows NT limit passwords to 14
+ characters, mainly for compatibility reasons, though this may
+ change in the future.
+
+
+
+
+
+
+
+
+
+Cobb [Page 6]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 )
+ }
+
+ NtPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ OUT 16-octet PasswordHash )
+ {
+ Use the MD4 algorithm [4] to irreversibly hash Password
+ into PasswordHash. Only the password is hashed without
+ including any terminating 0.
+ }
+
+ 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.
+ The LAN Manager response need not be provided (set to 0's) if the
+ implementation expects all user accounts to be stored only in
+ fresh Windows NT account databases or ones where all uploaded
+ passwords have been changed. However, doing so may sacrifice
+ downward compatibility with non-Windows-NT servers.
+
+ If the flag is 0, the Windows NT response is ignored and the LAN
+ Manager response is used. If the password is LAN Manager
+ compatible, interoperability may be achieved without providing the
+ Windows NT challenge response (set to 0's), and providing only the
+ LAN Manager response. This is what Microsoft Windows95 does,
+ though this may change in the future. Doing so may sacrifice
+ interoperability with OEM-specific versions of Windows NT designed
+ for maximum security in Windows-NT-only networks.
+
+ Implementors seeking the broadest possible interoperability are
+ advised to supply both responses when the password is LAN Manager
+ compatible. This is what Microsoft Windows NT does.
+
+
+
+
+
+
+
+Cobb [Page 7]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ The Name field identifies the authenticatee's user account name.
+ The Windows NT domain name may prefix the user's account name in
+ the typical Windows NT format, e.g. "redmond\stevec" where
+ "redmond" is a Windows NT domain containing the user account
+ "stevec". If a domain is not provided, the backslash should also
+ be omitted, e.g. "stevec".
+
+
+5. Success Packet
+
+ The Success packet is identical in format to the standard CHAP
+ Success packet.
+
+
+6. 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, does
+ affect 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 authenticator sets this flag to "1" it disables
+ short timeouts, expecting the authenticatee to prompt the user
+ for new credentials and resubmit the response.
+
+ The "cccccccccccccccc" is 16 hex digits representing an ASCII
+ representation of a new challenge value. This field is
+ optional. If it is not sent, 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. Windows95
+ authenticators may send this field. Windows NT authenticators
+ do not, but may in the future. Both systems implement
+ authenticatee support of this field.
+
+
+
+
+Cobb [Page 8]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 1.
+
+ Implementations should accept but ignore additional text they do
+ not recognize.
+
+
+7. Change Password Packet (version 1)
+
+ The version 1 Change Password packet does not appear in standard
+ CHAP. It allows the authenticatee 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) in the Message field of the
+ Failure packet.
+
+ This packet type is supported by Windows NT 3.5 and 3.51. It is
+ not supported by Windows95, though this may change in the future.
+ See also Change Password Packet (version 2).
+
+ 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
+
+
+
+
+Cobb [Page 9]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 an 8-octet key value [6], as
+ output by the pseudo-code routine LmEncryptedPasswordHash
+ below.
+
+ 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 )
+ }
+
+ PasswordHashEncryptedWithBlock(
+ IN 16-octet PasswordHash,
+ IN 7-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,
+ 1st 7-octets Block,
+ giving 2nd 8-octets Cypher )
+ }
+
+
+ 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 an 8-octet key value [6], as
+ output by the pseudo-code routine NtEncryptedPasswordHash
+ below.
+
+
+
+
+
+
+
+
+Cobb [Page 10]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 )
+ }
+
+
+ Password Length
+
+ The length in octets of the LAN Manager compatible form of the
+ new password. If this value is 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
+
+ Bit field of option flags where 0 is the least significant bit
+ of the 16-bit quantity:
+
+ 0 : Set 1 indicates that the encrypted Windows NT
+ hashed passwords are valid and should be used. If
+ 0, the Windows NT fields are not used and the LAN
+ Manager fields must be provided.
+
+ For the broadest possible interoperability,
+ implementations are encouraged to provide both the
+ Windows NT and LAN Manager fields when the password
+ is LAN Manager compatible. This is what Windows NT
+ does.
+
+ 1-15 : Reserved, always set 0.
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 11]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+8. Change Password Packet (version 2)
+
+ The version 2 Change Password packet does not appear in standard
+ CHAP. It allows the authenticatee to change the password on the
+ account specified in the previous 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 more in
+ the Message field of the Failure packet.
+
+ This packet type is supported by Windows NT 3.51. It is not
+ supported by Windows NT 3.5 or Windows95, though the latter may
+ change in the future. The version 2 change password packet type
+ is preferable to the version 1 type and should be offered and
+ accepted where possible.
+
+ The format of this packet is as follows:
+
+ 1 octet : Code (=6)
+ 1 octet : Identifier
+ 2 octet : Length (=1070)
+ 516 octets : Password Encrypted with Old NT Hash
+ 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 below:
+
+
+
+Cobb [Page 12]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 )
+ }
+
+ EncryptPwBlockWithPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ IN 16-octet PasswordHash,
+ OUT datatype-PWBLOCK PwBlock )
+ {
+ Fill ClearPwBlock with random octet values
+ lstrcpyW( to ClearPwBlock.Password, from Password )
+ ClearPwBlock.PasswordLength = lstrlenW( Password )
+
+ Rc4Encrypt(
+ ClearPwBlock,
+ sizeof( ClearPwBlock ),
+ PasswordHash,
+ sizeof( PasswordHash ),
+ giving PwBlock )
+ }
+
+ Rc4Encrypt(
+ IN x-octet Clear,
+ IN integer ClearLength,
+ IN y-octet Key,
+ IN integer KeyLength,
+ OUT x-octet Cypher )
+ {
+ Use the RC4 encryption algorithm [5] 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.
+ }
+
+
+
+
+
+Cobb [Page 13]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 below:
+
+ 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 )
+
+ PasswordHashEncryptedWithBlock(
+ OldPasswordHash,
+ NewPasswordHash,
+ giving EncrytptedPasswordHash )
+ }
+
+
+ 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 below:
+
+ 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 )
+ }
+
+
+
+
+
+
+
+
+Cobb [Page 14]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 below:
+
+ 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 )
+
+ PasswordHashEncryptedWithBlock(
+ OldPasswordHash,
+ NewPasswordHash,
+ giving EncrytptedPasswordHash )
+ }
+
+
+ LAN Manager compatible challenge response
+ Windows NT compatible challenge response
+
+ The challenge response fields as described in the Response
+ packet description, but calculated on the new password and the
+ same challenge used in the last response.
+
+
+ Flags
+
+ Bit field of option flags:
+
+ 0 : The "use Windows NT compatible challenge response"
+ flag as described in the Response packet.
+
+ 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. Set 0
+ indicates these fields are not valid.
+
+ For the broadest possible interoperability,
+ implementations are encouraged to provide both the
+ Windows NT and LAN Manager fields when the password
+ is LAN Manager compatible. This is what Windows NT
+ does.
+
+ 2-15 : Reserved, always set 0.
+
+
+Cobb [Page 15]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+9. Negotiation Examples
+
+ Here are some examples of typical negotiations. The authenticatee
+ 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 either 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.
+
+
+ Successful authentication
+
+ <- Challenge
+ Response ->
+ <- Success
+
+
+ Failed authentication with no retry allowed
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=0)
+
+
+ Successful authentication after retry
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Success
+
+
+ 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 ->
+ <- Failure (E=691 R=0)
+
+
+
+
+
+
+Cobb [Page 16]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ Successful authentication with password change
+
+ <- Challenge
+ Response ->
+ <- Failure (E=648 R=0), disable short timeout
+ ChangePassword (++ID) to first challenge ->
+ <- Success
+
+ 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), disable short timeout
+ ChangePassword (++ID) to first challenge+23 ->
+ <- Success
+
+
+10. Hash Example
+
+ Intermediate values for password "MyPw".
+
+ 8-octet Challenge:
+ 10 2D B5 DF 08 5D 30 41
+
+ 0-to-14-oem-char LmPassword:
+ 4D 59 50 57
+
+ 16-octet LmPasswordHash:
+ 75 BA 30 19 8E 6D 19 75 AA D3 B4 35 B5 14 04 EE
+
+ 24-octet LmChallengeResponse:
+ 91 88 1D 01 52 AB 0C 33 C5 24 13 5E C2 4A 95 EE
+ 64 E2 3C DC 2D 33 34 7D
+
+ 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
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 17]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+REFERENCES
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
+ Daydreamer, May 1992
+
+ [2] LLoyd, B and Simpson, W., "PPP Authentication Protocols",
+ RFC 1334, L&A and Daydreamer respectively, Octobet 1992
+
+ [3] "Data Encryption Standard (DES)" is Federal Information
+ Processing Standard publication 46, National Institute of
+ Standard and Techology.
+
+ [4] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, MIT
+ Laboratory for Computer Science and RSA Data Security, Inc.,
+ April 1992.
+
+ [5] RC4 is an encryption standard available from RSA Data Security
+ Inc.
+
+ [6] The 8-octet StdText string used in the LAN Manager compatible
+ password hashing and the 8-octet KeyValue used in the Change
+ Password (version 1) packet are not available for public
+ distribution at this time. Contact the Microsoft Developer
+ Relations group (at time of writing dbeaver@microsoft.com) for
+ details on obtaining these values. On this particular point
+ the author can't help you.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 18]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+CHAIR'S ADDRESS
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Email: fred@cisco.com
+
+
+
+AUTHOR'S ADDRESS
+
+ The author is a developer in Microsoft's Windows NT
+ Internetworking group, which monitors the ietf-ppp@merit.edu
+ discussions. Questions can also be directed as below, where email
+ is preferred.
+
+ Steve Cobb
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+
+ Email: stevec@microsoft.com
+
+ The author maintains an informal mailing list of persons
+ interested in MS-CHAP and other news regarding Windows NT support
+ for PPP authentication protocols. Send email if interested.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 19]
|