As per Relevance of the word extensions, we have this rfc below:
Network Working Group G.
Request for Comments: 2433 S.
Category: Informational Microsoft
October 1998
Microsoft PPP CHAP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
IESG
The protocol described here has significant vulnerabilities.
planning on implementing or using this protocol should read
12, "Security Considerations".
1.
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links.
defines an extensible Link Control Protocol and a family of
Control Protocols (NCPs) for establishing and configuring
network-layer protocols
This document describes Microsoft's PPP CHAP dialect (MS-CHAP),
extends the user authentication functionality provided on
networks to remote workstations. MS-CHAP is closely derived from
PPP Challenge Handshake Authentication Protocol described in RFC 1994
[2], which the reader should have at hand
The algorithms used in the generation of various MS-CHAP
fields are described in an appendix
2.
Microsoft created MS-CHAP to authenticate remote
workstations, providing the functionality to which LAN-based
are accustomed while integrating the encryption and
algorithms used on Windows networks
Zorn & Cobb Informational [Page 1]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
Where possible, MS-CHAP is consistent with standard CHAP. Briefly
the differences between MS-CHAP and standard CHAP are
* MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in
option 3, Authentication Protocol
* The MS-CHAP Response packet is in a format designed
compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0,
Windows95 networking products. The MS-CHAP format does
require the authenticator to store a clear-text or
encrypted password
* MS-CHAP provides authenticator-controlled authentication
and password changing mechanisms
* MS-CHAP defines a set of reason-for-failure codes returned
the Failure packet Message field
3. Specification of
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT" are to be interpreted
described in [2].
4. LCP
The LCP configuration for MS-CHAP is identical to that for
CHAP, except that the Algorithm field has value 0x80, rather than
MD5 value 0x05. PPP implementations which do not support MS-CHAP
but correctly implement LCP Config-Rej, should have no
dealing with this non-standard option
5. Challenge
The MS-CHAP Challenge packet is identical in format to the
CHAP Challenge packet
MS-CHAP authenticators send an 8-octet challenge Value field.
need not duplicate Microsoft's algorithm for selecting the 8-
value, but the standard guidelines on randomness [1,2,7] SHOULD
observed
Microsoft authenticators do not currently provide information in
Name field. This may change in the future
Zorn & Cobb Informational [Page 2]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
6. Response
The MS-CHAP Response packet is identical in format to the
CHAP Response packet. However, the Value field is sub-
differently as follows
24 octets: LAN Manager compatible challenge
24 octets: Windows NT compatible challenge
1 octet : "Use Windows NT compatible challenge response"
The LAN Manager compatible challenge response is an encoded
of the password and the received challenge as output by the
LmChallengeResponse() (see section A.1, below). LAN
passwords are limited to 14 case-insensitive OEM characters.
that use of the LAN Manager compatible challenge response has
deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD
zero-filled. The algorithm used in the generation of the LAN
compatible challenge response is described here for
purposes only
The Windows NT compatible challenge response is an encoded
of the password and the received challenge as output by the
NTChallengeResponse() (see section A.5, below). The Windows
password is a string of 0 to (theoretically) 256 case-
Unicode [8] characters. Current versions of Windows NT
passwords to 14 characters, mainly for compatibility reasons;
may change in the future
The "use Windows NT compatible challenge response" flag, if 1,
indicates that the Windows NT response is provided and should be
in preference to the LAN Manager response. The LAN Manager
will still be used if the account does not have a Windows NT
hash, e.g. if the password has not been changed since the
was uploaded from a LAN Manager 2.x account database. If the flag
0, the Windows NT response is ignored and the LAN Manager response
used. Since the use of LAN Manager authentication has
deprecated, this flag SHOULD always be set (1) and the LAN
compatible challenge response field SHOULD be zero-filled
The Name field identifies the peer's user account name. The
NT domain name may prefix the user's account name (e.g
"BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing
user account "john-doe"). If a domain is not provided, the
should also be omitted, (e.g. "johndoe").
Zorn & Cobb Informational [Page 3]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
7. Success
The Success packet is identical in format to the standard
Success packet
8. Failure
The Failure packet is identical in format to the standard
Failure packet. There is, however, formatted text stored in
Message field which, contrary to the standard CHAP rules, affects
protocol. The Message field format is
"E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv
The "eeeeeeeeee" is the decimal error code (need not be 10
digits) corresponding to one of those listed below,
implementations should deal with codes not on this
gracefully
646 ERROR_RESTRICTED_LOGON_
647 ERROR_ACCT_
648 ERROR_PASSWD_
649 ERROR_NO_DIALIN_
691 ERROR_AUTHENTICATION_
709 ERROR_CHANGING_
The "r" is a flag set to "1" if a retry is allowed, and "0"
not. When the authenticator sets this flag to "1" it
short timeouts, expecting the peer to prompt the user for
credentials and resubmit the response
The "cccccccccccccccc" is 16 hexadecimal digits representing
ASCII representation of a new challenge value. This field
optional. If it is not sent, the authenticator expects
resubmitted response to be calculated based on the
challenge value plus decimal 23 in the first octet, i.e.
one immediately following the Value Size field. Windows 95
authenticators may send this field. Windows NT
do not, but may in the future. Both systems implement
support of this field
The "vvvvvvvvvv" is the decimal version code (need not be 10
digits) indicating the MS-CHAP protocol version supported
the server. Currently, this is interesting only in selecting
Change Password packet type. If the field is not present
version should be assumed to be 1; since use of the version 1
Zorn & Cobb Informational [Page 4]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
Change Password packet has been deprecated, this field
always contain a value greater than or equal to 2.
Implementations should accept but ignore additional text they do
recognize
9. Change Password Packet (version 1)
The version 1 Change Password packet does not appear in
CHAP. It allows the peer to change the password on the
specified in the previous Response packet. The version 1
Password packet should be sent only if the authenticator
ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to
in the Message field of the Failure packet
The use of the Change Password Packet (version 1) has
deprecated; the format of the packet is described here
informational purposes, but peers SHOULD NOT transmit it
The format of this packet is as follows
1 octet : Code (=5)
1 octet :
2 octets: Length (=72)
16 octets: Encrypted LAN Manager Old password
16 octets: Encrypted LAN Manager New Password
16 octets: Encrypted Windows NT Old Password
16 octets: Encrypted Windows NT New Password
2 octets: Password
2 octets:
5
The Identifier field is one octet and aids in matching
and replies. The value is the Identifier of the
Failure packet to which this packet responds plus 1.
72
Encrypted LAN Manager New Password
Encrypted LAN Manager Old Password
These fields contain the LAN Manager password hash of the
and old passwords encrypted with the last received
value, as output by the routine LmEncryptedPasswordHash() (
section A.8, below).
Zorn & Cobb Informational [Page 5]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
Encrypted Windows NT New Password
Encrypted Windows NT Old Password
These fields contain the Windows NT password hash of the
and old passwords encrypted with the last received
value, as output by the pseudo-code
NtEncryptedPasswordHash() (see section A.10, below).
Password
The length in octets of the LAN Manager compatible form of
new password. If this value is greater than or equal to
and less than or equal to 14 it is assumed that the
LAN Manager password hash fields are valid. Otherwise, it
assumed these fields are not valid, in which case the
NT compatible passwords MUST be provided
This field is two octets in length. It is a bit field
option flags where 0 is the least significant bit of the 16-
quantity
Bit 0
If this bit is set (1), it indicates that the
Windows NT hashed passwords are valid and should be used
If this bit is cleared (0), the Windows NT fields are
used and the LAN Manager fields must be provided
Bits 1-15
Reserved, always clear (0).
10. Change Password Packet (version 2)
The version 2 Change Password packet does not appear in
CHAP. It allows the peer to change the password on the
specified in the preceding Response packet. The version 2
Password packet should be sent only if the authenticator
ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in
Message field of the Failure packet
This packet type is supported by Windows NT 3.51, 4.0 and
versions of Windows 95. It is not supported by Windows NT 3.5
early versions of Windows 95.
The format of this packet is as follows
1 octet :
1 octet :
2 octets :
516 octets : Password Encrypted with Old NT
Zorn & Cobb Informational [Page 6]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
16 octets : Old NT Hash Encrypted with New NT
516 octets : Password Encrypted with Old LM
16 octets : Old LM Hash Encrypted With New NT
24 octets : LAN Manager compatible challenge
24 octets : Windows NT compatible challenge
2-octet :
6
The Identifier field is one octet and aids in matching
and replies. The value is the Identifier of the
Failure packet to which this packet responds plus 1.
1118
Password Encrypted with Old NT
This field contains the PWBLOCK form of the new Windows
password encrypted with the old Windows NT password hash,
output by the NewPasswordEncryptedWithOldNtPasswordHash()
routine (see section A.11, below).
Old NT Hash Encrypted with New NT
This field contains the old Windows NT password hash
with the new Windows NT password hash, as output by
OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (
section A.14, below).
Password Encrypted with Old LM
This field contains the PWBLOCK form of the new Windows
password encrypted with the old LAN Manager password hash,
output by the NewPasswordEncryptedWithOldLmPasswordHash()
routine described in section A.15, below. Note, however,
the use of this field has been deprecated: peers SHOULD
generate it, and this field SHOULD be zero-filled
Old LM Hash Encrypted With New NT
This field contains the old LAN Manager password hash
with the new Windows NT password hash, as output by
OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (
section A.16, below). Note, however, that the use of
field has been deprecated: peers SHOULD NOT generate it,
this field SHOULD be zero-filled
Zorn & Cobb Informational [Page 7]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
LAN Manager compatible challenge
Windows NT compatible challenge
The challenge response field (as described in the
packet description), but calculated on the new password and
same challenge used in the last response. Note that use of
LAN Manager compatible challenge response has been deprecated
peers SHOULD NOT generate it, and the field SHOULD be zero
filled
This field is two octets in length. It is a bit field
option flags where 0 is the least significant bit of the 16-
quantity. The format of this field is illustrated in
following diagram
1
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit 0
The "use Windows NT compatible challenge response"
as described in the Response packet
Bit 1
Set (1) indicates that the "Password Encrypted with
LM Hash" and "Old LM Hash Encrypted With New NT Hash
fields are valid and should be used. Clear (0)
these fields are not valid. This bit SHOULD always
clear (0).
Bits 2-15
Reserved, always clear (0).
11. Security
As an implementation detail, the authenticator SHOULD limit
number of password retries allowed to make brute-force
guessing attacks more difficult
Because the challenge value is encrypted using the password hash
form the response and the challenge is transmitted in clear-
form, both passive known-plaintext and active chosen-
attacks against the password hash are possible. Suitable
(i.e., frequent password changes) SHOULD be taken in
where eavesdropping is likely
Zorn & Cobb Informational [Page 8]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
The Change Password (version 1) packet is vulnerable to a
eavesdropping attack which can easily reveal the new password hash
For this reason, it MUST NOT be sent if eavesdropping is possible
12.
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
1661, July 1994.
[2] Simpson, W., "PPP Challenge Handshake Authentication
(CHAP)", RFC 1994, August 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[4] "Data Encryption Standard (DES)", Federal Information
Standard Publication 46-2, National Institute of Standards
Technology, December 1993.
[5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992.
[6] RC4 is a proprietary encryption algorithm available under
from RSA Data Security Inc. For licensing information, contact
RSA Data Security, Inc
100 Marine
Redwood City, CA 94065-1031
[7] Eastlake, D., Crocker, S., and J. Schiller, "
Recomnendations for Security", RFC 1750, December 1994.
[8] "The Unicode Standard, Version 2.0", The Unicode Consortium
Addison-Wesley, 1996. ISBN 0-201-48345-9.
[9] "DES Modes of Operation", Federal Information
Standards Publication 81, National Institute of Standards
Technology, December 1980
13.
Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com),
Bill Palter (palter@network-alchemy.com), Bruce
(bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com),
Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com
for useful suggestions and feedback
Zorn & Cobb Informational [Page 9]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
14. Chair's
The PPP Extensions Working Group can be contacted via the
chair
Karl
Ascend
3518 Riverside
Suite 101
Columbus, OH 43221
Phone: +1 614 326 6841
EMail: karl@ascend.
15. Authors'
Questions about this memo can also be directed to
Glen
Microsoft
One Microsoft
Redmond, Washington 98052
Phone: +1 425 703 1559
Fax: +1 425 936 7329
EMail: glennz@microsoft.
Steve
Microsoft
One Microsoft
Redmond, Washington 98052
EMail: stevec@microsoft.
Zorn & Cobb Informational [Page 10]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
Appendix A -
The routines mentioned in the text are described in pseudocode below
A.1 LmChallengeResponse()
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 )
}
A.2 LmPasswordHash()
LmPasswordHash
IN 0-to-14-oem-char Password
OUT 16-octet PasswordHash )
{
Set UcasePassword to the uppercased
Zero pad UcasePassword to 14
DesHash( 1st 7-octets of UcasePassword
giving 1st 8-octets of PasswordHash )
DesHash( 2nd 7-octets of UcasePassword
giving 2nd 8-octets of PasswordHash )
}
A.3 DesHash()
DesHash
IN 7-octet Clear
OUT 8-octet Cypher )
{
/*
* Make Cypher an irreversibly encrypted form of Clear
* encrypting known text using Clear as the secret key
* The known text consists of the
*
* KGS!@#$%
*/
Set StdText to "KGS!@#$%"
Zorn & Cobb Informational [Page 11]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
DesEncrypt( StdText, Clear, giving Cypher )
}
A.4 DesEncrypt()
DesEncrypt
IN 8-octet Clear
IN 7-octet Key
OUT 8-octet Cypher )
{
/*
* Use the DES encryption algorithm [4] in ECB mode [9]
* to encrypt Clear into Cypher such that Cypher
* only be decrypted back to Clear by providing Key
* Note that the DES algorithm takes as input a 64-
* stream where the 8th, 16th, 24th, etc. bits
* parity bits ignored by the encrypting algorithm
* Unless you write your own DES to accept 56-bit
* without parity, you will need to insert the parity
* yourself
*/
}
A.5 NtChallengeResponse()
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 )
}
A.6 NtPasswordHash()
NtPasswordHash
IN 0-to-256-unicode-char Password
OUT 16-octet PasswordHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash
* into PasswordHash. Only the password is hashed
* including any terminating 0.
*/
Zorn & Cobb Informational [Page 12]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
}
A.7 ChallengeResponse()
ChallengeResponse
IN 8-octet Challenge
IN 16-octet PasswordHash
OUT 24-octet Response )
{
Set ZPasswordHash to PasswordHash zero-padded to 21
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 )
}
A.8 LmEncryptedPasswordHash()
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 )
}
A.9 PasswordHashEncryptedWithBlock()
PasswordHashEncryptedWithBlock
IN 16-octet PasswordHash
IN 8-octet Block
OUT 16-octet Cypher )
{
Zorn & Cobb Informational [Page 13]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
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 )
}
A.10 NtEncryptedPasswordHash()
NtEncryptedPasswordHash( IN 0-to-14-oem-char Password IN 8-
Challenge OUT 16-octet Cypher ) {
NtPasswordHash( Password, giving PasswordHash )
PasswordHashEncryptedWithBlock( PasswordHash
Challenge
giving Cypher )
}
A.11 NewPasswordEncryptedWithOldNtPasswordHash()
datatype-
{
256-unicode-char
4-octets
}
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 )
}
A.12 EncryptPwBlockWithPasswordHash()
EncryptPwBlockWithPasswordHash
IN 0-to-256-unicode-char Password
IN 16-octet PasswordHash
Zorn & Cobb Informational [Page 14]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
OUT datatype-PWBLOCK PwBlock )
{
Fill ClearPwBlock with random octet
PwSize = lstrlenW( Password ) * sizeof( unicode-char )
PwOffset = sizeof( ClearPwBlock.Password ) -
Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from
ClearPwBlock.PasswordLength =
Rc4Encrypt( ClearPwBlock
sizeof( ClearPwBlock ),
PasswordHash
sizeof( PasswordHash ),
giving PwBlock )
}
A.13 Rc4Encrypt()
Rc4Encrypt
IN x-octet Clear
IN integer ClearLength
IN y-octet Key
IN integer KeyLength
OUT x-octet Cypher )
{
/*
* Use the RC4 encryption algorithm [6] to encrypt Clear
* length ClearLength octets into a Cypher of the same
* such that the Cypher can only be decrypted back to
* by providing a Key of length KeyLength octets
*/
}
A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash()
OldNtPasswordHashEncryptedWithNewNtPasswordHash
IN 0-to-256-unicode-char NewPassword
IN 0-to-256-unicode-char OldPassword
OUT 16-octet EncryptedPasswordHash )
{
NtPasswordHash( OldPassword, giving OldPasswordHash )
NtPasswordHash( NewPassword, giving NewPasswordHash )
NtPasswordHashEncryptedWithBlock( OldPasswordHash
NewPasswordHash
giving EncryptedPasswordHash )
}
Zorn & Cobb Informational [Page 15]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
A.15 NewPasswordEncryptedWithOldLmPasswordHash()
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 )
}
A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash()
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 )
NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash
giving EncrytptedPasswordHash )
}
A.17 NtPasswordHashEncryptedWithBlock()
NtPasswordHashEncryptedWithBlock
IN 16-octet PasswordHash
IN 16-octet Block
OUT 16-octet Cypher )
{
DesEncrypt( 1st 8-octets PasswordHash
1st 7-octets Block
giving 1st 8-octets Cypher )
DesEncrypt( 2nd 8-octets PasswordHash
2nd 7-octets Block
giving 2nd 8-octets Cypher )
}
Zorn & Cobb Informational [Page 16]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
Appendix B -
B.1 Negotiation
Here are some examples of typical negotiations. The peer is on
left and the authenticator is on the right
The packet sequence ID is incremented on each authentication
Response and on the change password response. All cases where
packet sequence ID is updated are noted below
Response retry is never allowed after Change Password.
Password may occur after Response retry. The implied challenge
is shown in the examples, though all cases of "first challenge+23"
should be replaced by the "C=cccccccccccccccc" challenge
authenticator supplies it in the Failure packet
B.1.1 Successful
<-
Response ->
<-
B.1.2 Failed authentication with no retry
<-
Response ->
<- Failure (E=691 R=0)
B.1.3 Successful authentication after
<-
Response ->
<- Failure (E=691 R=1), disable short
Response (++ID) to first challenge+23 ->
<-
B.1.4 Failed hack attack with 3 attempts
<-
Response ->
<- Failure (E=691 R=1), disable short
Response (++ID) to first challenge+23 ->
<- Failure (E=691 R=1), disable short
Response (++ID) to first challenge+23+23 ->
Zorn & Cobb Informational [Page 17]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
<- Failure (E=691 R=0)
B.1.5 Successful authentication with password
<-
Response ->
<- Failure (E=648 R=0 V=2), disable short
ChangePassword (++ID) to first challenge ->
<-
B.1.6 Successful authentication with retry and password
<-
Response ->
<- Failure (E=691 R=1), disable short
Response (++ID) to first challenge+23 ->
<- Failure (E=648 R=0 V=2), disable short
ChangePassword (++ID) to first challenge+23 ->
<-
B.2 Hash
Intermediate values for password "MyPw".
8-octet Challenge
10 2D B5 DF 08 5D 30 41
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
24-octet NtChallengeResponse
4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6
A4 C3 51 AB 40 9A 3D 61
B.3 Example of DES Key
DES uses 56-bit keys, expanded to 64 bits by the insertion of
bits. After the parity of the key has been fixed, every eighth bit is
parity bit and the number of bits that are set (1) in each octet is odd
i.e., odd parity. Note that many DES engines do not check parity
however, simply stripping the parity bits. The following
illustrates the values resulting from the use of the 16-
NTPasswordHash shown in Appendix B.2 to generate a pair of DES
Zorn & Cobb Informational [Page 18]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
(e.g., for use in the NtPasswordHashEncryptedWithBlock() described
Appendix A.17).
16-octet NtPasswordHash
FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E
First "raw" DES key (initial 7 octets of password hash):
FC 15 6A F7 ED CD 6
First parity-corrected DES key (eight octets):
FD 0B 5B 5E 7F 6E 34 D
Second "raw" DES key (second 7 octets of password hash
0E DD E3 33 7D 42 7
Second parity-corrected DES key (eight octets):
0E 6E 79 67 37 EA 08
Zorn & Cobb Informational [Page 19]
RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Zorn & Cobb Informational [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
