Internet Engineering Task Force (IETF) Z. Cao
Request for Comments: 6630 H. Deng
Category: Standards Track China Mobile
ISSN: 2070-1721 Q. Wu
Huawei
G. Zorn, Ed.
Network Zen
June 2012
Internet Engineering Task Force (IETF) Z. Cao
Request for Comments: 6630 H. Deng
Category: Standards Track China Mobile
ISSN: 2070-1721 Q. Wu
Huawei
G. Zorn, Ed.
Network Zen
June 2012
EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)
用于认证预期密钥（ERP/AAK）的EAP再认证协议扩展
Abstract
摘要
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.
可扩展身份验证协议（EAP）是支持多种身份验证方法的通用框架。
The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.
EAP重新认证协议（ERP）指定对EAP和EAP密钥层次结构的扩展，以支持EAP方法独立协议，以便通过任何验证器在对等方和EAP重新认证服务器之间进行有效的重新认证。
Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport.
认证预期密钥（AAK）是一种方法，通过该方法，可在移交前在一个或多个候选连接点（CAP）上建立加密密钥材料。AAK使用AAA基础设施进行密钥传输。
This document specifies the extensions necessary to enable AAK support in ERP.
本文档指定了在ERP中启用AAK支持所需的扩展。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6630.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6630.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4
4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7
4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8
5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9
5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9
5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10
5.3. EAP-Finish/Re-auth Packet and TLV Extension . . . . . . . 12
5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 15
7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4
4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7
4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8
5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9
5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9
5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10
5.3. EAP-Finish/Re-auth Packet and TLV Extension . . . . . . . 12
5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 15
7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
The Extensible Authentication Protocol (EAP) [RFC3748] is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable not to repeat the entire EAP exchange with another authenticator. The EAP Re-authentication Protocol (ERP) [RFC5296] specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the EAP re-authentication peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the mobile host (i.e., the EAP re-authentication peer) is connecting.
可扩展认证协议（EAP）[RFC3748]是一个支持多种认证方法的通用框架。在使用EAP进行身份验证的系统中，不希望与另一个身份验证者重复整个EAP交换。EAP重新认证协议（ERP）[RFC5296]指定了对EAP和EAP键控层次结构的扩展，以支持EAP方法独立协议，以便通过任何验证器在EAP重新认证对等方和EAP重新认证服务器之间进行有效的重新认证。重新认证服务器可以在家庭网络中或者在移动主机（即，EAP重新认证对等方）正在连接的本地网络中。
Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK utilizes the AAA infrastructure for key transport.
认证预期键控（AAK）[RFC5836]是一种方法，通过该方法，可在移交前在一个或多个候选连接点（CAP）上建立加密键控材料。AAK利用AAA基础设施进行关键传输。
This document specifies the extensions necessary to enable AAK support in ERP.
本文档指定了在ERP中启用AAK支持所需的扩展。
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]中所述进行解释。
The following acronyms are used in this document; see the references for more details.
本文件中使用了以下首字母缩略词：；有关更多详细信息，请参阅参考资料。
AAA Authentication, Authorization, and Accounting [RFC3588]
AAA身份验证、授权和记帐[RFC3588]
CAP Candidate Attachment Point [RFC5836]
CAP候选连接点[RFC5836]
DSRK Domain-Specific Root Key [RFC5295]
DSRK域特定根密钥[RFC5295]
EA Abbreviation for "ERP/AAK"
EA是“ERP/AAK”的缩写
EA Peer An EAP peer that supports the ERP/AAK. Note that all references to "peer" in this document imply an EA peer, unless specifically noted otherwise.
EA对等点支持ERP/AAK的EAP对等点。请注意，除非另有特别说明，否则本文件中提及的所有“对等方”均指EA对等方。
NAI Network Access Identifier [RFC4282]
NAI网络访问标识符[RFC4282]
pMSK pre-established Master Session Key
预先建立的主会话密钥
pRK pre-established Root Key
pRK预先建立的根密钥
rIK re-authentication Integrity Key [RFC5296]
rIK重新认证完整性密钥[RFC5296]
rRK re-authentication Root Key [RFC5296]
rRK重新身份验证根密钥[RFC5296]
SAP Serving Attachment Point [RFC5836]
SAP服务连接点[RFC5836]
ERP/AAK is intended to allow (upon request by the peer) the establishment of cryptographic keying materials on a single Candidate Attachment Point prior to the arrival of the peer at the Candidate Access Network (CAN).
ERP/AAK旨在允许（根据对等方的请求）在对等方到达候选接入网络（CAN）之前在单个候选连接点上建立加密密钥材料。
In this document, ERP/AAK support by the peer is assumed. Also, it is assumed that the peer has previously completed full EAP authentication and that either the peer or the SAP knows the identities of neighboring attachment points. Note that the behavior of a peer that does not support the ERP-AAK scheme defined in this specification is out of the scope of this document. Figure 1 shows the general protocol exchange by which the keying material is established on the CAP.
在本文件中，假定对等方支持ERP/AAK。此外，假定对等方之前已完成完整的EAP身份验证，并且对等方或SAP知道相邻连接点的身份。请注意，不支持本规范中定义的ERP-AAK方案的对等方的行为超出了本文档的范围。图1显示了在CAP上建立密钥材料的通用协议交换。
+------+ +-----+ +-----+ +-----------+
| Peer | | SAP | | CAP | | EA Server |
+--+---+ +--+--+ +--+--+ +-----+-----+
| | | |
a. | [EAP-Initiate/ | | |
| Re-auth-start | | |
| (E flag)] | | |
|<---------------| | |
| | | |
b. | EAP-Initiate/ | | |
| Re-auth | | |
| (E flag) | | |
|--------------->| | |
c. | | AAA(EAP-Initiate/Re-auth(E flag))|
| |--------------------------------->|
| | | +---------+---------+
| | | | CA authorized & |
d. | | | | and EA Keying |
| | | | Distribution |
| | | +---------+---------+
| | | |
| | | |
f. | | AAA (EAP-Finish/Re-auth(E flag)) |
| |<---------------------------------|
g. | EAP-Finish/ | | |
| Re-auth(E flag)| | |
|<---------------| | |
| | | |
+------+ +-----+ +-----+ +-----------+
| Peer | | SAP | | CAP | | EA Server |
+--+---+ +--+--+ +--+--+ +-----+-----+
| | | |
a. | [EAP-Initiate/ | | |
| Re-auth-start | | |
| (E flag)] | | |
|<---------------| | |
| | | |
b. | EAP-Initiate/ | | |
| Re-auth | | |
| (E flag) | | |
|--------------->| | |
c. | | AAA(EAP-Initiate/Re-auth(E flag))|
| |--------------------------------->|
| | | +---------+---------+
| | | | CA authorized & |
d. | | | | and EA Keying |
| | | | Distribution |
| | | +---------+---------+
| | | |
| | | |
f. | | AAA (EAP-Finish/Re-auth(E flag)) |
| |<---------------------------------|
g. | EAP-Finish/ | | |
| Re-auth(E flag)| | |
|<---------------| | |
| | | |
Figure 1: ERP/AAK Exchange
图1:ERP/AAK交换
+-----------+ +---------+
| | | |
| EA Server | | CAP |
| | | |
+-----|-----+ +----|----+
| |
| |
| AAA Request (pMSK) |
e.1|------------------------->|
| |
| |
| |
| AAA Response (Success) |
e.2|<-------------------------|
| |
| |
| |
+-----------+ +---------+
| | | |
| EA Server | | CAP |
| | | |
+-----|-----+ +----|----+
| |
| |
| AAA Request (pMSK) |
e.1|------------------------->|
| |
| |
| |
| AAA Response (Success) |
e.2|<-------------------------|
| |
| |
| |
Figure 2: Key Distribution for ERP/AAK
图2:ERP/AAK的密钥分配
ERP/AAK reuses the packet format defined by ERP, but specifies a new flag to differentiate EAP early authentication from EAP re-authentication. The peer initiates ERP/AAK without an external trigger, or initiates ERP/AAK in response to an EAP-Initiate/ Re-Auth-Start message from the SAP.
ERP/AAK重用ERP定义的数据包格式，但指定一个新标志来区分EAP早期身份验证和EAP重新身份验证。对等方在没有外部触发器的情况下启动ERP/AAK，或响应SAP发出的EAP Initiate/Re-Auth Start消息启动ERP/AAK。
In the latter case, the SAP MAY send the identity of one or more Candidate Attachment Points to which the SAP is adjacent to the peer in the EAP-Initiate/Re-auth-Start message (see step a in Figure 1). The peer SHOULD override the identity of CAP(s) carried in the EAP-Initiate/Re-auth-Start message by sending EAP-Initiate/Re-auth with the E flag set if it knows to which CAP it will move. If the EAP-Initiate/Re-auth-Start packet is not supported by the peer, it MUST be silently discarded.
在后一种情况下，SAP可以在EAP Initiate/Re-auth Start消息中发送SAP与对等方相邻的一个或多个候选连接点的标识（参见图1中的步骤a）。对等方应通过发送设置了E标志的EAP Initiate/Re-auth来覆盖EAP Initiate/Re-auth启动消息中携带的CAP的标识，前提是它知道将移动到哪个CAP。如果对等方不支持EAP Initiate/Re-auth Start数据包，则必须以静默方式丢弃该数据包。
If the peer initiates ERP/AAK, the peer MAY send an early-authentication request message (EAP-Initiate/Re-auth with the E flag set) containing the keyName-NAI, the CAP-Identifier, rIK, and sequence number (see step b in Figure 1). The realm in the keyName-NAI field is used to locate the peer's ERP/AAK server. The CAP-Identifier is used to identify the CAP. The re-authentication Integrity Key (rIK) is defined by Narayanan & Dondeti in [RFC5296] and is used to protect the integrity of the message. The sequence number is used for replay protection.
如果对等方发起ERP/AAK，则对等方可以发送一条早期身份验证请求消息（EAP Initiate/Re auth with the E flag set），其中包含密钥名NAI、CAP标识符、rIK和序列号（参见图1中的步骤b）。keyName NAI字段中的域用于定位对等方的ERP/AAK服务器。CAP标识符用于标识CAP。重新认证完整性密钥（rIK）由Narayanan&Dondeti在[RFC5296]中定义，用于保护消息的完整性。序列号用于重播保护。
The SAP SHOULD verify the integrity of this message at step b. If this verification fails, the SAP MUST send an EAP-Finish/Re-auth message with the Result flag set to '1' (Failure). If the
SAP应在步骤b中验证此消息的完整性。如果此验证失败，SAP必须发送EAP Finish/Re auth消息，其结果标志设置为“1”（失败）。如果
verification succeeds, the SAP SHOULD encapsulate the early-authentication message into a AAA message and send it to the peer's ERP/AAK server in the realm indicated in the keyName-NAI field (see step c in Figure 1).
验证成功后，SAP应将早期身份验证消息封装为AAA消息，并将其发送到keyName NAI字段中指定领域内的对等方ERP/AAK服务器（参见图1中的步骤c）。
Upon receiving the message, the ERP/AAK server MUST first use the keyName indicated in the keyName-NAI to look up the rIK and check the integrity and freshness of the message. Then, the ERP/AAK server MUST verify the identity of the peer by checking the username portion of the KeyName-NAI. If any of the checks fail, the server MUST send an early-authentication finish message (EAP-Finish/Re-auth with E flag set) with the Result flag set to '1'. Next, the server MUST authorize the CAP specified in the CAP-Identifier TLV. In the success case, the server MUST derive a pMSK from the pRK for the CAP carried in the CAP-Identifier field using the sequence number associated with CAP-Identifier as an input to the key derivation. (see step d in Figure 1).
收到消息后，ERP/AAK服务器必须首先使用keyName NAI中指示的keyName来查找rIK并检查消息的完整性和新鲜度。然后，ERP/AAK服务器必须通过检查KeyName NAI的用户名部分来验证对等方的身份。如果任何检查失败，服务器必须发送结果标志设置为“1”的早期身份验证完成消息（设置了E标志的EAP finish/Re auth）。接下来，服务器必须授权CAP标识符TLV中指定的CAP。在成功的情况下，服务器必须使用与CAP标识符关联的序列号作为密钥派生的输入，从CAP标识符字段中携带的CAP的pRK派生pMSK。（参见图1中的步骤d）。
Then, the ERP/AAK server MUST transport the pMSK to the authorized CAP via AAA (see Section 7) as illustrated above (see steps e.1 and e.2 in Figure 2). Note that key distribution in Figure 2 is one part of step d in Figure 1.
然后，ERP/AAK服务器必须通过AAA（参见第7节）将pMSK传输到授权CAP，如上图所示（参见图2中的步骤e.1和e.2）。注意，图2中的密钥分配是图1中步骤d的一部分。
Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK server SHOULD send the early-authentication finish message (EAP-- -Finish/Re-auth with E flag set) containing the identity of the authorized CAP to the peer via the SAP along with the lifetime of the pMSK. If the peer also requests the rRK Lifetime, the ERP/AAK server SHOULD send the rRK Lifetime in the EAP-Finish/Re-auth message (see steps f and g in Figure 1).
最后，为了响应EAP Initiate/Re-auth消息，ERP/AAK服务器应通过SAP向对等方发送包含授权CAP标识的早期身份验证完成消息（EAP--finish/Re-auth with E flag set），以及pMSK的生存期。如果对等方也请求rRK生存期，ERP/AAK服务器应在EAP Finish/Re auth消息中发送rRK生存期（参见图1中的步骤f和g）。
ERP/AAK uses a key hierarchy similar to that of ERP. The ERP/AAK pre-established Root Key (pRK) is derived from either the EMSK or the DSRK as specified below (see Section 4.1). In general, the pRK is derived from the EMSK if the peer is located in the home AAA realm and derived from the DSRK if the peer is in a visited realm. The DSRK is delivered from the EAP server to the ERP/AAK server as specified in [KEYTRAN]. If the peer has previously been authenticated by means of ERP or ERP/AAK, the DSRK SHOULD be directly reused.
ERP/AAK使用与ERP类似的密钥层次结构。ERP/AAK预先建立的根密钥（pRK）源自以下指定的EMSK或DSRK（见第4.1节）。通常，如果对等方位于家庭AAA领域，则pRK从EMSK派生；如果对等方位于访问领域，则从DSRK派生。按照[KEYTRAN]中的规定，DSRK从EAP服务器传送到ERP/AAK服务器。如果对等方之前已通过ERP或ERP/AAK进行认证，则应直接重新使用DSRK。
DSRK EMSK
| |
+---+---+---+---+
|
pRK ...
DSRK EMSK
| |
+---+---+---+---+
|
pRK ...
Figure 3: ERP/AAK Root Key Derivation
图3:ERP/AAK根键派生
Similarly, the pre-established Master Session Key (pMSK) is derived from the pRK. The pMSK is established for the CAP when the peer early authenticates to the network. The hierarchy relationship is illustrated Figure 4, below.
类似地，从pRK导出预先建立的主会话密钥（pMSK）。当对等方提前向网络进行身份验证时，为CAP建立pMSK。层次关系如下图4所示。
pRK
|
+--------+--------+
|
pMSK ...
pRK
|
+--------+--------+
|
pMSK ...
Figure 4: ERP/AAK Key Hierarchy
图4:ERP/AAK密钥层次结构
The rRK is derived as specified in [RFC5295].
根据[RFC5295]中的规定推导rRK。
pRK = KDF (K, S), where
pRK=KDF（K，S），其中
K = EMSK or K = DSRK and
K=EMSK或K=DSRK和
S = pRK Label | "\0" | length
S=pRK标签|“\0”|长度
The pRK Label is an IANA-assigned 8-bit ASCII string:
pRK标签是IANA指定的8位ASCII字符串：
EAP Early-Authentication Root Key@ietf.org
EAP早期身份验证根Key@ietf.org
assigned from the "User Specific Root Keys (USRK) Key Labels" name space in accordance with Salowey, et al. [RFC5295]. The KDF and algorithm agility for the KDF are also defined in RFC 5295. The KDF algorithm is indicated in the cryptosuite field or list of cryptosuites TLV payload as specified in Sections 5.2 and 5.3.
根据Salowey等[RFC5295]的规定，从“用户特定根密钥（USRK）密钥标签”名称空间分配。KDF和KDF的算法敏捷性也在RFC 5295中定义。KDF算法在cryptosuite字段或cryptosuite TLV有效载荷列表中指明，如第5.2节和第5.3节所述。
The pMSK uses the same KDF as pRK and is derived as follows:
pMSK使用与pRK相同的KDF，其推导如下：
pMSK = KDF (K, S), where
pMSK=KDF（K，S），其中
K = pRK and
K = pRK and
S = pMSK label | "\0" | SEQ | length
S=pMSK标签|“\0”|序号|长度
The pMSK label is the 8-bit ASCII string:
pMSK标签是8位ASCII字符串：
EAP Early-Authentication Master Session Key@ietf.org
EAP早期身份验证主会话Key@ietf.org
The length field refers to the length of the pMSK in octets encoded as specified in RFC 5295. SEQ is sent by either the peer or the server in the ERP/AAK message using the SEQ field or the Sequence number TLV. It is encoded as a 16-bit number as specified in Sections 5.2 and 5.3.
长度字段是指按照RFC 5295中的规定编码的八位字节的pMSK长度。SEQ由对等方或服务器在ERP/AAK消息中使用SEQ字段或序列号TLV发送。按照第5.2节和第5.3节的规定，将其编码为16位数字。
This section describes the packet and TLV extensions for the ERP/AAK exchange.
本节介绍ERP/AAK交换的数据包和TLV扩展。
Figure 5 shows the new parameters contained in the EAP-Initiate/ Re-auth-Start packet defined in [RFC5296].
图5显示了[RFC5296]中定义的EAP Initiate/Re-auth Start数据包中包含的新参数。
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 |E| Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |E| Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP-Initiate/Re-auth-Start Extension
图5:EAP启动/重新验证启动扩展
Flags
旗帜
'E' - The E flag is used to indicate early authentication. This field MUST be set to '1' if early authentication is in use, and it MUST be set to '0' otherwise.
“E”-E标志用于指示早期身份验证。如果正在使用早期身份验证，则必须将此字段设置为“1”，否则必须将其设置为“0”。
The rest of the 7 bits (Reserved) MUST be set to 0 and ignored on reception.
其余7位（保留）必须设置为0，并在接收时忽略。
Type/Values (TVs) and TLVs
类型/值（TVs）和TLV
CAP-Identifier: Carried in a TLV payload. The format is identical to that of a DiameterIdentity [RFC3588]. It is used by the SAP to advertise the identity of the CAP to the peer. Exactly one CAP-Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP discovery.
CAP标识符：载于TLV有效载荷中。格式与直径相同[RFC3588]。SAP使用它向对等方公布CAP的身份。如果SAP已执行CAP发现，则EAP Initiate/Re-auth Start数据包中可能只包含一个CAP标识符TLV。
If the EAP-Initiate/Re-auth-Start packet is not supported by the peer, it SHOULD be discarded silently.
如果对等方不支持EAP Initiate/Re-auth Start数据包，则应以静默方式丢弃该数据包。
Figure 6 illustrates the new parameters contained in the EAP-Initiate/Re-auth packet defined in [RFC5296].
图6说明了[RFC5296]中定义的EAP Initiate/Re-auth数据包中包含的新参数。
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 |R|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |R|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EAP-Initiate/Re-auth Extension
图6:EAP启动/重新验证扩展
Flags
旗帜
'x' - The x flag is reserved. It MUST be ignored on receipt.
“x”-保留x标志。收到时必须忽略它。
'L' - As defined in Section 5.3.2 of [RFC5296], this bit is used to request the key lifetimes from the server.
“L”-如[RFC5296]第5.3.2节所定义，该位用于从服务器请求密钥寿命。
'E' - The E flag is used to indicate early authentication.
“E”-E标志用于指示早期身份验证。
The first bit(R) and final 4 bits (Resved) MUST be set to 0 and ignored on reception.
第一位（R）和最后4位（Resved）必须设置为0，并在接收时忽略。
SEQ
序号
As defined in Section 5.3.2 of [RFC5296], this field is 16-bit sequence number and used for replay protection.
如[RFC5296]第5.3.2节所述，该字段为16位序列号，用于重放保护。
TVs and TLVs
电视和TLV
keyName-NAI: As defined in [RFC5296], this is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The username part of the NAI is the EMSKname used to identify the peer. The realm part of the NAI is the peer's home domain name if the peer communicates with the home EA server or the domain to which the peer is currently attached (i.e., local domain name) if the peer communicates with a local EA server. The
keyName NAI：如[RFC5296]中所定义，这是在TLV有效载荷中携带的。类型是1。NAI长度可变，不超过253个八位字节。NAI的用户名部分是用于标识对等方的EMSKname。如果对等方与家庭EA服务器通信，则NAI的领域部分是对等方的家庭域名；如果对等方与本地EA服务器通信，则NAI的领域部分是对等方当前连接的域（即本地域名）。这个
SAP knows whether the KeyName-NAI carries the local domain name by comparing the domain name carried in the KeyName-NAI with the local domain name that is associated with the SAP. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet and the realm part of it SHOULD follow the use of internationalized domain names defined in [RFC5890].
SAP通过将KeyName NAI中包含的域名与SAP关联的本地域名进行比较，了解KeyName NAI是否包含本地域名。EAP Initiate/Re auth数据包中应仅存在一个keyName NAI属性，其领域部分应遵循[RFC5890]中定义的国际化域名的使用。
CAP-Identifier: Carried in a TLV payload. The Type is 11. This field is used to indicate the Fully Qualified Domain Name (FQDN) of a CAP. The value field MUST be encoded as specified in Section 8 of [RFC3315]. Exactly one instance of the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV.
CAP标识符：载于TLV有效载荷中。类型是11。此字段用于指示CAP的完全限定域名（FQDN）。值字段必须按照[RFC3315]第8节的规定进行编码。ERP/AAK密钥TLV中必须仅存在一个CAP标识符TLV实例。
Sequence number: The Type is 7. The value field is a 16-bit field and used in the derivation of the pMSK for a CAP.
序号：类型为7。值字段是一个16位字段，用于推导CAP的pMSK。
Cryptosuite
加密套件
This field indicates the integrity algorithm used for ERP/AAK. Key lengths and output lengths are either indicated or obvious from the cryptosuite name, e.g., HMAC-SHA256-128 denotes Hashed Message Authentication Code (HMAC) computed using the SHA-256 function [RFC4868] with 256-bit key length and the output truncated to 128 bits [RFC2104]. We specify some cryptosuites below:
此字段表示用于ERP/AAK的完整性算法。密钥长度和输出长度由cryptosuite名称指示或显而易见，例如，HMAC-SHA256-128表示使用SHA-256函数[RFC4868]计算的哈希消息认证码（HMAC），密钥长度为256位，输出截断为128位[RFC2104]。我们在下面指定了一些加密套件：
0-1 RESERVED
0-1保留
2 HMAC-SHA256-128
2 HMAC-SHA256-128
3 HMAC-SHA256-256
3 HMAC-SHA256-256
HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be enabled in the default configuration.
需要实现HMAC-SHA256-128，并且应在默认配置中启用。
Authentication Tag
认证标签
This field contains an integrity checksum over the ERP/AAK packet from the first bit of the Code field to the last bit of the Cryptosuite field, excluding the Authentication Tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and rIK specified in [RFC5296] as the secret key. The length of the field is indicated by the Cryptosuite.
此字段包含ERP/AAK数据包上从代码字段的第一位到Cryptosuite字段的最后一位的完整性校验和，不包括身份验证标记字段本身。使用Cryptosuite字段中指示的完整性算法和[RFC5296]中指定的rIK作为密钥计算值字段。字段的长度由Cryptosuite指示。
The peer uses the Authentication Tag to determine the validity of the EAP-Finish/Re-auth message from the server.
对等方使用身份验证标记确定来自服务器的EAP完成/重新身份验证消息的有效性。
If the message doesn't pass verification or the Authentication Tag is not included in the message, the message SHOULD be discarded silently.
如果消息未通过验证，或者消息中未包含身份验证标记，则应以静默方式丢弃该消息。
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it SHOULD be discarded silently. The peer MUST maintain retransmission timers for reliable transport of the EAP-Initiate/Re-auth message. If there is no response to the EAP-Initiate/Re-auth message from the server after the necessary number of retransmissions (see Section 6), the peer MUST assume that ERP/AAK is not supported by the SAP.
如果SAP不支持EAP Initiate/Re-auth数据包，则应以静默方式丢弃该数据包。对等方必须维护重传计时器，以便可靠传输EAP Initiate/Re-auth消息。如果在必要的重新传输次数后（参见第6节），服务器对EAP Initiate/Re-auth消息没有响应，则对等方必须假定SAP不支持ERP/AAK。
Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth packet defined in [RFC5296].
图7显示了[RFC5296]中定义的EAP Finish/Re-auth数据包中包含的新参数。
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 |R|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |R|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP-Finish/Re-auth Extension
图7:EAP完成/重新验证扩展
Flags
旗帜
'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used as the Result flag. This field MUST be set to '1' to indicate success, and it MUST be set to '0' otherwise.
“R”-如[RFC5296]第5.3.3节所定义，该位用作结果标志。此字段必须设置为“1”以表示成功，否则必须设置为“0”。
'x' - The x flag is reserved. It MUST be ignored on receipt.
“x”-保留x标志。收到时必须忽略它。
'L' - As defined in Section 5.3.3 of [RFC5296], this bit is used to request the key lifetimes from the server.
“L”-如[RFC5296]第5.3.3节所定义，此位用于从服务器请求密钥寿命。
'E' - The E flag is used to indicate early authentication.
“E”-E标志用于指示早期身份验证。
The final 4 bits (Resved) MUST be set to 0 and ignored on reception.
最后4位（Resved）必须设置为0，并在接收时忽略。
SEQ
序号
As defined in Section 5.3.3 of [RFC5296], this field is a 16-bit sequence number and is used for replay protection.
如[RFC5296]第5.3.3节所述，该字段为16位序列号，用于重放保护。
TVs and TLVs
电视和TLV
keyName-NAI: As defined in [RFC5296], this is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth packet.
keyName NAI：如[RFC5296]中所定义，这是在TLV有效载荷中携带的。类型是1。NAI长度可变，不超过253个八位字节。EAP完成/重新验证数据包中应仅存在一个keyName NAI属性。
ERP/AAK-Key: Carried in a TLV payload for the key container. The Type is 8. Exactly one ERP/AAK-key SHALL be present in an EAP-Finish/Re-auth packet.
ERP/AAK钥匙：装在钥匙容器的TLV有效载荷中。类型是8。EAP完成/重新认证数据包中应仅存在一个ERP/AAK密钥。
ERP/AAK-Key ::=
{ sub-TLV: CAP-Identifier }
{ sub-TLV: pMSK Lifetime }
{ sub-TLV: pRK Lifetime }
{ sub-TLV: Cryptosuites }
ERP/AAK-Key ::=
{ sub-TLV: CAP-Identifier }
{ sub-TLV: pMSK Lifetime }
{ sub-TLV: pRK Lifetime }
{ sub-TLV: Cryptosuites }
CAP-Identifier Carried in a sub-TLV payload. The Type is 11 (less than 128). This field is used to indicate the identifier of the candidate authenticator. The value field MUST be encoded as specified in Section 8 of [RFC3315]. At least one instance of the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV.
子TLV有效载荷中携带的CAP标识符。类型为11（小于128）。此字段用于指示候选验证器的标识符。值字段必须按照[RFC3315]第8节的规定进行编码。ERP/AAK密钥TLV中必须至少存在一个CAP标识符TLV实例。
pMSK Lifetime Carried in a sub-TLV payload of the EAP-Finish/Re-auth message. The Type is 10. The value field is an unsigned 32-bit field and contains the lifetime of the pMSK in seconds. This value is calculated by the server after performing the pRK Lifetime computation upon receiving the EAP-Initiate/Re-auth message. The rIK SHOULD share the same lifetime as the pMSK. If the 'L' flag is set, the pMSK Lifetime attribute MUST be present.
EAP Finish/Re auth消息的子TLV有效负载中携带的pMSK生存期。类型是10。值字段是一个无符号32位字段，包含pMSK的生存期（以秒为单位）。该值由服务器在收到EAP Initiate/Re-auth消息时执行pRK生存期计算后计算得出。rIK应与pMSK共享相同的寿命。如果设置了“L”标志，则必须存在pMSK生存期属性。
pRK Lifetime Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The Type is 9. The value field is an unsigned 32-bit field and contains the lifetime of the pRK in seconds. This value is calculated by the server before performing the pMSK Lifetime computation upon receiving a EAP-Initiate/Re-auth message. If the 'L' flag is set, the pRK Lifetime attribute MUST be present.
EAP Finish/Re auth消息的子TLV有效负载中携带的pRK生存期。类型是9。值字段是一个无符号32位字段，包含pRK的生存期（以秒为单位）。该值由服务器在接收到EAP Initiate/Re auth消息后执行pMSK生存期计算之前计算。如果设置了“L”标志，则必须存在pRK LIFET属性。
List of Cryptosuites Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value field contains a list of cryptosuites (at least one cryptosuite SHOULD be included), each 1 octet in length. The allowed cryptosuite values are as specified in Section 5.2. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal its cryptographic algorithm capabilities to the peer.
子TLV有效载荷中携带的加密套件列表。类型为5[RFC5296]。值字段包含一个cryptosuite列表（至少应包括一个cryptosuite），每个长度为1个八位字节。第5.2节规定了允许的cryptosuite值。如果EAP Initiate/Re auth消息中使用的cryptosuite不可接受且消息被拒绝，则服务器应包含此属性。在其他情况下，服务器可能会包含此属性。服务器可以使用此属性向对等方发送其加密算法功能的信号。
Cryptosuite
加密套件
This field indicates the integrity algorithm and PRF used for ERP/ AAK. HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be enabled in the default configuration. Key lengths and output lengths are either indicated or obvious from the cryptosuite name.
此字段表示用于ERP/AAK的完整性算法和PRF。需要实现HMAC-SHA256-128，并且应在默认配置中启用。密钥长度和输出长度由cryptosuite名称指示或明显可见。
Authentication Tag
认证标签
This field contains the integrity checksum over the ERP/AAK packet from the first bit of the Code field to the last bit of the Cryptosuite field, excluding the Authentication Tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and the rIK [RFC5296] as the integrity key. The length of the field is indicated by the corresponding Cryptosuite.
此字段包含ERP/AAK数据包上从代码字段的第一位到Cryptosuite字段的最后一位的完整性校验和，不包括身份验证标记字段本身。使用Cryptosuite字段中指示的完整性算法和rIK[RFC5296]作为完整性密钥计算值字段。字段的长度由相应的Cryptosuite指示。
The peer uses the authentication tag to determine the validity of the EAP-Finish/Re-auth message from a server.
对等方使用身份验证标签确定来自服务器的EAP完成/重新身份验证消息的有效性。
If the message doesn't pass verification or the authentication tag is not included in the message, the message SHOULD be discarded silently.
如果消息未通过验证，或者消息中未包含身份验证标记，则应以静默方式丢弃该消息。
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is discarded silently. The peer MUST maintain retransmission timers for reliable transport of the EAP-Initiate/Re-auth message. If there is no response to the EAP-Initiate/Re-auth message from the server after the necessary number of retransmissions (see Section 6), the peer MUST assume that ERP/AAK is not supported by the SAP.
如果SAP不支持EAP Initiate/Re-auth数据包，则会自动丢弃该数据包。对等方必须维护重传计时器，以便可靠传输EAP Initiate/Re-auth消息。如果在必要的重新传输次数后（参见第6节），服务器对EAP Initiate/Re-auth消息没有响应，则对等方必须假定SAP不支持ERP/AAK。
With the exception of the rRK Lifetime and rMSK Lifetime TV payloads, the attributes specified in Section 5.3.4 of [RFC5296] also apply to this document. In this document, new attributes that may be present in the EAP-Initiate and EAP-Finish messages are defined as below:
除rRK寿命和rMSK寿命电视有效载荷外，[RFC5296]第5.3.4节中规定的属性也适用于本文件。在本文档中，EAP Initiate和EAP Finish消息中可能存在的新属性定义如下：
o Sequence number: This is a TV payload. The Type is 7.
o 序列号：这是一个电视有效载荷。类型是7。
o ERP/AAK-Key: This is a TLV payload. The Type is 8.
o ERP/AAK键：这是TLV有效载荷。类型是8。
o pRK Lifetime: This is a TV payload. The Type is 9.
o pRK寿命：这是一个电视有效载荷。类型是9。
o pMSK Lifetime: This is a TV payload. The Type is 10.
o pMSK寿命：这是一个电视有效载荷。类型是10。
o CAP-Identifier: This is a TLV payload. The Type is 11.
o CAP标识符：这是TLV有效载荷。类型是11。
Similar to ERP, some lower-layer specifications may need to be revised to support ERP/AAK; refer to Section 6 of [RFC5296] for additional guidance.
与ERP类似，可能需要修改一些较低层规范以支持ERP/AAK；更多指南，请参阅[RFC5296]第6节。
The AAA transport of ERP/AAK messages is the same as that of the ERP message [RFC5296]. In addition, this document requires AAA transport of the ERP/AAK keying materials delivered by the ERP/AAK server to the CAP. Hence, a new AAA message for the ERP/AAK application should be specified to transport the keying materials.
ERP/AAK消息的AAA传输与ERP消息的AAA传输相同[RFC5296]。此外，本文件要求AAA将ERP/AAK服务器交付的ERP/AAK键控材料运输至CAP。因此，应为ERP/AAK应用程序指定一条新的AAA消息来传输键控材料。
This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in [RFC4962].
本节根据[RFC4962]中规定的AAA密钥管理要求对协议进行分析。
o Cryptographic algorithm independence: ERP-AAK satisfies this requirement. The algorithm chosen by the peer for calculating the authentication tag is indicated in the EAP-Initiate/Re-auth message. If the chosen algorithm is unacceptable, the EAP server returns an EAP-Finish/Re-auth message with a Failure indication.
o 密码算法独立性：ERP-AAK满足此要求。对等方选择用于计算认证标签的算法在EAP Initiate/Re-auth消息中指示。如果所选算法不可接受，EAP服务器将返回带有故障指示的EAP Finish/Re auth消息。
o Strong, fresh session keys: ERP-AAK results in the derivation of strong, fresh keys that are unique for the given CAP. A pMSK is always derived on demand when the peer requires a key with a new CAP. The derivation ensures that the compromise of one pMSK does not result in the compromise of a different pMSK at any time.
o 强、新会话密钥：ERP-AAK导致导出强、新密钥，这些密钥对于给定CAP是唯一的。当对等方需要具有新CAP的密钥时，总是根据需要派生pMSK。该推导确保了一个pMSK的折衷在任何时候都不会导致不同pMSK的折衷。
o Limit key scope: The scope of all the keys derived by ERP-AAK is well defined. The pRK is used to derive the pMSK for the CAP. Different sequence numbers for each CAP MUST be used to derive a unique pMSK.
o 限制键范围：ERP-AAK派生的所有键的范围都定义得很好。pRK用于推导CAP的pMSK。必须使用每个CAP的不同序列号来导出唯一的pMSK。
o Replay detection mechanism: For replay protection, a sequence number associated with the pMSK is used. The peer increments the sequence number by one after it sends an ERP/AAK message. The server sets the expected sequence number to the received sequence number plus one after verifying the validity of the received message, and it responds to the message.
o 重播检测机制：对于重播保护，使用与pMSK关联的序列号。对等方在发送ERP/AAK消息后，将序列号增加1。在验证接收到的消息的有效性后，服务器将预期序列号设置为接收到的序列号加上一，并响应消息。
o Authenticate all parties: The EAP Re-authentication Protocol provides mutual authentication of the peer and the server. The peer and SAP are authenticated via ERP. The CAP is authenticated and trusted by the SAP.
o 认证各方：EAP重新认证协议提供对等方和服务器的相互认证。对等机和SAP通过ERP进行身份验证。CAP由SAP进行身份验证和信任。
o Peer and authenticator authorization: The peer and authenticator demonstrate possession of the same keying material without disclosing it, as part of the lower-layer secure authentication protocol.
o 对等方和身份验证方授权：对等方和身份验证方证明拥有相同的密钥材料，而不披露，作为下层安全身份验证协议的一部分。
o Keying material confidentiality: The peer and the server derive the keys independently using parameters known to each entity.
o 密钥材料机密性：对等方和服务器使用每个实体已知的参数独立地派生密钥。
o Uniquely named keys: All keys produced within the ERP context can be referred to uniquely as specified in this document.
o 唯一命名的密钥：在ERP上下文中生成的所有密钥都可以按照本文档中的指定进行唯一引用。
o Prevent the domino effect: Different sequence numbers for each CAP MUST be used to derive the unique pMSK so that the compromise of one pMSK does not hurt any other CAP.
o 防止多米诺效应：必须使用每个CAP的不同序列号来推导唯一的pMSK，以便一个pMSK的妥协不会损害任何其他CAP。
o Bind key to its context: The pMSKs are bound to the context in which the sequence numbers are transmitted.
o 将密钥绑定到其上下文：PMSK绑定到传输序列号的上下文。
o Confidentiality of identity: This is the same as with ERP [RFC5296].
o 身份保密性：这与ERP[RFC5296]相同。
o Authorization restriction: All the keys derived are limited in lifetime by that of the parent key or by server policy. Any domain-specific keys are further restricted to be used only in the domain for which the keys are derived. Any other restrictions of session keys may be imposed by the specific lower layer and are out of scope for this specification.
o 授权限制：派生的所有密钥在生存期内都受到父密钥的限制或服务器策略的限制。任何特定于域的密钥进一步限制为仅在为其派生密钥的域中使用。会话密钥的任何其他限制可能由特定的较低层施加，超出本规范的范围。
IANA has assigned five TLVs from the registry of EAP Initiate and Finish Attributes maintained at http://www.iana.org/assignments/eap-numbers/ with the following numbers:
IANA已从维护在的EAP Initiate和Finish属性注册表中分配了五个TLVhttp://www.iana.org/assignments/eap-numbers/ 以下数字：
o Sequence number: This is a TV payload. The Type is 7.
o 序列号：这是一个电视有效载荷。类型是7。
o ERP/AAK-Key: This is a TLV payload. The Type is 8.
o ERP/AAK键：这是TLV有效载荷。类型是8。
o pRK Lifetime: This is a TLV payload. The Type is 9.
o pRK寿命：这是TLV有效载荷。类型是9。
o pMSK Lifetime: This is a TLV payload. The Type is 10.
o pMSK寿命：这是TLV有效载荷。类型是10。
o CAP-Identifier: This is a TLV payload. The Type is 11.
o CAP标识符：这是TLV有效载荷。类型是11。
This document reuses the cryptosuites that were created for "Re-authentication Cryptosuites" in [RFC5296].
本文档重用为[RFC5296]中的“重新验证加密套件”创建的加密套件。
Further, IANA has added a new label in the "User Specific Root Keys (USRK) Key Labels" sub-registry of the "Extended Master Session Key (EMSK) Parameters" registry, as follows:
此外，IANA在“扩展主会话密钥（EMSK）参数”注册表的“用户特定根密钥（USRK）密钥标签”子注册表中添加了一个新标签，如下所示：
EAP Early-Authentication Root Key@ietf.org
EAP早期身份验证根Key@ietf.org
A new registry for the flags in the EAP Initiate/Re-auth-Start message called the "EAP Initiate/Re-auth-Start Flags" has been created and a new flag (E) has been assigned as follows:
已为EAP Initiate/Re-auth Start消息中的标志创建了一个名为“EAP Initiate/Re-auth Start flags”的新注册表，并按如下方式分配了一个新标志（E）：
(E) 0x80
（E） 0x80
The rest of the values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG Approval [RFC5226].
8位字段中的其余值保留。可通过标准行动或IESG批准[RFC5226]分配新值。
A new registry for the flags in the EAP Initiate/Re-auth message called the "EAP Initiate/Re-auth Flags" has also been created. The following flags are reserved:
还为EAP Initiate/Re-auth消息中的标志创建了一个名为“EAP Initiate/Re-auth flags”的新注册表。保留以下标志：
(R) 0x80 [RFC5296]
（R） 0x80[RFC5296]
(B) 0x40 [RFC5296]
（B） 0x40[RFC5296]
(L) 0x20 [RFC5296]
（五十） 0x20[RFC5296]
This document assigns a new flag (E) as follows:
本文件指定了一个新标志（E），如下所示：
(E) 0x10
（E） 0x10
The rest of the values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG Approval.
8位字段中的其余值保留。可通过标准行动或IESG批准分配新值。
Further, this document creates a new registry for the flags in the EAP Finish/Re-auth message called the "EAP Finish/Re-auth Flags". The following values are assigned.
此外，本文档还为EAP Finish/Re-auth消息中的标志创建了一个新的注册表，称为“EAP Finish/Re-auth标志”。将指定以下值。
(R) 0x80 [RFC5296]
（R） 0x80[RFC5296]
(B) 0x40 [RFC5296]
（B） 0x40[RFC5296]
(L) 0x20 [RFC5296]
（五十） 0x20[RFC5296]
This document assigns a new flag (E) as follows:
本文件指定了一个新标志（E），如下所示：
(E) 0x10
（E） 0x10
The rest of the values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG approval.
8位字段中的其余值保留。可通过标准行动或IESG批准分配新值。
In writing this document, Yungui Wang contributed to early versions of this document and we have received reviews from many experts in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia, and Sujing Zhou. We apologize if we miss some of those who have helped us.
在撰写本文件的过程中，王云贵为本文件的早期版本做出了贡献，我们收到了IETF许多专家的评论，包括汤姆·泰勒、邹天娜、蒂姆·波尔克、谭章、塞米恩·米齐科夫斯基、斯蒂芬·法雷尔、拉迪亚·帕尔曼、米格尔·加西亚和周苏京。如果我们错过了一些帮助过我们的人，我们深表歉意。
[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月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[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月。
[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月。
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[RFC5295]Salowey，J.，Dondeti，L.，Narayanan，V.，和M.Nakhjiri，“从扩展主会话密钥（EMSK）派生根密钥的规范”，RFC 52952008年8月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296]Narayanan，V.和L.Dondeti，“EAP再认证协议（ERP）的EAP扩展”，RFC 52962008年8月。
[KEYTRAN] Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Work in Progress, August 2011.
[KEYTRAN]Zorn，G.，Wu，W.和V.Cakulev，“加密密钥传输的直径属性值对”，正在进行的工作，2011年8月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[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月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
[RFC5836]Ohba，Y.，Wu，Q.，和G.Zorn，“可扩展身份验证协议（EAP）早期身份验证问题声明”，RFC 58362010年4月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
Authors' Addresses
作者地址
Zhen Cao China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China
中国移动北京市宣武区西边门内大街53A号，邮编100053
EMail: zehn.cao@gmail.com
EMail: zehn.cao@gmail.com
Hui Deng China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China
中国北京市宣武区西边门内大街53A号惠登中国移动100053
EMail: denghui02@gmail.com
EMail: denghui02@gmail.com
Qin Wu Huawei Floor 12, HuiHong Mansion, No. 91 BaiXia Rd. Nanjing, Jiangsu 210001 P.R. China
中国江苏省南京市白下路91号汇鸿大厦12楼秦武华为210001
Phone: +86 25 56623633
EMail: sunseawq@huawei.com
Phone: +86 25 56623633
EMail: sunseawq@huawei.com
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
格伦·佐恩（编辑）网络禅227/358泰国曼谷Thnon Sanphawut Bang Na 10260
Phone: +66 (0) 87-040-4617
EMail: glenzorn@gmail.com
Phone: +66 (0) 87-040-4617
EMail: glenzorn@gmail.com