< draft-ietf-pppext-mschap-v2   rfc2759.txt 
G. Zorn
Internet-Draft Microsoft Corporation Network Working Group G. Zorn
Category: Informational April 1999 Request for Comments: 2759 Microsoft Corporation
<draft-ietf-pppext-mschap-v2-03.txt> Category: Informational January 2000
Microsoft PPP CHAP Extensions, Version 2 Microsoft PPP CHAP Extensions, Version 2
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This memo provides information for the Internet community. It does
provisions of Section 10 of RFC2026 except that the right to produce not specify an Internet standard of any kind. Distribution of this
derivative works is not granted. memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
This memo provides information for the Internet community. This memo Copyright (C) The Internet Society (2000). All Rights Reserved.
does not specify an Internet standard of any kind. The distribution of
this memo is unlimited. It is filed as <draft-ietf-pppext-mschap-
v2-03.txt> and expires October 25, 1999. Please send comments to the
PPP Extensions Working Group mailing list (ietf-ppp@merit.edu) or to the
author (gwz@acm.org).
Abstract Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol and a family of Network defines an extensible Link Control Protocol and a family of Network
Control Protocols (NCPs) for establishing and configuring different Control Protocols (NCPs) for establishing and configuring different
network-layer protocols. network-layer protocols.
This document describes version two of Microsoft's PPP CHAP dialect (MS- This document describes version two of Microsoft's PPP CHAP dialect
CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-
version one (MS-CHAP-V1, described in [9]). In particular, certain CHAP version one (MS-CHAP-V1, described in [9]). In particular,
protocol fields have been deleted or reused but with different certain protocol fields have been deleted or reused but with
semantics. In addition, MS-CHAP-V2 features mutual authentication. different semantics. In addition, MS-CHAP-V2 features mutual
authentication.
The algorithms used in the generation of various MS-CHAP-V2 protocol The algorithms used in the generation of various MS-CHAP-V2 protocol
fields are described in section 8. Negotiation and hash generation fields are described in section 8. Negotiation and hash generation
examples are provided in section 9. examples are provided in section 9.
Specification of Requirements Specification of Requirements
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
described in [3]. described in [3].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . 3
2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Challenge Packet . . . . . . . . . . . . . . . . . . . . . . . 3
4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . 6
8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . 7
8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . 8
7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . . 8 8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . 9
8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . 9
8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . 9
8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . . 9 8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10
8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . 12
8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . . 10 8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12
8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13
8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . . 11 8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13
8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . 14
8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . . 11 8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15
8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1.2. Authenticator authentication failure . . . . . . . . . . . 15
9.1.3. Failed authentication with no retry allowed . . . . . . . . 15
8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . . 12 9.1.4. Successful authentication after retry . . . . . . . . . . . 15
9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . 15
8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . . 13 9.1.6. Successful authentication with password change . . . . . . 16
9.1.7. Successful authentication with retry and password change. . 16
8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . . 14 9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . 16
9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17
8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . . 15 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . . 16
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . . 16
9.1.1. Successful authentication . . . . . . . . . . . . . . . . . . 16
9.1.2. Authenticator authentication failure . . . . . . . . . . . . 16
9.1.3. Failed authentication with no retry allowed . . . . . . . . . 17
9.1.4. Successful authentication after retry . . . . . . . . . . . . 17
9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . . 17
9.1.6. Successful authentication with password change . . . . . . . 17
9.1.7. Successful authentication with retry and password change
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Chair's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
15. Expiration Date . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and 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- standard CHAP. Briefly, the differences between MS-CHAP-V2 and MS-
V1 are: CHAP-V1 are:
* MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP
option 3, Authentication Protocol. option 3, Authentication Protocol.
* MS-CHAP-V2 provides mutual authentication between peers by * MS-CHAP-V2 provides mutual authentication between peers by
piggybacking a peer challenge on the Response packet and an piggybacking a peer challenge on the Response packet and an
authenticator reponse on the Success packet. authenticator response on the Success packet.
* The calculation of the "Windows NT compatible challenge * The calculation of the "Windows NT compatible challenge response"
response" sub-field in the Response packet has been changed sub-field in the Response packet has been changed to include the
to include the peer challenge and the user name. peer challenge and the user name.
* In MS-CHAP-V1, the "LAN Manager compatible challenge response" * In MS-CHAP-V1, the "LAN Manager compatible challenge response"
sub-field was always sent in the Response packet. This field sub-field was always sent in the Response packet. This field has
has been replaced in MS-CHAP-V2 by the Peer-Challenge field. been replaced in MS-CHAP-V2 by the Peer-Challenge field.
* The format of the Message field in the Failure packet has * The format of the Message field in the Failure packet has been
been changed. changed.
* The Change Password (version 1) and Change Password (version 2) * The Change Password (version 1) and Change Password (version 2)
packets are no longer supported. They have been replaced with a packets are no longer supported. They have been replaced with a
single Change-Password packet. single Change-Password packet.
2. LCP Configuration 2. LCP Configuration
The LCP configuration for MS-CHAP-V2 is identical to that for standard The LCP configuration for MS-CHAP-V2 is identical to that for
CHAP, except that the Algorithm field has value 0x81, rather than the standard CHAP, except that the Algorithm field has value 0x81, rather
MD5 value 0x05. PPP implementations which do not support MS-CHAP-V2, than the MD5 value 0x05. PPP implementations which do not support
but correctly implement LCP Config-Rej, should have no problem dealing MS-CHAP-V2, but correctly implement LCP Config-Rej, should have no
with this non-standard option. problem dealing with this non-standard option.
3. Challenge Packet 3. Challenge Packet
The MS-CHAP-V2 Challenge packet is identical in format to the standard The MS-CHAP-V2 Challenge packet is identical in format to the
CHAP Challenge packet. standard CHAP Challenge packet.
MS-CHAP-V2 authenticators send an 16-octet challenge Value field. Peers MS-CHAP-V2 authenticators send an 16-octet challenge Value field.
need not duplicate Microsoft's algorithm for selecting the 16-octet Peers need not duplicate Microsoft's algorithm for selecting the 16-
value, but the standard guidelines on randomness [1,2,7] SHOULD be octet value, but the standard guidelines on randomness [1,2,7] SHOULD
observed. be observed.
Microsoft authenticators do not currently provide information in the Microsoft authenticators do not currently provide information in the
Name field. This may change in the future. Name field. This may change in the future.
4. Response Packet 4. Response Packet
The MS-CHAP-V2 Response packet is identical in format to the standard The MS-CHAP-V2 Response packet is identical in format to the standard
CHAP Response packet. However, the Value field is sub-formatted CHAP Response packet. However, the Value field is sub-formatted
differently as follows: differently as follows:
16 octets: Peer-Challenge 16 octets: Peer-Challenge
8 octets: Reserved, must be zero 8 octets: Reserved, must be zero
24 octets: NT-Response 24 octets: NT-Response
1 octet : Flags 1 octet : Flags
The Peer-Challenge field is a 16-octet random number. As the name 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 implies, it is generated by the peer and is used in the calculation
the NT-Response field, below. Peers need not duplicate Microsoft's of the NT-Response field, below. Peers need not duplicate
algorithm for selecting the 16-octet value, but the standard guidelines Microsoft's algorithm for selecting the 16-octet value, but the
on randomness [1,2,7] SHOULD be observed. standard guidelines on randomness [1,2,7] SHOULD be observed.
The NT-Response field is an encoded function of the password, the user The NT-Response field is an encoded function of the password, the
name, the contents of the Peer-Challenge field and the received user name, the contents of the Peer-Challenge field and the received
challenge as output by the routine GenerateNTResponse() (see section challenge as output by the routine GenerateNTResponse() (see section
11.1, below). The Windows NT password is a string of 0 to 8.1, below). The Windows NT password is a string of 0 to
(theoretically) 256 case-sensitive Unicode [8] characters. Current (theoretically) 256 case-sensitive Unicode [8] characters. Current
versions of Windows NT limit passwords to 14 characters, mainly for versions of Windows NT limit passwords to 14 characters, mainly for
compatibility reasons; this may change in the future. When computing compatibility reasons; this may change in the future. When computing
the NT-Response field contents, only the user name is used, without any the NT-Response field contents, only the user name is used, without
associated Windows NT domain name. This is true regardless of whether a any associated Windows NT domain name. This is true regardless of
Windows NT domain name is present in the Name field (see below). 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 Flag field is reserved for future use and MUST be zero.
The Name field is a string of 0 to (theoretically) 256 case-sensitive The Name field is a string of 0 to (theoretically) 256 case-sensitive
ASCII characters which identifies the peer's user account name. The ASCII characters which identifies the peer's user account name. The
Windows NT domain name may prefix the user's account name (e.g. 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 "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the
account "johndoe"). If a domain is not provided, the backslash should user account "johndoe"). If a domain is not provided, the backslash
also be omitted, (e.g. "johndoe"). should also be omitted, (e.g. "johndoe").
5. Success Packet 5. Success Packet
The Success packet is identical in format to the standard CHAP Success The Success packet is identical in format to the standard CHAP
packet. However, the Message field contains a 42-octet authenticator Success packet. However, the Message field contains a 42-octet
response string and a printable message. The format of the message authenticator response string and a printable message. The format of
field is illustrated below. the message field is illustrated below.
"S=<auth_string> M=<message>" "S=<auth_string> M=<message>"
The <auth_string> quantity is a 20 octet number encoded in ASCII as
The <auth_string> quantity is a 20 octet number encoded in ASCII as 40 40 hexadecimal digits. The hexadecimal digits A-F (if present) MUST
hexadecimal digits. The hexadecimal digits A-F (if present) MUST be be uppercase. This number is derived from the challenge from the
uppercase. This number is derived from the challenge from the Challenge Challenge packet, the Peer-Challenge and NT-Response fields from the
packet, the Peer-Challenge and NT-Response fields from the Response Response packet, and the peer password as output by the routine
packet, and the peer password as output by the routine GenerateAuthenticatorResponse() (see section 8.7, below). The
GenerateAuthenticatorResponse() (see section 11.7, below). The
authenticating peer MUST verify the authenticator response when a authenticating peer MUST verify the authenticator response when a
Success packet is received. The method for verifying the authenticator Success packet is received. The method for verifying the
is described in section 11.8, below. If the authenticator response is authenticator is described in section 8.8, below. If the
either missing or incorrect, the peer MUST end the session. authenticator response is either missing or incorrect, the peer MUST
end the session.
The <message> quantity is human-readable text in the appropriate charset The <message> quantity is human-readable text in the appropriate
and language [12]. charset and language [12].
6. Failure Packet 6. Failure Packet
The Failure packet is identical in format to the standard CHAP Failure The Failure packet is identical in format to the standard CHAP
packet. There is, however, formatted text stored in the Message field Failure packet. There is, however, formatted text stored in the
which, contrary to the standard CHAP rules, does affect the operation of Message field which, contrary to the standard CHAP rules, does affect
the protocol. The Message field format is: the operation of the protocol. The Message field format is:
"E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv M=<Message>" "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv
M=<msg>"
where where
The "eeeeeeeeee" is the ASCII representation of a decimal error The "eeeeeeeeee" is the ASCII representation of a decimal error
code (need not be 10 digits) corresponding to one of those listed code (need not be 10 digits) corresponding to one of those listed
below, though implementations should deal with codes not on this below, though implementations should deal with codes not on this
list gracefully. list gracefully.
646 ERROR_RESTRICTED_LOGON_HOURS 646 ERROR_RESTRICTED_LOGON_HOURS
647 ERROR_ACCT_DISABLED 647 ERROR_ACCT_DISABLED
skipping to change at page 8, line 10 skipping to change at page 6, line 10
The "cccccccccccccccccccccccccccccccc" is the ASCII representation The "cccccccccccccccccccccccccccccccc" is the ASCII representation
of a hexadecimal challenge value. This field MUST be exactly 32 of a hexadecimal challenge value. This field MUST be exactly 32
octets long and MUST be present. octets long and MUST be present.
The "vvvvvvvvvv" is the ASCII representation of a decimal version The "vvvvvvvvvv" is the ASCII representation of a decimal version
code (need not be 10 digits) indicating the password changing code (need not be 10 digits) indicating the password changing
protocol version supported on the server. For MS-CHAP-V2, this protocol version supported on the server. For MS-CHAP-V2, this
value SHOULD always be 3. value SHOULD always be 3.
<message> is human-readable text in the appropriate charset and <msg> is human-readable text in the appropriate charset and
language [12]. language [12].
7. Change-Password Packet 7. Change-Password Packet
The Change-Password packet does not appear in either standard CHAP or 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 MS-CHAP-V1. It allows the peer to change the password on the account
specified in the preceding Response packet. The Change-Password packet specified in the preceding Response packet. The Change-Password
should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED packet should be sent only if the authenticator reports
(E=648) in the Message field of the Failure packet. 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, 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 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 NT 3.51, or early versions of Windows NT 4.0, Windows 95 and
Windows 98. Windows 98.
The format of this packet is as follows: The format of this packet is as follows:
1 octet : Code 1 octet : Code
1 octet : Identifier 1 octet : Identifier
skipping to change at page 9, line 5 skipping to change at page 7, line 9
and replies. The value is the Identifier of the received Failure and replies. The value is the Identifier of the received Failure
packet to which this packet responds plus 1. packet to which this packet responds plus 1.
Length Length
586 586
Encrypted-Password Encrypted-Password
This field contains the PWBLOCK form of the new Windows NT This field contains the PWBLOCK form of the new Windows NT
password encrypted with the old Windows NT password hash, as password encrypted with the old Windows NT password hash, as
output by the NewPasswordEncryptedWithOldNtPasswordHash() routine output by the NewPasswordEncryptedWithOldNtPasswordHash() routine
(see section 11.9, below). (see section 8.9, below).
Encrypted-Hash Encrypted-Hash
This field contains the old Windows NT password hash encrypted This field contains the old Windows NT password hash encrypted
with the new Windows NT password hash, as output by the with the new Windows NT password hash, as output by the
OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see
section 11.12, below). section 8.12, below).
Peer-Challenge Peer-Challenge
A 16-octet random quantity, as described in the Response packet A 16-octet random quantity, as described in the Response packet
description. description.
Reserved Reserved
8 octets, must be zero. 8 octets, must be zero.
NT-Response NT-Response
The NT-Response field (as described in the Response packet The NT-Response field (as described in the Response packet
skipping to change at page 9, line 41 skipping to change at page 7, line 45
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bits 0-15 Bits 0-15
Reserved, always clear (0). Reserved, always clear (0).
8. Pseudocode 8. Pseudocode
The routines mentioned in the text above are described in pseudocode in The routines mentioned in the text above are described in pseudocode
the following sections. in the following sections.
8.1. GenerateNTResponse() 8.1. GenerateNTResponse()
GenerateNTResponse( GenerateNTResponse(
IN 16-octet AuthenticatorChallenge, IN 16-octet AuthenticatorChallenge,
IN 16-octet PeerChallenge, IN 16-octet PeerChallenge,
IN 0-to-256-char UserName, IN 0-to-256-char UserName,
IN 0-to-256-unicode-char Password, IN 0-to-256-unicode-char Password,
OUT 24-octet Response ) OUT 24-octet Response )
{ {
8-octet Challenge 8-octet Challenge
16-octet PasswordHash 16-octet PasswordHash
ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName,
giving Challenge) giving Challenge)
NtPasswordHash( Password, giving PasswordHash ) NtPasswordHash( Password, giving PasswordHash )
skipping to change at page 15, line 4 skipping to change at page 13, line 14
8.10. EncryptPwBlockWithPasswordHash() 8.10. EncryptPwBlockWithPasswordHash()
EncryptPwBlockWithPasswordHash( EncryptPwBlockWithPasswordHash(
IN 0-to-256-unicode-char Password, IN 0-to-256-unicode-char Password,
IN 16-octet PasswordHash, IN 16-octet PasswordHash,
OUT datatype-PWBLOCK PwBlock ) OUT datatype-PWBLOCK PwBlock )
{ {
Fill ClearPwBlock with random octet values Fill ClearPwBlock with random octet values
PwSize = lstrlenW( Password ) * sizeof( unicode-char ) PwSize = lstrlenW( Password ) * sizeof( unicode-char )
PwOffset = sizeof( ClearPwBlock.Password ) - PwSize PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from
Password
ClearPwBlock.PasswordLength = PwSize ClearPwBlock.PasswordLength = PwSize
Rc4Encrypt( ClearPwBlock, Rc4Encrypt( ClearPwBlock,
sizeof( ClearPwBlock ), sizeof( ClearPwBlock ),
PasswordHash, PasswordHash,
sizeof( PasswordHash ), sizeof( PasswordHash ),
giving PwBlock ) giving PwBlock )
} }
8.11. Rc4Encrypt() 8.11. Rc4Encrypt()
skipping to change at page 16, line 23 skipping to change at page 14, line 37
1st 7-octets Block, 1st 7-octets Block,
giving 1st 8-octets Cypher ) giving 1st 8-octets Cypher )
DesEncrypt( 2nd 8-octets PasswordHash, DesEncrypt( 2nd 8-octets PasswordHash,
2nd 7-octets Block, 2nd 7-octets Block,
giving 2nd 8-octets Cypher ) giving 2nd 8-octets Cypher )
} }
9. Examples 9. Examples
The following sections include protocol negotiation and hash generation The following sections include protocol negotiation and hash
examples. generation examples.
9.1. Negotiation Examples 9.1. Negotiation Examples
Here are some examples of typical negotiations. The peer is on the left Here are some examples of typical negotiations. The peer is on the
and the authenticator is on the right. left and the authenticator is on the right.
The packet sequence ID is incremented on each authentication retry The packet sequence ID is incremented on each authentication retry
response and on the change password response. All cases where the response and on the change password response. All cases where the
packet sequence ID is updated are noted below. packet sequence ID is updated are noted below.
Response retry is never allowed after Change Password. Change Password Response retry is never allowed after Change Password. Change
may occur after response retry. Password may occur after response retry.
9.1.1. Successful authentication 9.1.1. Successful authentication
<- Authenticator Challenge <- Authenticator Challenge
Peer Response/Challenge -> Peer Response/Challenge ->
<- Success/Authenticator Response <- Success/Authenticator Response
(Authenticator Response verification succeeds, call continues) (Authenticator Response verification succeeds, call continues)
9.1.2. Authenticator authentication failure 9.1.2. Authenticator authentication failure
skipping to change at page 17, line 40 skipping to change at page 16, line 9
<- Failure (E=691 R=1), disable short timeout <- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in Failure message -> Response (++ID) to challenge in Failure message ->
<- Failure (E=691 R=1), disable short timeout <- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in Failure message -> Response (++ID) to challenge in Failure message ->
<- Failure (E=691 R=0) <- Failure (E=691 R=0)
9.1.6. Successful authentication with password change 9.1.6. Successful authentication with password change
<- Authenticator Challenge <- Authenticator Challenge
Peer Response/Challenge -> Peer Response/Challenge ->
<- Failure (E=648 R=0 V=3), disable short timeout <- Failure (E=648 R=0 V=3), disable short
timeout
ChangePassword (++ID) to challenge in Failure message -> ChangePassword (++ID) to challenge in Failure message ->
<- Success/Authenticator Response <- Success/Authenticator Response
(Authenticator Response verification succeeds, call continues) (Authenticator Response verification succeeds, call continues)
9.1.7. Successful authentication with retry and password change 9.1.7. Successful authentication with retry and password change
<- Authenticator Challenge <- Authenticator Challenge
Peer Response/Challenge -> Peer Response/Challenge ->
<- Failure (E=691 R=1), disable short timeout <- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 -> Response (++ID) to first challenge+23 ->
<- Failure (E=648 R=0 V=2), disable short timeout <- Failure (E=648 R=0 V=2), disable short
timeout
ChangePassword (++ID) to first challenge+23 -> ChangePassword (++ID) to first challenge+23 ->
<- Success/Authenticator Response <- Success/Authenticator Response
(Authenticator Response verification succeeds, call continues) (Authenticator Response verification succeeds, call continues)
9.2. Hash Example 9.2. Hash Example
Intermediate values for user name "User" and password "clientPass". All Intermediate values for user name "User" and password "clientPass".
numeric values are hexadecimal. All numeric values are hexadecimal.
0-to-256-char UserName: 0-to-256-char UserName:
55 73 65 72 55 73 65 72
0-to-256-unicode-char Password: 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 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00
16-octet AuthenticatorChallenge: 16-octet AuthenticatorChallenge:
5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28
skipping to change at page 19, line 8 skipping to change at page 17, line 16
16-octet PasswordHashHash: 16-octet PasswordHashHash:
41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
42-octet AuthenticatorResponse: 42-octet AuthenticatorResponse:
"S=407A5589115FD0D6209F510FE9C04566932CDA56" "S=407A5589115FD0D6209F510FE9C04566932CDA56"
9.3. Example of DES Key Generation 9.3. Example of DES Key Generation
DES uses 56-bit keys, expanded to 64 bits by the insertion of parity 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 bits. After the parity of the key has been fixed, every eighth bit
parity bit and the number of bits that are set (1) in each octet is odd; is a parity bit and the number of bits that are set (1) in each octet
i.e., odd parity. Note that many DES engines do not check parity, is odd; i.e., odd parity. Note that many DES engines do not check
however, simply stripping the parity bits. The following example parity, however, simply stripping the parity bits. The following
illustrates the values resulting from the use of the password "MyPw" to example illustrates the values resulting from the use of the password
generate a pair of DES keys (e.g., for use in the "MyPw" to generate a pair of DES keys (e.g., for use in the
NtPasswordHashEncryptedWithBlock() described in section 11.13). NtPasswordHashEncryptedWithBlock() described in section 8.13).
0-to-256-unicode-char Password: 0-to-256-unicode-char Password:
4D 79 50 77 4D 79 50 77
16-octet PasswordHash: 16-octet PasswordHash:
FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC 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): First "raw" DES key (initial 7 octets of password hash):
FC 15 6A F7 ED CD 6C FC 15 6A F7 ED CD 6C
skipping to change at page 19, line 36 skipping to change at page 17, line 44
FD 0B 5B 5E 7F 6E 34 D9 FD 0B 5B 5E 7F 6E 34 D9
Second "raw" DES key (second 7 octets of password hash) Second "raw" DES key (second 7 octets of password hash)
0E DD E3 33 7D 42 7F 0E DD E3 33 7D 42 7F
Second parity-corrected DES key (eight octets): Second parity-corrected DES key (eight octets):
0E 6E 79 67 37 EA 08 FE 0E 6E 79 67 37 EA 08 FE
10. Security Considerations 10. Security Considerations
As an implementation detail, the authenticator SHOULD limit the number As an implementation detail, the authenticator SHOULD limit the
of password retries allowed to make brute-force password guessing number of password retries allowed to make brute-force password
attacks more difficult. guessing attacks more difficult.
11. References 11. References
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
July 1994 1661, July 1994.
[2] Simpson, W., "PPP Challenge Handshake Authentication Protocol [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996 (CHAP)", RFC 1994, August 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997.
[4] "Data Encryption Standard (DES)", Federal Information Processing [4] "Data Encryption Standard (DES)", Federal Information Processing
Standard Publication 46-2, National Institute of Standards and Standard Publication 46-2, National Institute of Standards and
Technology, December 1993 Technology, December 1993.
[5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992. [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:
[6] RC4 is a proprietary encryption algorithm available under license
from RSA Data Security Inc. For licensing information, contact:
RSA Data Security, Inc. RSA Data Security, Inc.
100 Marine Parkway 100 Marine Parkway
Redwood City, CA 94065-1031 Redwood City, CA 94065-1031
[7] Eastlake, D., et. al., "Randomness Recomnendations for Security", [7] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
RFC 1750, December 1994 Recommendations for Security", RFC 1750, December 1994.
[8] "The Unicode Standard, Version 2.0", The Unicode Consortium, [8] "The Unicode Standard, Version 2.0", The Unicode Consortium,
Addison-Wesley, 1996. ISBN 0-201-48345-9. Addison-Wesley, 1996. ISBN 0-201-48345-9.
[9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, [9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC
October 1998 2433, October 1998.
[10] "DES Modes of Operation", Federal Information Processing Standards [10] "DES Modes of Operation", Federal Information Processing
Publication 81, National Institute of Standards and Technology, Standards Publication 81, National Institute of Standards and
December 1980 Technology, December 1980.
[11] "Secure Hash Standard", Federal Information Processing Standards [11] "Secure Hash Standard", Federal Information Processing Standards
Publication 180-1, National Institute of Standards and Technology, Publication 180-1, National Institute of Standards and
April 1995 Technology, April 1995.
[12] Zorn, G., "PPP LCP Internationalization Configuration Option", RFC [12] Zorn, G., "PPP LCP Internationalization Configuration Option",
2484, January 1999 RFC 2484, January 1999.
12. Acknowledgements 12. Acknowledgements
Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul Leach, Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul
Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh Pall, Jody Leach, Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh
Terrill, Brad Robel-Forrest, and Joe Davies for useful suggestions and Pall, Jody Terrill, Brad Robel-Forrest, and Joe Davies for useful
feedback. suggestions and feedback.
13. 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
14. Author's Address 13. Author's Address
Questions about this memo can also be directed to: Questions about this memo can also be directed to:
Glen Zorn Glen Zorn
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, Washington 98052 Redmond, Washington 98052
Phone: +1 425 703 1559 Phone: +1 425 703 1559
FAX: +1 425 936 7329 Fax: +1 425 936 7329
EMail: gwz@acm.org EMail: gwz@acm.org
15. Expiration Date 14. Full Copyright Statement
This memo is filed as <draft-ietf-pppext-mschap-v2-03.txt> and expires Copyright (C) The Internet Society (2000). All Rights Reserved.
on October 25, 1999.
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.
 End of changes. 59 change blocks. 
227 lines changed or deleted 174 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35