Network Working Group G. Zorn
Request for Comments: 2433 S. Cobb
Category: Informational Microsoft Corporation
October 1998
Network Working Group G. Zorn
Request for Comments: 2433 S. Cobb
Category: Informational Microsoft Corporation
October 1998
Microsoft PPP CHAP Extensions
Microsoft PPP CHAP扩展
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
IESG Note
IESG注释
The protocol described here has significant vulnerabilities. People planning on implementing or using this protocol should read section 12, "Security Considerations".
此处描述的协议存在严重漏洞。计划实施或使用本协议的人员应阅读第12节“安全注意事项”。
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.
点到点协议（PPP）[1]提供了通过点到点链路传输多协议数据报的标准方法。PPP定义了一个可扩展链路控制协议和一系列网络控制协议（NCP），用于建立和配置不同的网络层协议。
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 1994 [2], which the reader should have at hand.
本文档介绍了Microsoft的PPP CHAP方言（MS-CHAP），它将Windows网络上提供的用户身份验证功能扩展到远程工作站。MS-CHAP与RFC 1994[2]中描述的PPP质询握手认证协议密切相关，读者应该手头有该协议。
The algorithms used in the generation of various MS-CHAP protocol fields are described in an appendix.
附录中描述了用于生成各种MS-CHAP协议字段的算法。
Microsoft created MS-CHAP to authenticate remote Windows workstations, providing the functionality to which LAN-based users are accustomed while integrating the encryption and hashing algorithms used on Windows networks.
Microsoft创建了MS-CHAP来验证远程Windows工作站，提供了基于LAN的用户所习惯的功能，同时集成了Windows网络上使用的加密和哈希算法。
Where possible, MS-CHAP is consistent with standard CHAP. Briefly, the differences between MS-CHAP and standard CHAP are:
在可能的情况下，MS-CHAP与标准CHAP保持一致。简而言之，MS-CHAP与标准CHAP之间的区别是：
* MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP option 3, Authentication Protocol.
* MS-CHAP通过协商LCP选项3“身份验证协议”中的CHAP算法0x80启用。
* The MS-CHAP Response packet is in a format designed for compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and Windows95 networking products. The MS-CHAP format does not require the authenticator to store a clear-text or reversibly encrypted password.
* MS-CHAP响应数据包的格式旨在与Microsoft的Windows NT 3.5、3.51和4.0以及Windows 95网络产品兼容。MS-CHAP格式不要求验证器存储明文或可逆加密密码。
* MS-CHAP provides authenticator-controlled authentication retry and password changing mechanisms.
* MS-CHAP提供了验证器控制的身份验证重试和密码更改机制。
* MS-CHAP defines a set of reason-for-failure codes returned in the Failure packet Message field.
* MS-CHAP定义了故障包消息字段中返回的故障代码的一组原因。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[2]所述。
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. PPP implementations which do not support MS-CHAP, but correctly implement LCP Config-Rej, should have no problem dealing with this non-standard option.
MS-CHAP的LCP配置与标准CHAP相同，只是算法字段的值为0x80，而不是MD5值0x05。不支持MS-CHAP但正确实现LCP Config Rej的PPP实现在处理此非标准选项时应该没有问题。
The MS-CHAP Challenge packet is identical in format to the standard CHAP Challenge packet.
MS-CHAP质询数据包的格式与标准CHAP质询数据包的格式相同。
MS-CHAP authenticators send an 8-octet challenge Value field. Peers need not duplicate Microsoft's algorithm for selecting the 8-octet value, but the standard guidelines on randomness [1,2,7] SHOULD be observed.
MS-CHAP身份验证程序发送一个8位字节的质询值字段。同行无需重复微软选择8位八位组值的算法，但应遵守随机性标准指南[1,2,7]。
Microsoft authenticators do not currently provide information in the Name field. This may change in the future.
Microsoft验证器当前不在名称字段中提供信息。这在将来可能会改变。
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:
MS-CHAP响应数据包的格式与标准CHAP响应数据包的格式相同。但是，值字段的子格式不同，如下所示：
24 octets: LAN Manager compatible challenge response 24 octets: Windows NT compatible challenge response 1 octet : "Use Windows NT compatible challenge response" flag
24个八位字节：LAN Manager兼容的质询响应24个八位字节：Windows NT兼容的质询响应1个八位字节：“使用Windows NT兼容的质询响应”标志
The LAN Manager compatible challenge response is an encoded function of the password and the received challenge as output by the routine LmChallengeResponse() (see section A.1, below). LAN Manager passwords are limited to 14 case-insensitive OEM characters. Note that use of the LAN Manager compatible challenge response has been deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be zero-filled. The algorithm used in the generation of the LAN Manager compatible challenge response is described here for informational purposes only.
与LAN Manager兼容的质询响应是密码和接收到的质询的编码函数，作为例程LmChallengeResponse（）的输出（参见下面的A.1节）。LAN Manager密码限制为14个不区分大小写的OEM字符。请注意，已不推荐使用LAN Manager兼容的质询响应；对等方不应生成它，子字段应为零填充。在生成与LAN Manager兼容的质询响应时所使用的算法在此处描述仅供参考。
The Windows NT compatible challenge response is an encoded function of the password and the received challenge as output by the routine NTChallengeResponse() (see section A.5, below). The Windows NT password is a string of 0 to (theoretically) 256 case-sensitive Unicode [8] characters. Current versions of Windows NT limit passwords to 14 characters, mainly for compatibility reasons; this may change in the future.
与Windows NT兼容的质询响应是密码和接收到的质询的编码函数，作为例程NTChallengeResponse（）的输出（请参阅下面的A.5节）。Windows NT密码是由0到（理论上）256个区分大小写的Unicode[8]字符组成的字符串。当前版本的Windows NT将密码限制为14个字符，主要是出于兼容性原因；这在将来可能会改变。
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. If the flag is 0, the Windows NT response is ignored and the LAN Manager response is used. Since the use of LAN Manager authentication has been deprecated, this flag SHOULD always be set (1) and the LAN Manager compatible challenge response field SHOULD be zero-filled.
“使用Windows NT兼容质询响应”标志（如果为1）表示提供了Windows NT响应，并且应优先使用LAN Manager响应。如果帐户没有Windows NT密码哈希，例如，自从LAN Manager 2.x帐户数据库上载帐户后，密码未更改，则仍将使用LAN Manager响应。如果标志为0，则忽略Windows NT响应并使用LAN Manager响应。由于不推荐使用LAN Manager身份验证，因此应始终设置此标志（1），并且LAN Manager兼容的质询响应字段应为零。
The Name field identifies the peer's user account name. The Windows NT domain name may prefix the user's account name (e.g. "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the user account "john-doe"). If a domain is not provided, the backslash should also be omitted, (e.g. "johndoe").
Name字段标识对等方的用户帐户名。Windows NT域名可以作为用户帐户名的前缀（例如，“BIGCO\johndoe”，其中“BIGCO”是包含用户帐户“john doe”的Windows NT域）。如果未提供域，还应省略反斜杠（例如“johndoe”）。
The Success packet is identical in format to the standard CHAP Success packet.
成功数据包的格式与标准CHAP成功数据包的格式相同。
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, affects the protocol. The Message field format is:
故障数据包的格式与标准CHAP故障数据包的格式相同。但是，与标准CHAP规则相反，消息字段中存储的格式化文本会影响协议。消息字段格式为：
"E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"
"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.
“EEEE”是与下面列出的代码之一对应的十进制错误代码（不需要是10位数字），尽管实现应该优雅地处理不在此列表中的代码。
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
646错误\u限制\u登录\u时间647错误\u帐户\u禁用648错误\u密码\u过期649错误\u否\u拨号\u权限691错误\u身份验证\u失败709错误\u更改密码
The "r" is a flag set to "1" if a retry is allowed, and "0" if not. When the authenticator sets this flag to "1" it disables short timeouts, expecting the peer to prompt the user for new credentials and resubmit the response.
“r”是一个标志，如果允许重试，则设置为“1”；如果不允许重试，则设置为“0”。当验证器将此标志设置为“1”时，它将禁用短超时，期望对等方提示用户输入新凭据并重新提交响应。
The "cccccccccccccccc" is 16 hexadecimal digits representing an ASCII representation of a new challenge value. This field is optional. If it is not sent, the 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. Windows 95 authenticators may send this field. Windows NT authenticators do not, but may in the future. Both systems implement peer support of this field.
“CCCC”是16位十六进制数字，表示新质询值的ASCII表示。此字段是可选的。如果未发送，则验证器期望根据前一个质询值加上第一个八位字节中的十进制23（即紧跟在值大小字段后面的一个）计算重新提交的响应。Windows 95身份验证程序可以发送此字段。Windows NT身份验证程序不会，但将来可能会。这两个系统都实现了该领域的对等支持。
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 to be 1; since use of the version 1
“VV”是十进制版本代码（不需要是10位数字），表示服务器上支持的MS-CHAP协议版本。目前，这仅在选择更改密码数据包类型时才有意义。如果该字段不存在，则应假定版本为1；自版本1使用以来
Change Password packet has been deprecated, this field SHOULD always contain a value greater than or equal to 2.
更改密码数据包已被弃用，此字段应始终包含大于或等于2的值。
Implementations should accept but ignore additional text they do not recognize.
实现应该接受但忽略它们不识别的其他文本。
The version 1 Change Password packet does not appear in standard CHAP. It allows the peer 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) and V is either missing or equal to one in the Message field of the Failure packet.
版本1更改密码数据包未出现在标准CHAP中。它允许对等方更改上一个响应数据包中指定的帐户上的密码。仅当验证器报告错误_PASSWD_EXPIRED（E=648）且V在失败数据包的消息字段中缺失或等于1时，才应发送版本1更改密码数据包。
The use of the Change Password Packet (version 1) has been deprecated; the format of the packet is described here for informational purposes, but peers SHOULD NOT transmit it.
不推荐使用更改密码包（版本1）；此处描述的数据包格式仅供参考，但对等方不应传输数据包。
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
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
代码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.
标识符标识符字段是一个八位字节，有助于匹配请求和答复。该值是该数据包响应的已接收故障数据包的标识符加1。
Length 72
长度72
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 the last received challenge value, as output by the routine LmEncryptedPasswordHash() (see section A.8, below).
加密的LAN Manager新密码哈希加密的LAN Manager旧密码哈希这些字段包含由例程LmEncryptedPasswordHash（）输出的使用上次接收的质询值加密的新密码和旧密码的LAN Manager密码哈希（见下文第A.8节）。
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 the last received challenge value, as output by the pseudo-code routine NtEncryptedPasswordHash() (see section A.10, below).
加密的Windows NT新密码哈希加密的Windows NT旧密码哈希这些字段包含使用上次接收的质询值加密的新密码和旧密码的Windows NT密码哈希，由伪代码例程NTERCRyptedPasswordHash（）输出（请参阅下面的A.10节）。
Password Length The length in octets of the LAN Manager compatible form of the new password. If this value is greater than or equal to zero and 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.
密码长度新密码的LAN Manager兼容形式的长度（以八位字节为单位）。如果该值大于或等于零且小于或等于14，则假定加密的LAN Manager密码散列字段有效。否则，假定这些字段无效，在这种情况下，必须提供与Windows NT兼容的密码。
Flags This field is two octets in length. It is a bit field of option flags where 0 is the least significant bit of the 16-bit quantity:
标志此字段的长度为两个八位字节。它是选项标志的位字段，其中0是16位数量的最低有效位：
Bit 0 If this bit is set (1), it indicates that the encrypted Windows NT hashed passwords are valid and should be used. If this bit is cleared (0), the Windows NT fields are not used and the LAN Manager fields must be provided.
位0如果此位设置为（1），则表示加密的Windows NT哈希密码有效，应使用。如果清除该位（0），则不使用Windows NT字段，并且必须提供LAN Manager字段。
Bits 1-15 Reserved, always clear (0).
保留位1-15，始终清除（0）。
The version 2 Change Password packet does not appear in standard CHAP. It allows the peer to change the password on the account specified in the preceding 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 greater in the Message field of the Failure packet.
版本2更改密码数据包未出现在标准CHAP中。它允许对等方更改前面响应数据包中指定的帐户上的密码。仅当验证器报告错误_PASSWD_EXPIRED（E=648）且故障数据包的消息字段中的版本为2或更高时，才应发送版本2更改密码数据包。
This packet type is supported by Windows NT 3.51, 4.0 and recent versions of Windows 95. It is not supported by Windows NT 3.5 or early versions of Windows 95.
Windows NT 3.51、4.0和最新版本的Windows 95支持此数据包类型。Windows NT 3.5或早期版本的Windows 95不支持此功能。
The format of this packet is as follows:
此数据包的格式如下：
1 octet : Code 1 octet : Identifier 2 octets : Length 516 octets : Password Encrypted with Old NT Hash
1个八位组：代码1个八位组：标识符2个八位组：长度516个八位组：使用旧NT哈希加密的密码
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
16个八位组：使用新NT哈希加密的旧NT哈希516个八位组：使用旧LM哈希加密的密码16个八位组：使用新NT哈希加密的旧LM哈希24个八位组：LAN Manager兼容的质询响应24个八位组：Windows NT兼容的质询响应2个八位组：标志
Code 6
代码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.
标识符标识符字段是一个八位字节，有助于匹配请求和答复。该值是该数据包响应的已接收故障数据包的标识符加1。
Length 1118
长度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 (see section A.11, below).
使用旧NT哈希加密的密码此字段包含使用旧Windows NT密码哈希加密的新Windows NT密码的PWBLOCK格式，由NewPasswordEncryptedWithOldNtPasswordHash（）例程输出（请参阅下面的A.11节）。
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 (see section A.14, below).
使用新NT哈希加密的旧NT哈希此字段包含使用新Windows NT密码哈希加密的旧Windows NT密码哈希，由OldNtPasswordHashEncryptedWithNewNtPasswordHash（）例程输出（请参阅下面的A.14节）。
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 described in section A.15, below. Note, however, that the use of this field has been deprecated: peers SHOULD NOT generate it, and this field SHOULD be zero-filled.
使用旧LM哈希加密的密码此字段包含使用旧LAN Manager密码哈希加密的新Windows NT密码的PWBLOCK格式，由下面A.15节中描述的NewPasswordEncryptedWithOldLmPasswordHash（）例程输出。但是，请注意，此字段的使用已被弃用：对等方不应生成它，并且此字段应为零填充。
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 (see section A.16, below). Note, however, that the use of this field has been deprecated: peers SHOULD NOT generate it, and this field SHOULD be zero-filled.
Old LM Hash Encrypted With New NT Hash此字段包含由OldLmPasswordHashEncryptedWithNewNtPasswordHash（）例程输出的使用新Windows NT密码哈希加密的旧LAN Manager密码哈希（请参阅下面的A.16节）。但是，请注意，此字段的使用已被弃用：对等方不应生成它，并且此字段应为零填充。
LAN Manager compatible challenge response Windows NT compatible challenge response The challenge response field (as described in the Response packet description), but calculated on the new password and the same challenge used in the last response. Note that use of the LAN Manager compatible challenge response has been deprecated; peers SHOULD NOT generate it, and the field SHOULD be zero-filled.
LAN Manager兼容质询响应Windows NT兼容质询响应质询响应字段（如响应数据包描述中所述），但根据新密码和上次响应中使用的相同质询进行计算。请注意，已不推荐使用LAN Manager兼容的质询响应；对等方不应生成该字段，该字段应为零填充。
Flags This field is two octets in length. It is a bit field of option flags where 0 is the least significant bit of the 16-bit quantity. The format of this field is illustrated in the following diagram:
标志此字段的长度为两个八位字节。它是选项标志的位字段，其中0是16位量的最低有效位。该字段的格式如下图所示：
1
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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" flag as described in the Response packet.
位0“使用Windows NT兼容质询响应”标志，如响应数据包中所述。
Bit 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. Clear (0) indicates these fields are not valid. This bit SHOULD always be clear (0).
位1集合（1）表示“使用旧LM哈希加密的密码”和“使用新NT哈希加密的旧LM哈希”字段有效，应使用。清除（0）表示这些字段无效。该位应始终为清除（0）。
Bits 2-15 Reserved, always clear (0).
保留位2-15，始终清除（0）。
As an implementation detail, the authenticator SHOULD limit the number of password retries allowed to make brute-force password guessing attacks more difficult.
作为一个实现细节，身份验证器应该限制允许的密码重试次数，以使暴力密码猜测攻击更加困难。
Because the challenge value is encrypted using the password hash to form the response and the challenge is transmitted in clear-text form, both passive known-plaintext and active chosen-plaintext attacks against the password hash are possible. Suitable precautions (i.e., frequent password changes) SHOULD be taken in environments where eavesdropping is likely.
由于质询值使用密码散列加密以形成响应，并且质询以明文形式传输，因此针对密码散列的被动已知明文和主动选择明文攻击都是可能的。在可能发生窃听的环境中，应采取适当的预防措施（即频繁更改密码）。
The Change Password (version 1) packet is vulnerable to a passive eavesdropping attack which can easily reveal the new password hash. For this reason, it MUST NOT be sent if eavesdropping is possible.
更改密码（版本1）数据包容易受到被动窃听攻击，这很容易泄露新密码散列。因此，如果可能被窃听，则不得发送。
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[2] 辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] "Data Encryption Standard (DES)", Federal Information Processing Standard Publication 46-2, National Institute of Standards and Technology, December 1993.
[4] “数据加密标准（DES）”，联邦信息处理标准出版物46-2，国家标准与技术研究所，1993年12月。
[5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992.
[5] Rivest，R.，“MD4消息摘要算法”，RFC1320，1992年4月。
[6] RC4 is a proprietary encryption algorithm available under license from RSA Data Security Inc. For licensing information, contact: RSA Data Security, Inc. 100 Marine Parkway Redwood City, CA 94065-1031
[6] RC4是一种专有加密算法，在RSA Data Security Inc.的许可下可获得许可信息，联系方式：RSA Data Security，Inc.100 Marine Parkway Redwood City，CA 94065-1031
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recomnendations for Security", RFC 1750, December 1994.
[7] Eastlake，D.，Crocker，S.，和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[8] "The Unicode Standard, Version 2.0", The Unicode Consortium, Addison-Wesley, 1996. ISBN 0-201-48345-9.
[8] “Unicode标准，2.0版”，Unicode联盟，Addison-Wesley，1996年。ISBN 0-201-48345-9。
[9] "DES Modes of Operation", Federal Information Processing Standards Publication 81, National Institute of Standards and Technology, December 1980
[9] “DES操作模式”，联邦信息处理标准出版物81，国家标准与技术研究所，1980年12月
Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com), Bill Palter (palter@network-alchemy.com), Bruce Johnson (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com) for useful suggestions and feedback.
谢谢（没有特别的顺序）杰夫·哈格（杰夫·哈格）_Haag@3com.com)，比尔·帕特尔(palter@network-炼金术网），布鲁斯·约翰逊(bjohnson@microsoft.com)，托尼·贝尔(tonybe@microsoft.com)，Benoit Martin(ehlija@vircom.com)，还有乔·戴维斯(josephd@microsoft.com)获取有用的建议和反馈。
The PPP Extensions Working Group can be contacted via the current chair:
PPP扩展工作组可通过现任主席联系：
Karl Fox Ascend Communications 3518 Riverside Drive Suite 101 Columbus, OH 43221
卡尔·福克斯艾森德通讯公司3518河畔大道101号套房，俄亥俄州哥伦布市，邮编43221
Phone: +1 614 326 6841
EMail: karl@ascend.com
Phone: +1 614 326 6841
EMail: karl@ascend.com
Questions about this memo can also be directed to:
有关本备忘录的问题，请联系：
Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052
格伦·佐恩微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 1559
Fax: +1 425 936 7329
EMail: glennz@microsoft.com
Phone: +1 425 703 1559
Fax: +1 425 936 7329
EMail: glennz@microsoft.com
Steve Cobb Microsoft Corporation One Microsoft Way Redmond, Washington 98052
史蒂夫·科布（Steve Cobb）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: stevec@microsoft.com
EMail: stevec@microsoft.com
Appendix A - Pseudocode
附录A-伪代码
The routines mentioned in the text are described in pseudocode below.
本文中提到的例程在下面的伪代码中描述。
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 )
}
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
LmPasswordHash（在0-to-14-oem-char密码中，输出16个八位密码hash）{将UCASSEPASSWORD设置为大写密码零，将UCASSEPASSWORD设置为14个字符
DesHash( 1st 7-octets of UcasePassword, giving 1st 8-octets of PasswordHash )
DesHash（UcasePassword的前7个八位字节，给出密码hash的前8个八位字节）
DesHash( 2nd 7-octets of UcasePassword, giving 2nd 8-octets of PasswordHash ) }
DesHash（UcasePassword的第二个7个八位字节，给出密码hash的第二个8个八位字节）}
DesHash(
IN 7-octet Clear,
OUT 8-octet Cypher )
{
/*
* Make Cypher an irreversibly encrypted form of Clear by
* encrypting known text using Clear as the secret key.
* The known text consists of the string
*
* KGS!@#$%
*/
DesHash(
IN 7-octet Clear,
OUT 8-octet Cypher )
{
/*
* Make Cypher an irreversibly encrypted form of Clear by
* encrypting known text using Clear as the secret key.
* The known text consists of the string
*
* KGS!@#$%
*/
Set StdText to "KGS!@#$%"
Set StdText to "KGS!@#$%"
DesEncrypt( StdText, Clear, giving Cypher ) }
DesEncrypt（StdText、Clear、giving Cypher）}
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 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.
*/
}
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 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.
*/
}
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 )
}
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 [5] to irreversibly hash Password
* into PasswordHash. Only the password is hashed without
* including any terminating 0.
*/
NtPasswordHash(
IN 0-to-256-unicode-char Password,
OUT 16-octet PasswordHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash Password
* into PasswordHash. Only the password is hashed without
* including any terminating 0.
*/
}
}
ChallengeResponse( IN 8-octet Challenge, IN 16-octet PasswordHash, OUT 24-octet Response ) { Set ZPasswordHash to PasswordHash zero-padded to 21 octets
ChallengeResponse（在8个八位字节的质询中，在16个八位字节的密码哈希中，在24个八位字节的响应中）{将ZPasswordHash设置为密码哈希零，填充为21个八位字节
DesEncrypt( Challenge, 1st 7-octets of ZPasswordHash, giving 1st 8-octets of Response )
去加密（质询，ZPasswordHash的前7个八位字节，给出前8个八位字节的响应）
DesEncrypt( Challenge, 2nd 7-octets of ZPasswordHash, giving 2nd 8-octets of Response )
去加密（质询，ZPasswordHash的第二个7字节，给出第二个8字节的响应）
DesEncrypt( Challenge, 3rd 7-octets of ZPasswordHash, giving 3rd 8-octets of Response ) }
去加密（挑战，ZPasswordHash的第三个7位字节，给出第三个8位字节的响应）}
LmEncryptedPasswordHash( IN 0-to-14-oem-char Password, IN 8-octet KeyValue, OUT 16-octet Cypher ) { LmPasswordHash( Password, giving PasswordHash )
LmEncryptedPasswordHash（0-to-14-oem-char密码，8-octet键值，16-octet密码）{LmPasswordHash（密码，给出PasswordHash）
PasswordHashEncryptedWithBlock( PasswordHash, KeyValue, giving Cypher ) }
PasswordHashEncryptedWithBlock（PasswordHash，KeyValue，给定密码）}
PasswordHashEncryptedWithBlock( IN 16-octet PasswordHash, IN 8-octet Block, OUT 16-octet Cypher ) {
PasswordHashEncryptedWithBlock（在16个八位字节的PasswordHash中，在8个八位字节的块中，在16个八位字节的密码中）{
DesEncrypt( 1st 8-octets PasswordHash, 1st 7-octets Block, giving 1st 8-octets Cypher )
去加密（前8个八位字节的密码哈希，前7个八位字节的块，给出前8个八位字节的密码）
DesEncrypt( 2nd 8-octets PasswordHash, 1st 7-octets Block, giving 2nd 8-octets Cypher ) }
去加密（第二个8-octets密码哈希，第一个7-octets块，给出第二个8-octets密码）}
NtEncryptedPasswordHash( IN 0-to-14-oem-char Password IN 8-octet Challenge OUT 16-octet Cypher ) { NtPasswordHash( Password, giving PasswordHash )
NtEncryptedPasswordHash（在0-to-14-oem-char密码中，在8-octet中挑战16-octet密码）{NtPasswordHash（密码，给出PasswordHash）
PasswordHashEncryptedWithBlock( PasswordHash, Challenge, giving Cypher ) }
PasswordHashEncryptedWithBlock（密码哈希、质询、赋予密码）}
datatype-PWBLOCK
{
256-unicode-char Password
4-octets PasswordLength
}
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 )
NewPasswordEncryptedWithOldNtPasswordHash（在0-to-256-unicode-char NewPassword中，在0-to-256-unicode-char OldPassword中，输出数据类型pBlock EncryptedPwBlock）{NtPasswordHash（OldPassword，给出PasswordHash）
EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash, giving EncryptedPwBlock ) }
EncryptPwBlockWithPasswordHash（NewPassword、PasswordHash、giving EncryptedPwBlock）}
EncryptPwBlockWithPasswordHash( IN 0-to-256-unicode-char Password, IN 16-octet PasswordHash,
EncryptPwBlockWithPasswordHash（在0-to-256-unicode-char密码中，在16个八位密码哈希中，
OUT datatype-PWBLOCK PwBlock ) {
输出数据类型PWBLOCK PWBLOCK）{
Fill ClearPwBlock with random octet values
PwSize = lstrlenW( Password ) * sizeof( unicode-char )
PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password
ClearPwBlock.PasswordLength = PwSize
Rc4Encrypt( ClearPwBlock,
sizeof( ClearPwBlock ),
PasswordHash,
sizeof( PasswordHash ),
giving PwBlock )
}
Fill ClearPwBlock with random octet values
PwSize = lstrlenW( Password ) * sizeof( unicode-char )
PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password
ClearPwBlock.PasswordLength = PwSize
Rc4Encrypt( ClearPwBlock,
sizeof( ClearPwBlock ),
PasswordHash,
sizeof( PasswordHash ),
giving PwBlock )
}
Rc4Encrypt(
IN x-octet Clear,
IN integer ClearLength,
IN y-octet Key,
IN integer KeyLength,
OUT x-octet Cypher )
{
/*
* Use the RC4 encryption algorithm [6] to encrypt Clear of
* length ClearLength octets into a Cypher of the same length
* such that the Cypher can only be decrypted back to Clear
* by providing a Key of length KeyLength octets.
*/
}
Rc4Encrypt(
IN x-octet Clear,
IN integer ClearLength,
IN y-octet Key,
IN integer KeyLength,
OUT x-octet Cypher )
{
/*
* Use the RC4 encryption algorithm [6] to encrypt Clear of
* length ClearLength octets into a Cypher of the same length
* such that the Cypher can only be decrypted back to Clear
* by providing a Key of length KeyLength octets.
*/
}
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 )
}
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 )
}
NewPasswordEncryptedWithOldLmPasswordHash( IN 0-to-256-unicode-char NewPassword, IN 0-to-256-unicode-char OldPassword, OUT datatype-PWBLOCK EncryptedPwBlock ) { LmPasswordHash( OldPassword, giving PasswordHash )
NewPasswordEncryptedWithOldLmPasswordHash（在0-to-256-unicode-char NewPassword中，在0-to-256-unicode-char OldPassword中，输出数据类型pBlock EncryptedPwBlock）{LmPasswordHash（OldPassword，给出PasswordHash）
EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash, giving EncryptedPwBlock ) }
EncryptPwBlockWithPasswordHash（NewPassword、PasswordHash、giving EncryptedPwBlock）}
OldLmPasswordHashEncryptedWithNewNtPasswordHash( IN 0-to-256-unicode-char NewPassword, IN 0-to-256-unicode-char OldPassword, OUT 16-octet EncryptedPasswordHash ) { LmPasswordHash( OldPassword, giving OldPasswordHash )
OldLmPasswordHashEncryptedWithNewNtPasswordHash（在0到256-unicode-char的NewPassword中，在0到256-unicode-char的OldPassword中，输出16个八位加密的PasswordHash）{LmPasswordHash（OldPassword，给出OldPasswordHash）
NtPasswordHash( NewPassword, giving NewPasswordHash )
NtPasswordHash（NewPassword，给出NewPasswordHash）
NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash, giving EncrytptedPasswordHash ) }
NtPasswordHashEncryptedWithBlock（OldPasswordHash、NewPasswordHash、giving EncrytptedPasswordHash）}
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 )
NtPasswordHashEncryptedWithBlock（在16个八位字节的密码哈希中，在16个八位字节的块中，输出16个八位字节的密码）{去加密（前8个八位字节的密码哈希，前7个八位字节的块，给出前8个八位字节的密码）
DesEncrypt( 2nd 8-octets PasswordHash, 2nd 7-octets Block, giving 2nd 8-octets Cypher ) }
去加密（第二个8-octets密码哈希，第二个7-octets块，给出第二个8-octets密码）}
Appendix B - Examples
附录B-示例
Here are some examples of typical negotiations. The peer is on the left and the authenticator is on the right.
以下是一些典型谈判的例子。对等方在左侧，验证器在右侧。
The packet sequence ID is incremented on each authentication retry Response and on the change password response. All cases where the packet sequence ID is updated are noted below.
在每个身份验证重试响应和更改密码响应中，数据包序列ID都会增加。更新包序列ID的所有情况如下所示。
Response retry is never allowed after 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.
更改密码后不允许响应重试。在响应重试后可能会更改密码。示例中显示了隐含的质询形式，但如果验证器在故障数据包中提供了“首次质询+23”的所有情况，则应将其替换为“C=CCCC”质询。
<- Challenge Response -> <- Success
<-挑战响应-><-成功
<- Challenge
Response ->
<- Failure (E=691 R=0)
<- Challenge
Response ->
<- Failure (E=691 R=0)
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Success
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Success
<- 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 ->
<- 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)
<- Failure (E=691 R=0)
<- Challenge
Response ->
<- Failure (E=648 R=0 V=2), disable short timeout
ChangePassword (++ID) to first challenge ->
<- Success
<- Challenge
Response ->
<- Failure (E=648 R=0 V=2), disable short timeout
ChangePassword (++ID) to first challenge ->
<- Success
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Failure (E=648 R=0 V=2), disable short timeout
ChangePassword (++ID) to first challenge+23 ->
<- Success
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Failure (E=648 R=0 V=2), disable short timeout
ChangePassword (++ID) to first challenge+23 ->
<- Success
Intermediate values for password "MyPw".
密码“MyPw”的中间值。
8-octet Challenge: 10 2D B5 DF 08 5D 30 41
8-八重奏挑战：10 2D B5 DF 08 5D 30 41
0-to-256-unicode-char NtPassword: 4D 00 79 00 50 00 77 00
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
16八位字节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
24个八位组NTChallenger响应：4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C A4 C3 51 AB 40 9A 3D 61
DES uses 56-bit keys, expanded to 64 bits by the insertion of parity bits. After the parity of the key has been fixed, every eighth bit is a parity bit and the number of bits that are set (1) in each octet is odd; i.e., odd parity. Note that many DES engines do not check parity, however, simply stripping the parity bits. The following example illustrates the values resulting from the use of the 16-octet NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys
DES使用56位键，通过插入奇偶校验位扩展到64位。在密钥的奇偶校验被固定后，每八位是奇偶校验位，并且在每个八位字节中设置（1）的位数是奇数；i、 奇偶校验。注意，许多DES引擎不检查奇偶校验，但是，只是剥离奇偶校验位。以下示例说明了使用附录B.2中所示的16个八位字节的NTPasswordHash生成一对DES密钥所产生的值
(e.g., for use in the NtPasswordHashEncryptedWithBlock() described in Appendix A.17).
（例如，用于附录A.17中描述的NtPasswordHashEncryptedWithBlock（）中）。
16-octet NtPasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16八位字节NtPasswordHash:FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
First "raw" DES key (initial 7 octets of password hash): FC 15 6A F7 ED CD 6C
第一个“原始”DES密钥（密码散列的初始7个八位字节）：FC 15 6A F7 ED CD 6C
First parity-corrected DES key (eight octets): FD 0B 5B 5E 7F 6E 34 D9
第一个奇偶校验DES键（八个八位组）：FD0B5B5E7F6E34D9
Second "raw" DES key (second 7 octets of password hash) 0E DD E3 33 7D 42 7F
第二个“原始”DES密钥（密码散列的第二个7个八位字节）0E DD E3 33 7D 42 7F
Second parity-corrected DES key (eight octets): 0E 6E 79 67 37 EA 08 FE
第二奇偶校验DES键（八个八位组）：0E 6E 79 67 37 EA 08 FE
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。