Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6124 Independent
Category: Informational G. Zorn
ISSN: 2070-1721 Network Zen
H. Tschofenig
Nokia Siemens Networks
S. Fluhrer
Cisco
February 2011
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6124 Independent
Category: Informational G. Zorn
ISSN: 2070-1721 Network Zen
H. Tschofenig
Nokia Siemens Networks
S. Fluhrer
Cisco
February 2011
An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol
一种基于加密密钥交换（EKE）协议的EAP认证方法
Abstract
摘要
The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates.
可扩展身份验证协议（EAP）描述了一个允许使用多种身份验证机制的框架。本文档基于加密密钥交换（EKE）协议定义了EAP的身份验证机制，称为EAP-EKE。此方法通过使用简短、易于记忆的密码提供相互身份验证。与其他常用的身份验证方法相比，EAP-EKE不易受到字典攻击。它也不需要公钥证书的可用性。
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/rfc6124.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6124.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 4
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 7
4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. The EAP-EKE-ID Payload . . . . . . . . . . . . . . . . 8
4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 10
4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11
4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 12
4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13
4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14
4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 15
5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 15
5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 17
5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 18
5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 18
5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19
6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19
6.1. Generating Keying Material . . . . . . . . . . . . . . . . 19
6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20
6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27
8.2. Diffie-Hellman Group Considerations . . . . . . . . . . . 28
8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28
8.4. Identity Protection, Anonymity, and Pseudonymity . . . . . 28
8.5. Password Processing and Long-Term Storage . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 4
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 7
4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. The EAP-EKE-ID Payload . . . . . . . . . . . . . . . . 8
4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 10
4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11
4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 12
4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13
4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14
4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 15
5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 15
5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 17
5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 18
5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 18
5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19
6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19
6.1. Generating Keying Material . . . . . . . . . . . . . . . . 19
6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20
6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27
8.2. Diffie-Hellman Group Considerations . . . . . . . . . . . 28
8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28
8.4. Identity Protection, Anonymity, and Pseudonymity . . . . . 28
8.5. Password Processing and Long-Term Storage . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 31
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 to the 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-EKE is an EAP method [RFC3748] that addresses the problem of password-based authenticated key exchange, using a possibly weak password for authentication and to derive an authenticated and cryptographically strong shared secret. This problem was first described by Bellovin and Merritt in [BM92] and [BM93]. Subsequently, a number of other solution approaches have been proposed, for example [JAB96], [LUC97], [BMP00], and others.
EAP-EKE是一种EAP方法[RFC3748]，它解决了基于密码的身份验证密钥交换问题，使用可能较弱的密码进行身份验证，并推导出经过身份验证且加密的强共享密钥。贝洛文和梅里特在[BM92]和[BM93]中首次描述了这个问题。随后，提出了许多其他解决方案方法，例如[JAB96]、[LUC97]、[BMP00]等。
This proposal is based on the original Encrypted Key Exchange (EKE) proposal, as described in [BM92]. Some of the variants of the original EKE have been attacked, see e.g., [PA97], and improvements have been proposed. None of these subsequent improvements have been incorporated into the current protocol. However, we have used only the subset of [BM92] (namely the variant described in Section 3.1 of that paper) that has withstood the test of time and is believed secure as of this writing.
本提案基于[BM92]中所述的原始加密密钥交换（EKE）提案。原始EKE的一些变体已受到攻击，如[PA97]，并提出了改进建议。这些后续改进均未纳入当前协议。然而，我们仅使用了[BM92]的子集（即该论文第3.1节中描述的变体），该子集经受了时间的考验，并且在撰写本文时被认为是安全的。
This document uses Encr(Ke, ...) to denote encrypted information, and Prot(Ke, Ki, ...) to denote encrypted and integrity protected information.
本文档使用Encr（Ke，…）表示加密信息，使用Prot（Ke，Ki，…）表示加密和完整性保护信息。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
EAP is a two-party protocol spoken between an EAP peer and an EAP server (also known as "authenticator"). 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 and the EAP peer for the purpose of authentication and key derivation.
EAP是EAP对等方和EAP服务器（也称为“验证器”）之间的一种双方协议。EAP方法定义EAP使用的特定身份验证协议。此备忘录定义了一种特定的方法，因此定义了EAP服务器和EAP对等方之间发送的消息，用于身份验证和密钥派生。
A successful run of EAP-EKE consists of three message exchanges: an Identity exchange, a Commit exchange, and a Confirm exchange. This is shown in Figure 1.
EAP-EKE的成功运行包括三个消息交换：身份交换、提交交换和确认交换。这如图1所示。
The peer and server use the EAP-EKE Identity exchange to learn each other's identities and to agree upon a ciphersuite to use in the subsequent exchanges. 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 (note that the second message of the Commit exchange already plays an essential part in this liveness proof).
对等方和服务器使用EAP-EKE身份交换来了解彼此的身份，并商定在后续交换中使用的密码套件。在提交交换中，对等方和服务器交换信息以生成共享密钥，并将彼此绑定到对密码的特定猜测。在确认交换中，对等方和服务器通过生成和验证验证数据来证明密码的活动性和知识性（注意，提交交换的第二条消息已经在该活动性证明中发挥了重要作用）。
+--------+ +--------+
| | EAP-EKE-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| (P) | EAP-EKE-ID/Response | (S) |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | EAP-EKE-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| (P) | EAP-EKE-ID/Response | (S) |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Figure 1: A Successful EAP-EKE Exchange
图1：成功的EAP-EKE交换
Schematically, the original exchange as described in [BM92] (and with the roles reversed) is:
示意图上，[BM92]中描述的原始交换（角色颠倒）为：
Server Peer
------ ----
Server Peer
------ ----
Encr(Password, y_s) ->
Encr(Password, y_s) ->
<- Encr(Password, y_p), Encr(SharedSecret, Nonce_P)
<- Encr(Password, y_p), Encr(SharedSecret, Nonce_P)
Encr(SharedSecret, Nonce_S | Nonce_P) ->
Encr(SharedSecret, Nonce_S | Nonce_P) ->
<- Encr(SharedSecret, Nonce_S)
<-Encr（共享秘密，暂时）
Where:
哪里：
o Password is a typically short string, shared between the server and the peer. In other words, the same password is used to authenticate the server to the peer, and vice versa.
o 密码通常是一个短字符串，由服务器和对等方共享。换句话说，相同的密码用于向对等方验证服务器，反之亦然。
o y_s and y_p are the server's and the peer's, respectively, ephemeral public key, i.e., y_s = g ^ x_s (mod p) and y_p = g ^ x_p (mod p).
o y_s和y_p分别是服务器和对等方的临时公钥，即y_s=g^x_s（mod p）和y_p=g^x_p（mod p）。
o Nonce_S, Nonce_P are random strings generated by the server and the peer as cryptographic challenges.
o Nonce_S，Nonce_P是由服务器和对等方生成的作为加密挑战的随机字符串。
o SharedSecret is the secret created by the Diffie-Hellman algorithm, namely SharedSecret = g^(x_s * x_p) (mod p). This value is calculated by the server as: SharedSecret = y_p ^ x_s (mod p), and by the peer as: SharedSecret = y_s ^ x_p (mod p).
o SharedSecret是由Diffie-Hellman算法创建的秘密，即SharedSecret=g^（x_s*x_p）（mod p）。该值由服务器计算为：SharedSecret=y_p^x_s（mod p），由对等服务器计算为：SharedSecret=y_s^x_p（mod p）。
The current protocol extends the basic cryptographic protocol, and the regular successful exchange becomes:
当前协议扩展了基本加密协议，常规成功交换变成：
Message Server Peer
--------- -------- ------
ID/Request ID_S, CryptoProposals ->
Message Server Peer
--------- -------- ------
ID/Request ID_S, CryptoProposals ->
ID/Response <- ID_P, CryptoSelection
ID/响应<-ID\u P，加密选择
Commit/Request Encr(Password, y_s) ->
Commit/Request Encr(Password, y_s) ->
Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P)
Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P)
Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S ->
Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S ->
Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P
Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P
Where, in addition to the above terminology:
其中，除上述术语外：
o Encr means encryption only, and Prot is encryption with integrity protection.
o Encr仅表示加密，Prot是具有完整性保护的加密。
o Ke is an encryption key, and Ki is an integrity-protection key.
o Ke是加密密钥，Ki是完整性保护密钥。
Section 5 explains the various cryptographic values and how they are derived.
第5节解释了各种加密值及其派生方式。
As shown in the exchange above, the following information elements have been added to the original protocol: identity values for both protocol parties (ID_S, ID_P), negotiation of cryptographic protocols, and signature fields to protect the integrity of the negotiated parameters (Auth_S, Auth_P). In addition, the shared secret is not used directly. In this initial exposition, a few details were omitted for clarity. Section 5 should be considered as authoritative regarding message and field details.
如上面的交换所示，以下信息元素已添加到原始协议中：协议双方的标识值（ID_S，ID_P）、加密协议的协商以及用于保护协商参数（Auth_S，Auth_P）完整性的签名字段。此外，共享机密不直接使用。在最初的阐述中，为了清晰起见，省略了一些细节。关于消息和字段详细信息，第5节应被视为权威。
EAP-EKE defines a small number of message types, each message consisting of a header followed by a payload. This section defines the header, several payload formats, as well as the format of specific fields within the payloads.
EAP-EKE定义了少量的消息类型，每条消息由一个报头和一个有效负载组成。本节定义了标题、几种有效负载格式以及有效负载中特定字段的格式。
As usual, all multi-octet strings MUST be laid out in network byte order.
通常，所有多个八位字节字符串必须按网络字节顺序排列。
The EAP-EKE header consists of the standard EAP header (see Section 4 of [RFC3748]), followed by an EAP-EKE exchange type. The header has the following structure:
EAP-EKE头由标准EAP头（见[RFC3748]第4节）和EAP-EKE交换类型组成。标题具有以下结构：
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 | EKE-Exch | 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 | EKE-Exch | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EAP-EKE Header
图2:EAP-EKE头
The Code, Identifier, Length, and Type fields are all part of the EAP header as defined in [RFC3748]. The Type field in the EAP header is 53 for EAP-EKE Version 1.
代码、标识符、长度和类型字段都是[RFC3748]中定义的EAP标头的一部分。对于EAP-EKE版本1，EAP标头中的类型字段为53。
The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE payload encapsulated in the Data field. This document defines the following values for the EKE-Exch field:
EKE Exch（EKE交换）字段标识封装在数据字段中的EAP-EKE有效负载的类型。本文件定义了EKE Exch字段的以下值：
o 0x00: Reserved
o 0x00：保留
o 0x01: EAP-EKE-ID exchange
o 0x01:EAP-EKE-ID交换
o 0x02: EAP-EKE-Commit exchange
o 0x02:EAP EKE提交交换
o 0x03: EAP-EKE-Confirm exchange
o 0x03:EAP EKE确认交换
o 0x04: EAP-EKE-Failure message
o 0x04:EAP EKE故障消息
Further values of this EKE-Exch field are available via IANA registration (Section 7.7).
该EKE Exch字段的更多值可通过IANA注册获得（第7.7节）。
EAP-EKE messages all contain the EAP-EKE header and information encoded in a single payload, which differs for the different exchanges.
EAP-EKE消息都包含EAP-EKE报头和编码在单个有效负载中的信息，这对于不同的交换是不同的。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumProposals | Reserved | Proposal ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Proposal | IDType | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumProposals | Reserved | Proposal ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Proposal | IDType | Identity ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EAP-EKE-ID Payload
图3:EAP-EKE-ID有效载荷
The EAP-EKE-ID payload contains the following fields:
EAP-EKE-ID有效负载包含以下字段：
NumProposals:
NumProposals：
The NumProposals field contains the number of Proposal fields subsequently contained in the payload. In the EAP-EKE-ID/Request message, the NumProposals field MUST NOT be set to zero (0), and in the EAP-EKE-ID/Response message, the NumProposals field MUST be set to one (1). The offered proposals in the Request are listed contiguously in priority order, most preferable first. The selected proposal in the Response MUST be fully identical with one of the offered proposals.
NumProposals字段包含有效负载中随后包含的提案字段数。在EAP-EKE-ID/请求消息中，NumProposals字段不得设置为零（0），而在EAP-EKE-ID/响应消息中，NumProposals字段必须设置为一（1）。请求中提供的建议按优先顺序连续列出，最好先列出。响应中选定的提案必须与所提供的其中一个提案完全相同。
Reserved:
保留：
This field MUST be sent as zero, and MUST be ignored by the recipient.
此字段必须作为零发送，收件人必须忽略此字段。
Proposal:
提议：
Each proposal consists of four one-octet fields, in this order:
每个方案由四个一个八位组字段组成，顺序如下：
Group Description:
组说明：
This field's value is taken from the IANA registry for Diffie-Hellman groups defined in Section 7.1.
该字段的值取自第7.1节中定义的Diffie-Hellman组的IANA注册表。
Encryption:
加密：
This field's value is taken from the IANA registry for encryption algorithms defined in Section 7.2.
该字段的值取自第7.2节中定义的加密算法的IANA注册表。
PRF:
PRF：
This field's value is taken from the IANA registry for pseudo-random functions defined in Section 7.3.
该字段的值取自第7.3节中定义的伪随机函数的IANA注册表。
MAC:
雨衣：
This field's value is taken from the IANA registry for keyed message digest algorithms defined in Section 7.4.
该字段的值取自IANA注册表，用于第7.4节中定义的键控消息摘要算法。
IDType:
IDType：
Denotes the Identity Type. This is taken from the IANA registry defined in Section 7.5. The server and the peer MAY use different identity types. All implementations MUST be able to receive two identity types: ID_NAI and ID_FQDN.
表示标识类型。这来自第7.5节中定义的IANA注册。服务器和对等方可以使用不同的标识类型。所有实现必须能够接收两种标识类型：ID_NAI和ID_FQDN。
Identity:
身份：
The meaning of the Identity field depends on the values of the Code and IDType fields.
标识字段的含义取决于代码和IDType字段的值。
* EAP-EKE-ID/Request: server ID
* EAP-EKE-ID/请求：服务器ID
* EAP-EKE-ID/Response: peer ID
* EAP-EKE-ID/响应：对等ID
The length of the Identity field is computed from the Length field in the EAP header. Specifically, its length is
标识字段的长度根据EAP标头中的长度字段计算。具体来说，它的长度是
eap_header_length - 9 - 4 * number_of_proposals.
eap_标题_长度-9-4*建议数量。
This field, like all other fields in this specification, MUST be octet-aligned.
与本规范中的所有其他字段一样，此字段必须是八位字节对齐的。
This payload allows both parties to send their encrypted ephemeral public key, with the peer also including a Challenge.
该有效载荷允许双方发送其加密的临时公钥，对等方还包括质询。
In addition, a small amount of data can be included by the server and/or the peer, and used for channel binding. This data is sent here unprotected, but is verified later, when it is signed by the Auth_S/Auth_P payloads of the EAP-EKE-Confirm exchange.
此外，服务器和/或对等方可以包含少量数据，并用于通道绑定。此数据在未受保护的情况下发送到此处，但在稍后由EAP EKE确认交换的验证/验证有效负载签名时进行验证。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHComponent_S/DHComponent_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBValue (zero or more occurrences) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHComponent_S/DHComponent_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBValue (zero or more occurrences) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-EKE-Commit Payload
图4:EAP EKE提交负载
DHComponent_S/DHComponent_P:
DHU组件S/DHU组件P：
This field contains the password-encrypted Diffie-Hellman public key, which is generated as described in Section 5.1. Its size is determined by the group and the encryption algorithm.
该字段包含密码加密的Diffie-Hellman公钥，该公钥按照第5.1节的说明生成。其大小由组和加密算法决定。
PNonce_P:
PNU P：
This field only appears in the response, and contains the encrypted and integrity-protected challenge value sent by the peer. The field's size is determined by the encryption and MAC algorithms being used, since this protocol mandates a fixed nonce size for a given choice of algorithms. See Section 5.2.
此字段仅出现在响应中，并包含对等方发送的加密和完整性保护质询值。该字段的大小由所使用的加密和MAC算法决定，因为该协议要求给定算法选择具有固定的nonce大小。见第5.2节。
CBValue:
CBValue：
This structure MAY be included both in the request and in the response, and MAY be repeated multiple times in a single payload. See Section 4.5. Each structure contains its own length. The field is neither encrypted nor integrity protected, instead it is protected by the AUTH payloads in the Confirm exchange.
该结构可以包括在请求和响应中，并且可以在单个有效载荷中重复多次。见第4.5节。每个结构都包含自己的长度。该字段既不加密，也不受完整性保护，而是由Confirm exchange中的验证有效负载保护。
Using this payload, both parties complete the authentication by generating a shared temporary key, authenticating the entire protocol, and generating key material for the EAP consumer protocol.
使用此有效负载，双方通过生成共享临时密钥、验证整个协议以及生成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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_PS/PNonce_S ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth_S/Auth_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_PS/PNonce_S ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth_S/Auth_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP-EKE-Confirm Payload
图5:EAP EKE确认有效载荷
PNonce_PS/PNonce_S:
PNonce\u PS/PNonce\u S：
This field ("protected nonce") contains the encrypted and integrity-protected response to the other party's challenge; see Sections 5.3 and 5.4. Similarly to the PNonce_P field, this field's size is determined by the encryption and MAC algorithms.
该字段（“受保护的nonce”）包含对另一方质询的加密和完整性保护响应；见第5.3节和第5.4节。与PNonce_P字段类似，该字段的大小由加密和MAC算法决定。
Auth_S/Auth_P:
认证/认证：
This field signs the preceding messages, including the Identity and the negotiated fields. This prevents various possible attacks, such as algorithm downgrade attacks. See Section 5.3 and Section 5.4. The size is determined by the pseudo-random function negotiated.
此字段对前面的消息进行签名，包括标识和协商字段。这可以防止各种可能的攻击，例如算法降级攻击。见第5.3节和第5.4节。大小由协商的伪随机函数确定。
The EAP-EKE-Failure payload format is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The EAP-EKE-Failure payload format is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EAP-EKE-Failure Payload
图6:EAP EKE故障有效载荷
The payload's size is always exactly 4 octets.
有效载荷的大小始终正好是4个八位字节。
The following Failure-Code values are defined:
定义了以下故障代码值：
+------------+----------------+-------------------------------------+
| Value | Name | Meaning |
+------------+----------------+-------------------------------------+
| 0x00000000 | Reserved | |
| 0x00000001 | No Error | This code is used for failure |
| | | acknowledgement, see below. |
| 0x00000002 | Protocol Error | A failure to parse or understand a |
| | | protocol message or one of its |
| | | payloads. |
| 0x00000003 | Password Not | A password could not be located for |
| | Found | the identity presented by the other |
| | | protocol party, making |
| | | authentication impossible. |
| 0x00000004 | Authentication | Failure in the cryptographic |
| | Failure | computation, most likely caused by |
| | | an incorrect password or an |
| | | inappropriate identity type. |
| 0x00000005 | Authorization | While the password being used is |
| | Failure | correct, the user is not authorized |
| | | to connect. |
| 0x00000006 | No Proposal | The peer is unwilling to select any |
| | Chosen | of the cryptographic proposals |
| | | offered by the server. |
+------------+----------------+-------------------------------------+
+------------+----------------+-------------------------------------+
| Value | Name | Meaning |
+------------+----------------+-------------------------------------+
| 0x00000000 | Reserved | |
| 0x00000001 | No Error | This code is used for failure |
| | | acknowledgement, see below. |
| 0x00000002 | Protocol Error | A failure to parse or understand a |
| | | protocol message or one of its |
| | | payloads. |
| 0x00000003 | Password Not | A password could not be located for |
| | Found | the identity presented by the other |
| | | protocol party, making |
| | | authentication impossible. |
| 0x00000004 | Authentication | Failure in the cryptographic |
| | Failure | computation, most likely caused by |
| | | an incorrect password or an |
| | | inappropriate identity type. |
| 0x00000005 | Authorization | While the password being used is |
| | Failure | correct, the user is not authorized |
| | | to connect. |
| 0x00000006 | No Proposal | The peer is unwilling to select any |
| | Chosen | of the cryptographic proposals |
| | | offered by the server. |
+------------+----------------+-------------------------------------+
Additional values of this field are available via IANA registration, see Section 7.8.
该字段的其他值可通过IANA注册获得，见第7.8节。
When the peer encounters an error situation, it MUST respond with EAP-EKE-Failure. The server MUST reply with an EAP-Failure message to end the exchange.
当对等方遇到错误情况时，它必须以EAP EKE失败作为响应。服务器必须回复EAP失败消息才能结束交换。
When the server encounters an error situation, it MUST respond with EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message containing a "No Error" failure code. Then the server MUST send an EAP-Failure message to end the exchange.
当服务器遇到错误情况时，它必须响应EAP EKE故障。对等方必须发回包含“无错误”故障代码的EAP EKE故障消息。然后，服务器必须发送EAP失败消息以结束交换。
Implementation of the "Password Not Found" code is not mandatory. For security reasons, implementations MAY choose to return "Authentication Failure" also in cases where the password cannot be located.
不强制执行“未找到密码”代码。出于安全原因，在无法找到密码的情况下，实现也可以选择返回“身份验证失败”。
Several fields are encrypted and integrity-protected. They are denoted Prot(...). Their general structure is as follows:
多个字段被加密并受完整性保护。它们被表示为Prot（…）。其总体结构如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Random Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value (ICV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Random Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value (ICV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Protected Field Structure
图7：受保护字段结构
The protected field is a concatenation of three octet strings:
受保护字段是三个八位字符串的串联：
o An optional IV, required when the encryption algorithm/mode necessitates it, e.g., for CBC encryption. The content and size of this field are determined by the selected encryption algorithm. In the case of CBC encryption, this field is a random octet string having the same size as the algorithm's block size.
o 可选IV，当加密算法/模式需要时需要，例如用于CBC加密。此字段的内容和大小由选定的加密算法决定。在CBC加密的情况下，此字段是一个随机八位字节字符串，其大小与算法的块大小相同。
o The original data, followed if necessary by random padding. This padding has the minimal length (possibly zero) required to complete the length of the encrypted data to the encryption algorithm's block size. The original data and the padding are encrypted together.
o 原始数据，如有必要，后跟随机填充。此填充具有完成加密数据长度到加密算法块大小所需的最小长度（可能为零）。原始数据和填充一起加密。
o ICV, a Message Authentication Code (MAC) cryptographic checksum of the encrypted data, including the padding. The checksum is computed over the encrypted, rather than the plaintext, data. Its length is determined by the MAC algorithm negotiated.
o ICV，加密数据的消息认证码（MAC）加密校验和，包括填充。校验和是对加密数据而不是明文数据进行计算的。其长度由协商的MAC算法决定。
We note that because of the requirement for an explicit ICV, this specification does not support authenticated encryption algorithms. Such algorithms may be added by a future extension.
我们注意到，由于对显式ICV的要求，本规范不支持经过身份验证的加密算法。这种算法可以通过将来的扩展添加。
Two fields are encrypted but are not integrity protected. They are denoted Encr(...). Their format is identical to a protected field (Section 4.3), except that the Integrity Check Value is omitted.
两个字段已加密，但不受完整性保护。它们表示为Encr（…）。其格式与受保护字段（第4.3节）相同，只是省略了完整性检查值。
This protocol allows higher-level protocols to transmit limited opaque information between the peer and the server. This information is integrity protected but not encrypted, and may be used to ensure that protocol participants are identical at different protocol layers. See Section 7.15 of [RFC3748] for more information on the rationale behind this facility.
该协议允许高级协议在对等方和服务器之间传输有限的不透明信息。此信息受完整性保护，但未加密，可用于确保协议参与者在不同协议层是相同的。有关该设施背后原理的更多信息，请参见[RFC3748]第7.15节。
EAP-EKE neither validates nor makes any use of the transmitted information. The information MUST NOT be used by the consumer protocol until it is verified in the EAP-EKE-Confirm exchange (specifically, until it is integrity protected by the Auth_S, Auth_P payloads). Consequently, it MUST NOT be relied upon in case an error occurs at the EAP-EKE level.
EAP-EKE既不验证也不使用传输的信息。在EAP EKE确认交换中对信息进行验证之前，消费者协议不得使用该信息（具体而言，直到该信息受到身份验证、身份验证有效载荷的完整性保护）。因此，在EAP-EKE级别发生错误时，不得依赖该标准。
An unknown Channel Binding Value SHOULD be ignored by the recipient.
收件人应忽略未知的通道绑定值。
Some implementations may require certain values to be present, and will abort the protocol if they are not. Such policy is out of scope of the current protocol.
某些实现可能需要存在某些值，如果不存在，则将中止协议。这种政策超出了现行议定书的范围。
Each Channel Binding Value is encoded using a TLV structure:
使用TLV结构对每个通道绑定值进行编码：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBType | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBType | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Channel Binding Value
图8：通道绑定值
CBType:
CBType：
This is the Channel Binding Value's type. This document defines the value 0x0000 as reserved. Other values are available for IANA allocation, see Section 7.6.
这是通道绑定值的类型。本文档将值0x0000定义为保留值。IANA分配可使用其他值，见第7.6节。
Length:
长度：
This field is the total length in octets of the structure, including the CBType and Length fields.
此字段是结构的总长度（以八位字节为单位），包括CBType和length字段。
This facility should be used with care, since EAP-EKE does not provide for message fragmentation. EAP-EKE is not a tunneled method and should not be used as a generic transport; specifically, implementors should refrain from using the Channel Binding facility to transmit posture information, in the sense of [RFC5209].
由于EAP-EKE不提供消息分段，因此应小心使用此功能。EAP-EKE不是隧道方法，不应用作通用传输；具体而言，实施者应避免使用信道绑定设施来传输姿态信息，即[RFC5209]。
This section describes the sequence of messages for the Commit and Confirm exchanges, and lists the cryptographic operations performed by the server and the peer.
本节描述提交和确认交换的消息序列，并列出服务器和对等方执行的加密操作。
The server computes:
服务器计算：
y_s = g ^ x_s (mod p),
y_s=g^x_s（mod p），
where x_s is a randomly chosen number in the range 2 .. p-1. The randomly chosen number is the ephemeral private key, and the calculated value is the corresponding ephemeral public key. The server and the peer MUST both use a fresh, random value for x_s and the corresponding x_p on each run of the protocol.
其中x_s是范围2.内随机选择的数字。。p-1。随机选择的数字是临时私钥，计算出的值是相应的临时公钥。服务器和对等方在每次运行协议时都必须为x_s和相应的x_p使用一个新的随机值。
The server computes and transmits the encrypted field (Section 4.4)
服务器计算并传输加密字段（第4.4节）
temp = prf(0+, password)
temp = prf(0+, password)
key = prf+(temp, ID_S | ID_P)
键=prf+（温度、ID|S | ID|P）
DHComponent_S = Encr(key, y_s).
DHComponent_S=Encr（键，y_S）。
See Section 6.1 for the prf+ notation. The first argument to "prf" is a string of zero octets whose length is the output size of the base hash algorithm, e.g., 20 octets for HMAC-SHA1; the result is of the same length. The first output octets of prf+ are used as the encryption key for the negotiated encryption algorithm, according to that algorithm's key length.
prf+符号见第6.1节。“prf”的第一个参数是长度为基本哈希算法输出大小的零八位元字符串，例如，HMAC-SHA1为20个八位元；结果是相同的长度。根据协商加密算法的密钥长度，prf+的第一个输出八位字节用作该算法的加密密钥。
Since the PRF function is required to be an application of the HMAC operator to a hash function, the above construction implements HKDF as defined in [RFC5869].
由于PRF函数必须是HMAC运算符对哈希函数的应用，因此上述构造实现[RFC5869]中定义的HKDF。
When using block ciphers, it may be necessary to pad y_s on the right, to fit the encryption algorithm's block size. In such cases, random padding MUST be used, and this randomness is critical to the security of the protocol. Randomness recommendations can be found in [RFC4086]; also see [NIST.800-90.2007] for additional recommendations on cryptographic-level randomness. When decrypting this field, the real length of y_s is determined according to the negotiated Diffie-Hellman group.
使用分组密码时，可能需要在右侧填充y_，以适应加密算法的块大小。在这种情况下，必须使用随机填充，这种随机性对协议的安全性至关重要。随机性建议见[RFC4086]；关于加密级别随机性的其他建议，请参见[NIST.800-90.2007]。解密此字段时，y_s的实际长度根据协商的Diffie-Hellman组确定。
If the password needs to be stored on the server, it is RECOMMENDED to store a randomized password value as a password-equivalent, rather than the cleartext password. We note that implementations may choose the output of either of the two steps of the password derivation. Using the output of the second step, where the password is salted by the identity values, is more secure; however, it may create an operational issue if identities are likely to change. See also Section 8.5.
如果密码需要存储在服务器上，建议将随机密码值存储为等效密码，而不是明文密码。我们注意到，实现可以选择密码派生的两个步骤中的任何一个的输出。使用第二步的输出（其中密码由标识值加盐）更安全；但是，如果身份可能发生变化，则可能会产生操作问题。另见第8.5节。
This protocol supports internationalized, non-ASCII passwords. The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output is the binary representation of the processed UTF-8 [RFC3629] character string. Prohibited output and unassigned code points encountered in SASLprep preprocessing SHOULD cause a preprocessing failure and the output SHOULD NOT be used.
此协议支持国际化的非ASCII密码。输入密码字符串应根据[RFC3454]的[RFC4013]配置文件的规则进行处理。根据[RFC3454]，密码应视为“存储字符串”，因此禁止未分配的代码点。输出是已处理的UTF-8[RFC3629]字符串的二进制表示形式。SASLprep预处理中遇到的禁止输出和未分配代码点应导致预处理失败，并且不应使用该输出。
The peer computes:
对等方计算：
y_p = g ^ x_p (mod p)
y_p=g^x_p（模p）
Then computes:
然后计算：
temp = prf(0+, password)
temp = prf(0+, password)
key = prf+(temp, ID_S | ID_P)
键=prf+（温度、ID|S | ID|P）
DHComponent_P = Encr(key, y_p)
DHP组件=Encr（键，y\U P）
formatted as an encrypted field (Section 4.4).
格式化为加密字段（第4.4节）。
Both sides calculate
双方计算
SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p))
SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p))
The first argument to "prf" is a string of zero octets whose length is the output size of the base hash algorithm, e.g., 20 octets for HMAC-SHA1; the result is of the same length. This extra application of the pseudo-random function is the "extraction step" of [RFC5869]. Note that the peer needs to compute the SharedSecret value before sending out its response.
“prf”的第一个参数是长度为基本哈希算法输出大小的零八位元字符串，例如，HMAC-SHA1为20个八位元；结果是相同的长度。伪随机函数的额外应用是[RFC5869]的“提取步骤”。请注意，对等方需要在发送响应之前计算SharedSecret值。
The encryption and integrity protection keys are computed:
计算加密和完整性保护密钥：
Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P)
Ke | Ki=prf+（共享机密，“EAP-EKE密钥”| ID|S | ID|P）
And the peer generates the Protected Nonce:
对等方生成受保护的Nonce：
PNonce_P = Prot(Ke, Ki, Nonce_P),
PNonce_P=Prot（Ke，Ki，Nonce_P），
where Nonce_P is a randomly generated binary string. The length of Nonce_P MUST be the maximum of 16 octets, and half the key size of the negotiated prf (rounded up to the next octet if necessary). The peer constructs this value as a protected field (Section 4.3), encrypted using Ke and integrity protected using Ki with the negotiated encryption and MAC algorithm.
其中，Nonce_P是随机生成的二进制字符串。Nonce_P的长度必须最大为16个八位字节，为协商prf密钥大小的一半（如有必要，向上舍入到下一个八位字节）。对等方将该值构造为受保护字段（第4.3节），使用Ke进行加密，并使用Ki和协商加密和MAC算法进行完整性保护。
The peer now sends a message that contains the two generated fields.
对等方现在发送一条包含两个生成字段的消息。
The server MUST verify the correct integrity protection of the received nonce, and MUST abort the protocol if it is incorrect, with an "Authentication Failure" code.
服务器必须验证接收到的nonce的正确完整性保护，如果协议不正确，则必须中止协议，并显示“身份验证失败”代码。
The server constructs:
服务器构造：
PNonce_PS = Prot(Ke, Ki, Nonce_P | Nonce_S),
PNonce_PS=Prot（Ke，Ki，Nonce_P|Nonce_S），
as a protected field, where Nonce_S is a randomly generated string, of the same size as Nonce_P.
作为受保护字段，其中Nonce_S是随机生成的字符串，大小与Nonce_P相同。
It computes:
它计算：
Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | Nonce_S)
Ka=prf+（共享秘密，“EAP-EKE Ka”| ID|u S | ID|P | Nonce|P | Nonce|S）
whose length is the preferred key length of the negotiated prf (see Section 5.2). It then constructs:
其长度是协商prf的首选密钥长度（见第5.2节）。然后它构造：
Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE-ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response).
Auth_S=prf（Ka，“EAP-EKE服务器”| EAP-EKE-ID/请求| EAP-EKE-ID/响应| EAP-EKE提交/请求| EAP-EKE提交/响应）。
The messages are included in full, starting with the EAP header, and including any possible future extensions.
这些消息以完整的形式包含，从EAP头开始，包括任何可能的未来扩展。
This construction of the Auth_S (and Auth_P) value implies that any future extensions MUST NOT be added to the EAP-EKE-Confirm/Request or EAP-EKE-Confirm/Response messages themselves, unless these extensions are integrity-protected in some other manner.
Auth_S（和Auth_P）值的这种构造意味着任何未来的扩展都不能添加到EAP EKE确认/请求或EAP EKE确认/响应消息本身，除非这些扩展以其他方式受到完整性保护。
The server now sends a message that contains the two fields.
服务器现在发送一条包含这两个字段的消息。
The peer MUST verify the correct integrity protection of the received nonces and the correctness of the Auth_S value, and MUST abort the protocol if either is incorrect, with an "Authentication Failure" code.
对等方必须验证接收到的nonce的正确完整性保护和Auth_S值的正确性，如果其中一个不正确，则必须中止协议，并使用“身份验证失败”代码。
The peer computes Ka, and generates:
对等方计算Ka，并生成：
PNonce_S = Prot(Ke, Ki, Nonce_S)
PNonce_S=Prot（Ke，Ki，Nonce_S）
as a protected field. It then computes:
作为一个受保护的领域。然后计算：
Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/
Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response)
Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/
Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response)
The peer sends a message that contains the two fields.
对等方发送包含这两个字段的消息。
The server MUST verify the correct integrity protection of the received nonce and the correctness of the Auth_P value, and MUST abort the protocol if either is incorrect, with an "Authentication Failure" code.
服务器必须验证接收的nonce的正确完整性保护和Auth_P值的正确性，如果其中一个不正确，则必须中止协议，并显示“身份验证失败”代码。
Following the last message of the protocol, both sides compute and export the shared keys, each 64 bytes in length:
在协议的最后一条消息之后，双方计算并导出共享密钥，每个密钥的长度为64字节：
MSK | EMSK = prf+(SharedSecret, "EAP-EKE Exported Keys" | ID_S | ID_P | Nonce_P | Nonce_S)
MSK | EMSK=prf+（共享机密，“EAP-EKE导出密钥”| ID|u S | ID|u P | Nonce|P | Nonce|S）
When the RADIUS attributes specified in [RFC2548] are used to transport keying material, then the first 32 bytes of the MSK correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material (the MSK) are used.
当[RFC2548]中指定的半径属性用于传输键控材料时，MSK的前32字节对应于MS-MPPE-RECV-KEY，第二32字节对应于MS-MPPE-SEND-KEY。在这种情况下，仅使用64字节的键控材料（MSK）。
At this point, both protocol participants MUST discard all intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke, Ki, Ka, and SharedSecret. Similarly, both parties MUST immediately discard these values whenever the protocol terminates with a failure code or as a result of timeout.
此时，两个协议参与者必须放弃所有中间加密值，包括x_p、x_s、y_p、y_s、Ke、Ki、Ka和SharedSecret。类似地，当协议因故障代码或超时而终止时，双方必须立即丢弃这些值。
Keying material is derived as the output of the negotiated pseudo-random function (prf) algorithm. Since the amount of keying material needed may be greater than the size of the output of the prf algorithm, we will use the prf iteratively. We denote by "prf+" the function that outputs a pseudo-random stream based on the inputs to a prf as follows (where "|" indicates concatenation):
密钥材料是协商伪随机函数（prf）算法的输出。由于所需的键控材料量可能大于prf算法输出的大小，因此我们将迭代使用prf。我们用“prf+”表示函数，该函数根据prf的输入输出伪随机流，如下所示（其中“|”表示串联）：
prf+ (K, S) = T1 | T2 | T3 | T4 | ...
prf+（K，S）=T1 | T2 | T3 | T4 |。。。
where:
哪里：
T1 = prf(K, S | 0x01)
T1=prf（K，S | 0x01）
T2 = prf(K, T1 | S | 0x02)
T2=prf（K，T1 | S | 0x02）
T3 = prf(K, T2 | S | 0x03)
T3=prf（K，T2 | S | 0x03）
T4 = prf(K, T3 | S | 0x04)
T4=prf（K，T3 | S | 0x04）
continuing as needed to compute all required keys. The keys are taken from the output string without regard to boundaries (e.g., if the required keys are a 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC key, and the prf function generates 160 bits, the AES key will come from T1 and the beginning of T2, while the HMAC key will come from the rest of T2 and the beginning of T3).
根据需要继续计算所有必需的密钥。密钥取自输出字符串而不考虑边界（例如，如果所需密钥是256位高级加密标准（AES）密钥和160位HMAC密钥，并且prf函数生成160位，则AES密钥将来自T1和T2的开头，而HMAC密钥将来自T2的其余部分和T3的开头）。
The constant concatenated to the end of each string feeding the prf is a single octet. In this document, prf+ is not defined beyond 255 times the size of the prf output.
连接到提供prf的每个字符串末尾的常量是一个八位字节。在本文档中，prf+的定义不超过prf输出大小的255倍。
Many of the commonly used Diffie-Hellman groups are inappropriate for use in EKE. Most of these groups use a generator that is not a primitive element of the group. As a result, an attacker running a dictionary attack would be able to learn at least 1 bit of information for each decrypted password guess.
许多常用的Diffie-Hellman群不适合在EKE中使用。这些组中的大多数使用的生成器不是组的基本元素。因此，运行字典攻击的攻击者将能够为每次解密的密码猜测学习至少1位信息。
Any MODP Diffie-Hellman group defined for use in this protocol MUST have the following properties to ensure that it does not leak a usable amount of information about the password:
为在本协议中使用而定义的任何MODP Diffie-Hellman组必须具有以下属性，以确保其不会泄漏有关密码的可用信息量：
1. The generator is a primitive element of the group.
1. 生成器是组的基本元素。
2. The most significant 64 bits of the prime number are 1.
2. 素数的最高有效64位是1。
3. The group's order p is a "safe prime", i.e., (p-1)/2 is also prime.
3. 群的阶数p是“安全素数”，即（p-1）/2也是素数。
The last requirement is related to the strength of the Diffie-Hellman algorithm, rather than the password encryption. It also makes it easy to verify that the generator is primitive.
最后一个要求与Diffie-Hellman算法的强度有关，而不是密码加密。它还可以很容易地验证生成器是否是原始的。
Suitable groups are defined in Section 7.1.
第7.1节定义了合适的组。
To facilitate interoperability, the following algorithms are mandatory to implement:
为促进互操作性，必须实现以下算法：
o ENCR_AES128_CBC (encryption algorithm)
o ENCR_AES128_CBC（加密算法）
o PRF_HMAC_SHA1 (pseudo-random function)
o 伪随机函数
o MAC_HMAC_SHA1 (keyed message digest)
o MAC_HMAC_SHA1（键控消息摘要）
o DHGROUP_EKE_14 (DH-group)
o DH组_EKE_14（DH组）
IANA has allocated the EAP method type 53 from the range 1-191, for "EAP-EKE Version 1".
IANA已为“EAP-EKE版本1”分配范围为1-191的EAP方法类型53。
Per this document, IANA created the registries described in the following sub-sections. Values (other than private-use ones) can be added to these registries per Specification Required [RFC5226], with two exceptions: the Exchange and Failure Code registries can only be extended per RFC Required [RFC5226].
根据本文件，IANA创建了以下小节中描述的注册表。可根据所需规范[RFC5226]将值（私用值除外）添加到这些注册表中，但有两个例外：交换和故障代码注册表只能根据所需规范[RFC5226]进行扩展。
This section defines an IANA registry for Diffie-Hellman groups.
本节定义Diffie-Hellman组的IANA注册表。
This table defines the initial contents of this registry. The Value column is used when negotiating the group. Additional groups may be defined through IANA allocation. Any future specification that defines a non-MODP group MUST specify its use within EAP-EKE and MUST demonstrate the group's security in this context.
此表定义了此注册表的初始内容。协商组时使用值列。可通过IANA分配定义其他组。定义非MODP组的任何未来规范都必须指定其在EAP-EKE中的使用，并且必须证明该组在此上下文中的安全性。
+-----------------+---------+---------------------------------------+
| Name | Value | Description |
+-----------------+---------+---------------------------------------+
| Reserved | 0 | |
| DHGROUP_EKE_2 | 1 | The prime number of the 1024-bit |
| | | Group 2 [RFC5996], with the generator |
| | | 5 (decimal) |
| DHGROUP_EKE_5 | 2 | The prime number of the 1536-bit |
| | | Group 5 [RFC3526], g=31 |
| DHGROUP_EKE_14 | 3 | The prime number of the 2048-bit |
| | | Group 14 [RFC3526], g=11 |
| DHGROUP_EKE_15 | 4 | The prime number of the 3072-bit |
| | | Group 15 [RFC3526], g=5 |
| DHGROUP_EKE_16 | 5 | The prime number of the 4096-bit |
| | | Group 16 [RFC3526], g=5 |
| Available for | 6-127 | |
| allocation via | | |
| IANA | | |
| Reserved for | 128-255 | |
| Private Use | | |
+-----------------+---------+---------------------------------------+
+-----------------+---------+---------------------------------------+
| Name | Value | Description |
+-----------------+---------+---------------------------------------+
| Reserved | 0 | |
| DHGROUP_EKE_2 | 1 | The prime number of the 1024-bit |
| | | Group 2 [RFC5996], with the generator |
| | | 5 (decimal) |
| DHGROUP_EKE_5 | 2 | The prime number of the 1536-bit |
| | | Group 5 [RFC3526], g=31 |
| DHGROUP_EKE_14 | 3 | The prime number of the 2048-bit |
| | | Group 14 [RFC3526], g=11 |
| DHGROUP_EKE_15 | 4 | The prime number of the 3072-bit |
| | | Group 15 [RFC3526], g=5 |
| DHGROUP_EKE_16 | 5 | The prime number of the 4096-bit |
| | | Group 16 [RFC3526], g=5 |
| Available for | 6-127 | |
| allocation via | | |
| IANA | | |
| Reserved for | 128-255 | |
| Private Use | | |
+-----------------+---------+---------------------------------------+
This section defines an IANA registry for encryption algorithms:
本节定义了加密算法的IANA注册表：
+-----------------+---------+-----------------------------------+
| Name | Value | Definition |
+-----------------+---------+-----------------------------------+
| Reserved | 0 | |
| ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode |
| | 2-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-----------------+---------+-----------------------------------+
+-----------------+---------+-----------------------------------+
| Name | Value | Definition |
+-----------------+---------+-----------------------------------+
| Reserved | 0 | |
| ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode |
| | 2-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-----------------+---------+-----------------------------------+
This section defines an IANA registry for pseudo-random function algorithms:
本节定义了伪随机函数算法的IANA注册表：
+-------------------+---------+-------------------------------------+
| Name | Value | Definition |
+-------------------+---------+-------------------------------------+
| Reserved | 0 | |
| PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] |
| PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] |
| | 3-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-------------------+---------+-------------------------------------+
+-------------------+---------+-------------------------------------+
| Name | Value | Definition |
+-------------------+---------+-------------------------------------+
| Reserved | 0 | |
| PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] |
| PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] |
| | 3-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-------------------+---------+-------------------------------------+
A pseudo-random function takes two parameters K and S (the key and input string respectively), and, to be usable in this protocol, must be defined for all lengths of K between 0 and 65,535 bits (inclusive).
伪随机函数采用两个参数K和S（分别为密钥和输入字符串），并且为了在本协议中可用，必须为0到65535位（包括）之间的所有长度K定义伪随机函数。
Any future pseudo-random function MUST be based on the HMAC construct, since the security of HKDF is only known for such functions.
任何未来的伪随机函数都必须基于HMAC构造，因为HKDF的安全性仅为此类函数所知。
This section defines an IANA registry for keyed message digest algorithms:
本节为键控消息摘要算法定义IANA注册表：
+-------------------+---------+--------------+----------------------+
| Name | Value | Key Length | Definition |
| | | (Octets) | |
+-------------------+---------+--------------+----------------------+
| Reserved | 0 | | |
| MAC_HMAC_SHA1 | 1 | 20 | HMAC SHA-1, as |
| | | | defined in [RFC2104] |
| MAC_HMAC_SHA2_256 | 2 | 32 | HMAC SHA-2-256 |
| Reserved | 3-127 | | Available for |
| | | | allocation via IANA |
| Reserved | 128-255 | | Reserved for Private |
| | | | Use |
+-------------------+---------+--------------+----------------------+
+-------------------+---------+--------------+----------------------+
| Name | Value | Key Length | Definition |
| | | (Octets) | |
+-------------------+---------+--------------+----------------------+
| Reserved | 0 | | |
| MAC_HMAC_SHA1 | 1 | 20 | HMAC SHA-1, as |
| | | | defined in [RFC2104] |
| MAC_HMAC_SHA2_256 | 2 | 32 | HMAC SHA-2-256 |
| Reserved | 3-127 | | Available for |
| | | | allocation via IANA |
| Reserved | 128-255 | | Reserved for Private |
| | | | Use |
+-------------------+---------+--------------+----------------------+
This section defines an IANA registry for identity types:
本节定义标识类型的IANA注册表：
+-----------+---------+---------------------------------------------+
| Name | Value | Definition |
+-----------+---------+---------------------------------------------+
| Reserved | 0 | |
| ID_OPAQUE | 1 | An opaque octet string |
| ID_NAI | 2 | A Network Access Identifier, as defined in |
| | | [RFC4282] |
| ID_IPv4 | 3 | An IPv4 address, in binary format |
| ID_IPv6 | 4 | An IPv6 address, in binary format |
| ID_FQDN | 5 | A fully qualified domain name, see note |
| | | below |
| ID_DN | 6 | An LDAP Distinguished Name formatted as a |
| | | string, as defined in [RFC4514] |
| | 7-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-----------+---------+---------------------------------------------+
+-----------+---------+---------------------------------------------+
| Name | Value | Definition |
+-----------+---------+---------------------------------------------+
| Reserved | 0 | |
| ID_OPAQUE | 1 | An opaque octet string |
| ID_NAI | 2 | A Network Access Identifier, as defined in |
| | | [RFC4282] |
| ID_IPv4 | 3 | An IPv4 address, in binary format |
| ID_IPv6 | 4 | An IPv6 address, in binary format |
| ID_FQDN | 5 | A fully qualified domain name, see note |
| | | below |
| ID_DN | 6 | An LDAP Distinguished Name formatted as a |
| | | string, as defined in [RFC4514] |
| | 7-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-----------+---------+---------------------------------------------+
An example of an ID_FQDN is "example.com". The string MUST NOT contain any terminators (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an internationalized domain name, the syntax is as defined in [RFC5891], for example "xn--tmonesimerkki-bfbb.example.net".
ID_FQDN的一个示例是“example.com”。字符串不得包含任何终止符（例如NULL、CR等）。ID_FQDN中的所有字符均为ASCII；对于国际化域名，语法如[RFC5891]中所定义，例如“xn--tmonesimerkki bfbb.example.net”。
This section defines an IANA registry for the Channel Binding Type registry, a 16-bit long code. The value 0x0000 has been defined as Reserved. All other values up to and including 0xfeff are available for allocation via IANA. The remaining values up to and including 0xffff are available for Private Use.
本节为通道绑定类型注册表定义一个IANA注册表，一个16位长的代码。值0x0000已定义为保留。所有其他小于等于0xfeff的值可通过IANA分配。0xffff之前（含0xffff）的剩余值可供私人使用。
This section defines an IANA registry for the EAP-EKE Exchange registry, an 8-bit long code. Initial values are defined in Section 4.1. All values up to and including 0x7f are available for allocation via IANA. The remaining values up to and including 0xff are available for private use.
本节为EAP-EKE Exchange注册表定义IANA注册表，这是一个8位长的代码。初始值在第4.1节中定义。所有小于等于0x7f的值均可通过IANA分配。0xff之前（含0xff）的剩余值可供私人使用。
This section defines an IANA registry for the Failure-Code registry, a 32-bit long code. Initial values are defined in Section 4.2.4. All values up to and including 0xfeffffff are available for allocation via IANA. The remaining values up to and including 0xffffffff are available for private use.
本节为故障代码注册表定义了一个IANA注册表，一个32位长的代码。初始值在第4.2.4节中定义。所有小于等于0xFEFFFF的值均可通过IANA分配。0xFFFFFF之前（含0xFFFFFF）的其余值可供私人使用。
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 paragraphs.
任何声称能够解决密码认证密钥交换问题的协议都必须能够抵抗主动、被动和字典攻击，并且具有前向保密性。这些特征将在以下段落中进一步讨论。
Resistance to Passive Attack: A passive 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.
抵抗被动攻击：被动攻击者只是在对等方和服务器之间忠实地、不加修改地来回传递消息。消息的内容可供检查，但仅此而已。要实现对被动攻击的抵抗，此类攻击者必须无法通过观察协议的重复运行来获取有关密码或由此产生的共享秘密的任何信息。即使被动攻击者能够识别密码，她也无法确定对等方和服务器共享的任何有关最终秘密的信息。
Resistance to Active Attack: 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.
参与者认为协议成功完成。主动攻击者总是有可能拒绝传递对完成交换至关重要的消息。这与删除所有消息没有什么区别，也不是对协议的攻击。
Resistance to Dictionary Attack: 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.
抵抗字典攻击：为了使该协议抵抗字典攻击，对手可以获得的任何优势都必须与她与诚实协议参与者的交互次数直接相关，而不是通过计算。对手将无法获得有关密码的任何信息，除非从单个协议运行中猜测密码是否正确。
Forward Secrecy: Compromise of the password must not provide any information about the secrets generated by earlier runs of the protocol.
前向保密：密码泄露不得提供有关协议早期运行产生的秘密的任何信息。
[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]要求并推荐其中的几个。这些索赔是：
1. Mechanism: password.
1. 机制：密码。
2. Claims:
2. 声称：
* 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 (MSK and EMSK) from earlier runs of the protocol.
* 前向保密：密码泄露不会泄露协议早期运行的密钥（MSK和EMSK）。
* Replay protection: an attacker is unable to replay messages from a previous exchange either to 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.
* 重播保护：攻击者无法重播来自上一个exchange的消息以了解密码或exchange派生的密钥。类似地，攻击者无法诱导对等方或服务器相信交换已成功完成，而实际上交换尚未成功完成。
* Key derivation: a shared secret is 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: an attacker can only make one password guess per active attack, and the protocol is designed so that the attacker does not gain any confirmation of her guess by observing the decrypted y_s or y_p value (see below). The advantage she can gain is through interaction not through computation. This is REQUIRED by [RFC4017].
* 字典攻击抵抗：攻击者每次主动攻击只能猜测一个密码，协议的设计使得攻击者不会通过观察解密的y_s或y_p值（见下文）来确认其猜测。她能获得的优势是通过互动而不是通过计算。这是[RFC4017]所要求的。
* Session independence: this protocol is resistant to active and passive attacks and does not enable compromise of subsequent or prior MSKs or EMSKs from either passive or active attacks.
* 会话独立性：该协议能够抵抗主动和被动攻击，并且不会使后续或先前的MSK或EMSK受到被动或主动攻击。
* Denial-of-service resistance: it is possible for an attacker to cause a server to allocate state and consume CPU. Such an attack is gated, 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-EKE-ID/Request.
* 拒绝服务抵抗：攻击者可能导致服务器分配状态并消耗CPU。但是，这种攻击是通过要求攻击者首先通过较低层协议（例如，802.11认证，然后是802.11关联，或802.3“链接”）获得连接，并响应两条EAP消息（EAP-ID/请求和EAP-EKE-ID/请求）来实现的。
* 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-EKE, the peer and server both agree on the MSK and EMSK values. 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 generated shared secret are all combined to make the authentication element that must be shared between the peer and server for the exchange to complete. This is REQUIRED by [RFC4017].
* 共享状态等价：完成EAP-EKE后，对等方和服务器都同意MSK和EMSK值。对等方已根据服务器ID对服务器进行了身份验证，而服务器已根据对等方ID对对等方进行了身份验证。这是因为对等方ID、服务器ID和生成的共享密钥都组合在一起，从而形成了必须在对等方和服务器之间共享的身份验证元素，才能完成交换。这是[RFC4017]所要求的。
* Fragmentation: this protocol does not define a technique for fragmentation and reassembly.
* 分段：该协议没有定义分段和重新组装的技术。
* 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）分发的密钥不会帮助对手学习密码。
3. Key strength: the strength of the resulting key depends on the finite cyclic group chosen. Sufficient key strength is REQUIRED by [RFC4017]. Clearly, "sufficient" strength varies over time, depending on computation power assumed to be available to potential attackers.
3. 键强度：生成键的强度取决于所选的有限循环组。[RFC4017]要求有足够的键强度。显然，“足够”强度随时间而变化，这取决于假定潜在攻击者可用的计算能力。
4. Key hierarchy: MSKs and EMSKs are derived from the secret values generated during the protocol run, using a negotiated pseudo-random function.
4. 密钥层次结构：MSK和EMSK使用协商的伪随机函数从协议运行期间生成的秘密值派生而来。
5. Vulnerabilities (note that none of these are REQUIRED by [RFC4017]):
5. 漏洞（请注意，[RFC4017]不需要这些漏洞）：
* Protected ciphersuite negotiation: the ciphersuite proposal made by the server is not protected from tampering by an active attacker. However, if a proposal was modified by an active attacker, it would result in a failure to confirm the message sent by the other party, since the proposal is bound by each side into its Confirm message, and the protocol would fail as a result. Note that this assumes that none of the proposed ciphersuites enables an attacker to perform real-time cryptanalysis.
* 受保护的ciphersuite协商：服务器提出的ciphersuite方案不受主动攻击者篡改的保护。但是，如果主动攻击者修改了提案，则会导致无法确认另一方发送的消息，因为提案被每一方绑定到其确认消息中，因此协议将失败。请注意，这假设所建议的密码套件都不能让攻击者执行实时密码分析。
* Confidentiality: none of the messages sent in this protocol are encrypted, though many of the protocol fields are.
* 机密性：此协议中发送的任何消息都不加密，尽管许多协议字段都是加密的。
* Integrity protection: protocol messages are not directly integrity protected; however, the ID and Commit exchanges are integrity protected through the Auth payloads exchanged in the Confirm exchange.
* 完整性保护：协议消息不直接受完整性保护；但是，ID和提交交换通过在确认交换中交换的身份验证有效负载得到完整性保护。
* Channel binding: this protocol enables 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-EKE-ID exchange is not protected. An attacker will see the server's identity in the EAP-EKE-ID/ Request and see the peer's identity in EAP-EKE-ID/Response. See also Section 8.4.
* 身份保护：EAP-EKE-ID交换不受保护。攻击者将在EAP-EKE-ID/请求中看到服务器的标识，并在EAP-EKE-ID/响应中看到对等方的标识。另见第8.4节。
When analyzing the Commit exchange, it should be noted that the base security assumptions are different from "normal" cryptology. Normally, we assume that the key has strong security properties, and that the data may have few or none. Here, we assume that the key has weak security properties (the attacker may have a list of possible keys), and hence we need to ensure that the data has strong
在分析提交交换时，应该注意基本安全性假设不同于“普通”密码学。通常，我们假设密钥具有很强的安全属性，并且数据可能很少或没有。这里，我们假设密钥具有弱安全属性（攻击者可能有一系列可能的密钥），因此我们需要确保数据具有强安全性
properties (indistinguishable from random). This difference may mean that conventional wisdom in cryptology might not apply in this case. This also imposes severe constraints on the protocol, e.g., the mandatory use of random padding and the need to define specific finite groups.
属性（与随机属性无法区分）。这种差异可能意味着密码学中的传统智慧可能不适用于这种情况。这也对协议施加了严格的限制，例如，强制使用随机填充和需要定义特定的有限组。
It is fundamental to the dictionary attack resistance that the Diffie-Hellman public values y_s and y_p are indistinguishable from a random string. If this condition is not met, then a passive attacker can do trial-decryption of the encrypted DHComponent_P or DHComponent_S values based on a password guess, and if they decrypt to a value that is not a valid public value, they know that the password guess was incorrect.
Diffie-Hellman公共值y_s和y_p与随机字符串无法区分，这是字典攻击抵抗的基础。如果不满足此条件，则被动攻击者可以根据密码猜测对加密的DHComponent_P或DHComponent_S值进行尝试解密，如果他们解密为无效的公共值，则知道密码猜测不正确。
For MODP groups, Section 6.2 gives conditions on the group to make sure that this criterion is met. For other groups (for example, Elliptic Curve groups), some other means of ensuring this must be employed. The standard way of expressing Elliptic Curve public values does not meet this criterion, as a valid Elliptic Curve X coordinate can be distinguished from a random string with probability of approximately 0.5.
对于MODP组，第6.2节给出了组的条件，以确保满足该标准。对于其他组（例如，椭圆曲线组），必须采用一些其他方法来确保这一点。表示椭圆曲线公共值的标准方法不符合此标准，因为有效的椭圆曲线X坐标可以与概率约为0.5的随机字符串区分开来。
A future document might introduce a group representation, and/or a slight modification of the password encryption scheme, so that Elliptic Curve groups can be accommodated. [BR02] presents several alternative solutions for this problem.
未来的文档可能会引入组表示和/或密码加密方案的轻微修改，以便可以容纳椭圆曲线组。[BR02]介绍了解决此问题的几种备选方案。
An attacker, impersonating either the peer or the server, can always try to enumerate all possible passwords, for example by using a dictionary. To counter this likely attack vector, both peer and server MUST implement rate-limiting mechanisms. We note that locking out the other party after a small number of tries would create a trivial denial-of-service opportunity.
模拟对等方或服务器的攻击者总是可以尝试枚举所有可能的密码，例如使用字典。为了对抗这种可能的攻击向量，对等和服务器都必须实现速率限制机制。我们注意到，在少量尝试后锁定另一方将产生一个微不足道的拒绝服务机会。
By default, the EAP-EKE-ID exchange is unprotected, and an eavesdropper can observe both parties' identities. A future extension of this protocol may support anonymity, e.g., by allowing the server to send a temporary identity to the peer at the end of the exchange, so that the peer can use that identity in subsequent exchanges.
默认情况下，EAP-EKE-ID交换不受保护，窃听者可以观察双方的身份。该协议的未来扩展可以支持匿名性，例如，通过允许服务器在交换结束时向对等方发送临时标识，以便对等方可以在后续交换中使用该标识。
EAP-EKE differs in this respect from tunneled methods, which typically provide unconditional identity protection to the peer by encrypting the identity exchange, but reveal information in the server certificate. It is possible to use EAP-EKE as the inner method in a tunneled EAP method in order to achieve this level of identity protection.
EAP-EKE在这方面与隧道方法不同，隧道方法通常通过加密身份交换向对等方提供无条件身份保护，但会在服务器证书中显示信息。可以使用EAP-EKE作为隧道EAP方法中的内部方法，以实现此级别的身份保护。
This document recommends that a password-equivalent (a hash of the password) be stored instead of the cleartext password. While this solution provides a measure of security, there are also tradeoffs related to algorithm agility:
本文档建议存储与明文密码等效的密码（密码的散列），而不是明文密码。虽然此解决方案提供了一种安全措施，但也存在与算法灵活性相关的权衡：
o Each stored password must identify the hash function that was used to compute the stored value.
o 每个存储的密码必须标识用于计算存储值的哈希函数。
o Complex deployments and migration scenarios might necessitate multiple stored passwords, one per each algorithm.
o 复杂的部署和迁移场景可能需要存储多个密码，每个算法一个。
o Changing the algorithm can require, in some cases, that the users manually change their passwords.
o 在某些情况下，更改算法可能需要用户手动更改密码。
The reader is referred to Section 10 of [RFC3629] for security considerations related to the parsing and processing of UTF-8 strings.
读者可参考[RFC3629]第10节了解与UTF-8字符串解析和处理相关的安全注意事项。
Much of this document was unashamedly picked from [RFC5931] and [EAP-SRP], and we would like to acknowledge the authors of these documents: Dan Harkins, Glen Zorn, James Carlson, Bernard Aboba, and Henry Haverinen. We would like to thank David Jacobson, Steve Bellovin, Russ Housley, Brian Weis, Dan Harkins, and Alexey Melnikov for their useful comments. Lidar Herooty and Idan Ofrat implemented this protocol and helped us improve it by asking the right questions, and we would like to thank them both.
本文件的大部分内容都是从[RFC5931]和[EAP-SRP]中毫不掩饰地挑选出来的，我们要感谢这些文件的作者：Dan Harkins、Glen Zorn、James Carlson、Bernard Aboba和Henry Haverinen。我们要感谢David Jacobson、Steve Bellovin、Russ Housley、Brian Weis、Dan Harkins和Alexey Melnikov的有用评论。Lidar Herooty和Idan Ofrat实施了该协议，并通过提出正确的问题帮助我们改进了该协议，我们要感谢他们两人。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[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月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[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月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[SHA] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", NIST FIPS 180-3, October 2008.
[SHA]美国商务部国家标准与技术研究所，“安全哈希标准”，NIST FIPS 180-32008年10月。
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks", Proc. IEEE Symp. on Research in Security and Privacy , May 1992.
[BM92]Bellovin，S.和M.Merritt，“加密密钥交换：基于密码的协议防止字典攻击”，Proc。IEEE研讨会。关于安全和隐私的研究，1992年5月。
[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against Dictionary Attacks and Password File Compromise", Proc. 1st ACM Conference on Computer and Communication Security , 1993.
[BM93]Bellovin，S.和M.Merritt，“增强加密密钥交换：一种基于密码的协议，可防止字典攻击和密码文件泄露”，Proc。第一届ACM计算机和通信安全会议，1993年。
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman", Advances in Cryptology, EUROCRYPT 2000 , 2000.
[BMP00]Boyko，V.，MacKenzie，P.，和S.Patel，“使用Diffie Hellman可证明安全的密码认证密钥交换”，密码学进展，EUROCRYPT 2000，2000。
[BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite Domains", Proc. of the RSA Cryptographer's Track (RSA CT '02), LNCS 2271 , 2002.
[BR02]Black，J.和P.Rogaway，“具有任意有限域的密码”，Proc。《RSA密码学家的足迹》（RSA CT'02），LNCS 22712002。
[EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", Work in Progress, July 2001.
[EAP-SRP]Carlson，J.，Aboba，B.，和H.Haverinen，“EAP-SRP-SHA1认证协议”，正在进行的工作，2001年7月。
[JAB96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM Computer Communications Review Volume 1, Issue 5, October 1996.
[JAB96]Jablon，D.，“仅强密码认证密钥交换”，ACM计算机通信评论第1卷，第5期，1996年10月。
[LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary Attacks Without Encrypting Public Keys", Proc. of the Security Protocols Workshop LNCS 1361, 1997.
[Lucks，S.，“开放密钥交换：如何在不加密公钥的情况下击败字典攻击”，Proc。安全协议研讨会LNCS 13611997。
[NIST.800-90.2007] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised)", NIST SP 800-90, March 2007.
[NIST.800-90.2007]国家标准与技术研究所，“使用确定性随机位生成器生成随机数的建议（修订版）”，NIST SP 800-90，2007年3月。
[PA97] Patel, S., "Number Theoretic Attacks On Secure Password Schemes", Proceedings of the 1997 IEEE Symposium on Security and Privacy , 1997.
[PA97]Patel，S.，“对安全密码方案的数论攻击”，1997年IEEE安全与隐私研讨会论文集，1997年。
[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月。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[RFC5209]Sangster，P.，Khosravi，H.，Mani，M.，Narayan，K.，和J.Tardo，“网络端点评估（NEA）：概述和要求”，RFC 52092008年6月。
[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月。
[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月。
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, August 2010.
[RFC5931]Harkins，D.和G.Zorn，“仅使用密码的可扩展身份验证协议（EAP）身份验证”，RFC 59312010年8月。
Authors' Addresses
作者地址
Yaron Sheffer Independent
亚龙谢弗独立报
EMail: yaronf.ietf@gmail.com
EMail: yaronf.ietf@gmail.com
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
格伦佐恩网络禅宗227/358泰国曼谷Thanon Sanphawut Bang Na 10260
Phone: +66 (0) 87-040-4617
EMail: gwz@net-zen.net
Phone: +66 (0) 87-040-4617
EMail: gwz@net-zen.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Scott Fluhrer Cisco Systems. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
斯科特·弗勒思科系统公司。美国马萨诸塞州博克斯伯勒马萨诸塞大道1414号，邮编01719
EMail: sfluhrer@cisco.com
EMail: sfluhrer@cisco.com