You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1139 lines
33 KiB
1139 lines
33 KiB
|
|
|
|
|
|
|
|
|
|
|
|
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 [email protected]) 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: [email protected]
|
|
|
|
|
|
|
|
AUTHOR'S ADDRESS
|
|
|
|
The author is a developer in Microsoft's Windows NT
|
|
Internetworking group, which monitors the [email protected]
|
|
discussions. Questions can also be directed as below, where email
|
|
is preferred.
|
|
|
|
Steve Cobb
|
|
Microsoft Corporation
|
|
One Microsoft Way
|
|
Redmond, WA 98052-6399
|
|
|
|
Email: [email protected]
|
|
|
|
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]
|