1140 lines
32 KiB
Plaintext
1140 lines
32 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|