Network Working Group H. Tschofenig
Request for Comments: 5106 D. Kroeselberg
Category: Experimental Nokia Siemens Networks
A. Pashalidis
NEC
Y. Ohba
Toshiba
F. Bersani
France Telecom
February 2008
Network Working Group H. Tschofenig
Request for Comments: 5106 D. Kroeselberg
Category: Experimental Nokia Siemens Networks
A. Pashalidis
NEC
Y. Ohba
Toshiba
F. Bersani
France Telecom
February 2008
The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method
可扩展身份验证协议Internet密钥交换协议版本2（EAP-IKEv2）方法
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.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode.
本文档指定了EAP-IKEv2，这是一种基于Internet密钥交换（IKEv2）协议的可扩展身份验证协议（EAP）方法。EAP-IKEv2提供EAP对等方和EAP服务器之间的相互身份验证和会话密钥建立。它支持基于密码、高熵共享密钥和公钥证书的身份验证技术。EAP-IKEv2还提供对加密密码套件协商、哈希函数灵活性、身份保密性（在某些操作模式下）、碎片和可选的“快速重新连接”模式的支持。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
4. Fast Reconnect ..................................................9
5. Key Derivation .................................................12
6. Session ID, Peer ID, and Server ID .............................13
7. Error Handling .................................................13
8. Specification of Protocol Fields ...............................16
8.1. The Flags, Message Length, and Integrity Checksum
Data Fields ...............................................17
8.2. EAP-IKEv2 Header ..........................................19
8.3. Security Association Payload ..............................19
8.4. Key Exchange Payload ......................................20
8.5. Nonce Payload .............................................20
8.6. Identification Payload ....................................20
8.7. Certificate Payload .......................................20
8.8. Certificate Request Payload ...............................20
8.9. Encrypted Payload .........................................20
8.10. Authentication Payload ...................................20
8.11. Notify Payload ...........................................21
8.12. Next Fast-ID Payload .....................................21
9. Payload Types and Extensibility ................................22
10. Security Considerations .......................................22
10.1. Protected Ciphersuite Negotiation ........................23
10.2. Mutual Authentication ....................................23
10.3. Integrity Protection .....................................23
10.4. Replay Protection ........................................23
10.5. Confidentiality ..........................................23
10.6. Key Strength .............................................24
10.7. Dictionary Attack Resistance .............................24
10.8. Fast Reconnect ...........................................25
10.9. Cryptographic Binding ....................................25
10.10. Session Independence ....................................25
10.11. Fragmentation ...........................................26
10.12. Channel Binding .........................................26
10.13. Summary .................................................26
11. IANA Considerations ...........................................27
12. Contributors ..................................................28
13. Acknowledgements ..............................................28
14. References ....................................................29
14.1. Normative References .....................................29
14.2. Informative References ...................................29
Appendix A ........................................................30
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
4. Fast Reconnect ..................................................9
5. Key Derivation .................................................12
6. Session ID, Peer ID, and Server ID .............................13
7. Error Handling .................................................13
8. Specification of Protocol Fields ...............................16
8.1. The Flags, Message Length, and Integrity Checksum
Data Fields ...............................................17
8.2. EAP-IKEv2 Header ..........................................19
8.3. Security Association Payload ..............................19
8.4. Key Exchange Payload ......................................20
8.5. Nonce Payload .............................................20
8.6. Identification Payload ....................................20
8.7. Certificate Payload .......................................20
8.8. Certificate Request Payload ...............................20
8.9. Encrypted Payload .........................................20
8.10. Authentication Payload ...................................20
8.11. Notify Payload ...........................................21
8.12. Next Fast-ID Payload .....................................21
9. Payload Types and Extensibility ................................22
10. Security Considerations .......................................22
10.1. Protected Ciphersuite Negotiation ........................23
10.2. Mutual Authentication ....................................23
10.3. Integrity Protection .....................................23
10.4. Replay Protection ........................................23
10.5. Confidentiality ..........................................23
10.6. Key Strength .............................................24
10.7. Dictionary Attack Resistance .............................24
10.8. Fast Reconnect ...........................................25
10.9. Cryptographic Binding ....................................25
10.10. Session Independence ....................................25
10.11. Fragmentation ...........................................26
10.12. Channel Binding .........................................26
10.13. Summary .................................................26
11. IANA Considerations ...........................................27
12. Contributors ..................................................28
13. Acknowledgements ..............................................28
14. References ....................................................29
14.1. Normative References .....................................29
14.2. Informative References ...................................29
Appendix A ........................................................30
This document specifies EAP-IKEv2, an EAP method that is based on the Internet Key Exchange Protocol version 2 (IKEv2) [1]. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on the following types of credentials:
本文件规定了EAP-IKEv2，这是一种基于互联网密钥交换协议版本2（IKEv2）[1]的EAP方法。EAP-IKEv2提供EAP对等方和EAP服务器之间的相互身份验证和会话密钥建立。它支持基于以下凭据类型的身份验证技术：
o Asymmetric key pairs: these are public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party.
o 非对称密钥对：这些是公钥/私钥对，其中公钥嵌入到数字证书中，相应的私钥仅为一方所知。
o Passwords: these are low-entropy bit strings that are known to both the server and the peer.
o 密码：这些是服务器和对等方都知道的低熵位字符串。
o Symmetric keys: these are high-entropy bit strings that are known to both the server and the peer.
o 对称密钥：这些是服务器和对等方都知道的高熵位字符串。
It is possible to use a different authentication credential (and thereby technique) for each direction, e.g., the EAP server may authenticate itself using a public/private key pair and the EAP client may authenticate itself using a symmetric key. In particular, the following combinations are expected to be used in practice; these are referred to as "use cases" or "modes" in the remainder of this document:
可以对每个方向使用不同的认证凭证（从而使用不同的技术），例如，EAP服务器可以使用公钥/私钥对来认证自己，EAP客户端可以使用对称密钥来认证自己。具体而言，以下组合预计将在实践中使用：；在本文档的其余部分中，这些被称为“用例”或“模式”：
1. EAP server: asymmetric key pair, EAP peer: asymmetric key pair
1. EAP服务器：非对称密钥对，EAP对等方：非对称密钥对
2. EAP server: asymmetric key pair, EAP peer: symmetric key
2. EAP服务器：非对称密钥对，EAP对等方：对称密钥
3. EAP server: asymmetric key pair, EAP peer: password
3. EAP服务器：非对称密钥对，EAP对等方：密码
4. EAP server: symmetric key, EAP peer: symmetric key
4. EAP服务器：对称密钥，EAP对等方：对称密钥
Note that in use cases 2 and 4, a symmetric key is assumed to be chosen uniformly at random from its key space; it is therefore assumed that symmetric keys are not derived from passwords. Deriving a symmetric key from a password is insecure when used with mode 4 since the exchange is vulnerable to dictionary attacks, as described in more detail in Section 10.7. Also note that in use case 3, the EAP server must either have access to all passwords in plaintext, or, alternatively, for each password store, the value prf(password,"Key Pad for EAP-IKEv2") for all supported pseudorandom functions (also
注意，在用例2和4中，假设对称密钥从其密钥空间中均匀随机地选择；因此，假设对称密钥不是从密码派生的。当与模式4一起使用时，从密码派生对称密钥是不安全的，因为交换机容易受到字典攻击，如第10.7节所述。还请注意，在用例3中，EAP服务器必须能够访问明文形式的所有密码，或者，对于每个密码存储，对于所有支持的伪随机函数（也包括
see Section 8.10 below and Section 2.15 of [1]). Other conceivable use cases are not expected to be used in practice due to key management issues, and have not been considered in this document.
见下文第8.10节和[1]第2.15节。由于关键管理问题，其他可能的用例预计不会在实践中使用，本文档中未考虑到这些用例。
Note that the IKEv2 protocol is able to carry EAP exchanges. By contrast, EAP-IKEv2 does not inherit this capability. That is, it is not possible to tunnel EAP methods inside EAP-IKEv2. Also note that the set of functionality provided by EAP-IKEv2 is similar, but not identical, to that provided by other EAP methods such as, for example, EAP-TLS [6].
请注意，IKEv2协议能够承载EAP交换。相比之下，EAP-IKEv2并不继承此功能。也就是说，不可能在EAP-IKEv2内隧道EAP方法。还请注意，EAP-IKEv2提供的功能集与其他EAP方法（例如EAP-TLS）提供的功能集相似，但不完全相同[6]。
The remainder of this document is structured as follows:
本文件其余部分的结构如下：
o Section 2 provides an overview of the terminology and the abbreviations used in this document.
o 第2节概述了本文件中使用的术语和缩写。
o Section 3 provides an overview of the full EAP-IKEv2 exchange and thereby specifies the protocol message composition.
o 第3节概述了完整的EAP-IKEv2交换，从而指定了协议消息的组成。
o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode of operation.
o 第4节规定了可选的EAP-IKEv2“快速重新连接”操作模式。
o Section 5 specifies how exportable session keys are derived.
o 第5节指定如何导出可导出会话密钥。
o Section 6 specifies how the Session-ID, Peer-ID, and Server-ID elements are derived.
o 第6节指定如何派生会话ID、对等ID和服务器ID元素。
o Section 7 specifies how errors that may potentially occur during protocol execution are handled.
o 第7节指定如何处理协议执行期间可能发生的错误。
o Section 8 specifies the format of the EAP-IKEv2 data fields. Section 8.1 describes how fragmentation is handled in EAP-IKEv2.
o 第8节规定了EAP-IKEv2数据字段的格式。第8.1节描述了EAP-IKEv2中如何处理碎片。
o Section 9 specifies the payload type values and describes protocol extensibility.
o 第9节指定了有效负载类型值并描述了协议扩展性。
o Section 10 provides a list of claimed security properties.
o 第10节提供了声明的安全属性列表。
This document makes use of terms defined in [2] and [1]. In addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [3].
本文件使用了[2]和[1]中定义的术语。此外，本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[3]中所述进行解释。
A list of abbreviations that are used in this document follows.
本文件中使用的缩略语列表如下。
AUTH:
认证：
Denotes a data field containing either a Message Authentication Code (MAC) or a signature. This field is embedded into an Authentication payload, defined in Section 8.10.
表示包含消息身份验证码（MAC）或签名的数据字段。该字段嵌入第8.10节中定义的身份验证有效负载中。
CERT:
证书：
Public key certificate or similar structure.
公钥证书或类似结构。
CERTREQ:
CERTREQ：
Certificate Request.
证书申请。
NFID:
NFID:
Next Fast-ID payload (see Sections 4 and 8.12)
下一个快速ID有效载荷（见第4节和第8.12节）
EMSK:
EMSK：
Extended Master Session Key, defined in [2].
[2]中定义的扩展主会话密钥。
HDR:
人类发展报告：
EAP-IKEv2 header, defined in Section 8.2.
第8.2节中定义的EAP-IKEv2标头。
I:
一:
Initiator, the party that sends the first message of an EAP-IKEv2 protocol run. This is always the EAP server.
启动器，发送EAP-IKEv2协议运行的第一条消息的一方。这始终是EAP服务器。
MAC:
雨衣：
Message Authentication Code. The result of a cryptographic operation that involves a symmetric key.
消息身份验证代码。涉及对称密钥的加密操作的结果。
MSK:
MSK:
Master Session Key, defined in [2].
[2]中定义的主会话密钥。
prf:
prf：
Pseudorandom function: a cryptographic function whose output is assumed to be indistinguishable from that of a truly random function.
伪随机函数：一种密码函数，其输出被认为与真实随机函数的输出不可区分。
R:
R:
Responder, the party that sends the second message of an EAP-IKEv2 protocol run. This is always the EAP peer.
响应者，发送EAP-IKEv2协议运行的第二条消息的一方。这始终是EAP对等点。
SA:
SA:
Security Association. In this document, SA denotes a type of payload that is used for the negotiation of the cryptographic algorithms that are to be used within an EAP-IKEv2 protocol run. Specifically, SAi denotes a set of choices that are accepted by an initiator, and SAr denotes the choice of the responder.
安全协会。在本文中，SA表示一种有效载荷，用于协商EAP-IKEv2协议运行中使用的加密算法。具体而言，SAi表示发起者接受的一组选择，SAr表示响应者的选择。
Signature:
签名：
The result of a cryptographic operation that involves an asymmetric key. In particular, it involves the private part of a public/private key pair.
涉及非对称密钥的加密操作的结果。特别是，它涉及公钥/私钥对的私有部分。
SK:
SK：
Session Key. In this document, the notation SK{x} denotes that x is embedded within an Encrypted payload, i.e., that x is encrypted and integrity-protected using EAP-IKEv2 internal keys. These keys are different in each direction.
会话密钥。在本文档中，符号SK{x}表示x嵌入在加密的有效载荷中，即x使用EAP-IKEv2内部密钥进行加密和完整性保护。这些键在每个方向上都不同。
SK_xx:
SK_xx：
EAP-IKEv2 internal key, defined in Section 2.14 of [1].
[1]第2.14节中定义的EAP-IKEv2内部密钥。
SKEYSEED:
斯凯塞德：
Keying material, defined in Section 2.14 of [1].
[1]第2.14节中定义的键控材料。
In this section, the full EAP-IKEv2 protocol run is specified. All messages are sent between two parties, namely an EAP peer and an EAP server. In EAP-IKEv2, the EAP server always assumes the role of the initiator (I), and the EAP peer that of the responder (R) of an exchange.
在本节中，指定了完整的EAP-IKEv2协议运行。所有消息都在两方之间发送，即EAP对等方和EAP服务器。在EAP-IKEv2中，EAP服务器始终扮演交换机的发起方（I）的角色，EAP对等方扮演交换机的响应方（R）的角色。
The semantics and formats of EAP-IKEv2 messages are similar, albeit not identical, to those specified in IKEv2 [1] for the establishment of an IKE Security Association. The full EAP-IKEv2 protocol run consists of two roundtrips that are followed by either an EAP-Success or an EAP-Failure message. An optional roundtrip for exchanging EAP identities may precede the two exchanges.
EAP-IKEv2消息的语义和格式与IKEv2[1]中为建立IKE安全关联而指定的语义和格式相似，但不完全相同。完整的EAP-IKEv2协议运行包括两次往返，然后是EAP成功或EAP失败消息。交换EAP身份的可选往返可能在两次交换之前。
1. R<-I: EAP-Request/Identity
1. R<-I:EAP请求/标识
2. R->I: EAP-Response/Identity(Id)
2. R->I:EAP响应/标识（Id）
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
3. R<-I:EAP需求（HDR、SAi、KEi、Ni）
4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}])
4. R->I:EAP Res（HDR、SAr、KEr、Nr、[CERTREQ]、[SK{IDr}]）
5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH})
5. R<-I:EAP-Req（HDR，SK{IDi，[CERT]，[CERTREQ]，[NFID]，AUTH}）
6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH})
6. R->I:EAP Res（HDR，SK{IDr，[CERT]，AUTH}）
7. R<-I: EAP-Success
7. R<-I:EAP成功
Figure 1: EAP-IKEv2 Full, Successful Protocol Run
图1:EAP-IKEv2完整、成功的协议运行
Figure 1 shows the full EAP-IKEv2 protocol run, including the optional EAP identity exchange (messages 1 and 2). A detailed specification of the message composition follows.
图1显示了完整的EAP-IKEv2协议运行，包括可选的EAP标识交换（消息1和2）。下面是消息组合的详细说明。
Messages 1 and 2 are a standard EAP Identity Request and Response, as defined in [2]. Message 3 is the first EAP-IKEv2-specific message. With this, the server starts the actual EAP authentication exchange. It contains the initiator Security Parameter Index (SPI) in the EAP-IKEv2 header (HDR) (the initiator selects a new SPI for each protocol run), the set of cryptographic algorithms the server is willing to accept for the protection of EAP-IKEv2 traffic (encryption and integrity protection), and the derivation of the session key. This set is encoded in the Security Association payload (SAi). It also contains a Diffie-Hellman payload (KEi), and a Nonce payload (Ni).
消息1和2是标准EAP身份请求和响应，如[2]中所定义。消息3是第一条EAP-IKEv2特定消息。这样，服务器启动实际的EAP身份验证交换。它包含EAP-IKEv2标头（HDR）中的启动器安全参数索引（SPI）（启动器为每个协议运行选择一个新的SPI）、服务器愿意接受的用于保护EAP-IKEv2通信量（加密和完整性保护）的加密算法集，以及会话密钥的派生。此集合在安全关联有效负载（SAi）中编码。它还包含Diffie-Hellman有效载荷（KEi）和Nonce有效载荷（Ni）。
When the peer receives message 3, it selects a set of cryptographic algorithms from the ones that are proposed in the message. In this overview, it is assumed that an acceptable such set exists (and is thus selected), and that the Diffie-Hellman value KEi belongs to an acceptable group. The peer then generates a non-zero Responder SPI value for this protocol run, its own Diffie-Hellman value (KEr) and nonce (Nr), and calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, according to Section 2.14 of [1]. The peer then constructs message 4. In the context of use cases 1, 2, and 3, the peer's local policy MAY dictate the inclusion of the optional CERTREQ payload in that message, which gives a hint to the server to include a certificate for its public key in its next message. In the context of use case 4, the peer MUST include the optional SK{IDr} payload, which contains its EAP-IKEv2 identifier, encrypted and integrity-protected within an Encrypted payload. The keys used to construct this Encrypted payload are SK_er (for encryption) and SK_ar (for integrity protection), in accordance with
当对等方接收到消息3时，它从消息中提出的密码算法中选择一组密码算法。在本概述中，假设存在可接受的此类集合（并因此被选中），并且Diffie-Hellman值KEi属于可接受的组。然后，根据[1]第2.14节，对等方为该协议运行生成一个非零响应程序SPI值，它自己的Diffie-Hellman值（KEr）和nonce（Nr），并计算密钥skyseed、sku-d、SK-ai、SK-ar、SK-ei、SK-er、SK-pi和SK-pr。然后，对等方构造消息4。在用例1、2和3的上下文中，对等方的本地策略可能规定在该消息中包含可选的CERTREQ负载，这会提示服务器在其下一条消息中包含其公钥的证书。在用例4的上下文中，对等方必须包括可选的SK{IDr}有效载荷，该有效载荷包含其EAP-IKEv2标识符，在加密的有效载荷中进行加密和完整性保护。用于构造此加密有效负载的密钥是SK_er（用于加密）和SK_ar（用于完整性保护），根据
[1]. The responder's EAP-IKEv2 identifier (IDr) is likely to be needed in these use cases by the server in order to select the correct symmetric key or password for the construction of the AUTH payload of message 5.
[1]. 在这些用例中，服务器可能需要响应者的EAP-IKEv2标识符（IDr），以便为构建消息5的验证有效负载选择正确的对称密钥或密码。
Upon reception of message 4, the server also computes SKEYSEED, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, according to Section 2.14 of [1]. If an SK{IDr} payload is included, the server decrypts it and verifies its integrity with the corresponding keys. In this overview, decryption and verification is assumed to succeed. The server then constructs message 5, which contains only the EAP-IKEv2 header followed by a single Encrypted payload. The keys used to generate the encrypted payload MUST be SK_ei (for encryption) and SK_ai (for integrity protection), in accordance with [1]. The initiator MUST embed at least two payloads in the Encrypted Payload, as follows. An Identification payload with the initiator's EAP-IKEv2 identifier MUST be embedded in the Encrypted payload. The Authentication payload MUST be embedded in the Encrypted payload. A Certificate payload, and/or a Certificate Request payload, MAY also be embedded in the Encrypted payload. Moreover, a Next Fast-Reconnect Identifier payload MAY also be embedded in the Encrypted payload. Message 5 is sent to the responder.
在接收到消息4后，服务器还根据[1]的第2.14节计算skyseed、sku d、sku ai、sku ar、sku ei、sku er、sku pi和sku pr。如果包含SK{IDr}有效负载，服务器将对其进行解密，并使用相应的密钥验证其完整性。在此概述中，假设解密和验证成功。然后，服务器构造消息5，其中仅包含EAP-IKEv2头，后跟一个加密的有效负载。根据[1]，用于生成加密有效载荷的密钥必须是SK_ei（用于加密）和SK_ai（用于完整性保护）。启动器必须在加密的有效负载中嵌入至少两个有效负载，如下所示。具有启动器EAP-IKEv2标识符的标识有效负载必须嵌入到加密的有效负载中。身份验证有效负载必须嵌入到加密的有效负载中。证书有效载荷和/或证书请求有效载荷也可以嵌入到加密的有效载荷中。此外，下一个快速重新连接标识符有效载荷也可以嵌入到加密的有效载荷中。消息5被发送到响应者。
Upon reception of message 5, the responder (EAP peer) authenticates the initiator (EAP server). The checks that are performed to this end depend on the use case, local policies, and are specified in [1]. These checks include (but may not be limited to) decrypting the Encrypted payload, verifying its integrity, and checking that the Authentication payload contains the expected value. If all checks succeed (which is assumed in this overview), then the responder constructs message 6. That message MUST contain the EAP-IKEv2 header followed by a single Encrypted payload, in which at least two further payloads MUST be embedded, as shown in Figure 1.
在接收到消息5后，响应者（EAP对等方）对发起方（EAP服务器）进行身份验证。为此目的执行的检查取决于用例、本地策略，并在[1]中指定。这些检查包括（但不限于）解密加密的有效负载、验证其完整性以及检查认证有效负载是否包含预期值。如果所有检查都成功（在本概述中假定），则响应者构造消息6。该消息必须包含EAP-IKEv2报头，后跟一个加密的有效负载，其中必须嵌入至少两个额外的有效负载，如图1所示。
Upon reception of message 6, the initiator (EAP server) authenticates the responder (EAP peer). As above, the checks that are performed to this end depend on the use case, local policies, and MUST include decryption and verification of the Encrypted payload, as well as checking that the Authentication payload contains the expected value. If the optional SK{IDr} payload was included in message 4, the EAP server MUST also ensure that the IDr payload in message 6 is identical to that in message 4.
在接收到消息6后，发起方（EAP服务器）对响应方（EAP对等方）进行身份验证。如上所述，为此目的执行的检查取决于用例、本地策略，并且必须包括加密负载的解密和验证，以及验证验证负载是否包含预期值。如果可选的SK{IDr}有效载荷包含在消息4中，EAP服务器还必须确保消息6中的IDr有效载荷与消息4中的相同。
If authentication succeeds, an EAP-Success message is sent to the responder as message 7. The EAP server and the EAP peer generate a Master Session Key (MSK) and an Extended Master Session Key (EMSK) after a successful EAP-IKEv2 protocol run, according to Section 5.
如果认证成功，EAP成功消息将作为消息7发送给响应者。根据第5节，EAP服务器和EAP对等方在成功运行EAP-IKEv2协议后生成主会话密钥（MSK）和扩展主会话密钥（EMSK）。
This section specifies a "fast reconnect" mode of operation for EAP-IKEv2. This mode is mandatory to implement, but optional to use. The purpose of fast reconnect is to enable an efficient re-authentication procedure that also results in a fresh MSK and EMSK. The "fast reconnect" mode can only be used where an EAP-IKEv2 security context already exists at both the server and the peer, and its usage is subject to the local policies. In other words, it can only be used by an EAP server/EAP peer pair that has already performed mutual authentication in a previous EAP-IKEv2 protocol run.
本节规定了EAP-IKEv2的“快速重新连接”操作模式。此模式是强制实现的，但可选择使用。快速重新连接的目的是实现有效的重新身份验证过程，从而产生新的MSK和EMSK。“快速重新连接”模式只能在服务器和对等机上已经存在EAP-IKEv2安全上下文且其使用受本地策略约束的情况下使用。换句话说，它只能由在先前EAP-IKEv2协议运行中已执行相互身份验证的EAP服务器/EAP对等对使用。
The fast reconnect mode makes use of dedicated "fast reconnect EAP identifiers". The idea is that the server indicates its willingness to engage in "fast reconnect" protocol runs in the future by including the optional "Next Fast-ID" (NFID) payload in message 5 of a "full" protocol run (see Figure 1), or in message 3 of a "fast reconnect" protocol run (see Figure 2). This NFID payload contains a special EAP identity, denoted Fast Reconnect Identity (FRID) as the Network Access Identifier (NAI) in the EAP-Response/Identity message. The FRID contains an obfuscated username part and a realm part. When generating a FRID, the following aspects should be considered:
快速重新连接模式使用专用的“快速重新连接EAP标识符”。其思想是，服务器通过在“完整”协议运行的消息5（见图1）或“快速重新连接”协议运行的消息3（见图2）中包含可选的“下一个快速ID”（NFID）有效负载，表明其愿意在未来参与“快速重新连接”协议运行。此NFID有效负载包含一个特殊的EAP标识，表示为快速重新连接标识（FRID），作为EAP响应/标识消息中的网络访问标识（NAI）。FRID包含一个模糊的用户名部分和一个领域部分。生成FRID时，应考虑以下方面：
The FRID and therefore the pseudonym usernames are generated by the EAP server. The EAP server produces pseudonym usernames in an implementation-dependent manner. Only the EAP server needs to be able to map the pseudonym username to the permanent identity.
FRID和笔名用户名由EAP服务器生成。EAP服务器以依赖于实现的方式生成假名用户名。只有EAP服务器需要能够将假名用户名映射到永久身份。
EAP-IKEv2 includes no provisions to ensure that the same EAP server that generated a pseudonym username will be used on the authentication exchange when the pseudonym username is used. It is recommended that the EAP servers implement some centralized mechanism to allow all EAP servers of the home operator to map pseudonyms generated by other severs to the permanent identity. If no such mechanism is available, then the EAP server, failing to understand a pseudonym issued by another server, can request the peer to send the permanent identity.
EAP-IKEv2不包括确保在使用假名用户名时，在身份验证交换上使用生成假名用户名的同一EAP服务器的规定。建议EAP服务器实施某种集中式机制，以允许家庭运营商的所有EAP服务器将其他服务器生成的假名映射到永久身份。如果没有此类机制可用，则EAP服务器无法理解另一台服务器发出的假名，可以请求对等方发送永久身份。
When generating FRIDs, the server SHOULD choose a fresh and unique FRID that is different from the previous ones that were used after the same full authentication exchange. The FRID SHOULD include a random component in the username part. The random component works as a reference to the security context. Regardless of the construction method, the pseudonym username MUST conform to the grammar specified for the username portion of an NAI. Also, the FRID MUST conform to the NAI grammar [4]. The EAP servers, which subscribers of an operator can use, MUST ensure that the username part of a FRIDs that they generate are unique.
生成FRID时，服务器应选择一个新的、唯一的FRID，该FRID不同于在相同的完全身份验证交换之后使用的先前FRID。FRID应该在用户名部分包含一个随机组件。随机组件用作对安全上下文的引用。无论构造方法如何，假名用户名必须符合NAI用户名部分指定的语法。此外，FRID必须符合NAI语法[4]。运营商订户可以使用的EAP服务器必须确保其生成的FRID的用户名部分是唯一的。
The peer MAY use the FRID to indicate to start a "fast reconnect" protocol run. The EAP Identity Response MUST be sent at the beginning of a "fast reconnect" protocol run. If, in the previous successful "full" (resp. "fast reconnect") EAP-IKEv2 protocol execution, the server had not included an NFID payload in message 5 (resp. 3), then the peer MUST NOT start a fast reconnect protocol run. On reception of FRID, the server maps it to an existing EAP-IKEv2 security context. Depending on local policy, the server either proceeds with the "fast reconnect" protocol run, or proceeds with message 3 of a "full" protocol run. If the server had advertised the FRID in the previous EAP-IKEv2 protocol execution, it SHOULD proceed with a "fast reconnect" protocol run. The peer MUST be able to correctly handle a message 3 of a "full" protocol run, even if it indicated a FRID in its EAP Identity Response.
对等方可使用FRID指示开始“快速重新连接”协议运行。EAP标识响应必须在“快速重新连接”协议运行开始时发送。如果在上一次成功的“完全”（响应“快速重新连接”）EAP-IKEv2协议执行中，服务器未在消息5（响应3）中包含NFID有效负载，则对等方不得启动快速重新连接协议运行。在接收FRID时，服务器将其映射到现有EAP-IKEv2安全上下文。根据本地策略，服务器要么继续执行“快速重新连接”协议运行，要么继续执行“完整”协议运行的消息3。如果服务器在前一次EAP-IKEv2协议执行中公布了FRID，则应继续执行“快速重新连接”协议运行。对等方必须能够正确处理“完整”协议运行的消息3，即使它在其EAP标识响应中指示FRID。
Because the peer may fail to save a FRID that was sent in the NFID payload (for example, due to malfunction), the EAP server SHOULD maintain, at least, the most recently used FRID in addition to the most recently issued FRID. If the authentication exchange is not completed successfully, then the server MUST NOT overwrite the FRID that was issued during the most recent successful authentication exchange.
由于对等方可能无法保存在NFID有效负载中发送的FRID（例如，由于故障），EAP服务器应至少维护除最近发布的FRID之外的最近使用的FRID。如果身份验证交换未成功完成，则服务器不得覆盖最近成功的身份验证交换期间发出的FRID。
The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA rekeying procedure, as specified in Section 2.18 of [1]. Thus, it uses a CREATE_CHILD_SA request and response. The SPIs on those two messages would be the SPIs negotiated on the previous exchange. During fast reconnect, the server and the peer MAY exchange fresh Diffie-Hellman values.
EAP-IKEv2快速重新连接交换类似于[1]第2.18节中规定的IKE-SA密钥更新程序。因此，它使用CREATE_CHILD_SA请求和响应。这两条消息上的SPI将是在上一次交换上协商的SPI。在快速重新连接期间，服务器和对等方可能会交换新的Diffie-Hellman值。
1. R<-I: EAP-Request/Identity
1. R<-I:EAP请求/标识
2. R->I: EAP-Response/Identity(FRID)
2. R->I:EAP响应/标识（FRID）
3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]})
3. R<-I:EAP请求（HDR，SK{SA，Ni，[KEi]，[NFID]}）
4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]})
4. R->I:EAP Res（HDR，SK{SA，Nr，[KEr]}）
5. R<-I: EAP-Success
5. R<-I:EAP成功
Figure 2: Fast Reconnect Protocol Run
图2：快速重新连接协议运行
Figure 2 shows the message exchange for the EAP-IKEv2 fast reconnect mode. As in the full mode, the EAP server is the initiator and the EAP peer is the responder. The first two messages constitute the standard EAP identity exchange. Note that, in order to use the "fast reconnect" mode, message 2 MUST be sent. This is in order to enable the peer to indicate its "fast reconnect" identity FRID in message 2.
图2显示了EAP-IKEv2快速重新连接模式的消息交换。在完全模式下，EAP服务器是发起方，EAP对等方是响应方。前两条消息构成标准EAP身份交换。请注意，为了使用“快速重新连接”模式，必须发送消息2。这是为了使对等方能够在消息2中指示其“快速重新连接”标识FRID。
If the server can map the FRID to an existing EAP-IKEv2 context it proceeds with message 3. Note that, in this message, the server MAY embed an NFID payload into the encrypted payload to provide a new FRID to the peer. The server MAY choose to perform a full EAP-IKEv2 run, in which case, it would respond with a message that conforms to the format of message 3 in Figure 1.
如果服务器可以将FRID映射到现有EAP-IKEv2上下文，则继续执行消息3。注意，在该消息中，服务器可以将NFID有效负载嵌入到加密的有效负载中，以向对等方提供新的FRID。服务器可以选择执行完整的EAP-IKEv2运行，在这种情况下，它将使用符合图1中消息3格式的消息进行响应。
Messages 3 and 4 establish a new EAP-IKEv2 security context. In message 3, the initiator MUST select a new (non-zero) value for the SPI field in each proposal substructure in the SA payload (see Section 3.3 of [1]). The value of the IKE_SA Responder's SPI field in HDR MUST be the one from the previous successful EAP-IKEv2 protocol run. The nonce inside the Nonce payload (Ni) MUST be fresh, and the Diffie-Hellman value inside the Diffie-Hellman payload (if present, KEi) MUST also be fresh. If present, the Diffie-Hellman value MUST be drawn from the same group as the Diffie-Hellman value in the previous successful full EAP-IKEv2 protocol run. Note that the algorithms and keys that are used to construct the Encrypted payload in message 3 are the same as in the previous successful EAP-IKEv2 protocol run.
消息3和4建立了新的EAP-IKEv2安全上下文。在消息3中，发起者必须为SA有效载荷中每个提案子结构中的SPI字段选择一个新的（非零）值（见[1]第3.3节）。HDR中IKE_SA响应程序的SPI字段的值必须是上次成功运行EAP-IKEv2协议时的值。nonce有效载荷（Ni）内的nonce必须是新的，Diffie-Hellman有效载荷（如果存在，KEi）内的Diffie-Hellman值也必须是新的。如果存在，Diffie-Hellman值必须与上次成功的完整EAP-IKEv2协议运行中的Diffie-Hellman值来自同一组。请注意，用于构造消息3中的加密有效负载的算法和密钥与先前成功运行的EAP-IKEv2协议中的算法和密钥相同。
Upon reception of message 3, the responder (EAP peer) decrypts and verifies the Encrypted payload. If successful (as assumed in Figure 2), it constructs message 4 in a fashion similar to the construction of message 3. The responder MUST choose a new (non-zero) value for the SPI field in each proposal substructure. Upon reception of message 4, the initiator (EAP server) decrypts and verifies the Encrypted payload. If a correct message 4 is received, then this protocol run is deemed successful, and the server responds with an EAP-Success message (message 5).
收到消息3后，响应者（EAP对等方）解密并验证加密的有效负载。如果成功（如图2所示），它将以类似于消息3的方式构造消息4。响应者必须为每个提案子结构中的SPI字段选择一个新的（非零）值。接收到消息4后，启动器（EAP服务器）解密并验证加密的有效负载。如果接收到正确的消息4，则此协议运行被视为成功，服务器将响应EAP成功消息（消息5）。
After successful EAP-IKEv2 fast reconnect protocol run, both the initiator and the responder generate fresh keying material that is used for the protection of subsequent EAP-IKEv2 traffic. Furthermore, both the initiator and the responder MUST generate a fresh MSK and EMSK and export them.
成功运行EAP-IKEv2快速重新连接协议后，启动器和响应程序都会生成新的密钥材料，用于保护后续EAP-IKEv2通信。此外，发起方和响应方都必须生成新的MSK和EMSK并将其导出。
The new EAP-IKEv2-specific keying material is computed in the same way as in the full EAP-IKEv2 protocol run, and in accordance with Section 2.18 of [1]. That is, SKEYSEED is computed as SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr are the nonces (without the Nonce payload headers) that were exchanged in messages 3 and 4, and g^ir (new) is the newly computed Diffie-Hellman key, if both the values KEi and KEr were present in messages 3 and 4. The remaining EAP-IKEv2-specific keys (SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the full EAP-IKEv2 protocol run.
新的EAP-IKEv2特定键控材料的计算方法与完整EAP-IKEv2协议运行中的计算方法相同，并符合[1]第2.18节的规定。也就是说，SKEYSEED被计算为SKEYSEED=prf（SK_d（old），[g^ir（new）]| Ni | Nr，其中SK_d（old）是来自先前成功的EAP-IKEv2协议运行的密钥SK_d，Ni和Nr是在消息3和4中交换的Nonce（没有Nonce有效负载头），g^ir（new）是新计算的Diffie Hellman密钥，如果值KEi和KEr都出现在消息3和4中。剩余的EAP-IKEv2特定密钥（SK_d、SK_ai、SK_ar、SK_ei、SK_er、SK_pi和SK_pr）在完整的EAP-IKEv2协议运行中生成。
The generation of a fresh MSK and EMSK follows the generation of the EAP-IKEv2-specific keys and adheres to the rules in Section 5.
新MSK和EMSK的生成遵循EAP-IKEv2特定密钥的生成，并遵守第5节中的规则。
Note 1: In EAP-IKEv2, the EAP server initiates the fast reconnect mode and thereby causes fresh session keys to be established.
注1：在EAP-IKEv2中，EAP服务器启动快速重新连接模式，从而建立新的会话密钥。
Note 2: It is conceivable that an adversary tries to launch a replay attack against the EAP-IKEv2 fast reconnect mode of operation. In particular, the adversary may try to send a previously captured message 3 in a subsequent fast reconnect protocol run. This replay attempt will, however, fail because the keys that the responder will use to verify and decrypt the Encrypted payload are changed with every successful reconnect protocol run.
注2：可以想象，对手试图对EAP-IKEv2快速重新连接操作模式发起重放攻击。具体而言，对手可在随后的快速重新连接协议运行中尝试发送先前捕获的消息3。但是，此重播尝试将失败，因为响应程序用于验证和解密加密负载的密钥在每次成功运行重新连接协议时都会发生更改。
This section describes how the Master Session Key (MSK) and the Extended Master Session Key (EMSK) are derived in EAP-IKEv2. It is expected that the MSK and the EMSK are exported by the EAP-IKEv2 process and be used in accordance with the EAP keying framework [7].
本节介绍如何在EAP-IKEv2中导出主会话密钥（MSK）和扩展主会话密钥（EMSK）。预计MSK和EMSK将通过EAP-IKEv2流程导出，并根据EAP密钥框架使用[7]。
During an EAP-IKEv2 protocol run, the initiator and the responder generate a number of keys, as described above and in accordance with Section 2.14 of [1]. The generation of these keys is based on a pseudorandom function (prf) that both parties have agreed to use and that is applied in an iterative fashion. This iterative fashion is specified in Section 2.13 of [1] and is denoted by prf+.
在EAP-IKEv2协议运行期间，发起方和响应方生成大量密钥，如上所述，并符合[1]第2.14节的规定。这些密钥的生成基于双方同意使用的伪随机函数（prf），并以迭代方式应用。[1]第2.13节规定了这种迭代方式，并用prf+表示。
In particular, following a successful EAP-IKEv2 protocol run, both parties generate 128 octets of keying material, denoted KEYMAT, as KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the nonces (just payload without headers) from messages 3 and 4 shown in Figure 1 (in the context of a full EAP-IKEv2 protocol run) or Figure 2 (in the context of a fast reconnect EAP-IKEv2 protocol run). Note that only the nonces are used, i.e., not the entire Nonce payload that contains them.
特别是，在成功运行EAP-IKEv2协议之后，双方生成128个八位字节的键控材料，表示为KEYMAT，表示为KEYMAT=prf+（SK_d，Ni | Nr），其中Ni和Nr是图1（在完整EAP-IKEv2协议运行的上下文中）或图2中所示的消息3和4的nonce（只是没有报头的有效负载）（在快速重新连接EAP-IKEv2协议运行的上下文中）。请注意，仅使用Nonce，即不使用包含它们的整个Nonce有效负载。
The first 64 octets of KEYMAT are exported as the EAP MSK, and the second 64 octets are exported as the EMSK.
KEYMAT的前64个八位字节作为EAP MSK导出，后64个八位字节作为EMSK导出。
The MSK and EMSK MUST NOT be generated unless an EAP-IKEv2 protocol run completes successfully. Note that the EAP-IKEv2 method does not produce an initialisation vector [7].
除非EAP-IKEv2协议运行成功完成，否则不得生成MSK和EMSK。请注意，EAP-IKEv2方法不会生成初始化向量[7]。
The EAP key management framework [7] requires that EAP methods export three information elements, called the Session-ID, the Peer-ID, and the Server-ID. In EAP-IKEv2, these elements are derived as follows:
EAP密钥管理框架[7]要求EAP方法导出三个信息元素，称为会话ID、对等ID和服务器ID。在EAP-IKEv2中，这些元素派生如下：
o The Session-ID is constructed and exported as the concatenation of the following three elements, in this order: (a) the EAP Code Type for EAP-IKEv2 (to be defined by IANA), (b) the contents of the Nonce Data field of the Nonce Payload Ni from message 3, (c) the contents of the Nonce Data field of the Nonce Payload Nr from message 4.
o 会话ID被构造并导出为以下三个元素的串联，顺序如下：（a）EAP-IKEv2的EAP代码类型（由IANA定义），（b）来自消息3的非有效载荷Ni的非有效载荷数据字段的内容，（c）来自消息4的非有效载荷Nr的非有效载荷的非有效载荷数据字段的内容。
o In case of a full EAP-IKEv2 protocol run, the Peer-ID is constructed and exported as the content of the Identification Data field of the Identification Payload IDr from message 6. Note that only the "actual" identification data is exported, as indicated in the Payload Length field; if the Identification Data field contains any padding, this padding is ignored. In case of a "fast reconnect" protocol run, the Peer-ID field is constructed in exactly the same manner, where message 6 refers to the full EAP-IKEv2 protocol run that originally established the security context between the EAP peer and EAP server.
o 在完整EAP-IKEv2协议运行的情况下，对等ID被构造并导出为来自消息6的标识有效负载IDr的标识数据字段的内容。注意，如有效载荷长度字段所示，仅导出“实际”标识数据；如果标识数据字段包含任何填充，则忽略此填充。在“快速重新连接”协议运行的情况下，对等ID字段以完全相同的方式构造，其中消息6表示最初在EAP对等和EAP服务器之间建立安全上下文的完整EAP-IKEv2协议运行。
o In case of a full EAP-IKEv2 protocol run, the Server-ID is constructed and exported as the contents of the Identification Data field of the Identification Payload IDi from message 5. Note that only the "actual" identification data is exported, as indicated in the Payload Length field; if the Identification Data field contains any padding, this padding is ignored. In case of a "fast reconnect" protocol run, the Server-ID field is constructed in exactly the same manner, where message 5 refers to the full EAP-IKEv2 protocol run that originally established the security context between the EAP peer and EAP server.
o 在完整EAP-IKEv2协议运行的情况下，服务器ID被构造并导出为消息5中标识有效负载IDi的标识数据字段的内容。注意，如有效载荷长度字段所示，仅导出“实际”标识数据；如果标识数据字段包含任何填充，则忽略此填充。在“快速重新连接”协议运行的情况下，服务器ID字段以完全相同的方式构造，其中消息5表示最初在EAP对等方和EAP服务器之间建立安全上下文的完整EAP-IKEv2协议运行。
This section specifies how errors are handled within EAP-IKEv2. For conveying error information from one party to the other, the Notify payload is defined and used (see Section 8.11).
本节指定如何在EAP-IKEv2中处理错误。为了将错误信息从一方传送到另一方，定义并使用Notify有效载荷（见第8.11节）。
If, in a full EAP-IKEv2 protocol run, authentication fails (i.e., the verification of the AUTH field fails at the server or the peer), but no other errors have occurred, the message flow deviates from that described in Section 3. The message flows in the presence of authentication failures are specified in Appendix A.
如果在完整的EAP-IKEv2协议运行中，身份验证失败（即，在服务器或对等方验证身份验证字段失败），但没有发生其他错误，则消息流与第3节中描述的消息流不同。附录A中规定了认证失败时的消息流。
If, in message 3 of a full EAP-IKEv2 protocol run (see Figure 1), the responder receives a Diffie-Hellman value (KEi) that belongs to a group that is not supported (and in the absence of other errors), then the responder MUST send a message of the form shown in Figure 3 to the initiator. This effectively becomes message 4 in the full protocol run.
如果在完整EAP-IKEv2协议运行（见图1）的消息3中，响应程序收到一个Diffie-Hellman值（KEi），该值属于不受支持的组（并且在没有其他错误的情况下），则响应程序必须向发起程序发送图3所示形式的消息。这实际上成为完整协议运行中的消息4。
1. R<-I: EAP-Request/Identity
1. R<-I:EAP请求/标识
2. R->I: EAP-Response/Identity(Id)
2. R->I:EAP响应/标识（Id）
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
3. R<-I:EAP需求（HDR、SAi、KEi、Ni）
4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD))
4. R->I:EAP Res（HDR，N（无效负载））
Figure 3: Error Handling in Case of Unsupported D-H Value
图3：D-H值不受支持时的错误处理
The above message consists of the EAP-IKEv2 header and a Notification payload with the value of the Notify Message Type field value set to 17 (INVALID_KE_PAYLOAD). There is a two-octet value associated with this notification: the number of the selected DH Group in big endian order, as specified in Section 3.10.1 of [1]. This number MUST represent a DH group that is supported by both the initiator and the responder.
上述消息由EAP-IKEv2报头和Notify message Type字段值设置为17（无效有效负载）的通知有效负载组成。此通知有一个两个八位组值：所选DH组的大端顺序编号，如[1]第3.10.1节所述。此数字必须表示发起者和响应者都支持的DH组。
If, during a full EAP-IKEv2 protocol run (see Figure 1), the initiator receives a message conforming to Figure 3 instead of the usual message 4, then it MUST check whether or not the indicated DH group was proposed in message 3. If it was not, then the initiator MUST silently discard the message. Otherwise, the protocol continues with a new message 3 that the initiator sends to the peer. In this new message 3, the initiator MUST use a Diffie-Hellman value that is drawn from the group that is indicated in the Notify payload of message 4 in Figure 3.
如果在整个EAP-IKEv2协议运行期间（见图1），启动器收到符合图3的消息，而不是通常的消息4，则必须检查消息3中是否提出了指示的DH组。如果不是，则发起方必须以静默方式放弃该消息。否则，协议将继续使用启动器发送给对等方的新消息3。在这个新消息3中，启动器必须使用一个Diffie-Hellman值，该值来自图3中消息4的Notify有效负载中指示的组。
If, in the context of use case 4 and during a full EAP-IKEv2 protocol run (see Figure 1), the initiator receives, in message 4, an SK{IDr} payload that decrypts to a non-existent or unauthorised EAP-IKEv2 responder identifier IDr*, then the server SHOULD continue the protocol with a message conforming to the format of message 5. The AUTH payload in that message SHOULD contain a value that is computationally indistinguishable from a value that it would contain if IDr* was valid and authorised. This can be accomplished, for example, by generating a random key and calculating AUTH as usual (however, this document does not mandate a specific mechanism). Only after receiving message 6, the server SHOULD respond with an
如果在用例4的上下文中，并且在完整的EAP-IKEv2协议运行期间（参见图1），发起方在消息4中接收到将解密为不存在或未经授权的EAP-IKEv2响应方标识符IDr*的SK{IDr}有效载荷，则服务器应使用符合消息5格式的消息继续协议。该消息中的身份验证有效负载应包含一个在计算上无法与IDr*有效且经过授权时将包含的值区分的值。例如，可以通过生成一个随机密钥并像往常一样计算AUTH来实现这一点（但是，本文档并不要求特定的机制）。只有在接收到消息6后，服务器才应使用
authentication failure notification, i.e., a message conforming to message 6 in Figure 10. The purpose of this behaviour is to prevent an adversary from probing the EAP-IKEv2 peer identifier space.
认证失败通知，即符合图10中消息6的消息。此行为的目的是防止对手探测EAP-IKEv2对等标识符空间。
If, in the context of use cases 1, 2, or 3 and during a full EAP-IKEv2 protocol run (see Figure 1), the initiator receives, in message 4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder identifier IDr*, then the server MUST continue the protocol as usual (note that such a payload would not be required in these use cases). The server MUST compare IDr* with the IDr received in message 6 and, in case of a mismatch, MUST respond with an authentication failure notification, i.e., a message conforming to message 6 in Figure 10. If no mismatch is detected, normal processing applies.
如果在用例1、2或3的上下文中，并且在完整的EAP-IKEv2协议运行期间（参见图1），启动器在消息4中接收到解密为EAP-IKEv2响应器标识符IDr*的SK{IDr}有效负载，则服务器必须像往常一样继续协议（注意，在这些用例中不需要这样的有效负载）。服务器必须将IDr*与消息6中接收到的IDr进行比较，如果不匹配，必须以身份验证失败通知（即，符合图10中消息6的消息）进行响应。如果未检测到不匹配，则应用正常处理。
Other errors do not trigger messages with Notification payloads to be sent, and MUST be treated as if nothing happened (i.e., the erroneous EAP-IKEv2 packet MUST be silently discarded). This includes situations where at least one of the following conditions is met, with respect to an incoming EAP-IKEv2 packet.
其他错误不会触发具有要发送的通知有效负载的消息，并且必须将其视为什么也没有发生（即，必须无声地丢弃错误的EAP-IKEv2数据包）。这包括对于传入EAP-IKEv2分组至少满足以下条件之一的情况。
o The packet contains an Encrypted payload that, when decrypted with the appropriate key, yields an invalid decryption.
o 该数据包包含一个加密的有效负载，当使用适当的密钥解密时，该有效负载将产生无效的解密。
o The packet contains an Encrypted payload with a Checksum field that does not verify with the appropriate key.
o 该数据包包含一个加密的有效负载，其校验和字段未使用适当的密钥进行验证。
o The packet contains an Integrity Checksum Data field (see *Figure 4) that is incorrect.
o 数据包包含不正确的完整性校验和数据字段（参见*图4）。
o The packet does not contain a compulsory field.
o 该数据包不包含强制字段。
o A field in the packet contains an invalid value (e.g., an invalid combination of flags, a length field that is inconsistent with the real length of the field or packet, or the responder's choice of a cryptographic algorithm is different to NONE and any of those that were offered by the initiator).
o 数据包中的字段包含无效值（例如，无效的标志组合，与字段或数据包的实际长度不一致的长度字段，或者响应者对加密算法的选择不同于无和启动器提供的任何值）。
o The packet contains an invalid combination of fields (e.g., it contains two or more Notify payloads with the same Notify Message Type value, or two or more Transform substructures with the same Transform Type and Transform ID value).
o 数据包包含无效的字段组合（例如，它包含两个或多个具有相同Notify消息类型值的Notify有效载荷，或两个或多个具有相同转换类型和转换ID值的转换子结构）。
o The packet causes a defragmentation error.
o 该数据包导致碎片整理错误。
o The format of the packet is invalid.
o 数据包的格式无效。
o The identity provided by the EAP peer in the EAP-Response/Identity cannot be associated with either an established security context (in case of a fast reconnect) or with a real user account (in case of a full protocol exchange). In that case, the packet is silently discarded. With an outstanding message from the EAP server, the client may either retransmit the previous request or, in case of a fast reconnect, assume that state information was deleted (e.g., due to garbage collection) at the EAP server and fall back to a previously used FRID or to the full protocol exchange.
o EAP对等方在EAP响应/标识中提供的标识不能与已建立的安全上下文（在快速重新连接的情况下）或真实用户帐户（在完全协议交换的情况下）相关联。在这种情况下，数据包将被悄悄地丢弃。对于来自EAP服务器的未完成消息，客户端可以重新传输先前的请求，或者在快速重新连接的情况下，假设状态信息在EAP服务器上被删除（例如，由于垃圾收集），并返回到先前使用的FRID或完整的协议交换。
If an incoming packet contains an error for which a behaviour is specified in this section, and an error that, in the absence of the former error, would cause the packet to be silently discarded, then the packet MUST be silently discarded.
如果传入数据包包含本节中指定行为的错误，以及在没有前一个错误的情况下会导致数据包被静默丢弃的错误，则必须静默丢弃该数据包。
In this section, the format of the EAP-IKEv2 data fields and applicable processing rules are specified. Figure 4 shows the general packet format of EAP-IKEv2 messages, and the embedding of EAP-IKEv2 into EAP. The EAP-IKEv2 messages are embedded in the Data field of the standard EAP Request/Response packets. The Code, Identifier, Length, and Type fields are described in [2]. The EAP Type for this EAP method is 49.
本节规定了EAP-IKEv2数据字段的格式和适用的处理规则。图4显示了EAP-IKEv2消息的通用数据包格式，以及EAP-IKEv2在EAP中的嵌入。EAP-IKEv2消息嵌入标准EAP请求/响应数据包的数据字段中。[2]中描述了代码、标识符、长度和类型字段。此EAP方法的EAP类型为49。
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 | Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | HDR + payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Checksum Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | HDR + payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Checksum Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: General Packet Format of EAP-IKEv2
图4:EAP-IKEv2的通用数据包格式
The Flags field is always present and is used for fragmentation support, as described in Section 8.1. The Message Length field is not always present; its presence is determined by a certain flag in the Flags field, as described in Section 8.1. The field denoted as "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see Section 8.2), followed by the number of payloads, in accordance with the composition of EAP-IKEv2 messages, as described in the previous
如第8.1节所述，标志字段始终存在并用于碎片支持。消息长度字段并不总是存在；其存在由标志字段中的某个标志确定，如第8.1节所述。图4中表示为“HDR+有效载荷”的字段包含EAP-IKEv2标头（见第8.2节），后跟有效载荷的数量，符合EAP-IKEv2消息的组成，如前所述
sections. Note that each payload begins with a generic payload header that is specified in Section 3.2 of [1].
部分。请注意，每个有效载荷以[1]第3.2节中规定的通用有效载荷头开始。
The Integrity Checksum Data field is not always present; its presence is determined by a certain flag in the Flags field, as described in Section 8.1.
完整性校验和数据字段并不总是存在；其存在由标志字段中的某个标志确定，如第8.1节所述。
In the remainder of this section, the protocol fields that are used in EAP-IKEv2 are specified. This specification heavily relies on the IKEv2 specification [1], and many fields are constructed, formatted, and processed in way that is almost identical to that in IKEv2. However, certain deviations from standard IKEv2 formatting and processing exist. These deviations are highlighted in the remainder of this section.
在本节的其余部分中，指定了EAP-IKEv2中使用的协议字段。该规范严重依赖于IKEv2规范[1]，许多字段的构造、格式化和处理方式几乎与IKEv2中的相同。但是，存在与标准IKEv2格式和处理的某些偏差。这些偏差在本节剩余部分中突出显示。
This section describes EAP-IKEv2 fragmentation, and specifies the encoding and processing rules for the Flags, Message Length, and Integrity Checksum Data field shown in Figure 4.
本节描述EAP-IKEv2分段，并指定图4所示的标志、消息长度和完整性校验和数据字段的编码和处理规则。
Fragmentation support in EAP-IKEv2 is provided by the Flags and Message Length fields shown in Figure 4. These are encoded and used as follows:
EAP-IKEv2中的碎片支持由图4所示的标志和消息长度字段提供。它们的编码和使用如下所示：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L M I 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L M I 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
L = Length included M = More fragments I = Integrity Checksum Data included
L=包含的长度M=包含的碎片更多I=包含的完整性校验和数据
Figure 5: Flags Field
图5：标志字段
The Flags field is defined in Figure 5. Only the first three bits (0-2) are used; all remaining bits MUST be set to zero and ignored on receipt. The L flag indicates the presence of a Message Length field, and the M flag indicates whether or not the current EAP message has more fragments. In particular, if the L bit is set, then a Message Length field MUST be present in the EAP message, as shown in Figure 4. The Message Length field is four octets long and contains the length of the entire message (i.e., the length of the EAP Data field.). Note that, in contrast, the Length field shown in Figure 4 contains the length of only the current fragment. (Note that there exist two fields that are related to length: the Length
Flags字段在图5中定义。仅使用前三位（0-2）；所有剩余位必须设置为零，并在接收时忽略。L标志表示存在消息长度字段，M标志表示当前EAP消息是否有更多的片段。特别是，如果设置了L位，则EAP消息中必须存在消息长度字段，如图4所示。消息长度字段有四个八位字节长，包含整个消息的长度（即EAP数据字段的长度）。请注意，相比之下，图4所示的长度字段只包含当前片段的长度。（请注意，存在两个与长度相关的字段：长度
field, which is a generic EAP field, and the Message Length field, which is an EAP-IKEv2-specific field.) If the L bit is not set, then the Message Length field MUST NOT be present.
字段（通用EAP字段）和消息长度字段（EAP-IKEv2特定字段。）如果未设置L位，则消息长度字段不得存在。
The M flag MUST be set on all fragments except the last one. In the last fragment, the M flag MUST NOT be set. Reliable fragment delivery is provided by the retransmission mechanism of EAP as described below.
必须在除最后一个片段外的所有片段上设置M标志。在最后一个片段中，不能设置M标志。如下所述，EAP的重传机制提供了可靠的片段传送。
When an EAP-IKEv2 peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-IKEv2 and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
当EAP-IKEv2对等方接收到设置了M位的EAP请求数据包时，它必须以EAP Type=EAP-IKEv2且无数据的EAP响应进行响应。这是一个片段。EAP服务器必须等到收到EAP响应后再发送另一个片段。为了防止处理片段时出错，EAP服务器必须增加EAP请求中包含的每个片段的标识符字段，并且对等方必须在EAP响应中包含的片段确认中包含此标识符值。重新传输的片段将包含相同的标识符值。
Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-IKEv2 and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response.
类似地，当EAP服务器接收到设置了M位的EAP响应时，它必须使用EAP Type=EAP-IKEv2且无数据的EAP请求进行响应。这是一个片段。EAP对等方必须等到收到EAP请求后再发送另一个片段。为了防止片段处理中出现错误，EAP服务器必须增加EAP请求中包含的每个片段ACK的标识符值，并且对等方必须在EAP响应中包含的后续片段中包含该标识符值。
The Integrity Checksum Data field contains a cryptographic checksum that covers the entire EAP message, starting with the Code field, and ending at the end of the EAP Data field. This field, shown in Figure 4, is present only if the I bit is set in the Flags field. The Integrity Checksum Data field immediately follows the EAP Data field without padding.
完整性校验和数据字段包含覆盖整个EAP消息的加密校验和，从代码字段开始，到EAP数据字段结束。如图4所示，只有在Flags字段中设置了I位时，该字段才会出现。完整性校验和数据字段紧跟在EAP数据字段之后，没有填充。
Whenever possible, the Integrity Checksum Data field MUST be present (and the I bit set) for each fragment, including the case where the entire EAP-IKEv2 message is carried in a single fragment. The algorithm and keys that are used to compute the Integrity Checksum Data field MUST be identical to those used to compute the Integrity Checksum Data field of the Encrypted Payload (see Section 8.9). That is, the algorithm and keys that were negotiated and established during this EAP-IKEv2 protocol run are used. Note that this means that different keys are used to compute the Integrity Checksum Data field in each direction. Also note that, for messages where this
只要可能，每个片段都必须存在完整性校验和数据字段（以及I位集），包括整个EAP-IKEv2消息在单个片段中传输的情况。用于计算完整性校验和数据字段的算法和密钥必须与用于计算加密有效负载的完整性校验和数据字段的算法和密钥相同（参见第8.9节）。也就是说，使用在EAP-IKEv2协议运行期间协商和建立的算法和密钥。请注意，这意味着在每个方向上使用不同的键来计算完整性校验和数据字段。还请注意，对于
algorithm and the keys are not yet established, the Integrity Checksum Data field cannot be computed and is therefore not included. This applies, for example, to messages 3 and 4 in Figure 1.
算法和密钥尚未建立，完整性校验和数据字段无法计算，因此不包括在内。例如，这适用于图1中的消息3和4。
In order to minimize the exposure to denial-of-service attacks on fragmented packets, messages that are not protected with an Integrity Checksum Data field SHOULD NOT be fragmented. Note, however, that those packets are not likely to be fragmented anyway since they do not carry certificates.
为了最大限度地减少碎片数据包遭受拒绝服务攻击的风险，不应碎片化未使用完整性校验和数据字段保护的消息。但是，请注意，这些数据包无论如何都不可能被分割，因为它们不携带证书。
The EAP-IKEv2 header, denoted HDR in this specification, is constructed and formatted according to the rules specified in Section 3.1 of [1].
本规范中表示为HDR的EAP-IKEv2标头根据[1]第3.1节规定的规则构造和格式化。
In the first EAP-IKEv2 message that is sent by the initiator (message 3 in Figure 1), the IKE_SA Responder's SPI field is set to zero. This is because, at this point in time, the initiator does not know what SPI value the responder will choose for this protocol run. In all other messages, both SPI fields MUST contain non-zero values that reflect the initiator- and responder-chosen SPI values.
在启动器发送的第一条EAP-IKEv2消息（图1中的消息3）中，IKE_SA响应者的SPI字段设置为零。这是因为，此时，发起方不知道响应方将为此协议运行选择什么SPI值。在所有其他消息中，两个SPI字段都必须包含非零值，以反映启动器和响应程序选择的SPI值。
In accordance with [1], for this version of EAP-IKEv2, the MjVer (major version) and MnVer (minor version) fields in the header MUST be 2 and 0 respectively. The value of the Exchange Type field MUST be set to 34 (IKE_SA_INIT) in messages 3 and 4, and to 35 (IKE_SA_AUTH) in messages 5 and 6 in Figure 1. In messages 3 and 4 in Figure 2, this value MUST be set to 36 (CREATE_CHILD_SA).
根据[1]，对于此版本的EAP-IKEv2，标头中的MjVer（主要版本）和MnVer（次要版本）字段必须分别为2和0。交换类型字段的值在消息3和4中必须设置为34（IKE_SA_INIT），在图1中的消息5和6中必须设置为35（IKE_SA_AUTH）。在图2中的消息3和4中，该值必须设置为36（CREATE_CHILD_SA）。
The Flags field of the EAP-IKEv2 header is also constructed according to Section 3.1 of [1]. Note that this is not the same field as the Flags field shown in Figure 4.
EAP-IKEv2报头的标志字段也根据[1]的第3.1节构造。注意，这与图4所示的Flags字段不同。
The Message ID field is constructed as follows. Messages 3 and 4 in a full protocol run MUST carry Message ID value 0. Messages 5 and 6 in a full protocol run (see Figure 1) MUST carry Message ID value 1. Messages 3 and 4 in a fast reconnect protocol run MUST carry Message ID value 2.
消息ID字段的构造如下所示。完整协议运行中的消息3和消息4必须带有消息ID值0。完整协议运行中的消息5和6（见图1）必须带有消息ID值1。快速重新连接协议运行中的消息3和4必须带有消息ID值2。
The SA payload is used for the negotiation of cryptographic algorithms between the initiator and the responder. The rules for its construction adhere to [1]; in particular, Sections 2.7 and 3.3.
SA有效负载用于发起方和响应方之间的密码算法协商。其构造规则遵循[1]；特别是第2.7节和第3.3节。
In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry Protocol ID value 1 (IKE).
在EAP-IKEv2中，SA有效载荷中的所有提案子结构必须携带协议ID值1（IKE）。
The Key Exchange payload, denoted KEi if constructed by the initiator and KEr if constructed by the responder, is formatted according to the rules specified in Section 3.4 of [1].
密钥交换有效载荷，如果由发起方构造，则表示为KEi，如果由响应方构造，则表示为KEr，根据[1]第3.4节中规定的规则进行格式化。
The Nonce payload, denoted Ni if constructed by the initiator and Nr if constructed by the responder, is constructed and formatted according to the rules specified in Section 3.9 of [1].
根据[1]第3.9节规定的规则构造和格式化非有效载荷，如果由发起方构造，则表示为Ni，如果由响应方构造，则表示为Nr。
The Identification payload, denoted IDi if it contains an identifier for the initiator and IDr if it contains an identifier for the responder, is constructed and formatted according to the rules specified in Section 3.5 of [1].
根据[1]第3.5节中规定的规则构造和格式化标识有效载荷（如果标识有效载荷包含启动器标识符，则表示为IDi；如果标识有效载荷包含响应者标识符，则表示为IDr）。
The Certificate payload, denoted CERT, is constructed and formatted according to the rules specified in Section 3.6 of [1]. Note that certain certificate encodings for the EAP server certificate, e.g., those that need to be resolved via another network protocol, cannot be used in some typical EAP-IKEv2 deployment scenarios. A user, for example, that authenticates himself by means of EAP-IKEv2 in order to obtain network access, cannot resolve the server certificate at the time of EAP-IKEv2 protocol execution.
证书有效载荷（表示为CERT）是根据[1]第3.6节规定的规则构造和格式化的。请注意，EAP服务器证书的某些证书编码，例如，需要通过另一个网络协议解析的证书编码，不能在某些典型的EAP-IKEv2部署场景中使用。例如，通过EAP-IKEv2对自己进行身份验证以获得网络访问的用户在执行EAP-IKEv2协议时无法解析服务器证书。
The Certificate Request payload, denoted CERTREQ, is constructed and formatted according to the rules specified in Section 3.7 of [1].
证书请求有效负载表示为CERTREQ，根据[1]第3.7节中规定的规则构造和格式化。
The Encrypted payload, denoted SK{...}, is constructed and formatted according to the rules specified in Section 3.14 of [1].
根据[1]第3.14节中规定的规则构造并格式化了表示为SK{…}的加密有效负载。
The Authentication payload, denoted AUTH, is constructed and formatted according to the rules specified in Sections 2.15 and 3.8 of [1].
根据[1]第2.15节和第3.8节中规定的规则构造和格式化认证有效负载（表示为AUTH）。
The contents of the Authentication payload depend on which party generates this field, the use case, and the algorithm that
身份验证有效负载的内容取决于生成该字段的第三方、用例和生成该字段的算法
corresponds to the credential (asymmetric key, symmetric key, or password) that this party uses to authenticate itself. The Authentication payload contains either a MAC or a signature.
对应于该方用于自身身份验证的凭据（非对称密钥、对称密钥或密码）。身份验证有效负载包含MAC或签名。
If the party that generates the Authentication payload authenticates itself based on a shared secret (i.e., a password or a symmetric key), then the Authentication payload MUST contain a MAC. This MAC is calculated using a key that is derived from the shared secret, according to Section 2.15 of [1]. According to that section, the shared secret is padded with the string "Key Pad for IKEv2" as part of this key derivation. For the EAP-IKEv2 method, this rule is overridden, in that the padding string is redefined as "Key Pad for EAP-IKEv2". The latter padding string MUST be used for the derivation of the MAC key from a shared secret in the context of EAP-IKEv2. This is done in order to avoid the same MAC key to be used for both IKEv2 and EAP-IKEv2 in scenarios where the same shared secret is used for both. Note that using a shared secret (e.g., a password) in the context EAP-IKEv2 that is identical or similar to a shared secret that is used in another context (including IKEv2) is nevertheless NOT RECOMMENDED.
如果生成认证有效载荷的一方基于共享秘密（即密码或对称密钥）对其自身进行认证，则认证有效载荷必须包含MAC。根据[1]第2.15节的规定，该MAC使用从共享秘密派生的密钥进行计算。根据该部分，共享秘密被填充为字符串“KeyPadforIKEv2”，作为密钥派生的一部分。对于EAP-IKEv2方法，此规则被覆盖，因为填充字符串被重新定义为“EAP-IKEv2的键盘”。后一个填充字符串必须用于从EAP-IKEv2上下文中的共享密钥派生MAC密钥。这样做是为了避免在IKEv2和EAP-IKEv2使用相同共享密钥的场景中使用相同的MAC密钥。注意，尽管如此，不建议在上下文EAP-IKEv2中使用与另一上下文（包括IKEv2）中使用的共享秘密相同或相似的共享秘密（例如密码）。
The Notify payload, denoted N(...), is constructed and formatted according to the rules specified in Section 3.10 of [1]. The Protocol ID field of this payload MUST be set to 1 (IKE_SA).
Notify有效载荷，表示为N（…），根据[1]第3.10节中规定的规则构造和格式化。此有效负载的协议ID字段必须设置为1（IKE_SA）。
The Next Fast-ID Payload is defined as follows:
下一个Fast ID有效负载定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Fast-Reconnect-ID (FRID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Fast-Reconnect-ID (FRID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NFID Payload Format
图6:NFID有效负载格式
The Next Fast-ID payload, denoted NFID, does not have an equivalent in IKEv2. Nevertheless, the Next Payload, C, RESERVED, and Payload Length fields of this payload are constructed according to Section 3.2 of [1]. The payload ID is registered in Section 11. The Fast-Reconnect-ID field contains a fast reconnect identifier that the peer
下一个Fast ID有效负载，表示为NFID，在IKEv2中没有等价物。然而，该有效载荷的下一个有效载荷C、保留和有效载荷长度字段是根据[1]的第3.2节构造的。有效载荷ID在第11节中注册。Fast Reconnect ID字段包含一个快速重新连接标识符，对等方可以使用该标识符
can use in the next fast reconnect protocol run, as described in Section 4. In environments where a realm portion is required, Fast-Reconnect-ID includes both a username portion and a realm name portion. The Fast-Reconnect-ID MUST NOT include any terminating null characters. The encoding of the Fast-Reconnect-ID field MUST follow the NAI format [4].
可以在下一次快速重新连接协议运行中使用，如第4节所述。在需要领域部分的环境中，快速重新连接ID包括用户名部分和领域名称部分。快速重新连接ID不得包含任何终止的空字符。快速重新连接ID字段的编码必须遵循NAI格式[4]。
In EAP-IKEv2, each payload is identified by means of a type field, which, as specified in [1], is indicated in the "Next Payload" field of the preceding payload. However, the identifier space from which EAP-IKEv2 payload types are drawn is independent from the payload type space of IKEv2. This is because EAP-IKEv2 and IKEv2 may evolve in a different way and, as such, payload types that appear in one protocol do not necessary appear in the other. An example of this is the "Next Fast-ID" (NFID) payload, which does not exist in IKEv2.
在EAP-IKEv2中，通过类型字段标识每个有效载荷，如[1]中所述，该字段在前一有效载荷的“下一有效载荷”字段中指示。然而，从中绘制EAP-IKEv2有效负载类型的标识符空间独立于IKEv2的有效负载类型空间。这是因为EAP-IKEv2和IKEv2可能以不同的方式发展，因此，出现在一个协议中的有效负载类型不一定出现在另一个协议中。这方面的一个例子是“下一个快速ID”（NFID）有效负载，它在IKEv2中不存在。
The values for the payload types defined in this document are listed in Section 11. Payload type values 13-127 are reserved to IANA for future assignment in EAP-IKEv2. Payload type values 128-255 are for private use among mutually consenting parties.
第11节列出了本文件中定义的有效载荷类型的值。有效载荷类型值13-127保留给IANA，以备将来在EAP-IKEv2中分配。有效负载类型值128-255供双方同意的各方私人使用。
As mentioned in Section 3, in EAP-IKEv2, the EAP server always assumes the role of the initiator (I), and the EAP peer takes on the role of the responder (R) of an exchange. This is in order to ensure that, in scenarios where the peer authenticates itself based on a password (i.e., in use case 3), operations that involve this password only take place after the server has been successfully authenticated. In other words, this assignment of initiator and responder roles results in protection against offline dictionary attacks on the password that is used by the peer to authenticate itself (see Section 10.7).
如第3节所述，在EAP-IKEv2中，EAP服务器始终承担发起方（I）的角色，EAP对等方承担交换的响应方（R）的角色。这是为了确保，在对等方基于密码对自身进行身份验证的场景中（即，在用例3中），涉及该密码的操作仅在服务器成功进行身份验证后发生。换句话说，这种启动器和响应程序角色的分配可以防止对对等方用于自身身份验证的密码的脱机字典攻击（参见第10.7节）。
In order for two EAP-IKEv2 implementations to be interoperable, they must support at least one common set of cryptographic algorithms. In order to promote interoperability, EAP-IKEv2 implementations MUST support the following algorithms based on the "MUST/MUST-" recommendations given in [5]:
为了使两个EAP-IKEv2实现能够互操作，它们必须至少支持一组通用的加密算法。为了促进互操作性，EAP-IKEv2实施必须基于[5]中给出的“必须/必须-”建议支持以下算法：
Diffie-Hellman Groups: 1024 MODP Group IKEv2 Transform Type 1 Algorithms: ENCR_3DES IKEv2 Transform Type 2 Algorithms: PRF_HMAC_SHA1 IKEv2 Transform Type 3 Algorithms: AUTH_HMAC_SHA1_96
Diffie-Hellman组：1024个MODP组IKEv2变换类型1算法：ENCR_3DES IKEv2变换类型2算法：PRF_HMAC_SHA1 IKEv2变换类型3算法：AUTH_HMAC_SHA1_96
All other options of [5] MAY be implemented.
[5]的所有其他选项均可实施。
The remainder of this section describes EAP-IKEv2 in terms of specific security terminology as required by [2]. The discussion makes reference to the use cases defined in Section 1.
本节剩余部分根据[2]要求的特定安全术语描述了EAP-IKEv2。讨论参考了第1节中定义的用例。
In message 3, the EAP server provides the set of ciphersuites it is willing to accept in an EAP-IKEv2 protocol run. Hence, the server is in control of the ciphersuite. An EAP peer that does not support any of the indicated ciphersuites is not able to authenticate. The local security policy of the peer MUST specify the set of ciphersuites that the peer accepts. The server MUST verify that the ciphersuite that is indicated as being chosen by the peer in message 4, belongs to the set of ciphersuites that were offered in message 3. If this verification fails, the server MUST silently discard the packet.
在消息3中，EAP服务器提供它愿意在EAP-IKEv2协议运行中接受的一组密码套件。因此，服务器控制着密码套件。不支持任何指定密码套件的EAP对等方无法进行身份验证。对等方的本地安全策略必须指定对等方接受的密码套件集。服务器必须验证消息4中指示由对等方选择的密码套件是否属于消息3中提供的密码套件集。如果验证失败，服务器必须自动丢弃数据包。
EAP-IKEv2 supports mutual authentication.
EAP-IKEv2支持相互认证。
EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This protection is offered after authentication is completed and it is facilitated by inclusion of two Integrity Checksum Data fields: one at the end of the EAP packet (see Figure 4), and one as part of an Encrypted payload (see Section 8.9).
EAP-IKEv2提供EAP-IKEv2通信的完整性保护。这种保护在认证完成后提供，并通过包含两个完整性校验和数据字段来实现：一个位于EAP数据包的末尾（参见图4），另一个作为加密有效负载的一部分（参见第8.9节）。
EAP-IKEv2 provides protection against replay attacks by a variety of means. This includes the requirement that the Authentication payload is computed as a function of, among other things, a server-provided nonce and a peer-provided nonce. These nonces are required to be practically unpredictable by an adversary. Assuming that the algorithm that is used to compute the Authentication payload does not contain cryptographic weaknesses, the probability that an Authentication payload that is valid in a particular protocol run will also be valid in a subsequent run is therefore negligible.
EAP-IKEv2通过多种方式提供针对重播攻击的保护。这包括认证有效负载作为服务器提供的nonce和对等方提供的nonce的函数计算的要求。对手要求这些临时状态实际上是不可预测的。假设用于计算认证有效负载的算法不包含密码弱点，因此，在特定协议运行中有效的认证有效负载在后续运行中也将有效的概率可以忽略不计。
EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields, namely those included in Encrypted payloads. With respect to identity confidentiality, the following claims are made. Note that identity confidentiality refers to the EAP-IKEv2 identity of the EAP peer.
EAP-IKEv2为某些EAP-IKEv2字段提供机密性，即加密有效载荷中包含的字段。关于身份保密性，提出以下要求。注意，身份保密性指的是EAP对等方的EAP-IKEv2身份。
Identity confidentiality is provided in the face of a passive adversary, i.e., an adversary that does not modify traffic as it is in transit. Whenever the optional SK{IDr} payload in message 4 of a full EAP-IKEv2 protocol (see Figure 1) is not included, identity confidentiality is also provided in the face of an active adversary. This payload MUST NOT be included in use cases 1, 2, and 3. In use case 4, this payload MUST be included. Therefore, in use case 4, EAP- IKEv2 does not provide identity confidentiality in the face of an active adversary.
在被动对手面前提供身份保密性，即在传输过程中不修改流量的对手。当完整EAP-IKEv2协议（见图1）的消息4中的可选SK{IDr}有效载荷未包含时，也会在主动对手面前提供身份保密性。该有效载荷不得包含在用例1、2和3中。在用例4中，必须包括该有效载荷。因此，在用例4中，EAP-IKEv2在主动对手面前不提供身份保密性。
Note, however, that the EAP peer provides its identity in message 2 in Figure 1 in cleartext. In order to provide identity confidentiality as discussed in the previous paragraphs, it is necessary to obfuscate the username part of the identity (the realm part must stay intact to allow correct message routing by the Authentication, Authorization, and Accounting (AAA) infrastructure). The EAP server then uses the identity information in message 4. The same mechanism is also used by other EAP methods to provide identity confidentiality, for example, EAP-TTLS [8].
然而，请注意，EAP对等方在图1的消息2中以明文形式提供其标识。为了提供前面段落中讨论的身份机密性，有必要混淆身份的用户名部分（领域部分必须保持完整，以允许通过身份验证、授权和记帐（AAA）基础设施进行正确的消息路由）。EAP服务器然后使用消息4中的标识信息。其他EAP方法也使用相同的机制来提供身份保密性，例如EAP-TTLS[8]。
EAP-IKEv2 supports the establishment of session keys (MSK and EMSK) of a variety of key strengths, with the theoretical maximum at 512 bits per key (since this is the size of the MSK and the EMSK). However, in practice, the effective key strength is likely to be significantly lower, and depends on the authentication credentials used, the negotiated ciphersuite (including the output size of the pseudorandom function), the Diffie-Hellman group used, and on the extent to which the assumptions on which the underlying cryptographic algorithms depend really hold. Of the above mechanisms, the one that offers the lowest key strength can be regarded as a measure of the effective key strength of the resulting session keys. Note that this holds for other EAP methods, too.
EAP-IKEv2支持建立各种密钥强度的会话密钥（MSK和EMSK），理论最大值为每个密钥512位（因为这是MSK和EMSK的大小）。然而，在实践中，有效密钥强度可能会显著降低，并且取决于所使用的身份验证凭据、协商密码套件（包括伪随机函数的输出大小）、所使用的Diffie-Hellman组、，以及基础密码算法所依赖的假设在多大程度上真正成立。在上述机制中，提供最低密钥强度的机制可以被视为对结果会话密钥的有效密钥强度的度量。请注意，这也适用于其他EAP方法。
Due to the large variety of possible combinations, no indication of a practical effective key strength for MSK or EMSK is given here. However, those responsible for the deployment of EAP-IKEv2 in a particular environment should consider the threats this environment may be exposed to, and configure the EAP-IKEv2 server and peer policies and authentication credentials such that the established session keys are of a sufficiently high effective key strength.
由于可能的组合种类繁多，此处未给出MSK或EMSK实际有效密钥强度的指示。然而，负责在特定环境中部署EAP-IKEv2的人应考虑该环境可能暴露的威胁，并配置EAP-IKEv2服务器和对等策略和认证凭证，使得所建立的会话密钥具有足够高的有效密钥强度。
EAP-IKEv2 can be used in a variety of use cases, as explained in Section 1. In some of these uses cases, namely use case 1, 2, and 4, dictionary attacks cannot be launched since no passwords are used.
EAP-IKEv2可用于各种用例，如第1节所述。在其中一些用例中，即用例1、2和4，由于未使用密码，无法启动字典攻击。
In use case 3, EAP-IKEv2 provides protection against offline dictionary attacks, since operations that involve the password are executed only after the server has authenticated itself (based on a credential other than a password).
在用例3中，EAP-IKEv2提供了针对离线字典攻击的保护，因为涉及密码的操作只有在服务器进行了自身身份验证（基于除密码之外的凭证）后才能执行。
In order to reduce exposure against online dictionary attacks, in use case 3, the server SHOULD provide the capability to log failed peer authentication events, and SHOULD implement a suitable policy in case of consecutive failed peer authentication attempts within a short period of time (such as responding with an EAP-Failure instead of message 5 for a predetermined amount of time).
为了减少对在线字典攻击的暴露，在用例3中，服务器应该提供记录失败的对等身份验证事件的能力，并且应该在短时间内连续失败的对等身份验证尝试的情况下实施适当的策略（例如，在预定的时间内，用EAP故障而不是消息5进行响应）。
When passwords are used with method 4 (instead of using a key with high entropy), dictionary attacks are possible, as described in Section 8 of [1]:
当密码与方法4一起使用时（而不是使用高熵的密钥），字典攻击是可能的，如[1]第8节所述：
"When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social engineering attacks, among others."
“在使用预共享密钥时，一个关键的考虑因素是如何确保这些秘密的随机性。最重要的做法是确保任何预共享密钥包含的随机性与正在协商的最强密钥一样多。从密码、名称或其他低熵源派生共享密钥是不安全的。这些源受到字典和社会工程攻击等。”
Hence, the usage of passwords with mode 4 where the EAP peer and the EAP server rely on a shared secret that was derived from a password is insecure. It is strongly recommended to use mode 3 when passwords are used by the EAP peer.
因此，在模式4中使用密码时，EAP对等方和EAP服务器依赖于从密码派生的共享秘密是不安全的。当EAP对等方使用密码时，强烈建议使用模式3。
EAP-IKEv2 supports a "fast reconnect" mode of operation, as described in Section 4.
EAP-IKEv2支持“快速重新连接”操作模式，如第4节所述。
EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding does not apply to EAP-IKEv2.
EAP-IKEv2不是隧道EAP方法。因此，加密绑定不适用于EAP-IKEv2。
EAP-IKEv2 provides session independence in a number of ways, as follows:
EAP-IKEv2以多种方式提供会话独立性，如下所示：
Firstly, knowledge of captured EAP-IKEv2 conversations (i.e., the information that a passive adversary may obtain) does not enable the adversary to compute the Master Session Key (MSK) and Extended Master Session Key (EMSK) that resulted from these conversations. This
首先，对捕获的EAP-IKEv2会话（即被动对手可能获得的信息）的了解不能使对手计算由这些会话产生的主会话密钥（MSK）和扩展主会话密钥（EMSK）。这
holds even in the case where the adversary later obtains access to the server and/or the peer's long-term authentication credentials that were used in these conversations. That is, EAP-IKEv2 provides support for "perfect forward secrecy". However, whether or not this support is made use of in a particular EAP-IKEv2 protocol run, depends on when the peer and the server delete the Diffie-Hellman values that they used in that run, and on whether or not they use fresh Diffie-Hellman values in each protocol run. The discussion in Section 2.12 of [1] applies.
即使在敌方稍后获得对服务器和/或对等方在这些对话中使用的长期身份验证凭据的访问权限的情况下也保持有效。也就是说，EAP-IKEv2提供了对“完美前向保密”的支持。但是，是否在特定EAP-IKEv2协议运行中使用此支持取决于对等方和服务器何时删除在该运行中使用的Diffie-Hellman值，以及它们是否在每个协议运行中使用新的Diffie-Hellman值。[1]第2.12节中的讨论适用。
Secondly, an active adversary that does not know the peer's and server's long-term authentication credentials cannot learn the MSK and EMSK that were established in a particular protocol run of EAP-IKEv2, even if it obtains access to the MSK and EMSK that were established in other protocol runs of EAP-IKEv2. This is because the MSK and the EMSK are a function of, among other things, data items that are assumed to be generated independently at random in each protocol run.
其次，不知道对等方和服务器的长期身份验证凭据的主动对手无法了解在EAP-IKEv2的特定协议运行中建立的MSK和EMSK，即使其获得对在EAP-IKEv2的其他协议运行中建立的MSK和EMSK的访问。这是因为MSK和EMSK是假定在每个协议运行中随机独立生成的数据项的函数。
EAP-IKEv2 provides support for fragmentation, as described in Section 8.1.
EAP-IKEv2提供了对碎片化的支持，如第8.1节所述。
Channel binding is not supported in EAP-IKEv2.
EAP-IKEv2中不支持通道绑定。
EAP security claims are defined in Section 7.2.1 of [2]. The security claims for EAP-IKEv2 are as follows:
EAP担保索赔的定义见[2]第7.2.1节。EAP-IKEv2的担保要求如下：
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes; see Section 5
Key strength: Variable
Dictionary attack prot.: Yes; see Section 10.7
Fast reconnect: Yes; see Section 4
Crypt. binding: N/A
Session independence: Yes; see Section 10.10
Fragmentation: Yes; see Section 10.11
Channel binding: No
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes; see Section 5
Key strength: Variable
Dictionary attack prot.: Yes; see Section 10.7
Fast reconnect: Yes; see Section 4
Crypt. binding: N/A
Session independence: Yes; see Section 10.10
Fragmentation: Yes; see Section 10.11
Channel binding: No
IANA has allocated value 49 for the EAP method type indicating EAP-IKEv2. EAP-IKEv2 has already earlier successfully passed Designated Expert Review as mandated by RFC 3748 for IANA allocations.
IANA已为指示EAP-IKEv2的EAP方法类型分配了值49。EAP-IKEv2早些时候已经成功通过了RFC 3748关于IANA分配的指定专家评审。
In addition, IANA has created a new registry for "EAP-IKEv2 Payloads", and populated it with the following initial entries listed below.
此外，IANA还为“EAP-IKEv2有效载荷”创建了一个新的注册表，并使用下列初始条目填充该注册表。
The following payload type values are used by this document.
本文档使用以下有效负载类型值。
Next Payload Type | Value
----------------------------------+----------------------------------
No Next payload | 0
Security Association payload | 33
Key Exchange payload | 34
Identification payload |
(when sent by initiator, IDi) | 35
Identification payload |
(when sent by responder, IDr) | 36
Certificate payload | 37
Certificate Request payload | 38
Authentication payload | 39
Nonce payload | 40
Notification payload | 41
Vendor ID payload | 43
Encrypted payload | 46
Next Fast-ID payload | 121
RESERVED TO IANA | 1-32, 42, 44-45, 47-120, 122-127
PRIVATE USE | 128-255
Next Payload Type | Value
----------------------------------+----------------------------------
No Next payload | 0
Security Association payload | 33
Key Exchange payload | 34
Identification payload |
(when sent by initiator, IDi) | 35
Identification payload |
(when sent by responder, IDr) | 36
Certificate payload | 37
Certificate Request payload | 38
Authentication payload | 39
Nonce payload | 40
Notification payload | 41
Vendor ID payload | 43
Encrypted payload | 46
Next Fast-ID payload | 121
RESERVED TO IANA | 1-32, 42, 44-45, 47-120, 122-127
PRIVATE USE | 128-255
Payload type values 1-120 match the corresponding payloads in the IKEv2 IANA registry. That is, the EAP-IKEv2 payloads that have been assigned a type value in the range 1-120 have a semantically equivalent payload type in IKEv2, with an identical payload type value. However, there exist payloads types in IKEv2 that do not have a semantically equivalent payload in EAP-IKEv2; this explains the fact that the payload type values 42, 44, and 45 have not been assigned in EAP-IKEv2; these values remain RESERVED TO IANA for this version of EAP-IKEv2.
有效负载类型值1-120与IKEv2 IANA注册表中的相应有效负载匹配。也就是说，分配了1-120范围内的类型值的EAP-IKEv2有效负载在IKEv2中具有语义等效的有效负载类型，具有相同的有效负载类型值。然而，IKEv2中存在的有效负载类型在EAP-IKEv2中没有语义等效的有效负载；这解释了EAP-IKEv2中未分配有效负载类型值42、44和45的事实；对于此版本的EAP-IKEv2，这些值保留给IANA。
Payload type values 121-127 are used for EAP-IKEv2 specific payloads, i.e., for payloads that do not have a semantically equivalent payload in IKEv2. Note that this range has been reserved for this purpose in the IKEv2 IANA registry too. This means that the same payload type values will not be used for different things in IKEv2 and EAP-IKEv2 protocols.
有效载荷类型值121-127用于EAP-IKEv2特定的有效载荷，即用于IKEv2中没有语义等效有效载荷的有效载荷。请注意，IKEv2 IANA注册表中也为此保留了此范围。这意味着相同的有效负载类型值不会用于IKEv2和EAP-IKEv2协议中的不同内容。
Payload type values 122-127 are reserved to IANA for future assignment to EAP-IKEv2-specific payloads. Payload type values 128-255 are for private use among mutually consenting parties.
有效载荷类型值122-127保留给IANA，以便将来分配给EAP-IKEv2特定的有效载荷。有效负载类型值128-255供双方同意的各方私人使用。
The semantics of the above-listed payloads is provided in this document (0-127) and refer to IKEv2 when necessary (1-120).
本文件（0-127）提供了上述有效载荷的语义，必要时参考IKEv2（1-120）。
New payload type values with a description of their semantic will be assigned after Expert Review. The expert is chosen by the IESG in consultation with the Security Area Directors and the EMU working group chairs (or the working group chairs of a designated successor working group). Updates can be provided based on expert approval only. A designated expert will be appointed by the Security Area Directors. Based on expert approval it is possible to delete entries from the registry or to mark entries as "deprecated".
新的有效负载类型值及其语义描述将在专家审查后分配。专家由IESG与安全区域主管和EMU工作组主席（或指定继任工作组的工作组主席）协商后选择。只能在专家批准的基础上提供更新。安全区域主管将任命一名指定专家。根据专家的批准，可以从注册表中删除条目或将条目标记为“已弃用”。
Each registration must include the payload type value and the semantic of the payload.
每个注册必须包括有效负载类型值和有效负载的语义。
The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr Marnik, and Pawel Matejski, who, during their implementation of EAP-IKEv2 (see http://eap-ikev2.sourceforge.net/), provided invaluable feedback and identified a number of errors in previous versions of this document.
作者感谢Krzysztof Rzecki、Rafal Mijal、Piotr Marnik和Pawel Matejski，他们在EAP-IKEv2的实施过程中（参见http://eap-ikev2.sourceforge.net/)，提供了宝贵的反馈，并发现了本文件以前版本中的一些错误。
The authors also thank Pasi Eronen for his invaluable comments as expert reviewer assigned by the EAP working group chairs Jari Arkko and Bernard Aboba. The authors would also like to thank Guenther Horn, Thomas Otto, Paulo Pagliusi, and John Vollbrecht for their insightful comments and suggestions. The members of the PANA design team; in particular, D. Forsberg and A. Yegin, also provided comments on the initial version of this document. We would like to thank Hugo Krawczyk for his feedback regarding the usage of the password-based authentication.
作者还感谢Pasi Eronen作为EAP工作组主席Jari Arkko和Bernard Aboba指派的专家评审员所作的宝贵评论。作者还想感谢根瑟·霍恩、托马斯·奥托、保罗·帕柳西和约翰·沃尔布雷希特的富有洞察力的评论和建议。PANA设计团队成员；特别是，D.Forsberg和A.Yegin也对本文件的初始版本提出了意见。我们要感谢Hugo Krawczyk就基于密码的身份验证的使用提供的反馈。
The authors are grateful to the members of the EAP keying design team for their discussion in the area of the EAP Key Management Framework.
作者感谢EAP密钥设计团队成员在EAP密钥管理框架领域的讨论。
We would like to thank Jari Arkko for his support and for his comments. Finally, we would like to thank Charlie Kaufman, Bernard Aboba, and Paul Hoffman for their comments during IETF Last Call.
我们要感谢Jari Arkko的支持和评论。最后，我们要感谢Charlie Kaufman、Bernard Aboba和Paul Hoffman在IETF最后一次通话中的评论。
[1] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[1] Kaufman，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[2] Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[4] Aboba，B.，Beadles，M.，Arkko，J.，和P.Eronen，“网络接入标识符”，RFC 42822005年12月。
[5] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[5] Schiller，J.，“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[6] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[6] Aboba，B.和D.Simon，“PPP EAP TLS认证协议”，RFC 2716，1999年10月。
[7] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, February 2007.
[7] Aboba，B.，“可扩展认证协议（EAP）密钥管理框架”，正在进行的工作，2007年2月。
[8] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol (EAP-TTLS)", Work in Progress, July 2004.
[8] Funk，P.和S.Blake Wilson，“EAP隧道TLS认证协议（EAP-TTLS）”，正在进行的工作，2004年7月。
This appendix illustrates how authentication failures are handled within EAP-IKEv2. Note that authentication failures only occur in full EAP-IKEv2 protocol runs.
本附录说明了如何在EAP-IKEv2中处理身份验证失败。请注意，身份验证失败仅发生在完整的EAP-IKEv2协议运行中。
Figure 10 shows the message flow in case the EAP peer fails to authenticate the EAP server.
图10显示了EAP对等方未能对EAP服务器进行身份验证时的消息流。
1. R<-I: EAP-Request/Identity
1. R<-I:EAP请求/标识
2. R->I: EAP-Response/Identity(Id)
2. R->I:EAP响应/标识（Id）
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
3. R<-I:EAP需求（HDR、SAi1、KEi、Ni）
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
4. R->I:EAP Res（HDR、SAr1、KEr、Nr、[CERTREQ]、[SK{IDr}]）
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH})
5. R<-I:EAP-Req（HDR，SK{IDi，[CERT]，[CERTREQ]，[IDr]，AUTH}）
6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)})
6. R->I:EAP Res（HDR，SK{N（身份验证失败）}）
7. R<-I: EAP-Failure
7. R<-I:EAP故障
Figure 10: EAP-IKEv2 with Failed Server Authentication
图10：服务器身份验证失败的EAP-IKEv2
The difference in the full successful exchange described in Section 3 is that, in message 6, the EAP peer MUST answer the EAP server with an Encrypted payload that contains a Notify payload with the Notify Message Type value set to 24 (AUTHENTICATION_FAILED). In that message, the Message ID field in the EAP-IKEv2 header (HDR) MUST carry Message ID value 2. In message 7, an EAP-Failure message MUST be returned by the EAP server.
第3节中描述的完全成功交换的区别在于，在消息6中，EAP对等方必须使用加密的有效负载应答EAP服务器，该有效负载包含一个Notify有效负载，Notify消息类型值设置为24（身份验证失败）。在该消息中，EAP-IKEv2报头（HDR）中的消息ID字段必须包含消息ID值2。在消息7中，EAP服务器必须返回EAP失败消息。
Figure 11 shows the message flow in case the EAP server fails to authenticate the EAP peer.
图11显示了EAP服务器无法对EAP对等方进行身份验证时的消息流。
1. R<-I: EAP-Request/Identity
1. R<-I:EAP请求/标识
2. R->I: EAP-Response/Identity(Id)
2. R->I:EAP响应/标识（Id）
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
3. R<-I:EAP需求（HDR、SAi1、KEi、Ni）
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
4. R->I:EAP Res（HDR、SAr1、KEr、Nr、[CERTREQ]、[SK{IDr}]）
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH})
5. R<-I:EAP-Req（HDR，SK{IDi，[CERT]，[CERTREQ]，AUTH}）
6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH})
6. R->I:EAP Res（HDR，SK{IDr，[CERT]，AUTH}）
7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})
7. R<-I:EAP-Req（HDR，SK{N（身份验证失败）}）
8. R->I: EAP-Res (HDR, SK {})
8. R->I:EAP Res（HDR，SK{}）
9. R<-I: EAP-Failure
9. R<-I:EAP故障
Figure 11: EAP-IKEv2 with Failed Peer Authentication
图11：对等身份验证失败的EAP-IKEv2
Compared to the full successful exchange, one additional roundtrip is required. In message 7, the EAP server MUST send an EAP request with Encrypted payload that contains a Notify payload with the Notify Message Type value set to 24 (AUTHENTICATION_FAILED), instead of sending an EAP-Success message. The EAP peer, upon receiving message 7, MUST send an empty EAP-IKEv2 (informational) message in reply to the EAP server's error indication, as shown in message 8. In messages 7 and 8, the Message ID field in the EAP-IKEv2 header (HDR) MUST carry Message ID value 2. Finally, by means of message 9, the EAP server answers with an EAP-Failure.
与完全成功的交换相比，需要额外的一次往返。在消息7中，EAP服务器必须发送带有加密有效负载的EAP请求，该有效负载包含Notify message Type值设置为24（身份验证失败）的Notify有效负载，而不是发送EAP Success消息。EAP对等方在收到消息7后，必须发送一条空EAP-IKEv2（信息性）消息，以响应EAP服务器的错误指示，如消息8所示。在消息7和8中，EAP-IKEv2标头（HDR）中的消息ID字段必须包含消息ID值2。最后，通过消息9，EAP服务器以EAP故障进行应答。
Authors' Addresses
作者地址
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑第6环汉内斯·茨霍芬尼诺基亚西门子网络公司奥托·哈恩81739
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Dirk Kroeselberg Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑6号环诺基亚西门子网络公司
EMail: Dirk.Kroeselberg@nsn.com
EMail: Dirk.Kroeselberg@nsn.com
Andreas Pashalidis NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Andreas Pashalidis NEC Kurfuersten Anlage 36德国海德堡69115
EMail: pashalidis@nw.neclab.eu
EMail: pashalidis@nw.neclab.eu
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
美国新泽西州皮斯卡塔韦Telcordia Drive 1号东芝美国研究有限公司，邮编：08854
EMail: yohba@tari.toshiba.com
EMail: yohba@tari.toshiba.com
Florent Bersani France Telecom R&D 38, rue du General Leclerc Issy-Les-Moulineaux, Cedex 92794 France
法国Cedex 92794勒克莱尔将军街38号弗洛伦特·贝尔萨尼法国电信研发中心
EMail: florent.ftrd@gmail.com
EMail: florent.ftrd@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.