Network Working Group T. Clancy
Request for Comments: 5433 LTS
Category: Standards Track H. Tschofenig
Nokia Siemens Networks
February 2009
Network Working Group T. Clancy
Request for Comments: 5433 LTS
Category: Standards Track H. Tschofenig
Nokia Siemens Networks
February 2009
Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method
可扩展身份验证协议-通用预共享密钥（EAP-GPSK）方法
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation.
此备忘录定义了一种称为EAP通用预共享密钥（EAP-GPSK）的可扩展身份验证协议（EAP）方法。该方法是一种轻量级的共享密钥认证协议，支持相互认证和密钥派生。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................6
4. Key Derivation ..................................................8
5. Key Management .................................................11
6. Ciphersuites ...................................................11
7. Generalized Key Derivation Function (GKDF) .....................12
8. Ciphersuites Processing Rules ..................................13
8.1. Ciphersuite #1 ............................................13
8.1.1. Encryption .........................................13
8.1.2. Integrity ..........................................13
8.2. Ciphersuite #2 ............................................14
8.2.1. Encryption .........................................14
8.2.2. Integrity ..........................................14
9. Packet Formats .................................................15
9.1. Header Format .............................................15
9.2. Ciphersuite Formatting ....................................16
9.3. Payload Formatting ........................................16
9.4. Protected Data ............................................21
10. Packet Processing Rules .......................................24
11. Example Message Exchanges .....................................25
12. Security Considerations .......................................28
12.1. Security Claims ..........................................28
12.2. Mutual Authentication ....................................29
12.3. Protected Result Indications .............................29
12.4. Integrity Protection .....................................29
12.5. Replay Protection ........................................30
12.6. Reflection Attacks .......................................30
12.7. Dictionary Attacks .......................................30
12.8. Key Derivation and Key Strength ..........................31
12.9. Denial-of-Service Resistance .............................31
12.10. Session Independence ....................................32
12.11. Compromise of the PSK ...................................32
12.12. Fragmentation ...........................................32
12.13. Channel Binding .........................................32
12.14. Fast Reconnect ..........................................33
12.15. Identity Protection .....................................33
12.16. Protected Ciphersuite Negotiation .......................33
12.17. Confidentiality .........................................34
12.18. Cryptographic Binding ...................................34
13. IANA Considerations ...........................................34
14. Contributors ..................................................35
15. Acknowledgments ...............................................36
16. References ....................................................37
16.1. Normative References .....................................37
16.2. Informative References ...................................38
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................6
4. Key Derivation ..................................................8
5. Key Management .................................................11
6. Ciphersuites ...................................................11
7. Generalized Key Derivation Function (GKDF) .....................12
8. Ciphersuites Processing Rules ..................................13
8.1. Ciphersuite #1 ............................................13
8.1.1. Encryption .........................................13
8.1.2. Integrity ..........................................13
8.2. Ciphersuite #2 ............................................14
8.2.1. Encryption .........................................14
8.2.2. Integrity ..........................................14
9. Packet Formats .................................................15
9.1. Header Format .............................................15
9.2. Ciphersuite Formatting ....................................16
9.3. Payload Formatting ........................................16
9.4. Protected Data ............................................21
10. Packet Processing Rules .......................................24
11. Example Message Exchanges .....................................25
12. Security Considerations .......................................28
12.1. Security Claims ..........................................28
12.2. Mutual Authentication ....................................29
12.3. Protected Result Indications .............................29
12.4. Integrity Protection .....................................29
12.5. Replay Protection ........................................30
12.6. Reflection Attacks .......................................30
12.7. Dictionary Attacks .......................................30
12.8. Key Derivation and Key Strength ..........................31
12.9. Denial-of-Service Resistance .............................31
12.10. Session Independence ....................................32
12.11. Compromise of the PSK ...................................32
12.12. Fragmentation ...........................................32
12.13. Channel Binding .........................................32
12.14. Fast Reconnect ..........................................33
12.15. Identity Protection .....................................33
12.16. Protected Ciphersuite Negotiation .......................33
12.17. Confidentiality .........................................34
12.18. Cryptographic Binding ...................................34
13. IANA Considerations ...........................................34
14. Contributors ..................................................35
15. Acknowledgments ...............................................36
16. References ....................................................37
16.1. Normative References .....................................37
16.2. Informative References ...................................38
EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a generalized pre-shared key authentication technique. Mutual authentication is achieved through a nonce-based exchange that is secured by a pre-shared key.
EAP通用预共享密钥（EAP-GPSK）是一种定义通用预共享密钥认证技术的EAP方法。相互身份验证通过基于nonce的交换实现，该交换由预共享密钥保护。
EAP-GPSK addresses a large number of design goals with the intention of being applicable in a broad range of usage scenarios.
EAP-GPSK解决了大量设计目标，旨在适用于广泛的使用场景。
The main design goals of EAP-GPSK are:
EAP-GPSK的主要设计目标是：
Simplicity:
简单性：
EAP-GPSK should be easy to implement.
EAP-GPSK应该易于实现。
Security Model:
安全模型：
EAP-GPSK has been designed in a threat model where the attacker has full control over the communication channel. This EAP threat model is presented in Section 7.1 of [RFC3748].
EAP-GPSK是在威胁模型中设计的，攻击者可以完全控制通信信道。[RFC3748]第7.1节介绍了EAP威胁模型。
Efficiency:
效率：
EAP-GPSK does not make use of public key cryptography and fully relies of symmetric cryptography. The restriction of symmetric cryptographic computations allows for low computational overhead. Hence, EAP-GPSK is lightweight and well suited for any type of device, especially those with processing power, memory, and battery constraints. Additionally, it seeks to minimize the number of round trips.
EAP-GPSK不使用公钥密码，完全依赖对称密码。对称密码计算的限制允许较低的计算开销。因此，EAP-GPSK是轻量级的，非常适合任何类型的设备，特别是处理能力、内存和电池限制的设备。此外，它力求尽量减少往返次数。
Flexibility:
灵活性：
EAP-GPSK offers cryptographic flexibility. At the beginning, the EAP server proposes a list of ciphersuites. The client then selects one. The current version of EAP-GPSK includes two ciphersuites, but additional ones can be easily added.
EAP-GPSK提供了加密灵活性。在开始时，EAP服务器提出一个密码套件列表。然后客户机选择一个。EAP-GPSK的当前版本包括两个密码套件，但可以轻松添加其他密码套件。
Extensibility:
扩展性：
The design of EAP-GPSK allows to securely exchange information between the EAP peer and the EAP server using protected data fields. These fields might, for example, be used to exchange channel binding information or to provide support for identity confidentiality.
EAP-GPSK的设计允许使用受保护的数据字段在EAP对等方和EAP服务器之间安全地交换信息。例如，这些字段可用于交换通道绑定信息或提供身份机密性支持。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section describes the various variables and functions used in the EAP-GPSK method.
本节介绍EAP-GPSK方法中使用的各种变量和函数。
Variables:
变量：
CSuite_List: An octet array listing available ciphersuites (variable length).
CSuite_List：列出可用密码套件（可变长度）的八位字节数组。
CSuite_Sel: Ciphersuite selected by the peer (6 octets).
CSuite_Sel：由对等方选择的密码套件（6个八位字节）。
ID_Peer: Peer Network Access Identifier (NAI) [RFC4282].
ID_Peer：对等网络访问标识符（NAI）[RFC4282]。
ID_Server: Server identity as an opaque blob.
ID_服务器：作为不透明blob的服务器标识。
KS: Integer representing the input key size, in octets, of the selected ciphersuite CSuite_Sel. The key size is one of the ciphersuite parameters.
KS：整数，表示所选密码套件CSuite_Sel的输入密钥大小（以八位字节为单位）。密钥大小是ciphersuite参数之一。
ML: Integer representing the length of the Message Authentication Code (MAC) output, in octets, of the selected ciphersuite CSuite_Sel.
ML：整数，表示所选密码套件CSuite_Sel的消息身份验证码（MAC）输出的长度（以八位字节为单位）。
PD_Payload: Data carried within the protected data payload.
PD_有效载荷：受保护数据有效载荷内携带的数据。
PD_Payload_Block: Block of possibly multiple PD_Payloads carried by a GPSK packet.
PD_有效载荷块：GPSK数据包可能携带多个PD_有效载荷的块。
PL: Integer representing the length of the PSK in octets (2 octets). PL MUST be larger than or equal to KS.
PL：表示PSK长度的整数，单位为八位字节（2个八位字节）。PL必须大于或等于KS。
RAND_Peer: Random integer generated by the peer (32 octets).
RAND_Peer：由对等方生成的随机整数（32个八位字节）。
RAND_Server: Random integer generated by the server (32 octets).
RAND_Server：由服务器生成的随机整数（32个八位字节）。
Operations:
操作：
A || B: Concatenation of octet strings A and B.
A | | B：八位组字符串A和B的串联。
A**B: Integer exponentiation.
A**B：整数幂运算。
truncate(A,B): Returns the first B octets of A.
truncate（A，B）：返回A的前B个八位字节。
ENC_X(Y): Encryption of message Y with a symmetric key X, using a defined block cipher.
ENC_X（Y）：使用定义的分组密码，使用对称密钥X对消息Y进行加密。
KDF-X(Y): Key Derivation Function that generates an arbitrary number of octets of output using secret X and seed Y.
KDF-X（Y）：密钥派生函数，使用秘密X和种子Y生成任意数量的八进制输出。
length(X): Function that returns the length of input X in octets, encoded as a 2-octet integer in network byte order.
length（X）：返回输入X的长度（以八位字节为单位），以网络字节顺序编码为2位八位整数的函数。
MAC_X(Y): Keyed message authentication code computed over Y with symmetric key X.
MAC_X（Y）：使用对称密钥X在Y上计算的密钥消息认证码。
SEC_X(Y): SEC is a function that provides integrity protection based on the chosen ciphersuite. The function SEC uses the algorithm defined by the selected ciphersuite and applies it to the message content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y).
SEC_X（Y）：SEC是一种基于所选密码套件提供完整性保护的功能。函数SEC使用所选密码套件定义的算法，并将其应用于带有密钥X的消息内容Y。简言之，SEC|X（Y）=Y | MAC|X（Y）。
X[A..B]: Notation representing octets A through B of octet array X where the first octet of the array has index zero.
X[A..B]：表示八位组数组X的八位组A到B的符号，其中数组的第一个八位组的索引为零。
The following abbreviations are used for the keying material:
以下缩写用于键控材料：
EMSK: Extended Master Session Key is exported by the EAP method (64 octets).
EMSK：扩展主会话密钥通过EAP方法导出（64个八位字节）。
MK: A session-specific Master Key between the peer and EAP server from which all other EAP method session keys are derived (KS octets).
MK：对等服务器和EAP服务器之间的特定于会话的主密钥，所有其他EAP方法会话密钥都是从该主密钥派生的（KS八位字节）。
MSK: Master Session Key exported by the EAP method (64 octets).
MSK：通过EAP方法导出的主会话密钥（64个八位字节）。
PK: Session key generated from the MK and used during protocol exchange to encrypt protected data (KS octets).
PK：从MK生成的会话密钥，在协议交换期间用于加密受保护的数据（KS八位字节）。
PSK: Long-term key shared between the peer and the server (PL octets).
PSK：对等方和服务器之间共享的长期密钥（PL八位字节）。
SK: Session key generated from the MK and used during protocol exchange to demonstrate knowledge of the PSK (KS octets).
SK：从MK生成的会话密钥，在协议交换期间用于演示PSK知识（KS八位字节）。
The EAP framework (see Section 1.3 of [RFC3748]) defines three basic steps that occur during the execution of an EAP conversation between the EAP peer, the Authenticator, and the EAP server.
EAP框架（见[RFC3748]第1.3节）定义了在执行EAP对等方、认证方和EAP服务器之间的EAP对话期间发生的三个基本步骤。
1. The first phase, discovery, is handled by the underlying protocol, e.g., IEEE 802.1X as utilized by IEEE 802.11 [80211].
1. 第一阶段，发现，由底层协议处理，例如IEEE 802.11使用的IEEE 802.1X[80211]。
2. The EAP authentication phase with EAP-GPSK is defined in this document.
2. 本文档中定义了EAP-GPSK的EAP身份验证阶段。
3. The secure association distribution and secure association phases are handled differently depending on the underlying protocol.
3. 安全关联分发和安全关联阶段的处理方式因基础协议而异。
EAP-GPSK performs mutual authentication between the EAP peer ("Peer") and EAP server ("Server") based on a pre-shared key (PSK). The protocol consists of the message exchanges (GPSK-1, ..., GPSK-4) in which both sides exchange nonces and their identities, and compute and exchange a Message Authentication Code (MAC) over the previously exchanged values, keyed with the pre-shared key. This MAC is considered as proof of possession of the pre-shared key. Two further messages, namely GPSK-Fail and GPSK-Protected-Fail, are used to deal with error situations.
EAP-GPSK基于预共享密钥（PSK）在EAP对等方（“对等方”）和EAP服务器（“服务器”）之间执行相互认证。该协议由消息交换（GPSK-1，…，GPSK-4）组成，其中双方交换nonce及其标识，并在先前交换的值上计算和交换消息身份验证码（MAC），该值由预共享密钥加密。此MAC被视为拥有预共享密钥的证据。另外两条消息，即GPSK Fail和GPSK Protected Fail，用于处理错误情况。
A successful protocol exchange is shown in Figure 1.
成功的协议交换如图1所示。
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-3 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-4 | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-3 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-4 | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Figure 1: EAP-GPSK: Successful Exchange
图1:EAP-GPSK:成功交换
The full EAP-GPSK protocol is as follows:
完整的EAP-GPSK协议如下：
GPSK-1:
GPSK-1：
ID_Server, RAND_Server, CSuite_List
ID_服务器、RAND_服务器、CSuite_列表
GPSK-2:
GPSK-2：
SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List, CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )
SEC_SK（ID_Peer、ID_Server、RAND_Peer、RAND_Server、CSuite_List、CSuite_Sel、[ENC_PK（PD_有效负载块）]）
GPSK-3:
GPSK-3：
SEC_SK(RAND_Peer, RAND_Server, ID_Server, CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )
SEC_SK（随机对等、随机服务器、ID服务器、CSuite_Sel、[ENC_PK（PD_有效负载块）]）
GPSK-4:
GPSK-4：
SEC_SK( [ ENC_PK(PD_Payload_Block) ] )
SEC_SK（[ENC_PK（PD_有效载荷块）]）
The EAP server begins EAP-GPSK by selecting a random number RAND_Server and encoding the supported ciphersuites into CSuite_List. A ciphersuite consists of an encryption algorithm, a key derivation function, and a message authentication code.
EAP服务器通过选择随机数RAND_服务器并将支持的密码套件编码到CSuite_列表中开始EAP-GPSK。密码套件由加密算法、密钥派生函数和消息身份验证码组成。
In GPSK-1, the EAP server sends its identity ID_Server, a random number RAND_Server, and a list of supported ciphersuites CSuite_List. The decision of which ciphersuite to offer and which ciphersuite to pick is policy- and implementation-dependent and, therefore, outside the scope of this document.
在GPSK-1中，EAP服务器发送其标识ID_服务器、随机数RAND_服务器和支持的密码套件列表CSuite_列表。提供哪个ciphersuite和选择哪个ciphersuite的决定取决于策略和实施，因此不在本文档的范围内。
In GPSK-2, the peer sends its identity ID_Peer and a random number RAND_Peer. Furthermore, it repeats the received parameters of the GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected ciphersuite. It computes a Message Authentication Code over all the transmitted parameters.
在GPSK-2中，对等方发送其标识ID_peer和随机数RAND_peer。此外，它还重复接收到的GPSK-1消息参数（ID_服务器、RAND_服务器、CSuite_列表）和所选密码套件。它计算所有传输参数的消息身份验证码。
The EAP server verifies the received Message Authentication Code and the consistency of the identities, nonces, and ciphersuite parameters transmitted in GPSK-1. In case of successful verification, the EAP server computes a Message Authentication Code over the session parameter and returns it to the peer (within GPSK-3). Within GPSK-2 and GPSK-3, the EAP peer and EAP server have the possibility to exchange encrypted protected data parameters.
EAP服务器验证接收到的消息验证码以及在GPSK-1中传输的标识、nonce和密码套件参数的一致性。在验证成功的情况下，EAP服务器通过会话参数计算消息身份验证码，并将其返回给对等方（在GPSK-3内）。在GPSK-2和GPSK-3中，EAP对等方和EAP服务器可以交换加密的受保护数据参数。
The peer verifies the received Message Authentication Code and the consistency of the identities, nonces, and ciphersuite parameters transmitted in GPSK-2. If the verification is successful, GPSK-4 is prepared. This message can optionally contain the peer's protected data parameters.
对等方验证接收到的消息身份验证码以及在GPSK-2中传输的标识、nonce和密码套件参数的一致性。如果验证成功，则准备GPSK-4。此消息可以选择性地包含对等方的受保护数据参数。
Upon receipt of GPSK-4, the server processes any included PD_Payload_Block. Then, the EAP server sends an EAP Success message to indicate the successful outcome of the authentication.
在收到GPSK-4后，服务器处理任何包含的PD_有效负载_块。然后，EAP服务器发送EAP Success消息以指示认证的成功结果。
EAP-GPSK provides key derivation in compliance to the requirements of [RFC3748] and [RFC5247]. Note that this section provides an abstract description for the key derivation procedure that needs to be instantiated with a specific ciphersuite.
EAP-GPSK按照[RFC3748]和[RFC5247]的要求提供密钥派生。请注意，本节提供了需要使用特定密码套件实例化的密钥派生过程的抽象描述。
The long-term credential shared between EAP peer and EAP server SHOULD be a strong pre-shared key PSK of at least 16 octets, though its length and entropy are variable. While it is possible to use a password or passphrase, doing so is NOT RECOMMENDED as EAP-GPSK is vulnerable to dictionary attacks.
EAP对等方和EAP服务器之间共享的长期凭证应该是至少16个八位字节的强预共享密钥PSK，尽管其长度和熵是可变的。虽然可以使用密码或密码短语，但不建议这样做，因为EAP-GPSK容易受到字典攻击。
During an EAP-GPSK authentication, a Master Key MK, a Session Key SK, and a Protected Data Encryption Key PK (if using an encrypting ciphersuite) are derived using the ciphersuite-specified KDF and data exchanged during the execution of the protocol, namely 'RAND_Peer || ID_Peer || RAND_Server || ID_Server', referred to as inputString in its short-hand form.
在EAP-GPSK身份验证期间，主密钥MK、会话密钥SK和受保护的数据加密密钥PK（如果使用加密密码套件）是使用密码套件指定的KDF和在协议执行期间交换的数据，即“RAND_Peer | ID|u Peer | RAND|u Server | ID|u Server”，在其简写形式中称为inputString。
In case of successful completion, EAP-GPSK derives and exports an MSK and an EMSK, each 64 octets in length.
在成功完成的情况下，EAP-GPSK派生并导出一个MSK和一个EMSK，每个长度为64个八位字节。
The following notation is used: KDF-X(Y, Z)[A..B], whereby
使用以下符号：KDF-X（Y，Z）[A..B]，其中
X is the length, in octets, of the desired output,
X是所需输出的长度，以八位字节为单位，
Y is a secret key,
Y是一把秘密钥匙，
Z is the inputString,
Z是输入字符串，
[A..B] extracts the string of octets starting with octet A and finishing with octet B from the output of the KDF function.
[A..B]从KDF函数的输出中提取以八位字节A开始，以八位字节B结束的八位字节字符串。
This keying material is derived using the ciphersuite-specified KDF as follows:
此键控材料使用指定的密码套件KDF派生，如下所示：
o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
o inputString=RAND|u Peer | ID|u Peer | RAND|u Server | ID|u Server
o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || inputString)[0..KS-1]
o MK=KDF-KS（PSK[0..KS-1]，PL | | PSK | | CSuite|u Sel | | inputString）[0..KS-1]
o MSK = KDF-{128+2*KS}(MK, inputString)[0..63]
o MSK=KDF-{128+2*KS}（MK，inputString）[0..63]
o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
o EMSK=KDF-{128+2*KS}（MK，inputString）[64..127]
o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
o SK=KDF-{128+2*KS}（MK，inputString）[128..127+KS]
o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using an encrypting ciphersuite)
o PK=KDF-{128+2*KS}（MK，inputString）[128+KS..127+2*KS]（如果使用加密密码套件）
The value for PL (the length of the PSK in octets) is encoded as a 2-octet integer in network byte order. Recall that KS is the length of the ciphersuite input key size in octets.
PL值（以八位字节为单位的PSK长度）编码为网络字节顺序的2位八位整数。回想一下，KS是ciphersuite输入密钥大小的长度（以八位字节为单位）。
Additionally, the EAP keying framework [RFC5247] requires the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. These values are defined as:
此外，EAP键控框架[RFC5247]需要定义方法ID、会话ID、对等ID和服务器ID。这些值定义为：
o Method-ID = KDF-16(PSK[0..KS-1], "Method ID" || EAP_Method_Type || CSuite_Sel || inputString)[0..15]
o 方法ID=KDF-16（PSK[0..KS-1]，“方法ID”| | EAP| U方法| U类型| | CSuite|U Sel | | inputString）[0..15]
o Session-ID = EAP_Method_Type || Method_ID
o 会话ID=EAP_方法|类型|方法| ID
o Peer-ID = ID_Peer
o 对等ID=ID\U对等
o Server-ID = ID_Server
o 服务器ID=ID\u服务器
EAP_Method_Type refers to the 1-octet, IANA-allocated EAP Type code value.
EAP_方法_类型是指IANA分配的1个八位字节的EAP类型代码值。
Figure 2 depicts the key derivation procedure of EAP-GPSK.
图2描述了EAP-GPSK的密钥推导过程。
+-------------+ +-------------------------------+
| PL-octet | | RAND_Peer || ID_Peer || |
| PSK | | RAND_Server || ID_Server |
+-------------+ +-------------------------------+
| | |
| +------------+ | |
| | CSuite_Sel | | |
| +------------+ | |
| | | |
v v v |
+--------------------------------------------+ |
| KDF | |
+--------------------------------------------+ |
| |
v |
+-------------+ |
| KS-octet | |
| MK | |
+-------------+ |
| |
v v
+---------------------------------------------------+
| KDF |
+---------------------------------------------------+
| | | |
v v v v
+---------+ +---------+ +----------+ +----------+
| 64-octet| | 64-octet| | KS-octet | | KS-octet |
| MSK | | EMSK | | SK | | PK |
+---------+ +---------+ +----------+ +----------+
+-------------+ +-------------------------------+
| PL-octet | | RAND_Peer || ID_Peer || |
| PSK | | RAND_Server || ID_Server |
+-------------+ +-------------------------------+
| | |
| +------------+ | |
| | CSuite_Sel | | |
| +------------+ | |
| | | |
v v v |
+--------------------------------------------+ |
| KDF | |
+--------------------------------------------+ |
| |
v |
+-------------+ |
| KS-octet | |
| MK | |
+-------------+ |
| |
v v
+---------------------------------------------------+
| KDF |
+---------------------------------------------------+
| | | |
v v v v
+---------+ +---------+ +----------+ +----------+
| 64-octet| | 64-octet| | KS-octet | | KS-octet |
| MSK | | EMSK | | SK | | PK |
+---------+ +---------+ +----------+ +----------+
Figure 2: EAP-GPSK Key Derivation
图2:EAP-GPSK密钥派生
In order to be interoperable, PSKs must be entered in the same way on both the peer and server. The management interface for entering PSKs MUST support entering PSKs up to 64 octets in length as ASCII strings and in hexadecimal encoding.
为了互操作，必须以相同的方式在对等机和服务器上输入PSK。用于输入PSK的管理界面必须支持以ASCII字符串和十六进制编码输入长度不超过64个八位字节的PSK。
Additionally, the ID_Peer and ID_Server MUST be provisioned with the PSK. Validation of these values is by an octet-wise comparison. The management interface SHOULD support entering non-ASCII octets for the ID_Peer and ID_Server up to 254 octets in length. For more information, the reader is advised to read Section 2.4 of RFC 4282 [RFC4282].
此外，必须使用PSK配置ID_对等和ID_服务器。通过八位字节比较验证这些值。管理界面应支持为ID_对等方和ID_服务器输入长度不超过254个八位字节的非ASCII八位字节。有关更多信息，建议读者阅读RFC 4282[RFC4282]第2.4节。
The design of EAP-GPSK allows cryptographic algorithms and key sizes, called ciphersuites, to be negotiated during the protocol run. The ability to specify block-based and hash-based ciphersuites is offered. Extensibility is provided with the introduction of new ciphersuites; this document specifies an initial set. The CSuite/ Specifier column in Figure 3 uniquely identifies a ciphersuite.
EAP-GPSK的设计允许在协议运行期间协商密码算法和密钥大小（称为密码套件）。提供了指定基于块和基于哈希的密码套件的功能。新密码套件的引入提供了可扩展性；本文件规定了初始设置。图3中的CSuite/Specifier列唯一标识一个密码套件。
For a vendor-specific ciphersuite, the first four octets are the vendor-specific enterprise number that contains the IANA-assigned "SMI Network Management Private Enterprise Codes" value (see [ENTNUM]), encoded in network byte order. The last two octets are vendor assigned for the specific ciphersuite. A vendor code of 0x00000000 indicates ciphersuites standardized by the IETF in an IANA-maintained registry.
对于特定于供应商的密码套件，前四个八位字节是特定于供应商的企业编号，其中包含IANA分配的“SMI网络管理专用企业代码”值（请参见[ENTNUM]），按网络字节顺序编码。最后两个八位字节是供应商为特定密码套件指定的。供应商代码0x00000000表示IETF在IANA维护的注册表中标准化的密码套件。
The following ciphersuites are specified in this document (recall that KS is the length of the ciphersuite input key length in octets, and ML is the length of the MAC output in octets):
本文件中规定了以下密码套件（请记住，KS是密码套件输入密钥长度（以八位字节为单位），ML是MAC输出长度（以八位字节为单位）：
+-----------+----+-------------+----+--------------+----------------+
| CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation |
| Specifier | | | | KDF MAC | Function |
+-----------+----+-------------+----+--------------+----------------+
| 0x0001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF |
+-----------+----+-------------+----+--------------+----------------+
| 0x0002 | 32 | NULL | 32 | HMAC-SHA256 | GKDF |
+-----------+----+-------------+----+--------------+----------------+
+-----------+----+-------------+----+--------------+----------------+
| CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation |
| Specifier | | | | KDF MAC | Function |
+-----------+----+-------------+----+--------------+----------------+
| 0x0001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF |
+-----------+----+-------------+----+--------------+----------------+
| 0x0002 | 32 | NULL | 32 | HMAC-SHA256 | GKDF |
+-----------+----+-------------+----+--------------+----------------+
Figure 3: Ciphersuites
图3：密码套件
Ciphersuite 1, which is based on the Advanced Encryption Standard (AES) as a cryptographic primitive, MUST be implemented. This document specifies also a second ciphersuite, which MAY be implemented. Both ciphersuites defined in this document make use of the Generalized Key Derivation Function (GKDF), as defined in Section 7. The following aspects need to be considered to ensure that the PSK that is used as input to the GKDF is sufficiently long:
必须实现作为加密原语的基于高级加密标准（AES）的Ciphersuite 1。本文档还指定了第二个密码套件，该套件可以实现。本文档中定义的两个密码套件均使用第7节中定义的通用密钥派生函数（GKDF）。需要考虑以下方面，以确保用作GKDF输入的PSK足够长：
1. The PSK used with ciphersuite 1 MUST be 128 bits in length. Keys longer than 128 bits will be truncated.
1. 与ciphersuite 1一起使用的PSK长度必须为128位。超过128位的密钥将被截断。
2. The PSK used with ciphersuite 2 MUST be 256 bits in length. Keys longer than 256 bits will be truncated.
2. 与ciphersuite 2一起使用的PSK长度必须为256位。长度超过256位的密钥将被截断。
3. It is RECOMMENDED that 256 bit keys be provisioned in all cases to provide enough entropy for all current and many possible future ciphersuites.
3. 建议在所有情况下提供256位密钥，以便为所有当前和许多可能的未来密码套件提供足够的熵。
Ciphersuites defined in the future that make use of the GKDF need to specify a minimum PSK size (as is done with the ciphersuites listed in this document).
将来使用GKDF定义的密码套件需要指定最小PSK大小（本文档中列出的密码套件也是如此）。
Each ciphersuite needs to specify a key derivation function. The ciphersuites defined in this document make use of the Generalized Key Derivation Function (GKDF) that utilizes the MAC function defined in the ciphersuite. Future ciphersuites can use any other formally specified KDF that takes as arguments a key and a seed value, and produces at least 128+2*KS octets of output.
每个密码套件都需要指定一个密钥派生函数。本文档中定义的密码套件使用广义密钥派生函数（GKDF），该函数利用了密码套件中定义的MAC函数。未来的密码套件可以使用任何其他正式指定的KDF，该KDF将密钥和种子值作为参数，并产生至少128+2*KS个八位字节的输出。
GKDF has the following structure:
GKDF具有以下结构：
GKDF-X(Y, Z)
GKDF-X（Y，Z）
X length, in octets, of the desired output
所需输出的X长度（以八位字节为单位）
Y secret key
Y密钥
Z inputString
Z输入字符串
GKDF-X (Y, Z)
{
n = ceiling integer of ( X / ML );
/* determine number of output blocks */
GKDF-X (Y, Z)
{
n = ceiling integer of ( X / ML );
/* determine number of output blocks */
result = "";
结果=”；
for i = 1 to n {
result = result || MAC_Y (i || Z);
}
for i = 1 to n {
result = result || MAC_Y (i || Z);
}
return truncate(result, X) }
返回截断（结果，X）}
Note that the variable 'i' in M_i is represented as a 2-octet value in network byte order.
请注意，M_i中的变量“i”表示为网络字节顺序的2个八位组值。
With this ciphersuite, all cryptography is built around a single cryptographic primitive, AES-128 ([AES]). Within the protected data frames, AES-128 is used in the Cipher Block Chaining (CBC) mode of operation (see [CBC]). This EAP method uses encryption in a single payload, in the protected data payload (see Section 9.4).
使用此密码套件，所有加密都围绕单个加密原语AES-128（[AES]）构建。在受保护的数据帧中，AES-128用于密码块链接（CBC）操作模式（参见[CBC]）。此EAP方法在受保护的数据有效载荷中的单个有效载荷中使用加密（见第9.4节）。
In a nutshell, the CBC mode proceeds as follows. The IV is XORed with the first plaintext block before it is encrypted. Then for successive blocks, the previous ciphertext block is XORed with the current plaintext, before it is encrypted.
简而言之，CBC模式进行如下操作。IV在加密前与第一个明文块异或。然后，对于连续的块，前一个密文块在加密之前与当前明文异或。
Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is recommended by NIST. Among its advantages, CMAC is capable to work with messages of arbitrary length. A detailed description of CMAC can be found in [CMAC].
Ciphersuite 1使用CMAC作为消息身份验证代码。CMAC由NIST推荐。CMAC的优点之一是能够处理任意长度的消息。有关CMAC的详细说明，请参见[CMAC]。
The following instantiation is used: AES-CMAC-128(SK, Input) denotes the MAC of Input under the key SK where Input refers to the following content:
使用以下实例化：AES-CMAC-128（SK，输入）表示密钥SK下输入的MAC，其中输入指以下内容：
o Parameter within SEC_SK(Parameter) in message GPSK-2
o 消息GPSK-2中SEC_SK（参数）内的参数
o Parameter within SEC_SK(Parameter) in message GPSK-3
o 消息GPSK-3中SEC_SK（参数）内的参数
o Parameter within SEC_SK(Parameter) in message GPSK-4
o 消息GPSK-4中SEC_SK（参数）内的参数
Ciphersuite 2 does not include an algorithm for encryption. With a NULL encryption algorithm, encryption is defined as:
Ciphersuite 2不包括加密算法。对于空加密算法，加密定义为：
E_X(Y) = Y
E_X（Y）=Y
When using this ciphersuite, the data exchanged inside the protected data block is not encrypted. Therefore, this mode MUST NOT be used if confidential information appears inside the protected data block.
使用此密码套件时，在受保护数据块内交换的数据不会加密。因此，如果机密信息出现在受保护的数据块内，则不得使用此模式。
Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash algorithm (see [RFC4634]).
Ciphersuite 2使用键控MAC函数HMAC和SHA256哈希算法（参见[RFC4634]）。
For integrity protection, the following instantiation is used:
对于完整性保护，使用以下实例化：
HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK where Input refers to the following content:
HMAC-SHA256（SK，输入）表示密钥SK下输入的MAC，其中输入指以下内容：
o Parameter within SEC_SK(Parameter) in message GPSK-2
o 消息GPSK-2中SEC_SK（参数）内的参数
o Parameter within SEC_SK(Parameter) in message GPSK-3
o 消息GPSK-3中SEC_SK（参数）内的参数
o Parameter within SEC_SK(Parameter) in message GPSK-4
o 消息GPSK-4中SEC_SK（参数）内的参数
This section defines the packet format of the EAP-GPSK messages.
本节定义EAP-GPSK消息的数据包格式。
The EAP-GPSK header has the following structure:
EAP-GPSK报头具有以下结构：
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-GPSK Header
图4:EAP-GPSK报头
The Code, Identifier, Length, and Type fields are all part of the EAP header and are defined in [RFC3748]. The Type field in the EAP header MUST be the value allocated by IANA for EAP-GPSK.
代码、标识符、长度和类型字段都是EAP标头的一部分，并在[RFC3748]中定义。EAP标头中的类型字段必须是IANA为EAP-GPSK分配的值。
The OP-Code field is one of 6 values:
OP Code字段是6个值之一：
o 0x00 : Reserved
o 0x00：保留
o 0x01 : GPSK-1
o 0x01:GPSK-1
o 0x02 : GPSK-2
o 0x02:GPSK-2
o 0x03 : GPSK-3
o 0x03:GPSK-3
o 0x04 : GPSK-4
o 0x04:GPSK-4
o 0x05 : GPSK-Fail
o 0x05:GPSK失败
o 0x06 : GPSK-Protected-Fail
o 0x06:GPSK保护失败
All other values of this OP-Code field are available via IANA registration.
此操作码字段的所有其他值可通过IANA注册获得。
Ciphersuites are encoded as 6-octet arrays. The first four octets indicate the CSuite/Vendor field. For vendor-specific ciphersuites, this represents the vendor enterprise number and contains the IANA-assigned "SMI Network Management Private Enterprise Codes" value (see [ENTNUM]), encoded in network byte order. The last two octets indicate the CSuite/Specifier field, which identifies the particular ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates ciphersuites allocated by the IETF.
密码套件编码为6个八位组数组。前四个八位字节表示CSuite/供应商字段。对于特定于供应商的密码套件，它表示供应商企业编号，并包含IANA分配的“SMI网络管理专用企业代码”值（请参见[ENTNUM]），以网络字节顺序编码。最后两个八位字节表示CSuite/说明符字段，用于标识特定的密码套件。4个八位字节的CSuite/供应商值0x00000000表示IETF分配的密码套件。
Graphically, they are represented as:
从图形上看，它们表示为：
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Vendor = 0x00000000 or enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Specifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Vendor = 0x00000000 or enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Specifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Ciphersuite Formatting
图5：密码套件格式
CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and CSuite/Specifier pair.
CSuite_Sel编码为6位八位密码套件CSuite/供应商和CSuite/说明符对。
CSuite_List is a variable-length octet array of ciphersuites. It is encoded by concatenating encoded ciphersuite values. Its length in octets MUST be a multiple of 6.
CSuite_List是一个可变长度的密码套件八位数组。它通过连接编码的密码套件值进行编码。其长度（以八位字节为单位）必须是6的倍数。
Payload formatting is based on the protocol exchange description in Section 3.
有效负载格式化基于第3节中的协议交换描述。
The GPSK-1 payload format is defined as follows:
GPSK-1有效载荷格式定义如下：
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... CSuite_List ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... CSuite_List ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GPSK-1 Payload
图6:GPSK-1有效载荷
The GPSK-2 payload format is defined as follows:
GPSK-2有效载荷格式定义如下：
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Peer) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... CSuite_List ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Peer) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... CSuite_List ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GPSK-2 Payload
图7:GPSK-2有效载荷
If the optional protected data payload is not included, then length(PD_Payload_Block)=0 and the PD payload is excluded. The payload MAC covers the entire packet, from the ID_Peer length through the optional PD_Payload_Block.
如果未包括可选的受保护数据有效负载，则长度（PD_有效负载_块）=0，并且不包括PD有效负载。有效负载MAC覆盖整个数据包，从ID_对等长度到可选的PD_有效负载_块。
The GPSK-3 payload is defined as follows:
GPSK-3有效载荷定义如下：
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: GPSK-3 Payload
图8:GPSK-3有效载荷
If the optional protected data payload is not included, then length(PD_Payload_Block)=0 and the PD payload is excluded. The payload MAC covers the entire packet, from the RAND_Peer through the optional PD_Payload_Block.
如果未包括可选的受保护数据有效负载，则长度（PD_有效负载_块）=0，并且不包括PD有效负载。有效负载MAC覆盖整个数据包，从RAND_对等方到可选的PD_有效负载_块。
The GPSK-4 payload format is defined as follows:
GPSK-4有效载荷格式定义如下：
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(PD_Payload_Block) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(PD_Payload_Block) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: GPSK-4 Payload
图9:GPSK-4有效载荷
If the optional protected data payload is not included, then length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC MUST always be included, regardless of the presence of PD_Payload_Block. The payload MAC covers the entire packet, from the PD_Payload_Block length through the optional PD_Payload_Block.
如果未包括可选的受保护数据有效负载，则长度（PD_有效负载_块）=0，并且不包括PD有效负载。无论是否存在PD_有效负载_块，都必须始终包括MAC。有效负载MAC覆盖整个数据包，从PD_有效负载块长度到可选的PD_有效负载块。
The GPSK-Fail payload format is defined as follows:
GPSK失效有效负载格式定义如下：
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: GPSK-Fail Payload
图10:GPSK失效有效负载
The GPSK-Protected-Fail payload format is defined as follows:
GPSK保护失效有效负载格式定义如下：
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: GPSK-Protected-Fail Payload
图11:GPSK保护失效有效负载
The Failure-Code field is one of three values, but can be extended:
故障代码字段是三个值之一，但可以扩展：
o 0x00000000 : Reserved
o 0x00000000：保留
o 0x00000001 : PSK Not Found
o 0x00000001:未找到PSK
o 0x00000002 : Authentication Failure
o 0x00000002:身份验证失败
o 0x00000003 : Authorization Failure
o 0x00000003:授权失败
All other values of this field are available via IANA registration.
此字段的所有其他值可通过IANA注册获得。
"PSK Not Found" indicates a key for a particular user could not be located, making authentication impossible. "Authentication Failure" indicates a MAC failure due to a PSK mismatch. "Authorization Failure" indicates that while the PSK being used is correct, the user is not authorized to connect.
“未找到PSK”表示无法找到特定用户的密钥，从而无法进行身份验证。“身份验证失败”表示由于PSK不匹配而导致MAC失败。“授权失败”表示当使用的PSK正确时，用户未被授权连接。
The protected data blocks are a generic mechanism for the peer and server to securely exchange data. If the specified ciphersuite has a NULL encryption primitive, then this channel only offers authenticity, not confidentiality.
受保护的数据块是对等方和服务器安全交换数据的通用机制。如果指定的密码套件具有空加密原语，则此通道仅提供真实性，而不提供机密性。
These payloads are encoded as the concatenation of type-length-value (TLV) triples called PD_Payloads.
这些有效载荷被编码为类型长度值（TLV）三元组的串联，称为PD_有效载荷。
Type values are encoded as a 6-octet string and represented by a 4-octet vendor and a 2-octet specifier field. The vendor field indicates the type as either standards-specified or vendor-specific.
类型值编码为6个八位字节的字符串，由4个八位字节的供应商和2个八位字节的说明符字段表示。“供应商”字段表示指定标准或供应商特定的类型。
If these four octets are 0x00000000, then the value is standards-specified, and any other value represents a vendor-specific enterprise number.
如果这四个八位字节为0x00000000，则该值为指定的标准值，任何其他值表示特定于供应商的企业编号。
The specifier field indicates the actual type. For vendor field 0x00000000, the specifier field is maintained by IANA. For any other vendor field, the specifier field is maintained by the vendor.
说明符字段指示实际类型。对于供应商字段0x00000000，说明符字段由IANA维护。对于任何其他供应商字段，说明符字段由供应商维护。
Length fields are specified as 2-octet integers in network byte order, reflect only the length of the value, and do not include the length of the type and length fields.
长度字段按网络字节顺序指定为2个八位整数，仅反映值的长度，不包括类型和长度字段的长度。
Graphically, this can be depicted as follows:
从图形上看，这可以描述如下：
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PData/Vendor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PData/Specifier | PData/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PData/Value ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PData/Vendor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PData/Specifier | PData/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PData/Value ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Protected Data Payload (PD_Payload) Formatting
图12：受保护的数据有效负载（PD_有效负载）格式
These PD_Payloads are concatenated together to form a PD_Payload_Block. If the CSuite_Sel includes support for encryption, then the PD_Payload_Block includes fields specifying an Initialization Vector (IV) and the necessary padding. This can be depicted as follows:
这些PD_有效载荷连接在一起，形成PD_有效载荷块。如果CSuite_Sel包括对加密的支持，那么PD_Payload_块包括指定初始化向量（IV）和必要填充的字段。这可以描述如下：
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV Length | |
+-+-+-+-+-+-+-+-+ Initialization Vector +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV Length | |
+-+-+-+-+-+-+-+-+ Initialization Vector +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Protected Data Block (PD_Payload_Block) Formatting if Encryption is Supported
图13：受保护数据块（PD_有效负载_块）格式（如果支持加密）
The Initialization Vector is a randomly chosen value whose length is equal to the specified IV Length. The required length is defined by the ciphersuite. Recipients MUST accept any value. Senders SHOULD either pick this value pseudo-randomly and independently for each message or use the final ciphertext block of the previous message sent. Senders MUST NOT use the same value for each message, use a sequence of values with low hamming distance (e.g., a sequence number), or use ciphertext from a received message. IVs should be selected per the security requirements of the underlying cipher. If the data is not being encrypted, then the IV Length MUST be 0. If the ciphersuite does not require an IV, or has a self-contained way of communicating the IV, then the IV Length field MUST be 0. In these cases, the ciphersuite definition defines how the IV is encapsulated in the PD_Payload.
初始化向量是一个随机选择的值，其长度等于指定的IV长度。所需的长度由密码套件定义。收件人必须接受任何值。发送方应为每条消息单独伪随机选取该值，或使用前一条消息的最终密文块。发送方不得对每条消息使用相同的值，不得使用具有低汉明距离的值序列（例如，序列号），也不得使用接收到的消息中的密文。应根据基础密码的安全要求选择IVs。如果数据未加密，则IV长度必须为0。如果密码套件不需要IV，或具有独立的IV通信方式，则IV长度字段必须为0。在这些情况下，密码套件定义定义了IV如何封装在PD_有效负载中。
The concatenation of PD_Payloads along with the padding and padding length are all encrypted using the negotiated block cipher. If no block cipher is specified, then these fields are not encrypted.
PD_有效载荷的串联以及填充和填充长度都使用协商分组密码进行加密。如果未指定分组密码，则这些字段不加密。
The Padding field MAY contain any value chosen by the sender. For block-based cipher modes, the padding MUST have a length that makes the combination of the concatenation of PD_Payloads, the Padding, and the Pad Length to be a multiple of the encryption block size. If the
填充字段可以包含发件人选择的任何值。对于基于块的密码模式，填充的长度必须使PD_有效负载、填充和填充长度的组合成为加密块大小的倍数。如果
underlying ciphersuite does not require padding (e.g., a stream-based cipher mode) or no encryption is being used, then the padding length MUST still be present and be 0.
基础密码套件不需要填充（例如，基于流的密码模式）或未使用加密，则填充长度必须仍然存在且为0。
The Pad Length field is the length of the Padding field. The sender SHOULD set the Pad Length to the minimum value that makes the combination of the PD_Payloads, the Padding, and the Pad Length a multiple of the block size (in the case of block-based cipher modes), but the recipient MUST accept any length that results in proper alignment. This field is encrypted with the negotiated cipher.
Pad Length字段是Padding字段的长度。发送方应将Pad Length设置为使PD_有效载荷、Padding和Pad Length的组合为块大小的倍数（在基于块的密码模式的情况下）的最小值，但接收方必须接受导致正确对齐的任何长度。此字段使用协商密码加密。
If the negotiated ciphersuite does not support encryption, then the IV field MUST be of length 0 and the padding field MUST be of length 0. The IV length and padding length fields MUST still be present, and contain the value 0. The rationale for still requiring the length fields is to allow for modular implementations where the crypto processing is independent of the payload processing. This is depicted in the following figure.
如果协商的密码套件不支持加密，则IV字段的长度必须为0，填充字段的长度必须为0。IV长度和填充长度字段必须仍然存在，并且包含值0。仍然需要长度字段的理由是允许模块化实现，其中加密处理独立于有效负载处理。下图对此进行了描述。
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | |
+-+-+-+-+-+-+-+-+ PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc +-+-+-+-+-+-+-+-+
| | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | |
+-+-+-+-+-+-+-+-+ PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc +-+-+-+-+-+-+-+-+
| | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Protected Data Block (PD_Payload_Block) Formatting Without Encryption
图14：未加密的受保护数据块（PD_有效负载_块）格式化
For PData/Vendor field 0x00000000, the following PData/Specifier fields are defined:
对于PData/供应商字段0x00000000，定义了以下PData/说明符字段：
o 0x0000 : Reserved
o 0x0000：保留
All other values of this field are available via IANA registration.
此字段的所有其他值可通过IANA注册获得。
This section defines how the EAP peer and EAP server MUST behave when a received packet is deemed invalid.
本节定义了当接收到的数据包被视为无效时，EAP对等方和EAP服务器必须如何工作。
Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP server MUST be silently discarded. An EAP peer or EAP server receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 before receiving GPSK-1 or before transmitting GPSK-2) MUST silently discard the packet.
EAP对等方或EAP服务器无法解析的任何EAP-GPSK数据包都必须以静默方式丢弃。接收任何意外数据包的EAP对等方或EAP服务器（例如，在接收GPSK-1之前或在发送GPSK-2之前接收GPSK-3的EAP对等方）必须以静默方式丢弃该数据包。
GPSK-1 contains no MAC protection, so provided it properly parses, it MUST be accepted by the peer. If the EAP peer has no ciphersuites in common with the server or decides the ID_Server is that of an Authentication, Authorization, and Accounting (AAA) server to which it does not wish to authenticate, the EAP peer MUST respond with an EAP-NAK.
GPSK-1不包含MAC保护，因此只要它正确解析，就必须被对等方接受。如果EAP对等方没有与服务器相同的密码套件，或者确定ID_服务器是其不希望进行身份验证的身份验证、授权和记帐（AAA）服务器的ID_服务器，则EAP对等方必须使用EAP-NAK进行响应。
For GPSK-2, if the ID_Peer is for an unknown user, the EAP server MUST send either a "PSK Not Found" GPSK-Fail message or an "Authentication Failure" GPSK-Fail, depending on its policy. If the MAC validation fails, the server MUST transmit a GPSK-Fail message specifying "Authentication Failure". If the RAND_Server or CSuite_List field in GPSK-2 does not match the values in GPSK-1, the server MUST silently discard the packet. If server policy determines the peer is not authorized and the MAC is correct, the server MUST transmit a GPSK-Protected-Fail message indicating "Authorization Failure", and discard the received packet.
对于GPSK-2，如果ID_对等方用于未知用户，EAP服务器必须发送“PSK未找到”GPSK失败消息或“身份验证失败”GPSK失败，具体取决于其策略。如果MAC验证失败，服务器必须发送指定“身份验证失败”的GPSK失败消息。如果GPSK-2中的RAND_服务器或CSuite_列表字段与GPSK-1中的值不匹配，则服务器必须以静默方式丢弃数据包。如果服务器策略确定对等方未经授权且MAC正确，则服务器必须发送指示“授权失败”的GPSK保护失败消息，并丢弃接收到的数据包。
A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in response to a GPSK-2 message MUST replay the received GPSK-Fail / GPSK-Protected-Fail message. Then, the EAP server returns an EAP-Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message to correctly finish the EAP conversation. If MAC validation on a GPSK-Protected-Fail packet fails, then the received packet MUST be silently discarded.
接收GPSK Fail/GPSK Protected Fail消息以响应GPSK-2消息的对等方必须重播接收到的GPSK Fail/GPSK Protected Fail消息。然后，EAP服务器在接收到GPSK Fail/GPSK Protected Fail消息后返回EAP Failure，以正确完成EAP对话。如果GPSK保护失败数据包上的MAC验证失败，则必须以静默方式丢弃接收到的数据包。
For GPSK-3, a peer MUST silently discard messages where the RAND_Peer, ID_Server, or the CSuite_Sel fields do not match those transmitted in GPSK-2. An EAP peer MUST silently discard any packet whose MAC fails.
对于GPSK-3，当RAND_peer、ID_Server或CSuite_Sel字段与GPSK-2中传输的字段不匹配时，对等方必须以静默方式丢弃消息。EAP对等方必须悄悄地丢弃MAC失败的任何数据包。
For GPSK-4, a server MUST silently discard any packet whose MAC fails validation.
对于GPSK-4，服务器必须悄悄地丢弃MAC未通过验证的任何数据包。
If a decryption failure of a protected payload is detected, the recipient MUST silently discard the GPSK packet.
如果检测到受保护负载的解密失败，则接收方必须以静默方式丢弃GPSK数据包。
This section shows a couple of example message flows.
本节显示了两个示例消息流。
A successful EAP-GPSK message exchange is shown in Figure 1.
成功的EAP-GPSK消息交换如图1所示。
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/EAP-NAK | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/EAP-NAK | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 15: EAP-GPSK: Unsuccessful Exchange
(Unacceptable AAA Server Identity; ID_Server)
Figure 15: EAP-GPSK: Unsuccessful Exchange
(Unacceptable AAA Server Identity; ID_Server)
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-Fail | |
| | (PSK Not Found or Authentication | |
| | Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-Fail | |
| | (PSK Not Found or Authentication | |
| | Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-Fail | |
| | (PSK Not Found or Authentication | |
| | Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-Fail | |
| | (PSK Not Found or Authentication | |
| | Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 16: EAP-GPSK: Unsuccessful Exchange (Unknown User)
图16:EAP-GPSK:交换失败（未知用户）
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-Fail | |
| | (Authentication Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-Fail | |
| | (Authentication Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-Fail | |
| | (Authentication Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-Fail | |
| | (Authentication Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 17: EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2)
图17:EAP-GPSK:交换失败（GPSK-2中的MAC无效）
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/ | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Request/ | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/ | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Request/ | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 18: EAP-GPSK: Unsuccessful Exchange (Authorization Failure)
图18:EAP-GPSK:交换失败（授权失败）
[RFC3748] highlights several attacks that are possible against EAP since EAP itself does not provide any security.
[RFC3748]强调了几种可能针对EAP的攻击，因为EAP本身不提供任何安全性。
This section discusses the claimed security properties of EAP-GPSK as well as vulnerabilities and security recommendations in the threat model of [RFC3748].
本节讨论EAP-GPSK声称的安全属性以及[RFC3748]威胁模型中的漏洞和安全建议。
Authentication mechanism: Shared Keys Ciphersuite negotiation: Yes (Section 12.16) Mutual authentication: Yes (Section 12.2) Integrity protection: Yes (Section 12.4) Replay protection: Yes (Section 12.5) Confidentiality: No (Section 12.17, Section 12.15) Key derivation: Yes (Section 12.8) Key strength: Varies (Section 12.8)
认证机制：共享密钥密码套件协商：是（第12.16节）相互认证：是（第12.2节）完整性保护：是（第12.4节）重播保护：是（第12.5节）机密性：否（第12.17节，第12.15节）密钥派生：是（第12.8节）密钥强度：变化（第12.8节）
Dictionary attack protection: No (Section 12.7) Fast reconnect: No (Section 12.14) Cryptographic binding: N/A (Section 12.18) Session independence: Yes (Section 12.10) Fragmentation: No (Section 12.12) Channel binding: Extensible (Section 12.13)
字典攻击保护：否（第12.7节）快速重新连接：否（第12.14节）加密绑定：不适用（第12.18节）会话独立性：是（第12.10节）碎片：否（第12.12节）通道绑定：可扩展（第12.13节）
EAP-GPSK provides mutual authentication.
EAP-GPSK提供相互认证。
The server believes that the peer is authentic when it successfully verifies the MAC in the GPSK-2 message; the peer believes that the server is authentic when it successfully verifies the MAC it receives with the GPSK-3 message.
当服务器成功验证GPSK-2消息中的MAC时，认为对等方是可信的；当对等方通过GPSK-3消息成功验证接收到的MAC时，它认为服务器是可信的。
The key used for mutual authentication is derived based on the long-term secret PSK, nonces contributed by both parties, and other parameters. The long-term secret PSK has to provide sufficient entropy and, therefore, sufficient strength. The nonces (RAND_Peer and RAND_Server) need to be fresh and unique for every session. In this way, EAP-GPSK is not different than other authentication protocols based on pre-shared keys.
用于相互认证的密钥是基于长期秘密PSK、双方提供的nonce和其他参数导出的。长期秘密PSK必须提供足够的熵，因此也必须提供足够的强度。nonce（RAND_对等和RAND_服务器）对于每个会话都需要是新的和唯一的。这样，EAP-GPSK与其他基于预共享密钥的认证协议没有什么不同。
EAP-GPSK supports protected result indications via the GPSK-Protected-Fail message. This allows a server to provide additional information to the peer as to why the session failed, and to do so in an authenticated way (if possible). In particular, the server can indicate the lack of PSK (account not present), failed authentication (PSK incorrect), or authorization failure (account disabled or unauthorized). Only the third message could be integrity protected.
EAP-GPSK通过GPSK受保护失败消息支持受保护结果指示。这允许服务器向对等方提供有关会话失败原因的附加信息，并以经过身份验证的方式（如果可能）提供这些信息。特别是，服务器可以指示缺少PSK（帐户不存在）、身份验证失败（PSK不正确）或授权失败（帐户被禁用或未经授权）。只有第三条消息可以被完整性保护。
It should be noted that these options make debugging network and account errors easier, but they also leak information about accounts to attackers. An attacker can determine if a particular ID_Peer is a valid user on the network or not. Thus, implementers should use care in enabling this particular option on their servers. If they are in an environment where such attacks are of concern, then protected result indication capabilities should be disabled.
应该注意的是，这些选项使调试网络和帐户错误变得更容易，但它们也会将有关帐户的信息泄漏给攻击者。攻击者可以确定特定ID_对等方是否是网络上的有效用户。因此，实现者应该谨慎地在其服务器上启用此特定选项。如果他们所处的环境中存在此类攻击，则应禁用受保护的结果指示功能。
EAP-GPSK provides integrity protection based on the ciphersuites suggested in this document. Integrity protection is a minimum feature every ciphersuite must provide.
EAP-GPSK根据本文档中建议的密码套件提供完整性保护。完整性保护是每个密码套件必须提供的最低功能。
EAP-GPSK provides replay protection of its mutual authentication part thanks to the use of random numbers RAND_Server and RAND_Peer. Since RAND_Server is 32 octets long, one expects to have to record 2**64 (i.e., approximately 1.84*10**19) EAP-GPSK successful authentications before a protocol run can be replayed. Hence, EAP-GPSK provides replay protection of its mutual authentication part as long as RAND_Server and RAND_Peer are chosen at random; randomness is critical for replay protection. RFC 4086 [RFC4086] describes techniques for producing random quantities.
由于使用随机数RAND_服务器和RAND_对等机，EAP-GPSK为其相互认证部分提供重播保护。由于RAND_服务器的长度为32个八位字节，因此在重播协议运行之前，需要记录2**64（即大约1.84*10**19）个EAP-GPSK成功身份验证。因此，只要随机选择RAND_服务器和RAND_对等点，EAP-GPSK就可以为其相互认证部分提供重播保护；随机性对于重播保护至关重要。RFC 4086[RFC4086]描述了用于产生随机量的技术。
Reflection attacks occur in bi-directional, challenge-response, mutual authentication protocols where an attacker, upon being issued a challenge by an authenticator, responds by issuing the same challenge back to the authenticator, obtaining the response, and then "reflecting" that same response to the original challenge.
反射攻击发生在双向、质询-响应、相互身份验证协议中，在该协议中，攻击者在收到身份验证器发出的质询后，通过向身份验证器发出相同的质询进行响应，获得响应，然后将相同的响应“反射”到原始质询。
EAP-GPSK provides protection against reflection attacks because the message formats for the challenges differ. The protocol does not consist of two independent authentications, but rather the authentications are tightly coupled.
EAP-GPSK提供了针对反射攻击的保护，因为用于挑战的消息格式不同。该协议不包含两个独立的认证，而是认证紧密耦合。
Also note that EAP-GPSK does not provide MAC protection of the OP-Code field, but again since each message is constructed differently, it would not be possible to change the OP-Code of a valid message and still have it be parseable and accepted by the recipient.
还请注意，EAP-GPSK不提供操作码字段的MAC保护，但由于每个消息的构造不同，因此不可能更改有效消息的操作码，并且仍然使其可解析并被接收方接受。
EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be based on at least 16 octets of entropy to be fully secure. The EAP-GPSK protocol makes no special provisions to ensure keys based on passwords are used securely. Users who use passwords as the basis of their PSK are not protected against dictionary attacks. Derivation of the long-term shared secret from a password is strongly discouraged.
EAP-GPSK依赖于一个长期共享秘密（PSK），该长期共享秘密至少应基于16个八位组的熵才能完全安全。EAP-GPSK协议没有特别规定确保安全使用基于密码的密钥。使用密码作为PSK基础的用户不受字典攻击的保护。强烈反对从密码中派生长期共享秘密。
The success of a dictionary attack against EAP-GPSK depends on the strength of the long-term shared secret (PSK) it uses. The PSK used by EAP-GPSK SHOULD be drawn from a pool of secrets that is at least 2^128 bits large and whose distribution is uniformly random. Note that this does not imply resistance to dictionary attacks -- only that the probability of success in such an attack is acceptably remote.
针对EAP-GPSK的字典攻击的成功取决于它使用的长期共享密钥（PSK）的强度。EAP-GPSK使用的PSK应从至少2^128位大且分布均匀随机的秘密池中提取。请注意，这并不意味着对字典攻击的抵抗——只意味着这种攻击的成功概率是可以接受的。
EAP-GPSK supports key derivation as shown in Section 4.
EAP-GPSK支持密钥派生，如第4节所示。
Keys used within EAP-GPSK are all based on the security of the originating PSK. PSKs SHOULD have at least 16 octets of entropy. Independent of the protocol exchange (i.e., without knowing RAND_Peer and RAND_Server), the keys have been derived with sufficient input entropy to make them as secure as the underlying KDF output key length.
EAP-GPSK中使用的密钥都基于原始PSK的安全性。PSK应该至少有16个八位字节的熵。独立于协议交换（即，在不知道RAND_Peer和RAND_Server的情况下），密钥已以足够的输入熵导出，使其与底层KDF输出密钥长度一样安全。
There are three forms of denial-of-service (DoS) attacks relevant for this document, namely (1) attacks that lead to a vast amount of state being allocated, (2) attacks that attempt to prevent communication between the peer and server, and (3) attacks against computational resources.
本文档涉及三种形式的拒绝服务（DoS）攻击，即（1）导致大量状态被分配的攻击，（2）试图阻止对等方和服务器之间通信的攻击，以及（3）对计算资源的攻击。
In an EAP-GPSK conversation the server has to maintain state, namely the 32-octet RAND_Server, when transmitting the GPSK-1 message to the peer. An adversary could therefore flood a server with a large number of EAP-GPSK communication attempts. An EAP server may therefore ensure that an established state times out after a relatively short period of time when no further messages are received. This enables a sort of garbage collection.
在EAP-GPSK会话中，当向对等方传输GPSK-1消息时，服务器必须保持状态，即32个八位组的RAND_服务器。因此，对手可能会用大量EAP-GPSK通信尝试淹没服务器。因此，EAP服务器可以确保在相对较短的时间段之后，当没有接收到进一步的消息时，所建立的状态超时。这可以实现某种垃圾收集。
The client has to keep state information after receiving the GPSK-1 message. To prevent a replay attack, all the client needs to do is ensure that the value of RAND_Peer is consistent between GPSK-2 and GPSK-3. Message GPSK-3 contains all the material required to re-compute the keying material. Thus, if a client chooses to implement this client-side DoS protection mechanism, it may manage RAND_Peer and CSuite_Sel on a per-server basis for servers it knows, instead of on a per-message basis.
客户端在收到GPSK-1消息后必须保留状态信息。为了防止重播攻击，客户端需要做的就是确保RAND_Peer的值在GPSK-2和GPSK-3之间保持一致。消息GPSK-3包含重新计算键控材料所需的所有材料。因此，如果客户机选择实施这种客户端DoS保护机制，它可能会在每台服务器的基础上管理它知道的服务器的RAND_Peer和CSuite_Sel，而不是在每条消息的基础上。
Attacks that disrupt communication between the peer and server are mitigated by silently discarding messages with invalid MACs. Attacks against computational resources are mitigated by having very light-weight cryptographic operations required during each protocol round.
通过默默地丢弃带有无效MAC的消息，可以减轻中断对等方和服务器之间通信的攻击。通过在每个协议回合中使用非常轻量级的加密操作，可以减轻对计算资源的攻击。
The security considerations of EAP itself, see Sections 5.2 and 7 of RFC 3748 [RFC3748], are also applicable to this specification (e.g., for example concerning EAP-based notifications).
EAP本身的安全注意事项，参见RFC 3748[RFC3748]第5.2节和第7节，也适用于本规范（例如，关于基于EAP的通知）。
Thanks to its key derivation mechanisms, EAP-GPSK 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. The assumption that RAND_Peer and RAND_Server are random is central for the security of EAP-GPSK in general and session independence in particular.
由于其密钥派生机制，EAP-GPSK提供了会话独立性：被动攻击（如捕获EAP会话）或主动攻击（包括MSK或EMSK的泄露）无法泄露后续或先前的MSK或EMSK。RAND_对等机和RAND_服务器是随机的这一假设对于EAP-GPSK的安全性尤其是会话独立性至关重要。
EAP-GPSK does not provide perfect forward secrecy. Compromise of the PSK leads to compromise of recorded past sessions.
EAP-GPSK不提供完美的前向保密性。PSK的妥协导致过去记录的会议的妥协。
Compromise of the PSK enables the attacker to impersonate the peer and the server, and it allows the adversary to compromise future sessions.
PSK泄露使攻击者能够模拟对等方和服务器，并允许对手泄露未来会话。
EAP-GPSK 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, the choice of which is outside the scope of this document. The PSK used by EAP-GPSK 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 (e.g., those with different ID_Peer values) communicating with the same server.
EAP-GPSK不针对与第三方共享其PSK的合法对等方提供保护。此类保护可由PSK的适当存储库提供，其选择不在本文档范围内。EAP-GPSK使用的PSK只能在两方之间共享：对等方和服务器。特别是，与同一服务器通信的一组对等方（例如，具有不同ID_对等值的对等方）不得共享此PSK。
The PSK used by EAP-GPSK must be cryptographically separated from keys used by other protocols, otherwise the security of EAP-GPSK may be compromised.
EAP-GPSK使用的PSK必须以加密方式与其他协议使用的密钥分开，否则EAP-GPSK的安全性可能会受到损害。
EAP-GPSK does not support fragmentation and reassembly since the message size is relatively small. However, it should be noted that this impacts the length of protected data payloads that can be attached to messages. Also, if the EAP frame is larger than the MTU of the underlying transport, and that transport does not support fragmentation, the frame will most likely not be transported. Consequently, implementers and deployers should take care to ensure EAP-GPSK frames are short enough to work properly on the target underlying transport mechanism.
EAP-GPSK不支持分段和重组，因为消息大小相对较小。但是，应注意，这会影响可附加到消息的受保护数据有效负载的长度。此外，如果EAP帧大于底层传输的MTU，并且该传输不支持碎片，则该帧很可能不会被传输。因此，实现者和部署者应该注意确保EAP-GPSK帧足够短，能够在目标底层传输机制上正常工作。
This document enables the ability to exchange channel binding information. It does not, however, define the encoding of channel binding information in the document.
此文档支持交换通道绑定信息。但是，它没有定义文档中通道绑定信息的编码。
EAP-GPSK does not provide fast reconnect capability since this method is already at (or close to) the lower limit of the number of roundtrips and the cryptographic operations.
EAP-GPSK不提供快速重新连接功能，因为此方法已达到（或接近）往返次数和加密操作的下限。
Identity protection is not specified in this document. Extensions can be defined that enhance this protocol to provide this feature.
本文档中未指定身份保护。可以定义扩展来增强此协议以提供此功能。
EAP-GPSK provides protected ciphersuite negotiation via the indication of available ciphersuites by the server in the first message, and a confirmation by the peer in the subsequent message.
EAP-GPSK通过服务器在第一条消息中指示可用的密码套件以及对等方在后续消息中的确认来提供受保护的密码套件协商。
Note, however, that the GPSK-2 message may optionally contain a payload, ENC_PK(PD_Payload_Block), protected with an algorithm based on a selected ciphersuite before the ciphersuite list has actually been authenticated. In the classical downgrading attack, an adversary would choose a ciphersuite that is so weak that it can be broken in real time or would attempt to disable cryptographic protection altogether. The latter is not possible since any ciphersuite defined for EAP-GPSK must at least provide authentication and integrity protection. Confidentiality protection is optional. When, at some time in the future, a ciphersuite contains algorithms that can be broken in real-time, then a policy on peers and the server needs to indicate that such a ciphersuite must not be selected by any of parties.
然而，请注意，GPSK-2消息可选择性地包含有效载荷ENC_PK（PD_payload_Block），该有效载荷在实际验证密码套件列表之前由基于所选密码套件的算法保护。在经典的降级攻击中，对手会选择一个非常弱的密码套件，该套件可能会被实时破坏，或者试图完全禁用密码保护。后者是不可能的，因为为EAP-GPSK定义的任何密码套件必须至少提供身份验证和完整性保护。保密保护是可选的。如果在将来某个时间，密码套件包含可实时中断的算法，则对等方和服务器上的策略需要指示任何一方都不得选择此类密码套件。
Furthermore, an adversary may modify the selection of the ciphersuite for the client to select a ciphersuite that does not provide confidentiality protection. As a result, this would cause the content of PD_Payload_Block to be transmitted in cleartext. When protocol designers extend EAP-GPSK to carry information in the PD_Payload_Block of the GPSK-2 message, then it must be indicated whether confidentiality protection is mandatory. In case such an extension requires a ciphersuite with confidentiality protection, then the policy at the peer must be to not transmit information of that extension in the PD_Payload_Block of the GPSK-2 message. The peer may, if possible, delay the transmission of this information element to the GPSK-4 message where the ciphersuite negotiation has been confirmed already. In general, when a ciphersuite is selected that does not provide confidentiality protection, then information that demands confidentiality protection must not be included in any of the PD_Payload_Block objects.
此外，对手可以修改密码套件的选择，以便客户选择不提供保密保护的密码套件。因此，这将导致以明文形式传输PD_Payload_块的内容。当协议设计者扩展EAP-GPSK以在GPSK-2消息的PD_Payload_块中携带信息时，必须指出保密保护是否是强制性的。如果此类扩展需要具有保密保护的密码套件，则对等方的策略必须是不在GPSK-2消息的PD_Payload_块中传输该扩展的信息。如果可能，对等方可以延迟将该信息元素传输到已经确认密码套件协商的GPSK-4消息。通常，如果选择了不提供保密保护的密码套件，则要求保密保护的信息不得包含在任何PD_Payload_Block对象中。
Although EAP-GPSK provides confidentiality in its protected data payloads, it cannot claim to do so, per Section 7.2.1 of [RFC3748], since it does not support identity protection.
尽管EAP-GPSK在其受保护的数据有效载荷中提供保密性，但根据[RFC3748]第7.2.1节，EAP-GPSK不能声称这样做，因为它不支持身份保护。
Since EAP-GPSK does not tunnel another EAP method, it does not implement cryptographic binding.
由于EAP-GPSK不通过隧道传输另一个EAP方法，因此它不实现加密绑定。
IANA has allocated a new EAP Type for EAP-GPSK (51).
IANA已为EAP-GPSK分配了新的EAP类型（51）。
IANA has created a new registry for ciphersuites, protected data types, failure codes, and op-codes. IANA has added the specified ciphersuites, protected data types, failure codes, and op-codes to these registries as defined below. Values defining ciphersuites (block-based or hash-based), protected data payloads, failure codes, and op-codes can be added or modified per IETF Review [RFC5226].
IANA为密码套件、受保护的数据类型、故障代码和操作代码创建了一个新的注册表。IANA已将指定的密码套件、受保护的数据类型、故障代码和操作代码添加到这些注册表中，定义如下。根据IETF审查[RFC5226]，可以添加或修改定义密码套件（基于块或基于散列）、受保护数据有效载荷、故障代码和操作代码的值。
Figure 3 represents the initial contents of the "EAP-GPSK Ciphersuites" registry. The CSuite/Specifier field is 16 bits long. All other values are available via IANA registration. Each ciphersuite needs to provide processing rules and needs to specify how the following algorithms are instantiated: encryption, integrity, key derivation, and key length.
图3显示了“EAP-GPSK密码套件”注册表的初始内容。CSuite/说明符字段的长度为16位。所有其他值均可通过IANA注册获得。每个密码套件都需要提供处理规则，并需要指定以下算法的实例化方式：加密、完整性、密钥派生和密钥长度。
The following are the initial contents of the "EAP-GPSK Protected Data Payloads" registry:
以下是“EAP-GPSK受保护数据有效载荷”注册表的初始内容：
o 0x0000 : Reserved
o 0x0000：保留
The PData/Specifier field is 16 bits long, and all other values are available via IANA registration. Each extension needs to indicate whether confidentiality protection for transmission between the EAP peer and the EAP server is mandatory.
PData/说明符字段长度为16位，所有其他值均可通过IANA注册获得。每个扩展都需要指出EAP对等方和EAP服务器之间传输的保密保护是否是强制性的。
The following are the initial contents of the "EAP-GPSK Failure Codes" registry:
以下是“EAP-GPSK故障代码”注册表的初始内容：
o 0x00000000 : Reserved
o 0x00000000：保留
o 0x00000001 : PSK Not Found
o 0x00000001:未找到PSK
o 0x00000002 : Authentication Failure
o 0x00000002:身份验证失败
o 0x00000003 : Authorization Failure
o 0x00000003:授权失败
The Failure-Code field is 32 bits long, and all other values are available via IANA registration.
故障代码字段的长度为32位，所有其他值均可通过IANA注册获得。
The following are the initial contents of the "EAP-GPSK OP Codes" registry:
以下是“EAP-GPSK操作码”注册表的初始内容：
o 0x00 : Reserved
o 0x00：保留
o 0x01 : GPSK-1
o 0x01:GPSK-1
o 0x02 : GPSK-2
o 0x02:GPSK-2
o 0x03 : GPSK-3
o 0x03:GPSK-3
o 0x04 : GPSK-4
o 0x04:GPSK-4
o 0x05 : GPSK-Fail
o 0x05:GPSK失败
o 0x06 : GPSK-Protected-Fail
o 0x06:GPSK保护失败
The OP-Code field is 8 bits long, and all other values are available via IANA registration.
操作码字段的长度为8位，所有其他值均可通过IANA注册获得。
This work is a joint effort of the EAP Method Update (EMU) design team of the EMU Working Group that was created to develop a mechanism based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 4017 [RFC4017] requirements. The design team members (in alphabetical order) were:
这项工作是EMU工作组EAP方法更新（EMU）设计团队的共同努力，该团队旨在开发基于强共享机密的机制，满足RFC 3748[RFC3748]和RFC 4017[RFC4017]要求。设计团队成员（按字母顺序）为：
o Jari Arkko
o 贾里·阿克科
o Mohamad Badra
o 穆罕默德·巴德拉
o Uri Blumenthal
o 乌里·布鲁门塔尔
o Charles Clancy
o 查尔斯·克兰西
o Lakshminath Dondeti
o 莱克什米纳顿代蒂酒店
o David McGrew
o 大卫·麦克格鲁
o Joe Salowey
o 乔·萨洛维
o Sharma Suman
o 夏尔玛·苏曼
o Hannes Tschofenig
o 汉内斯·乔菲尼
o Jesse Walker
o 杰西·沃克
Finally, we would like to thank Thomas Otto for his reviews, feedback, and text contributions.
最后，我们要感谢Thomas Otto的评论、反馈和文本贡献。
We would like to thank:
我们要感谢：
o Jouni Malinen and Bernard Aboba for their early comments on the document in June 2006. Jouni Malinen developed the first prototype implementation.
o Jouni Malinen和Bernard Aboba感谢他们在2006年6月对该文件的早期评论。Jouni Malinen开发了第一个原型实现。
o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela Vanderveen, and Ray Bell for their input to the ciphersuite discussions between July and August 2006.
o Lakshminath Dondeti、David McGrew、Bernard Aboba、Michaela Vanderveen和Ray Bell感谢他们在2006年7月至8月的ciphersuite讨论中的贡献。
o Lakshminath Dondeti for his detailed review (sent to the EMU mailing list on 12 July 2006).
o Lakshminath Dondeti进行详细审查（于2006年7月12日发送至欧洲货币联盟邮件列表）。
o Based on a review requested from NIST, Quynh Dang suggested changes to the GKDF function (December 2006).
o 根据NIST要求的审查，Quynh Dang建议对GKDF职能进行变更（2006年12月）。
o Jouni Malinen and Victor Fajardo for their review in January 2007.
o Jouni Malinen和Victor Fajardo在2007年1月进行了审查。
o Jouni Malinen for his suggestions regarding the examples and the key derivation function in February 2007.
o 2007年2月，Jouni Malinen就示例和关键推导函数提出了建议。
o Bernard Aboba and Jouni Malinen for their review in February 2007.
o Bernard Aboba和Jouni Malinen于2007年2月进行了审查。
o Vidya Narayanan for her review in March 2007.
o 维迪亚·纳拉亚南于2007年3月发表评论。
o Pasi Eronen for his IESG review in March and July 2008.
o Pasi Eronen于2008年3月和7月接受IESG审查。
o Dan Harkins for his review in June 2008.
o Dan Harkins于2008年6月发表评论。
o Joe Salowey, the EMU working group chair, provided a document review in April 2007. Jouni Malinen also reviewed the document during the same month.
o 欧洲货币联盟工作组主席Joe Salowey于2007年4月提供了一份文件审查。Jouni Malinen也在同一个月审查了该文件。
o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov, and Prof. John C. Mitchell for their analysis of EAP-GPSK, for their input to the key derivation function, and for pointing us to a client-side DoS attack and to a downgrading attack. Based on their input, the key derivation function has been modified and the text in the security considerations section has been updated.
o 我们要感谢Paul Rowe、Arnab Roy、Andre Scedrov教授和John C.Mitchell教授对EAP-GPSK的分析，感谢他们对密钥派生函数的输入，感谢他们向我们指出客户端DoS攻击和降级攻击。根据他们的输入，修改了密钥派生函数，并更新了“安全注意事项”部分中的文本。
o Finally, we would like to thank our working group chair, Joe Salowey, for his support and for the time he spent discussing open issues with us.
o 最后，我们要感谢工作组主席Joe Salowey的支持，感谢他花时间与我们讨论未决问题。
[AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", Federal Information Processing Standards (FIPS) 197, November 2001.
[AES]国家标准与技术研究所，“高级加密标准（AES）规范”，联邦信息处理标准（FIPS）197，2001年11月。
[CBC] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Encryption -- Methods and Techniques", Special Publication (SP) 800-38A, December 2001.
[CBC]国家标准与技术研究所，“分组密码加密模式的建议——方法和技术”，特别出版物（SP）800-38A，2001年12月。
[CMAC] 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.
[CMAC]国家标准与技术研究所，“分组密码操作模式建议：认证CMAC模式”，特别出版物（SP）800-38B，2005年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]Eastlake，D.和T.Hansen，“美国安全哈希算法（SHA和HMAC-SHA）”，RFC 46342006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
[80211] "Information technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-2007, March 2007.
[80211]“信息技术-系统间电信和信息交换-局域网和城域网-特定要求-第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11-2007，2007年3月。
[ENTNUM] IANA, "SMI Network Management Private Enterprise Codes", Private Enterprise Numbers, <http://www.iana.org>.
[ENTNUM]IANA，“SMI网络管理私有企业代码”，私有企业编号<http://www.iana.org>.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
Authors' Addresses
作者地址
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 USA
T.Charles Clancy国防部电信科学实验室8080美国马里兰州格林米德大道学院公园20740
EMail: clancy@ltsnet.net
EMail: clancy@ltsnet.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
EMail: Hannes.Tschofenig@gmx.net
EMail: Hannes.Tschofenig@gmx.net