summaryrefslogtreecommitdiff
path: root/rfc/rfc2759.txt
diff options
context:
space:
mode:
Diffstat (limited to 'rfc/rfc2759.txt')
-rw-r--r--rfc/rfc2759.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/rfc/rfc2759.txt b/rfc/rfc2759.txt
new file mode 100644
index 0000000..60371c4
--- /dev/null
+++ b/rfc/rfc2759.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group G. Zorn
+Request for Comments: 2759 Microsoft Corporation
+Category: Informational January 2000
+
+
+ Microsoft PPP CHAP Extensions, Version 2
+
+
+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 (2000). All Rights Reserved.
+
+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 version two of Microsoft's PPP CHAP dialect
+ (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-
+ CHAP version one (MS-CHAP-V1, described in [9]). In particular,
+ certain protocol fields have been deleted or reused but with
+ different semantics. In addition, MS-CHAP-V2 features mutual
+ authentication.
+
+ The algorithms used in the generation of various MS-CHAP-V2 protocol
+ fields are described in section 8. Negotiation and hash generation
+ examples are provided in section 9.
+
+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 [3].
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 1]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Challenge Packet . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . 6
+ 8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . 7
+ 8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . 9
+ 8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . 9
+ 8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . 9
+ 8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10
+ 8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . 12
+ 8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12
+ 8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13
+ 8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . 14
+ 8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14
+ 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . 14
+ 9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15
+ 9.1.2. Authenticator authentication failure . . . . . . . . . . . 15
+ 9.1.3. Failed authentication with no retry allowed . . . . . . . . 15
+ 9.1.4. Successful authentication after retry . . . . . . . . . . . 15
+ 9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . 15
+ 9.1.6. Successful authentication with password change . . . . . . 16
+ 9.1.7. Successful authentication with retry and password change. . 16
+ 9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
+ 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
+ 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 2]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+1. Introduction
+
+ Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and
+ standard CHAP. Briefly, the differences between MS-CHAP-V2 and MS-
+ CHAP-V1 are:
+
+ * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP
+ option 3, Authentication Protocol.
+
+ * MS-CHAP-V2 provides mutual authentication between peers by
+ piggybacking a peer challenge on the Response packet and an
+ authenticator response on the Success packet.
+
+ * The calculation of the "Windows NT compatible challenge response"
+ sub-field in the Response packet has been changed to include the
+ peer challenge and the user name.
+
+ * In MS-CHAP-V1, the "LAN Manager compatible challenge response"
+ sub-field was always sent in the Response packet. This field has
+ been replaced in MS-CHAP-V2 by the Peer-Challenge field.
+
+ * The format of the Message field in the Failure packet has been
+ changed.
+
+ * The Change Password (version 1) and Change Password (version 2)
+ packets are no longer supported. They have been replaced with a
+ single Change-Password packet.
+
+2. LCP Configuration
+
+ The LCP configuration for MS-CHAP-V2 is identical to that for
+ standard CHAP, except that the Algorithm field has value 0x81, rather
+ than the MD5 value 0x05. PPP implementations which do not support
+ MS-CHAP-V2, but correctly implement LCP Config-Rej, should have no
+ problem dealing with this non-standard option.
+
+3. Challenge Packet
+
+ The MS-CHAP-V2 Challenge packet is identical in format to the
+ standard CHAP Challenge packet.
+
+ MS-CHAP-V2 authenticators send an 16-octet challenge Value field.
+ Peers need not duplicate Microsoft's algorithm for selecting the 16-
+ 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 Informational [Page 3]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+4. Response Packet
+
+ The MS-CHAP-V2 Response packet is identical in format to the standard
+ CHAP Response packet. However, the Value field is sub-formatted
+ differently as follows:
+
+ 16 octets: Peer-Challenge
+ 8 octets: Reserved, must be zero
+ 24 octets: NT-Response
+ 1 octet : Flags
+
+ The Peer-Challenge field is a 16-octet random number. As the name
+ implies, it is generated by the peer and is used in the calculation
+ of the NT-Response field, below. Peers need not duplicate
+ Microsoft's algorithm for selecting the 16-octet value, but the
+ standard guidelines on randomness [1,2,7] SHOULD be observed.
+
+ The NT-Response field is an encoded function of the password, the
+ user name, the contents of the Peer-Challenge field and the received
+ challenge as output by the routine GenerateNTResponse() (see section
+ 8.1, 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. When computing
+ the NT-Response field contents, only the user name is used, without
+ any associated Windows NT domain name. This is true regardless of
+ whether a Windows NT domain name is present in the Name field (see
+ below).
+
+ The Flag field is reserved for future use and MUST be zero.
+
+ The Name field is a string of 0 to (theoretically) 256 case-sensitive
+ ASCII characters which 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 "johndoe"). If a domain is not provided, the backslash
+ should also be omitted, (e.g. "johndoe").
+
+5. Success Packet
+
+ The Success packet is identical in format to the standard CHAP
+ Success packet. However, the Message field contains a 42-octet
+ authenticator response string and a printable message. The format of
+ the message field is illustrated below.
+
+ "S=<auth_string> M=<message>"
+
+
+
+
+
+Zorn Informational [Page 4]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ The <auth_string> quantity is a 20 octet number encoded in ASCII as
+ 40 hexadecimal digits. The hexadecimal digits A-F (if present) MUST
+ be uppercase. This number is derived from the challenge from the
+ Challenge packet, the Peer-Challenge and NT-Response fields from the
+ Response packet, and the peer password as output by the routine
+ GenerateAuthenticatorResponse() (see section 8.7, below). The
+ authenticating peer MUST verify the authenticator response when a
+ Success packet is received. The method for verifying the
+ authenticator is described in section 8.8, below. If the
+ authenticator response is either missing or incorrect, the peer MUST
+ end the session.
+
+ The <message> quantity is human-readable text in the appropriate
+ charset and language [12].
+
+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 operation of the protocol. The Message field format is:
+
+ "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv
+M=<msg>"
+
+ where
+
+ The "eeeeeeeeee" is the ASCII representation of a 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 an ASCII 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 "cccccccccccccccccccccccccccccccc" is the ASCII representation
+ of a hexadecimal challenge value. This field MUST be exactly 32
+ octets long and MUST be present.
+
+
+
+
+Zorn Informational [Page 5]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ The "vvvvvvvvvv" is the ASCII representation of a decimal version
+ code (need not be 10 digits) indicating the password changing
+ protocol version supported on the server. For MS-CHAP-V2, this
+ value SHOULD always be 3.
+
+ <msg> is human-readable text in the appropriate charset and
+ language [12].
+
+7. Change-Password Packet
+
+ The Change-Password packet does not appear in either standard CHAP or
+ MS-CHAP-V1. It allows the peer to change the password on the account
+ specified in the preceding Response packet. The 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 recent versions of Windows NT 4.0,
+ Windows 95 and Windows 98. It is not supported by Windows NT 3.5,
+ Windows NT 3.51, or early versions of Windows NT 4.0, Windows 95 and
+ Windows 98.
+
+ The format of this packet is as follows:
+
+ 1 octet : Code
+ 1 octet : Identifier
+ 2 octets : Length
+ 516 octets : Encrypted-Password
+ 16 octets : Encrypted-Hash
+ 16 octets : Peer-Challenge
+ 8 octets : Reserved
+ 24 octets : NT-Response
+ 2-octet : Flags
+
+ Code
+ 7
+
+ 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
+ 586
+
+
+
+
+
+
+
+Zorn Informational [Page 6]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ Encrypted-Password
+ 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 8.9, below).
+
+ Encrypted-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 8.12, below).
+
+ Peer-Challenge
+ A 16-octet random quantity, as described in the Response packet
+ description.
+
+ Reserved
+ 8 octets, must be zero.
+
+ NT-Response
+ The NT-Response field (as described in the Response packet
+ description), but calculated on the new password and the challenge
+ received in the Failure packet.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Bits 0-15
+ Reserved, always clear (0).
+
+8. Pseudocode
+
+ The routines mentioned in the text above are described in pseudocode
+ in the following sections.
+
+8.1. GenerateNTResponse()
+
+ GenerateNTResponse(
+ IN 16-octet AuthenticatorChallenge,
+ IN 16-octet PeerChallenge,
+
+
+
+Zorn Informational [Page 7]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ IN 0-to-256-char UserName,
+
+ IN 0-to-256-unicode-char Password,
+ OUT 24-octet Response )
+ {
+ 8-octet Challenge
+ 16-octet PasswordHash
+
+ ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName,
+ giving Challenge)
+
+ NtPasswordHash( Password, giving PasswordHash )
+ ChallengeResponse( Challenge, PasswordHash, giving Response )
+ }
+
+8.2. ChallengeHash()
+
+ ChallengeHash(
+ IN 16-octet PeerChallenge,
+ IN 16-octet AuthenticatorChallenge,
+ IN 0-to-256-char UserName,
+ OUT 8-octet Challenge
+ {
+
+ /*
+ * SHAInit(), SHAUpdate() and SHAFinal() functions are an
+ * implementation of Secure Hash Algorithm (SHA-1) [11]. These are
+ * available in public domain or can be licensed from
+ * RSA Data Security, Inc.
+ */
+
+ SHAInit(Context)
+ SHAUpdate(Context, PeerChallenge, 16)
+ SHAUpdate(Context, AuthenticatorChallenge, 16)
+
+ /*
+ * Only the user name (as presented by the peer and
+ * excluding any prepended domain name)
+ * is used as input to SHAUpdate().
+ */
+
+ SHAUpdate(Context, UserName, strlen(Username))
+ SHAFinal(Context, Digest)
+ memcpy(Challenge, Digest, 8)
+ }
+
+
+
+
+
+
+Zorn Informational [Page 8]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.3. 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.
+ */
+ }
+
+8.4. HashNtPasswordHash()
+
+ HashNtPasswordHash(
+ IN 16-octet PasswordHash,
+ OUT 16-octet PasswordHashHash )
+ {
+ /*
+ * Use the MD4 algorithm [5] to irreversibly hash
+ * PasswordHash into PasswordHashHash.
+ */
+ }
+
+8.5. 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 )
+ }
+
+
+
+
+
+Zorn Informational [Page 9]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.6. DesEncrypt()
+
+ DesEncrypt(
+ IN 8-octet Clear,
+ IN 7-octet Key,
+ OUT 8-octet Cypher )
+ {
+ /*
+ * Use the DES encryption algorithm [4] in ECB mode [10]
+ * 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.
+ */
+ }
+
+8.7. GenerateAuthenticatorResponse()
+
+ GenerateAuthenticatorResponse(
+ IN 0-to-256-unicode-char Password,
+ IN 24-octet NT-Response,
+ IN 16-octet PeerChallenge,
+ IN 16-octet AuthenticatorChallenge,
+ IN 0-to-256-char UserName,
+ OUT 42-octet AuthenticatorResponse )
+ {
+ 16-octet PasswordHash
+ 16-octet PasswordHashHash
+ 8-octet Challenge
+
+ /*
+ * "Magic" constants used in response generation
+ */
+
+ Magic1[39] =
+ {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76,
+ 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65,
+ 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67,
+ 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74};
+
+
+
+
+
+
+
+
+Zorn Informational [Page 10]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ Magic2[41] =
+ {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B,
+ 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F,
+ 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E,
+ 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F,
+ 0x6E};
+
+ /*
+ * Hash the password with MD4
+ */
+
+ NtPasswordHash( Password, giving PasswordHash )
+
+ /*
+ * Now hash the hash
+ */
+
+ HashNtPasswordHash( PasswordHash, giving PasswordHashHash)
+
+ SHAInit(Context)
+ SHAUpdate(Context, PasswordHashHash, 16)
+ SHAUpdate(Context, NTResponse, 24)
+ SHAUpdate(Context, Magic1, 39)
+ SHAFinal(Context, Digest)
+
+ ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName,
+ giving Challenge)
+
+ SHAInit(Context)
+ SHAUpdate(Context, Digest, 20)
+ SHAUpdate(Context, Challenge, 8)
+ SHAUpdate(Context, Magic2, 41)
+ SHAFinal(Context, Digest)
+
+ /*
+ * Encode the value of 'Digest' as "S=" followed by
+ * 40 ASCII hexadecimal digits and return it in
+ * AuthenticatorResponse.
+ * For example,
+ * "S=0123456789ABCDEF0123456789ABCDEF01234567"
+ */
+
+ }
+
+
+
+
+
+
+
+
+Zorn Informational [Page 11]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.8. CheckAuthenticatorResponse()
+
+ CheckAuthenticatorResponse(
+ IN 0-to-256-unicode-char Password,
+ IN 24-octet NtResponse,
+ IN 16-octet PeerChallenge,
+ IN 16-octet AuthenticatorChallenge,
+ IN 0-to-256-char UserName,
+ IN 42-octet ReceivedResponse,
+ OUT Boolean ResponseOK )
+ {
+
+ 20-octet MyResponse
+
+ set ResponseOK = FALSE
+ GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge,
+ AuthenticatorChallenge, UserName,
+ giving MyResponse)
+
+ if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE
+ return ResponseOK
+ }
+
+8.9. 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 )
+ }
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 12]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.10. EncryptPwBlockWithPasswordHash()
+
+ EncryptPwBlockWithPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ IN 16-octet PasswordHash,
+ 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 )
+ }
+
+8.11. 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.
+ */
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 13]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.12. 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 )
+ }
+
+8.13. 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 )
+ }
+
+9. Examples
+
+ The following sections include protocol negotiation and hash
+ generation examples.
+
+9.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.
+
+
+
+
+
+Zorn Informational [Page 14]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+9.1.1. Successful authentication
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification succeeds, call continues)
+
+9.1.2. Authenticator authentication failure
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification fails, peer disconnects)
+
+9.1.3. Failed authentication with no retry allowed
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=691 R=0)
+
+ (Authenticator disconnects)
+
+9.1.4. Successful authentication after retry
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to challenge in failure message ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification succeeds, call continues)
+
+9.1.5. Failed hack attack with 3 attempts allowed
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to challenge in Failure message ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to challenge in Failure message ->
+ <- Failure (E=691 R=0)
+
+
+
+
+
+
+
+
+Zorn Informational [Page 15]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+9.1.6. Successful authentication with password change
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=648 R=0 V=3), disable short
+ timeout
+ ChangePassword (++ID) to challenge in Failure message ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification succeeds, call continues)
+
+9.1.7. Successful authentication with retry and password change
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- 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/Authenticator Response
+
+ (Authenticator Response verification succeeds, call continues)
+
+9.2. Hash Example
+
+ Intermediate values for user name "User" and password "clientPass".
+ All numeric values are hexadecimal.
+
+0-to-256-char UserName:
+55 73 65 72
+
+0-to-256-unicode-char Password:
+63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00
+
+16-octet AuthenticatorChallenge:
+5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28
+
+16-octet PeerChallenge:
+21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
+
+8-octet Challenge:
+D0 2E 43 86 BC E9 12 26
+
+16-octet PasswordHash:
+44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
+
+
+
+
+
+Zorn Informational [Page 16]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+24 octet NT-Response:
+82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF
+
+16-octet PasswordHashHash:
+41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
+
+42-octet AuthenticatorResponse:
+"S=407A5589115FD0D6209F510FE9C04566932CDA56"
+
+9.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 password
+ "MyPw" to generate a pair of DES keys (e.g., for use in the
+ NtPasswordHashEncryptedWithBlock() described in section 8.13).
+
+ 0-to-256-unicode-char Password:
+ 4D 79 50 77
+
+ 16-octet PasswordHash:
+ 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
+
+10. 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.
+
+
+
+
+
+
+
+
+Zorn Informational [Page 17]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+11. 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
+ Recommendations 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] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC
+ 2433, October 1998.
+
+ [10] "DES Modes of Operation", Federal Information Processing
+ Standards Publication 81, National Institute of Standards and
+ Technology, December 1980.
+
+ [11] "Secure Hash Standard", Federal Information Processing Standards
+ Publication 180-1, National Institute of Standards and
+ Technology, April 1995.
+
+ [12] Zorn, G., "PPP LCP Internationalization Configuration Option",
+ RFC 2484, January 1999.
+
+
+
+
+
+
+Zorn Informational [Page 18]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+12. Acknowledgements
+
+ Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul
+ Leach, Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh
+ Pall, Jody Terrill, Brad Robel-Forrest, and Joe Davies for useful
+ suggestions and feedback.
+
+13. Author's Address
+
+ 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: gwz@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 19]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+14. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 20]
+
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-10 11:54:15 +0000