Internet Engineering Task Force (IETF) D. Harkins
Request for Comments: 5931 Aruba Networks
Category: Informational G. Zorn
ISSN: 2070-1721 Network Zen
August 2010
Internet Engineering Task Force (IETF) D. Harkins
Request for Comments: 5931 Aruba Networks
Category: Informational G. Zorn
ISSN: 2070-1721 Network Zen
August 2010
Extensible Authentication Protocol (EAP) Authentication Using Only a Password
仅使用密码的可扩展身份验证协议（EAP）身份验证
Abstract
摘要
This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.
本备忘录描述了可扩展身份验证协议（EAP）方法EAP pwd，该方法使用共享密码进行身份验证。密码可能是低熵密码，并且可能来自攻击者可用的一组可能的密码，如字典。底层密钥交换可以抵抗主动攻击、被动攻击和字典攻击。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5931.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5931.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Keyword Definitions . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Resistance to Passive Attack . . . . . . . . . . . . . 4
1.3.2. Resistance to Active Attack . . . . . . . . . . . . . 5
1.3.3. Resistance to Dictionary Attack . . . . . . . . . . . 5
1.3.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . 5
2. Specification of EAP-pwd . . . . . . . . . . . . . . . . . . . 5
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 7
2.2.1. Finite Field Cryptography . . . . . . . . . . . . . . 7
2.2.2. Elliptic Curve Cryptography . . . . . . . . . . . . . 8
2.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Instantiating the Random Function . . . . . . . . . . . . 9
2.5. Key Derivation Function . . . . . . . . . . . . . . . . . 10
2.6. Random Numbers . . . . . . . . . . . . . . . . . . . . . . 10
2.7. Representation and Processing of Input Strings . . . . . . 11
2.7.1. Identity Strings . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Keyword Definitions . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Resistance to Passive Attack . . . . . . . . . . . . . 4
1.3.2. Resistance to Active Attack . . . . . . . . . . . . . 5
1.3.3. Resistance to Dictionary Attack . . . . . . . . . . . 5
1.3.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . 5
2. Specification of EAP-pwd . . . . . . . . . . . . . . . . . . . 5
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 7
2.2.1. Finite Field Cryptography . . . . . . . . . . . . . . 7
2.2.2. Elliptic Curve Cryptography . . . . . . . . . . . . . 8
2.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Instantiating the Random Function . . . . . . . . . . . . 9
2.5. Key Derivation Function . . . . . . . . . . . . . . . . . 10
2.6. Random Numbers . . . . . . . . . . . . . . . . . . . . . . 10
2.7. Representation and Processing of Input Strings . . . . . . 11
2.7.1. Identity Strings . . . . . . . . . . . . . . . . . . . 11
2.7.2. Passwords . . . . . . . . . . . . . . . . . . . . . . 11
2.8. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.2. Message Flows . . . . . . . . . . . . . . . . . . . . 12
2.8.3. Fixing the Password Element . . . . . . . . . . . . . 14
2.8.3.1. ECC Operation for PWE . . . . . . . . . . . . . . 15
2.8.3.2. FFC Operation for pwe . . . . . . . . . . . . . . 16
2.8.4. Message Construction . . . . . . . . . . . . . . . . . 16
2.8.4.1. ECC Groups . . . . . . . . . . . . . . . . . . . . 16
2.8.4.2. FFC Groups . . . . . . . . . . . . . . . . . . . . 17
2.8.5. Message Processing . . . . . . . . . . . . . . . . . . 18
2.8.5.1. EAP-pwd-ID Exchange . . . . . . . . . . . . . . . 18
2.8.5.2. EAP-pwd-Commit Exchange . . . . . . . . . . . . . 20
2.8.5.3. EAP-pwd-Confirm Exchange . . . . . . . . . . . . . 21
2.9. Management of EAP-pwd Keys . . . . . . . . . . . . . . . . 22
2.10. Mandatory-to-Implement Parameters . . . . . . . . . . . . 23
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1. EAP-pwd Header . . . . . . . . . . . . . . . . . . . . . . 23
3.2. EAP-pwd Payloads . . . . . . . . . . . . . . . . . . . . . 25
3.2.1. EAP-pwd-ID . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2. EAP-pwd-Commit . . . . . . . . . . . . . . . . . . . . 26
3.2.3. EAP-pwd-Confirm . . . . . . . . . . . . . . . . . . . 27
3.3. Representation of Group Elements and Scalars . . . . . . . 27
3.3.1. Elements in FFC Groups . . . . . . . . . . . . . . . . 27
3.3.2. Elements in ECC Groups . . . . . . . . . . . . . . . . 28
3.3.3. Scalars . . . . . . . . . . . . . . . . . . . . . . . 28
4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6.1. Resistance to Passive Attack . . . . . . . . . . . . . . . 31
6.2. Resistance to Active Attack . . . . . . . . . . . . . . . 31
6.3. Resistance to Dictionary Attack . . . . . . . . . . . . . 32
6.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 34
6.5. Group Strength . . . . . . . . . . . . . . . . . . . . . . 34
6.6. Random Functions . . . . . . . . . . . . . . . . . . . . . 34
7. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . . 38
2.7.2. Passwords . . . . . . . . . . . . . . . . . . . . . . 11
2.8. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.2. Message Flows . . . . . . . . . . . . . . . . . . . . 12
2.8.3. Fixing the Password Element . . . . . . . . . . . . . 14
2.8.3.1. ECC Operation for PWE . . . . . . . . . . . . . . 15
2.8.3.2. FFC Operation for pwe . . . . . . . . . . . . . . 16
2.8.4. Message Construction . . . . . . . . . . . . . . . . . 16
2.8.4.1. ECC Groups . . . . . . . . . . . . . . . . . . . . 16
2.8.4.2. FFC Groups . . . . . . . . . . . . . . . . . . . . 17
2.8.5. Message Processing . . . . . . . . . . . . . . . . . . 18
2.8.5.1. EAP-pwd-ID Exchange . . . . . . . . . . . . . . . 18
2.8.5.2. EAP-pwd-Commit Exchange . . . . . . . . . . . . . 20
2.8.5.3. EAP-pwd-Confirm Exchange . . . . . . . . . . . . . 21
2.9. Management of EAP-pwd Keys . . . . . . . . . . . . . . . . 22
2.10. Mandatory-to-Implement Parameters . . . . . . . . . . . . 23
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1. EAP-pwd Header . . . . . . . . . . . . . . . . . . . . . . 23
3.2. EAP-pwd Payloads . . . . . . . . . . . . . . . . . . . . . 25
3.2.1. EAP-pwd-ID . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2. EAP-pwd-Commit . . . . . . . . . . . . . . . . . . . . 26
3.2.3. EAP-pwd-Confirm . . . . . . . . . . . . . . . . . . . 27
3.3. Representation of Group Elements and Scalars . . . . . . . 27
3.3.1. Elements in FFC Groups . . . . . . . . . . . . . . . . 27
3.3.2. Elements in ECC Groups . . . . . . . . . . . . . . . . 28
3.3.3. Scalars . . . . . . . . . . . . . . . . . . . . . . . 28
4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6.1. Resistance to Passive Attack . . . . . . . . . . . . . . . 31
6.2. Resistance to Active Attack . . . . . . . . . . . . . . . 31
6.3. Resistance to Dictionary Attack . . . . . . . . . . . . . 32
6.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 34
6.5. Group Strength . . . . . . . . . . . . . . . . . . . . . . 34
6.6. Random Functions . . . . . . . . . . . . . . . . . . . . . 34
7. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . . 38
The predominant access method for the Internet today is that of a human using a username and password to authenticate to a computer enforcing access control. Proof of knowledge of the password authenticates the human and computer.
当今互联网的主要访问方法是人类使用用户名和密码向实施访问控制的计算机进行身份验证。密码知识证明对人和计算机进行身份验证。
Typically these passwords are not stored on a user's computer for security reasons and must be entered each time the human desires network access. Therefore, the passwords must be ones that can be repeatedly entered by a human with a low probability of error. They will likely not possess high-entropy, and it may be assumed that an adversary with access to a dictionary will have the ability to guess a user's password. It is therefore desirable to have a robust authentication method that is secure even when used with a weak password in the presence of a strong adversary.
通常，出于安全原因，这些密码不会存储在用户的计算机上，并且必须在每次人类希望访问网络时输入。因此，密码必须是可由人重复输入的密码，且出错概率较低。它们可能不具有高熵，并且可以假设能够访问字典的对手能够猜测用户的密码。因此，希望有一种健壮的身份验证方法，即使在存在强大对手的情况下使用弱密码时也是安全的。
EAP-pwd is an EAP method that addresses the problem of password-based authenticated key exchange -- using a possibly weak password for authentication to derive an authenticated and cryptographically strong shared secret. This problem was first described by Bellovin and Merritt in [BM92] and [BM93]. There have been a number of subsequent suggestions ([JAB96], [LUC97], [BMP00], and others) for password-based authenticated key exchanges.
EAP pwd是一种EAP方法，它解决了基于密码的经过身份验证的密钥交换问题——使用可能较弱的密码进行身份验证，以获得经过身份验证且加密性较强的共享密钥。贝洛文和梅里特在[BM92]和[BM93]中首次描述了这个问题。对于基于密码的认证密钥交换，随后提出了许多建议（[JAB96]、[LUC97]、[BMP00]等）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Any protocol that claims to solve the problem of password-authenticated key exchange must be resistant to active, passive, and dictionary attack and have the quality of forward secrecy. These characteristics are discussed further in the following sections.
任何声称能够解决密码认证密钥交换问题的协议都必须能够抵抗主动、被动和字典攻击，并且具有前向保密性。这些特性将在以下章节中进一步讨论。
A passive, or benign, attacker is one that merely relays messages back and forth between the peer and server, faithfully, and without modification. The contents of the messages are available for inspection, but that is all. To achieve resistance to passive attack, such an attacker must not be able to obtain any information about the password or anything about the resulting shared secret from
被动或良性的攻击者只是在对等方和服务器之间忠实地、不加修改地来回传递消息。消息的内容可供检查，但仅此而已。要实现对被动攻击的抵抗，此类攻击者必须无法从中获取有关密码或由此产生的共享秘密的任何信息
watching repeated runs of the protocol. Even if a passive attacker is able to learn the password, she will not be able to determine any information about the resulting secret shared by the peer and server.
观察协议的重复运行。即使被动攻击者能够识别密码，她也无法确定对等方和服务器共享的任何有关最终秘密的信息。
An active attacker is able to modify, add, delete, and replay messages sent between protocol participants. For this protocol to be resistant to active attack, the attacker must not be able to obtain any information about the password or the shared secret by using any of its capabilities. In addition, the attacker must not be able to fool a protocol participant into thinking that the protocol completed successfully.
主动攻击者能够修改、添加、删除和重播协议参与者之间发送的消息。为了使该协议能够抵抗主动攻击，攻击者必须不能使用其任何功能获取有关密码或共享秘密的任何信息。此外，攻击者不得欺骗协议参与者认为协议已成功完成。
It is always possible for an active attacker to deny delivery of a message critical in completing the exchange. This is no different than dropping all messages and is not an attack against the protocol.
主动攻击者总是有可能拒绝传递对完成交换至关重要的消息。这与删除所有消息没有什么区别，也不是对协议的攻击。
For this protocol to be resistant to dictionary attack, any advantage an adversary can gain must be directly related to the number of interactions she makes with an honest protocol participant and not through computation. The adversary will not be able to obtain any information about the password except whether a single guess from a single protocol run is correct or incorrect.
为了使该协议能够抵抗字典攻击，对手能够获得的任何优势都必须直接与她与诚实协议参与者的交互次数有关，而不是通过计算。对手将无法获得有关密码的任何信息，除非从单个协议运行中猜测密码是否正确。
Compromise of the password must not provide any information about the secrets generated by earlier runs of the protocol.
密码泄露不得提供有关协议早期运行产生的秘密的任何信息。
The following notation is used in this memo:
本备忘录中使用了以下符号：
peer-ID The peer's identity, the peer NAI [RFC4282].
对等方ID对等方的身份，对等方NAI[RFC4282]。
server-ID A string that identifies the server to the peer.
服务器ID向对等方标识服务器的字符串。
password The password shared between the peer and server.
密码对等方和服务器之间共享的密码。
y = H(x) The binary string x is given to a function H, which produces a fixed-length output y.
y=H（x）二进制字符串x被赋予函数H，该函数产生固定长度的输出y。
a | b The concatenation of string a with string b.
a | b字符串a与字符串b的串联。
[a]b A string consisting of the single bit "a" repeated "b" times.
[a] b由单个位“a”重复“b”次组成的字符串。
x mod y The remainder of division of x by y. The result will be between 0 and y.
x mod y x除以y的余数。结果将介于0和y之间。
g^x mod p The multiplication of the value "g" with itself "x" times, modulo the value "p".
g^x mod p值“g”与自身“x”的乘积，取值“p”的模。
inv(Q) The inverse of an element, Q, from a finite field.
inv（Q）有限域中元素Q的逆。
len(x) The length in bits of the string x.
len（x）字符串x的位长度。
chop(x, y) The reduction of string x, being at least y bits in length, to y bits.
将长度至少为y位的字符串x缩减为y位。
PRF(x,y) A pseudo-random function that takes a key, x, and variable-length data, y, and produces a fixed-length output that cannot be distinguished (with a significant advantage) from a random source.
PRF（x，y）一种伪随机函数，它接受一个键x和可变长度数据y，并产生一个固定长度的输出，该输出无法与随机源区分（具有显著优势）。
LSB(x) Returns the least-significant bit of the bitstring "x".
LSB（x）返回位字符串“x”的最低有效位。
Ciphersuite An encoding of a group to use with EAP-pwd, the definition of function H, and a PRF, in that order.
Ciphersuite按该顺序使用EAP pwd、函数H的定义和PRF的组编码。
MK The Master Key is generated by EAP-pwd. This is a high-entropy secret whose length depends on the random function used.
MK主密钥由EAP pwd生成。这是一个高熵秘密，其长度取决于使用的随机函数。
MSK The Master Session Key exported by EAP-pwd. This is a high-entropy secret 512 bits in length.
MSK EAP pwd导出的主会话密钥。这是一个长度为512位的高熵秘密。
EMSK The Extended Master Session Key exported by EAP-pwd. This is a high-entropy secret 512 bits in length.
EMSK EAP pwd导出的扩展主会话密钥。这是一个长度为512位的高熵秘密。
This protocol uses discrete logarithm cryptography to achieve authentication and key agreement (see [SP800-56A]). Each party to the exchange derives ephemeral keys with respect to a particular set of domain parameters (referred to here as a "group"). A group can be based on Finite Field Cryptography (FFC) or Elliptic Curve Cryptography (ECC).
该协议使用离散对数加密实现身份验证和密钥协商（见[SP800-56A]）。交换的每一方都获得与特定域参数集（此处称为“组”）相关的临时密钥。组可以基于有限域加密（FFC）或椭圆曲线加密（ECC）。
Domain parameters for the FFC groups used by EAP-pwd include:
EAP pwd使用的FFC组的域参数包括：
o A prime, p, determining a prime field GF(p), the integers modulo p. The FFC group will be a subgroup of GF(p)*, the multiplicative group of non-zero elements in GF(p). The group operation for FFC groups is multiplication modulo p.
o 一个素数，p，决定一个素数域GF（p），模p的整数。FFC群将是GF（p）*的子群，GF（p）中非零元素的乘法群。FFC组的组运算是乘法模p。
o An element, G, in GF(p)* which serves as a generator for the FFC group. G is chosen such that its multiplicative order is a sufficiently large prime divisor of ((p-1)/2).
o GF（p）*中的一个元素G，用作FFC组的生成器。选择G，使其乘法阶为（（p-1）/2）的足够大的素因子。
o A prime, r, which is the multiplicative order of G, and thus also the size of the cryptographic subgroup of GF(p)* that is generated by G.
o 素数r是G的乘法阶，因此也是G生成的GF（p）*的加密子群的大小。
An integer scalar, x, acts on an FFC group element, Y, via exponentiation modulo p -- Y^x mod p.
整数标量x通过模p--Y^x mod p的幂运算作用于FFC组元素Y。
The inverse function for an FFC group is defined such that the product of an element and its inverse modulo the group prime equals one (1). In other words,
FFC群的反函数定义为：元素及其逆模与群素数的乘积等于一（1）。换句话说,，
(q * inv(q)) mod p = 1
(q * inv(q)) mod p = 1
EAP-pwd uses an IANA registry for the definition of groups. Some FFC groups in this registry are based on safe primes and the order is not included in the domain parameters. In this case only, the order, r, MUST be computed as the prime minus one divided by two -- (p-1)/2. If the definition of the group includes an order in its domain
EAP pwd使用IANA注册表来定义组。此注册表中的某些FFC组基于安全素数，并且顺序不包括在域参数中。仅在这种情况下，阶数r必须计算为素数减1除以2——（p-1）/2。如果组的定义在其域中包含订单
parameters, that value MUST be used in this exchange when an order is called for. If an FFC group definition does not have an order in its domain parameters and it is not based on a safe prime, it MUST NOT be used with EAP-pwd.
参数，该值在调用订单时必须在此交换中使用。如果FFC组定义在其域参数中没有顺序，并且它不是基于安全素数，则不得与EAP pwd一起使用。
Domain parameters for the ECC groups used by EAP-pwd include:
EAP pwd使用的ECC组的域参数包括：
o A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group that consists of points on an elliptic curve -- elements from GF(p) that satisfy the curve's equation -- together with the "point at infinity" that serves as the identity element. The group operation for ECC groups is addition of points on the elliptic curve.
o 素数，p，决定素数域GF（p）。密码组将是完整椭圆曲线组的一个子组，由椭圆曲线上的点组成——满足曲线方程的GF（p）元素——以及作为身份元素的“无穷远点”。ECC群的群运算是在椭圆曲线上加点。
o Elements a and b from GF(p) that define the curve's equation. The point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only if (y^2 - x^3 - a*x - b) mod p equals zero (0).
o 定义曲线方程的GF（p）中的元素a和b。GF（p）xgf（p）中的点（x，y）在椭圆曲线上当且仅当（y^2-x^3-a*x-b）mod p等于零（0）。
o A point, G, on the elliptic curve, which serves as a generator for the ECC group. G is chosen such that its order, with respect to elliptic curve addition, is a sufficiently large prime.
o 椭圆曲线上的一个点G，用作ECC组的生成器。选择G，使其相对于椭圆曲线加法的阶数是一个足够大的素数。
o A prime, r, which is the order of G, and thus is also the size of the cryptographic subgroup that is generated by G.
o 素数r是G的阶数，因此也是由G生成的加密子群的大小。
o A co-factor, f, defined by the requirement that the size of the full elliptic curve group (including the "point at infinity") is the product of f and r.
o 一个协因子f，由完整椭圆曲线组（包括“无穷远点”）的大小为f和r的乘积的要求定义。
An integer scalar, x, acts on an ECC group element, Y, via repetitive addition (Y is added to itself x times), also called point multiplication -- x * Y.
整数标量x通过重复加法（Y自身加x次）作用于ECC组元素Y，也称为点乘--x*Y。
The inverse function for an ECC group is defined such that the sum of an element and its inverse is the "point at infinity" (the identity for elliptic curve point addition). In other words,
ECC群的反函数定义为，元素及其逆的和为“无穷远点”（椭圆曲线点加法的恒等式）。换句话说,，
Q + inv(Q) = "O"
Q + inv(Q) = "O"
Only ECC groups over GF(p) can be used by EAP-pwd. ECC groups over GF(2^m) SHALL NOT be used by EAP-pwd. While such groups exist in the IANA registry used by EAP-pwd, their use in EAP-pwd is not defined. In addition, ECC groups with a co-factor greater than one (1) SHALL NOT be used by EAP-pwd. At the time of publication, no such groups existed in the IANA registry used by EAP-pwd.
EAP pwd只能使用GF（p）上的ECC组。EAP pwd不得使用GF（2^m）以上的ECC组。虽然EAP pwd使用的IANA注册表中存在此类组，但未定义它们在EAP pwd中的使用。此外，EAP pwd不得使用系数大于一（1）的ECC组。在出版时，EAP pwd使用的IANA注册表中不存在此类组。
In order to see how the protocol addresses the requirements above (see Section 1.3), it is necessary to state some assumptions under which the protocol can be evaluated. They are:
为了了解协议如何满足上述要求（见第1.3节），有必要说明一些可以评估协议的假设。他们是：
1. Function H maps a binary string of indeterminate length onto a fixed binary string that is x bits in length.
1. 函数H将长度不确定的二进制字符串映射到长度为x位的固定二进制字符串上。
H: {0,1}^* --> {0,1}^x
H: {0,1}^* --> {0,1}^x
2. Function H is a "random oracle" (see [RANDOR]). Given knowledge of the input to H, an adversary is unable to distinguish the output of H from a random data source.
2. 函数H是一个“随机预言”（参见[RANDOR]）。已知H的输入，敌方无法区分H的输出和随机数据源。
3. Function H is a one-way function. Given the output of H, it is computationally infeasible for an adversary to determine the input.
3. 函数H是单向函数。给定H的输出，对手确定输入在计算上是不可行的。
4. For any given input to function H, each of the 2^x possible outputs are equally probable.
4. 对于函数H的任何给定输入，每个2^x可能输出的概率相等。
5. The discrete logarithm problem for the chosen group is hard. That is, given g, p, and y = g^x mod p, it is computationally infeasible to determine x. Similarly, for an ECC group given the curve definition, a generator G, and Y = x * G, it is computationally infeasible to determine x.
5. 所选组的离散对数问题很难解决。也就是说，给定g，p和y=g^x mod p，计算上不可能确定x。类似地，对于给定曲线定义的ECC组、生成器G和Y=x*G，确定x在计算上是不可行的。
6. There exists a pool of passwords from which the password shared by the peer and server is drawn. This pool can consist of words from a dictionary, for example. Each password in this pool has an equal probability of being the shared password. All potential attackers have access to this pool of passwords.
6. 存在一个密码池，从中提取对等方和服务器共享的密码。例如，此池可以由字典中的单词组成。此池中的每个密码成为共享密码的概率相等。所有潜在攻击者都可以访问此密码池。
The protocol described in this memo uses a random function, H. As noted in Section 2.3, this is a "random oracle" as defined in [RANDOR]. At first glance, one may view this as a hash function. As noted in [RANDOR], though, hash functions are too structured to be used directly as a random oracle. But they can be used to instantiate the random oracle.
本备忘录中描述的协议使用随机函数H。如第2.3节所述，这是[RANDOR]中定义的“随机预言”。乍一看，人们可能认为这是一个散列函数。不过，正如[RANDOR]中所指出的，哈希函数的结构过于结构化，无法直接用作随机预言。但它们可以用来实例化随机预言。
The random function, H, in this memo is instantiated by HMAC-SHA256 (see [RFC4634]) with a key whose length is 32 octets and whose value is zero. In other words,
本备忘录中的随机函数H由HMAC-SHA256（参见[RFC4634]）实例化，其密钥长度为32个八位字节，值为零。换句话说,，
H(x) = HMAC-SHA-256([0]32, x)
H(x) = HMAC-SHA-256([0]32, x)
The keys output by this protocol, MSK and EMSK, are each 512 bits in length. The shared secret that results from the successful termination of this protocol is only 256 bits. Therefore, it is necessary to stretch the shared secret using a key derivation function (KDF).
该协议输出的密钥MSK和EMSK的长度均为512位。成功终止此协议所产生的共享秘密仅为256位。因此，有必要使用密钥派生函数（KDF）来扩展共享密钥。
The KDF used in this protocol has a counter-mode with feedback construction using a generic pseudo-random function (PRF), according to [SP800-108]. The specific value of the PRF is specified along with the random function and group when the server sends the first EAP-pwd packet to the peer.
根据[SP800-108]，本协议中使用的KDF具有使用通用伪随机函数（PRF）的反馈构造的计数器模式。当服务器向对等方发送第一个EAP pwd数据包时，指定PRF的特定值以及随机函数和组。
The KDF takes a key to stretch, a label to bind into the key, and an indication of the desired length of the output in bits. It uses two internal variables, i and L, each of which is 16 bits in length and is represented in network order. Algorithmically, it is:
KDF使用一个键进行拉伸，一个标签绑定到键中，并以位表示所需的输出长度。它使用两个内部变量i和L，每个变量的长度为16位，并以网络顺序表示。在算法上，它是：
KDF(key, label, length) {
i = 1
L = length
K(1) = PRF(key, i | label | L)
res = K(1)
while (len(res) < length)
do
i = i + 1
K(i) = PRF(key, K(i-1) | i | label | L)
res = res | K(i)
done
return chop(res, length)
}
KDF(key, label, length) {
i = 1
L = length
K(1) = PRF(key, i | label | L)
res = K(1)
while (len(res) < length)
do
i = i + 1
K(i) = PRF(key, K(i-1) | i | label | L)
res = res | K(i)
done
return chop(res, length)
}
Figure 1: Key Derivation Function
图1：键派生函数
The security of EAP-pwd relies upon each side, the peer and server, producing quality secret random numbers. A poor random number chosen by either side in a single exchange can compromise the shared secret from that exchange and open up the possibility of dictionary attack.
EAP pwd的安全性依赖于每一方、对等方和服务器，产生高质量的秘密随机数。在一次交换中，任何一方选择的一个糟糕的随机数都可能破坏该交换的共享秘密，并可能导致字典攻击。
Producing quality random numbers without specialized hardware entails using a cryptographic mixing function (like a strong hash function) to distill entropy from multiple, uncorrelated sources of information and events. A very good discussion of this can be found in [RFC4086].
在没有专用硬件的情况下生成高质量随机数需要使用加密混合函数（如强哈希函数）从多个不相关的信息和事件源中提取熵。[RFC4086]中对这一点进行了很好的讨论。
The strings representing the server identity and peer identity MUST follow the requirements of [RFC4282] for Network Access Identifiers. This ensures a canonical representation of identities by both ends of the conversation prior to their use in EAP-pwd.
表示服务器标识和对等标识的字符串必须符合[RFC4282]对网络访问标识符的要求。这确保了在EAP pwd中使用身份之前，对话的两端都能对身份进行规范化表示。
EAP-pwd requires passwords be input as binary strings. For the protocol to successfully terminate, each side must produce identical binary strings from the password. This imposes processing requirements on a password prior to its use.
EAP pwd要求密码作为二进制字符串输入。为了使协议成功终止，每一方都必须从密码中产生相同的二进制字符串。这对密码在使用前提出了处理要求。
Three techniques for password pre-processing exist for EAP-pwd:
EAP pwd有三种密码预处理技术：
o None: The input password string SHALL be treated as an ASCII string or a hexadecimal string with no treatment or normalization performed. The output SHALL be the binary representation of the input string.
o 无：输入密码字符串应视为ASCII字符串或十六进制字符串，不进行任何处理或规范化。输出应为输入字符串的二进制表示。
o RFC 2759: The input password string SHALL be processed to produce the output PasswordHashHash, as defined in [RFC2759], including any approved errata to [RFC2759]. This technique is useful when the server does not have access to the plaintext password.
o RFC 2759：应处理输入密码字符串，以产生[RFC2759]中定义的输出密码哈希，包括[RFC2759]中任何批准的勘误表。当服务器无法访问明文密码时，此技术非常有用。
o SASLprep: The input password string is processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHALL be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output SHALL be the binary representation of the processed UTF-8 character string. Prohibited output and unassigned codepoints encountered in SASLprep pre-processing SHALL cause a failure of pre-processing, and the output SHALL NOT be used with EAP-pwd.
o SASLprep：根据[RFC3454]的[RFC4013]配置文件的规则处理输入密码字符串。根据[RFC3454]，密码应视为“存储字符串”，因此禁止未分配的代码点。输出应为已处理UTF-8字符串的二进制表示。SASLprep预处理中遇到的禁止输出和未分配代码点应导致预处理失败，且输出不得与EAP pwd一起使用。
Changing a password is out of scope of EAP-pwd, but due to the ambiguities in the way internationalized character strings are handled, 1) it SHOULD be done using SASLprep to ensure a canonical representation of the new password is stored on the server, and 2) subsequent invocations of EAP-pwd SHOULD use SASLprep to ensure that the client generates an identical binary string from the input password.
更改密码超出EAP pwd的范围，但由于处理国际化字符串的方式存在歧义，1）应使用SASLprep进行更改，以确保新密码的规范表示形式存储在服务器上，2）EAP pwd的后续调用应使用SASLprep确保客户端从输入密码生成相同的二进制字符串。
EAP is a two-party protocol spoken between an EAP peer and an authenticator. For scaling purposes, the functionality of the authenticator that speaks EAP is frequently broken out into a stand-alone EAP server. In this case, the EAP peer communicates with an EAP server through the authenticator, with the authenticator merely being a passthrough.
EAP是EAP对等方和认证方之间的一种双方协议。出于扩展目的，讲EAP的验证器的功能经常被分解成一个独立的EAP服务器。在这种情况下，EAP对等方通过验证器与EAP服务器通信，验证器只是一个直通。
An EAP method defines the specific authentication protocol being used by EAP. This memo defines a particular method and therefore defines the messages sent between the EAP server (or the "EAP server" functionality in an authenticator if it is not broken out) and the EAP peer for the purposes of authentication and key derivation.
EAP方法定义EAP使用的特定身份验证协议。本备忘录定义了一种特定的方法，因此定义了EAP服务器（或身份验证程序中的“EAP服务器”功能，如果未断开）与EAP对等方之间发送的消息，以进行身份验证和密钥派生。
EAP-pwd defines three message exchanges: an Identity exchange, a Commit exchange, and a Confirm exchange. A successful authentication is shown in Figure 2.
EAP pwd定义了三种消息交换：身份交换、提交交换和确认交换。成功的身份验证如图2所示。
The peer and server use the Identity exchange to discover each other's identities and to agree upon a Ciphersuite to use in the subsequent exchanges; in addition, the EAP Server uses the EAP-pwd-ID/Request message to inform the client of any password pre-processing that may be required. In the Commit exchange, the peer and server exchange information to generate a shared key and also to bind each other to a particular guess of the password. In the Confirm exchange, the peer and server prove liveness and knowledge of the password by generating and verifying verification data.
对等方和服务器使用身份交换来发现彼此的身份，并商定在后续交换中使用的密码套件；此外，EAP服务器使用EAP pwd ID/请求消息通知客户端可能需要的任何密码预处理。在提交交换中，对等方和服务器交换信息以生成共享密钥，并将彼此绑定到对密码的特定猜测。在确认交换中，对等方和服务器通过生成和验证验证数据来证明密码的活性和知识。
+--------+ +--------+
| | EAP-pwd-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-pwd-ID/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | EAP-pwd-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-pwd-ID/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Figure 2: A Successful EAP-pwd Exchange
图2：成功的EAP pwd交换
The components of the EAP-pwd-* messages are as follows:
EAP pwd-*消息的组成如下：
EAP-pwd-ID/Request Ciphersuite, Token, Password Processing Method, Server_ID
EAP pwd ID/请求密码套件、令牌、密码处理方法、服务器ID
EAP-pwd-ID/Response Ciphersuite, Token, Password Processing Method, Peer_ID
EAP pwd ID/响应密码套件、令牌、密码处理方法、对等ID
EAP-pwd-Commit/Request Scalar_S, Element_S
EAP pwd提交/请求标量、元素
EAP-pwd-Commit/Response Scalar_P, Element_P
EAP pwd提交/响应标量，元素
EAP-pwd-Confirm/Request Confirm_S
EAP pwd确认/请求确认
EAP-pwd-Confirm/Response Confirm_P
EAP pwd确认/响应确认\u P
Once the EAP-pwd-ID exchange is completed, the peer and server use each other's identities and the agreed upon ciphersuite to fix an element in the negotiated group called the Password Element (PWE or pwe, for an element in an ECC group or an FFC group, respectively). The resulting element must be selected in a deterministic fashion using the password but must result in selection of an element that will not leak any information about the password to an attacker. From the point of view of an attacker who does not know the password, the Password Element will be a random element in the negotiated group.
一旦EAP pwd ID交换完成，对等方和服务器使用彼此的身份和约定的密码套件来修复协商组中称为密码元素的元素（分别用于ECC组或FFC组中的元素的PWE或PWE）。必须使用密码以确定的方式选择结果元素，但必须选择不会向攻击者泄露任何密码信息的元素。从不知道密码的攻击者的角度来看，密码元素将是协商组中的随机元素。
To properly fix the Password Element, both parties must have a common view of the string "password". Therefore, if a password pre-processing algorithm was negotiated during the EAP-pwd-ID exchange, the client MUST perform the specified password pre-processing prior to fixing the Password Element.
要正确修复Password元素，双方必须对字符串“Password”有一个共同的视图。因此，如果在EAP pwd ID交换期间协商了密码预处理算法，则客户端必须在修复密码元素之前执行指定的密码预处理。
Fixing the Password Element involves an iterative hunting-and-pecking technique using the prime from the negotiated group's domain parameter set and an ECC- or FFC-specific operation depending on the negotiated group.
修复密码元素涉及使用协商组域参数集中的素数的迭代搜索和啄食技术，以及取决于协商组的ECC或FFC特定操作。
First, an 8-bit counter is set to the value one (1). Then, the agreed-upon random function is used to generate a password seed from the identities and the anti-clogging token from the EAP-pwd-ID exchange (see Section 2.8.5.1):
首先，将8位计数器设置为值1（1）。然后，使用商定的随机函数从身份和EAP pwd ID交换的防阻塞令牌生成密码种子（见第2.8.5.1节）：
pwd-seed = H(token | peer-ID | server-ID | password | counter)
pwd seed=H（令牌|对等ID |服务器ID |密码|计数器）
Then, the pwd-seed is expanded using the KDF from the agreed-upon Ciphersuite out to the length of the prime:
然后，使用KDF将pwd种子从约定的密码套件扩展到素数长度：
pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
If the pwd-value is greater than or equal to the prime, p, the counter is incremented, and a new pwd-seed is generated and the hunting-and-pecking continues. If pwd-value is less than the prime, p, it is passed to the group-specific operation which either returns the selected Password Element or fails. If the group-specific operation fails, the counter is incremented, a new pwd-seed is generated, and the hunting-and-pecking continues. This process continues until the group-specific operation returns the Password Element.
如果pwd值大于或等于素数p，则计数器递增，并生成新的pwd种子，狩猎和啄食继续。如果pwd值小于prime，p，则将其传递给特定于组的操作，该操作返回所选密码元素或失败。如果特定于组的操作失败，计数器将递增，生成新的pwd种子，狩猎和啄食将继续。此过程将继续，直到特定于组的操作返回Password元素。
The group-specific operation for ECC groups uses pwd-value, pwd-seed, and the equation for the curve to produce the Password Element. First, pwd-value is used directly as the x-coordinate, x, with the equation for the elliptic curve, with parameters a and b from the domain parameter set of the curve, to solve for a y-coordinate, y. If there is no solution to the quadratic equation, this operation fails and the hunting-and-pecking process continues. If a solution is found, then an ambiguity exists as there are technically two solutions to the equation and pwd-seed is used to unambiguously select one of them. If the low-order bit of pwd-seed is equal to the low-order bit of y, then a candidate PWE is defined as the point (x, y); if the low-order bit of pwd-seed differs from the low-order bit of y, then a candidate PWE is defined as the point (x, p - y), where p is the prime over which the curve is defined. The candidate PWE becomes PWE, and the hunting and pecking terminates successfully.
ECC组的组特定操作使用pwd值、pwd种子和曲线方程生成密码元素。首先，pwd值直接用作x坐标x，椭圆曲线方程，参数a和b来自曲线的域参数集，用于求解y坐标y。如果二次方程没有解，该操作将失败，狩猎和啄食过程将继续。如果找到一个解决方案，则存在歧义，因为从技术上讲，方程有两个解决方案，并且使用pwd seed明确地选择其中一个。如果pwd种子的低阶位等于y的低阶位，则候选PWE被定义为点（x，y）；如果pwd seed的低阶位与y的低阶位不同，则候选PWE被定义为点（x，p-y），其中p是定义曲线的素数。候选者PWE变成PWE，狩猎和啄食成功终止。
Algorithmically, the process looks like this:
从算法上看，该过程如下所示：
found = 0
counter = 1
do {
pwd-seed = H(token | peer-ID | server-ID | password | counter)
pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
if (pwd-value < p)
then
x = pwd-value
if ( (y = sqrt(x^3 + ax + b)) != FAIL)
then
if (LSB(y) == LSB(pwd-seed))
then
PWE = (x, y)
else
PWE = (x, p-y)
fi
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
found = 0
counter = 1
do {
pwd-seed = H(token | peer-ID | server-ID | password | counter)
pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
if (pwd-value < p)
then
x = pwd-value
if ( (y = sqrt(x^3 + ax + b)) != FAIL)
then
if (LSB(y) == LSB(pwd-seed))
then
PWE = (x, y)
else
PWE = (x, p-y)
fi
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
Figure 3: Fixing PWE for ECC Groups
图3：固定ECC组的PWE
The group-specific operation for FFC groups takes pwd-value, and the prime, p, and order, r, from the group's domain parameter set (see Section 2.2.1 when the order is not part of the defined domain parameter set) to directly produce a candidate Password Element, pwe, by exponentiating the pwd-value to the value ((p-1)/r) modulo the prime. If the result is greater than one (1), the candidate pwe becomes pwe, and the hunting and pecking terminates successfully.
FFC组的特定于组的操作从组的域参数集中获取pwd值、素数p和顺序r（当顺序不是定义的域参数集的一部分时，请参见第2.2.1节），通过将pwd值乘以素数的值（（p-1）/r），直接生成候选密码元素pwe。如果结果大于一（1），候选pwe变为pwe，狩猎和啄食成功终止。
Algorithmically, the process looks like this:
从算法上看，该过程如下所示：
found = 0
counter = 1
do {
pwd-seed = H(token | peer-ID | server-ID | password | counter)
pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
if (pwd-value < p)
then
pwe = pwd-value ^ ((p-1)/r) mod p
if (pwe > 1)
then
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
found = 0
counter = 1
do {
pwd-seed = H(token | peer-ID | server-ID | password | counter)
pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
if (pwd-value < p)
then
pwe = pwd-value ^ ((p-1)/r) mod p
if (pwe > 1)
then
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
Figure 4: Fixing PWE for FFC Groups
图4：固定FFC组的PWE
After the EAP-pwd Identity exchange, the construction of the components of subsequent messages depends on the type of group from the ciphersuite (ECC or FFC). This section provides an overview of the authenticated key exchange. For a complete description of message generation and processing, see Sections 2.8.5.2 and 2.8.5.3.
EAP pwd身份交换后，后续消息组件的构造取决于密码套件（ECC或FFC）中的组类型。本节概述了经过身份验证的密钥交换。有关消息生成和处理的完整说明，请参见第2.8.5.2节和第2.8.5.3节。
Using the mapping function F() defined in Section 2.2.2 and the group order r:
使用第2.2.2节中定义的映射函数F（）和组顺序r：
Server: EAP-pwd-Commit/Request
- choose two random numbers, 1 < s_rand, s_mask < r
- compute Scalar_S = (s_rand + s_mask) mod r
- compute Element_S = inv(s_mask * PWE)
Server: EAP-pwd-Commit/Request
- choose two random numbers, 1 < s_rand, s_mask < r
- compute Scalar_S = (s_rand + s_mask) mod r
- compute Element_S = inv(s_mask * PWE)
Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request
元素和标量用于构造EAP pwd提交/请求
Peer: EAP-pwd-Commit/Response
- choose two random numbers, 1 < p_rand, p_mask < r
- compute Scalar_P = (p_rand + p_mask) mod r
- compute Element_P = inv(p_mask * PWE)
Peer: EAP-pwd-Commit/Response
- choose two random numbers, 1 < p_rand, p_mask < r
- compute Scalar_P = (p_rand + p_mask) mod r
- compute Element_P = inv(p_mask * PWE)
Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response
元素和标量用于构造EAP pwd提交/响应
Server: EAP-pwd-Confirm/Request
- compute KS = (s_rand * (Scalar_P * PWE + Element_P))
- compute ks = F(KS)
- compute Confirm_S = H(ks | Element_S | Scalar_S |
Element_P | Scalar_P | Ciphersuite)
Server: EAP-pwd-Confirm/Request
- compute KS = (s_rand * (Scalar_P * PWE + Element_P))
- compute ks = F(KS)
- compute Confirm_S = H(ks | Element_S | Scalar_S |
Element_P | Scalar_P | Ciphersuite)
Confirm_S is used to construct EAP-pwd-Confirm/Request
确认_S用于构造EAP pwd确认/请求
Peer: EAP-pwd-Confirm/Response
- compute KP = (p_rand * (Scalar_S * PWE + Element_S)),
- compute kp = F(KP)
- compute Confirm_P = H(kp | Element_P | Scalar_P |
Element_S | Scalar_S | Ciphersuite)
Peer: EAP-pwd-Confirm/Response
- compute KP = (p_rand * (Scalar_S * PWE + Element_S)),
- compute kp = F(KP)
- compute Confirm_P = H(kp | Element_P | Scalar_P |
Element_S | Scalar_S | Ciphersuite)
Confirm_P is used to construct EAP-pwd-Confirm/Response
确认P用于构造EAP pwd确认/响应
The EAP Server computes the shared secret as: MK = H(ks | Confirm_P | Confirm_S)
EAP服务器将共享秘密计算为：MK=H（ks | Confirm|u P | Confirm|u S）
The EAP Peer computes the shared secret as: MK = H(kp | Confirm_P | Confirm_S)
EAP对等方将共享秘密计算为：MK=H（kp | Confirm|u P | Confirm|u S）
The MSK and EMSK are derived from MK per Section 2.9.
根据第2.9节，MSK和EMSK源自MK。
There is no mapping function, F(), required for an FFC group. Using the order, r, for the group (see Section 2.2.1 when the order is not part of the defined domain parameters):
FFC组不需要映射函数F（）。使用组的顺序r（当顺序不是定义域参数的一部分时，请参见第2.2.1节）：
Server: EAP-pwd-Commit/Request
- choose two random numbers, 1 < s_rand, s_mask < r
- compute Scalar_S = (s_rand + s_mask) mod r
- compute Element_S = inv(pwe^s_mask mod p)
Server: EAP-pwd-Commit/Request
- choose two random numbers, 1 < s_rand, s_mask < r
- compute Scalar_S = (s_rand + s_mask) mod r
- compute Element_S = inv(pwe^s_mask mod p)
Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request
元素和标量用于构造EAP pwd提交/请求
Peer: EAP-pwd-Commit/Response
- choose random two numbers, 1 < p_rand, p_mask < r
- compute Scalar_P = (p_rand + p_mask) mod r
- compute Element_P = inv(pwe^p_mask mod p)
Peer: EAP-pwd-Commit/Response
- choose random two numbers, 1 < p_rand, p_mask < r
- compute Scalar_P = (p_rand + p_mask) mod r
- compute Element_P = inv(pwe^p_mask mod p)
Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response
元素和标量用于构造EAP pwd提交/响应
Server: EAP-pwd-Confirm/Request
- compute ks = ((pwe^Scalar_P mod p) * Element_P)^s_rand mod p
- compute Confirm_S = H(ks | Element_S | Scalar_S |
Element_P | Scalar_P | Ciphersuite)
Server: EAP-pwd-Confirm/Request
- compute ks = ((pwe^Scalar_P mod p) * Element_P)^s_rand mod p
- compute Confirm_S = H(ks | Element_S | Scalar_S |
Element_P | Scalar_P | Ciphersuite)
Confirm_S is used to construct EAP-pwd-Confirm/Request
确认_S用于构造EAP pwd确认/请求
Peer: EAP-pwd-Confirm/Response
- compute kp = ((pwe^Scalar_S mod p) * Element_S)^p_rand mod p
- compute Confirm_P = H(kp | Element_P | Scalar_P |
Element_S | Scalar_S | Ciphersuite)
Peer: EAP-pwd-Confirm/Response
- compute kp = ((pwe^Scalar_S mod p) * Element_S)^p_rand mod p
- compute Confirm_P = H(kp | Element_P | Scalar_P |
Element_S | Scalar_S | Ciphersuite)
Confirm_P is used to construct EAP-pwd-Confirm/Request
确认P用于构造EAP pwd确认/请求
The EAP Server computes the shared secret as: MK = H(ks | Confirm_P | Confirm_S)
EAP服务器将共享秘密计算为：MK=H（ks | Confirm|u P | Confirm|u S）
The EAP Peer computes the shared secret as: MK = H(kp | Confirm_P | Confirm_S)
EAP对等方将共享秘密计算为：MK=H（kp | Confirm|u P | Confirm|u S）
The MSK and EMSK are derived from MK per Section 2.9.
根据第2.9节，MSK和EMSK源自MK。
Although EAP provides an Identity method to determine the identity of the peer, the value in the Identity Response may have been truncated or obfuscated to provide privacy or decorated for routing purposes [RFC3748], making it inappropriate for usage by the EAP-pwd method. Therefore, the EAP-pwd-ID exchange is defined for the purpose of exchanging identities between the peer and server.
尽管EAP提供了一种标识方法来确定对等方的标识，但标识响应中的值可能已被截断或模糊，以提供隐私或出于路由目的进行修饰[RFC3748]，因此不适合EAP pwd方法使用。因此，EAP pwd ID交换是为了在对等方和服务器之间交换身份而定义的。
The EAP-pwd-ID/Request contains the following quantities:
EAP pwd ID/请求包含以下数量：
o a ciphersuite
o 密码套件
o a representation of the server's identity per Section 2.7.1
o 根据第2.7.1节，服务器标识的表示
o an anti-clogging token
o 防堵塞令牌
o a password pre-processing method
o 一种密码预处理方法
The ciphersuite specifies the finite cyclic group, random function, and PRF selected by the server for use in the subsequent authentication exchange.
密码套件指定服务器选择用于后续身份验证交换的有限循环组、随机函数和PRF。
The value of the anti-clogging token MUST be unpredictable and SHOULD NOT be from a source of random entropy. The purpose of the anti-clogging token is to provide the server an assurance that the peer constructing the EAP-pwd-ID/Response is genuine and not part of a flooding attack.
防堵塞令牌的值必须是不可预测的，并且不应来自随机熵源。防阻塞令牌的目的是向服务器提供一种保证，即构造EAP pwd ID/响应的对等方是真实的，而不是泛洪攻击的一部分。
A password pre-processing method is communicated to ensure interoperability by producing a canonical representation of the password string between the peer and server (see Section 2.7.2).
通过在对等方和服务器之间生成密码字符串的规范表示，传递密码预处理方法以确保互操作性（参见第2.7.2节）。
The EAP-pwd-ID/Request is constructed according to Section 3.2.1 and is transmitted to the peer.
EAP pwd ID/请求根据第3.2.1节构造，并传输给对等方。
Upon receipt of an EAP-pwd-ID/Request, the peer determines whether the ciphersuite and pre-processing method are acceptable. If not, the peer MUST respond with an EAP-NAK. If acceptable, the peer responds to the EAP-pwd-ID/Request with an EAP-pwd-ID/Response, constructed according to Section 3.2.1, that acknowledges the Ciphersuite, token, and pre-processing method and then adds its identity. After sending the EAP-pwd-ID/Response, the peer has the identity of the server (from the Request), its own identity (it encoded in the Response), a password pre-processing algorithm, and it can compute the Password Element as specified in Section 2.8.3. The Password Element is stored in state allocated for this exchange.
在收到EAP pwd ID/请求后，对等方确定密码套件和预处理方法是否可接受。否则，对等方必须使用EAP-NAK进行响应。如果可以接受，对等方使用根据第3.2.1节构造的EAP pwd ID/响应响应EAP pwd ID/请求，该响应确认密码套件、令牌和预处理方法，然后添加其标识。发送EAP pwd ID/响应后，对等方拥有服务器的身份（来自请求）、自己的身份（在响应中编码）、密码预处理算法，并且可以按照第2.8.3节的规定计算密码元素。密码元素存储在为此交换分配的状态中。
The EAP-pwd-ID/Response acknowledges the Ciphersuite from the Request, acknowledges the anti-clogging token from the Request providing a demonstration of "liveness" on the part of the peer, and contains the identity of the peer. Upon receipt of the Response, the server verifies that the Ciphersuite acknowledged by the peer is the same as that sent in the Request and that the anti-clogging token added by the peer in the Response is the same as that sent in the Request. If Ciphersuites or anti-clogging tokens differ, the server MUST respond with an EAP-Failure message. If the anti-clogging tokens are the same, the server knows the peer is an active participant in the exchange. If the Ciphersuites are the same, the server now knows its own identity (it encoded in the Request) and the peer's identity (from the Response) and can compute the Password
EAP pwd ID/响应确认请求中的密码套件，确认请求中提供对等方“活跃性”证明的防阻塞令牌，并包含对等方的标识。收到响应后，服务器将验证对等方确认的密码套件是否与请求中发送的密码套件相同，以及对等方在响应中添加的防阻塞令牌是否与请求中发送的密码套件相同。如果密码套件或防阻塞令牌不同，服务器必须以EAP故障消息响应。如果防阻塞令牌相同，则服务器知道对等方是exchange中的活动参与者。如果密码套件相同，服务器现在知道自己的身份（在请求中编码）和对等方的身份（从响应中），并可以计算密码
Element according to Section 2.8.3. The server stores the Password Element in state it has allocated for this exchange. The server then initiates an EAP-pwd-Commit exchange.
第2.8.3节规定的元件。服务器将Password元素存储为它为此exchange分配的状态。然后，服务器启动EAP pwd提交交换。
The server begins the EAP-pwd-Confirm exchange by choosing two random numbers, s_rand and s_mask, between 1 and r (where r is described in Section 2.1 according to the group established in Section 2.8.5.1) such that their sum modulo r is greater than one (1). It then computes Element_S and Scalar_S as defined in Section 2.8.4 and constructs an EAP-pwd-Commit/Request according to Section 3.2.2. Element_S and Scalar_S are added to the state allocated for this exchange, and the EAP-pwd-Commit/Request is transmitted to the peer.
服务器通过选择1和r之间的两个随机数s_rand和s_mask（其中r根据第2.8.5.1节中建立的组在第2.1节中进行了描述）开始EAP pwd确认交换，以使其和模r大于一（1）。然后，它计算第2.8.4节中定义的元素和标量，并根据第3.2.2节构造EAP pwd提交/请求。元素和标量被添加到为此交换分配的状态中，EAP pwd提交/请求被传输到对等方。
Upon receipt of the EAP-pwd-Commit/Request, the peer validates the length of the entire payload based upon the expected lengths of Element_S and Scalar_S (which are fixed according to the length of the agreed-upon group). If the length is incorrect, the peer MUST terminate the exchange. If the length is correct, Element_S and Scalar_S are extracted from the EAP-pwd-Commit/Request. Scalar_S is then checked to ensure it is between 1 and r, exclusive. If it is not, the peer MUST terminate the exchange. If it is, Element_S MUST be validated depending on the type of group -- Element validation for FFC groups is described in Section 2.8.5.2.1, and Element validation for ECC groups is described in Section 2.8.5.2.2. If validation is successful, the peer chooses two random numbers, p_rand and p_mask, between 1 and r (where r is described in Section 2.1 according to the group established in Section 2.8.5.1) such that their sum modulo r is greater than one (1), and computes Element_P and Scalar_P. Next, the peer computes kp from p_rand, Element_S, Scalar_S, and the Password Element according to Section 2.8.4. If kp is the "identity element" -- the point at infinity for an ECC group or the value one (1) for an FFC group -- the peer MUST terminate the exchange. If not, the peer uses Element_P and Scalar_P to construct an EAP-pwd-Commit/Response according to Section 3.2.2 and transmits the EAP-pwd-Commit/Response to the server.
在收到EAP pwd提交/请求后，对等方根据元素和标量的预期长度（根据商定组的长度固定）验证整个有效负载的长度。如果长度不正确，对等方必须终止交换。如果长度正确，则从EAP pwd提交/请求中提取元素和标量。然后检查标量_S，以确保其介于1和r之间，互斥。如果不是，对等方必须终止交换。如果是，则必须根据组的类型对元素进行验证——第2.8.5.2.1节描述了FFC组的元素验证，第2.8.5.2.2节描述了ECC组的元素验证。如果验证成功，对等方选择1和r之间的两个随机数p_rand和p_mask（其中r根据第2.8.5.1节中建立的组在第2.1节中进行了描述），以使其模和r大于一（1），并计算元素p和标量p。接下来，对等方根据p_rand、元素S、标量S计算kp，以及第2.8.4节规定的密码元素。如果kp是“标识元素”——ECC组的无穷大点或FFC组的值一（1）——则对等方必须终止交换。如果没有，则对等方根据第3.2.2节使用元素和标量来构造EAP pwd提交/响应，并将EAP pwd提交/响应传输给服务器。
Upon receipt of the EAP-pwd-Commit/Response, the server validates the length of the entire payload based upon the expected lengths of Element_P and Scalar_P (which are fixed according to the agreed-upon group). If the length is incorrect, the server MUST respond with an EAP-Failure message, and it MUST terminate the exchange and free up any state allocated. If the length is correct, Scalar_P and Element_P are extracted from the EAP-pwd-Commit/Response and compared to Scalar_S and Element_S. If Scalar_P equals Scalar_S and Element_P equals Element_S, it indicates a reflection attack and the server MUST respond with an EAP-failure and terminate the exchange. If they
在收到EAP pwd提交/响应后，服务器根据元素和标量的预期长度（根据商定的组固定）验证整个有效负载的长度。如果长度不正确，服务器必须响应EAP失败消息，并且必须终止交换并释放任何分配的状态。如果长度正确，则从EAP pwd提交/响应中提取Scalar_P和Element_P，并与Scalar_S和Element_S进行比较。如果Scalar_P等于Scalar_S，Element_P等于Element_S，则表示存在反射攻击，服务器必须以EAP故障进行响应并终止交换。如果他们
differ, Scalar_P is checked to ensure it is between 1 and r, exclusive. If not the server MUST respond with an EAP-failure and terminate the exchange. If it is, Element_P is verified depending on the type of group -- Element validation for FFC groups is described in Section 2.8.5.2.1, and Element validation for ECC groups is described in Section 2.8.5.2.2. If validation is successful, the server computes ks from s_rand, Element_P, Scalar_P, and the Password Element according to Section 2.8.4. If ks is the "identity element" -- the point at infinity for an ECC group or the value one (1) for an FFC group -- the server MUST respond with an EAP-failure and terminate the exchange. Otherwise, the server initiates an EAP-pwd-Confirm exchange.
不同的是，将检查标量_P以确保其介于1和r之间，互斥。如果没有，服务器必须响应EAP故障并终止交换。如果是，则根据组类型验证元素P——第2.8.5.2.1节描述了FFC组的元素验证，第2.8.5.2.2节描述了ECC组的元素验证。如果验证成功，服务器根据第2.8.4节从s_rand、Element_P、Scalar_P和Password元素计算ks。如果ks是“标识元素”——ECC组的无穷大点或FFC组的值1——服务器必须响应EAP故障并终止交换。否则，服务器将启动EAP pwd确认交换。
A received FFC Element is valid if: 1) it is between one (1) and the prime, p, exclusive; and 2) if modular exponentiation of the Element by the group order, r, equals one (1). If either of these conditions are not true the received Element is invalid.
接收到的FFC元素在以下情况下有效：1）它介于一（1）和素数p互斥之间；2）如果元素按组阶r的模幂等于一（1）。如果这些条件中的任何一个不正确，则接收的元素无效。
Validating a received ECC Element involves: 1) checking whether the two coordinates, x and y, are both greater than zero (0) and less than the prime defining the underlying field; and 2) checking whether the x- and y-coordinates satisfy the equation of the curve (that is, that they produce a valid point on the curve that is not the point at infinity). If either of these conditions are not met, the received Element is invalid; otherwise, the Element is valid.
验证接收到的ECC元素包括：1）检查两个坐标x和y是否都大于零（0）且小于定义基础字段的素数；2）检查x坐标和y坐标是否满足曲线方程（即，它们在曲线上生成的有效点不是无穷远处的点）。如果不满足上述任一条件，则接收的元素无效；否则，元素是有效的。
The server computes Confirm_S according to Section 2.8.4, constructs an EAP-pwd-Confirm/Request according to Section 3.2.3, and sends it to the peer.
服务器根据第2.8.4节计算确认，根据第3.2.3节构造EAP pwd确认/请求，并将其发送给对等方。
Upon receipt of an EAP-pwd-Confirm/Request, the peer validates the length of the entire payload based upon the expected length of Confirm_S (whose length is fixed by the agreed-upon random function). If the length is incorrect, the peer MUST terminate the exchange and free up any state allocated. If the length is correct, the peer verifies that Confirm_S is the value it expects based on the value of kp. If the value of Confirm_S is incorrect, the peer MUST terminate the exchange and free up any state allocated. If the value of Confirm_S is correct, the peer computes Confirm_P, constructs an EAP-pwd-Confirm/Response according to Section 3.2.3, and sends it off to the server. The peer then computes MK (according to Section 2.8.4) and the MSK and EMSK (according to Section 2.9) and stores these keys
在收到EAP pwd确认/请求后，对等方根据确认的预期长度（其长度由商定的随机函数固定）验证整个有效负载的长度。如果长度不正确，对等方必须终止交换并释放任何分配的状态。如果长度正确，对等方将根据kp的值验证Confirm_S是否为其期望的值。如果Confirm_S的值不正确，对等方必须终止交换并释放任何分配的状态。如果Confirm_S的值正确，对等方计算Confirm_P，根据第3.2.3节构造EAP pwd Confirm/Response，并将其发送到服务器。然后，对等方计算MK（根据第2.8.4节）以及MSK和EMSK（根据第2.9节），并存储这些密钥
in state allocated for this exchange. The peer SHOULD export the MSK and EMSK at this time in anticipation of a secure association protocol by the lower layer to create session keys. Alternatively, the peer can wait until an EAP-Success message from the server before exporting the MSK and EMSK.
处于为此交换分配的状态。对等方此时应导出MSK和EMSK，以期望较低层使用安全关联协议来创建会话密钥。或者，对等方可以在导出MSK和EMSK之前等待来自服务器的EAP成功消息。
Upon receipt of an EAP-pwd-Confirm/Response, the server validates the length of the entire payload based upon the expected length of Confirm_P (whose length is fixed by the agreed-upon random function). If the length is incorrect, the server MUST respond with an EAP-Failure message, and it MUST terminate the exchange and free up any state allocated. If the length is correct, the server verifies that Confirm_P is the value it expects based on the value of ks. If the value of Confirm_P is incorrect, the server MUST respond with an EAP-Failure message. If the value of Confirm_P is correct, the server computes MK (according to Section 2.8.4) and the MSK and EMSK (according to Section 2.9). It exports the MSK and EMSK and responds with an EAP-Success message. The server SHOULD free up state allocated for this exchange.
在收到EAP pwd确认/响应后，服务器根据预期的确认长度（其长度由商定的随机函数固定）验证整个有效负载的长度。如果长度不正确，服务器必须响应EAP失败消息，并且必须终止交换并释放任何分配的状态。如果长度正确，服务器将根据ks的值验证Confirm_P是否为它期望的值。如果Confirm_P的值不正确，服务器必须响应EAP故障消息。如果Confirm_P的值正确，服务器将计算MK（根据第2.8.4节）以及MSK和EMSK（根据第2.9节）。它导出MSK和EMSK，并以EAP成功消息进行响应。服务器应释放为此exchange分配的状态。
[RFC5247] recommends each EAP method define how to construct a Method-ID and Session-ID to identify a particular EAP session between a peer and server. This information is constructed thusly:
[RFC5247]建议每个EAP方法定义如何构造方法ID和会话ID，以标识对等方和服务器之间的特定EAP会话。该信息的结构如下：
Method-ID = H(Ciphersuite | Scalar_P | Scalar_S)
方法ID=H（密码套件|标量|标量| P |标量| S）
Session-ID = Type-Code | Method-ID
会话ID=类型代码|方法ID
where Ciphersuite, Scalar_P, and Scalar_S are from the specific exchange being identified; H is the random function specified in the Ciphersuite; and, Type-Code is the code assigned for EAP-pwd, 52, represented as a single octet.
其中，Ciphersuite、Scalar_P和Scalar_S来自被标识的特定交换；H是密码套件中指定的随机函数；并且，类型代码是为EAP pwd 52分配的代码，表示为单个八位字节。
The authenticated key exchange of EAP-pwd generates a shared and authenticated key, MK. The size of MK is dependent on the random function, H, asserted in the Ciphersuite. EAP-pwd must export two 512-bit keys, MSK and EMSK. Regardless of the value of len(MK), implementations MUST invoke the KDF defined in Section 2.5 to construct the MSK and EMSK. The MSK and EMSK are derived thusly:
EAP pwd的认证密钥交换生成共享和认证密钥MK。MK的大小取决于密码套件中断言的随机函数H。EAP pwd必须导出两个512位密钥MSK和EMSK。不管len（MK）的值是多少，实现都必须调用第2.5节中定义的KDF来构造MSK和EMSK。MSK和EMSK由此导出：
MSK | EMSK = KDF(MK, Session-ID, 1024)
MSK | EMSK=KDF（MK，会话ID，1024）
[RFC4962] mentions the importance of naming keys, particularly when key caching is being used. To facilitate such an important optimization, names are assigned thusly:
[RFC4962]提到了命名密钥的重要性，特别是在使用密钥缓存时。为便于进行如此重要的优化，应指定以下名称：
o EMSK-name = Session-ID | 'E' | 'M'| 'S' | 'K'
o EMSK name=Session ID |“E”|“M”|“S”|“K”
o MSK-name = Session-ID | 'M'| 'S' | 'K'
o MSK name=会话ID |“M”|“S”|“K”
where 'E' is a single octet of value 0x45, 'M' is a single octet of value 0x4d, 'S' is a single octet of value 0x53, and 'K' is a single octet of value 0x4b.
其中，“E”是值0x45的单个八位字节，“M”是值0x4d的单个八位字节，“S”是值0x53的单个八位字节，“K”是值0x4b的单个八位字节。
This naming scheme allows for key-management applications to quickly and accurately identify keys for a particular session or all keys of a particular type.
此命名方案允许密钥管理应用程序快速准确地识别特定会话的密钥或特定类型的所有密钥。
For the purposes of interoperability, compliant EAP-pwd implementations SHALL support the following parameters:
为了实现互操作性，符合要求的EAP pwd实施应支持以下参数：
o Diffie-Hellman Group: group 19 defined in [RFC5114]
o Diffie-Hellman组：在[RFC5114]中定义的组19
o Random Function: defined in Section 2.4
o 随机函数：定义见第2.4节
o PRF: HMAC-SHA256 defined in [RFC4634]
o PRF:HMAC-SHA256在[RFC4634]中定义
o Password Pre-Processing: none
o 密码预处理：无
The EAP-pwd header has the following structure:
EAP pwd标头具有以下结构：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |L|M| PWD-Exch | Total-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |L|M| PWD-Exch | Total-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP-pwd Header
图5:EAP pwd头
Code
密码
Either 1 (for Request) or 2 (for Response); see [RFC3748].
1（用于请求）或2（用于响应）；见[RFC3748]。
Identifier
标识符
The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet.
标识符字段是一个八位字节，有助于将响应与请求匹配。必须在每个请求数据包上更改标识符字段。
Length
长
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型和数据字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时必须忽略。
Type
类型
52 - EAP-pwd
52-EAP pwd
L and M bits
L和M位
The L bit (Length included) is set to indicate the presence of the two-octet Total-Length field, and MUST be set for the first fragment of a fragmented EAP-pwd message or set of messages.
L位（包括长度）被设置为指示存在两个八位字节的总长度字段，并且必须为分段EAP pwd消息或消息集的第一个片段设置。
The M bit (more fragments) is set on all but the last fragment.
M位（更多片段）设置在除最后一个片段外的所有片段上。
PWD-Exch
PWD Exch
The PWD-Exch field identifies the type of EAP-pwd payload encapsulated in the Data field. This document defines the following values for the PWD-Exch field:
PWD Exch字段标识封装在数据字段中的EAP PWD有效负载的类型。本文件定义了PWD Exch字段的以下值：
* 0x00 : Reserved
* 0x00：保留
* 0x01 : EAP-pwd-ID exchange
* 0x01:EAP pwd ID交换
* 0x02 : EAP-pwd-Commit exchange
* 0x02:EAP pwd提交交换
* 0x03 : EAP-pwd-Confirm exchange
* 0x03:EAP pwd确认交换
All other values of the PWD-Exch field are unassigned.
PWD Exch字段的所有其他值均未赋值。
Total-Length
全长
The Total-Length field is two octets in length, and is present only if the L bit is set. This field provides the total length of the EAP-pwd message or set of messages that is being fragmented.
“总长度”字段的长度为两个八位字节，仅当设置了L位时才出现。此字段提供正在分段的EAP pwd消息或消息集的总长度。
EAP-pwd payloads all contain the EAP-pwd header and encoded information. Encoded information is comprised of sequences of data. Payloads in the EAP-pwd-ID exchange also include a ciphersuite statement indicating what finite cyclic group to use, what cryptographic primitive to use for H, and what PRF to use for deriving keys.
EAP pwd有效载荷均包含EAP pwd标头和编码信息。编码信息由数据序列组成。EAP pwd ID交换中的有效负载还包括一个ciphersuite语句，指示要使用的有限循环组、用于H的加密原语以及用于派生密钥的PRF。
The Group Description, Random Function, and PRF together, and in that order, comprise the Ciphersuite included in the calculation of the peer's and server's confirm messages.
组描述、随机函数和PRF按顺序一起构成对等方和服务器确认消息计算中包含的密码套件。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Description | Random Func'n | PRF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prep | Identity...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Description | Random Func'n | PRF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prep | Identity...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EAP-pwd-ID Payload
图6:EAP pwd ID有效负载
The Group Description field value is taken from the IANA registry for "Group Description" created by IKE [RFC2409].
组描述字段值取自IKE[RFC2409]创建的“组描述”的IANA注册表。
This document defines the following value for the Random Function field:
本文件定义了随机函数字段的以下值：
o 0x01 : Function defined in this memo in Section 2.4
o 0x01：本备忘录第2.4节中定义的功能
The value 0x00 is reserved for private use between mutually consenting parties. All other values of the Random Function field are unassigned.
值0x00保留给双方同意的各方之间的私人使用。随机函数字段的所有其他值均未赋值。
The PRF field has the following value:
PRF字段具有以下值：
o 0x01 : HMAC-SHA256 [RFC4634]
o 0x01:HMAC-SHA256[RFC4634]
The value 0x00 is reserved for private use between mutually consenting parties. All other values of the PRF field are unassigned.
值0x00保留给双方同意的各方之间的私人使用。PRF字段的所有其他值均未赋值。
The Token field contains an unpredictable value assigned by the server in an EAP-pwd-ID/Request and acknowledged by the peer in an EAP-pwd-ID/Response (see Section 2.8.5).
令牌字段包含由服务器在EAP pwd ID/请求中分配的不可预测值，并由对等方在EAP pwd ID/响应中确认（见第2.8.5节）。
The Prep field represents the password pre-processing technique (see Section 2.7.2) to be used by the client prior to generating the password seed (see Section 2.8.3). This document defines the following values for the Prep field:
Prep字段表示客户端在生成密码种子（见第2.8.3节）之前使用的密码预处理技术（见第2.7.2节）。本文档定义了Prep字段的以下值：
o 0x00 : None
o 0x00：无
o 0x01 : RFC2759
o 0x01:RFC2759
o 0x02 : SASLprep
o 0x02:SASLprep
All other values of the Prep field are unassigned.
Prep字段的所有其他值均未赋值。
The Identity field depends on the tuple of PWD-Exch/Code.
标识字段取决于PWD Exch/Code的元组。
o EAP-pwd-ID/Request : Server_ID
o EAP pwd ID/请求：服务器\u ID
o EAP-pwd-ID/Response : Peer_ID
o EAP pwd ID/响应：对等\u ID
The length of the identity is computed from the Length field in the EAP header.
标识的长度是根据EAP头中的长度字段计算的。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Element ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ Scalar +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Element ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ Scalar +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP-pwd-Commit Payload
图7:EAP pwd提交负载
The Element and Scalar fields depend on the tuple of PWD-Exch/Code.
元素和标量字段取决于PWD Exch/Code的元组。
o EAP-pwd-Commit/Request : Element_S, Scalar_S
o EAP pwd提交/请求：元素、标量
o EAP-pwd-Commit/Response : Element_P, Scalar_P
o EAP pwd提交/响应：元素、标量
The Element is encoded according to Section 3.3. The length of the Element is inferred by the finite cyclic group from the agreed-upon Ciphersuite. The length of the scalar can then be computed from the Length in the EAP header.
根据第3.3节对元素进行编码。元素的长度由有限循环群根据商定的密码套件推断。然后可以根据EAP头中的长度计算标量的长度。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Confirm ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Confirm ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EAP-pwd-Confirm Payload
图8:EAP pwd确认有效载荷
The Confirm field depends on the tuple of PWD-Exch/Code.
确认字段取决于PWD Exch/Code的元组。
o EAP-pwd-Confirm/Request : Confirm_S
o EAP pwd确认/请求：确认
o EAP-pwd-Confirm/Response : Confirm_P
o EAP pwd确认/响应：确认
The length of the Confirm field computed from the Length in the EAP header.
根据EAP标头中的长度计算的确认字段的长度。
Payloads in the EAP-pwd-Commit exchange contain elements from the agreed-upon finite cyclic cryptographic group (either an FCC group or an ECC group). To ensure interoperability, field elements and scalars MUST be represented in payloads in accordance with the requirements described below.
EAP pwd提交交换中的有效负载包含来自商定的有限循环密码组（FCC组或ECC组）的元素。为了确保互操作性，必须按照下面描述的要求在有效负载中表示字段元素和标量。
Elements in an FFC group MUST be represented (in binary form) as unsigned integers that are strictly less than the prime, p, from the group's domain parameter set. The binary representation of each group element MUST have a bit length equal to the bit length of the
FFC组中的元素必须（以二进制形式）表示为无符号整数，严格小于组域参数集中的素数p。每个组元素的二进制表示形式的位长度必须等于
binary representation of p. This length requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
p。如有必要，可通过在整数的二进制表示形式前加零来强制执行此长度要求，直到达到所需的长度。
Elements in an ECC group are points on the agreed-upon elliptic curve. Each such element MUST be represented by the concatenation of two components, an x-coordinate and a y-coordinate.
ECC组中的元素是约定椭圆曲线上的点。每个这样的元素必须由两个组件（x坐标和y坐标）的串联表示。
Each of the two components, the x-coordinate and the y-coordinate, MUST be represented (in binary form) as an unsigned integer that is strictly less than the prime, p, from the group's domain parameter set. The binary representation of each component MUST have a bit length equal to the bit length of the binary representation of p. This length requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
x坐标和y坐标这两个分量中的每一个都必须（以二进制形式）表示为一个无符号整数，严格小于组域参数集中的素数p。每个组件的二进制表示的位长度必须等于p的二进制表示的位长度。如有必要，可通过在整数的二进制表示形式前加零来强制执行此长度要求，直到达到所需的长度。
Since the field element is represented in a payload by the x-coordinate followed by the y-coordinate, it follows that the length of the element in the payload MUST be twice the bit length of p. In other words, "compressed representation" is not used.
由于有效载荷中的字段元素由x坐标和y坐标表示，因此有效载荷中的元素长度必须是p的位长度的两倍。换句话说，不使用“压缩表示”。
Scalars MUST be represented (in binary form) as unsigned integers that are strictly less than r, the order of the generator of the agreed-upon cryptographic group. The binary representation of each scalar MUST have a bit length equal to the bit length of the binary representation of r. This requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
标量必须（以二进制形式）表示为严格小于r的无符号整数，r是约定加密组的生成器的顺序。每个标量的二进制表示的位长度必须等于r的二进制表示的位长度。如有必要，可通过在整数的二进制表示形式前加零来强制执行此要求，直到达到所需的长度。
EAP [RFC3748] is a request-response protocol. The server sends requests and the peer responds. These request and response messages are assumed to be limited to at most 1020 bytes. Messages in EAP-pwd can be larger than 1020 bytes and therefore require support for fragmentation and reassembly.
EAP[RFC3748]是一种请求-响应协议。服务器发送请求，对等方响应。假设这些请求和响应消息最多限制为1020字节。EAP pwd中的消息可能大于1020字节，因此需要支持分段和重新组装。
Implementations MUST establish a fragmentation threshold that indicates the maximum size of an EAP-pwd payload. When an implementation knows the maximum transmission unit (MTU) of its lower layer, it SHOULD calculate the fragmentation threshold from that value. In lieu of knowledge of the lower layer's MTU, the fragmentation threshold MUST be set to 1020 bytes.
实施必须建立一个碎片阈值，该阈值指示EAP pwd负载的最大大小。当实现知道其较低层的最大传输单元（MTU）时，它应该根据该值计算碎片阈值。为了不了解较低层的MTU，必须将碎片阈值设置为1020字节。
Since EAP is a simple ACK-NAK protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field as is provided in IPv4.
由于EAP是一个简单的ACK-NAK协议，因此可以以简单的方式添加碎片支持。在EAP中，在传输过程中丢失或损坏的片段将被重新传输，并且由于序列信息由EAP中的标识符字段提供，因此不需要IPv4中提供的片段偏移字段。
EAP-pwd fragmentation support is provided through the addition of flags within the EAP-Response and EAP-Request packets, as well as a Total-Length field of two octets. Flags include the Length included (L) and More fragments (M) bits. The L flag is set to indicate the presence of the two-octet Total-Length field, and MUST be set for the first fragment of a fragmented EAP-pwd message or set of messages. The M flag is set on all but the last fragment. The Total-Length field is two octets, and provides the total length of the EAP-pwd message or set of messages that is being fragmented; this simplifies buffer allocation.
EAP pwd分段支持通过在EAP响应和EAP请求数据包中添加标志以及两个八位字节的总长度字段来提供。标志包括包含的长度（L）和更多片段（M）位。设置L标志以指示存在两个八位字节的总长度字段，并且必须为分段EAP pwd消息或消息集的第一个片段设置L标志。除最后一个片段外，所有片段都设置了M标志。“总长度”字段为两个八位字节，提供正在分段的EAP pwd消息或消息集的总长度；这简化了缓冲区分配。
When an EAP-pwd peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-pwd and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
当EAP pwd对等方接收到设置了M位的EAP请求数据包时，它必须以EAP Type=EAP pwd且无数据的EAP响应进行响应。这是一个片段。EAP服务器必须等到收到EAP响应后再发送另一个片段。为了防止处理片段时出错，EAP服务器必须增加EAP请求中包含的每个片段的标识符字段，并且对等方必须在EAP响应中包含的片段确认中包含此标识符值。重新传输的片段将包含相同的标识符值。
Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-pwd and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response.
类似地，当EAP服务器接收到设置了M位的EAP响应时，它必须使用EAP Type=EAP pwd且无数据的EAP请求进行响应。这是一个片段。EAP对等方必须等到收到EAP请求后再发送另一个片段。为了防止片段处理中出现错误，EAP服务器必须增加EAP请求中包含的每个片段ACK的标识符值，并且对等方必须在EAP响应中包含的后续片段中包含该标识符值。
This memo contains new numberspaces to be managed by IANA. The policies used to allocate numbers are described in [RFC5226]. IANA has allocated a new EAP method type for EAP-pwd (52).
此备忘录包含IANA管理的新数字空间。[RFC5226]中描述了用于分配号码的策略。IANA已为EAP pwd分配了新的EAP方法类型（52）。
IANA has created new registries for PWD-Exch messages, random functions, PRFs, and password pre-processing methods and has added the message numbers, random function, PRF, and pre-processing methods specified in this memo to those registries, respectively.
IANA已为PWD Exch消息、随机函数、PRF和密码预处理方法创建了新的注册表，并已将本备忘录中指定的消息编号、随机函数、PRF和预处理方法分别添加到这些注册表中。
The following is the initial PWD-Exch message registry layout:
以下是PWD Exch消息注册表的初始布局：
o 0x00 : Reserved
o 0x00：保留
o 0x01 : EAP-pwd-ID exchange
o 0x01:EAP pwd ID交换
o 0x02 : EAP-pwd-Commit exchange
o 0x02:EAP pwd提交交换
o 0x03 : EAP-pwd-Confirm exchange
o 0x03:EAP pwd确认交换
The PWD-Exch field is 6 bits long. The value 0x00 is reserved. All other values are available through assignment by IANA. IANA is instructed to assign values based on "IETF Review" (see [RFC5226]).
PWD Exch字段的长度为6位。值0x00是保留的。所有其他值均可通过IANA分配获得。IANA被指示根据“IETF审查”分配值（见[RFC5226]）。
The following is the initial Random Function registry layout:
以下是初始随机函数注册表布局：
o 0x00 : Private Use
o 0x00：私人使用
o 0x01 : Function defined in this memo, Section 2.4
o 0x01：本备忘录第2.4节中定义的功能
The Random Function field is 8 bits long. The value 0x00 is for Private Use between mutually consenting parties. All other values are available through assignment by IANA. IANA is instructed to assign values based on "Specification Required" (see [RFC5226]). The Designated Expert performing the necessary review MUST ensure the random function has been cryptographically vetted.
随机函数字段的长度为8位。值0x00供双方同意的双方私人使用。所有其他值均可通过IANA分配获得。IANA被指示根据“所需规范”（见[RFC5226]）分配值。执行必要审查的指定专家必须确保随机函数已通过加密审查。
The following is the initial PRF registry layout:
以下是初始PRF注册表布局：
o 0x00 : Private Use
o 0x00：私人使用
o 0x01 : HMAC-SHA256 as defined in [RFC4634]
o 0x01:HMAC-SHA256，定义见[RFC4634]
The PRF field is 8 bits long. The value 0x00 is for Private Use between mutually consenting parties. All other values are available through assignment by IANA. IANA is instructed to assign values based on "IETF Review" (see [RFC5226]).
PRF字段的长度为8位。值0x00供双方同意的双方私人使用。所有其他值均可通过IANA分配获得。IANA被指示根据“IETF审查”分配值（见[RFC5226]）。
The following is the initial layout for the password pre-processing method registry:
以下是密码预处理方法注册表的初始布局：
o 0x00 : None
o 0x00：无
o 0x01 : RFC2759
o 0x01:RFC2759
o 0x02 : SASLprep
o 0x02:SASLprep
The Prep field is 8 bits long, and all other values are available through assignment by IANA. IANA is instructed to assign values based on "Specification Required" (see [RFC5226]).
Prep字段的长度为8位，所有其他值都可以通过IANA赋值获得。IANA被指示根据“所需规范”（见[RFC5226]）分配值。
In Section 1.3, several security properties were presented that motivated the design of this protocol. This section will address how well they are met.
在第1.3节中，介绍了促使本协议设计的几个安全属性。本节将介绍如何很好地满足这些要求。
A passive attacker will see Scalar_P, Element_P, Scalar_S, and Element_S. She can guess at passwords to compute the password element but will not know s_rand or p_rand and therefore will not be able to compute MK.
被动攻击者将看到标量P、元素P、标量S和元素S。她可以猜测密码来计算密码元素，但不知道S_rand或P_rand，因此无法计算MK。
The secret random value of the peer (server) is effectively hidden by adding p_mask (s_mask) to p_rand (s_rand) modulo the order of the group. If the order is "r", then there are approximately "r" distinct pairs of numbers that will sum to the value Scalar_P (Scalar_S). Attempting to guess the particular pair is just as difficult as guessing the secret random value p_rand (s_rand), the probability of a guess is 1/(r - i) after "i" guesses. For a large value of r, this exhaustive search technique is computationally infeasible. An attacker would do better by determining the discrete logarithm of Element_P (Element_S) using an algorithm like the baby-step giant-step algorithm (see [APPCRY]), which runs on the order of the square root of r group operations (e.g., a group with order 2^160 would require 2^80 exponentiations or point multiplications). Based on the assumptions made on the finite cyclic group in Section 2.3, that is also computationally infeasible.
通过将p_掩码（s_掩码）添加到p_rand（s_rand）中，使组的顺序模化，可以有效隐藏对等方（服务器）的秘密随机值。如果顺序为“r”，则大约有“r”个不同的数字对，它们的总和将为标量P（标量S）。尝试猜测特定的配对就像猜测秘密随机值p_rand（s_rand）一样困难，在“i”猜测之后，猜测的概率为1/（r-i）。对于较大的r值，这种穷举搜索技术在计算上是不可行的。攻击者可以通过使用像baby step giant step算法（参见[APPCRY]）这样的算法来确定元素P（元素）的离散对数，该算法按照r组运算的平方根顺序运行（例如，2^160阶的组需要2^80次幂运算或点乘法），从而做得更好。基于第2.3节中对有限循环群的假设，这在计算上也是不可行的。
An active attacker can launch her attack after an honest server has sent EAP-pwd-Commit/Request to an honest peer. This would result in the peer sending EAP-pwd-Commit/Response. In this case, the active attack has been reduced to that of a passive attacker since p_rand and s_rand will remain unknown. The active attacker could forge a value of Confirm_P (Confirm_S) and send it to the EAP server (EAP peer) in the hope that it will be accepted, but due to the assumptions on H made in Section 2.3, that is computationally infeasible.
主动攻击者可以在诚实的服务器向诚实的对等方发送EAP pwd提交/请求后发起攻击。这将导致对等方发送EAP pwd提交/响应。在这种情况下，由于p_rand和s_rand将保持未知状态，主动攻击已减少为被动攻击。主动攻击者可以伪造Confirm_P（Confirm_S）的值，并将其发送到EAP服务器（EAP对等方），希望其被接受，但由于第2.3节中对H的假设，这在计算上是不可行的。
The active attacker can launch her attack by forging EAP-pwd-Commit/ Request and sending it to the peer. This will result in the peer responding with EAP-pwd-Commit/Response. The attacker can then
主动攻击者可以通过伪造EAP pwd提交/请求并将其发送给对等方来发起攻击。这将导致对等方使用EAP pwd提交/响应进行响应。然后攻击者可以
attempt to compute ks, but since she doesn't know the password, this is infeasible. It can be shown that an attack by forging an EAP-pwd-Commit/Response is an identical attack with equal infeasibility.
尝试计算ks，但由于她不知道密码，这是不可行的。可以证明，伪造EAP pwd提交/响应的攻击是具有相同不可行性的相同攻击。
An active attacker can wait until an honest server sends EAP-pwd-Commit/Request and then forge EAP-pwd-Commit/Response and send it to the server. The server will respond with EAP-pwd-Confirm/Request. Now the attacker can attempt to launch a dictionary attack. She can guess at potential passwords, compute the password element, and compute kp using her p_rand, Scalar_S, and Element_S from the EAP-pwd-Commit/Request and the candidate password element from her guess. She will know if her guess is correct when she is able to verify Confirm_S in EAP-pwd-Confirm/Request.
主动攻击者可以等待诚实的服务器发送EAP pwd提交/请求，然后伪造EAP pwd提交/响应并将其发送到服务器。服务器将响应EAP pwd确认/请求。现在，攻击者可以尝试发起字典攻击。她可以猜测潜在密码，计算密码元素，并使用EAP pwd提交/请求中的p_rand、Scalar_S和element_S以及猜测中的候选密码元素计算kp。当她能够验证EAP pwd确认/请求中的确认时，她将知道她的猜测是否正确。
But the attacker committed to a password guess with her forged EAP-pwd-Commit/Response when she computed Element_P. That value was used by the server in his computation of ks that was used when he constructed Confirm_S in EAP-pwd-Confirm/Request. Any guess of the password that differs from the one used in the forged EAP-pwd-Commit/ Response could not be verified as correct since the attacker has no way of knowing whether it is correct. She is able to make one guess and one guess only per attack. This means that any advantage she can gain -- guess a password, if it fails exclude it from the pool of possible passwords and try again -- is solely through interaction with an honest protocol peer.
但攻击者在计算元素P时使用伪造的EAP pwd Commit/Response进行了密码猜测。服务器在计算ks时使用了该值，在EAP pwd CONFIFM/Request中构造确认时使用了该值。任何与伪造EAP pwd提交/响应中使用的密码不同的猜测都无法验证为正确，因为攻击者无法知道密码是否正确。她能猜一次，每次攻击只能猜一次。这意味着她所能获得的任何优势——猜一个密码，如果它失败，将其从可能的密码池中排除，然后再试一次——完全是通过与诚实的协议对等方的交互。
The attacker can commit to the guess with the forged EAP-pwd-Commit/ Response and then run through the dictionary, computing the password element and ks using her forged Scalar_P and Element_P. She will know she is correct if she can compute the same value for Confirm_S that the server produced in EAP-pwd-Confirm/Request. But this requires the attacker to know s_rand, which we noted above was not possible.
攻击者可以使用伪造的EAP pwd commit/Response提交猜测，然后运行字典，使用伪造的标量P和元素P计算密码元素和ks。如果能够计算服务器在EAP pwd确认/请求中生成的确认值，她就会知道自己是正确的。但这需要攻击者知道s_rand，我们上面提到的是不可能的。
The password element PWE/pwe is chosen using a method described in Section 2.8.3. Since this is an element in the group, there exists a scalar value, q, such that:
使用第2.8.3节所述的方法选择密码元素PWE/PWE。由于这是组中的一个元素，因此存在一个标量值q，因此：
PWE = q * G, for an ECC group
PWE=q*G，用于ECC组
pwe = g^q mod p, for an FFC group
pwe=g^q mod p，对于FFC组
Knowledge of q can be used to launch a dictionary attack. For the sake of brevity, the attack will be demonstrated assuming an ECC group. The attack works thusly:
关于q的知识可用于发起字典攻击。为简洁起见，将在假设ECC组的情况下演示攻击。攻击的效果如此之好：
The attacker waits until an honest server sends an EAP-pwd-Commit/ Request. The attacker then generates a random Scalar_P and a random p_mask and computes Element_P = p_mask * G. The attacker sends the bogus Scalar_P and Element_P to the server and obtains Confirm_S in return. Note that the server is unable to detect that Element_P was calculated incorrectly.
攻击者等待诚实的服务器发送EAP pwd提交/请求。然后，攻击者生成一个随机标量P和一个随机P_掩码，并计算元素P=P_掩码*G。攻击者将伪标量P和元素P发送到服务器，并获得确认作为回报。请注意，服务器无法检测到元素P的计算不正确。
The attacker now knows that:
攻击者现在知道：
KS = (Scalar_P * q + p_mask) * s_rand * G
KS = (Scalar_P * q + p_mask) * s_rand * G
and
和
s_rand * G = Scalar_P * G - ((1/q) mod r * -Element_P)
s_rand * G = Scalar_P * G - ((1/q) mod r * -Element_P)
Since Scalar_P, p_mask, G, and Element_P are all known, the attacker can run through the dictionary, make a password guess, compute PWE using the technique in Section 2.8.3, determine q, and then use the equations above to compute KS and see if it can verify Confirm_S. But to determine q for a candidate PWE, the attacker needs to perform a discrete logarithm that was assumed to be computationally infeasible in Section 2.3. Therefore, this attack is also infeasible.
由于标量P、P_掩码、G和元素P都是已知的，攻击者可以运行字典，猜测密码，使用第2.8.3节中的技术计算PWE，确定q，然后使用上面的等式计算KS，看看是否可以验证Confirm S。但要确定候选PWE的q，攻击者需要执行第2.3节中假定为计算不可行的离散对数。因此，这种攻击也是不可行的。
The best advantage an attacker can gain in a single active attack is to determine whether a single guess at the password was correct. Therefore, her advantage is solely through interaction and not computation, which is the definition for resistance to dictionary attack.
攻击者在一次主动攻击中获得的最大优势是确定对密码的一次猜测是否正确。因此，她的优势完全是通过交互而不是计算，这是抵抗字典攻击的定义。
Resistance to dictionary attack means that the attacker must launch an active attack to make a single guess at the password. If the size of the dictionary from which the password was extracted was D, and each password in the dictionary has an equal probability of being chosen, then the probability of success after a single guess is 1/D. After X guesses, and removal of failed guesses from the pool of possible passwords, the probability becomes 1/(D-X). As X grows, so does the probability of success. Therefore, it is possible for an attacker to determine the password through repeated brute-force, active, guessing attacks. This protocol does not presume to be secure against this, and implementations SHOULD ensure the size of D is sufficiently large to prevent this attack. Implementations SHOULD also take countermeasures -- for instance, refusing authentication attempts for a certain amount of time, after the number of failed authentication attempts reaches a certain threshold. No such threshold or amount of time is recommended in this memo.
抵抗字典攻击意味着攻击者必须发起主动攻击才能猜测密码。如果从中提取密码的字典的大小为D，并且字典中的每个密码被选择的概率相等，则一次猜测后的成功概率为1/D。在进行X次猜测并从可能的密码池中删除失败的猜测后，概率为1/（D-X）。随着X的增长，成功的概率也随之增加。因此，攻击者有可能通过反复的暴力、主动、猜测攻击来确定密码。此协议并不假定对此是安全的，实现应确保D的大小足够大，以防止此攻击。实现还应该采取对策——例如，在失败的身份验证尝试次数达到某个阈值后，在一定时间内拒绝身份验证尝试。本备忘录中不建议使用此类阈值或时间量。
The MSK and EMSK are extracted from MK, which is derived from doing group operations with s_rand, p_rand, and the password element. The peer and server choose random values with each run of the protocol. So even if an attacker is able to learn the password, she will not know the random values used by either the peer or server from an earlier run and will therefore be unable to determine MK, or the MSK or EMSK. This is the definition of Forward Secrecy.
MSK和EMSK是从MK中提取出来的，MK是通过使用s_rand、p_rand和password元素进行组操作得到的。对等方和服务器在每次运行协议时选择随机值。因此，即使攻击者能够了解密码，她也不会知道对等方或服务器在早期运行中使用的随机值，因此无法确定MK、MSK或EMSK。这是前向保密的定义。
The strength of the shared secret, MK, derived in Section 2.8.4 depends on the effort needed to solve the discrete logarithm problem in the chosen group. [RFC3766] has a good discussion on the strength estimates of symmetric keys derived from discrete logarithm cryptography.
第2.8.4节中导出的共享秘密MK的强度取决于所选组中解决离散对数问题所需的努力。[RFC3766]对源自离散对数密码的对称密钥的强度估计进行了很好的讨论。
The mandatory-to-implement group defined in this memo is group 19, a group from [RFC5114] based on Elliptic Curve Cryptography (see Section 2.2.2) with a prime bit length of 256. This group was chosen because the current best estimate of a symmetric key derived using this group is 128 bits, which is the typical length of a key for the Advanced Encryption Standard ([FIPS-197]). While it is possible to obtain a equivalent measure of strength using a group based on Finite Field Cryptography (see Section 2.2.1), it would require a much larger prime and be more memory and compute intensive.
本备忘录中定义的强制实施组是组19，该组来自[RFC5114]，基于椭圆曲线加密（见第2.2.2节），基本位长度为256。选择此组是因为使用此组导出的对称密钥的当前最佳估计值为128位，这是高级加密标准（[FIPS-197]）的密钥的典型长度。虽然可以使用基于有限域加密的组获得等效强度度量（见第2.2.1节），但它需要更大的素数，并且需要更多的内存和计算。
The protocol described in this memo uses a function referred to as a "random oracle" (as defined in [RANDOR]). A significant amount of care must be taken to instantiate a random oracle out of handy cryptographic primitives. The random oracle used here is based on the notion of a "Randomness Extractor" from [RFC5869].
本备忘录中描述的协议使用了一种称为“随机预言机”（定义见[RANDOR]）的功能。必须非常小心地实例化一个随机的oracle加密原语。这里使用的随机预言是基于[RFC5869]中“随机抽取器”的概念。
This protocol can use any properly instantiated random oracle. To ensure that any new value for H will use a properly instantiated random oracle, IANA has been instructed (in Section 5) to only allocate values from the Random Function registry after being vetted by an expert.
该协议可以使用任何正确实例化的随机oracle。为确保H的任何新值将使用正确实例化的随机oracle，IANA已被指示（在第5节中）在专家审查后仅从随机函数注册表分配值。
A few of the defined groups that can be used with this protocol have a security estimate (see Section 6.5) less than 128 bits, many do not though, and to prevent the random function from being the gating factor (or a target for attack), any new random function MUST map its input to a target of at least 128 bits and SHOULD map its input to a target of at least 256 bits.
一些可用于本协议的已定义组的安全估计值（见第6.5节）小于128位，但许多组的安全估计值不小于128位，并且为了防止随机函数成为选通因子（或攻击目标），任何新的随机函数必须将其输入映射到至少128位的目标，并应将其输入映射到至少256位的目标。
[RFC3748] requires that documents describing new EAP methods clearly articulate the security properties of the method. In addition, for use with wireless LANs, [RFC4017] mandates and recommends several of these. The claims are:
[RFC3748]要求描述新EAP方法的文档明确说明该方法的安全属性。此外，对于与无线局域网一起使用，[RFC4017]要求并推荐其中的几个。这些索赔是：
a. mechanism: password.
a. 机制：密码。
b. claims:
b. 声称：
* mutual authentication: the peer and server both authenticate each other by proving possession of a shared password. This is REQUIRED by [RFC4017].
* 相互认证：对等方和服务器都通过证明拥有共享密码来相互认证。这是[RFC4017]所要求的。
* forward secrecy: compromise of the password does not reveal the secret keys -- MK, MSK, or EMSK -- from earlier runs of the protocol.
* 前向保密：密码泄露不会泄露协议早期运行的密钥——MK、MSK或EMSK。
* replay protection: an attacker is unable to replay messages from a previous exchange to either learn the password or a key derived by the exchange. Similarly the attacker is unable to induce either the peer or server to believe the exchange has successfully completed when it hasn't. Reflection attacks are foiled because the server ensures that the scalar and element supplied by the peer do not equal its own.
* 重播保护：攻击者无法重播来自上一个exchange的消息以了解密码或exchange派生的密钥。类似地，攻击者无法诱导对等方或服务器相信交换已成功完成，而事实上交换尚未成功完成。反射攻击被挫败，因为服务器确保对等方提供的标量和元素不等于自己的标量和元素。
* key derivation: keys are derived by performing a group operation in a finite cyclic group (e.g., exponentiation) using secret data contributed by both the peer and server. An MSK and EMSK are derived from that shared secret. This is REQUIRED by [RFC4017]
* 密钥派生：通过使用对等方和服务器提供的机密数据在有限循环组中执行组操作（例如，指数运算）来派生密钥。MSK和EMSK是从该共享秘密派生的。这是[RFC4017]所要求的
* dictionary attack resistance: this protocol is resistant to dictionary attack because an attacker can only make one password guess per active attack. The advantage gained by an attacker is through interaction not through computation. This is REQUIRED by [RFC4017].
* 字典攻击抵抗：此协议抵抗字典攻击，因为攻击者每次活动攻击只能猜测一个密码。攻击者获得的优势是通过交互而不是通过计算。这是[RFC4017]所要求的。
* session independence: this protocol is resistant to active and passive attack and does not enable compromise of subsequent or prior MSKs or EMSKs from either passive or active attack.
* 会话独立性：该协议能够抵抗主动和被动攻击，并且不会使后续或先前的MSK或EMSK受到被动或主动攻击。
* Denial-of-Service Resistance: it is possible for an attacker to cause a server to allocate state and consume CPU cycles generating Scalar_S and Element_S. Such an attack is gated,
* 拒绝服务抵抗：攻击者有可能导致服务器分配状态并消耗CPU周期来生成标量和元素。这种攻击是门控的，
though, by the requirement that the attacker first obtain connectivity through a lower-layer protocol (e.g. 802.11 authentication followed by 802.11 association, or 802.3 "link-up") and respond to two EAP messages --the EAP-ID/ Request and the EAP-pwd-ID/Request. The EAP-pwd-ID exchange further includes an anti-clogging token that provides a level of assurance to the server that the peer is, at least, performing a rudimentary amount of processing and not merely spraying packets. This prevents distributed denial-of-service attacks and also requires the attacker to announce, and commit to, a lower-layer identity, such as a MAC (Media Access Control) address.
但是，根据攻击者首先通过较低层协议（例如802.11认证，然后是802.11关联，或802.3“链接”）获得连接，并响应两条EAP消息的要求——EAP-ID/请求和EAP pwd ID/请求。EAP pwd ID交换还包括防阻塞令牌，该令牌向服务器提供一级保证，即对等方至少正在执行基本量的处理，而不仅仅是喷洒数据包。这可以防止分布式拒绝服务攻击，还需要攻击者宣布并提交较低层身份，如MAC（媒体访问控制）地址。
* Man-in-the-Middle Attack Resistance: this exchange is resistant to active attack, which is a requirement for launching a man-in-the-middle attack. This is REQUIRED by [RFC4017].
* 中间人攻击抵抗：此交换抵抗主动攻击，这是发起中间人攻击的必要条件。这是[RFC4017]所要求的。
* shared state equivalence: upon completion of EAP-pwd, the peer and server both agree on MK, MSK, EMSK, Method-ID, and Session-ID. The peer has authenticated the server based on the Server-ID, and the server has authenticated the peer based on the Peer-ID. This is due to the fact that Peer-ID, Server-ID, and the shared password are all combined to make the password element, which must be shared between the peer and server for the exchange to complete. This is REQUIRED by [RFC4017].
* 共享状态等价：完成EAP pwd后，对等方和服务器都同意MK、MSK、EMSK、方法ID和会话ID。对等方已根据服务器ID对服务器进行身份验证，服务器已根据对等ID对对等方进行身份验证。这是由于对等方ID、服务器ID、，和共享密码一起构成密码元素，必须在对等方和服务器之间共享该元素才能完成交换。这是[RFC4017]所要求的。
* fragmentation: this protocol defines a technique for fragmentation and reassembly in Section 4.
* 分段：该协议在第4节中定义了分段和重新组装的技术。
* resistance to "Denning-Sacco" attack: learning keys distributed from an earlier run of the protocol, such as the MSK or EMSK, will not help an adversary learn the password.
* 抵抗“Denning Sacco”攻击：学习从早期运行的协议（如MSK或EMSK）分发的密钥不会帮助对手学习密码。
c. key strength: the strength of the resulting key depends on the finite cyclic group chosen. See Section 6.5. This is REQUIRED by [RFC4017].
c. 键强度：生成键的强度取决于所选的有限循环组。见第6.5节。这是[RFC4017]所要求的。
d. key hierarchy: MSKs and EMSKs are derived from the MK using the KDF defined in Section 2.5 as described in Section 2.8.4.
d. 密钥层次结构：MSK和EMSK使用第2.5节中定义的KDF从MK派生，如第2.8.4节所述。
e. vulnerabilities (note that none of these are REQUIRED by [RFC4017]):
e. 漏洞（请注意，[RFC4017]不需要这些漏洞）：
* protected ciphersuite negotiation: the ciphersuite offer made by the server is not protected from tampering by an active attacker. Downgrade attacks are prevented, though, since
* 受保护的ciphersuite协商：服务器提供的ciphersuite服务不受主动攻击者篡改的保护。但是，由于
this is not a "negotiation" with a list of acceptable ciphersuites. If a Ciphersuite was modified by an active attacker it would result in a failure to confirm the message sent by the other party, since the Ciphersuite is bound by each side into its confirm message, and the protocol would fail as a result.
这不是一个有可接受密码套件列表的“协商”。如果主动攻击者修改了密码套件，则会导致无法确认另一方发送的消息，因为每一方都将密码套件绑定到其确认消息中，因此协议将失败。
* confidentiality: none of the messages sent in this protocol are encrypted.
* 机密性：此协议中发送的所有消息均未加密。
* integrity protection: messages in the EAP-pwd-Commit exchange are not integrity protected.
* 完整性保护：EAP pwd提交交换中的消息不受完整性保护。
* channel binding: this protocol does not enable the exchange of integrity-protected channel information that can be compared with values communicated via out-of-band mechanisms.
* 通道绑定：此协议不允许交换完整性保护的通道信息，这些信息可以与通过带外机制传递的值进行比较。
* fast reconnect: this protocol does not provide a fast-reconnect capability.
* 快速重新连接：此协议不提供快速重新连接功能。
* cryptographic binding: this protocol is not a tunneled EAP method and therefore has no cryptographic information to bind.
* 加密绑定：此协议不是隧道EAP方法，因此没有要绑定的加密信息。
* identity protection: the EAP-pwd-ID exchange is not protected. An attacker will see the server's identity in the EAP-pwd-ID/Request and see the peer's identity in EAP-pwd-ID/ Response.
* 身份保护：EAP pwd ID交换不受保护。攻击者将在EAP pwd ID/请求中看到服务器的标识，并在EAP pwd ID/响应中看到对等方的标识。
The authors would like to thank Scott Fluhrer for discovering the "password as exponent" attack that was possible in the initial version of this memo and for his very helpful suggestions on the techniques for fixing the PWE/pwe to prevent it. The authors would also like to thank Hideyuki Suzuki for his insight in discovering an attack against a previous version of the underlying key exchange protocol. Special thanks to Lily Chen for helpful discussions on hashing into an elliptic curve and to Jin-Meng Ho for suggesting the countermeasures to protect against a small sub-group attack. Rich Davis suggested the defensive checks to Commit messages, and his various comments greatly improved the quality of this memo and the underlying key exchange on which it is based. Scott Kelly suggested adding the anti-clogging token to the ID exchange to prevent distributed denial-of-service attacks. Dorothy Stanley provided valuable suggestions to improve the quality of this memo. The fragmentation method used was taken from [RFC5216].
作者要感谢Scott Fluhrer发现了本备忘录初始版本中可能存在的“密码为指数”攻击，并就修复PWE/PWE以防止其发生的技术提出了非常有用的建议。作者还要感谢Suzuki Hideyuki在发现针对基础密钥交换协议先前版本的攻击方面的洞察力。特别感谢Lily Chen就散列成椭圆曲线进行了有益的讨论，并感谢Jin Meng Ho提出了防范小子组攻击的对策。Rich Davis建议使用防御性检查来提交消息，他的各种评论极大地提高了该备忘录的质量以及它所基于的底层密钥交换。Scott Kelly建议在ID交换中添加防阻塞令牌，以防止分布式拒绝服务攻击。多萝西·斯坦利为提高这份备忘录的质量提供了宝贵的建议。使用的破碎方法取自[RFC5216]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759]Zorn，G.，“微软PPP CHAP扩展，第2版”，RFC 2759，2000年1月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]Eastlake，D.和T.Hansen，“美国安全哈希算法（SHA和HMAC-SHA）”，RFC 46342006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[SP800-108] Chen, L., "Recommendations for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, April 2008.
[SP800-108]Chen，L.“使用伪随机函数进行密钥推导的建议”，NIST特别出版物800-108，2008年4月。
[SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendations for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, March 2007.
[SP800-56A]Barker，E.，Johnson，D.和M.Smid，“使用离散对数加密的成对密钥建立方案的建议”，NIST特别出版物800-56A，2007年3月。
[APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press Series on Discrete Mathematics and Its Applications, 1996.
[APPCRY]Menezes，A.，van Oorshot，P.，和S.Vanstone，“应用密码学手册”，CRC离散数学及其应用出版社系列，1996年。
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attack", Proceedings of the IEEE Symposium on Security and Privacy, Oakland, 1992.
[BM92]Bellovin，S.和M.Merritt，“加密密钥交换：基于密码的协议防止字典攻击”，IEEE安全和隐私研讨会论文集，奥克兰，1992年。
[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against Dictionary Attacks and Password File Compromise", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993.
[BM93]Bellovin，S.和M.Merritt，“增强加密密钥交换：防止字典攻击和密码文件泄露的基于密码的协议”，第一届ACM计算机和通信安全会议记录，ACM出版社，1993年。
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman", Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 2000.
[BMP00]Boyko，V.，MacKenzie，P.，和S.Patel，“使用Diffie Hellman可证明安全的密码认证密钥交换”，欧洲密码会议录2000年，LNCS 1807 Springer Verlag，2000年。
[FIPS-197] National Institute of Standards and Technology, FIPS Pub 197: Advanced Encryption Standard (AES), November 2001.
[FIPS-197]国家标准与技术研究所，FIPS Pub 197：高级加密标准（AES），2001年11月。
[JAB96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM SIGCOMM Computer Communication Review Volume 1, Issue 5, October 1996.
[JAB96]Jablon，D.，“仅强密码认证密钥交换”，ACM SIGCOMM计算机通信评论第1卷，第5期，1996年10月。
[LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary Attacks Without Encrypting Public Keys", Proceedings of the Security Protocols Workshop, LNCS 1361, Springer-Verlag, 1997.
[Lucks，S.，“开放密钥交换：如何在不加密公钥的情况下击败字典攻击”，《安全协议研讨会论文集》，LNCS 1361，Springer Verlag，1997年。
[RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993.
[RANDOR]Bellare，M.和P.Rogaway，“随机预言是实用的：设计有效协议的范例”，《第一届ACM计算机和通信安全会议论文集》，ACM出版社，1993年。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114]Lepinski，M.和S.Kent，“与IETF标准一起使用的其他Diffie-Hellman组”，RFC 5114，2008年1月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，2008年3月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，2010年5月。
Authors' Addresses
作者地址
Dan Harkins Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 USA
Dan Harkins Aruba Networks美国加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089-1113
EMail: dharkins@arubanetworks.com
EMail: dharkins@arubanetworks.com
Glen Zorn Network Zen 1310 East Thomas Street #306 Seattle, WA 98102 USA
美国华盛顿州西雅图东托马斯街1310号#306号Glen Zorn Network Zen 98102
Phone: +1 (206) 377-9035
EMail: gwz@net-zen.net
Phone: +1 (206) 377-9035
EMail: gwz@net-zen.net