Network Working Group G. Zorn
Request for Comments: 2759 Microsoft Corporation
Category: Informational January 2000
Network Working Group G. Zorn
Request for Comments: 2759 Microsoft Corporation
Category: Informational January 2000
Microsoft PPP CHAP Extensions, Version 2
Microsoft PPP CHAP扩展，第2版
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
点到点协议（PPP）[1]提供了通过点到点链路传输多协议数据报的标准方法。PPP定义了一个可扩展链路控制协议和一系列网络控制协议（NCP），用于建立和配置不同的网络层协议。
This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication.
本文档介绍了Microsoft PPP CHAP方言（MS-CHAP-V2）的第二版。MS-CHAP-V2与MS-CHAP版本1（MS-CHAP-V1，如[9]所述）相似，但不兼容。特别是，某些协议字段已被删除或重用，但语义不同。此外，MS-CHAP-V2还具有相互身份验证功能。
The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9.
第8节描述了生成各种MS-CHAP-V2协议字段时使用的算法。协商和散列生成示例见第9节。
Specification of Requirements
需求说明
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [3].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[3]所述。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenge Packet . . . . . . . . . . . . . . . . . . . . . . . 3
4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . 6
8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . 7
8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . 8
8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . 9
8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . 9
8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . 9
8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . 10
8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10
8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . 12
8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12
8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13
8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13
8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . 14
8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15
9.1.2. Authenticator authentication failure . . . . . . . . . . . 15
9.1.3. Failed authentication with no retry allowed . . . . . . . . 15
9.1.4. Successful authentication after retry . . . . . . . . . . . 15
9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . 15
9.1.6. Successful authentication with password change . . . . . . 16
9.1.7. Successful authentication with retry and password change. . 16
9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . 16
9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenge Packet . . . . . . . . . . . . . . . . . . . . . . . 3
4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . 6
8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . 7
8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . 8
8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . 9
8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . 9
8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . 9
8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . 10
8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10
8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . 12
8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12
8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13
8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13
8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . 14
8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15
9.1.2. Authenticator authentication failure . . . . . . . . . . . 15
9.1.3. Failed authentication with no retry allowed . . . . . . . . 15
9.1.4. Successful authentication after retry . . . . . . . . . . . 15
9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . 15
9.1.6. Successful authentication with password change . . . . . . 16
9.1.7. Successful authentication with retry and password change. . 16
9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . 16
9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and standard CHAP. Briefly, the differences between MS-CHAP-V2 and MS-CHAP-V1 are:
在可能的情况下，MS-CHAP-V2与MS-CHAP-V1和标准CHAP一致。简而言之，MS-CHAP-V2和MS-CHAP-V1之间的区别如下：
* MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP option 3, Authentication Protocol.
* MS-CHAP-V2通过协商LCP选项3“身份验证协议”中的CHAP算法0x81启用。
* MS-CHAP-V2 provides mutual authentication between peers by piggybacking a peer challenge on the Response packet and an authenticator response on the Success packet.
* MS-CHAP-V2通过在响应数据包上搭载对等质询和在成功数据包上搭载验证器响应，在对等方之间提供相互认证。
* The calculation of the "Windows NT compatible challenge response" sub-field in the Response packet has been changed to include the peer challenge and the user name.
* 响应数据包中“Windows NT compatible challenge response”子字段的计算已更改为包括对等质询和用户名。
* In MS-CHAP-V1, the "LAN Manager compatible challenge response" sub-field was always sent in the Response packet. This field has been replaced in MS-CHAP-V2 by the Peer-Challenge field.
* 在MS-CHAP-V1中，“LAN Manager兼容质询响应”子字段始终在响应数据包中发送。在MS-CHAP-V2中，此字段已被对等质询字段替换。
* The format of the Message field in the Failure packet has been changed.
* 故障数据包中消息字段的格式已更改。
* The Change Password (version 1) and Change Password (version 2) packets are no longer supported. They have been replaced with a single Change-Password packet.
* 不再支持更改密码（版本1）和更改密码（版本2）数据包。它们已被替换为单个更改密码包。
The LCP configuration for MS-CHAP-V2 is identical to that for standard CHAP, except that the Algorithm field has value 0x81, rather than the MD5 value 0x05. PPP implementations which do not support MS-CHAP-V2, but correctly implement LCP Config-Rej, should have no problem dealing with this non-standard option.
MS-CHAP-V2的LCP配置与标准CHAP相同，只是算法字段的值为0x81，而不是MD5值0x05。不支持MS-CHAP-V2，但正确实现LCP Config Rej的PPP实现在处理此非标准选项时应该没有问题。
The MS-CHAP-V2 Challenge packet is identical in format to the standard CHAP Challenge packet.
MS-CHAP-V2质询数据包的格式与标准CHAP质询数据包的格式相同。
MS-CHAP-V2 authenticators send an 16-octet challenge Value field. Peers need not duplicate Microsoft's algorithm for selecting the 16- octet value, but the standard guidelines on randomness [1,2,7] SHOULD be observed.
MS-CHAP-V2身份验证程序发送16个八位字节的质询值字段。同行不需要重复微软的算法来选择16个八位组的值，但是应该遵守随机性的标准准则[1,2,7]。
Microsoft authenticators do not currently provide information in the Name field. This may change in the future.
Microsoft验证器当前不在名称字段中提供信息。这在将来可能会改变。
The MS-CHAP-V2 Response packet is identical in format to the standard CHAP Response packet. However, the Value field is sub-formatted differently as follows:
MS-CHAP-V2响应数据包的格式与标准CHAP响应数据包的格式相同。但是，值字段的子格式不同，如下所示：
16 octets: Peer-Challenge 8 octets: Reserved, must be zero 24 octets: NT-Response 1 octet : Flags
16个八位字节：对等挑战8个八位字节：保留，必须为零24个八位字节：NT响应1个八位字节：标志
The Peer-Challenge field is a 16-octet random number. As the name implies, it is generated by the peer and is used in the calculation of the NT-Response field, below. Peers need not duplicate Microsoft's algorithm for selecting the 16-octet value, but the standard guidelines on randomness [1,2,7] SHOULD be observed.
对等质询字段是一个16个八位组的随机数。顾名思义，它由对等方生成，并用于计算NT响应字段，如下所示。同行无需重复微软选择16个八位组值的算法，但应遵守随机性标准指南[1,2,7]。
The NT-Response field is an encoded function of the password, the user name, the contents of the Peer-Challenge field and the received challenge as output by the routine GenerateNTResponse() (see section 8.1, 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. When computing the NT-Response field contents, only the user name is used, without any associated Windows NT domain name. This is true regardless of whether a Windows NT domain name is present in the Name field (see below).
NT响应字段是密码、用户名、对等质询字段的内容和接收到的质询的编码函数，作为例程GeneraterResponse（）的输出（参见下面第8.1节）。Windows NT密码是由0到（理论上）256个区分大小写的Unicode[8]字符组成的字符串。当前版本的Windows NT将密码限制为14个字符，主要是出于兼容性原因；这在将来可能会改变。计算NT响应字段内容时，只使用用户名，不使用任何关联的Windows NT域名。无论名称字段中是否存在Windows NT域名（请参见下文），这都是正确的。
The Flag field is reserved for future use and MUST be zero.
标志字段保留供将来使用，并且必须为零。
The Name field is a string of 0 to (theoretically) 256 case-sensitive ASCII characters which 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 "johndoe"). If a domain is not provided, the backslash should also be omitted, (e.g. "johndoe").
名称字段是一个由0到（理论上）256个区分大小写的ASCII字符组成的字符串，用于标识对等方的用户帐户名称。Windows NT域名可以作为用户帐户名的前缀（例如，“BIGCO\johndoe”，其中“BIGCO”是包含用户帐户“johndoe”的Windows NT域）。如果未提供域，还应省略反斜杠（例如“johndoe”）。
The Success packet is identical in format to the standard CHAP Success packet. However, the Message field contains a 42-octet authenticator response string and a printable message. The format of the message field is illustrated below.
成功数据包的格式与标准CHAP成功数据包的格式相同。但是，消息字段包含42个八位字节的验证器响应字符串和可打印消息。消息字段的格式如下所示。
"S=<auth_string> M=<message>"
"S=<auth_string> M=<message>"
The <auth_string> quantity is a 20 octet number encoded in ASCII as 40 hexadecimal digits. The hexadecimal digits A-F (if present) MUST be uppercase. This number is derived from the challenge from the Challenge packet, the Peer-Challenge and NT-Response fields from the Response packet, and the peer password as output by the routine GenerateAuthenticatorResponse() (see section 8.7, below). The authenticating peer MUST verify the authenticator response when a Success packet is received. The method for verifying the authenticator is described in section 8.8, below. If the authenticator response is either missing or incorrect, the peer MUST end the session.
<auth_string>数量是一个20个八位组的数字，用ASCII编码为40个十六进制数字。十六进制数字A-F（如果存在）必须为大写。该数字来源于来自质询数据包的质询、来自响应数据包的对等质询和NT响应字段，以及由例程GenerateAuthenticatorResponse（）输出的对等密码（见下文第8.7节）。当接收到成功数据包时，身份验证对等方必须验证验证器响应。下面第8.8节描述了验证验证器的方法。如果验证器响应缺失或不正确，对等方必须结束会话。
The <message> quantity is human-readable text in the appropriate charset and language [12].
<message>数量是适当字符集和语言的人类可读文本[12]。
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 operation of the protocol. The Message field format is:
故障数据包的格式与标准CHAP故障数据包的格式相同。但是，与标准CHAP规则相反，消息字段中存储的格式化文本确实会影响协议的操作。消息字段格式为：
"E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv
M=<msg>"
"E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv
M=<msg>"
where
哪里
The "eeeeeeeeee" is the ASCII representation of a 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位数字）的ASCII表示形式，对应于下面列出的其中一个错误代码，尽管实现应该优雅地处理不在此列表中的代码。
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 an ASCII 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”是一个ASCII标志，如果允许重试，则设置为“1”；如果不允许重试，则设置为“0”。当验证器将此标志设置为“1”时，它将禁用短超时，期望对等方提示用户输入新凭据并重新提交响应。
The "cccccccccccccccccccccccccccccccc" is the ASCII representation of a hexadecimal challenge value. This field MUST be exactly 32 octets long and MUST be present.
“CCCCCC”是十六进制质询值的ASCII表示形式。此字段的长度必须正好为32个八位字节，并且必须存在。
The "vvvvvvvvvv" is the ASCII representation of a decimal version code (need not be 10 digits) indicating the password changing protocol version supported on the server. For MS-CHAP-V2, this value SHOULD always be 3.
“VVV”是十进制版本代码（不需要是10位数字）的ASCII表示形式，表示服务器上支持的密码更改协议版本。对于MS-CHAP-V2，此值应始终为3。
<msg> is human-readable text in the appropriate charset and language [12].
<msg>是适当字符集和语言的人类可读文本[12]。
The Change-Password packet does not appear in either standard CHAP or MS-CHAP-V1. It allows the peer to change the password on the account specified in the preceding Response packet. The Change-Password packet should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED (E=648) in the Message field of the Failure packet.
更改密码数据包不会出现在标准CHAP或MS-CHAP-V1中。它允许对等方在前面的响应数据包中指定的帐户上更改密码。仅当验证器在失败数据包的消息字段中报告错误\u PASSWD\u EXPIRED（E=648）时，才应发送更改密码数据包。
This packet type is supported by recent versions of Windows NT 4.0, Windows 95 and Windows 98. It is not supported by Windows NT 3.5, Windows NT 3.51, or early versions of Windows NT 4.0, Windows 95 and Windows 98.
最新版本的Windows NT 4.0、Windows 95和Windows 98支持此数据包类型。Windows NT 3.5、Windows NT 3.51或早期版本的Windows NT 4.0、Windows 95和Windows 98不支持此功能。
The format of this packet is as follows:
此数据包的格式如下：
1 octet : Code 1 octet : Identifier 2 octets : Length 516 octets : Encrypted-Password 16 octets : Encrypted-Hash 16 octets : Peer-Challenge 8 octets : Reserved 24 octets : NT-Response 2-octet : Flags
1个八位组：代码1个八位组：标识符2个八位组：长度516个八位组：加密密码16个八位组：加密哈希16个八位组：对等质询8个八位组：保留24个八位组：NT响应2个八位组：标志
Code 7
代码7
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 586
长度586
Encrypted-Password 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 8.9, below).
加密密码此字段包含由NewPasswordEncryptedWithOldNtPasswordHash（）例程输出的用旧Windows NT密码哈希加密的新Windows NT密码的PWBLOCK格式（请参阅下面的第8.9节）。
Encrypted-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 8.12, below).
加密散列此字段包含由OldNtPasswordHashEncryptedWithNewNtPasswordHash（）例程输出的用新的Windows NT密码散列加密的旧Windows NT密码散列（见下面第8.12节）。
Peer-Challenge A 16-octet random quantity, as described in the Response packet description.
对等方质询16个八位组的随机量，如响应包描述中所述。
Reserved 8 octets, must be zero.
保留8个八位字节，必须为零。
NT-Response The NT-Response field (as described in the Response packet description), but calculated on the new password and the challenge received in the Failure packet.
NT响应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. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bits 0-15 Reserved, always clear (0).
保留位0-15，始终清除（0）。
The routines mentioned in the text above are described in pseudocode in the following sections.
上文提到的例程将在以下部分中以伪代码进行描述。
GenerateNTResponse( IN 16-octet AuthenticatorChallenge, IN 16-octet PeerChallenge,
GenerateResponse（在16个八位字节的验证器挑战中，在16个八位字节的PeerChallenge中，
IN 0-to-256-char UserName,
在0到256字符的用户名中，
IN 0-to-256-unicode-char Password, OUT 24-octet Response ) { 8-octet Challenge 16-octet PasswordHash
在0-to-256-unicode-char密码中，输出24个八位字节响应）{8个八位字节挑战16个八位字节密码哈希
ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, giving Challenge)
ChallengeHash（PeerChallenge、AuthenticatorChallenge、UserName、giving Challenge）
NtPasswordHash( Password, giving PasswordHash ) ChallengeResponse( Challenge, PasswordHash, giving Response ) }
NtPasswordHash（密码，给出密码哈希）ChallengeResponse（质询，密码哈希，给出响应）}
ChallengeHash( IN 16-octet PeerChallenge, IN 16-octet AuthenticatorChallenge, IN 0-to-256-char UserName, OUT 8-octet Challenge {
ChallengeHash（在16个八位字节的PeerChallenge中，在16个八位字节的AuthenticatorChallenge中，在0到256个字符的用户名中，在8个八位字节的Challenge中{
/*
* SHAInit(), SHAUpdate() and SHAFinal() functions are an
* implementation of Secure Hash Algorithm (SHA-1) [11]. These are
* available in public domain or can be licensed from
* RSA Data Security, Inc.
*/
/*
* SHAInit(), SHAUpdate() and SHAFinal() functions are an
* implementation of Secure Hash Algorithm (SHA-1) [11]. These are
* available in public domain or can be licensed from
* RSA Data Security, Inc.
*/
SHAInit(Context) SHAUpdate(Context, PeerChallenge, 16) SHAUpdate(Context, AuthenticatorChallenge, 16)
SHAInit（上下文）SHAUpdate（上下文，PeerChallenge，16）SHAUpdate（上下文，AuthenticatorChallenge，16）
/*
* Only the user name (as presented by the peer and
* excluding any prepended domain name)
* is used as input to SHAUpdate().
*/
/*
* Only the user name (as presented by the peer and
* excluding any prepended domain name)
* is used as input to SHAUpdate().
*/
SHAUpdate(Context, UserName, strlen(Username)) SHAFinal(Context, Digest) memcpy(Challenge, Digest, 8) }
SHAUpdate（Context，UserName，strlen（UserName））SHAFinal（Context，Digest）memcpy（Challenge，Digest，8）}
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.
*/
}
HashNtPasswordHash(
IN 16-octet PasswordHash,
OUT 16-octet PasswordHashHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash
* PasswordHash into PasswordHashHash.
*/
}
HashNtPasswordHash(
IN 16-octet PasswordHash,
OUT 16-octet PasswordHashHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash
* PasswordHash into PasswordHashHash.
*/
}
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位字节的响应）}
DesEncrypt(
IN 8-octet Clear,
IN 7-octet Key,
OUT 8-octet Cypher )
{
/*
* Use the DES encryption algorithm [4] in ECB mode [10]
* 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 [10]
* 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.
*/
}
GenerateAuthenticatorResponse( IN 0-to-256-unicode-char Password, IN 24-octet NT-Response, IN 16-octet PeerChallenge, IN 16-octet AuthenticatorChallenge, IN 0-to-256-char UserName, OUT 42-octet AuthenticatorResponse ) { 16-octet PasswordHash 16-octet PasswordHashHash 8-octet Challenge
GenerateAuthenticatorResponse（0-to-256-unicode-char密码、24个八位字节的NT响应、16个八位字节的PeerChallenge、16个八位字节的AuthenticatorChallenge、0-to-256-char用户名、42个八位字节的AuthenticatorResponse）{16个八位字节的密码hash 8个八位字节的挑战
/*
* "Magic" constants used in response generation
*/
/*
* "Magic" constants used in response generation
*/
Magic1[39] = {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74};
Magic1[39]={0x4D、0x61、0x67、0x69、0x63、0x20、0x73、0x65、0x72、0x76、0x65、0x72、0x20、0x74、0x6F、0x20、0x63、0x6C、0x69、0x65、0x6E、0x74、0x20、0x73、0x69、0x67、0x6E、0x67、0x20、0x63、0x6F、0x6E、0x6E、0x6E、0x73、0x74、0x61、0x6E、0x74}；
Magic2[41] = {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, 0x6E};
Magic2[41]={0x50、0x61、0x64、0x20、0x74、0x6F、0x20、0x6D、0x61、0x6B、0x65、0x20、0x69、0x74、0x20、0x64、0x6F、0x20、0x6D、0x6F、0x72、0x65、0x20、0x68、0x61、0x6E、0x20、0x6F、0x6E、0x65、0x20、0x69、0x74、0x65、0x72、0x61、0x74、0x69、0x6F、0x6E}；
/*
* Hash the password with MD4
*/
/*
* Hash the password with MD4
*/
NtPasswordHash( Password, giving PasswordHash )
NtPasswordHash（密码，给定密码哈希）
/*
* Now hash the hash
*/
/*
* Now hash the hash
*/
HashNtPasswordHash( PasswordHash, giving PasswordHashHash)
HashNtPasswordHash（PasswordHash，给定PasswordHashHash）
SHAInit(Context) SHAUpdate(Context, PasswordHashHash, 16) SHAUpdate(Context, NTResponse, 24) SHAUpdate(Context, Magic1, 39) SHAFinal(Context, Digest)
SHAInit（Context）SHAUpdate（Context，PasswordHashHash，16）SHAUpdate（Context，NTResponse，24）SHAUpdate（Context，Magic1，39）SHAFinal（Context，Digest）
ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, giving Challenge)
ChallengeHash（PeerChallenge、AuthenticatorChallenge、UserName、giving Challenge）
SHAInit(Context) SHAUpdate(Context, Digest, 20) SHAUpdate(Context, Challenge, 8) SHAUpdate(Context, Magic2, 41) SHAFinal(Context, Digest)
SHAInit（上下文）SHAUpdate（上下文，摘要，20）SHAUpdate（上下文，挑战，8）SHAUpdate（上下文，Magic2，41）SHAFinal（上下文，摘要）
/*
* Encode the value of 'Digest' as "S=" followed by
* 40 ASCII hexadecimal digits and return it in
* AuthenticatorResponse.
* For example,
* "S=0123456789ABCDEF0123456789ABCDEF01234567"
*/
/*
* Encode the value of 'Digest' as "S=" followed by
* 40 ASCII hexadecimal digits and return it in
* AuthenticatorResponse.
* For example,
* "S=0123456789ABCDEF0123456789ABCDEF01234567"
*/
}
}
CheckAuthenticatorResponse( IN 0-to-256-unicode-char Password, IN 24-octet NtResponse, IN 16-octet PeerChallenge, IN 16-octet AuthenticatorChallenge, IN 0-to-256-char UserName, IN 42-octet ReceivedResponse, OUT Boolean ResponseOK ) {
CheckAuthenticatorResponse（0-to-256-unicode-char密码、24个八位字节的NtResponse、16个八位字节的PeerCallenge、16个八位字节的AuthenticatorChallenge、0-to-256-char用户名、42个八位字节的ReceivedResponse、OUT Boolean ResponseOK）{
20-octet MyResponse
20八位元MyResponse
set ResponseOK = FALSE GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge, AuthenticatorChallenge, UserName, giving MyResponse)
set-ResponseOK=FALSE GenerateAuthenticator响应（密码、NtResponse、PeerCallenge、Authenticator质询、用户名、给出MyResponse）
if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE return ResponseOK }
如果（MyResponse=ReceivedResponse），则设置ResponseOK=TRUE返回ResponseOK}
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, OUT datatype-PWBLOCK PwBlock ) {
EncryptPwBlockWithPasswordHash（0-to-256-unicode-char密码，16位八位组密码哈希，输出数据类型PWBLOCK PWBLOCK）{
Fill ClearPwBlock with random octet values
用随机八位组值填充ClearPwBlock
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 )
}
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 )
}
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密码）}
The following sections include protocol negotiation and hash generation examples.
以下部分包括协议协商和哈希生成示例。
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.
更改密码后不允许响应重试。在响应重试后可能会更改密码。
<- Authenticator Challenge
Peer Response/Challenge ->
<- Success/Authenticator Response
<- Authenticator Challenge
Peer Response/Challenge ->
<- Success/Authenticator Response
(Authenticator Response verification succeeds, call continues)
（验证器响应验证成功，呼叫继续）
<- Authenticator Challenge
Peer Response/Challenge ->
<- Success/Authenticator Response
<- Authenticator Challenge
Peer Response/Challenge ->
<- Success/Authenticator Response
(Authenticator Response verification fails, peer disconnects)
（验证器响应验证失败，对等断开连接）
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=0)
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=0)
(Authenticator disconnects)
（验证器断开连接）
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in failure message ->
<- Success/Authenticator Response
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in failure message ->
<- Success/Authenticator Response
(Authenticator Response verification succeeds, call continues)
（验证器响应验证成功，呼叫继续）
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in Failure message ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in Failure message ->
<- Failure (E=691 R=0)
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in Failure message ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in Failure message ->
<- Failure (E=691 R=0)
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=648 R=0 V=3), disable short
timeout
ChangePassword (++ID) to challenge in Failure message ->
<- Success/Authenticator Response
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=648 R=0 V=3), disable short
timeout
ChangePassword (++ID) to challenge in Failure message ->
<- Success/Authenticator Response
(Authenticator Response verification succeeds, call continues)
（验证器响应验证成功，呼叫继续）
<- Authenticator Challenge
Peer Response/Challenge ->
<- 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/Authenticator Response
<- Authenticator Challenge
Peer Response/Challenge ->
<- 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/Authenticator Response
(Authenticator Response verification succeeds, call continues)
（验证器响应验证成功，呼叫继续）
Intermediate values for user name "User" and password "clientPass". All numeric values are hexadecimal.
用户名“user”和密码“clientPass”的中间值。所有数值均为十六进制。
0-to-256-char UserName: 55 73 65 72
0到256字符用户名：55 73 65 72
0-to-256-unicode-char Password: 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00
0-to-256-unicode-char密码：63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00
16-octet AuthenticatorChallenge: 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28
16八位字节验证器挑战：5B 5D 7C 7D 7B 3F 2F 3E 3C 60 21 32 26 28
16-octet PeerChallenge: 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
16八重奏对白：21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
8-octet Challenge: D0 2E 43 86 BC E9 12 26
8-八重奏挑战：D0 2E 43 86 BC E9 12 26
16-octet PasswordHash: 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
16八位字节密码哈希：44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
24 octet NT-Response: 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF
24个八重奏NT应答：82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF
16-octet PasswordHashHash: 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
16八位字节密码哈希：41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
42-octet AuthenticatorResponse: "S=407A5589115FD0D6209F510FE9C04566932CDA56"
42八位字节身份验证响应：“S=407A5589115FD0D6209F510FE9C04566932CDA56”
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 password "MyPw" to generate a pair of DES keys (e.g., for use in the NtPasswordHashEncryptedWithBlock() described in section 8.13).
DES使用56位键，通过插入奇偶校验位扩展到64位。在密钥的奇偶校验被固定后，每八位是奇偶校验位，并且在每个八位字节中设置（1）的位数是奇数；i、 奇偶校验。注意，许多DES引擎不检查奇偶校验，但是，只是剥离奇偶校验位。以下示例说明了使用密码“MyPw”生成一对DES密钥（例如，用于第8.13节所述的NtPasswordHashEncryptedWithBlock（）中）所产生的值。
0-to-256-unicode-char Password: 4D 79 50 77
0-to-256-unicode-char密码：4D 79 50 77
16-octet PasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16个八位密码哈希：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
As an implementation detail, the authenticator SHOULD limit the number of password retries allowed to make brute-force password guessing attacks more difficult.
作为一个实现细节，身份验证器应该限制允许的密码重试次数，以使暴力密码猜测攻击更加困难。
[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:
[6] RC4是RSA Data Security Inc.许可下提供的专有加密算法。有关许可信息，请联系：
RSA Data Security, Inc. 100 Marine Parkway Redwood City, CA 94065-1031
RSA Data Security，Inc.加利福尼亚州红木市海洋公园路100号，邮编94065-1031
[7] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations 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] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[9] Zorn，G.和Cobb，S.，“微软PPP CHAP扩展”，RFC 2433，1998年10月。
[10] "DES Modes of Operation", Federal Information Processing Standards Publication 81, National Institute of Standards and Technology, December 1980.
[10] “DES操作模式”，联邦信息处理标准出版物81，国家标准与技术研究所，1980年12月。
[11] "Secure Hash Standard", Federal Information Processing Standards Publication 180-1, National Institute of Standards and Technology, April 1995.
[11] “安全散列标准”，联邦信息处理标准出版物180-1，国家标准与技术研究所，1995年4月。
[12] Zorn, G., "PPP LCP Internationalization Configuration Option", RFC 2484, January 1999.
[12] Zorn，G.“PPP LCP国际化配置选项”，RFC 2484，1999年1月。
Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul Leach, Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh Pall, Jody Terrill, Brad Robel-Forrest, and Joe Davies for useful suggestions and feedback.
感谢布鲁斯·约翰逊、托尼·贝尔、保罗·里奇、特伦斯·斯皮尔斯、丹·西蒙、纳伦德拉·吉德瓦尼、古迪普·辛格·帕尔、乔迪·泰瑞尔、布拉德·罗伯尔·福雷斯和乔·戴维斯（无特殊顺序）提供了有用的建议和反馈。
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: gwz@acm.org
Phone: +1 425 703 1559
Fax: +1 425 936 7329
EMail: gwz@acm.org
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。