Network Working Group F. Bersani
Request for Comments: 4764 France Telecom R&D
Category: Experimental H. Tschofenig
Siemens Networks GmbH & Co KG
January 2007
Network Working Group F. Bersani
Request for Comments: 4764 France Telecom R&D
Category: Experimental H. Tschofenig
Siemens Networks GmbH & Co KG
January 2007
The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method
EAP-PSK协议：一种预共享密钥可扩展认证协议（EAP）方法
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
The IESG thinks that this work is related to IETF work done in WGs EMU and EAP, but this does not prevent publishing.
IESG认为这项工作与在WGs EMU和EAP中完成的IETF工作有关，但这并不妨碍发布。
Abstract
摘要
This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.
本文档指定了EAP-PSK，这是一种可扩展身份验证协议（EAP）方法，用于使用预共享密钥（PSK）进行相互身份验证和会话密钥派生。EAP-PSK在双方成功通过相互身份验证进行通信时提供受保护的通信信道。本文档描述了该通道仅用于结果指示的受保护交换，但未来的EAP-PSK扩展可能会将该通道用于其他目的。EAP-PSK设计用于在不安全网络（如IEEE 802.11）上进行身份验证。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Design Goals for EAP-PSK ...................................4
1.1.1. Simplicity ..........................................4
1.1.2. Wide Applicability ..................................5
1.1.3. Security ............................................5
1.1.4. Extensibility .......................................5
1.2. Terminology ................................................5
1.3. Conventions ................................................8
1.4. Related Work ...............................................9
2. Protocol Overview ..............................................12
2.1. EAP-PSK Key Hierarchy .....................................13
2.1.1. The PSK ............................................13
2.1.2. AK .................................................14
2.1.3. KDK ................................................14
2.2. The TEK ...................................................15
2.3. The MSK ...................................................15
2.4. The EMSK ..................................................15
2.5. The IV ....................................................15
3. Cryptographic Design of EAP-PSK ................................15
3.1. The Key Setup .............................................16
3.2. The Authenticated Key Exchange ............................19
3.3. The Protected Channel .....................................23
4. EAP-PSK Message Flows ..........................................25
4.1. EAP-PSK Standard Authentication ...........................26
4.2. EAP-PSK Extended Authentication ...........................28
5. EAP-PSK Message Format .........................................31
5.1. EAP-PSK First Message .....................................32
5.2. EAP-PSK Second Message ....................................34
5.3. EAP-PSK Third Message .....................................36
5.4. EAP-PSK Fourth Message ....................................39
6. Rules of Operation for the EAP-PSK Protected Channel ...........41
6.1. Protected Result Indications ..............................41
6.1.1. CONT ...............................................42
6.1.2. DONE_SUCCESS .......................................43
6.1.3. DONE_FAILURE .......................................43
6.2. Extended Authentication ...................................43
7. IANA Considerations ............................................45
7.1. Allocation of an EAP-Request/Response Type for EAP-PSK ....45
7.2. Allocation of EXT Type Numbers ............................45
8. Security Considerations ........................................46
8.1. Mutual Authentication .....................................46
8.2. Protected Result Indications ..............................47
8.3. Integrity Protection ......................................48
8.4. Replay Protection .........................................48
8.5. Reflection Attacks ........................................48
8.6. Dictionary Attacks ........................................49
1. Introduction ....................................................4
1.1. Design Goals for EAP-PSK ...................................4
1.1.1. Simplicity ..........................................4
1.1.2. Wide Applicability ..................................5
1.1.3. Security ............................................5
1.1.4. Extensibility .......................................5
1.2. Terminology ................................................5
1.3. Conventions ................................................8
1.4. Related Work ...............................................9
2. Protocol Overview ..............................................12
2.1. EAP-PSK Key Hierarchy .....................................13
2.1.1. The PSK ............................................13
2.1.2. AK .................................................14
2.1.3. KDK ................................................14
2.2. The TEK ...................................................15
2.3. The MSK ...................................................15
2.4. The EMSK ..................................................15
2.5. The IV ....................................................15
3. Cryptographic Design of EAP-PSK ................................15
3.1. The Key Setup .............................................16
3.2. The Authenticated Key Exchange ............................19
3.3. The Protected Channel .....................................23
4. EAP-PSK Message Flows ..........................................25
4.1. EAP-PSK Standard Authentication ...........................26
4.2. EAP-PSK Extended Authentication ...........................28
5. EAP-PSK Message Format .........................................31
5.1. EAP-PSK First Message .....................................32
5.2. EAP-PSK Second Message ....................................34
5.3. EAP-PSK Third Message .....................................36
5.4. EAP-PSK Fourth Message ....................................39
6. Rules of Operation for the EAP-PSK Protected Channel ...........41
6.1. Protected Result Indications ..............................41
6.1.1. CONT ...............................................42
6.1.2. DONE_SUCCESS .......................................43
6.1.3. DONE_FAILURE .......................................43
6.2. Extended Authentication ...................................43
7. IANA Considerations ............................................45
7.1. Allocation of an EAP-Request/Response Type for EAP-PSK ....45
7.2. Allocation of EXT Type Numbers ............................45
8. Security Considerations ........................................46
8.1. Mutual Authentication .....................................46
8.2. Protected Result Indications ..............................47
8.3. Integrity Protection ......................................48
8.4. Replay Protection .........................................48
8.5. Reflection Attacks ........................................48
8.6. Dictionary Attacks ........................................49
8.7. Key Derivation ............................................49
8.8. Denial-of-Service Resistance ..............................51
8.9. Session Independence ......................................51
8.10. Exposition of the PSK ....................................52
8.11. Fragmentation ............................................52
8.12. Channel Binding ..........................................53
8.13. Fast Reconnect ...........................................53
8.14. Identity Protection ......................................53
8.15. Protected Ciphersuite Negotiation ........................55
8.16. Confidentiality ..........................................55
8.17. Cryptographic Binding ....................................55
8.18. Implementation of EAP-PSK ................................55
9. Security Claims ................................................56
10. Acknowledgments ...............................................57
11. References ....................................................57
11.1. Normative References .....................................57
11.2. Informative References ...................................58
Appendix A. Generation of the PSK from a Password - Discouraged ...62
8.7. Key Derivation ............................................49
8.8. Denial-of-Service Resistance ..............................51
8.9. Session Independence ......................................51
8.10. Exposition of the PSK ....................................52
8.11. Fragmentation ............................................52
8.12. Channel Binding ..........................................53
8.13. Fast Reconnect ...........................................53
8.14. Identity Protection ......................................53
8.15. Protected Ciphersuite Negotiation ........................55
8.16. Confidentiality ..........................................55
8.17. Cryptographic Binding ....................................55
8.18. Implementation of EAP-PSK ................................55
9. Security Claims ................................................56
10. Acknowledgments ...............................................57
11. References ....................................................57
11.1. Normative References .....................................57
11.2. Informative References ...................................58
Appendix A. Generation of the PSK from a Password - Discouraged ...62
The Extensible Authentication Protocol (EAP) [3] provides an authentication framework that supports multiple authentication methods.
可扩展身份验证协议（EAP）[3]提供了支持多种身份验证方法的身份验证框架。
This document specifies an EAP method, called EAP-PSK, that uses a Pre-Shared Key (PSK).
本文档指定了一种称为EAP-PSK的EAP方法，该方法使用预共享密钥（PSK）。
EAP-PSK was developed at France Telecom R&D in 2003-2004. It is published as an RFC for the general information of the Internet community and to allow independent implementations.
EAP-PSK于2003-2004年由法国电信研发部开发。它作为RFC发布，用于互联网社区的一般信息，并允许独立实施。
Because PSKs are of frequent use in security protocols, other protocols may also refer to a PSK or contain this word in their name. For instance, Wi-Fi Protected Access (WPA) [48] specifies an authentication mode called "WPA-PSK". EAP-PSK is distinct from these protocols and should not be confused with them.
由于PSK在安全协议中经常使用，其他协议也可能引用PSK或在其名称中包含此词。例如，Wi-Fi保护访问（WPA）[48]指定了一种称为“WPA-PSK”的身份验证模式。EAP-PSK与这些协议不同，不应与它们混淆。
Design goals for EAP-PSK were:
EAP-PSK的设计目标为：
o Simplicity: EAP-PSK should be easy to implement and deploy without any pre-existing infrastructure. It should be available quickly because recently-released protocols, such as IEEE 802.11i [27], employ EAP in a different threat model than PPP [44] and thus require "modern" EAP methods.
o 简单性：EAP-PSK应易于实施和部署，无需任何预先存在的基础架构。它应该可以很快获得，因为最近发布的协议，如IEEE 802.11i[27]，在不同于PPP[44]的威胁模型中使用EAP，因此需要“现代”EAP方法。
o Wide applicability: EAP-PSK should be suitable to authenticate over any network, and in particular over IEEE 802.11 [28] wireless LANs.
o 广泛适用性：EAP-PSK应适用于在任何网络上进行身份验证，特别是在IEEE 802.11[28]无线局域网上。
o Security: EAP-PSK should be conservative in its cryptographic design.
o 安全性：EAP-PSK的密码设计应保守。
o Extensibility: EAP-PSK should be easily extensible.
o 可扩展性：EAP-PSK应该易于扩展。
For the sake of simplicity, EAP-PSK relies on a single cryptographic primitive, AES-128 [7].
为了简单起见，EAP-PSK依赖于单个加密原语AES-128[7]。
Restriction to such a primitive, and in particular, not using asymmetric cryptography like Diffie-Hellman key exchange, makes EAP-PSK:
对此类原语的限制，尤其是不使用Diffie-Hellman密钥交换等非对称加密，使得EAP-PSK：
o Easy to understand and implement while avoiding cryptographic negotiations.
o 易于理解和实现，同时避免加密协商。
o Lightweight and well suited for any type of device, especially those with little processing power and memory.
o 重量轻，非常适合任何类型的设备，尤其是那些处理能力和内存很少的设备。
However, as further discussed in Section 8, this prevents EAP-PSK from offering advanced features such as identity protection, password support, or Perfect Forward Secrecy (PFS). This choice has been deliberately made as a trade-off between simplicity and security.
但是，如第8节中进一步讨论的，这会阻止EAP-PSK提供身份保护、密码支持或完美前向保密（PFS）等高级功能。这种选择是为了在简单性和安全性之间进行权衡。
For the sake of simplicity, EAP-PSK has also chosen a fixed message format and not a Type-Length-Value (TLV) design.
为了简单起见，EAP-PSK还选择了固定的消息格式，而不是类型长度值（TLV）设计。
EAP-PSK has been designed in a threat model where the attacker has full control over the communication channel. This is the EAP threat model that is presented in Section 7.1 of [3].
EAP-PSK是在威胁模型中设计的，攻击者可以完全控制通信通道。这是[3]第7.1节中介绍的EAP威胁模型。
Since the design of authenticated key exchange is notoriously known to be hard and error prone, EAP-PSK tries to avoid inventing any new cryptographic mechanism. It attempts instead to build on existing primitives and protocols that have been reviewed by the cryptographic community.
由于众所周知，经过身份验证的密钥交换的设计很难且容易出错，EAP-PSK试图避免发明任何新的加密机制。相反，它试图建立在加密社区已经审查过的现有原语和协议的基础上。
EAP-PSK explicitly provides a mechanism to allow future extensions within its protected channel (see Section 3.3). Thanks to this mechanism, EAP-PSK will be able to provide more sophisticated services as the need to do so arises.
EAP-PSK明确提供了一种机制，允许在其受保护通道内进行未来扩展（见第3.3节）。由于这种机制，EAP-PSK将能够在需要时提供更复杂的服务。
Authentication, Authorization, and Accounting (AAA) Please refer to [10] for more details.
认证、授权和记帐（AAA）有关更多详细信息，请参阅[10]。
AES-128 A block cipher specified in the Advanced Encryption Standard [7].
AES-128高级加密标准[7]中规定的分组密码。
Authentication Key (AK) A 16-byte key derived from the PSK that the EAP peer and server use to mutually authenticate.
认证密钥（AK）：从PSK派生的16字节密钥，EAP对等方和服务器使用该密钥进行相互认证。
AKEP2 An authenticated key exchange protocol; please refer to [14] for more details.
AKEP2是一种经过认证的密钥交换协议；有关更多详细信息，请参阅[14]。
Backend Authentication Server An entity that provides an authentication service to an Authenticator. When used, this server typically executes EAP methods for the Authenticator. (This terminology is also used in [26], and has the same meaning in this document.)
后端身份验证服务器向身份验证程序提供身份验证服务的实体。使用时，此服务器通常为身份验证程序执行EAP方法。（该术语也在[26]中使用，在本文件中具有相同的含义。）
CMAC Cipher-based Message Authentication Code. It is the authentication mode of operation of AES recommended by NIST in [8].
基于CMAC密码的消息认证码。这是NIST在[8]中推荐的AES操作认证模式。
Extensible Authentication Protocol (EAP) Defined in [3].
[3]中定义的可扩展身份验证协议（EAP）。
EAP Authenticator (or simply Authenticator) The end of the EAP link initiating the EAP authentication methods. (This terminology is also used in [26], and has the same meaning in this document.)
EAP认证器（或简称认证器）启动EAP认证方法的EAP链路的末端。（该术语也在[26]中使用，在本文件中具有相同的含义。）
EAP peer (or simply peer) The end of the EAP link that responds to the Authenticator. (In [26], this end is known as the Supplicant.)
EAP对等（或简单对等）响应身份验证程序的EAP链路的末端。（在[26]中，这一端被称为恳求者。）
EAP server (or simply server) The entity that terminates the EAP authentication with the peer. When there is no Backend Authentication Server, this term refers to the EAP Authenticator. Where the EAP Authenticator operates in pass-through mode, it refers to the Backend Authentication Server.
EAP服务器（或简称服务器）终止与对等方的EAP身份验证的实体。当没有后端身份验证服务器时，该术语指的是EAP身份验证程序。当EAP认证器以直通模式运行时，它指的是后端认证服务器。
EAX An authenticated-encryption with associated data mode of operation for block ciphers [4].
EAX一种具有分组密码相关数据操作模式的认证加密[4]。
Extended Master Session Key (EMSK) Additional keying material derived between the EAP peer and server that is exported by the EAP method. The EMSK is reserved for future uses that are not defined yet and is not provided to a third party. Please refer to [9] for more details. EAP-PSK generates a 64-byte EMSK.
扩展主会话密钥（EMSK）：在EAP对等方和服务器之间派生的、通过EAP方法导出的附加密钥材料。EMSK保留用于尚未定义且未提供给第三方的未来用途。有关更多详细信息，请参阅[9]。EAP-PSK生成一个64字节的EMSK。
Initialization Vector (IV) A quantity of at least 64 bytes, suitable for use in an initialization vector field, that is derived between the peer and EAP server. Since the IV is a known value in
初始化向量（IV）在对等服务器和EAP服务器之间导出的至少64字节的量，适合在初始化向量字段中使用。因为IV是一个已知的
methods such as EAP-TLS [11], it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and EAP methods are not required to generate it. Please refer to [9] for more details. EAP-PSK does not generate an IV.
EAP-TLS等方法[11]本身不能用于计算需要保密的任何数量。因此，它的使用已被弃用，并且不需要EAP方法来生成它。有关更多详细信息，请参阅[9]。EAP-PSK不生成IV。
Key-Derivation Key (KDK) A 16-byte key derived from the PSK that the EAP peer and server use to derive session keys (namely, the TEK, MSK, and EMSK).
密钥派生密钥（KDK）：从PSK派生的16字节密钥，EAP对等方和服务器使用该密钥派生会话密钥（即TEK、MSK和EMSK）。
Message Authentication Code (MAC) Informally, the purpose of a MAC is to provide assurances regarding both the source of a message and its integrity [40]. IEEE 802.11i uses the acronym MIC (Message Integrity Check) to avoid confusion with the other meaning of the acronym MAC (Medium Access Control).
消息认证码（MAC）非正式地说，MAC的目的是提供关于消息源及其完整性的保证[40]。IEEE 802.11i使用缩写词MIC（消息完整性检查），以避免与缩写词MAC（媒体访问控制）的其他含义混淆。
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. In existing implementations, a AAA server acting as an EAP server transports the MSK to the Authenticator [9]. EAP-PSK generates a 64-byte MSK.
主会话密钥（MSK）是在EAP对等方和服务器之间派生并通过EAP方法导出的密钥材料。在现有实现中，充当EAP服务器的AAA服务器将MSK传输到验证器[9]。EAP-PSK生成一个64字节的MSK。
Network Access Identifier (NAI) Identifier used to identify the communicating parties [2].
网络访问标识符（NAI）用于标识通信方的标识符[2]。
One Key CBC-MAC 1 (OMAC1) A method to generate a Message Authentication Code [29]. CMAC is the name under which NIST has standardized OMAC1.
一键CBC-MAC 1（OMAC1）生成消息认证码的方法[29]。CMAC是NIST标准化OMAC1的名称。
Perfect Forward Secrecy (PFS) The confidence that the compromise of a long-term private key does not compromise any earlier session keys. In other words, once an EAP dialog is finished and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the peer and the server cannot reconstruct the keys used to protect the conversation without doing a brute-force search of the session key space.
完美前向保密（PFS）长期私钥泄露不会泄露任何早期会话密钥的信心。换句话说，一旦EAP对话完成并且忘记了相应的密钥，即使是记录了连接中的所有数据并访问了对等方和服务器的所有长期密钥的人，如果不对会话密钥空间进行强制搜索，也无法重构用于保护对话的密钥。
EAP-PSK does not have this property.
EAP-PSK不具有此属性。
Pre-Shared Key (PSK) A Pre-Shared Key simply means a key in symmetric cryptography. This key is derived by some prior mechanism and shared between the parties before the protocol using it takes place. It is merely a bit sequence of given length, each bit of which has been chosen at random uniformly and independently. For EAP-PSK, the PSK is the long-term 16- byte credential shared by the EAP peer and server.
预共享密钥（PSK）预共享密钥仅指对称密码中的密钥。这个密钥是由一些先前的机制派生出来的，并在使用它的协议发生之前在双方之间共享。它仅仅是一个给定长度的位序列，其中的每一位都是均匀地、独立地随机选择的。对于EAP-PSK，PSK是EAP对等方和服务器共享的长期16字节凭证。
Protected Result Indication Please refer to Section 7.16 of [3] for a definition of this term. This feature has been introduced because EAP-Success/Failure packets are unidirectional and are not protected.
受保护结果指示有关该术语的定义，请参考[3]第7.16节。引入此功能是因为EAP成功/失败数据包是单向的且不受保护。
Transient EAP Key (TEK) A session key that is used to establish a protected channel between the EAP peer and server during the EAP authentication exchange. The TEK is appropriate for use with the ciphersuite negotiated between the EAP peer and server to protect the EAP conversation. Note that the ciphersuite used to set up the protected channel between the EAP peer and server during EAP authentication is unrelated to the ciphersuite used to subsequently protect data sent between the EAP peer and Authenticator [9]. EAP-PSK uses a 16-byte TEK for its protected channel, which is the only ciphersuite available between the EAP peer and server to protect the EAP conversation. This ciphersuite uses AES-128 in the EAX mode of operation.
瞬态EAP密钥（TEK）：在EAP身份验证交换期间，用于在EAP对等方和服务器之间建立受保护通道的会话密钥。TEK适合与EAP对等方和服务器之间协商的密码套件一起使用，以保护EAP对话。请注意，在EAP身份验证期间用于在EAP对等方和服务器之间设置受保护通道的密码套件与随后用于保护EAP对等方和身份验证方之间发送的数据的密码套件无关[9]。EAP-PSK使用16字节TEK作为其受保护通道，这是EAP对等方和服务器之间唯一可用于保护EAP会话的密码套件。此密码套件在EAX操作模式下使用AES-128。
All numbers presented in this document are considered in network-byte order.
本文件中的所有数字均按网络字节顺序考虑。
|| denotes concatenation of strings (and not the logical OR).
||表示字符串的串联（而不是逻辑OR）。
MAC(K, String) denotes the MAC of String under the key K (the algorithm used in this document to compute the MACs is CMAC with AES-128; see Section 3.2).
MAC（K，String）表示密钥K下字符串的MAC（本文档中用于计算MAC的算法是带有AES-128的CMAC；参见第3.2节）。
[String] denotes the concatenation of String with the MAC of String calculated as specified by the context. Hence, we have, with K specified by the context: [String]=String||MAC(K,String)
[String]表示字符串与上下文指定的字符串MAC的连接。因此，我们有，由上下文指定的K:[String]=String | | MAC（K，String）
** denotes integer exponentiation.
**表示整数幂运算。
"i" denotes the unsigned binary representation on 16 bytes of the integer i in network byte order. Therefore, this notation only makes sense when i is between 0 and 2**128-1.
“i”表示整数i的16个字节（按网络字节顺序）上的无符号二进制表示。因此，只有当i介于0和2**128-1之间时，此符号才有意义。
<i> denotes the unsigned binary representation on 4 bytes of the integer i in network byte order. Therefore, this notation only makes sense when i is between 0 and 2**32-1.
<i> 以网络字节顺序表示整数i的4个字节上的无符号二进制表示。因此，只有当i介于0和2**32-1之间时，此符号才有意义。
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
At the time this document is written, only three EAP methods are standards track EAP methods per IETF terminology (see [17]), namely:
在编写本文件时，根据IETF术语（见[17]），只有三种EAP方法是标准跟踪EAP方法，即：
o MD5-Challenge (EAP-Request/Response type 4), defined in [3], which uses a MD5 challenge similar to [45].
o [3]中定义的MD5质询（EAP请求/响应类型4），它使用类似于[45]的MD5质询。
o OTP (EAP-Request/Response type 5), defined in [3], which aims at providing One-Time Password support similar to [22] and [39].
o OTP（EAP请求/响应类型5），定义于[3]，旨在提供类似于[22]和[39]的一次性密码支持。
o GTC (EAP-Request/Response type 6), defined in [3], which aims at providing Generic Token Card Support.
o [3]中定义的GTC（EAP请求/响应类型6），旨在提供通用令牌卡支持。
Unfortunately, all three methods are deprecated for security reasons that are explained in part in [3].
不幸的是，由于[3]中部分解释的安全原因，这三种方法都被弃用。
Myriads of EAP methods have, however, been otherwise proposed:
然而，另有无数EAP方法被提出：
o One as an experimental RFC (EAP-TLS [11]), which therefore is not a standard (see [25]).
o 一个作为实验RFC（EAP-TLS[11]），因此不是标准（见[25]）。
o Some as individual Internet-Draft submissions (e.g., [42] or this document).
o 一些作为个人互联网草案提交（例如，[42]或本文件）。
o And some even undocumented (e.g., Rob EAP, which has EAP-Request/ Response type 31).
o 还有一些甚至没有记录（例如Rob EAP，其EAP请求/响应类型为31）。
However, no secure and mature Pre-Shared Key EAP method is yet easily and widely available, which is all the more regrettable because Pre-Shared Key methods are the most basic ones!
然而，目前还没有一种安全、成熟的预共享密钥EAP方法可以轻松、广泛地使用，这更令人遗憾，因为预共享密钥方法是最基本的方法！
The existing proposals for a future Pre-Shared Key EAP method are briefly reviewed hereafter (please refer to [16] for a more thorough synthesis of EAP methods).
下文简要回顾了未来预共享密钥EAP方法的现有建议（请参考[16]了解EAP方法的更全面综合）。
Among these proposals, there are some that:
在这些建议中，有一些是：
o Are broken from a security point of view, e.g.:
o 从安全角度来看是不可靠的，例如：
* LEAP, which is specified in [38] and whose vulnerabilities are discussed in [49].
* [38]中规定的LEAP，其漏洞在[49]中讨论。
* EAP-MSCHAPv2, which is specified in [34] and whose vulnerabilities are indirectly discussed in [43].
* EAP-MSCHAPv2，在[34]中指定，其漏洞在[43]中间接讨论。
o Essentially require additional infrastructure, e.g., EAP-SIM [24], EAP-AKA [12], or OTP/token card methods like [31].
o 基本上需要额外的基础设施，例如EAP-SIM[24]、EAP-AKA[12]或OTP/令牌卡方法，如[31]。
o Are not shared key methods but are often confused with them, namely, the password methods, e.g., EAP-SRP [18] or SPEKE [30], whose wide adoption very unfortunately seems to be hindered by Intellectual Property Rights issues.
o 不是共享密钥方法，但经常与之混淆，即密码方法，例如EAP-SRP[18]或SPEKE[30]，其广泛采用似乎很不幸地受到知识产权问题的阻碍。
o Are generic tunneling methods, which do not essentially rely on Pre-Shared Keys as they require a public-key certificate for the server and allow the peer to authenticate with whatever EAP method or even other non-EAP authentication mechanisms, namely, [32] and [21].
o 是通用隧道方法，基本上不依赖预共享密钥，因为它们需要服务器的公钥证书，并允许对等方使用任何EAP方法或甚至其他非EAP身份验证机制进行身份验证，即[32]和[21]。
o Are abandoned but have provided the basis for EAP-PSK, namely, EAP-Archie [47].
o 已放弃，但为EAP-PSK提供了基础，即EAP ARCHE[47]。
o Are possible alternatives to EAP-PSK (i.e., claimed to be secure and subject of active work):
o 是否有EAP-PSK的可能替代品（即，声称安全且主动工作的主体）：
* EAP-FAST [42].
* EAP-FAST[42]。
* EAP-IKEv2 [46].
* EAP-IKEv2[46]。
* EAP-TLS (when shared key/password support is added to TLS; see [50]).
* EAP-TLS（当共享密钥/密码支持添加到TLS时；请参见[50]）。
EAP-PSK differs from the aforementioned methods on the following points:
EAP-PSK在以下几点上与上述方法不同：
o No attacks on EAP-PSK within its threat model have yet been found.
o 尚未发现EAP-PSK在其威胁模型中受到攻击。
o EAP-PSK was not designed to leverage a pre-existing infrastructure. Thus, it does not inherit potential limitations of such an infrastructure and it should be easier to deploy "from scratch".
o EAP-PSK的设计目的不是利用现有的基础设施。因此，它不会继承这样一个基础设施的潜在限制，而且应该更容易“从头开始”部署。
o EAP-PSK wished to avoid IPR blockages.
o EAP-PSK希望避免知识产权封锁。
o EAP-PSK does not have any dependencies on protocols other than EAP.
o EAP-PSK对EAP以外的协议没有任何依赖关系。
o EAP-PSK was restricted to simply proposing a Pre-Shared Key method with symmetric cryptography
o EAP-PSK仅限于提出一种具有对称密码的预共享密钥方法
* To remain simple to understand and implement
* 保持简单易懂和易于实施
* To avoid potentially complex configurations and negotiations
* 避免潜在的复杂配置和协商
o EAP-PSK was designed with efficiency in mind.
o EAP-PSK的设计考虑了效率。
Figure 1 presents an overview of the EAP-PSK key hierarchy.
图1概述了EAP-PSK密钥层次结构。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^
| EAP-PSK Protocol: a Pre-Shared Key EAP Method | |
| | |
| +----------+ | |
| | PSK | | |
| |(16 bytes)| | |
| +----------+ | |
| | | |
| v | |
| *********************** | |
| *Modified Counter Mode* | |
| *********************** | |
| | | | |
| v v | |
| +----------+ +----------+ +----------------+ | |
| | AK | | KDK | | RAND_P | | |
| |(16 bytes)| |(16 bytes)| | (16 bytes) | | |
| +----------+ +----------+ +----------------+ | |
| | | | |
| | | | |
| +-----------+ | | | |
| +--------+|Plain Text | | | | |
|+-------+|Header H||Var.Length | | | | |
||Nonce N||22 bytes|+-----------+ v v Local |
||4 bytes|+--------+ | *********************** to EAP |
|+-------+ | +--------+ +------*Modified Counter Mode* Method |
| | v v v *********************** | |
| | ******* +--------+ |64 |64 | |
| | * EAX *-------|TEK | |bytes |bytes | |
| +-->******* |16 bytes| | | | |
| | +--------+ | | | |
| +-----+----+ | | | |
| v v | | | |
|+--------+ +-------------------+ | | | |
||Tag | |Cipher Text Payload| | | | |
||16 bytes| | Variable length L | | | | |
|+--------+ +-------------------+ | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^
+-+-+-+-+-++ +-+-+-+-+-++ |
|MSK | |EMSK | |
| | | | Exported |
+-+-+-+-+-++ +-+-+-+-+-++ by EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^
| EAP-PSK Protocol: a Pre-Shared Key EAP Method | |
| | |
| +----------+ | |
| | PSK | | |
| |(16 bytes)| | |
| +----------+ | |
| | | |
| v | |
| *********************** | |
| *Modified Counter Mode* | |
| *********************** | |
| | | | |
| v v | |
| +----------+ +----------+ +----------------+ | |
| | AK | | KDK | | RAND_P | | |
| |(16 bytes)| |(16 bytes)| | (16 bytes) | | |
| +----------+ +----------+ +----------------+ | |
| | | | |
| | | | |
| +-----------+ | | | |
| +--------+|Plain Text | | | | |
|+-------+|Header H||Var.Length | | | | |
||Nonce N||22 bytes|+-----------+ v v Local |
||4 bytes|+--------+ | *********************** to EAP |
|+-------+ | +--------+ +------*Modified Counter Mode* Method |
| | v v v *********************** | |
| | ******* +--------+ |64 |64 | |
| | * EAX *-------|TEK | |bytes |bytes | |
| +-->******* |16 bytes| | | | |
| | +--------+ | | | |
| +-----+----+ | | | |
| v v | | | |
|+--------+ +-------------------+ | | | |
||Tag | |Cipher Text Payload| | | | |
||16 bytes| | Variable length L | | | | |
|+--------+ +-------------------+ | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^
+-+-+-+-+-++ +-+-+-+-+-++ |
|MSK | |EMSK | |
| | | | Exported |
+-+-+-+-+-++ +-+-+-+-+-++ by EAP |
| | Method |
| | |
V V |
************************* V
* AAA Key Derivation * ---+
* Naming & Binding *
*************************
| | Method |
| | |
V V |
************************* V
* AAA Key Derivation * ---+
* Naming & Binding *
*************************
Figure 1: EAP-PSK Key Hierarchy Overview
图1:EAP-PSK密钥层次结构概述
This section presents the key hierarchy used by EAP-PSK. This hierarchy is inspired by the EAP key hierarchy described in [9].
本节介绍EAP-PSK使用的密钥层次结构。该层次结构受[9]中描述的EAP密钥层次结构的启发。
The PSK is shared between the EAP peer and the EAP server.
PSK在EAP对等方和EAP服务器之间共享。
EAP-PSK assumes that the PSK is known only to the EAP peer and EAP server. The security properties of the protocol are compromised if it has wider distribution. Please note that EAP-PSK shares this property with all other symmetric key methods (including all password-based methods).
EAP-PSK假定PSK仅为EAP对等方和EAP服务器所知。如果协议具有更广泛的分布，则其安全属性会受到损害。请注意，EAP-PSK与所有其他对称密钥方法（包括所有基于密码的方法）共享此属性。
EAP-PSK also assumes the EAP server and EAP peer identify the correct PSK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI.
EAP-PSK还假设EAP服务器和EAP对等方通过各自的NAI识别正确的PSK以相互使用。这意味着，在使用给定服务器NAI的EAP服务器和使用给定对等NAI的EAP对等方之间，最多只能共享一个PSK。
This PSK is used, as shown in Figure 2, to derive two 16-byte static long-lived subkeys, respectively called the Authentication Key (AK) and the Key-Derivation Key (KDK). This derivation should only be done once: it is called the key setup. See Section 3.1 for an explanation of why PSK is not used as a static long-lived key, but only as the initial keying material for deriving the static long-lived keys, AK and KDK, which are actually used by the protocol EAP-PSK.
如图2所示，此PSK用于派生两个16字节的静态长寿命子密钥，分别称为身份验证密钥（AK）和密钥派生密钥（KDK）。此派生只能执行一次：称为密钥设置。请参见第3.1节，了解为什么PSK不用作静态长寿命密钥，而仅用作派生静态长寿命密钥AK和KDK的初始密钥材料，协议EAP-PSK实际使用这些密钥。
+---------------------------+
| PSK |
| (16 bytes) |
+---------------------------+
| |
v v
+---------------------------+ +---------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+---------------------------+ +---------------------------+
+---------------------------+
| PSK |
| (16 bytes) |
+---------------------------+
| |
v v
+---------------------------+ +---------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+---------------------------+ +---------------------------+
Figure 2: Derivation of AK and KDK from the PSK
图2：从PSK推导AK和KDK
EAP-PSK uses AK to mutually authenticate the EAP peer and the EAP server.
EAP-PSK使用AK相互验证EAP对等方和EAP服务器。
AK is a static long-lived key derived from the PSK; see Section 3.1. AK is not a session key.
AK是从PSK派生的静态长寿命密钥；见第3.1节。AK不是会话密钥。
The EAP server and EAP peer identify the correct AK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one AK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This is the case when there is at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI; see Section 2.1.1.
EAP服务器和EAP对等机通过各自的NAI确定要相互使用的正确AK。这意味着使用给定服务器NAI的EAP服务器和使用给定对等NAI的EAP对等方之间最多只能共享一个AK。这是在使用给定服务器NAI的EAP服务器和使用给定对等NAI的EAP对等之间共享最多一个PSK的情况；见第2.1节。
The EAP peer chooses the AK to use based on the EAP server NAI that has been sent by the EAP server in the first EAP-PSK message (namely, ID_S; see Section 4.1) and the EAP peer NAI it chooses to include in the second EAP-PSK message (namely, ID_P; see Section 4.1).
EAP对等方根据EAP服务器在第一条EAP-PSK消息中发送的EAP服务器NAI（即，ID_S；参见第4.1节）和它选择包含在第二条EAP-PSK消息中的EAP对等方NAI（即，ID_P；参见第4.1节）来选择要使用的AK。
EAP-PSK uses KDK to derive session keys shared by the EAP peer and the EAP server (namely, the TEK, MSK, and EMSK).
EAP-PSK使用KDK派生EAP对等方和EAP服务器（即TEK、MSK和EMSK）共享的会话密钥。
KDK is a static long-lived key derived from the PSK; see Section 3.1. KDK is not a session key.
KDK是从PSK派生的静态长寿命密钥；见第3.1节。KDK不是会话密钥。
The EAP server and EAP peer identify the correct AK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one AK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This is the case
EAP服务器和EAP对等机通过各自的NAI确定要相互使用的正确AK。这意味着使用给定服务器NAI的EAP服务器和使用给定对等NAI的EAP对等方之间最多只能共享一个AK。情况就是这样
when there is at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI; see Section 2.1.1.
当使用给定服务器NAI的EAP服务器和使用给定对等NAI的EAP对等方之间最多共享一个PSK时；见第2.1节。
The EAP peer chooses the AK to use based on the EAP server NAI that has been sent by the EAP server in the first EAP-PSK message (namely, ID_S; see Section 4.1) and the EAP peer NAI it chooses to include in the second EAP-PSK message (namely, ID_P; see Section 4.1).
EAP对等方根据EAP服务器在第一条EAP-PSK消息中发送的EAP服务器NAI（即，ID_S；参见第4.1节）和它选择包含在第二条EAP-PSK消息中的EAP对等方NAI（即，ID_P；参见第4.1节）来选择要使用的AK。
EAP-PSK derives a 16-byte TEK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and KDK.
EAP-PSK通过在身份验证（RAND_P；见第5.1节）和KDK期间交换的随机数派生出一个16字节的TEK。
This TEK is used to implement a protected channel for both mutually authenticated parties to communicate over securely.
该TEK用于为相互认证的双方实现一个受保护的通道，以便安全地进行通信。
EAP-PSK derives a MSK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and the KDK.
EAP-PSK通过身份验证过程中交换的随机数（RAND_P；见第5.1节）和KDK派生MSK。
The MSK is 64 bytes long, which complies with [3].
MSK的长度为64字节，符合[3]。
EAP-PSK derives an EMSK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and the KDK.
EAP-PSK通过身份验证过程中交换的随机数（RAND_P；见第5.1节）和KDK来获得EMSK。
The EMSK is 64 bytes long, which complies with [3].
EMSK的长度为64字节，符合[3]。
EAP-PSK does not derive any IV, which complies with [9].
EAP-PSK不衍生任何符合[9]的IV。
EAP-PSK relies on a single cryptographic primitive, a block cipher, which is instantiated with AES-128. AES-128 takes a 16-byte Pre-Shared Key and a 16-byte Plain Text block as inputs. It outputs a 16-byte Cipher Text block. For a detailed description of AES-128, please refer to [7].
EAP-PSK依赖于一个加密原语，即分组密码，该原语由AES-128实例化。AES-128采用16字节预共享密钥和16字节纯文本块作为输入。它输出一个16字节的密码文本块。有关AES-128的详细说明，请参阅[7]。
AES-128 has been chosen because:
选择AES-128是因为：
o It is standardized and implementations are widely available.
o 它是标准化的，并且可以广泛使用。
o It has been carefully reviewed by the cryptographic community and is believed to be secure.
o 加密社区已经仔细审查了它，并认为它是安全的。
Other block ciphers could easily be proposed for EAP-PSK, as EAP-PSK does not intrinsically depend on AES-128. The only parameters of AES-128 that EAP-PSK depends on are the AES-128 block and key size (16 bytes). For the sake of simplicity, EAP-PSK has, however, been chosen to restrict to a single mandatory block cipher and not allow the negotiation of other block ciphers. In the case that AES-128 is deprecated for security reasons, EAP-PSK should also be deprecated and a cut-and-paste EAP-PSK' should be defined with another block cipher. This EAP-PSK' should not be backward compatible with EAP-PSK because of the security issues with AES-128. EAP-PSK' should therefore use a different EAP-Request/Response Type number. With the EAP-Request/Response Type number space structure defined in [3], this should not be a problem. The use of a different EAP-Request/Response Type number for EAP-PSK' will prevent this new method from being vulnerable to chosen protocol attacks.
由于EAP-PSK本质上并不依赖于AES-128，因此可以很容易地为EAP-PSK提出其他分组密码。EAP-PSK依赖的AES-128的唯一参数是AES-128块和密钥大小（16字节）。然而，为了简单起见，EAP-PSK被选择为仅限于一个强制分组密码，而不允许协商其他分组密码。如果出于安全原因不推荐使用AES-128，则也应不推荐使用EAP-PSK，并应使用另一个分组密码定义剪切粘贴EAP-PSK。由于AES-128存在安全问题，此EAP-PSK不应与EAP-PSK向后兼容。因此，“EAP-PSK”应使用不同的EAP请求/响应类型编号。对于[3]中定义的EAP请求/响应类型数字空间结构，这应该不是问题。为EAP-PSK使用不同的EAP请求/响应类型编号将防止此新方法易受所选协议攻击的攻击。
EAP-PSK uses three cryptographic parts:
EAP-PSK使用三个加密部分：
o A key setup to derive AK and KDK from the PSK.
o 从PSK派生AK和KDK的密钥设置。
o An authenticated key exchange protocol to mutually authenticate the communicating parties and derive session keys.
o 一种经过身份验证的密钥交换协议，用于相互验证通信双方并派生会话密钥。
o A protected channel protocol for both mutually authenticated parties to communicate over.
o 一种受保护的信道协议，供相互认证的双方通过网络进行通信。
Each part is discussed in more detail in the subsequent paragraphs.
每个部分将在后面的段落中进行更详细的讨论。
EAP-PSK needs two cryptographically separated 16-byte subkeys for mutual authentication and session key derivation. Indeed, it is a rule of thumb in cryptography to use different keys for different applications.
EAP-PSK需要两个加密分隔的16字节子密钥，用于相互身份验证和会话密钥派生。事实上，密码学的经验法则是为不同的应用程序使用不同的密钥。
It could have implemented these two subkeys either by specifying a 32-byte PSK that would then be split in two 16-byte subkeys, or by specifying a 16-byte PSK that would then be cryptographically expanded to two 16-byte subkeys.
它可以通过指定一个32字节的PSK来实现这两个子键，然后将其拆分为两个16字节的子键，或者通过指定一个16字节的PSK，然后将其加密扩展为两个16字节的子键。
Because provisioning a 32-byte long-term credential is more cumbersome than a 16-byte one, and the strength of the derived session keys is 16 bytes either way, the latter option was chosen.
由于提供32字节的长期凭证比16字节的凭证更麻烦，并且派生会话密钥的强度为16字节，因此选择了后一种选项。
Hence, the PSK is only used by EAP-PSK to derive AK and KDK. This derivation should be done only once, immediately after the PSK has been provisioned. As soon as AK and KDK have been derived, the PSK should be deleted. If the PSK is deleted, it should be done so securely (see, for instance, [19] for guidance on secure deletion of the PSK).
因此，PSK仅由EAP-PSK用于派生AK和KDK。此推导只应在PSK设置后立即执行一次。一旦获得AK和KDK，就应该删除PSK。如果删除了PSK，则应安全地执行（例如，请参阅[19]了解安全删除PSK的指南）。
Derivation of AK and KDK from the PSK is called the key setup:
从PSK派生AK和KDK称为密钥设置：
o The input to the key setup is the PSK.
o 钥匙设置的输入是PSK。
o The outputs of the key setup are AK and KDK.
o 钥匙设置的输出为AK和KDK。
AK and KDK are derived from the PSK using the modified counter mode of operation of AES-128. The modified counter mode is a length increasing function, i.e., it expands one AES-128 input block into a longer t-block output, where t>=2. This mode was chosen for the key setup because it had already been chosen for the derivation of the session keys (see Section 3.2).
AK和KDK是使用AES-128改进的计数器操作模式从PSK派生的。修改后的计数器模式是一种长度增加功能，即，它将一个AES-128输入块扩展为更长的t块输出，其中t>=2。选择该模式进行密钥设置是因为已经选择该模式来导出会话密钥（参见第3.2节）。
The details of the derivation of AK and KDK from the PSK are shown in Figure 3.
图3显示了从PSK派生AK和KDK的详细信息。
+--------------------------+
| "0" |
| Input Block (16 bytes) |
+--------------------------+
|
v
+----------------+
| |
| AES-128(PSK,.) |
| |
+----------------+
|
|
+----------------------------+
| |
v v
+--------+ +---+ +--------+ +---+
| c1="1" |->|XOR| | c2="2" |->|XOR|
|16 bytes| +---+ |16 bytes| +---+
+--------+ | +--------+ |
| |
+----------------+ +----------------+
| | | |
| AES-128(PSK,.) | | AES-128(PSK,.) |
| | | |
+----------------+ +----------------+
| |
| |
v v
+------------------------+ +------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+------------------------+ +------------------------+
+--------------------------+
| "0" |
| Input Block (16 bytes) |
+--------------------------+
|
v
+----------------+
| |
| AES-128(PSK,.) |
| |
+----------------+
|
|
+----------------------------+
| |
v v
+--------+ +---+ +--------+ +---+
| c1="1" |->|XOR| | c2="2" |->|XOR|
|16 bytes| +---+ |16 bytes| +---+
+--------+ | +--------+ |
| |
+----------------+ +----------------+
| | | |
| AES-128(PSK,.) | | AES-128(PSK,.) |
| | | |
+----------------+ +----------------+
| |
| |
v v
+------------------------+ +------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+------------------------+ +------------------------+
Figure 3: Derivation of AK and KDK from the PSK in Details
图3：从PSK中详细推导AK和KDK
The input block is "0". For the sake of simplicity, this input block has been chosen constant: it could have been set to a value depending on the peer and the server (for instance, the XOR of their respective NAIs appropriately truncated or zero-padded), but this did not seem to add much security to the scheme, whereas it added complexity. Any 16-byte constant could have been chosen, as the security is not supposed to depend on the particular value taken by the constant. "0" was arbitrarily chosen.
输入块为“0”。为了简单起见，这个输入块被选择为常量：它可以被设置为一个取决于对等方和服务器的值（例如，它们各自的NAI的XOR被适当地截断或零填充），但这似乎并没有给方案增加太多的安全性，反而增加了复杂性。可以选择任何16字节的常量，因为安全性不应取决于该常量采用的特定值。“0”是任意选择的。
The authentication protocol used by EAP-PSK is inspired by AKEP2, which is described in [14].
EAP-PSK使用的身份验证协议受[14]中描述的AKEP2启发。
AKEP2 consists of a one-and-a-half round-trip exchange, as shown in Figure 4, which is inspired by Figure 5 of [14].
AKEP2由一个半往返交换组成，如图4所示，其灵感来源于[14]中的图5。
Bob Alice
| RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
Bob Alice
| RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
Figure 4: Overview of AKEP2
图4:AKEP2概述
It is also worth noting that [14] focuses on cryptography and not on designing a real-life protocol. Thus, as noted in subsection "Out-Of-Band-Data" of [14], Alice has to send A, its identity, to Bob so that Bob may select the appropriate credential for the sequel to the conversation. This leads to a slightly complemented version of AKEP2 for EAP-PSK as depicted in Figure 5.
还值得注意的是[14]关注的是密码学，而不是设计现实生活中的协议。因此，如[14]小节“带外数据”中所述，Alice必须向Bob发送一个其标识，以便Bob可以为对话的续集选择适当的凭证。这导致了图5中所示的EAP-PSK的AKEP2的稍微补充版本。
Bob Alice
| A||RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
Bob Alice
| A||RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
Figure 5: Overview of AKEP2
图5:AKEP2概述
In AKEP2,
在AKEP2中，
o RA and RB are random numbers chosen respectively by Alice and Bob.
o RA和RB是Alice和Bob分别选择的随机数。
o A and B are Alice's and Bob's respective identities. They allow Alice and Bob to retrieve the key that they have to use to run an authenticated key exchange between each other. They are also included in the protocol for cryptographic reasons.
o A和B是爱丽丝和鲍勃各自的身份。它们允许Alice和Bob检索他们必须使用的密钥，以在彼此之间运行经过身份验证的密钥交换。出于加密原因，它们也包含在协议中。
o The MACs (see Section 1.3 for the notation "[]") are calculated using a dedicated key.
o MAC（符号“[]”见第1.3节）使用专用键计算。
EAP-PSK instantiates this protocol with:
EAP-PSK通过以下方式实例化此协议：
o The server as Alice and the peer as Bob.
o 服务器为Alice，对等方为Bob。
o RA and RB as 16-byte random numbers, using Section 4.1 notations; this means RA=RAND_S and RB=RAND_P.
o RA和RB为16字节随机数，使用第4.1节的符号；这意味着RA=RAND_S和RB=RAND_P。
o A and B as Alice's and Bob's respective NAIs, using Section 4.1 notations; this means A=ID_S and B=ID_P.
o A和B作为Alice和Bob各自的NAI，使用第4.1节的符号；这意味着A=ID_S和B=ID_P。
o The MAC algorithm as CMAC with AES-128 using AK and producing a tag length of 16 bytes.
o MAC算法为CMAC，AES-128使用AK并产生16字节的标记长度。
o The modified counter mode of operation of AES-128 using KDK, to derive session keys as a result of this exchange.
o 使用KDK修改AES-128的计数器操作模式，以作为此交换的结果导出会话密钥。
CMAC was chosen as the MAC algorithm because it is capable of handling arbitrary length messages, and its design is simple. It also enjoys up-to-date review by the cryptographic community, especially using provable security concepts. It has been recommended by the NIST. For a detailed description of CMAC, please refer to [8].
选择CMAC作为MAC算法是因为它能够处理任意长度的消息，并且设计简单。它还受到加密社区的最新审查，特别是使用可证明的安全概念。这是NIST推荐的。有关CMAC的详细说明，请参阅[8]。
In AKEP2, the key exchange is "implicit": the session keys are derived from RB. In EAP-PSK, the session keys are thus derived from RAND_P by using KDK and the modified counter mode of operation of AES-128 described in [5]. This mode was chosen because it is a simple key derivation scheme that relies on a block cipher and has a proof of its security. It is a length increasing function, i.e., it expands one AES-128 input block into a longer t-block output, where t>=2. The derivation of the session keys is shown in Figure 6.
在AKEP2中，密钥交换是“隐式”的：会话密钥来自RB。在EAP-PSK中，会话密钥因此通过使用KDK和[5]中描述的AES-128的修改计数器操作模式从RAND_P中导出。之所以选择这种模式，是因为它是一种简单的密钥派生方案，依赖于分组密码，并且具有安全性证明。它是一个长度增加函数，即，它将一个AES-128输入块扩展为更长的t块输出，其中t>=2。会话密钥的派生如图6所示。
+--------------------------+ +-------------------------------+
| RAND_P | | KDK |
| Input Block (16 bytes) | | Key Derivation Key (16 bytes) |
+--------------------------+ +-------------------------------+
| |
v v
+-----------------------------------------------------------------+
| |
| Modified Counter Mode |
| |
+-----------------------------------------------------------------+
| | |
v v v
+------------+ +----------------------+ +----------------------+
| TEK | | MSK | | EMSK |
| (16 bytes) | | (64 bytes) | | (64 bytes) |
+------------+ +----------------------+ +----------------------+
+--------------------------+ +-------------------------------+
| RAND_P | | KDK |
| Input Block (16 bytes) | | Key Derivation Key (16 bytes) |
+--------------------------+ +-------------------------------+
| |
v v
+-----------------------------------------------------------------+
| |
| Modified Counter Mode |
| |
+-----------------------------------------------------------------+
| | |
v v v
+------------+ +----------------------+ +----------------------+
| TEK | | MSK | | EMSK |
| (16 bytes) | | (64 bytes) | | (64 bytes) |
+------------+ +----------------------+ +----------------------+
Figure 6: Derivation of the Session Keys
图6：会话密钥的推导
The input to the derivation of the session keys is RAND_P.
会话密钥派生的输入是RAND\u P。
The outputs of the derivation of the session keys are:
会话密钥派生的输出为：
o The 16-byte TEK (the first output block).
o 16字节TEK（第一个输出块）。
o The 64-byte MSK (the concatenation of the second to fifth output blocks).
o 64字节MSK（第二到第五输出块的串联）。
o The 64-byte EMSK (the concatenation of the sixth to ninth output blocks).
o 64字节EMSK（第六到第九个输出块的串联）。
The details of the derivation of the session keys are shown in Figure 7.
会话密钥派生的详细信息如图7所示。
+--------------------------+
| RAND_P |
| Input Block (16 bytes) |
+--------------------------+
|
v
+----------------+
| |
| AES-128(KDK,.) |
| |
+----------------+
|
|
+---------------------+-- - - - - - - - - - --+
| | |
v v v
+--------+ +---+ +--------+ +---+ +--------+ +---+
| c1="1" |->|XOR| | c2="2" |->|XOR|.......| c9="9" |->|XOR|
|16 bytes| +---+ |16 bytes| +---+ |16 bytes| +---+
+--------+ | +--------+ | +--------+ |
| | |
+----------------+ +----------------+ +----------------+
| | | | | |
| AES-128(KDK,.) | | AES-128(KDK,.) |......| AES-128(KDK,.) |
| | | | | |
+----------------+ +----------------+ +----------------+
| | |
| | |
v v v
+-----------------+ +-----------------+ +------------------+
| Output Block #1 | | Output Block #2 | | Output Block #9 |
| (16 bytes) | | (16 bytes) |.....| (16 bytes) |
| TEK | | MSK (block 1/4) | | EMSK (block 4/4) |
+-----------------+ +-----------------+ +------------------+
+--------------------------+
| RAND_P |
| Input Block (16 bytes) |
+--------------------------+
|
v
+----------------+
| |
| AES-128(KDK,.) |
| |
+----------------+
|
|
+---------------------+-- - - - - - - - - - --+
| | |
v v v
+--------+ +---+ +--------+ +---+ +--------+ +---+
| c1="1" |->|XOR| | c2="2" |->|XOR|.......| c9="9" |->|XOR|
|16 bytes| +---+ |16 bytes| +---+ |16 bytes| +---+
+--------+ | +--------+ | +--------+ |
| | |
+----------------+ +----------------+ +----------------+
| | | | | |
| AES-128(KDK,.) | | AES-128(KDK,.) |......| AES-128(KDK,.) |
| | | | | |
+----------------+ +----------------+ +----------------+
| | |
| | |
v v v
+-----------------+ +-----------------+ +------------------+
| Output Block #1 | | Output Block #2 | | Output Block #9 |
| (16 bytes) | | (16 bytes) |.....| (16 bytes) |
| TEK | | MSK (block 1/4) | | EMSK (block 4/4) |
+-----------------+ +-----------------+ +------------------+
Figure 7: Derivation of the Session Keys in Details
图7：会话密钥的详细推导
The counter values are set respectively to the first t integers (that is, ci="i", with i=1 to 9).
计数器值分别设置为第一个t整数（即i=1到9的ci=“i”）。
Keying material is sensitive information and should be handled accordingly (see Section 8.10 for further discussion).
键控材料是敏感信息，应进行相应处理（有关进一步讨论，请参阅第8.10节）。
EAP-PSK provides a protected channel for both parties to communicate over, in case of a successful authentication. This protected channel is currently used to exchange protected result indications and may be used in the future to implement extensions.
EAP-PSK为双方提供了一个受保护的通道，以便在认证成功的情况下进行通信。此受保护通道当前用于交换受保护的结果指示，将来可能用于实现扩展。
EAP-PSK uses the EAX mode of operation to provide this protected channel. For a detailed description of EAX, please refer to [4]. Figure 8 shows how EAX is used to implement EAP-PSK protected channel.
EAP-PSK使用EAX操作模式来提供此受保护信道。有关EAX的详细说明，请参阅[4]。图8显示了如何使用EAX实现EAP-PSK保护通道。
+-----------+ +----------------+ +---------------------+ +----------+
| Nonce N | | Header H | | Plain Text Payload | | TEK |
| 4 bytes | | 22 bytes | | Variable length L | | 16 bytes |
+-----------+ +----------------+ +---------------------+ +----------+
| | | |
v v v v
+-------------------------------------------------------------------+
| |
| EAX |
| |
+-------------------------------------------------------------------+
| |
v v
+---------------------+ +----------+
| Cipher Text Payload | | Tag |
| Variable length L | | 16 bytes |
+---------------------+ +----------+
+-----------+ +----------------+ +---------------------+ +----------+
| Nonce N | | Header H | | Plain Text Payload | | TEK |
| 4 bytes | | 22 bytes | | Variable length L | | 16 bytes |
+-----------+ +----------------+ +---------------------+ +----------+
| | | |
v v v v
+-------------------------------------------------------------------+
| |
| EAX |
| |
+-------------------------------------------------------------------+
| |
v v
+---------------------+ +----------+
| Cipher Text Payload | | Tag |
| Variable length L | | 16 bytes |
+---------------------+ +----------+
Figure 8: The Protected Channel
图8：受保护的通道
This protected channel:
此受保护通道：
o Provides replay protection.
o 提供重播保护。
o Encrypts and authenticates a Plain Text Payload that becomes an Encrypted Payload. The Plain Text Payload must not exceed 960 bytes; see Sections 5.3, 5.4, and 8.11.
o 加密并验证成为加密负载的纯文本负载。纯文本有效负载不得超过960字节；见第5.3、5.4和8.11节。
o Only authenticates a Header that is thus sent in clear.
o 仅对以明文形式发送的标头进行身份验证。
EAX is instantiated with AES-128 as the underlying block cipher.
EAX以AES-128作为基础分组密码进行实例化。
AES-128 is keyed with the TEK.
AES-128采用TEK键控。
The nonce N is used to provide cryptographic security to the encryption and data origin authentication as well as protection replay. Indeed, N is a 4-byte sequence number starting from <0> that is monotonically incremented at each EAP-PSK message within one EAP-PSK dialog, except retransmissions, of course.
nonce N用于为加密和数据源身份验证以及保护重播提供加密安全性。实际上，N是一个4字节的序列号，从<0>开始，在一个EAP-PSK对话框中的每个EAP-PSK消息处单调递增，当然，除了重新传输之外。
N was taken to be 4 bytes to avoid 16-byte arithmetic. Since EAX uses a 16-byte nonce, N is padded with 96 zero bits for its high-order bits.
N被取为4字节，以避免16字节的运算。由于EAX使用16字节的nonce，N的高阶位用96个零位填充。
For cryptographic reasons, N is not allowed to wrap around. In the unlikely, yet possible, event of the server sending an EAP-PSK message with N set to <2**32-2>, it must not send any further message on this protected channel, which would cause to reusing the value 0. Either the conversation is finished after the server receives the EAP-PSK answer from the peer with N set to <2**32-1> and the server proceeds (typically by sending an EAP-Success or Failure), or the conversation is not finished and must then be aborted (a new EAP-PSK dialog may subsequently be started to try again to authenticate). Thus, the maximum number of messages that can be exchanged over the same protected channel is 2**32 (which should not be a limitation in practice, as this is approximately equal to 4 billion).
出于加密原因，不允许N环绕。如果服务器发送的EAP-PSK消息的N设置为<2**32-2>，则该事件不太可能发生，但也有可能发生，服务器不得在此受保护通道上发送任何进一步的消息，这将导致重用值0。在服务器接收到来自对等方的EAP-PSK应答且N设置为<2**32-1>且服务器继续（通常通过发送EAP成功或失败）后，会话完成，或者会话未完成，然后必须中止（随后可能会启动新的EAP-PSK对话以重试身份验证）。因此，可在同一受保护信道上交换的最大消息数为2**32（这在实践中不应是限制，因为这大约等于40亿）。
The Header H consists of the first 22 bytes of the EAP Request or Response packet (i.e., the EAP Code, Identifier, Length, and Type fields followed by the EAP-PSK Flags and RAND_S fields). Although it may appear unorthodox that an upper layer (EAP-PSK) protects some information of the lower layer (EAP), this was chosen to comply with EAP recommendation (see Section 7.5. of [3]) and seems to be existing practice at IETF (see, for instance, [35]).
报头H由EAP请求或响应数据包的前22个字节组成（即，EAP代码、标识符、长度和类型字段，后跟EAP-PSK标志和RAND_S字段）。虽然上层（EAP-PSK）保护下层（EAP）的某些信息似乎是非正统的，但选择它是为了符合EAP建议（见[3]第7.5节），并且似乎是IETF的现有做法（例如，见[35]）。
The Plain Text Payload is the payload that is to be encrypted and integrity protected. The Cipher Text Payload is the result of the encryption of the Plain Text.
纯文本有效负载是要加密和完整性保护的有效负载。密码文本有效负载是纯文本加密的结果。
The Tag is a MAC that protects both the Header and the Plain Text Payload. The verification of the Tag must only be done after a successful verification of the Nonce for replay protection. If the verification of the Tag succeeds, then the Encrypted Payload is decrypted to recover the Plain Text Payload. If the verification of the Tag fails, then no decryption is performed and this MAC failure should be logged. The tag length is chosen to be 16 bytes for EAX within EAP-PSK. This length is considered appropriate by the cryptographic community.
标签是一个MAC，它同时保护报头和纯文本负载。只有在成功验证用于重播保护的Nonce之后，才能验证标记。如果标记验证成功，则加密的有效负载将被解密以恢复纯文本有效负载。如果标签验证失败，则不执行解密，并且应记录此MAC故障。EAP-PSK中EAX的标记长度选择为16字节。加密社区认为该长度是合适的。
EAX was mainly chosen because:
选择EAX主要是因为：
o It strongly relies on OMAC in its design and OMAC1, a variant of OMAC, had already been chosen in EAP-PSK for the authentication part (please remember that OMAC1 and CMAC are analogous).
o 它在设计上强烈依赖于OMAC，而OMAC的一个变体OMAC1已经在EAP-PSK中被选择用于认证部分（请记住，OMAC1和CMAC是类似的）。
o Its design is simple.
o 它的设计很简单。
o It enjoys a security proof.
o 它具有安全性证明。
o It is free of any Intellectual Property Rights claims.
o 它没有任何知识产权要求。
EAP-PSK may consist of two different types of message flows:
EAP-PSK可由两种不同类型的消息流组成：
o The "standard authentication", which is:
o “标准认证”，即：
* Mandatory to implement.
* 强制执行。
* Fully specified in this document.
* 在本文件中完全指定。
* The simpler type of message flow, which is expected to be used most frequently.
* 更简单的消息流类型，预计使用频率最高。
o The "extended authentication", which is:
o “扩展身份验证”，即：
* Optional to implement (i.e., there are no mandatory extensions).
* 可选实现（即，没有强制扩展）。
* Partly specified in this document since it depends on extensions and none are currently specified, let alone in this document.
* 部分在本文档中指定，因为它依赖于扩展，并且当前未指定任何扩展，更不用说在本文档中了。
* The type of message flow that should be used when extensions of EAP-PSK are needed by more sophisticated usage scenarios and are available.
* 当更复杂的使用场景需要EAP-PSK扩展时，应该使用的消息流类型，并且可以使用。
EAP-PSK introduces the concept of a session to facilitate its analysis and provide a cleaner interface to other layers. A session is a particular instance of an EAP-PSK dialog between two parties. This session is identified by a session identifier.
EAP-PSK引入了会话的概念，以便于分析，并为其他层提供更清晰的接口。会话是双方之间EAP-PSK对话的特定实例。此会话由会话标识符标识。
In the first EAP-PSK message, the EAP server asserts its identity. Given that the EAP-Request/Identity and EAP-Response/Identity may not be assumed to have occurred prior to this sending and that the response included in EAP-Response/Identity (if this EAP Identity exchange takes place) may not contain the actual NAI the peer shall
在第一条EAP-PSK消息中，EAP服务器断言其标识。鉴于EAP请求/标识和EAP响应/标识可能不会在发送之前发生，且EAP响应/标识中包含的响应（如果发生EAP标识交换）可能不包含实际NAI，对等方应
use with EAP-PSK, this means that an EAP server implementing EAP-PSK must use the same EAP server NAI for all EAP-PSK dialogs with any EAP peer implementing EAP-PSK.
与EAP-PSK一起使用，这意味着实现EAP-PSK的EAP服务器必须为所有EAP-PSK对话框与任何实现EAP-PSK的EAP对等方使用相同的EAP服务器NAI。
EAP-PSK standard authentication is comprised of four messages, i.e., two round-trips; see Figure 9.
EAP-PSK标准认证由四条消息组成，即两条往返消息；参见图9。
peer server
| Flags||RAND_S||ID_S |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| Flags||RAND_S||MAC_S||PCHANNEL_S_0 |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_1 |
|--------------------------------------------------------->|
| |
peer server
| Flags||RAND_S||ID_S |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| Flags||RAND_S||MAC_S||PCHANNEL_S_0 |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_1 |
|--------------------------------------------------------->|
| |
Figure 9: EAP-PSK Standard Authentication
图9:EAP-PSK标准认证
o The first message is sent by the server to the peer to:
o 第一条消息由服务器发送到对等方：
* Send a 16-byte random challenge (RAND_S). RAND_S was called RA in Section 3.2
* 发送一个16字节的随机质询（随机）。RAND_S在第3.2节中称为RA
* State its identity (ID_S). ID_S was denoted by A in Section 3.2.
* 说明其身份（ID）。ID_S在第3.2节中用A表示。
o The second message is sent by the peer to the server to:
o 第二条消息由对等方发送到服务器：
* Send another 16-byte random challenge (RAND_P). RAND_P was called RB in Section 3.2
* 发送另一个16字节随机质询（RAND_P）。RAND_P在第3.2节中称为RB
* State its identity (ID_P). ID_P was denoted by B in Section 3.2.
* 说明其身份（ID\P）。ID_P在第3.2节中用B表示。
* Authenticate to the server by proving that it is able to compute a particular MAC (MAC_P), which is a function of the two challenges and AK: MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)
* 通过证明服务器能够计算特定的MAC（MAC|P），这是两个挑战和AK的函数：MAC|P=CMAC-AES-128（AK，ID|P | ID|S | RAND|S | RAND|P），对服务器进行身份验证
o The third message is sent by the server to the peer to:
o 第三条消息由服务器发送到对等方：
* Authenticate to the peer by proving that it is able to compute another MAC (MAC_S), which is a function of the peer's challenge and AK: MAC_S = CMAC-AES-128(AK, ID_S||RAND_P)
* 通过证明对等方能够计算另一个MAC（MAC|S）进行身份验证，该MAC是对等方挑战的函数，AK:MAC|S=CMAC-AES-128（AK，ID|S | RAND|P）
* Set up the protected channel (P_CHANNEL_S_0) to:
* 将受保护通道（P_通道\u S_0）设置为：
+ Confirm that it has derived session keys (at least the TEK).
+ 确认它已派生会话密钥（至少是TEK）。
+ Give a protected result indication of the authentication.
+ 提供身份验证的受保护结果指示。
o The fourth message is sent by the peer to the server to finish the setup of the protected channel (P_CHANNEL_P_1) to:
o 第四条消息由对等方发送到服务器，以完成受保护通道（P_channel_P_1）的设置，发送到：
* Confirm that it has derived session keys (at least the TEK).
* 确认它已派生会话密钥（至少是TEK）。
* Give a protected result indication of the authentication.
* 提供身份验证的受保护结果指示。
The PCHANNEL_S_0 and PCHANNEL_P_1 fields of the third and fourth EAP-PSK messages contain a MAC-computed thanks to TEK that protects the integrity of the messages. For a detailed list of the fields of the messages that are integrity protected, please refer to Section 3.3.
第三和第四EAP-PSK消息的PCchannel_S_0和PCchannel_P_1字段包含由TEK计算的MAC，TEK保护消息的完整性。有关完整性保护的消息字段的详细列表，请参阅第3.3节。
All EAP-PSK messages include a sort of header, which is comprised of two fields:
所有EAP-PSK消息都包含一种标头，该标头由两个字段组成：
o Flags, a 1-byte field that is currently only used to number EAP-PSK messages.
o 标志，一个1字节字段，当前仅用于对EAP-PSK消息进行编号。
o RAND_S, a 16-byte challenge sent by the server that is used as a session identifier.
o RAND_S，服务器发送的16字节质询，用作会话标识符。
This standard message flow could be comprised of only three messages, like AKEP2, were it not the request/response nature of EAP that prevents the third message to be the last one. Since the fourth message is mandatory, EAP-PSK chose to take advantage of this and set up a protected channel.
如果不是EAP的请求/响应特性阻止第三条消息成为最后一条消息，那么这个标准消息流只能由三条消息组成，如AKEP2。由于第四条消息是强制性的，EAP-PSK选择利用这一点并设置受保护的通道。
The standard message flow also includes a statement by the peer of its identity, in addition to the EAP-Response/Identity it may have sent. This behavior follows Section 5.1 of [3], which recommends that the EAP-Response/Identity be used primarily for routing purposes and selecting which EAP method to use, and therefore that EAP methods include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response.
除了可能发送的EAP响应/标识外，标准消息流还包括对等方对其标识的声明。该行为遵循[3]第5.1节，该节建议EAP响应/标识主要用于路由目的和选择要使用的EAP方法，因此EAP方法包括用于获取标识的方法特定机制，以便它们不必依赖标识响应。
When a party receives an EAP-PSK message, it checks that the message is syntactically valid in accordance with the message formats defined in Section 5. If the message is syntactically incorrect, then it is silently discarded. Then it checks the cryptographic validity of this message, i.e., it checks the MAC(s) as follows:
当一方收到EAP-PSK消息时，它根据第5节中定义的消息格式检查该消息在语法上是否有效。如果消息在语法上不正确，那么它将被悄悄地丢弃。然后检查该消息的加密有效性，即检查MAC，如下所示：
o If the received message is the first EAP-PSK message, there is no MAC to check as none is included in message 1.
o 如果收到的消息是第一条EAP-PSK消息，则没有要检查的MAC，因为消息1中不包括MAC。
o If the received message is the second EAP-PSK message, the validity of MAC_P is checked.
o 如果收到的消息是第二条EAP-PSK消息，则检查MAC_P的有效性。
o If the received message is the third EAP-PSK message, the validity of MAC_S is checked and then the validity of the Tag included in P_CHANNEL_S_0 is checked. The validity checks must be done in this order to avoid unnecessarily deriving TEK, MSK, and EMSK in case MAC_S is invalid, meaning that mutual authentication has failed. Indeed, TEK is used to verify the validity of the Tag included in P_CHANNEL_S_0.
o 如果收到的消息是第三条EAP-PSK消息，则检查MAC_S的有效性，然后检查P_信道_S_0中包含的标签的有效性。有效性检查必须按此顺序进行，以避免在MAC_无效的情况下不必要地派生TEK、MSK和EMSK，这意味着相互身份验证失败。事实上，TEK用于验证P_CHANNEL_S_0中包含的标签的有效性。
o If the received message is the fourth EAP-PSK message, the validity of the Tag included in P_CHANNEL_P_1 is checked.
o 如果收到的消息是第四条EAP-PSK消息，则检查P_信道P_1中包含的标签的有效性。
If a validity check fails, the message is silently discarded. There can be a counter to track the number of silently discarded messages Section 8.8. If there is an encrypted payload in the message (namely, in the PCHANNEL attribute), then the encrypted payload is decrypted. Then, if the decrypted payload is syntactically incorrect, the message is silently discarded.
如果有效性检查失败，消息将被自动丢弃。第8.8节中可以有一个计数器来跟踪静默丢弃的消息数。如果消息中存在加密的有效负载（即，在PCHANNEL属性中），则加密的有效负载将被解密。然后，如果解密的有效负载在语法上不正确，则消息将被悄悄地丢弃。
To remain simple and yet be extensible to meet future requirements, EAP-PSK provides an extension mechanism within its protected channel: the payload of the protected channel may contain an optional extension field (EXT).
为了保持简单且可扩展以满足未来需求，EAP-PSK在其受保护信道内提供了一种扩展机制：受保护信道的有效负载可能包含一个可选扩展字段（EXT）。
Figure 10 presents the message sequence for EAP-PSK extended authentication.
图10显示了EAP-PSK扩展身份验证的消息序列。
Extended authentication MUST be supported, i.e., any EAP-PSK implementation MUST support sending and reception of an EXT attribute according to rules of operation described in Section 6. Yet, although support of the EXT field is mandatory, there is no mandatory extension type to support. This means that if a server engages in EAP-PSK extended authentication, as only the server can start extended authentication per Section 6, a peer will recognize the attempt to start extended authentication through its EXT support. If
必须支持扩展认证，即任何EAP-PSK实现必须根据第6节中描述的操作规则支持发送和接收EXT属性。然而，尽管对EXT字段的支持是强制性的，但并没有强制性的扩展类型可支持。这意味着，如果服务器参与EAP-PSK扩展身份验证，因为只有服务器可以根据第6节启动扩展身份验证，对等方将通过其EXT支持识别启动扩展身份验证的尝试。如果
the peer does not support the particular extension type used by the server, the peer will still be able to conclude the EAP-PSK dialog.
对等方不支持服务器使用的特定扩展类型，对等方仍然能够结束EAP-PSK对话框。
The mandatory support of the EXT field is dictated:
EXT字段的强制支持规定如下：
o To guarantee a robust behavior in the future where some peers might support some extensions and others not. All peers will thus be able to understand that an extended authentication is being attempted and indicate whether or not they support the extension that is tried.
o 为了保证将来在某些对等方可能支持某些扩展而其他对等方不支持的情况下有健壮的行为。因此，所有对等方将能够理解正在尝试扩展身份验证，并指示它们是否支持尝试的扩展。
o To ensure that all implementations will indeed be extensible.
o 确保所有的实现都是可扩展的。
No extension is currently defined.
当前未定义扩展。
At most, one extension may be run within a single EAP-PSK dialog: there can neither be sequences of extensions nor interleaved extensions. However, extensions may take a variable number of round-trips to complete.
最多可以在单个EAP-PSK对话框中运行一个扩展：既不能有扩展序列，也不能有交叉扩展。但是，扩展可能需要不同数量的往返才能完成。
Only the server can start an extension and, if it does so, it must start it in the first payload it sends over the protected channel.
只有服务器可以启动扩展，如果它这样做，它必须在通过受保护通道发送的第一个有效负载中启动它。
peer server
| Flags||RAND_S||ID_S |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT) |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_1(EXT) |
|--------------------------------------------------------->|
| |
. .
. .
. .
| Flags||RAND_S||PCHANNEL_S_2i(EXT) |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_2i+1(EXT) |
|--------------------------------------------------------->|
| |
peer server
| Flags||RAND_S||ID_S |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT) |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_1(EXT) |
|--------------------------------------------------------->|
| |
. .
. .
. .
| Flags||RAND_S||PCHANNEL_S_2i(EXT) |
|<---------------------------------------------------------|
| |
| Flags||RAND_S||PCHANNEL_P_2i+1(EXT) |
|--------------------------------------------------------->|
| |
Figure 10: EAP-PSK Extended Authentication
图10:EAP-PSK扩展认证
Please refer to Section 6 for more details on how extended authentication works.
有关扩展身份验证工作原理的更多详细信息，请参阅第6节。
The PCHANNEL_S_2j and PCHANNEL_P_2j+1 fields of the EAP-PSK messages (where j varies from 0 to i) contain a MAC-computed thanks to TEK that protects the integrity of the messages. For a detailed list of the fields of the messages that are integrity protected, please refer to Section 3.3.
EAP-PSK消息的PCHANNEL_S_2j和PCHANNEL_P_2j+1字段（其中j从0到i变化）包含一个由TEK计算的MAC，TEK保护消息的完整性。有关完整性保护的消息字段的详细列表，请参阅第3.3节。
When a party receives an EAP-PSK message, it checks that the message is syntactically valid in accordance with the message formats defined in Section 5. If the message is syntactically incorrect, then it is silently discarded. Then it checks the cryptographic validity of this message, i.e., it checks the MAC(s) as follows:
当一方收到EAP-PSK消息时，它根据第5节中定义的消息格式检查该消息在语法上是否有效。如果消息在语法上不正确，那么它将被悄悄地丢弃。然后检查该消息的加密有效性，即检查MAC，如下所示：
o If the received message is the first EAP-PSK message, there is no MAC to check as none is included in message 1.
o 如果收到的消息是第一条EAP-PSK消息，则没有要检查的MAC，因为消息1中不包括MAC。
o If the received message is the second EAP-PSK message, the validity of MAC_P is checked.
o 如果收到的消息是第二条EAP-PSK消息，则检查MAC_P的有效性。
o If the received message is the third EAP-PSK message, the validity of MAC_S is checked and then the validity of the Tag included in P_CHANNEL_S_0 is checked. The validity checks must be done in this order to avoid unnecessarily deriving TEK, MSK, and EMSK in case MAC_S is invalid, meaning that mutual authentication has failed. Indeed, TEK is used to verify the validity of the Tag included in P_CHANNEL_S_0.
o 如果收到的消息是第三条EAP-PSK消息，则检查MAC_S的有效性，然后检查P_信道_S_0中包含的标签的有效性。有效性检查必须按此顺序进行，以避免在MAC_无效的情况下不必要地派生TEK、MSK和EMSK，这意味着相互身份验证失败。事实上，TEK用于验证P_CHANNEL_S_0中包含的标签的有效性。
o If the received message is the fourth EAP-PSK message, the validity of the Tag included in P_CHANNEL_P_1 is checked.
o 如果收到的消息是第四条EAP-PSK消息，则检查P_信道P_1中包含的标签的有效性。
o If the received message is an EAP-PSK message different from the first four ones, then validity of the Tag included in P_CHANNEL is checked.
o 如果收到的消息是不同于前四条的EAP-PSK消息，则检查P_信道中包含的标签的有效性。
If a validity check fails, the message is silently discarded. There can be a counter to track the number of silently discarded messages Section 8.8. If there is an encrypted payload in the message (namely in the PCHANNEL attribute), then the encrypted payload is decrypted. Then, if the decrypted payload is syntactically incorrect, the message is silently discarded.
如果有效性检查失败，消息将被自动丢弃。第8.8节中可以有一个计数器来跟踪静默丢弃的消息数。如果消息中（即PCChannel属性中）存在加密的有效负载，则加密的有效负载将被解密。然后，如果解密的有效负载在语法上不正确，则消息将被悄悄地丢弃。
For the sake of simplicity, EAP-PSK uses a fixed message format. There are four different types of EAP-PSK messages:
为了简单起见，EAP-PSK使用固定的消息格式。有四种不同类型的EAP-PSK消息：
o The first EAP-PSK message, which is sent by the server to the peer.
o 第一条EAP-PSK消息，由服务器发送给对等方。
o The second EAP-PSK message, which is sent by the peer to the server.
o 第二条EAP-PSK消息，由对等方发送到服务器。
o The third EAP-PSK message, which is sent by the server to the peer.
o 第三条EAP-PSK消息，由服务器发送给对等方。
o The fourth EAP-PSK message, which is sent by the peer to the server. This is also the type of message that the peer further sends to the server in case of an extended authentication. This is also essentially the type of message that the server further sends to the peer in case of an extended authentication: the only slight modification that occurs in this last case is the setting of the EAP Code to 1 instead of 2 in the other cases.
o 第四条EAP-PSK消息，由对等方发送到服务器。这也是对等方在进行扩展身份验证时进一步发送到服务器的消息类型。这本质上也是服务器在扩展身份验证情况下进一步发送给对等方的消息类型：最后一种情况下发生的唯一轻微修改是将EAP代码设置为1，而不是其他情况下的2。
For the sake of clarity, the whole EAP packet that encapsulates the EAP-PSK message (i.e., the EAP-PSK message plus its EAP headers) is depicted in Figures 11, 13, 14, and 18.
为了清楚起见，图11、13、14和18中描述了封装EAP-PSK消息的整个EAP分组（即，EAP-PSK消息及其EAP报头）。
The first EAP-PSK message is sent by the server to the peer. It has the format presented in Figure 11.
第一条EAP-PSK消息由服务器发送给对等方。它的格式如图11所示。
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=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
: ID_S :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
: ID_S :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: EAP-PSK First Message
图11:EAP-PSK第一条消息
Since IANA has allocated EAP method type 47 for EAP-PSK, Type EAP-PSK for the first EAP-PSK message as well as any other EAP-PSK message MUST be 47.
由于IANA已为EAP-PSK分配了EAP方法类型47，因此第一条EAP-PSK消息以及任何其他EAP-PSK消息的类型EAP-PSK必须为47。
The first EAP-PSK message consists of:
第一条EAP-PSK消息包括：
o A 1-byte Flags field
o 一个1字节的标志字段
o A 16-byte random number: RAND_S
o 一个16字节的随机数：RAND_S
o A variable length field that conveys the server's NAI: ID_S. The length of this field is deduced from the EAP length field. The length of this NAI must not exceed 966 bytes. This restriction aims at avoiding fragmentation issues (see Section 8.11).
o 表示服务器的NAI:ID_s的可变长度字段。此字段的长度由EAP长度字段推导而来。此NAI的长度不得超过966字节。该限制旨在避免碎片问题（见第8.11节）。
The Flags field has the format presented in Figure 12.
Flags字段的格式如图12所示。
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| T | Reserved |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| T | Reserved |
+-+-+-+-+-+-+-+-+
Figure 12: EAP-PSK Flags Field
图12:EAP-PSK标志字段
The Flags field is comprised of two subfields:
Flags字段由两个子字段组成：
o A 2-bit T subfield, which indicates the type of EAP-PSK message:
o 2位T子字段，指示EAP-PSK消息的类型：
* T=0 for the first EAP-PSK message presented in Section 5.1.
* 第5.1节中给出的第一条EAP-PSK消息的T=0。
* T=1 for the second EAP-PSK message presented in Section 5.2.
* 第5.2节中给出的第二条EAP-PSK消息的T=1。
* T=2 for the third EAP-PSK message presented in Section 5.3.
* 第5.3节中给出的第三条EAP-PSK消息的T=2。
* T=3 for the fourth EAP-PSK message presented in Section 5.4 and the subsequent EAP-PSK messages that may be exchanged during extended authentication.
* 对于第5.4节中显示的第四条EAP-PSK消息以及扩展身份验证期间可能交换的后续EAP-PSK消息，T=3。
o A 6-bit Reserved subfield that is set to zero on transmission and ignored on reception.
o 一种6位保留子字段，在传输时设置为零，在接收时忽略。
The PCHANNEL Nonce field N (see Section 5.3) is used to distinguish between the different EAP-PSK messages that may be exchanged during extended authentication that all have T set to 3, i.e., the fourth EAP-PSK message and possibly the next ones.
PCHANNEL Nonce字段N（参见第5.3节）用于区分在扩展认证期间可能交换的不同EAP-PSK消息，这些消息都未设置为3，即第四条EAP-PSK消息和可能的下一条EAP-PSK消息。
The second EAP-PSK message is sent by the peer to the server. It has the format presented in Figure 13.
第二条EAP-PSK消息由对等方发送到服务器。它的格式如图13所示。
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=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_P |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| MAC_P |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
: ID_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_P |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| MAC_P |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
: ID_P :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: EAP-PSK Second Message
图13:EAP-PSK第二条消息
It consists of:
它包括：
o A 1-byte Flags field
o 一个1字节的标志字段
o The 16-byte random number sent by the server in the first EAP-PSK message (RAND_S) that serves as a session identifier
o 服务器在作为会话标识符的第一条EAP-PSK消息（RAND_S）中发送的16字节随机数
o A 16-byte random number: RAND_P
o 一个16字节的随机数：RAND\u P
o A 16-byte MAC: MAC_P
o 一个16字节的MAC:MAC\P
o A variable length field that conveys the peer's NAI: ID_P. The length of this field is deduced from the EAP length field. The length of this NAI must not exceed 966 bytes. This restriction aims at avoiding fragmentation issues (see Section 8.11).
o 一个可变长度字段，用于传递对等方的NAI:ID_P。该字段的长度由EAP长度字段推导而来。此NAI的长度不得超过966字节。该限制旨在避免碎片问题（见第8.11节）。
The Flags field format is presented in Figure 12.
Flags字段格式如图12所示。
The third EAP-PSK message is sent by the server to the peer. It has the format presented in Figure 14.
第三条EAP-PSK消息由服务器发送给对等方。它的格式如图14所示。
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=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| MAC_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
: PCHANNEL :
: :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| MAC_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
: PCHANNEL :
: :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: EAP-PSK Third Message
图14:PSK第三条消息
It consists of:
它包括：
o A 1-byte Flags field
o 一个1字节的标志字段
o The 16-byte random number sent by the server in the first EAP-PSK message (RAND_S) that is used as a session identifier
o 服务器在用作会话标识符的第一条EAP-PSK消息（RAND_S）中发送的16字节随机数
o A 16-byte MAC: MAC_S
o 16字节MAC:MAC\S
o A variable length field that constitutes the protected channel: PCHANNEL
o 构成受保护通道的可变长度字段：PCHANNEL
The Flags field format is presented in Figure 12.
Flags字段格式如图12所示。
If there is no extension, i.e., if the authentication is standard, the PCHANNEL field consists of:
如果没有扩展，即如果认证是标准的，则PCChannel字段包括：
o A 4-byte Nonce N (see Section 3.3).
o 一个4字节的Nonce N（见第3.3节）。
o A 16-byte Tag (see Section 3.3).
o 一个16字节的标签（见第3.3节）。
o A 2-bit result indication flag R.
o 2位结果指示标志R。
o A 1-bit extension flag E, which is set to 0.
o 1位扩展标志E，设置为0。
o A 5-bit Reserved field, which is set to zero on emission and ignored on reception.
o 5位保留字段，发射时设置为零，接收时忽略。
R, E, and Reserved are sent encrypted by the protected channel (see Section 3.3).
R、 E和保留的数据由受保护通道加密发送（见第3.3节）。
If there is no extension, PCHANNEL has the format presented in Figure 15 (where R, E, and Reserved are presented in the clear for the sake of clarity, although in reality they are sent encrypted).
如果没有扩展，PCChannel的格式如图15所示（其中R、E和Reserved为清晰起见以明文形式显示，尽管实际上它们是加密发送的）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |0| Reserved|
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |0| Reserved|
+-+-+-+-+-+-+-+-+
Figure 15: The PCHANNEL Field with E=0
图15：E=0的PCChannel字段
If there is an extension, i.e., if the authentication is extended, the PCHANNEL field consists of:
如果存在扩展，即如果认证被扩展，则PCHANNEL字段包括：
o A 4-byte Nonce N (see Section 3.3).
o 一个4字节的Nonce N（见第3.3节）。
o A 16-byte Tag (see Section 3.3).
o 一个16字节的标签（见第3.3节）。
o A 2-bit result indication flag R.
o 2位结果指示标志R。
o A 1-bit extension flag E, which is set to 1.
o 1位扩展标志E，设置为1。
o A 5-bit Reserved field, which is set to zero on emission and ignored on reception.
o 5位保留字段，发射时设置为零，接收时忽略。
o A variable length EXT field.
o 可变长度的外部字段。
R, E, Reserved, and EXT are sent encrypted by the protected channel (see Section 3.3).
R、 E、Reserved和EXT由受保护通道加密发送（见第3.3节）。
If there is an extension, PCHANNEL has the format presented in Figure 16 where R, E, Reserved and EXT are presented in the clear for the sake of clarity, although in reality they are sent encrypted).
如果有扩展，PCChannel的格式如图16所示，为了清晰起见，R、E、Reserved和EXT以明文形式显示，但实际上它们是加密发送的）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |1| Reserved| |
+-+-+-+-+-+-+-+-+ +
: EXT :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |1| Reserved| |
+-+-+-+-+-+-+-+-+ +
: EXT :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: The PCHANNEL Field with E=1
图16：E=1的PCChannel字段
This EXT field is split in two subfields:
此EXT字段分为两个子字段：
o The EXT_Type subfield, which indicates the type of the extension
o EXT_Type子字段，指示扩展的类型
o The EXT_Payload subfield, which consists of the payload of the extension. The EXT_Payload length is derived from the EAP Length field. EXT_Payload must have a bit length that is a multiple of 8 bits and must not exceed 960 bytes. The latter restriction aims
o EXT_有效载荷子字段，由扩展的有效载荷组成。EXT_有效负载长度来自EAP长度字段。EXT_有效负载的位长度必须是8位的倍数，且不得超过960字节。后一项限制旨在
at avoiding fragmentation issues (see Section 8.11), whereas the former comes from the EAP length being specified in bytes.
在避免碎片问题时（参见第8.11节），前者来自以字节为单位指定的EAP长度。
The format of the EXT field is presented in Figure 17.
EXT字段的格式如图17所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXT_Type | |
+-+-+-+-+-+-+-+-+ +
: EXT_Payload :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXT_Type | |
+-+-+-+-+-+-+-+-+ +
: EXT_Payload :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: The EXT Field
图17:EXT字段
The fourth EAP-PSK message is sent by the peer to the server. It has the format presented in Figure 18.
第四条EAP-PSK消息由对等方发送到服务器。它的格式如图18所示。
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=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
: PCHANNEL :
: :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
: PCHANNEL :
: :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: EAP-PSK Fourth Message
图18:EAP-PSK第四条消息
It consists of:
它包括：
o A 1-byte Flags field
o 一个1字节的标志字段
o The 16-byte random number sent by the server in the first EAP-PSK message (RAND_S) that is used as a session identifier
o 服务器在用作会话标识符的第一条EAP-PSK消息（RAND_S）中发送的16字节随机数
o A variable length field that constitutes the protected channel: PCHANNEL
o 构成受保护通道的可变长度字段：PCHANNEL
The Flags field format is presented in Figure 12.
Flags字段格式如图12所示。
The PCHANNEL field has the following structure, which was already described in Section 5.3.
PCChannel字段具有以下结构，已在第5.3节中描述。
If there is no extension, i.e., if the authentication is standard, the PCHANNEL field consists of:
如果没有扩展，即如果认证是标准的，则PCChannel字段包括：
o A 4-byte Nonce N (see Section 3.3).
o 一个4字节的Nonce N（见第3.3节）。
o A 16-byte Tag (see Section 3.3).
o 一个16字节的标签（见第3.3节）。
o A 2-bit result indication flag R.
o 2位结果指示标志R。
o A 1-bit extension flag E, which is set to 0.
o 1位扩展标志E，设置为0。
o A 5-bit Reserved field, which is set to zero on emission and ignored on reception.
o 5位保留字段，发射时设置为零，接收时忽略。
R, E, and Reserved are sent encrypted by the protected channel (see Section 3.3).
R、 E和保留的数据由受保护通道加密发送（见第3.3节）。
If there is no extension, PCHANNEL has the format presented in Figure 15.
如果没有扩展，PCChannel的格式如图15所示。
If there is an extension, i.e., if the authentication is extended, the PCHANNEL field consists of:
如果存在扩展，即如果认证被扩展，则PCHANNEL字段包括：
o A 4-byte Nonce N (see Section 3.3).
o 一个4字节的Nonce N（见第3.3节）。
o A 16-byte Tag (see Section 3.3).
o 一个16字节的标签（见第3.3节）。
o A 2-bit result indication flag R.
o 2位结果指示标志R。
o A 1-bit extension flag E, which is set to 1.
o 1位扩展标志E，设置为1。
o A 5-bit Reserved field, which is set to zero on emission and ignored on reception.
o 5位保留字段，发射时设置为零，接收时忽略。
o A variable length EXT field.
o 可变长度的外部字段。
R, E, Reserved, and EXT are sent encrypted by the protected channel (see Section 3.3).
R、 E、Reserved和EXT由受保护通道加密发送（见第3.3节）。
If there is an extension, PCHANNEL has the format presented in Figure 16.
如果有扩展名，PCChannel的格式如图16所示。
This EXT field is split in two subfields:
此EXT字段分为两个子字段：
o The EXT_Type subfield, which indicates the type of the extension
o EXT_Type子字段，指示扩展的类型
o The EXT_Payload subfield, which consists of the payload of the extension. The EXT_Payload length is derived from the EAP Length field. EXT_Payload must have a bit length that is a multiple of 8 bits and must not exceed 960 bytes. The latter restriction aims at avoiding fragmentation issues (see Section 8.11).
o EXT_有效载荷子字段，由扩展的有效载荷组成。EXT_有效负载长度来自EAP长度字段。EXT_有效负载的位长度必须是8位的倍数，且不得超过960字节。后一种限制旨在避免碎片问题（见第8.11节）。
The format of the EXT field is presented in Figure 17.
EXT字段的格式如图17所示。
In this section, the rules of operation of the EAP-PSK protected channel are presented:
本节介绍了EAP-PSK保护信道的操作规则：
o How protected result indications are implemented.
o 如何实施受保护的结果指示。
o How an extended authentication works in details.
o 详细介绍了扩展身份验证的工作原理。
The R flag of the PCHANNEL field in the third and fourth types of EAP-PSK messages is used to provide result indications.
第三类和第四类EAP-PSK消息中PCChannel字段的R标志用于提供结果指示。
Since this 2-bit flag is communicated over the protected channel, it is:
由于该2位标志通过受保护信道进行通信，因此：
o Encrypted so that only the peer and the server can know its value.
o 加密，以便只有对等方和服务器可以知道其值。
o Integrity-protected so that it cannot be modified by an attacker without the peer or the server detecting this modification.
o 完整性受到保护，因此攻击者无法在对等方或服务器未检测到此修改的情况下对其进行修改。
o Protected against replays.
o 防止重播。
This 2-bit R flag can take the following values:
此2位R标志可以采用以下值：
o 01 to mean CONT
o 01表示继续
o 10 to mean DONE_SUCCESS
o 10表示成功
o 11 to mean DONE_FAILURE
o 11表示完成或失败
The peer and the server each remember some information about both the values of R that they have sent and the values of R they have received. It is the conjunction of both sent and received R values that indicate the success or the failure of the EAP-PSK dialog.
对等方和服务器都会记住一些关于发送的R值和接收的R值的信息。发送和接收的R值的结合表示EAP-PSK对话框的成功或失败。
In the case of a standard authentication, the following values of R should be exchanged:
对于标准身份验证，应交换以下R值：
o Either the server sends a DONE_SUCCESS in the PCHANNEL of the third EAP-PSK message, to which the peer replies with a DONE_SUCCESS in the PCHANNEL of the fourth EAP-PSK message, which successfully ends the EAP-PSK dialog.
o 服务器在第三条EAP-PSK消息的PCChannel中发送DONE_SUCCESS，对等方在第四条EAP-PSK消息的PCChannel中回复DONE_SUCCESS，从而成功结束EAP-PSK对话框。
o Or the server sends a DONE_FAILURE in the PCHANNEL of the third EAP-PSK message, to which the peer replies with a DONE_FAILURE in the PCHANNEL of the fourth EAP-PSK message, which unsuccessfully ends the EAP-PSK dialog.
o 或者，服务器在第三条EAP-PSK消息的PCChannel中发送DONE_故障，对等方在第四条EAP-PSK消息的PCChannel中回复DONE_故障，但未成功结束EAP-PSK对话框。
In the case of an extended authentication, more complex exchanges may occur, which is why the CONT value was introduced.
在扩展身份验证的情况下，可能会发生更复杂的交换，这就是引入CONT值的原因。
The rules of operation for each value that R may take are detailed below.
R可能采用的每个值的操作规则如下所述。
The server and the peer each initialize the values of R they intend to send and receive as CONT.
服务器和对等方各自初始化它们打算作为CONT发送和接收的R的值。
Here CONT stands for "Continue". It indicates that the EAP-PSK dialog is not yet successful and that the party sending it wants to continue the dialog to try and reach success.
这里CONT代表“Continue”。它表示EAP-PSK对话尚未成功，发送该对话的一方希望继续对话以尝试并取得成功。
Indeed, although the peer and the server must have successfully authenticated each other, thanks to MAC_P and MAC_S, before they start communicating over the protected channel, the EAP-PSK dialog may not yet be deemed successful after this mutual authentication because of authorization issues. For instance, a prepaid customer of a wireless Hot-Spot might have successfully authenticated but has to refill its account, e.g., with a credit card transaction over the protected channel, before it is authorized.
事实上，尽管对等方和服务器在开始通过受保护信道进行通信之前必须已经成功地相互认证，但由于授权问题，EAP-PSK对话在相互认证之后可能尚未被视为成功。例如，无线热点的预付费客户可能已经成功地进行了身份验证，但必须在获得授权之前重新注册其帐户，例如，通过受保护的渠道进行信用卡交易。
DONE_SUCCESS indicates that the party that sent it deems the EAP-PSK dialog successful and therefore proposes to end this dialog.
因此，EAP-PSK认为该对话已成功结束。
Once the server has sent a DONE_SUCCESS, it must keep sending this value for R.
一旦服务器发送了一个DONE_SUCCESS，它就必须继续为R发送这个值。
The peer must first receive a DONE_SUCCESS from the server before it is allowed to send a DONE_SUCCESS.
对等方必须首先从服务器接收“已完成”成功，然后才允许其发送“已完成”成功。
After the peer has received a DONE_SUCCESS from the server, it may:
对等方从服务器接收到DONE_成功后，可能会：
o Send a CONT to the server if it has not reached success on its side. The server that receives a CONT should continue the EAP-PSK dialog (see Section 8.2 for some discussion on the security implications of this).
o 如果服务器未成功，则向服务器发送CONT。接收CONT的服务器应继续EAP-PSK对话框（有关此对话框的安全含义，请参阅第8.2节）。
o Send a DONE_SUCCESS to the server, which will end the EAP-PSK dialog with success.
o 将DONE_SUCCESS发送到服务器，服务器将以SUCCESS结束EAP-PSK对话框。
o Send a DONE_FAILURE to the server, which will end the EAP-PSK dialog with failure.
o 向服务器发送一个DONE_故障，这将以故障结束EAP-PSK对话框。
DONE_FAILURE indicates that the party that sent it deems the EAP-PSK dialog unsuccessful and proposes to end this dialog because nothing will make it change its mind.
DONE_FAILURE表示发送它的一方认为EAP-PSK对话不成功，并建议结束此对话，因为没有任何东西会使它改变主意。
If the server is the first to send a DONE_FAILURE, then the peer that receives this DONE_FAILURE must reply with a DONE_FAILURE and fail, which ends the EAP-PSK dialog.
如果服务器是第一个发送DONE_故障的，则接收该DONE_故障的对等方必须回复DONE_故障和fail，从而结束EAP-PSK对话框。
If the peer is the first to send a DONE_FAILURE, then the server that receives this DONE_FAILURE must immediately end this EAP-PSK dialog without sending any further EAP-PSK message, and fail.
如果对等方是第一个发送“已完成”故障的，则接收此“已完成”故障的服务器必须立即结束此EAP-PSK对话框，而不发送任何进一步的EAP-PSK消息，并且失败。
An extended authentication can only be started by the server.
扩展身份验证只能由服务器启动。
Exactly one extension (identified by the EXT_Type subfield of the EXT field) must be run during an EAP-PSK extended authentication dialog.
在EAP-PSK扩展身份验证对话框期间，必须只运行一个扩展（由扩展字段的EXT_Type子字段标识）。
The extension is run over the protected channel: it can assume confidentiality, integrity, and replay protection.
扩展在受保护的通道上运行：它可以承担机密性、完整性和重播保护。
To start an extended authentication, the server sets the PCHANNEL E flag to 1 and includes the EXT_Payload of the extension it has chosen.
要启动扩展身份验证，服务器将PCHANNEL E标志设置为1，并包括其选择的扩展的EXT_有效负载。
Since EAP-PSK does not provide fragmentation, the extension must not send an EXT_Payload larger than 960 bytes, which corresponds to the 1020-byte EAP MTU that may minimally be assumed (see [3]).
由于EAP-PSK不提供分段，因此扩展不能发送大于960字节的EXT_有效负载，这对应于可以最低限度假设的1020字节EAP MTU（参见[3]）。
Moreover, an extension must not send an empty EXT_Payload (because this has a particular meaning for EAP-PSK; see below).
此外，扩展不能发送空的EXT_负载（因为这对EAP-PSK有特殊意义；请参见下文）。
When the peer receives the third EAP-PSK message with the E flag set to 1, it checks whether it is able to process the proposed extension.
当对等方收到E标志设置为1的第三条EAP-PSK消息时，它检查是否能够处理提议的扩展。
If the peer is not able to process the proposed extension, i.e., it does not recognize the EXT_Type of the proposed extension, it sets E=1 in its reply (the fourth EAP-PSK message) and include an EXT field of the same EXT_Type but with an empty EXT_Payload.
如果对等方无法处理所提议的扩展，即，它不识别所提议扩展的EXT_类型，它将在其回复（第四条EAP-PSK消息）中设置e=1，并包括相同EXT_类型但具有空EXT_有效负载的EXT字段。
Depending on the values taken by the R flags, the EAP-PSK dialog may:
根据R标志采用的值，EAP-PSK对话框可能：
o End
o 终止
* If the peer's policy mandates that it fails in the case of an unrecognized extension, it sends a DONE_FAILURE in the fourth EAP-PSK message.
* 如果对等方的策略要求它在无法识别扩展的情况下失败，它将在第四条EAP-PSK消息中发送DONE_失败。
* If the server has sent a DONE_SUCCESS in the third EAP-PSK message, and the peer's policy authorizes it to succeed even if the extension is not recognized, the peer sends a DONE_SUCCESS.
* 如果服务器在第三条EAP-PSK消息中发送了一个DONE_SUCCESS，并且对等方的策略授权它成功，即使扩展未被识别，对等方也会发送DONE_SUCCESS。
o Continue for exactly one round-trip; namely, in case the server has sent a CONT in the third EAP-PSK message and the peer's policy authorizes it to succeed even if the extension is not recognized, the peer replies with a CONT in the fourth EAP-PSK message. The server must then, depending on its policy, send either a DONE_SUCCESS or a DONE_FAILURE to the peer in the fifth EAP-PSK message. If the server sent a DONE_SUCCESS in the fifth EAP-PSK message, the peer must send a DONE_SUCCESS in the sixth EAP-PSK message. All these messages must have the E flag set to 1 with an EXT field with the EXT_Type of the extension that was proposed and an empty EXT_Payload (this behavior was chosen to simplify implementations).
o 连续往返一次；即，如果服务器在第三个EAP-PSK消息中发送了CONT，并且对等方的策略授权它成功，即使扩展未被识别，对等方也会在第四个EAP-PSK消息中回复CONT。然后，服务器必须根据其策略，在第五条EAP-PSK消息中向对等方发送“完成”成功或“完成”失败。如果服务器在第五条EAP-PSK消息中发送了DONE_SUCCESS，则对等方必须在第六条EAP-PSK消息中发送DONE_SUCCESS。所有这些消息都必须将E标志设置为1，其中包含一个EXT字段，该字段具有所建议的扩展的EXT_类型，且EXT_有效负载为空（选择此行为是为了简化实现）。
If the peer is able to process the proposed extension, then it does so. In this case, the extension must be aware of the R values sent and received and able to propose to update them. All the subsequent messages exchanged between the peer and the server must have the E
如果对等方能够处理提议的扩展，那么它就会这样做。在这种情况下，扩展必须知道发送和接收的R值，并且能够建议更新它们。对等方和服务器之间交换的所有后续消息必须具有E
flag set to 1 with an EXT field of the EXT_Type of the extension that was proposed and a non-empty EXT_Payload.
标志设置为1，带有建议扩展的EXT_类型的EXT字段和非空EXT_有效负载。
This section provides guidance to the IANA regarding registration of values related to the EAP-PSK protocol, in accordance with [6].
本节根据[6]为IANA提供了有关EAP-PSK协议相关值注册的指南。
The following terms are used here with the meanings defined in [6]: "name space" and "registration".
此处使用的术语具有[6]中定义的含义：“名称空间”和“注册”。
The following policies are used here with the meanings defined in [6]: "Expert Review" and "Specification Required".
此处使用以下政策，其含义见[6]：“专家评审”和“所需规范”。
This document introduces one new Internet Assigned Numbers Authority (IANA) consideration: there is one name space in EAP-PSK that requires registration: the EXT_Type values (see Section 5.3 and Section 5.4).
本文件介绍了一个新的互联网分配号码管理局（IANA）注意事项：EAP-PSK中有一个名称空间需要注册：EXT_类型值（见第5.3节和第5.4节）。
For registration requests where a Designated Expert should be consulted, the responsible IETF Area Director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published. The Designated Expert will post a request to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
对于需要咨询指定专家的注册请求，IETF区域负责人应指定指定专家。其目的是，任何分配都将附带公布的RFC。但为了允许在批准发布RFC之前分配值，一旦确定RFC将发布，指定专家可以批准分配。指定专家将向EAP工作组邮件列表（或区域总监指定的继任者）发出请求，以征求意见和审查，包括互联网草案。在30天内，指定专家将批准或拒绝注册请求，并向EAP工作组邮件列表或其继任者发布决定通知，同时通知IANA。拒绝通知必须有理由作出解释，并在可能的情况下，就如何修改请求以使其成为可接受的请求提出具体建议。
IANA allocated a new EAP Type for EAP-PSK.
IANA为EAP-PSK分配了新的EAP类型。
EAP-PSK is not intended as a general-purpose protocol, and allocations of EXT_Type should not be made for purposes unrelated to authentication, authorization, and accounting.
EAP-PSK不是一个通用协议，EXT_类型的分配不应用于与身份验证、授权和记帐无关的目的。
EXT_Type numbers have a range from 1 to 255.
EXT_类型编号的范围为1到255。
EXT_Type 255 has been allocated for Experimental use.
EXT_类型255已分配用于实验用途。
EXT_Type 1-254 may be allocated on the advice of a Designated Expert, with Specification Required.
EXT_类型1-254可根据指定专家的建议进行分配，并需要规范。
[3] highlights several attacks that are possible against EAP, as EAP does not provide any robust security mechanism.
[3] 重点介绍了可能针对EAP的几种攻击，因为EAP不提供任何强健的安全机制。
This section discusses the claimed security properties of EAP-PSK as well as vulnerabilities and security recommendations in the threat model of [3].
本节讨论EAP-PSK声称的安全属性以及[3]的威胁模型中的漏洞和安全建议。
EAP-PSK provides mutual authentication.
EAP-PSK提供相互认证。
The server believes that the peer is authentic because it can calculate a valid MAC and the peer believes that the server is authentic because it can calculate another valid MAC.
服务器认为对等方是可信的，因为它可以计算一个有效的MAC，而对等方认为服务器是可信的，因为它可以计算另一个有效的MAC。
The authentication protocol that inspired EAP-PSK, AKEP2, enjoys a security proof in the provable security paradigm; see [14].
激发EAP-PSK的认证协议AKEP2在可证明安全范式中享有安全性证明；见[14]。
The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK, CMAC, also enjoys a security proof in the provable security paradigm; see [29]. A tag length of 16 bytes for CMAC is currently deemed appropriate by the cryptographic community for entity authentication.
EAP-PSK、CMAC中用于AKEP2实例化的MAC算法在可证明安全范式中也具有安全性证明；见[29]。CMAC的标签长度为16字节，目前被加密社区视为适用于实体身份验证。
The underlying block cipher used, AES-128, is widely believed to be a secure block cipher.
使用的底层分组密码AES-128被广泛认为是一种安全的分组密码。
Finally, the key used for mutual authentication, AK, is only used for that purpose, which makes this part cryptographically independent of the other parts of the protocol.
最后，用于相互认证的密钥AK仅用于此目的，这使得此部分在加密上独立于协议的其他部分。
EAP-PSK provides mutual authentication if it is based on a pairwise PSK of sufficient strength. If the PSK is not pairwise or not sufficiently strong, then it does not provide authentication. In this way, EAP-PSK is no different than other authentication protocols based on Pre-Shared Keys.
如果EAP-PSK基于具有足够强度的成对PSK，则EAP-PSK提供相互认证。如果PSK不是成对的或不够强，则它不提供身份验证。这样，EAP-PSK与其他基于预共享密钥的认证协议没有什么不同。
EAP-PSK provides protected result indications thanks to its 2-bit R flag (see Section 6.1). This 2-bit R flag is protected because it is encrypted and integrity protected by the EAX mode of operation; see Section 3.3.
EAP-PSK通过其2位R标志（见第6.1节）提供受保护的结果指示。该2位R标志受到保护，因为它是加密的，并且完整性受到EAX操作模式的保护；见第3.3节。
Care may be taken against Byzantine failures, that is to say, for instance, when a peer tries to force a server to engage in a never-ending conversation. This could, for example, be done by a peer that keeps sending a CONT after it has received a DONE_SUCCESS from the server. A policy may limit the number of rounds in an EAP-PSK extended authentication to mitigate this threat, which is outside our threat model.
可能需要注意拜占庭式的失败，也就是说，例如，当一个对等方试图强迫服务器进行无休止的对话时。例如，这可以由一个对等方完成，该对等方在从服务器收到done_成功后继续发送CONT。策略可能会限制EAP-PSK扩展身份验证中的轮数，以缓解此威胁，这超出了我们的威胁模型。
It should also be noted that the cryptographic protection of the result indications does not prevent message deletion.
还应注意，结果指示的加密保护并不阻止消息删除。
For instance, let us consider a scenario in which:
例如，让我们考虑一个场景：
o A server sends a DONE_SUCCESS to a peer.
o 服务器向对等方发送“完成”成功。
o The peer replies with a DONE_SUCCESS.
o 同伴以“完成”的成功回答。
In the case that the last message from the peer is intercepted, and an EAP Success is sent to the peer before any retransmission from the server reaches it, or the retransmissions from the server are also deleted, the peer will believe that it has successfully authenticated to the server while the server will fail.
如果截获了来自对等方的最后一条消息，并且在服务器的任何重传到达对等方之前向对等方发送了EAP成功消息，或者从服务器的重传也被删除，则对等方将认为它已成功通过服务器身份验证，而服务器将失败。
This behavior is well known (see, e.g., [23]) and in a sense unavoidable. There is a trade-off between efficiency and the "level" of information sharing that is attainable. EAP-PSK specified a single round-trip of DONE_SUCCESS because it is believed that:
这种行为是众所周知的（参见，例如[23]），并且在某种意义上是不可避免的。效率和可实现的信息共享“水平”之间存在权衡。EAP-PSK规定了单次成功往返，因为人们相信：
o If there is an adversary capable of disrupting the communication channel, it can do so whenever it wants (be it after 1 or 10 round-trips or even during data communication).
o 如果有一个对手能够中断通信信道，它可以随时这样做（无论是在1次或10次往返之后，甚至是在数据通信期间）。
o Other layers/applications will generally start by doing a specific key exchange and confirmation procedure using the keys derived by EAP-PSK. This is typically done by IEEE 802.11i "four-way handshake". In case the error is not detected by EAP-PSK, it should be detected then (please note, however, that it is bad practice to rely on an external mechanism to ensure synchronization, unless this is an explicit property of the external mechanism).
o 其他层/应用程序通常首先使用EAP-PSK派生的密钥执行特定的密钥交换和确认程序。这通常由IEEE 802.11i“四向握手”完成。如果EAP-PSK没有检测到错误，那么应该检测到错误（但是，请注意，依赖外部机制来确保同步是不好的做法，除非这是外部机制的显式属性）。
EAP-PSK provides integrity protection thanks to the Tag of its protected channel (see Section 3.3).
EAP-PSK通过其受保护信道的标签提供完整性保护（见第3.3节）。
EAP-PSK provides integrity protection if it is based on a pairwise PSK of sufficient strength. If the PSK is not pairwise or not sufficiently strong, then it does not provide authentication. In this way, it is no different than other authentication protocols based on Pre-Shared Keys.
如果EAP-PSK基于具有足够强度的成对PSK，则可提供完整性保护。如果PSK不是成对的或不够强，则它不提供身份验证。这样，它与其他基于预共享密钥的身份验证协议没有什么不同。
EAP-PSK provides replay protection of its mutual authentication part thanks to the use of random numbers RAND_S and RAND_P. Since RAND_S is 128 bits long, one expects to have to record 2**64 (i.e., approximately 1.84*10**19) EAP-PSK successful authentications before an authentication can be replayed. Hence, EAP-PSK provides replay protection of its mutual authentication part as long as RAND_S and RAND_P are chosen at random; randomness is critical for security.
由于使用随机数RAND_S和RAND_P，EAP-PSK为其相互认证部分提供了重放保护。由于RAND_S为128位长，人们希望在重放认证之前必须记录2**64（即大约1.84*10**19）EAP-PSK成功认证。因此，EAP-PSK为其相互认证部分提供重播保护，只要随机选择RAND_S和RAND_P；随机性对安全性至关重要。
EAP-PSK provides replay protection during the conversation of the protected channel thanks to the Nonce N of its protected channel (see Section 3.3). This nonce is initialized to 0 by the server and monotonically incremented by one by the party that receives a valid EAP-PSK message. For instance, after receiving from the server a valid EAP-PSK message with Nonce set to x, the peer will answer with an EAP-PSK message with Nonce set to x+1 and wait for an EAP-PSK message with Nonce set to x+2. A retransmission of the server's message with Nonce set to x would cause the peer EAP layer to resend the message in which Nonce was set to x+1, which would be transparent to the EAP-PSK layer.
EAP-PSK由于其受保护信道的暂时性，在受保护信道的会话期间提供重播保护（见第3.3节）。此nonce由服务器初始化为0，并由接收有效EAP-PSK消息的一方单调递增1。例如，在从服务器接收到Nonce设置为x的有效EAP-PSK消息后，对等方将使用Nonce设置为x+1的EAP-PSK消息进行应答，并等待Nonce设置为x+2的EAP-PSK消息。重新传输Nonce设置为x的服务器消息将导致对等EAP层重新发送Nonce设置为x+1的消息，这对EAP-PSK层是透明的。
The EAP peer must check that the Nonce is indeed initialized to 0 by the server.
EAP对等方必须检查Nonce是否确实由服务器初始化为0。
EAP-PSK provides protection against reflection attacks in case of an extended authentication because:
EAP-PSK在扩展身份验证的情况下提供了针对反射攻击的保护，因为：
o It integrity protects the EAP header (which contains the indication Request/Response.
o It完整性保护EAP标头（其中包含指示请求/响应）。
o It includes two separate spaces for the Nonces: the EAP server only receives messages with odd nonces, whereas the EAP peer only receives messages with even nonces.
o 它包含两个独立的nonce空间：EAP服务器仅接收具有奇数nonce的消息，而EAP对等方仅接收具有偶数nonce的消息。
Because EAP-PSK is not a password protocol, it is not vulnerable to dictionary attacks.
由于EAP-PSK不是密码协议，因此不易受到字典攻击。
Indeed, the PSK used by EAP-PSK must not be derived from a password. Derivation of the PSK from a password may lead to dictionary attacks.
事实上，EAP-PSK使用的PSK不能来自密码。从密码派生PSK可能会导致字典攻击。
However, using a 16-byte PSK has:
但是，使用16字节PSK有：
o Ergonomic impacts: some people may find it cumbersome to manually provision a 16-byte PSK.
o 人体工程学影响：一些人可能会发现手动提供16字节PSK很麻烦。
o Deployment impacts: some people may want to reuse existing credential databases that contain passwords and not PSKs.
o 部署影响：有些人可能希望重用包含密码而不是PSK的现有凭据数据库。
Because people will probably not heed the warning not to use passwords, guidance to derive a PSK from a password is provided in Appendix A. The method proposed in Appendix A only tries to make dictionary attacks harder. It does not eliminate them.
由于人们可能不会注意到不使用密码的警告，因此附录a中提供了从密码推导PSK的指南。附录a中提出的方法只会使字典攻击更加困难。它并没有消除它们。
However, it does not cause a fatal error if passwords are used instead of PSKs: people rarely use password-derived certificates, so why should they do so for shared keys?
但是，如果使用密码而不是PSK，则不会导致致命错误：人们很少使用密码派生的证书，那么为什么要对共享密钥这样做呢？
EAP-PSK supports key derivation.
EAP-PSK支持密钥派生。
The key hierarchy is specified in Section 2.1.
第2.1节规定了密钥层次结构。
The mechanism used for key derivation is the modified counter mode.
用于密钥派生的机制是修改的计数器模式。
The instantiation of the modified counter in EAP-PSK complies with the conditions stated in [5] so that the security proof for this mode holds.
EAP-PSK中修改计数器的实例化符合[5]中规定的条件，因此该模式的安全性证明成立。
The underlying block cipher used, AES-128, is widely believed to be a secure block cipher.
使用的底层分组密码AES-128被广泛认为是一种安全的分组密码。
A first key derivation occurs to calculate AK and KDK from the PSK: it is called the key setup (see Section 3.1). It uses the PSK as the key to the modified counter mode. Thus, AK and KDK are believed to be cryptographically separated and computable only to those who have knowledge of the PSK.
第一个密钥派生用于从PSK计算AK和KDK：称为密钥设置（见第3.1节）。它使用PSK作为修改计数器模式的键。因此，AK和KDK被认为是密码学上分离的，并且只有了解PSK的人才能计算。
A second key derivation occurs to derive session keys, namely, the TEK, MSK, and EMSK (see Section 3.2). It uses KDK as the key to the modified counter mode.
第二个密钥派生用于派生会话密钥，即TEK、MSK和EMSK（参见第3.2节）。它使用KDK作为修改计数器模式的键。
The protocol design explicitly assumes that neither AK nor KDK are shared beyond the two parties utilizing them. AK loses its efficacy to mutually authenticate the peer and server with each other when it is shared. Similarly, the derived TEK, MSK, and EMSK lose their value when KDK is shared with a third party.
协议设计明确假设，除了使用AK和KDK的双方之外，AK和KDK都不共享。AK在共享对等方和服务器时失去了相互验证对等方和服务器的效力。类似地，当KDK与第三方共享时，派生的TEK、MSK和EMSK也会失去价值。
It should be emphasized that the peer has control of the session keys derived by EAP-PSK. In particular, it can easily choose the random number it sends in EAP-PSK so that one of the nine derived 16-byte key blocks (see Section 2.1) takes a pre-specified value.
应该强调的是，对等方可以控制EAP-PSK派生的会话密钥。特别是，它可以轻松地选择在EAP-PSK中发送的随机数，以便九个派生的16字节密钥块（见第2.1节）中的一个采用预先指定的值。
It was chosen not to prevent this control of the session keys by the peer because:
已选择不阻止对等方对会话密钥进行此控制，因为：
o Preventing it would have added some complexity to the protocol (typically, the inclusion of a one-way mode of operation of AES in the key derivation part).
o 阻止它会给协议增加一些复杂性（通常，在密钥派生部分包含AES的单向操作模式）。
o It is believed that the peer won't try to force the server to use some pre-specified value for the session keys. Such an attack is outside the threat model and seems to have little value compared to a peer sharing its PSK.
o 据信，对等方不会试图强制服务器为会话密钥使用某些预先指定的值。这种攻击超出了威胁模型，与共享其PSK的对等方相比，似乎没有什么价值。
However, this is not the behavior recommended by EAP in Section 7.10 of [3].
然而，这不是EAP在[3]第7.10节中建议的行为。
Since deriving the session keys requires some cryptographic computations, it is recommended that the session keys be derived only once authentication has succeeded (i.e., once the server has successfully verified MAC_P for the server side, and once the peer has successfully verified MAC_S for the peer side).
由于导出会话密钥需要一些加密计算，因此建议仅在身份验证成功后（即，服务器成功验证了服务器端的MAC_P，并且对等方成功验证了对等方的MAC_S）才导出会话密钥。
It is recommended to take great care in implementations, so that derived keys are not made available if the EAP-PSK dialog fails (e.g., ends with DONE_FAILURE).
建议在实现过程中格外小心，以便在EAP-PSK对话框失败（例如，以“完成”失败结束）时，派生密钥不可用。
The TEK must not be made available to anyone except to the current EAP-PSK dialog.
除当前EAP-PSK对话框外，不得向任何人提供TEK。
Denial of Service (DoS) resistance has not been a design goal for EAP-PSK.
EAP-PSK的设计目标不是抵抗拒绝服务（DoS）。
It is, however, believed that EAP-PSK does not provide any obvious and avoidable venue for such attacks.
然而，据信EAP-PSK并未为此类攻击提供任何明显且可避免的场所。
It is worth noting that the server has to do a cryptographic calculation and maintain some state when it engages in an EAP-PSK conversation, namely, generate and remember the 16-byte RAND_S. However, this should not lead to resource exhaustion as this state and the associated computation are fairly lightweight.
值得注意的是，当服务器参与EAP-PSK对话时，服务器必须进行加密计算并保持某些状态，即生成并记住16字节随机数。但是，这不应导致资源耗尽，因为此状态和相关计算相当轻量级。
Please note that both the peer and the server must commit to their RAND_S and RAND_P to protect their partners from flooding attacks.
请注意，对等方和服务器都必须向其RAND_S和RAND_P承诺，以保护其合作伙伴免受洪水攻击。
It is recommended that EAP-PSK not allow EAP notifications to be interleaved in its dialog to prevent potential DoS attacks. Indeed, since EAP notifications are not integrity protected, they can easily be spoofed by an attacker. Such an attacker could force a peer that allows EAP notifications to engage in a discussion that would delay his or her authentication or result in the peer taking unexpected actions (e.g., in case a notification is used to prompt the peer to do some "bad" action).
建议EAP-PSK不允许EAP通知在其对话框中交错，以防止潜在的DoS攻击。事实上，由于EAP通知不受完整性保护，攻击者很容易欺骗它们。此类攻击者可能会迫使允许EAP通知的对等方参与讨论，从而延迟其身份验证或导致对等方采取意外操作（例如，如果通知被用于提示对等方执行某些“错误”操作）。
It is up to the implementation of EAP-PSK or to the peer and the server to specify the maximum number of failed cryptographic checks that are allowed. For instance, does the reception of a bogus MAC_P in the second EAP-PSK message cause a fatal error or is it discarded to continue waiting for the valid response of the valid peer? There is a trade-off between possibly allowing multiple tentative forgeries and allowing a direct DoS (in case the first error is fatal).
由EAP-PSK的实现或对等方和服务器指定允许的最大失败加密检查数。例如，在第二个EAP-PSK消息中接收到虚假MAC_P是否会导致致命错误，或者是否放弃该错误以继续等待有效对等方的有效响应？在允许多个临时伪造和允许直接拒绝（如果第一个错误是致命的）之间有一个权衡。
For the sake of simplicity and denial-of-service resilience, EAP-PSK has chosen not to include any error messages. Hence, an "invalid" EAP-PSK message is silently discarded. Although this makes interoperability testing and debugging harder, this leads to simpler implementations and does not open any venue for denial-of-service attacks.
为了简单性和拒绝服务弹性，EAP-PSK选择不包含任何错误消息。因此，“无效”EAP-PSK消息将被静默丢弃。尽管这使得互操作性测试和调试更加困难，但这会导致更简单的实现，并且不会为拒绝服务攻击打开任何场所。
Thanks to its key derivation mechanisms, EAP-PSK provides session independence: passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK or EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs.
由于其密钥派生机制，EAP-PSK提供了会话独立性：被动攻击（如捕获EAP会话）或主动攻击（包括MSK或EMSK的泄露）无法泄露后续或先前的MSK或EMSK。
The assumption that RAND_P and RAND_S are random is central for the security of EAP-PSK in general and session independence in particular.
RAND_P和RAND_S是随机的假设对于EAP-PSK的安全性尤其是会话独立性至关重要。
EAP-PSK does not provide Perfect Forward Secrecy. Compromise of the PSK leads to compromise of recorded past sessions.
EAP-PSK不提供完美的前向保密。PSK的妥协导致过去记录的会议的妥协。
Compromise of the PSK enables the attacker to impersonate the peer and the server: compromise of the PSK leads to "full" compromise of future sessions.
PSK泄露使攻击者能够模拟对等方和服务器：PSK泄露会导致未来会话的“完全”泄露。
EAP-PSK provides no protection against a legitimate peer sharing its PSK with a third party. Such protection may be provided by appropriate repositories for the PSK, whose choice is outside the scope of this document. The PSK used by EAP-PSK must only be shared between two parties: the peer and the server. In particular, this PSK must not be shared by a group of peers communicating with the same server.
EAP-PSK不针对与第三方共享其PSK的合法对等方提供保护。此类保护可由PSK的适当存储库提供，其选择不在本文档范围内。EAP-PSK使用的PSK只能在两方之间共享：对等方和服务器。特别是，与同一服务器通信的一组对等方不能共享此PSK。
The PSK used by EAP-PSK must be cryptographically separated from keys used by other protocols, otherwise the security of EAP-PSK may be compromised. It is a rule of thumb in cryptography to use different keys for different applications.
EAP-PSK使用的PSK必须以加密方式与其他协议使用的密钥分开，否则EAP-PSK的安全性可能会受到损害。密码学中的经验法则是为不同的应用程序使用不同的密钥。
EAP-PSK does not support fragmentation and reassembly.
EAP-PSK不支持碎片和重新组装。
Indeed, the largest EAP-PSK frame is at most 1015 bytes long, because:
实际上，最大EAP-PSK帧的长度最多为1015字节，因为：
o The maximum length for the peer NAI identity used in EAP-PSK is 966 bytes (see Section 5.2). This should not be a limitation in practice (see Section 2.2 of [2] for more considerations on NAI length).
o EAP-PSK中使用的对等NAI标识的最大长度为966字节（见第5.2节）。这不应成为实践中的限制（有关NAI长度的更多考虑，请参见[2]第2.2节）。
o The maximum length for the EXT_Payload field used in EAP-PSK is 960 bytes (see Section 5.3 and Section 5.4).
o EAP-PSK中使用的EXT_有效负载字段的最大长度为960字节（见第5.3节和第5.4节）。
Per Section 3.1 of [3], the lower layers over which EAP may be run are assumed to have an EAP MTU of 1020 bytes or greater. Since the EAP header is 5 bytes long, supporting fragmentation for EAP-PSK is unnecessary.
根据[3]第3.1节，可运行EAP的较低层假定具有1020字节或更大的EAP MTU。由于EAP标头的长度为5字节，因此不需要支持EAP-PSK的分段。
Extensions that require sending a payload larger than 960 bytes should provide their own fragmentation and reassembly mechanism.
需要发送大于960字节的有效负载的扩展应该提供自己的碎片和重组机制。
EAP-PSK does not provide channel binding as this feature is still very much a work in progress (see [13]).
EAP-PSK不提供通道绑定，因为此功能仍在进行中（请参见[13]）。
However, it should be easy to add it to EAP-PSK as an extension (see Section 4.2).
但是，将其作为扩展添加到EAP-PSK中应该很容易（参见第4.2节）。
EAP-PSK does not provide any fast reconnect capability.
EAP-PSK不提供任何快速重新连接功能。
Indeed, as noted, for instance, in [15], mutual authentication (without counters or timestamps) requires three exchanges, thus four exchanges in EAP since any EAP-Request must be answered to by an EAP-Response.
事实上，如[15]所述，例如，相互认证（无计数器或时间戳）需要三次交换，因此在EAP中需要四次交换，因为任何EAP请求都必须由EAP响应来响应。
Since this minimum bound is already reached in EAP-PSK standard authentication, there is no way the number of round-trips used within EAP-PSK can be reduced without using timestamps or counters. Timestamps and counters were deliberately avoided for the sake of simplicity and security (e.g., synchronization issues).
由于在EAP-PSK标准认证中已达到该最小界限，因此在不使用时间戳或计数器的情况下，无法减少EAP-PSK中使用的往返次数。为了简单和安全起见（例如，同步问题），故意避免使用时间戳和计数器。
Since it was chosen to restrict to a single cryptographic primitive from symmetric cryptography, namely, the block cipher AES-128, it appears that it is not possible to provide "reasonable" identity protection without failing to meet the simplicity goal.
由于选择它是为了限制对称密码中的单个密码原语，即分组密码AES-128，因此似乎不可能提供“合理”的身份保护而不满足简单性目标。
Hereafter is an informal discussion of what is meant by identity protection and the rationale behind the requirement of identity protection. For some complementary discussion, refer to [37].
下文将非正式讨论身份保护的含义以及身份保护要求背后的基本原理。有关补充讨论，请参阅[37]。
Identity protection basically means preventing the disclosure of the identities of the communicating parties over the network, which is quite contradictory to authentication. There are two levels of identity protection: protection against passive attackers and protection against active eavesdroppers.
身份保护基本上意味着防止通信方的身份在网络上被泄露，这与身份验证非常矛盾。身份保护分为两个级别：针对被动攻击者的保护和针对主动窃听者的保护。
As explained in [37], "a common example [for identity protection] is the case of mobile devices wishing to prevent an attacker from correlating their (changing) location with the logical identity of the device (or user)".
如[37]所述，“一个常见的[身份保护]示例是移动设备希望防止攻击者将其（更改）位置与设备（或用户）的逻辑身份相关联”。
If only symmetric cryptography is used, only a weak form of identity protection may be offered, namely, pseudonym management. In other words, the peer and the server agree on pseudonyms that they use to
如果只使用对称加密，则只能提供一种弱形式的身份保护，即假名管理。换言之，对等方和服务器在使用笔名时达成一致
identify each other and usually change them periodically, possibly in a protected way so that an attacker cannot learn new pseudonyms before they are used.
相互识别，通常定期更改它们，可能是以受保护的方式，以便攻击者在使用新的假名之前无法了解它们。
With pseudonym management, there is a trade-off between allowing for pseudonym resynchronization (thanks to a permanent identity) and being vulnerable to active attacks (in which the attacker forges messages simulating a pseudonym desynchronization).
使用笔名管理，在允许笔名重新同步（由于永久身份）和易受主动攻击（攻击者伪造模拟笔名取消同步的消息）之间存在权衡。
Indeed, a protocol using time-varying pseudonyms may want to anticipate "desynchronization" situations such as, for instance, when the peer believes that its current pseudonym is "pseudo1@bigco.com" whereas the server believes this peer will use the pseudonym "pseudo2@bigco.com" (which is the pseudonym the server has sent to update "pseudo1@bigco.com").
事实上，使用时变化名的协议可能希望预测“去同步”情况，例如，当对等方认为其当前化名为pseudo1@bigco.com“而服务器认为该对等方将使用笔名”pseudo2@bigco.com“（这是服务器发送用于更新的笔名"pseudo1@bigco.com").
Because pseudonym management adds complexity to the protocol and implies this unsatisfactory trade-off, it was decided not to include this feature in EAP-PSK.
由于笔名管理增加了协议的复杂性，并暗示了这一不令人满意的权衡，因此决定在EAP-PSK中不包括此功能。
However, EAP-PSK may trivially provide some protection when the concern is to avoid the "real-life" identity of the user being "discovered". For instance, let us take the example of user John Doe that roams and connects to a Hot-Spot owned and operated by Wireless Internet Service Provider (WISP) BAD. Suppose this user authenticates to his home WISP (WISP GOOD) with an EAP method under an identity (e.g., "john.doe@wispgood.com") that allows WISP BAD (or an attacker) to recover his "real-life" identity, i.e., John Doe. An example drawback of this is when a competitor of John Doe's WISP wants to win John Doe as a new customer by sending him some special targeted advertisement.
然而，EAP-PSK可能会提供一些保护，当关注点是避免“发现”用户的“真实”身份时。例如，让我们以用户John Doe为例，他漫游并连接到由无线互联网服务提供商（WISP）拥有和运营的热点。假设该用户使用一个身份（例如，“john”）下的EAP方法对其家庭WISP（WISP GOOD）进行身份验证。doe@wispgood.com）使WISP BAD（或攻击者）恢复其“真实”身份，即John Doe。这样做的一个缺点是，John Doe WISP的一个竞争对手希望通过向John Doe发送一些特别针对性的广告来赢得John Doe作为新客户的地位。
EAP-PSK can very simply thwart this attack, merely by avoiding to provide John Doe with an NAI that allows easy recovery of his real-life identity. It is believed that when an NAI that is not correlated to a real-life identity is used, no valuable information leaks because of the EAP method.
EAP-PSK可以非常简单地挫败这一攻击，只需避免向John Doe提供NAI即可轻松恢复其真实身份。人们相信，当使用与真实身份不相关的NAI时，不会因为EAP方法而泄露有价值的信息。
Indeed, the identity of the WISP used by a peer has to be disclosed anyway in the realm portion of its NAI to allow AAA routing. Moreover, the Medium Access Control Address of the peer's Network Interface Card can generally be used to track the peer as efficiently as a fixed NAI.
事实上，对等方使用的WISP的身份必须在其NAI的领域部分公开，以允许AAA路由。此外，对等方的网络接口卡的介质访问控制地址通常可以与固定NAI一样有效地用于跟踪对等方。
It is worth noting that the server systematically discloses its identity, which may allow probing attacks. This may not be a problem as the identity of the server is not supposed to remain secret. On the contrary, users tend to want to know to whom they will be talking in order to choose the right network to attach to.
值得注意的是，服务器系统性地公开其身份，这可能允许探测攻击。这可能不是问题，因为服务器的身份不应该保持机密。相反，用户往往想知道他们将与谁交谈，以便选择合适的网络连接。
EAP-PSK does not allow negotiating ciphersuites. Hence, it is not vulnerable to negotiation attacks and does not implement protected ciphersuite negotiation.
EAP-PSK不允许协商密码套件。因此，它不易受到协商攻击，并且不实现受保护的密码套件协商。
Although EAP-PSK provides confidentiality in its protected channel, it cannot claim to do so as per Section 7.2.1 of [3]: "A method making this claim must support identity protection".
尽管EAP-PSK在其受保护的信道中提供机密性，但它不能根据[3]第7.2.1节：“提出此声明的方法必须支持身份保护”。
Since EAP-PSK is not intended to be tunneled within another protocol that omits peer authentication, it does not implement cryptographic binding.
由于EAP-PSK不打算在另一个忽略对等身份验证的协议中进行隧道传输，因此它不实现加密绑定。
To really provide security, not only must a protocol be well thought-out and correctly specified, but its implementation must take special care.
要真正提供安全性，不仅必须精心设计和正确指定协议，而且必须特别注意其实现。
For instance, implementing cryptographic algorithms requires special skills since cryptographic software is vulnerable not only to classical attacks (e.g., buffer overflow or missing checks) but also to some special cryptographic attacks (e.g., side channels attacks like timing ones; see [36]). In particular, care must be taken to avoid such attacks in EAX implementation; please refer to [4] for a note on this point.
例如，实施加密算法需要特殊技能，因为加密软件不仅容易受到经典攻击（例如，缓冲区溢出或丢失检查），而且容易受到某些特殊加密攻击（例如，边通道攻击，如定时攻击；请参见[36]）。特别是，在EAX实现中必须注意避免此类攻击；有关这一点的说明，请参考[4]。
An EAP-PSK implementation should use a good source of randomness to generate the random numbers required in the protocol. Please refer to [20] for more information on generating random numbers for security applications.
EAP-PSK实现应使用良好的随机性源来生成协议中所需的随机数。有关为安全应用程序生成随机数的更多信息，请参阅[20]。
Handling sensitive material (namely, keying material such as the PSK, AK, KDK, etc.) should be done in a secure way (see, for instance, [19] for guidance on secure deletion).
应以安全的方式处理敏感材料（即，密钥材料，如PSK、AK、KDK等）（例如，有关安全删除的指南，请参见[19]）。
The specification of a repository for the PSK that EAP-PSK uses is outside the scope of this document. In particular, nothing prevents one from storing this PSK on a tamper-resistant device such as a smart card rather than having it memorized or written down on a sheet of paper. The choice of the PSK repository may have important security impacts.
EAP-PSK使用的PSK存储库规范不在本文档范围内。特别是，没有任何东西可以阻止人们将此PSK存储在防篡改设备（如智能卡）上，而不是将其存储或写在一张纸上。PSK存储库的选择可能会产生重要的安全影响。
This section provides the security claims required by [3].
本节提供了[3]要求的担保索赔。
[a] Mechanism. EAP-PSK is based on symmetric cryptography (AES-128) and uses a 16-byte Pre-Shared Key (PSK).
[a] 机械装置EAP-PSK基于对称加密（AES-128）并使用16字节预共享密钥（PSK）。
[b] Security claims. EAP-PSK provides:
[b] 担保索赔。EAP-PSK提供：
* Mutual authentication (see Section 8.1)
* 相互认证（见第8.1节）
* Integrity protection (see Section 8.3)
* 完整性保护（见第8.3节）
* Replay protection (see Section 8.4)
* 重播保护（见第8.4节）
* Key derivation (see Section 8.7)
* 密钥推导（见第8.7节）
* Dictionary attack resistance (see Section 8.6)
* 字典抗攻击性（见第8.6节）
* Session independence (see Section 8.9)
* 会话独立性（见第8.9节）
[c] Key strength. EAP-PSK provides a 16-byte effective key strength.
[c] 关键力量。EAP-PSK提供16字节的有效密钥强度。
[d] Description of key hierarchy. Please see Section 2.1.
[d] 密钥层次结构的描述。请参见第2.1节。
[e] Indication of vulnerabilities. EAP-PSK does not provide:
[e] 漏洞指示。EAP-PSK不提供：
* Identity protection (see Section 8.14)
* 身份保护（见第8.14节）
* Confidentiality (see Section 8.16)
* 保密性（见第8.16节）
* Fast reconnect (see Section 8.13)
* 快速重新连接（见第8.13节）
* Fragmentation (see Section 8.11)
* 碎片（见第8.11节）
* Cryptographic binding (see Section 8.17)
* 加密绑定（见第8.17节）
* Protected ciphersuite negotiation (see Section 8.15)
* 受保护的密码套件协商（见第8.15节）
* Perfect Forward Secrecy (see Section 8.10)
* 完全前向保密（见第8.10节）
* Key agreement: the session key is chosen by the peer (see Section 8.7)
* 密钥协议：会话密钥由对等方选择（见第8.7节）
* Channel binding (see Section 8.12)
* 通道绑定（见第8.12节）
This EAP method has been inspired by EAP-Archie and EAP-SIM. Many thanks to their respective authors: Jesse Walker (extra thanks to Jesse Walker for his thorough and challenging expert review of EAP-PSK), Russ Housley, Henry Haverinen, and Joseph Salowey.
此EAP方法受EAP-Archie和EAP-SIM的启发。非常感谢他们各自的作者：Jesse Walker（特别感谢Jesse Walker对EAP-PSK进行了全面而富有挑战性的专家评审）、Russ Housley、Henry Haverinen和Joseph Salowey。
Thanks to
幸亏
o Henri Gilbert for some interesting discussions on the cryptographic parts of EAP-PSK.
o Henri Gilbert就EAP-PSK的密码部分进行了一些有趣的讨论。
o Aurelien Magniez for his valuable feedback on network aspects of EAP-PSK, his curiosity and rigor that led to numerous improvements, and his help in the first implementation of EAP-PSK under Microsoft Windows and Freeradius.
o Aurelian Magniez感谢他对EAP-PSK网络方面的宝贵反馈，他的好奇心和严谨导致了许多改进，以及他在Microsoft Windows和Freeradius下首次实施EAP-PSK方面的帮助。
o Thomas Otto for his valuable feedback on EAP-PSK and the implementation of the first version of EAP-PSK under Xsupplicant.
o Thomas Otto感谢他对EAP-PSK和Xsupplicant下EAP-PSK第一版实施的宝贵反馈。
o Nancy Cam-Winget for some exchanges on EAP-PSK.
o Nancy Cam Winget在EAP-PSK上进行了一些交流。
o Jari Arkko and Bernard Aboba, the beloved EAP WG chairs, for the work they stimulate.
o Jari Arkko和Bernard Aboba，受人喜爱的EAP工作组主席，感谢他们激励的工作。
Finally, thanks to Vir Z., who has brought a permanent and outstanding though discreet contribution to this protocol.
最后，感谢Vir Z.，他为本协议带来了永久和杰出但谨慎的贡献。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[2] Aboba，B.，Beadles，M.，Arkko，J.，和P.Eronen，“网络接入标识符”，RFC 42822005年12月。
[3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[3] Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[4] Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of operation", FSE 04, Springer-Verlag LNCS 3017, 2004.
[4] Bellare，M.，Rogaway，P.，和D.Wagner，“EAX运行模式”，FSE 04，Springer Verlag LNCS 30172004。
[5] Gilbert, H., "The Security of One-Block-to-Many Modes of Operation", FSE 03, Springer-Verlag LNCS 2287, 2003.
[5] Gilbert，H.，“一个区块对多种运行模式的安全性”，FSE 03，Springer Verlag LNCS 2287，2003年。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[7] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", Federal Information Processing Standards (FIPS) 197, November 2001.
[7] 国家标准与技术研究所，“高级加密标准（AES）规范”，联邦信息处理标准（FIPS）197，2001年11月。
[8] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", Special Publication (SP) 800-38B, May 2005.
[8] 国家标准与技术研究所，“分组密码操作模式的建议：用于认证的CMAC模式”，特别出版物（SP）800-38B，2005年5月。
[9] Aboba, B., Simon, D., Eronen, P., and H. Levkowetz,"Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2006.
[9] Aboba，B.，Simon，D.，Eronen，P.，和H.Levkowetz，“可扩展认证协议（EAP）密钥管理框架”，正在进行的工作，2006年10月。
[10] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Walsh, P., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Xu, Y., Campell, E., Baba, S., and E. Jaques, "Criteria for Evaluating AAA Protocols for work Access", RFC 2989, November 2000.
[10] Aboba，B.，Calhoun，P.，Glass，S.，Hiller，T.，McCann，P.，Shiino，H.，Zorn，G.，Dommety，G.，Perkins，C.，Patil，B.，Mitton，D.，Manning，S.，Beadles，M.，Walsh，P.，Chen，X.，Sivalingham，S.，Hameed，A.，Munson，M.，Jacobs，S.，Lim，B.，Hirschman，B.，Hsu，R.，Xu，Y.，Campell，E.，Baba，S.，和E.Jaques，“评估工作准入AAA协议的标准”，RFC 2989，2000年11月。
[11] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[11] Aboba，B.和D.Simon，“PPP EAP TLS认证协议”，RFC 2716，1999年10月。
[12] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[12] Arkko，J.和H.Haverinen，“第三代认证和密钥协议（EAP-AKA）的可扩展认证协议方法”，RFC 4187，2006年1月。
[13] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2005.
[13] Arkko，J.和P.Eronen，“可扩展认证协议（EAP）的认证服务信息”，正在进行的工作，2005年10月。
[14] Bellare, M. and P. Rogaway, "Entity Authentication and Key Distribution", CRYPTO 93, Springer-Verlag LNCS 773, 1994.
[14] Bellare，M.和P.Rogaway，“实体认证和密钥分发”，CRYPTO 93，Springer Verlag LNCS 773，1994年。
[15] Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated Key Exchange Secure Against Dictionary attacks", EUROCRYPT 00, Springer-Verlag LNCS 1807, 2000.
[15] Bellare，M.，Pointcheval，D.，和P.Rogaway，“针对字典攻击的认证密钥交换安全”，EUROCRYPT 00，Springer Verlag LNCS 180720000。
[16] Bersani, F., "EAP shared key methods: a tentative synthesis of those proposed so far", Work in Progress, April 2004.
[16] Bersani，F.，“EAP共享关键方法：迄今提出的方法的初步综合”，进展中的工作，2004年4月。
[17] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[17] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[18] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", Work in Progress, July 2001.
[18] Carlson，J.，Aboba，B.，和H.Haverinen，“EAP SRP-SHA1认证协议”，正在进行的工作，2001年7月。
[19] Department of Defense of the United States, "National Industrial Security Program Operating Manual", DoD 5220-22M, January 1995.
[19] 美国国防部，《国家工业安全计划操作手册》，国防部5220-22M，1995年1月。
[20] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[20] Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[21] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol (EAP-TTLS)", Work in Progress, July 2004.
[21] Funk，P.和S.Blake Wilson，“EAP隧道TLS认证协议（EAP-TTLS）”，正在进行的工作，2004年7月。
[22] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", RFC 2289, February 1998.
[22] N.Haller、C.Metz、P.Nesser和M.Straw，“一次性密码系统”，RFC 2289，1998年2月。
[23] Halpern, J. and Y. Moses, "Knowledge and common knowledge in a distributed environment", Journal of the ACM 37:3, 1990.
[23] Halpern，J.和Y.Moses，“分布式环境中的知识和公共知识”，ACM杂志37:31990。
[24] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.
[24] Haverinen，H.和J.Salowey，“全球移动通信系统（GSM）用户身份模块（EAP-SIM）的可扩展认证协议方法”，RFC 4186，2006年1月。
[25] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995.
[25] Huitema，C.，Postel，J.和S.Crocker，“并非所有RFC都是标准”，RFC 1796，1995年4月。
[26] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.
[26] 电气和电子工程师协会，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X，2001年9月。
[27] Institute of Electrical and Electronics Engineers, "Approved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems-LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE 802.11i-2004, 2004.
[27] 电气和电子工程师协会，“系统间电信和信息交换标准的批准补充草案LAN/MAN特定要求-第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范：增强安全规范”，IEEE 802.11i-2004，2004年。
[28] Institute of Electrical and Electronics Engineers, "Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
[28] 电气和电子工程师协会，“系统间电信和信息交换标准——LAN/MAN特定要求——第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.111999。
[29] Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 03, Springer-Verlag LNCS 2887, 2003.
[29] 岩田，T.和K.黑泽明，“OMAC：一个关键的CBC MAC”，FSE 03，斯普林格-维拉格LNCS 2887，2003年。
[30] Jablon, D., "The SPEKE Password-Based Key Agreement Methods", Work in Progress, November 2002.
[30] Jablon，D.，“基于SPEKE密码的密钥协商方法”，正在进行的工作，2002年11月。
[31] Josefsson, S., "The EAP SecurID(r) Mechanism", Work in Progress, February 2002.
[31] Josefsson，S.，“EAP SecurID（r）机制”，正在进行的工作，2002年2月。
[32] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[32] Josefsson，S.，Palekar，A.，Simon，D.，和G.Zorn，“受保护的EAP协议（PEAP）版本2”，正在进行的工作，2004年10月。
[33] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[33] Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 28982000年9月。
[34] Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions", Work in Progress, April 2004.
[34] Kamath，V.和A.Palekar，“Microsoft EAP CHAP扩展”，正在进行的工作，2004年4月。
[35] Kent, S., "IP Authentication Header", RFC 4302, December 2005
[35] Kent，S.，“IP认证头”，RFC 4302，2005年12月
[36] Kocher, P., "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems", CRYPTO 96, Springer-Verlag LNCS 1109, 1996.
[36] Kocher，P.，“对Diffie Hellman、RSA、DSS和其他系统实现的定时攻击”，CRYPTO 96，Springer Verlag LNCS 1109，1996年。
[37] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", CRYPTO 03, Springer-Verlag LNCS 2729, June 2003.
[37] Krawczyk，H.，“西格玛：认证Diffie-Hellman的`符号和MAc'方法及其在IKE协议中的使用”，CRYPTO 03，Springer Verlag LNCS 27292003年6月。
[38] MacNally, C., "Cisco LEAP protocol description", September 2001, available from <http://www.missl.cs.umd.edu/wireless/ethereal/leap.txt>.
[38] MacNally，C.，“Cisco LEAP协议说明”，2001年9月，可从<http://www.missl.cs.umd.edu/wireless/ethereal/leap.txt>.
[39] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
[39] Metz，C.，“检察官办公室延长的答复”，RFC 2243，1997年11月。
[40] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press , 1996.
[40] Menezes，A.，van Oorschot，P.，和S.Vanstone，“应用密码学手册”，CRC出版社，1996年。
[41] National Institute of Standards and Technology, "Password Usage", Federal Information Processing Standards (FIPS) 112, May 1985.
[41] 国家标准和技术研究所，“密码使用”，联邦信息处理标准（FIPS）112，1985年5月。
[42] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", Work in Progress, October 2006.
[42] Cam Winget，N.，McGrew，D.，Salowey，J.，和H.Zhou，“通过安全隧道可扩展认证协议方法（EAP-FAST）的灵活认证”，正在进行的工作，2006年10月。
[43] Schneier, B., Mudge, and D. Wagner, "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", CQRE 99, Springer-Verlag LNCS 1740, October 1999.
[43] Schneier，B.，Mudge和D.Wagner，“微软PPTP认证扩展（MS-CHAPv2）的密码分析”，CQRE 99，Springer Verlag LNCS 1740，1999年10月。
[44] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[44] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[45] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[45] 辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[46] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "EAP IKEv2 Method", Work in Progress, October 2006.
[46] Tschofenig，H.，Kroeselberg，D.，Pashalidis，A.，Ohba，Y.，和F.Bersani，“EAP IKEv2方法”，正在进行的工作，2006年10月。
[47] Walker, J. and R. Housley, "The EAP Archie Protocol", Work in Progress, June 2003.
[47] Walker，J.和R.Housley，“EAP阿尔奇协议”，正在进行的工作，2003年6月。
[48] Wi-Fi Alliance, "Wi-Fi Protected Access, version 2.0", April 2003.
[48] Wi-Fi联盟，“Wi-Fi保护接入，2.0版”，2003年4月。
[49] Wright, J., "Weaknesses in LEAP Challenge/Response", Defcon 03, August 2003.
[49] Wright，J.，“跳跃挑战/反应中的弱点”，2003年8月，Defcon 03。
[50] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[50] Eronen，P.和H.Tschofenig，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
It is formally discouraged to use a password to generate the PSK, since this opens the door to exhaustive search or dictionary attacks, two attacks that would not otherwise be possible.
正式情况下，不鼓励使用密码生成PSK，因为这为彻底搜索或字典攻击打开了大门，否则这两种攻击是不可能的。
EAP-PSK only provides a 16-byte key strength when a 16-byte PSK is drawn at random from the set of all possible 16-byte strings.
当从所有可能的16字节字符串集中随机抽取16字节PSK时，EAP-PSK仅提供16字节密钥强度。
However, as people will probably do this anyway, guidance is provided hereafter to generate the PSK from a password.
然而，由于人们可能无论如何都会这样做，下文将提供从密码生成PSK的指导。
For some hints on how passwords should be selected, please refer to [41].
有关如何选择密码的提示，请参阅[41]。
The technique presented herein is drawn from [33]. It is intended to try to mitigate the risks associated with password usage in cryptography, typically dictionary attacks.
本文介绍的技术来源于[33]。其目的是试图减轻密码术中密码使用的相关风险，通常是字典攻击。
If the binary representation of the password is strictly fewer than 16 bytes long (which by the way means that the chosen password is probably weak because it is too short), then it is padded to 16 bytes with zeroes as its high-order bits.
如果密码的二进制表示长度严格小于16字节（顺便说一句，这意味着所选密码可能很弱，因为它太短），那么它将被填充到16字节，并使用零作为其高阶位。
If the binary representation of the password is strictly more than 16 bytes long, then it is hashed down to exactly 16 bytes using the Matyas-Meyer-Oseas hash (please refer to [40] for a description of this hash. Using the notation of Figure 9.3 of [40], g is the identity function and E is AES-128 in our construction.) with IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has been arbitrarily selected).
如果密码的二进制表示长度严格超过16字节，则使用Matyas Meyer Oseas散列将其散列到正好16字节（请参阅[40]了解此散列的描述。使用[40]中图9.3的表示法，在我们的构造中，g是标识函数，E是AES-128）IV=0x0123456789ABCDEFFEDCBA9876543210（此值已任意选择）。
We now assume that we have a 16-byte number derived from the initial password (that can be the password itself if its binary representation is exactly 16 bytes long). We shall call this number P16.
现在，我们假设我们有一个从初始密码派生的16字节的数字（如果其二进制表示正好是16字节长，则可以是密码本身）。我们叫这个号码P16。
Following the notations used in [33], the PSK is derived thanks to PBKDF2 instantiated with:
按照[33]中使用的符号，由于PBKDF2实例化了以下各项，因此PSK得到：
o P16 as P
o P16作为P
o The first 96 bits of the XOR of the peer and server NAIs as Salt (zero-padded in the high-order bits if necessary).
o 对等机和服务器的XOR的前96位作为Salt（如有必要，在高阶位中填充零）。
o 5000 as c
o 5000作为c
o 16 as dkLen
o 16作为dkLen
Although this gives better protection than nothing, this derivation does not stricto sensu protect against dictionary attacks. It only makes dictionary precomputation harder.
虽然这提供了比没有更好的保护，但严格意义上说，这种派生并不能防止字典攻击。这只会使字典预计算更加困难。
Authors' Addresses
作者地址
Florent Bersani France Telecom R&D 38, rue du General Leclerc Issy-Les-Moulineaux 92794 Cedex 9 FR
弗洛伦特·贝尔萨尼法国电信研发部，勒克莱尔将军街38号，莱斯·穆莱诺92794 Cedex 9 FR
EMail: bersani_florent@yahoo.fr
EMail: bersani_florent@yahoo.fr
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich 81739 GE
Hannes Tschofenig Siemens Networks GmbH&Co KG Otto Hahn Ring 6慕尼黑81739 GE
EMail: Hannes.Tschofenig@siemens.com
EMail: Hannes.Tschofenig@siemens.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。