Internet Engineering Task Force (IETF) Z. Cao
Request for Comments: 6696 China Mobile
Obsoletes: 5296 B. He
Category: Standards Track CATR
ISSN: 2070-1721 Y. Shi
Q. Wu, Ed.
Huawei
G. Zorn, Ed.
Network Zen
July 2012
Internet Engineering Task Force (IETF) Z. Cao
Request for Comments: 6696 China Mobile
Obsoletes: 5296 B. He
Category: Standards Track CATR
ISSN: 2070-1721 Y. Shi
Q. Wu, Ed.
Huawei
G. Zorn, Ed.
Network Zen
July 2012
EAP Extensions for the EAP Re-authentication Protocol (ERP)
EAP重新认证协议（ERP）的EAP扩展
Abstract
摘要
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document 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. The re-authentication server may be in the home network or in the local network to which the peer is connecting.
可扩展身份验证协议（EAP）是支持多种身份验证方法的通用框架。在使用EAP进行身份验证的系统中，希望避免与另一个身份验证者重复整个EAP交换。本文档指定了对EAP和EAP密钥层次结构的扩展，以支持EAP方法独立协议，以便通过任何验证器在对等方和EAP重新认证服务器之间进行有效的重新认证。重新认证服务器可以在家庭网络中或者在对等方正在连接的本地网络中。
This memo obsoletes RFC 5296.
本备忘录废除RFC 5296。
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/rfc6696.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6696.
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 ....................................................4
1.1. Changes from RFC 5296 ......................................5
2. Terminology .....................................................5
3. ERP Description .................................................7
3.1. ERP with the Home ER Server ...............................10
3.2. ERP with a Local ER Server ................................11
4. ER Key Hierarchy ...............................................13
4.1. rRK Derivation ............................................13
4.2. rRK Properties ............................................14
4.3. rIK Derivation ............................................14
4.4. rIK Properties ............................................15
4.5. rIK Usage .................................................16
4.6. rMSK Derivation ...........................................16
4.7. rMSK Properties ...........................................17
5. Protocol Details ...............................................17
5.1. ERP Bootstrapping .........................................17
5.2. Steps in ERP ..............................................20
5.2.1. Multiple Simultaneous Runs of ERP ..................23
5.2.2. ERP Failure Handling ...............................23
5.3. EAP Codes .................................................25
5.3.1. EAP-Initiate/Re-auth-Start Packet ..................26
5.3.1.1. Authenticator Operation ...................27
5.3.1.2. Peer Operation ............................27
5.3.2. EAP-Initiate/Re-auth Packet ........................28
5.3.3. EAP-Finish/Re-auth Packet ..........................30
5.3.4. TV and TLV Attributes ..............................32
5.4. Replay Protection .........................................33
5.5. Channel Binding ...........................................34
6. Lower-Layer Considerations .....................................35
7. AAA Transport of ERP Messages ..................................36
8. Security Considerations ........................................36
9. IANA Considerations ............................................41
10. Contributors ..................................................41
11. Acknowledgments ...............................................42
12. References ....................................................42
12.1. Normative References .....................................42
12.2. Informative References ...................................42
Appendix A. RFC 5296 Acknowledgments ..............................45
Appendix B. Sample ERP Exchange ...................................46
1. Introduction ....................................................4
1.1. Changes from RFC 5296 ......................................5
2. Terminology .....................................................5
3. ERP Description .................................................7
3.1. ERP with the Home ER Server ...............................10
3.2. ERP with a Local ER Server ................................11
4. ER Key Hierarchy ...............................................13
4.1. rRK Derivation ............................................13
4.2. rRK Properties ............................................14
4.3. rIK Derivation ............................................14
4.4. rIK Properties ............................................15
4.5. rIK Usage .................................................16
4.6. rMSK Derivation ...........................................16
4.7. rMSK Properties ...........................................17
5. Protocol Details ...............................................17
5.1. ERP Bootstrapping .........................................17
5.2. Steps in ERP ..............................................20
5.2.1. Multiple Simultaneous Runs of ERP ..................23
5.2.2. ERP Failure Handling ...............................23
5.3. EAP Codes .................................................25
5.3.1. EAP-Initiate/Re-auth-Start Packet ..................26
5.3.1.1. Authenticator Operation ...................27
5.3.1.2. Peer Operation ............................27
5.3.2. EAP-Initiate/Re-auth Packet ........................28
5.3.3. EAP-Finish/Re-auth Packet ..........................30
5.3.4. TV and TLV Attributes ..............................32
5.4. Replay Protection .........................................33
5.5. Channel Binding ...........................................34
6. Lower-Layer Considerations .....................................35
7. AAA Transport of ERP Messages ..................................36
8. Security Considerations ........................................36
9. IANA Considerations ............................................41
10. Contributors ..................................................41
11. Acknowledgments ...............................................42
12. References ....................................................42
12.1. Normative References .....................................42
12.2. Informative References ...................................42
Appendix A. RFC 5296 Acknowledgments ..............................45
Appendix B. Sample ERP Exchange ...................................46
The Extensible Authentication Protocol (EAP) is an authentication framework that supports multiple authentication methods. The primary purpose is network access authentication, and a key-generating method is used when the lower layer wants to enforce access control. The EAP keying hierarchy defines two keys to be derived by all key-generating EAP methods: the Master Session Key (MSK) and the Extended MSK (EMSK). In the most common deployment scenario, an EAP peer and an EAP server authenticate each other through a third party known as the EAP authenticator. The EAP authenticator or an entity controlled by the EAP authenticator enforces access control. After successful authentication, the EAP server transports the MSK to the EAP authenticator; the EAP authenticator and the EAP peer establish Transient Session Keys (TSKs) using the MSK as the authentication key, key derivation key, or a key transport key, and use the TSK for per-packet access enforcement.
可扩展身份验证协议（EAP）是一个支持多种身份验证方法的身份验证框架。主要目的是网络访问认证，当较低层想要强制访问控制时，使用密钥生成方法。EAP密钥层次结构定义了由所有密钥生成EAP方法派生的两个密钥：主会话密钥（MSK）和扩展MSK（EMSK）。在最常见的部署场景中，EAP对等方和EAP服务器通过称为EAP验证器的第三方相互认证。EAP验证器或由EAP验证器控制的实体实施访问控制。认证成功后，EAP服务器将MSK传输给EAP认证器；EAP认证器和EAP对等方使用MSK作为认证密钥、密钥派生密钥或密钥传输密钥来建立临时会话密钥（TSK），并使用TSK来实施每个分组的访问。
When a peer moves from one authenticator to another, it is desirable to avoid a full EAP authentication to support fast handovers. The full EAP exchange with another run of the EAP method can take several round trips and significant time to complete, causing increased handover times. Some EAP methods specify the use of state from the initial authentication to optimize re-authentications by reducing the computational overhead (e.g., EAP Authentication and Key Agreement (EAP-AKA) [RFC4187]), but method-specific re-authentication takes at least 2 round trips with the original EAP server in most cases. It is also important to note that several methods do not offer support for re-authentication.
当对等方从一个验证器移动到另一个验证器时，希望避免完全EAP认证以支持快速切换。与另一个EAP方法运行的完整EAP交换可能需要多次往返和大量时间才能完成，从而导致切换时间增加。一些EAP方法通过减少计算开销（例如，EAP身份验证和密钥协议（EAP-AKA）[RFC4187]）指定使用初始身份验证的状态来优化重新身份验证，但在大多数情况下，特定于方法的重新身份验证至少需要与原始EAP服务器进行两次往返。还需要注意的是，有几种方法不支持重新身份验证。
Key sharing across authenticators is sometimes used as a practical solution to lower handover times. In that case, however, the compromise of one authenticator results in the compromise of key material established via other authenticators. Other solutions for fast re-authentication exist in the literature: for example, see Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP re-authentication problem statement in detail [RFC5169].
跨认证器的密钥共享有时被用作减少切换时间的实用解决方案。然而，在这种情况下，一个验证器的泄露导致通过其他验证器建立的密钥材料的泄露。文献中还存在其他快速重新认证的解决方案：例如，见Lopez等人[MSKHierarchy]；Clancy等人详细描述了EAP重新认证问题陈述[RFC5169]。
In conclusion, to achieve low latency handovers, there is a need for a method-independent re-authentication protocol that completes in less than 2 round trips, preferably with a local server.
总之，为了实现低延迟切换，需要一种独立于方法的重新认证协议，该协议在不到2次往返中完成，最好是使用本地服务器。
This document specifies EAP Re-authentication Extensions (ERXs) for efficient re-authentication using EAP. The protocol that uses these extensions is itself referred to as the EAP Re-authentication Protocol (ERP). It supports EAP method-independent re-authentication
本文档指定了EAP重新身份验证扩展（ERX），以便使用EAP进行有效的重新身份验证。使用这些扩展的协议本身称为EAP重新认证协议（ERP）。它支持与EAP方法无关的重新身份验证
for a peer that has valid, unexpired key material from a previously performed EAP authentication. The protocol and the key hierarchy required for EAP re-authentication are described in this document.
对于具有来自先前执行的EAP身份验证的有效、未过期密钥材料的对等方。本文档描述了EAP重新认证所需的协议和密钥层次结构。
Note that to support ERP, lower-layer specifications may need to be revised to allow carrying EAP messages that have a code value higher than 4 and to accommodate the peer-initiated nature of ERP. Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must be updated to carry ERP messages; work is in progress on this project [IKE-EXT-for-ERP].
请注意，为了支持ERP，可能需要修改下层规范，以允许承载代码值大于4的EAP消息，并适应ERP的对等启动性质。具体而言，必须更新互联网密钥交换（IKE）协议[RFC5996]，以承载ERP消息；该项目的工作正在进行中[IKE EXT for ERP]。
This document obsoletes RFC 5296 but is fully backward compatible with that document. The changes introduced in this document focus on fixing issues that have surfaced since the publication of the original ERP specification [RFC5296]. An overview of some of the major changes is given below.
本文件淘汰RFC 5296，但与该文件完全向后兼容。本文档中引入的更改侧重于修复自原始ERP规范[RFC5296]发布以来出现的问题。下文概述了一些主要变化。
o Co-location of the home EAP Re-authentication (ER) and EAP servers is no longer required (see the "ER Server" entry in Section 2).
o 不再需要将家庭EAP重新认证（ER）和EAP服务器放在同一位置（请参阅第2节中的“ER服务器”条目）。
o The behavior of the authenticator and local ER server during the bootstrapping process has been clarified (Section 5.1); in particular, the authenticator and/or local ER server is now required to check for current possession of the root keys.
o 已澄清了自举过程中认证器和本地ER服务器的行为（第5.1节）；特别是，现在需要验证器和/或本地ER服务器来检查根密钥的当前拥有情况。
o The authenticator is now recommended, rather than just allowed, to initiate the ERP conversation by means of the EAP-Initiate/ Re-auth-Start message (Section 5.3.1.1).
o 现在建议认证者通过EAP initiate/Re-auth Start消息（第5.3.1.1节）发起ERP对话，而不仅仅是允许认证者。
In addition, many editorial changes have been made to improve the clarity of the document and to eliminate perceived ambiguities. A comprehensive list of changes is not given here for practical reasons.
此外，还进行了许多编辑性修改，以提高文件的清晰度并消除可察觉的歧义。出于实际原因，此处未给出全面的变更列表。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document uses the basic EAP terminology [RFC3748] and EMSK keying hierarchy terminology [RFC5295]. In addition, this document uses the following terms:
本文件使用基本EAP术语[RFC3748]和EMSK键控层次术语[RFC5295]。此外，本文件使用以下术语：
ER Peer - An EAP peer that supports the EAP Re-authentication Protocol. All references to "peer" in this document imply an ER peer, unless specifically noted otherwise.
ER对等-支持EAP重新认证协议的EAP对等。除非另有特别说明，否则本文件中提及的“对等方”均指ER对等方。
ER Authenticator - An entity that supports the authenticator functionality for EAP re-authentication described in this document. All references to "authenticator" in this document imply an ER authenticator, unless specifically noted otherwise.
ER验证器-支持本文档中所述EAP重新认证的验证器功能的实体。除非另有特别说明，否则本文件中对“验证者”的所有引用均指ER验证者。
ER Server - An entity that performs the server portion of ERP described here. This entity may or may not be an EAP server. All references to "server" in this document imply an ER server, unless specifically noted otherwise. An ER server is a logical entity; it may not necessarily be co-located with, or physically part of, a full EAP server.
ER服务器-执行此处描述的ERP服务器部分的实体。此实体可能是也可能不是EAP服务器。除非另有特别说明，否则本文件中对“服务器”的所有引用均指ER服务器。ER服务器是一个逻辑实体；它不一定与完整EAP服务器位于同一位置，也不一定是完整EAP服务器的物理部分。
ERX - EAP re-authentication extensions.
ERX-EAP重新认证扩展。
ERP - EAP Re-authentication Protocol. Uses the re-authentication extensions.
ERP-EAP再认证协议。使用重新身份验证扩展。
rRK - re-authentication Root Key, derived from the EMSK or the Domain-Specific Root Key (DSRK).
rRK—重新身份验证根密钥，从EMSK或域特定根密钥（DSRK）派生。
rIK - re-authentication Integrity Key, derived from the rRK.
rIK-从rRK派生的重新身份验证完整性密钥。
rMSK - re-authentication MSK. This is a per-authenticator key, derived from the rRK.
rMSK-重新验证MSK。这是从rRK派生的每个验证器密钥。
keyName-NAI - ERP messages are integrity protected with the rIK or the DS-rIK. The use of rIK or DS-rIK for integrity protection of ERP messages is indicated by the EMSKname [RFC5295]; the protocol, which is ERP; and the realm, which indicates the domain name of the ER server. The EMSKname is copied into the username part of the Network Access Identifier (NAI).
keyName NAI-ERP消息通过rIK或DS rIK进行完整性保护。EMSKname[RFC5295]表示使用rIK或DS rIK保护ERP消息的完整性；协议，即ERP；域，表示ER服务器的域名。EMSKname被复制到网络访问标识符（NAI）的用户名部分。
Domain - Refers to a "key management domain" as defined in Salowey, et al. [RFC5295]. For simplicity, it is referred to as "domain" in this document. The terms "home domain" and "local domain" are used to differentiate between the originating key management domain that performs the full EAP exchange with the peer and the local domain to which a peer may be attached at a given time.
域-指Salowey等人[RFC5295]中定义的“密钥管理域”。为简单起见，在本文档中它被称为“域”。术语“主域”和“本地域”用于区分与对等方执行完整EAP交换的原始密钥管理域和对等方在给定时间可能连接到的本地域。
ERP allows a peer and server to mutually verify proof of possession of key material from an earlier EAP method run and to establish a security association between the peer and the authenticator. The authenticator acts as a pass-through entity for the re-authentication protocol in a manner similar to that of an EAP authenticator as described in Aboba, et al. [RFC3748]. ERP is a single round-trip exchange between the peer and the server; it is independent of the lower layer and the EAP method used during the full EAP exchange. The ER server may be in the home domain or in the same (visited) domain as the peer and the authenticator (i.e., the local domain).
ERP允许对等方和服务器相互验证拥有早期EAP方法运行的关键材料的证据，并在对等方和认证方之间建立安全关联。认证器作为重新认证协议的传递实体，其方式类似于Aboba等人[RFC3748]中描述的EAP认证器。ERP是对等方和服务器之间的单次往返交换；它独立于较低层和完整EAP交换期间使用的EAP方法。ER服务器可以在主域中，或者与对等方和认证器（即，本地域）在相同的（访问的）域中。
Figure 1 shows the protocol exchange. The first time the peer attaches to any network, it performs a full EAP exchange (shown in Figure 2) with the EAP server; as a result, an MSK is distributed to the EAP authenticator. The MSK is then used by the authenticator and the peer to establish TSKs as needed. At the time of the initial EAP exchange, the peer and the server also derive an EMSK, which is used to derive an rRK. More precisely, an rRK is derived from the EMSK or from a DSRK, which is itself derived from the EMSK. The rRK is only available to the peer and the ER server and is never handed out to any other entity. Further, an rIK is derived from the rRK; the peer and the ER server use the rIK to provide proof of possession while performing an ERP exchange. The rIK is also never handed out to any entity and is only available to the peer and server.
图1显示了协议交换。对等方第一次连接到任何网络时，它会与EAP服务器执行完整的EAP交换（如图2所示）；结果，MSK被分发到EAP验证器。然后，认证器和对等方使用MSK根据需要建立TSK。在初始EAP交换时，对等方和服务器还派生一个EMSK，用于派生rRK。更准确地说，rRK是从EMSK或DSRK派生的，DSRK本身是从EMSK派生的。rRK仅对对等方和ER服务器可用，从不分发给任何其他实体。此外，从rRK导出rIK；对等方和ER服务器在执行ERP交换时使用rIK提供占有证明。rIK也从不分发给任何实体，只对对等方和服务器可用。
Peer ER Authenticator ER Server
==== ================ =========
Peer ER Authenticator ER Server
==== ================ =========
<-- EAP-Initiate/ -----
Re-auth-Start
[<-- EAP-Request/ ------
Identity]
<-- EAP-Initiate/ -----
Re-auth-Start
[<-- EAP-Request/ ------
Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
Note: [] brackets indicate optionality.
注：[]括号表示可选性。
Figure 1: ERP Exchange
图1:ERP交换
EAP Peer EAP Authenticator EAP Server
======== ================= ==========
EAP Peer EAP Authenticator EAP Server
======== ================= ==========
<--- EAP-Request/ ------
Identity
<--- EAP-Request/ ------
Identity
----- EAP Response/ --->
Identity ---AAA(EAP Response/Identity)-->
----- EAP Response/ --->
Identity ---AAA(EAP Response/Identity)-->
<--- EAP Method -------> <------ AAA(EAP Method -------->
exchange exchange)
<--- EAP Method -------> <------ AAA(EAP Method -------->
exchange exchange)
<----AAA(MSK, EAP-Success)------
<----AAA(MSK, EAP-Success)------
<---EAP-Success---------
<---EAP-Success---------
Figure 2: EAP Authentication
图2:EAP身份验证
Two EAP codes -- EAP-Initiate and EAP-Finish -- are specified in this document for the purpose of EAP re-authentication. When the peer identifies a target authenticator that supports EAP re-authentication, it performs an ERP exchange, as shown in Figure 1; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP re-authentication, or prior to attachment. The peer initiates ERP by itself; it may also do so in response to an EAP-Initiate/Re-auth-Start message from the new authenticator. The EAP-Initiate/Re-auth-Start message allows the authenticator to trigger the ERP exchange. The EAP-Finish message also can be used by the authenticator to announce the local domain name.
本文档中指定了两个EAP代码——EAP Initiate和EAP Finish——用于EAP重新认证。当对等方识别出支持EAP重新认证的目标认证器时，它将执行ERP交换，如图1所示；当对等方连接到支持EAP重新身份验证的新身份验证程序时，或在连接之前，交换本身可能发生。对等方自行发起ERP；它还可以响应来自新验证器的EAP Initiate/Re auth Start消息而这样做。EAP Initiate/Re auth Start消息允许验证器触发ERP交换。认证者还可以使用EAP Finish消息来宣布本地域名。
It is plausible that the authenticator does not know whether the peer supports ERP and whether the peer has performed a full EAP authentication through another authenticator. The authenticator MAY initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start message and if there is no response MAY send the EAP-Request/Identity message. Note that this avoids having two EAP messages in flight at the same time [RFC3748]. The authenticator may send the EAP-Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. This message indicates to the peer that the authenticator supports ERP. In response to this trigger from the authenticator, the peer can initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. If there is no response from the peer after the necessary number of retransmissions (see Section 6), the authenticator MUST initiate EAP by sending an EAP-Request message, typically the EAP-Request/Identity message. Note that the authenticator may receive an EAP-Initiate/Re-auth message after it has sent an EAP-Request/Identity message. If the authenticator
认证者不知道对等方是否支持ERP，以及对等方是否通过另一认证者执行了完整的EAP认证，这似乎是合理的。认证器可通过发送EAP initiate/Re auth Start消息来启动ERP交换，如果没有响应，则可发送EAP Request/Identity消息。请注意，这样可以避免同时传输两条EAP消息[RFC3748]。认证器可发送EAP Initiate/Re-auth Start消息并等待本地配置的短时间。此消息向对等方指示验证器支持ERP。为了响应来自认证器的该触发，对等方可以通过发送EAP initiate/Re-auth消息来启动ERP交换。如果在必要的重新传输次数之后没有来自对等方的响应（参见第6节），则认证者必须通过发送EAP请求消息（通常是EAP请求/标识消息）来启动EAP。注意，认证器在发送EAP请求/标识消息后可能会收到EAP启动/重新认证消息。如果验证者
supports ERP, it MUST proceed with the ERP exchange. When the EAP-Request/Identity times out, the authenticator MUST NOT close the connection if an ERP exchange is in progress or has already succeeded in establishing a re-authentication MSK.
支持ERP，必须进行ERP交换。当EAP请求/身份超时时，如果ERP交换正在进行或已成功建立重新身份验证MSK，则身份验证方不得关闭连接。
If the authenticator does not support ERP, it will silently discard EAP-Initiate/Re-auth messages (Section 5.3.2), since the EAP code of those packets is greater than 4 ([RFC3748], Section 4). An ERP-capable peer will exhaust the EAP-Initiate/Re-auth message retransmissions and fall back to EAP authentication by responding to EAP-Request/Identity messages from the authenticator. If the peer does not support ERP or if it does not have unexpired key material from a previous EAP authentication, it drops EAP-Initiate/ Re-auth-Start messages. If there is no response to the EAP-Initiate/ Re-auth-Start message, the authenticator SHALL send an EAP-Request message (typically EAP-Request/Identity) to start EAP authentication. From this point onward, RFC 3748 rules apply. Note that this may introduce some delay in starting EAP. In some lower layers, the delay can be minimized or even avoided by the peer initiating EAP by sending messages such as EAPoL-Start [IEEE_802.1X].
如果认证器不支持ERP，它将自动放弃EAP启动/重新认证消息（第5.3.2节），因为这些数据包的EAP代码大于4（[RFC3748]，第4节）。支持ERP的对等方将通过响应来自认证方的EAP请求/标识消息来耗尽EAP发起/重新认证消息的重新传输，并退回到EAP认证。如果对等方不支持ERP，或者没有来自先前EAP身份验证的未过期密钥材料，则会丢弃EAP Initiate/Re auth Start消息。如果EAP Initiate/Re auth Start消息没有响应，则认证者应发送EAP请求消息（通常为EAP请求/标识）以启动EAP认证。从这一点开始，RFC 3748规则适用。请注意，这可能会在启动EAP时引入一些延迟。在一些较低层中，对等方通过发送诸如EAPoL Start[IEEE_802.1X]之类的消息来发起EAP，可以最小化甚至避免延迟。
The peer sends an EAP-Initiate/Re-auth message that contains the keyName-NAI to identify the ER server's domain and the rIK used to protect the message, and a sequence number for replay protection. The EAP-Initiate/Re-auth message is integrity protected with the rIK. The authenticator uses the realm in the keyName-NAI field to send the message to the appropriate ER server. The server uses the keyName to look up the rIK. The server, after verifying proof of possession of the rIK and freshness of the message, derives an rMSK from the rRK using the sequence number as an input to the key derivation. The server then updates the expected sequence number to the received sequence number plus one.
对等方发送EAP Initiate/Re-auth消息，该消息包含用于标识ER服务器域和用于保护消息的rIK的密钥名NAI，以及用于重播保护的序列号。EAP Initiate/Re-auth消息受rIK的完整性保护。验证器使用keyName NAI字段中的域将消息发送到相应的ER服务器。服务器使用keyName来查找rIK。在验证rIK的拥有证明和消息的新鲜度之后，服务器使用序列号作为密钥派生的输入，从rRK派生一个rMSK。然后，服务器将预期序列号更新为接收到的序列号加1。
In response to the EAP-Initiate/Re-auth message, the server sends an EAP-Finish/Re-auth message; this message is integrity protected with the rIK. The server transports the rMSK along with this message to the authenticator. The rMSK is transported in a manner similar to that of the MSK along with the EAP-Success message in a full EAP exchange. Hoeper, et al. [RFC5749] discuss an additional key distribution protocol that can be used to transport the rRK from an EAP server to one of many different ER servers that share a trust relationship with the EAP server.
响应EAP启动/重新验证消息，服务器发送EAP完成/重新验证消息；此消息受rIK的完整性保护。服务器将rMSK与此消息一起传输到验证器。rMSK以类似于MSK的方式在完整EAP交换中与EAP成功消息一起传输。Hoeper等人[RFC5749]讨论了一种附加密钥分发协议，该协议可用于将rRK从EAP服务器传输到与EAP服务器共享信任关系的多个不同ER服务器之一。
The peer MAY request the rMSK lifetime from the server. If so, the ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message.
对等方可以从服务器请求rMSK生存期。如果是这样，ER服务器将在EAP Finish/Re-auth消息中发送rMSK生存期。
In an ERP bootstrap exchange, the peer MAY ask the server for the rRK lifetime. If so, the ER server sends the rRK lifetime in the EAP-Finish/Re-auth message.
在ERP引导交换中，对等方可能要求服务器提供rRK生存期。如果是，ER服务器将在EAP Finish/Re auth消息中发送rRK生存期。
The peer verifies the sequence number and the integrity of the message. It then uses the sequence number in the EAP-Finish/Re-auth message to compute the rMSK. The lower-layer security association protocol is ready to be triggered after this point.
对等方验证消息的序列号和完整性。然后，它使用EAP Finish/Re-auth消息中的序列号来计算rMSK。在这一点之后，可以触发下层安全关联协议。
The ER server is located either in the home domain or in the visited domain. When the ER server is in the home domain and there is no local ER server in the visited domain, the peer and the server use the rIK and rRK derived from the EMSK; and when the ER server is in the local domain, they use the DS-rIK and DS-rRK corresponding to the local domain. The domain of the ER server is identified by the realm portion of the keyName-NAI in ERP messages.
ER服务器位于主域或访问域中。当ER服务器在主域中并且在访问的域中没有本地ER服务器时，对等方和服务器使用从EMSK派生的rIK和rRK；当ER服务器在本地域中时，它们使用与本地域对应的DS rIK和DS rRK。ER服务器的域由ERP消息中的keyName NAI的realm部分标识。
If the peer is in the home domain or there is no local server in the same domain as the peer, it SHOULD initiate an ERP bootstrap exchange with the home ER server to obtain the domain name.
如果对等方在主域中，或者在与对等方相同的域中没有本地服务器，则应启动与主ER服务器的ERP引导交换以获取域名。
The defined ER extensions allow executing ERP with an ER server in the home domain. The home ER server may be co-located with a home Authentication, Authorization, and Accounting (AAA) server. ERP with the home ER server is similar to the ERP exchange described in Figure 1.
定义的ER扩展允许使用主域中的ER服务器执行ERP。家庭ER服务器可以与家庭认证、授权和计费（AAA）服务器位于同一位置。带有家庭ER服务器的ERP类似于图1中描述的ERP交换。
Peer ER Authenticator Home ER Server
==== ================ ==============
Peer ER Authenticator Home ER Server
==== ================ ==============
<-- EAP-Initiate/ -----
Re-auth-Start
[<-- EAP-Request/ ------
Identity]
<-- EAP-Initiate/ -----
Re-auth-Start
[<-- EAP-Request/ ------
Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
Bootstrap Bootstrap)
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
Bootstrap Bootstrap)
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
Bootstrap Bootstrap)
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
Bootstrap Bootstrap)
Figure 3: ER Explicit Bootstrapping Exchange/ERP with the Home ER Server
图3：ER显式引导Exchange/ERP与家庭ER服务器
The defined ER extensions allow the execution of ERP with an ER server in the local domain (access network) if the peer moves out of the home domain and a local ER server is present in the visited domain. The local ER server may be co-located with a local AAA server. The peer may learn about the presence of a local ER server in the network and the local domain name (or ER server name) either via a lower-layer advertisement or by means of an ERP exchange. The peer uses the domain name and the EMSK to compute the DSRK and, from that key, the DS-rRK; the peer also uses the domain name in the realm portion of the keyName-NAI for using ERP in the local domain. Figure 4 shows the ER implicit bootstrapping exchange through a local ER server; Figure 5 shows ERP with a local ER server.
定义的ER扩展允许在对等方移出主域且访问域中存在本地ER服务器的情况下，使用本地域（接入网络）中的ER服务器执行ERP。本地ER服务器可以与本地AAA服务器位于同一位置。对等方可以通过较低层广告或通过ERP交换来了解网络中本地ER服务器的存在和本地域名（或ER服务器名称）。对等方使用域名和EMSK计算DSRK，并根据该密钥计算DS rRK；对等方还使用keyName NAI领域部分中的域名在本地域中使用ERP。图4显示了通过本地ER服务器的ER隐式引导交换；图5显示了带有本地ER服务器的ERP。
EAP Authenticator Local AAA Agent
Peer /ER Authenticator /Local ER Server Home EAP Server
==== ================== ================ ===============
EAP Authenticator Local AAA Agent
Peer /ER Authenticator /Local ER Server Home EAP Server
==== ================== ================ ===============
<-- EAP-Request/ -- Identity
<--EAP请求/--标识
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity, --AAA(EAP Response/ -->
[domain name]) Identity,
[DSRK Request,
domain name])
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity, --AAA(EAP Response/ -->
[domain name]) Identity,
[DSRK Request,
domain name])
<------------------------ EAP Method exchange------------------>
<------------------------ EAP Method exchange------------------>
<---AAA(MSK, DSRK, ----
EMSKname,
EAP-Success)
<---AAA(MSK, DSRK, ----
EMSKname,
EAP-Success)
<--- AAA(MSK, -----
EAP-Success)
<--- AAA(MSK, -----
EAP-Success)
<---EAP-Success-----
<---EAP-Success-----
Figure 4: Implicit Bootstrapping ERP Exchange, Initial EAP Exchange
图4：隐式引导ERP交换，初始EAP交换
Peer ER Authenticator Local ER Server
==== ================ ===============
Peer ER Authenticator Local ER Server
==== ================ ===============
<-- EAP-Initiate/ --------
Re-auth-Start
[<-- EAP-Request/ ---------
Identity]
<-- EAP-Initiate/ --------
Re-auth-Start
[<-- EAP-Request/ ---------
Identity]
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
Re-auth Re-auth)
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
Re-auth Re-auth)
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth)
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth)
Figure 5: Local ERP Exchange
图5：本地ERP交换
As shown in Figure 4, the local ER server may be present in the path of the full EAP exchange (e.g., this may be one of the AAA entities, such as AAA proxies, in the path between the EAP authenticator and the home EAP server of the peer). In that case, the local ER server requests the DSRK by sending the domain name to the home EAP server by means of a AAA message. In response, the home EAP server computes the DSRK by following the procedure specified in RFC 5295 and sends the DSRK and the key name, EMSKname, to the ER server in the claimed domain (i.e., the local ER server). The local domain is responsible for announcing that same domain name to the peer via a lower layer (for example, through DHCP-based local domain name discovery [RFC6440] or through the EAP-Initiate/Re-auth-Start message with the local ER server).
如图4所示，本地ER服务器可能存在于完整EAP交换的路径中（例如，这可能是EAP验证器和对等方的家庭EAP服务器之间的路径中的AAA实体之一，例如AAA代理）。在这种情况下，本地ER服务器通过AAA消息将域名发送到家庭EAP服务器来请求DSRK。作为响应，家庭EAP服务器通过遵循RFC 5295中指定的过程来计算DSRK，并将DSRK和密钥名EMSKname发送到所声明域中的ER服务器（即本地ER服务器）。本地域负责通过较低层（例如，通过基于DHCP的本地域名发现[RFC6440]或通过本地ER服务器的EAP Initiate/Re auth Start消息）向对等方宣布相同的域名。
After receiving the DSRK and the EMSKname, the local ER server computes the DS-rRK and the DS-rIK from the DSRK as defined in Sections 4.1 and 4.3 below. After receiving the domain name, the peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys are referred to by a keyName-NAI formed as follows: the username part of the NAI is the EMSKname, and the realm portion of the NAI is the domain name. Both parties also maintain a sequence number (initialized to zero) corresponding to the specific keyName-NAI.
在接收到DSRK和EMSKname后，本地ER服务器根据下面第4.1节和第4.3节中定义的DSRK计算DS rRK和DS rIK。在收到域名后，对等方还派生DSRK、DS rRK和DS rIK。这些密钥由一个keyName NAI引用，其形式如下：NAI的用户名部分是EMSKname，而NAI的领域部分是域名。双方还维护一个与特定keyName NAI对应的序列号（初始化为零）。
If the peer subsequently attaches to an authenticator within the local domain, it may perform an ERP exchange with the local ER server to obtain an rMSK for the new authenticator. ERP with the local ER server is similar to the ERP exchange illustrated in Figure 1.
如果对等方随后连接到本地域内的验证器，则其可与本地ER服务器执行ERP交换以获得新验证器的rMSK。带有本地ER服务器的ERP类似于图1所示的ERP交换。
Each time the peer re-authenticates to the network, the peer and the authenticator establish an rMSK. The rMSK serves the same purposes that an MSK, which is the result of full EAP authentication, serves. To prove possession of the rRK, we specify the derivation of another key, the rIK. These keys are derived from the rRK. Together they constitute the ER key hierarchy.
每次对等方对网络进行重新认证时，对等方和认证方都会建立一个rMSK。rMSK的用途与MSK相同，MSK是完全EAP认证的结果。为了证明拥有rRK，我们指定了另一个密钥rIK的派生。这些密钥来自rRK。它们一起构成ER密钥层次结构。
The rRK is derived from either the EMSK or a DSRK as specified in Section 4.1. For the purpose of rRK derivation, this document specifies derivation of a Usage-Specific Root Key (USRK) or a Domain-Specific USRK (DSUSRK) [RFC5295] for re-authentication. The USRK designated for re-authentication is the rRK. A DSUSRK designated for re-authentication is the DS-rRK available to a local ER server in a particular domain. For simplicity, the keys are referred to without the DS label in the rest of the document. However, the scope of the various keys is limited to just the respective domains for which they are derived, in the case of the domain-specific keys. Based on the ER server with which the peer performs the ERP exchange, it knows the corresponding keys that must be used.
rRK源自第4.1节规定的EMSK或DSRK。出于rRK推导的目的，本文档规定了用于重新认证的特定于使用的根密钥（USRK）或特定于域的USRK（DSUSRK）[RFC5295]的推导。指定用于重新身份验证的USRK是rRK。指定用于重新身份验证的DSUSRK是特定域中本地ER服务器可用的DS rRK。为简单起见，在文档的其余部分中引用的键没有DS标签。然而，在域特定密钥的情况下，各种密钥的范围仅限于为其派生的各个域。基于对等方执行ERP交换的ER服务器，它知道必须使用的相应密钥。
The rRK is used to derive an rIK and rMSKs for one or more authenticators. The figure below shows the key hierarchy with the rRK, rIK, and rMSKs.
rRK用于导出一个或多个验证器的rIK和rMSKs。下图显示了带有rRK、rIK和RMSK的密钥层次结构。
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
Figure 6: Re-authentication Key Hierarchy
图6：重新验证密钥层次结构
The derivations in this document are from RFC 5295. Key derivations and field encodings, where unspecified, default to that document.
本文件中的衍生产品来自RFC 5295。未指定的键派生和字段编码默认为该文档。
The rRK may be derived from the EMSK or DSRK. This section provides the relevant key derivations for that purpose.
rRK可以从EMSK或DSRK中导出。本节提供了相关的关键衍生工具。
The rRK is derived as specified in RFC 5295.
rRK根据RFC 5295中的规定推导。
rRK = KDF (K, S), where
rRK=KDF（K，S），其中
K = EMSK or K = DSRK and
K=EMSK或K=DSRK和
S = rRK Label | "\0" | length
S=rRK标签|“\0”|长度
The rRK Label is an IANA-assigned 8-bit ASCII string:
rRK标签是IANA分配的8位ASCII字符串：
EAP Re-authentication Root Key@ietf.org
EAP重新身份验证根目录Key@ietf.org
assigned from the "USRK Key Labels" name space in accordance with the policy stated in RFC 5295.
根据RFC 5295中规定的政策，从“USRK密钥标签”名称空间分配。
The Key Derivation Function (KDF) and algorithm agility for the KDF are as defined in RFC 5295.
密钥派生函数（KDF）和KDF的算法敏捷性如RFC 5295中所定义。
An rRK derived from the DSRK is referred to as a DS-rRK in the rest of the document. All of the key derivation and properties specified in this section remain the same.
从DSRK派生的rRK在文档的其余部分中称为DS rRK。本节中指定的所有密钥派生和属性保持不变。
The rRK has the following properties. These properties apply to the rRK regardless of the parent key used to derive it.
rRK具有以下属性。无论用于派生rRK的父密钥是什么，这些属性都适用于rRK。
o The length of the rRK MUST be equal to the length of the parent key used to derive it.
o rRK的长度必须等于用于派生它的父密钥的长度。
o The rRK is to be used only as a root key for re-authentication and never used to directly protect any data.
o rRK仅用作重新身份验证的根密钥，从不用于直接保护任何数据。
o The rRK is only used for the derivation of the rIK and rMSK as specified in this document.
o rRK仅用于推导本文件规定的rIK和rMSK。
o The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity.
o rRK必须保留在对等机和派生它的服务器上，并且不得传输到任何其他实体。
o The lifetime of the rRK is never greater than that of its parent key. The rRK is expired when the parent key expires and MUST be removed from use at that time.
o rRK的生存期永远不会大于其父密钥的生存期。当父密钥过期时，rRK将过期，此时必须将其从使用中删除。
The rIK is used for integrity protecting the ERP exchange. This serves as the proof of possession of valid key material from a previous full EAP exchange by the peer to the server.
rIK用于保护ERP交换的完整性。这可作为对等方拥有服务器之前完整EAP交换的有效密钥材料的证明。
The rIK is derived as follows:
rIK的推导如下：
rIK = KDF (K, S), where
rIK=KDF（K，S），其中
K = rRK and
K = rRK and
S = rIK Label | "\0" | cryptosuite | length
S=rIK标签|“\0”|加密套件|长度
The rIK Label is the 8-bit ASCII string:
rIK标签是8位ASCII字符串：
Re-authentication Integrity Key@ietf.org
重新认证完整性Key@ietf.org
The length field refers to the length of the rIK in octets and is encoded as specified in RFC 5295.
长度字段是指rIK的长度（以八位字节为单位），并按照RFC 5295中的规定进行编码。
The cryptosuite and length of the rIK are part of the input to the KDF to ensure cryptographic separation of keys if different rIKs of different lengths (for example, for use with different Message Authentication Code (MAC) algorithms) are derived from the same rRK. The cryptosuite is encoded as an 8-bit number; see Section 5.3.2 for the cryptosuite specification.
如果不同长度的不同rIK（例如，用于不同的消息认证码（MAC）算法）来自同一rRK，则加密套件和rIK的长度是KDF输入的一部分，以确保密钥的加密分离。加密套件编码为8位数字；cryptosuite规范见第5.3.2节。
The rIK is referred to by the EMSKname-NAI within the context of ERP messages. The username part of the EMSKname-NAI is the EMSKname; the realm is the domain name of the ER server. In the case of ERP with the home ER server, the peer uses the realm from its original NAI; in the case of a local ER server, the peer uses the domain name received at the lower layer or through an ERP bootstrapping exchange.
rIK由EMSKname NAI在ERP消息上下文中引用。EMSKname NAI的用户名部分是EMSKname；领域是ER服务器的域名。对于带有家庭ER服务器的ERP，对等方使用其原始NAI中的域；对于本地ER服务器，对等方使用在较低层或通过ERP引导交换接收的域名。
An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All of the key derivation and properties specified in this section remain the same.
从DS rRK派生的rIK在文档的其余部分中称为DS rIK。本节中指定的所有密钥派生和属性保持不变。
The rIK has the following properties:
rIK具有以下特性：
o The length of the rIK MUST be equal to the length of the rRK.
o rIK的长度必须等于rRK的长度。
o The rIK is only used for authentication of the ERP exchange as specified in this document.
o rIK仅用于本文件规定的ERP交换验证。
o The rIK MUST NOT be used to derive any other keys.
o rIK不得用于派生任何其他关键点。
o The rIK must remain on the peer and the server and MUST NOT be transported to any other entity.
o rIK必须保留在对等机和服务器上，并且不得传输到任何其他实体。
o The rIK is cryptographically separate from any other keys derived from the rRK.
o rIK以加密方式与从rRK派生的任何其他密钥分离。
o The lifetime of the rIK is never greater than that of its parent key. The rIK MUST be expired when the EMSK expires and MUST be removed from use at that time.
o rIK的生存期永远不会大于其父密钥的生存期。当EMSK到期时，rIK必须到期，并且必须在该时间停止使用。
The rIK is the key the possession of which is demonstrated by the peer and the ERP server to the other party. The peer demonstrates possession of the rIK by computing the integrity checksum over the EAP-Initiate/Re-auth message. When the peer uses the rIK for the first time, it can choose the integrity algorithm to use with the rIK. The peer and the server MUST use the same integrity algorithm with a given rIK for all ERP messages protected with that key. The peer and the server store the algorithm information after the first use, and they employ the same algorithm for all subsequent uses of that rIK.
rIK是由对等方和ERP服务器向另一方证明其拥有的密钥。对等方通过计算EAP Initiate/Re-auth消息上的完整性校验和来证明其拥有rIK。当对等方第一次使用rIK时，它可以选择与rIK一起使用的完整性算法。对等方和服务器必须对使用该密钥保护的所有ERP消息使用具有给定rIK的相同完整性算法。对等方和服务器在第一次使用后存储算法信息，并且在该rIK的所有后续使用中使用相同的算法。
If the server's policy does not allow the use of the cryptosuite selected by the peer, the server SHALL reject the EAP-Initiate/ Re-auth message and SHOULD send a list of acceptable cryptosuites in the EAP-Finish/Re-auth message.
如果服务器的策略不允许使用对等方选择的加密套件，则服务器应拒绝EAP Initiate/Re-auth消息，并应在EAP Finish/Re-auth消息中发送可接受的加密套件列表。
The rIK length may be different from the key length required by an integrity algorithm. In the case of hash-based MAC algorithms, the key is first hashed to the required key length using the HMAC algorithm [RFC2104]. In the case of cipher-based MAC algorithms, if the required key length is less than 32 octets, the rIK is hashed using HMAC-SHA256 and the first k octets of the output are used, where k is the key length required by the algorithm. If the required key length is more than 32 octets, the first k octets of the rIK are used by the cipher-based MAC algorithm.
rIK长度可能不同于完整性算法所需的密钥长度。在基于散列的MAC算法的情况下，首先使用HMAC算法[RFC2104]将密钥散列到所需的密钥长度。在基于密码的MAC算法的情况下，如果所需密钥长度小于32个八位字节，则使用HMAC-SHA256对rIK进行散列，并使用输出的前k个八位字节，其中k是算法所需的密钥长度。如果所需密钥长度超过32个八位字节，则rIK的前k个八位字节由基于密码的MAC算法使用。
The rMSK is derived at the peer and server and delivered to the authenticator. The rMSK is derived following an ERP exchange.
rMSK在对等机和服务器上派生，并传递给验证器。rMSK是在ERP交换之后导出的。
The rMSK is derived as follows:
rMSK的推导如下：
rMSK = KDF (K, S), where
rMSK=KDF（K，S），其中
K = rRK and
K = rRK and
S = rMSK Label | "\0" | SEQ | length
S=rMSK标签|“\0”|序号|长度
The rMSK Label is the 8-bit ASCII string:
rMSK标签是8位ASCII字符串：
Re-authentication Master Session Key@ietf.org
重新验证主会话Key@ietf.org
The length field refers to the length of the rMSK in octets and is encoded as specified in RFC 5295.
长度字段指以八位字节为单位的rMSK的长度，并按照RFC 5295中的规定进行编码。
SEQ is the sequence number sent by the peer in the EAP-Initiate/ Re-auth message. This field is encoded as a 16-bit number in network byte order (see Section 5.3.2).
SEQ是对等方在EAP Initiate/Re auth消息中发送的序列号。该字段按网络字节顺序编码为16位数字（见第5.3.2节）。
An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. The key derivation and properties specified in this section remain the same.
从DS rRK派生的rMSK在文档的其余部分中称为DS rIK。本节中指定的密钥派生和属性保持不变。
The rMSK has the following properties:
rMSK具有以下属性：
o The length of the rMSK MUST be equal to the length of the rRK.
o rMSK的长度必须等于rRK的长度。
o The rMSK is delivered to the authenticator and is used for the same purposes that an MSK serves when the MSK is used at an authenticator.
o rMSK被交付给认证器，并用于与在认证器上使用MSK时MSK所服务的目的相同的目的。
o The rMSK is cryptographically separate from any other keys derived from the rRK.
o rMSK以加密方式与从rRK派生的任何其他密钥分离。
o The lifetime of the rMSK is less than or equal to that of the rRK. It MUST NOT be greater than the lifetime of the rRK.
o rMSK的寿命小于或等于rRK的寿命。它不得大于rRK的寿命。
o If a new rRK is derived, subsequent rMSKs MUST be derived from the new rRK. Previously delivered rMSKs MAY still be used until the expiry of the lifetime.
o 如果派生新的rRK，则必须从新的rRK派生后续的RMSK。之前交付的RMSK在使用寿命到期之前仍可使用。
o A given rMSK MUST NOT be shared by multiple authenticators.
o 给定的rMSK不能由多个身份验证程序共享。
We identify two types of bootstrapping for ERP: explicit and implicit. In implicit bootstrapping, the ER-capable authenticator or local ER server MUST verify whether it has a valid rMSK or rRK corresponding to the peer. If the ER-capable authenticator or the local ER server has the key material corresponding to the peer, it MUST be able to respond directly in the same way as the home AAA server does without forwarding the DSRK Request to the home domain;
我们确定了ERP的两种引导类型：显式引导和隐式引导。在隐式引导中，支持ER的验证器或本地ER服务器必须验证其是否具有与对等方对应的有效rMSK或rRK。如果具有ER能力的验证器或本地ER服务器具有对应于对等方的密钥材料，则其必须能够以与家庭AAA服务器相同的方式直接响应，而无需将DSRK请求转发到家庭域；
if not, the ER-capable authenticator or local ER server SHOULD include its domain name in the AAA message encapsulating the first EAP Response message sent by the peer and request the DSRK from the home EAP server during the initial EAP exchange. If such an EAP exchange is successful, the home EAP server sends the DSRK for the specified local AAA client or agent (derived using the EMSK and the domain name as specified in RFC 5295), EMSKname, and DSRK lifetime along with the EAP-Success message. The local AAA client or agent MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding the EAP-Success message to the peer. Note that the MSK (also present with the EAP-Success message) is extracted by the EAP authenticator as usual. The peer learns the domain name through the EAP-Initiate/Re-auth-Start message or by means of a lower-layer announcement (for example, DHCP [RFC6440]). When the domain name is available to the peer during or after the full EAP authentication, it attempts to use ERP when it associates with a new authenticator.
如果没有，支持ER的验证器或本地ER服务器应在AAA消息中包含其域名，该消息封装了对等方发送的第一个EAP响应消息，并在初始EAP交换期间从家庭EAP服务器请求DSRK。如果这样的EAP交换成功，家庭EAP服务器将发送指定的本地AAA客户端或代理（使用EMSK和RFC 5295中指定的域名派生）、EMSKname和DSRK生存期的DSRK以及EAP成功消息。在将EAP成功消息转发给对等方之前，本地AAA客户端或代理必须提取DSRK、EMSKname和DSRK生存期（如果存在）。请注意，MSK（与EAP成功消息一起出现）通常由EAP验证器提取。对等方通过EAP Initiate/Re-auth Start消息或通过下层公告（例如，DHCP[RFC6440]）来学习域名。当域名在完整EAP身份验证期间或之后可供对等方使用时，它会在与新身份验证程序关联时尝试使用ERP。
If the peer knows there is no local ER server present in the visited domain, it SHOULD initiate ERP explicit bootstrapping (ERP exchange with the bootstrap flag turned on) with the home ER server to obtain the rRK. The peer MAY also initiate bootstrapping to fetch information such as the rRK lifetime from the AAA server.
如果对等方知道访问的域中不存在本地ER服务器，则应与家庭ER服务器启动ERP显式引导（启用引导标志的ERP交换），以获取rRK。对等方还可以启动引导以从AAA服务器获取诸如rRK生存期之类的信息。
The following steps describe the ERP explicit bootstrapping process:
以下步骤描述了ERP显式引导过程：
o The peer sends the EAP-Initiate/Re-auth message with the bootstrapping flag set (1). The bootstrap message is always sent to the home ER server, and the keyName-NAI attribute in the bootstrap message is constructed as follows: the username portion of the NAI contains the EMSKname, and the realm portion contains the home domain name.
o 对等方发送设置了引导标志（1）的EAP Initiate/Re-auth消息。引导消息始终发送到家庭ER服务器，引导消息中的keyName NAI属性构造如下：NAI的username部分包含EMSKname，realm部分包含家庭域名。
o In addition, the message MUST contain a sequence number for replay protection, a cryptosuite, and an integrity checksum. The cryptosuite indicates the authentication algorithm. The integrity checksum indicates that the message originated at the claimed entity, the peer indicated by the Peer-ID, or the rIKname.
o 此外，消息必须包含用于重播保护的序列号、加密套件和完整性校验和。cryptosuite指示身份验证算法。完整性校验和表示消息源于声明的实体、由对等ID指示的对等方或rIKname。
o The peer MAY additionally set the lifetime flag to request the key lifetimes.
o 对等方可另外设置生存期标志以请求密钥生存期。
o Upon receipt of the EAP-Initiate/Re-auth message from a peer, the ERP-capable authenticator verifies whether it has the local domain name and valid key material corresponding to the peer. If it knows the local domain name and has valid key material corresponding to the peer, it MUST be able to respond directly in the same way as the home ER does, with the local domain name included. If not, it copies the contents of the keyName-NAI into
o 在收到来自对等方的EAP Initiate/Re auth消息后，支持ERP的验证器验证其是否具有与对等方对应的本地域名和有效密钥材料。如果它知道本地域名，并且拥有与对等方对应的有效密钥材料，那么它必须能够以与家庭ER相同的方式直接响应，包括本地域名。如果没有，它会将keyName NAI的内容复制到
the appropriate AAA attribute and may include its domain name in the AAA message encapsulating the EAP-Initiate/Re-auth message sent by the peer.
适当的AAA属性，并且可以在封装对等方发送的EAP Initiate/Re-auth消息的AAA消息中包括其域名。
o Upon receipt of an EAP-Initiate/Re-auth message, the home ER server verifies whether the message is fresh or is a replay by evaluating whether the received sequence number is equal to or greater than the expected sequence number for that rIK. The home ER server then verifies that the cryptosuite used by the peer is acceptable. Next, it verifies the integrity of the message by looking up the rIK and checking the integrity checksum contained in the Authentication Tag field. If any of the checks fail, the home ER server sends an EAP-Finish/Re-auth message with the Result flag set to '1'. Please refer to Section 5.2.2 for details on failure handling. This error MUST NOT have any correlation to any EAP-Success message that may have been received by the EAP authenticator and the peer earlier. If the EAP-Initiate/Re-auth message is well formed and valid, the server prepares the EAP-Finish/Re-auth message. The bootstrap flag MUST be set to indicate that this is a bootstrapping exchange. The message contains the following fields:
o 在接收到EAP Initiate/Re-auth消息后，家庭ER服务器通过评估接收到的序列号是否等于或大于该rIK的预期序列号来验证该消息是新消息还是重播。然后，家庭ER服务器验证对等方使用的加密套件是否可接受。接下来，它通过查找rIK并检查Authentication Tag字段中包含的完整性校验和来验证消息的完整性。如果任何检查失败，家庭ER服务器将发送一条EAP Finish/Re auth消息，其结果标志设置为“1”。有关故障处理的详细信息，请参阅第5.2.2节。此错误不得与EAP验证器和对等方先前接收到的任何EAP成功消息有任何关联。如果EAP Initiate/Re-auth消息格式正确且有效，服务器将准备EAP Finish/Re-auth消息。必须设置引导标志以指示这是一个引导交换。该消息包含以下字段：
* A sequence number for replay protection.
* 用于重播保护的序列号。
* The same keyName-NAI as in the EAP-Initiate/Re-auth message.
* 与EAP Initiate/Re auth消息中的密钥名NAI相同。
* If the lifetime flag was set in the EAP-Initiate/Re-auth message, the ER server SHOULD include the rRK lifetime and the rMSK lifetime in the EAP-Finish/Re-auth message. The server may have a local policy for the network to maintain and enforce lifetime unilaterally. In such cases, the server need not respond to the peer's request for the lifetime.
* 如果在EAP Initiate/Re-auth消息中设置了生存期标志，则ER服务器应在EAP Finish/Re-auth消息中包括rRK生存期和rMSK生存期。服务器可能具有用于网络的本地策略，以单方面维护和实施生存期。在这种情况下，服务器在生命周期内不需要响应对等方的请求。
* If the bootstrap flag is set, the ER server MUST include the domain name to which the DSRK is being sent along with the EAP-Finish/Re-auth message.
* 如果设置了引导标志，ER服务器必须包括DSRK发送到的域名以及EAP Finish/Re auth消息。
* If the ER server verifies the authorization of a local ER server, it MAY include the Authorization Indication TLV to indicate to the peer that the server that received the DSRK and that is advertising the domain included in the Domain name TLV is authorized.
* 如果ER服务器验证本地ER服务器的授权，则其可以包括授权指示TLV，以向对等方指示接收DSRK并且正在公布包括在域名TLV中的域的服务器被授权。
* An authentication tag MUST be included to prove that the EAP-Finish/Re-auth message originates at a server that possesses the rIK corresponding to the EMSKname-NAI.
* 必须包括身份验证标签，以证明EAP Finish/Re auth消息源自拥有与EMSKname NAI对应的rIK的服务器。
o If the home ER server is involved in the ERP exchange and the ERP exchange is successful, the home ER server SHOULD request the DSRK from the home EAP server; the home EAP server MUST provide the DSRK for the home ER server (derived using the EMSK and the domain name as specified in RFC 5295), EMSKname, and DSRK lifetime for inclusion in the AAA message. The home ER server SHOULD obtain them before sending the EAP-Finish/Re-auth message.
o 如果家庭ER服务器参与ERP交换且ERP交换成功，则家庭ER服务器应从家庭EAP服务器请求DSRK；家庭EAP服务器必须提供家庭ER服务器的DSRK（使用RFC 5295中指定的EMSK和域名派生）、EMSKname和DSRK生存期，以便包含在AAA消息中。在发送EAP Finish/Re-auth消息之前，家庭ER服务器应该获取它们。
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth message in a AAA attribute (for an example, see Bournelle, et al. [DIAMETER-ERP]).
o 此外，rMSK与AAA属性中的EAP Finish/Re auth消息一起发送（例如，请参阅Bournelle等人[DIAMETER-ERP]）。
o The authenticator receives the rMSK.
o 验证器接收rMSK。
o When the peer receives an EAP-Finish/Re-auth message with the bootstrap flag set, if a local domain name is present, it MUST use that name to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-NAI, and initialize the replay counter for the DS-rIK. If not, the peer SHOULD derive the domain-specific keys using the domain name it learned via the lower layer or from the EAP-Initiate/Re-auth-Start message. If the peer does not know the domain name, it must assume that there is no local ER server available.
o 当对等方接收到设置了引导标志的EAP Finish/Re auth消息时，如果存在本地域名，则必须使用该名称派生适当的DSRK、DS rRK、DS rIK和keyName NAI，并初始化DS rIK的重播计数器。如果没有，对等方应使用通过较低层或从EAP Initiate/Re-auth Start消息了解到的域名派生特定于域的密钥。如果对等方不知道域名，则必须假定没有可用的本地ER服务器。
o The peer MAY also verify the Authorization Indication TLV.
o 对等方还可以验证授权指示TLV。
o The procedures for encapsulating ERP and obtaining relevant keys using Diameter are specified in Bournelle, et al. [DIAMETER-ERP].
o Bournelle等人[Diameter-ERP]中规定了封装ERP和使用Diameter获取相关密钥的程序。
Since the ER bootstrapping exchange is typically done immediately following the full EAP exchange, it is feasible that the process is completed through the same entity that served as the EAP authenticator for the full EAP exchange. In this case, the lower layer may already have established TSKs based on the MSK received earlier. The lower layer may then choose to ignore the rMSK that was received with the ER bootstrapping exchange. Alternatively, the lower layer may choose to establish a new TSK using the rMSK. In either case, the authenticator and the peer know which key is used based on whether or not a TSK establishment exchange is initiated. The bootstrapping exchange may also be carried out via a new authenticator, in which case, the rMSK received SHOULD trigger a lower-layer TSK establishment exchange.
由于ER引导交换通常在完整EAP交换之后立即完成，因此该过程可以通过充当完整EAP交换的EAP验证器的相同实体完成。在这种情况下，较低层可能已经基于先前接收到的MSK建立了tsk。然后，较低层可以选择忽略ER引导交换接收的rMSK。或者，较低层可以选择使用rMSK建立新的TSK。在任何一种情况下，验证器和对等方都根据是否发起了TSK建立交换来知道使用了哪个密钥。引导交换也可以通过新的验证器来执行，在这种情况下，接收到的rMSK应该触发较低层的TSK建立交换。
When a peer that has an active rRK and rIK associates with a new authenticator that supports ERP, it may perform an ERP exchange with that authenticator. ERP is typically a peer-initiated exchange,
当具有活动rRK和rIK的对等方与支持ERP的新验证器关联时，它可以与该验证器执行ERP交换。ERP通常是由对等方发起的交换，
consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth message. The ERP exchange may be performed with a local ER server (when one is present) or with the original EAP server.
由EAP启动/重新验证和EAP完成/重新验证消息组成。ERP交换可以与本地ER服务器（如果存在）或原始EAP服务器一起执行。
It is plausible for the network to trigger the EAP re-authentication process, however. An ERP-capable authenticator SHOULD send an EAP-Initiate/Re-auth-Start message to indicate support for ERP. The peer may or may not wait for these messages to arrive to initiate the EAP-Initiate/Re-auth message.
然而，网络触发EAP重新认证过程似乎是合理的。具有ERP功能的验证器应发送EAP Initiate/Re auth Start消息，以指示对ERP的支持。对等方可以等待也可以不等待这些消息到达，以启动EAP initiate/Re-auth消息。
The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP-capable authenticator. The authenticator may retransmit it a few times until it receives an EAP-Initiate/Re-auth message in response from the peer. The EAP-Initiate/Re-auth message from the peer may have originated before the peer receives either an EAP-Request/ Identity or an EAP-Initiate/Re-auth-Start message from the authenticator. Hence, the Identifier value in the EAP-Initiate/ Re-auth message is independent of the Identifier value in the EAP-Initiate/Re-auth-Start or EAP-Request/Identity messages.
EAP Initiate/Re auth Start（EAP启动/重新验证启动）消息应由支持ERP的验证器发送。验证器可以重新传输它几次，直到它收到来自对等方的EAP Initiate/Re auth消息作为响应。来自对等方的EAP Initiate/Re-auth消息可能是在对等方从验证器接收到EAP请求/标识或EAP Initiate/Re-auth Start消息之前发出的。因此，EAP Initiate/Re-auth消息中的标识符值独立于EAP Initiate/Re-auth Start或EAP Request/Identity消息中的标识符值。
Operational Considerations at the Peer:
同行的操作注意事项：
ERP requires that the peer maintain retransmission timers for reliable transport of EAP re-authentication messages. The reliability considerations of Section 4.3 of RFC 3748 apply with the peer as the retransmitting entity.
ERP要求对等方维护重传计时器，以可靠传输EAP重新认证消息。RFC 3748第4.3节的可靠性考虑适用于对等方作为重传实体。
ERP has the following steps:
ERP有以下步骤：
o The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start message to trigger the ERP exchange.
o 支持ERP的验证器发送EAP Initiate/Re auth Start消息以触发ERP交换。
o The peer sends an EAP-Initiate/Re-auth message. At a minimum, the message SHALL include the following fields:
o 对等方发送EAP启动/重新验证消息。信息至少应包括以下字段：
* a 16-bit sequence number for replay protection.
* 用于重播保护的16位序列号。
* keyName-NAI as a TLV attribute to identify the rIK used to integrity protect the message.
* keyName NAI作为TLV属性，用于标识用于保护消息完整性的rIK。
* cryptosuite to indicate the authentication algorithm used to compute the integrity checksum.
* cryptosuite，指示用于计算完整性校验和的身份验证算法。
* authentication tag computed over the message.
* 通过消息计算的身份验证标记。
o When the peer is performing ERP with a local ER server, it MUST use the corresponding DS-rIK it shares with the local ER server. The peer SHOULD set the lifetime flag to request the key lifetimes
o 当对等方使用本地ER服务器执行ERP时，它必须使用与本地ER服务器共享的相应DS rIK。对等方应设置生存期标志以请求密钥生存期
from the server. The peer can use the rRK lifetime to know when to trigger an EAP method exchange and the rMSK lifetime to know when to trigger another ERP exchange.
从服务器。对等方可以使用rRK生存期来知道何时触发EAP方法交换，使用rMSK生存期来知道何时触发另一个ERP交换。
o The authenticator copies the contents of the value field of the keyName-NAI TLV into an appropriate attribute (e.g., User-Name [RFC2865]) in the AAA message to the ER server.
o 验证器将keyName NAI TLV的值字段的内容复制到AAA消息中的适当属性（例如，用户名[RFC2865]）中，并发送到ER服务器。
o The ER server uses the keyName-NAI to look up the rIK. It MUST first verify whether the sequence number is equal to or greater than the expected sequence number. If the ER server supports a sequence number window size greater than 1, it MUST verify whether the sequence number falls within the window and has not been received before. The ER server MUST then verify that the cryptosuite used by the peer is acceptable. The ER server then proceeds to verify the integrity of the message using the rIK, thereby verifying proof of possession of that key by the peer. If any of these verifications fail, the ER server MUST send an EAP-Finish/Re-auth message with the Result flag set to '1' (Failure). Please refer to Section 5.2.2 for details on failure handling. Otherwise, it MUST compute an rMSK from the rRK using the sequence number as the additional input to the key derivation.
o ER服务器使用keyName NAI来查找rIK。它必须首先验证序列号是否等于或大于预期序列号。如果ER服务器支持大于1的序列号窗口大小，则必须验证序列号是否在该窗口内，并且之前是否未收到该序列号。ER服务器必须验证对等方使用的加密套件是否可接受。ER服务器然后使用rIK继续验证消息的完整性，从而验证对等方拥有该密钥的证据。如果这些验证中的任何一个失败，ER服务器必须发送EAP Finish/Re auth消息，其结果标志设置为“1”（失败）。有关故障处理的详细信息，请参阅第5.2.2节。否则，它必须使用序列号作为密钥派生的附加输入，从rRK计算rMSK。
o In response to a well-formed EAP-Initiate/Re-auth message, the ER server MUST send an EAP-Finish/Re-auth message with the following contents:
o 为了响应格式良好的EAP Initiate/Re-auth消息，ER服务器必须发送包含以下内容的EAP Finish/Re-auth消息：
* a 16-bit sequence number for replay protection, which MUST be the same as the received sequence number. The local copy of the sequence number MUST be incremented by 1. If the ER server supports multiple simultaneous ERP exchanges, it MUST instead update the sequence number window.
* 用于重播保护的16位序列号，必须与接收到的序列号相同。序列号的本地副本必须增加1。如果ER服务器支持多个同时的ERP交换，则必须更新序列号窗口。
* keyName-NAI as a TLV attribute to identify the rIK used to integrity protect the message.
* keyName NAI作为TLV属性，用于标识用于保护消息完整性的rIK。
* cryptosuite to indicate the authentication algorithm used to compute the integrity checksum.
* cryptosuite，指示用于计算完整性校验和的身份验证算法。
* authentication tag computed over the message.
* 通过消息计算的身份验证标记。
* If the lifetime flag was set in the EAP-Initiate/Re-auth message, the ER server SHOULD include the rRK lifetime and the rMSK lifetime.
* 如果在EAP Initiate/Re-auth消息中设置了生存期标志，则ER服务器应包括rRK生存期和rMSK生存期。
o The ER server causes the rMSK along with this message to be transported to the authenticator. The rMSK is transported in a manner similar to the MSK and the EAP-Success message in a regular EAP exchange.
o ER服务器使rMSK连同此消息一起传输到验证器。rMSK的传输方式类似于常规EAP交换中的MSK和EAP成功消息。
o The peer looks up the sequence number to verify whether it is expecting an EAP-Finish/Re-auth message with that sequence number protected by the keyName-NAI. It then verifies the integrity of the message. If the verifications fail, the peer logs an error and stops the process; otherwise, it proceeds to the next step.
o 对等方查找序列号以验证是否期望EAP Finish/Re auth消息，该序列号受keyName NAI保护。然后验证消息的完整性。如果验证失败，对等方记录错误并停止该过程；否则，将进入下一步。
o The peer uses the sequence number to compute the rMSK.
o 对等方使用序列号来计算rMSK。
o The lower-layer security association protocol can be triggered at this point.
o 此时可以触发下层安全关联协议。
When a peer is within the range of multiple authenticators, it may choose to run ERP via all of them simultaneously to the same ER server. In that case, it is plausible that the ERP messages may arrive out of order, resulting in the ER server rejecting legitimate EAP-Initiate/Re-auth messages.
当一个对等方在多个验证器的范围内时，它可以选择通过所有验证器同时运行ERP到同一个ER服务器。在这种情况下，ERP消息可能会无序到达，导致ER服务器拒绝合法的EAP Initiate/Re-auth消息。
To facilitate such operation, an ER server MAY allow multiple simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth messages with sequence number values within a window of allowed values. Recall that the sequence number allows replay protection. Replay window maintenance mechanisms are a local matter.
为了促进这样的操作，ER服务器可以通过在允许值窗口内接受具有序列号值的所有EAP Initiate/Re auth消息来允许多个同时的ERP交换。回想一下，序列号允许重播保护。重播窗口维护机制是本地事务。
If the processing of the EAP-Initiate/Re-auth message results in a failure, the ER server MUST send an EAP-Finish/Re-auth message with the Result flag set to '1'. If the server has a valid rIK for the peer, it MUST integrity protect the EAP-Finish/Re-auth failure message. If the failure is due to an unacceptable cryptosuite, the server SHOULD send a list of acceptable cryptosuites (in a TLV of Type 5) along with the EAP-Finish/Re-auth message. In this case, the server MUST indicate the cryptosuite used to protect the EAP-Finish/ Re-auth message in the Cryptosuite field of that message. The rIK used with the EAP-Finish/Re-auth message in this case MUST be computed as specified in Section 4.3 using the new cryptosuite. If the server does not have a valid rIK for the peer, the EAP-Finish/ Re-auth message indicating a failure will be unauthenticated; the server MAY include a list of acceptable cryptosuites in the message.
如果EAP Initiate/Re-auth消息的处理导致失败，ER服务器必须发送结果标志设置为“1”的EAP Finish/Re-auth消息。如果服务器具有对等方的有效rIK，则必须完整性保护EAP完成/重新验证失败消息。如果失败是由于不可接受的cryptosuite造成的，则服务器应发送可接受的cryptosuite列表（在类型为5的TLV中）以及EAP Finish/Re auth消息。在这种情况下，服务器必须在该消息的cryptosuite字段中指明用于保护EAP Finish/Re auth消息的cryptosuite。在这种情况下，与EAP Finish/Re auth消息一起使用的rIK必须使用新的cryptosuite按照第4.3节的规定进行计算。如果服务器没有对等方的有效rIK，则表示失败的EAP Finish/Re auth消息将未经验证；服务器可以在消息中包括可接受的加密套件的列表。
The peer, upon receiving an EAP-Finish/Re-auth message with the Result flag set to '1', MUST verify the sequence number and, if possible, the authentication tag to determine the validity of the message. If the peer supports the cryptosuite, it MUST verify the integrity of the received EAP-Finish/Re-auth message. If the EAP-Finish message contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with a cryptosuite picked from the list included by the server. The peer MUST use the appropriate rIK for the subsequent ERP exchange by computing it with the corresponding cryptosuite, as specified in Section 4.3. If the Pseudo-Random Function (PRF) in the chosen cryptosuite is different from the PRF originally used by the peer, it MUST derive a new DSRK (if required), rRK, and rIK before proceeding with the subsequent ERP exchange.
对等方在收到结果标志设置为“1”的EAP Finish/Re auth消息时，必须验证序列号，如果可能，还必须验证身份验证标签，以确定消息的有效性。如果对等方支持cryptosuite，则必须验证收到的EAP Finish/Re-auth消息的完整性。如果EAP Finish消息包含类型为5的TLV，则对等方应使用从服务器包含的列表中选择的加密套件重试ERP交换。对等方必须按照第4.3节的规定，通过使用相应的cryptosuite计算相应的rIK，为后续ERP交换使用适当的rIK。如果所选cryptosuite中的伪随机函数（PRF）与对等方最初使用的PRF不同，则必须在继续后续ERP交换之前派生新的DSRK（如果需要）、rRK和rIK。
If the peer cannot verify the integrity of the received message, it MAY choose to retry the ERP exchange with one of the cryptosuites in the list of acceptable cryptosuites (in a TLV of Type 5), after a failure has been clearly determined following the procedure in the next paragraph.
如果对等方无法验证接收到的消息的完整性，它可以选择在按照下一段中的程序明确确定故障后，与可接受加密套件列表中的一个加密套件（在类型5的TLV中）重试ERP交换。
If the replay or integrity checks fail, the failure message may have been sent by an attacker. It may also mean that the server and peer do not support the same cryptosuites; however, the peer cannot determine if that is the case. Hence, the peer SHOULD continue the ERP exchange per the retransmission timers before declaring a failure.
如果重播或完整性检查失败，则失败消息可能是由攻击者发送的。这也可能意味着服务器和对等方不支持相同的加密套件；但是，对等方无法确定是否是这种情况。因此，在宣布失败之前，对等方应根据重传计时器继续ERP交换。
When the peer runs explicit bootstrapping (ERP with the bootstrapping flag on), there may not be a local ER server available to send a DSRK Request and the domain name. In that case, the server cannot send the DSRK and MUST NOT include the Domain name TLV. When the peer receives a response in the bootstrapping exchange without a Domain name TLV, it assumes that there is no local ER server. The home ER server sends an rMSK to the ER authenticator, however, and the peer SHALL run the TSK establishment protocol as usual.
当对等机运行显式引导（启用引导标志的ERP）时，可能没有本地ER服务器可用于发送DSRK请求和域名。在这种情况下，服务器无法发送DSRK，并且不能包含域名TLV。当对等方在引导exchange中收到没有域名TLV的响应时，它假定没有本地ER服务器。然而，家庭ER服务器向ER认证器发送rMSK，对等方应像往常一样运行TSK建立协议。
Two EAP codes are defined for the purpose of ERP: EAP-Initiate and EAP-Finish. The packet format for these messages follows the EAP packet format defined in Aboba, et al. [RFC3748].
为ERP的目的定义了两个EAP代码：EAP Initiate和EAP Finish。这些消息的数据包格式遵循Aboba等人[RFC3748]中定义的EAP数据包格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-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 | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: EAP Packet
图7:EAP数据包
Code
密码
Two code values are defined for the purpose of ERP:
为ERP的目的定义了两个代码值：
5 Initiate
5发起
6 Finish
6完成
Identifier
标识符
The Identifier field is one octet. The Identifier field MUST be the same if an EAP-Initiate packet is retransmitted due to a timeout while waiting for an EAP-Finish message. Any new (non-retransmission) EAP-Initiate message MUST use a new Identifier field.
标识符字段是一个八位字节。如果在等待EAP完成消息时由于超时而重新传输EAP Initiate数据包，则标识符字段必须相同。任何新的（非重传）EAP Initiate消息必须使用新的标识符字段。
The Identifier field of the EAP-Finish message MUST match that of the currently outstanding EAP-Initiate message. A peer or authenticator receiving an EAP-Finish message whose Identifier value does not match that of the currently outstanding EAP-Initiate message MUST silently discard the packet.
EAP完成消息的标识符字段必须与当前未完成的EAP启动消息的标识符字段匹配。接收到其标识符值与当前未完成的EAP Initiate消息的标识符值不匹配的EAP Finish消息的对等方或身份验证方必须以静默方式丢弃该数据包。
In order to avoid confusion between new EAP-Initiate messages and retransmissions, the peer must choose an Identifier value that is different from the previous EAP-Initiate message, especially if that exchange has not finished. It is RECOMMENDED that the authenticator clear EAP Re-auth state after 300 seconds.
为了避免新EAP Initiate消息和重传之间的混淆，对等方必须选择一个不同于先前EAP Initiate消息的标识符值，尤其是在交换尚未完成的情况下。建议验证器在300秒后清除EAP重新验证状态。
Type
类型
This field indicates that this is an ERP exchange. Two type values are defined in this document for this purpose -- Re-auth-Start (Type 1) and Re-auth (Type 2).
此字段表示这是ERP交换。为此，本文档中定义了两个类型值——重新验证开始（类型1）和重新验证（类型2）。
Type-Data
类型数据
The Type-Data field varies according to the value of the Type field in the re-authentication packet.
类型数据字段根据重新认证数据包中类型字段的值而变化。
The EAP-Initiate/Re-auth-Start packet contains the fields shown in Figure 8.
EAP Initiate/Re auth Start数据包包含图8所示的字段。
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 | 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 | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EAP-Initiate/Re-auth-Start Packet
图8:EAP启动/重新验证启动数据包
Type = 1.
类型=1。
Reserved: MUST be zero. Set to zero on transmission and ignored on reception.
保留：必须为零。传输时设置为零，接收时忽略。
One or more Type/Values (TVs) or TLVs are used to convey information to the peer; for instance, the authenticator may send the domain name to the peer.
一个或多个类型/值（tv）或tlv用于向对等方传送信息；例如，认证者可以向对等方发送域名。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets.
TVs或TLV：在TV有效载荷中，有一个1-octet类型的有效载荷和一个具有特定类型长度的值。在TLV有效载荷中，有一个1-octet类型的有效载荷和一个1-octet长度的有效载荷。长度字段表示以八位字节数表示的值的长度。
Domain name: This is a TLV payload. The Type is 4. The domain name is to be used as the realm in an NAI [RFC4282]. The Domain name TLV SHOULD be present in an EAP-Initiate/ Re-auth-Start message.
域名：这是TLV有效载荷。类型是4。域名将用作NAI[RFC4282]中的领域。域名TLV应出现在EAP Initiate/Re-auth Start消息中。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 12 for parameter specification.
此外，可以包括信道绑定信息；有关讨论，请参见第5.5节。参数规格见图12。
In order to minimize ERP failure times, the authenticator SHOULD send the EAP-Initiate/Re-auth-Start message to indicate support for ERP to the peer and to initiate ERP if the peer has already performed full EAP authentication and has unexpired key material. The authenticator SHOULD include the Domain name TLV to allow the peer to learn it without requiring either lower-layer support or the ERP bootstrapping exchange.
为了尽量减少ERP故障时间，认证者应向对等方发送EAP Initiate/Re auth Start（EAP启动/重新认证启动）消息，以指示对ERP的支持，并在对等方已执行完整EAP认证且密钥材料未过期时启动ERP。认证器应包括域名TLV，以允许对等方在不需要较低层支持或ERP引导交换的情况下学习该域名。
The authenticator MAY include channel binding information so that the server can verify whether the authenticator is claiming the same identity to both parties.
认证器可以包括信道绑定信息，以便服务器可以验证认证器是否向双方声明相同的身份。
The authenticator MAY retransmit the EAP-Initiate/Re-auth-Start message a few times for reliable transport.
验证器可以重新传输EAP Initiate/Re auth Start消息几次，以实现可靠传输。
The peer SHOULD send the EAP-Initiate/Re-auth message in response to the EAP-Initiate/Re-auth-Start message from the authenticator. If the peer does not recognize the EAP-Initiate code value or if the peer has already sent the EAP-Initiate/Re-auth message to begin the ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start message.
对等方应发送EAP Initiate/Re-auth消息，以响应来自验证器的EAP Initiate/Re-auth Start消息。如果对等方不识别EAP Initiate code值，或者如果对等方已发送EAP Initiate/Re auth消息以开始ERP交换，则必须以静默方式放弃EAP Initiate/Re auth Start消息。
If the EAP-Initiate/Re-auth-Start message contains the domain name, and if the peer does not already have the domain information, the peer SHOULD use the domain name contained in the message to compute the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/ Re-auth message to start an ERP exchange with the local ER server. If there is a local ER server between the peer and the home ER server and the peer has already initiated an ERP exchange with the local ER server, it SHOULD NOT start an ERP exchange with the home ER server.
如果EAP Initiate/Re-auth Start消息包含域名，并且如果对等方还没有域信息，则对等方应使用消息中包含的域名计算DSRK，并使用相应的DS rIK发送EAP Initiate/Re-auth消息，以启动与本地ER服务器的ERP交换。如果对等方和家庭ER服务器之间存在本地ER服务器，并且对等方已启动与本地ER服务器的ERP交换，则不应启动与家庭ER服务器的ERP交换。
The EAP-Initiate/Re-auth packet contains the parameters shown in Figure 9.
EAP Initiate/Re-auth数据包包含图9所示的参数。
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|B|L| Reserved| 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|B|L| Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: EAP-Initiate/Re-auth Packet
图9:EAP启动/重新验证数据包
Type = 2.
类型=2。
Flags
旗帜
'R' - The R flag is set to 0 and ignored upon reception.
“R”-R标志设置为0，并在接收时忽略。
'B' - The B flag is used as the bootstrapping flag. If the flag is turned on, the message is a bootstrap message.
“B”-B标志用作引导标志。如果该标志已打开，则该消息为引导消息。
'L' - The L flag is used to request the key lifetimes from the server.
“L”-L标志用于从服务器请求密钥生存期。
The remaining 5 bits are set to 0 on transmission and ignored on reception.
其余5位在传输时设置为0，在接收时忽略。
SEQ: An unsigned 16-bit sequence number is used for replay protection. The SEQ field is initialized to 0 every time a new rRK is derived. The field is encoded in network byte order.
SEQ：无符号16位序列号用于重播保护。每次导出新的rRK时，SEQ字段初始化为0。该字段按网络字节顺序编码。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets.
TVs或TLV：在TV有效载荷中，有一个1-octet类型的有效载荷和一个具有特定类型长度的值。在TLV有效载荷中，有一个1-octet类型的有效载荷和一个1-octet长度的有效载荷。长度字段表示以八位字节数表示的值的长度。
keyName-NAI: This is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in
keyName NAI：这是在TLV有效载荷中携带的。类型是1。NAI长度可变，不超过253个八位字节。EMSKname位于NAI的用户名部分，并以十六进制值编码。EMSKname的长度为64位
length, and so the username portion takes up 16 octets. If the rIK is derived from the EMSK, the realm part of the NAI is the home domain name, and if the rIK is derived from a DSRK, the realm part of the NAI is the domain name used in the derivation of the DSRK. The NAI syntax is specified in Aboba, et al. [RFC4282]. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet.
长度，因此用户名部分占16个八位字节。如果rIK来自EMSK，则NAI的领域部分是主域名，如果rIK来自DSRK，则NAI的领域部分是DSRK派生中使用的域名。NAI语法在Aboba等人[RFC4282]中有详细说明。EAP Initiate/Re-auth数据包中应仅存在一个keyName NAI属性。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 12 for parameter specification.
此外，可以包括信道绑定信息；有关讨论，请参见第5.5节。参数规格见图12。
Cryptosuite: This field indicates the integrity algorithm used for ERP. Key lengths and output lengths are either indicated or are obvious from the cryptosuite name. We specify some cryptosuites below:
Cryptosuite：此字段表示用于ERP的完整性算法。密钥长度和输出长度由cryptosuite名称指示或明显可见。我们在下面指定了一些加密套件：
* 0 RESERVED
* 0保留
* 1 HMAC-SHA256-64
* 1 HMAC-SHA256-64
* 2 HMAC-SHA256-128
* 2 HMAC-SHA256-128
* 3 HMAC-SHA256-256
* 3 HMAC-SHA256-256
HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled in the default configuration.
HMAC-SHA256-128是强制实施的，应在默认配置中启用。
Authentication Tag: This field contains the integrity checksum over the ERP packet, excluding the Authentication Tag field itself. The length of the field is indicated by the cryptosuite.
身份验证标签：此字段包含ERP数据包的完整性校验和，不包括身份验证标签字段本身。字段的长度由cryptosuite指示。
The EAP-Finish/Re-auth packet contains the parameters shown in Figure 10.
EAP Finish/Re-auth数据包包含如图10所示的参数。
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|B|L| Reserved | 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|B|L| Reserved | SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: EAP-Finish/Re-auth Packet
图10:EAP完成/重新验证数据包
Type = 2.
类型=2。
Flags
旗帜
'R' - The R flag is used as the Result flag. When set to 0, it indicates success, and when set to '1', it indicates a failure.
“R”-R标志用作结果标志。设置为0时表示成功，设置为“1”时表示失败。
'B' - The B flag is used as the bootstrapping flag. If the flag is turned on, the message is a bootstrap message.
“B”-B标志用作引导标志。如果该标志已打开，则该消息为引导消息。
'L' - The L flag is used to indicate the presence of the rRK lifetime TLV.
“L”-L标志用于指示rRK寿命TLV的存在。
The remaining 5 bits are set to 0 on transmission and ignored on reception.
其余5位在传输时设置为0，在接收时忽略。
SEQ: An unsigned 16-bit sequence number is used for replay protection. The SEQ field is initialized to 0 every time a new rRK is derived. The field is encoded in network byte order.
SEQ：无符号16位序列号用于重播保护。每次导出新的rRK时，SEQ字段初始化为0。该字段按网络字节顺序编码。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets.
TVs或TLV：在TV有效载荷中，有一个1-octet类型的有效载荷和一个具有特定类型长度的值。在TLV有效载荷中，有一个1-octet类型的有效载荷和一个1-octet长度的有效载荷。长度字段表示以八位字节数表示的值的长度。
keyName-NAI: This is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in length, and so the username portion takes up 16 octets. If the rIK is derived from the EMSK, the realm part of the NAI is the home domain name, and if the rIK is derived from a DSRK, the realm part of the NAI is the domain name used in the derivation of the DSRK. The NAI syntax is specified in [RFC4282]. Exactly one instance of the keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth message.
keyName NAI：这是在TLV有效载荷中携带的。类型是1。NAI长度可变，不超过253个八位字节。EMSKname位于NAI的用户名部分，并以十六进制值编码。EMSKname的长度为64位，因此用户名部分占16个八位字节。如果rIK来自EMSK，则NAI的领域部分是主域名，如果rIK来自DSRK，则NAI的领域部分是DSRK派生中使用的域名。[RFC4282]中指定了NAI语法。EAP完成/重新验证消息中应仅存在一个keyName NAI属性实例。
rRK Lifetime: This is a TV payload. The Type is 2. The value field contains an unsigned 32-bit integer in network byte order representing the lifetime of the rRK in seconds. If the 'L' flag is set, the rRK Lifetime attribute SHOULD be present.
rRK寿命：这是一个电视有效载荷。类型是2。值字段包含一个网络字节顺序的无符号32位整数，表示rRK的生存期（以秒为单位）。如果设置了“L”标志，则应存在rRK寿命属性。
rMSK Lifetime: This is a TV payload. The Type is 3. The value field contains an unsigned 32-bit integer in network byte order representing the lifetime of the rMSK in seconds. If the 'L' flag is set, the rMSK Lifetime attribute SHOULD be present.
rMSK寿命：这是一个电视有效载荷。类型是3。值字段包含一个网络字节顺序的无符号32位整数，表示rMSK的生存期（以秒为单位）。如果设置了“L”标志，则应该存在rMSK LIFET属性。
Domain name: This is a TLV payload. The Type is 4. The domain name is to be used as the realm in an NAI [RFC4282]. The Domain name attribute MUST be present in an EAP-Finish/ Re-auth message if the bootstrapping flag is set and if the local ER server sent a DSRK Request.
域名：这是TLV有效载荷。类型是4。域名将用作NAI[RFC4282]中的领域。如果设置了引导标志并且本地ER服务器发送了DSRK请求，则EAP Finish/Re auth消息中必须存在域名属性。
List of cryptosuites: This is a TLV payload. The Type is 5. The value field contains a list of cryptosuites, each of size 1 octet. The cryptosuite values are as specified in Figure 9. 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。值字段包含一个cryptosuites列表，每个大小为1个八位字节。cryptosuite值如图9所示。如果EAP Initiate/Re auth消息中使用的cryptosuite不可接受且消息被拒绝，则服务器应包含此属性。在其他情况下，服务器可能会包含此属性。服务器可以使用此属性向对等方发送其加密算法功能的信号。
Authorization Indication: This is a TLV payload. The Type is 6. This attribute MAY be included in the EAP-Finish/ Re-auth message when a DSRK is delivered to a local ER server and if the home EAP server can verify the authorization of the local ER server to advertise the domain name included in the domain TLV in the same message. The value field in the TLV contains an authentication tag computed over the entire packet, starting from the first bit of the code field to the last bit of the Cryptosuite field, with the value field of the Authorization Indication TLV filled with all 0s for the computation. The key used for the computation MUST be derived from the EMSK with key label "DSRK Delivery Authorized Key@ietf.org" and optional data containing an ASCII string representing the key management domain for which the DSRK is being derived.
授权指示：这是TLV有效载荷。类型是6。当DSRK被传递到本地ER服务器时，并且如果家庭EAP服务器可以验证本地ER服务器的授权以在同一消息中公布包含在域TLV中的域名，则此属性可能包含在EAP Finish/Re auth消息中。TLV中的值字段包含在整个数据包上计算的身份验证标签，从代码字段的第一位到Cryptosuite字段的最后一位，授权指示TLV的值字段中填充所有0以进行计算。用于计算的密钥必须来自密钥标签为“DSRK Delivery Authorized”的EMSKKey@ietf.org“和可选数据，其中包含一个ASCII字符串，表示为其派生DSRK的密钥管理域。
In addition, channel binding information MAY be included: see Section 5.5 for discussion. See Figure 12 for parameter specification. The server sends this information so that the peer can verify the information seen at the lower layer, if channel binding is to be supported.
此外，还可以包括通道绑定信息：有关讨论，请参见第5.5节。参数规格见图12。服务器发送此信息，以便对等方可以验证在较低层看到的信息（如果支持通道绑定）。
Cryptosuite: This field indicates the integrity algorithm and the PRF used for ERP. Key lengths and output lengths are either indicated or are obvious from the cryptosuite name.
Cryptosuite：此字段表示ERP使用的完整性算法和PRF。密钥长度和输出长度由cryptosuite名称指示或明显可见。
Authentication Tag: This field contains the integrity checksum over the ERP packet, excluding the Authentication Tag field itself. The length of the field is indicated by the cryptosuite.
身份验证标签：此字段包含ERP数据包的完整性校验和，不包括身份验证标签字段本身。字段的长度由cryptosuite指示。
The TV attributes that may be present in the EAP-Initiate or EAP-Finish messages are of the following format:
EAP Initiate或EAP Finish消息中可能存在的TV属性的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TV Attribute Format
图11:TV属性格式
The TLV attributes that may be present in the EAP-Initiate or EAP-Finish messages are of the following format:
EAP Initiate或EAP Finish消息中可能存在的TLV属性的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: TLV Attribute Format
图12:TLV属性格式
The following Types are defined in this document:
本文件中定义了以下类型：
'1' - keyName-NAI: This is a TLV payload.
“1”-keyName NAI：这是TLV有效载荷。
'2' - rRK Lifetime: This is a TV payload.
“2”-rRK寿命：这是一个电视有效载荷。
'3' - rMSK Lifetime: This is a TV payload.
“3”-rMSK生存期：这是一个电视有效载荷。
'4' - Domain name: This is a TLV payload.
“4”-域名：这是TLV有效负载。
'5' - Cryptosuite list: This is a TLV payload.
“5”-加密套件列表：这是TLV有效负载。
'6' - Authorization Indication: This is a TLV payload.
“6”-授权指示：这是TLV有效载荷。
The TLV type range of 128-191 is reserved to carry channel binding information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Below are the current assignments (all of them are TLVs):
保留TLV类型范围128-191，以便在EAP Initiate/Re-auth和EAP Finish/Re-auth消息中携带通道绑定信息。以下是当前分配（所有分配均为TLV）：
'128' - Called-Station-Id [RFC2865]
“128”-被叫站Id[RFC2865]
'129' - Calling-Station-Id [RFC2865]
“129”-呼叫站Id[RFC2865]
'130' - NAS-Identifier [RFC2865]
“130”-NAS标识符[RFC2865]
'131' - NAS-IP-Address [RFC2865]
“131”-NAS IP地址[RFC2865]
'132' - NAS-IPv6-Address [RFC3162]
'132'-NAS-IPv6-Address[RFC3162]
The length field indicates the length of the value part of the attribute in octets.
长度字段以八位字节表示属性值部分的长度。
For replay protection, ERP uses sequence numbers. The sequence number is maintained on a per rIK basis and is initialized to zero in both directions. In the first EAP-Initiate/Re-auth message, the peer
对于重播保护，ERP使用序列号。序列号以每rIK为基础进行维护，并在两个方向上初始化为零。在第一条EAP Initiate/Re-auth消息中，对等方
uses a sequence number value of zero or higher. Note that when the sequence number wraps back to zero, the rIK MUST be changed by running a full EAP authentication. The server expects a sequence number of zero or higher. When the server receives an EAP-Initiate/ Re-auth message, it uses the same sequence number in the EAP-Finish/ Re-auth message. The server then sets the expected sequence number to the received sequence number plus 1. The server MUST accept sequence numbers greater than or equal to the expected sequence number.
使用零或更高的序列号值。请注意，当序列号回零时，必须通过运行完整的EAP身份验证来更改rIK。服务器要求序列号为零或更高。当服务器收到EAP Initiate/Re-auth消息时，它在EAP Finish/Re-auth消息中使用相同的序列号。然后，服务器将预期序列号设置为接收序列号加1。服务器必须接受大于或等于预期序列号的序列号。
If the peer sends an EAP-Initiate/Re-auth message but does not receive a response, it retransmits the request (with no changes to the message itself) a preconfigured number of times before giving up. However, it is plausible that the server itself may have responded to the message and the response was lost in transit. Thus, the peer MUST increment the sequence number and use the new sequence number to send subsequent EAP re-authentication messages. The peer SHOULD increment the sequence number by 1; however, it may choose to increment by a larger number. If the sequence number wraps back to zero, the peer MUST run full EAP authentication.
如果对等方发送EAP Initiate/Re-auth消息但未收到响应，则在放弃之前，它会重新传输预配置次数的请求（不对消息本身进行更改）。但是，服务器本身可能已经响应了消息，并且响应在传输过程中丢失，这一点似乎是合理的。因此，对等方必须增加序列号，并使用新序列号发送后续EAP重新认证消息。对等方应将序列号增加1；然而，它可以选择增加一个更大的数字。如果序列号回到零，则对等方必须运行完整的EAP身份验证。
ERP provides a protected facility to carry channel binding (CB) information, according to the guidelines provided by Aboba, et al. (see Section 7.15 of [RFC3748]). The TLV type range of 128-191 is reserved to carry CB information in the EAP-Initiate/ Re-auth and EAP-Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id, NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples of channel binding information listed in RFC 3748, and they are assigned values 128-132. Additional values are managed by IANA, based on IETF Review (formerly called "IETF Consensus") [RFC5226].
根据Aboba等人提供的指南，ERP提供了一个受保护的设施来承载通道绑定（CB）信息（见[RFC3748]第7.15节）。TLV类型范围128-191保留为在EAP Initiate/Re-auth和EAP Finish/Re-auth消息中携带CB信息。被叫站Id、主叫站Id、NAS标识符、NAS IP地址和NAS-IPv6-Address是RFC 3748中列出的信道绑定信息的一些示例，它们是分配值128-132。IANA根据IETF审查（以前称为“IETF共识”）管理附加值[RFC5226]。
The authenticator MAY provide CB information to the peer via the EAP-Initiate/Re-auth-Start message. The peer sends the information to the server in the EAP-Initiate/Re-auth message; the server verifies whether the authenticator identity available via AAA attributes is the same as the identity provided to the peer.
验证器可以通过EAP Initiate/Re auth Start消息向对等方提供CB信息。对等方在EAP Initiate/Re-auth消息中向服务器发送信息；服务器验证通过AAA属性可用的验证器标识是否与提供给对等方的标识相同。
If the peer does not include the CB information in the EAP-Initiate/ Re-auth message, and if the local ER server's policy requires channel binding support, it SHALL send the CB attributes for the peer's verification. The peer attempts to verify the CB information if the authenticator has sent the CB parameters, and it proceeds with the lower-layer security association establishment if the attributes match. Otherwise, the peer SHALL NOT proceed with the lower-layer security association establishment.
如果对等方未在EAP Initiate/Re auth消息中包含CB信息，并且如果本地ER服务器的策略需要通道绑定支持，则应发送CB属性以供对等方验证。如果验证器已发送CB参数，对等方将尝试验证CB信息，如果属性匹配，对等方将继续建立较低层的安全关联。否则，对等方不得继续进行下层安全关联的建立。
The authenticator is responsible for retransmission of EAP-Initiate/ Re-auth-Start messages. The authenticator MAY retransmit the message a few times or until it receives an EAP-Initiate/Re-auth message from the peer. The authenticator might not know if the peer supports ERP; in those cases, the peer could be silently discarding the EAP-Initiate/Re-auth-Start packets. Thus, retransmission of these packets should be kept to a minimum. The exact number is up to each lower layer.
验证器负责EAP Initiate/Re-auth Start消息的重新传输。验证器可以重新传输消息几次，或者直到它从对等方接收到EAP Initiate/Re auth消息为止。认证者可能不知道对等方是否支持ERP；在这些情况下，对等方可能会默默地丢弃EAP Initiate/Re-auth Start数据包。因此，应将这些分组的重传保持在最低限度。确切的数字取决于每个较低的层。
The Identifier value in the EAP-Initiate/Re-auth packet is independent of the Identifier value in the EAP-Initiate/Re-auth-Start packet.
EAP Initiate/Re-auth数据包中的标识符值独立于EAP Initiate/Re-auth Start数据包中的标识符值。
The peer is responsible for retransmission of EAP-Initiate/Re-auth messages.
对等方负责重新传输EAP启动/重新验证消息。
Retransmitted packets MUST be sent with the same Identifier value in order to distinguish them from new packets. By default, where the EAP-Initiate message is sent over an unreliable lower layer, the retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested [RFC3748]. Where the EAP-Initiate message is sent over a reliable lower layer, the retransmission timer SHOULD be set to an infinite value so that retransmissions do not occur at the EAP layer. Please refer to RFC 3748 for additional guidance on setting timers.
重新传输的数据包必须使用相同的标识符值发送，以便将其与新数据包区分开来。默认情况下，如果EAP Initiate消息通过不可靠的较低层发送，则应动态估计重传计时器。建议最多3-5次重传[RFC3748]。如果EAP Initiate消息通过可靠的较低层发送，则应将重传计时器设置为无限值，以便在EAP层不会发生重传。请参阅RFC 3748，了解有关设置计时器的更多指导。
The Identifier value in the EAP-Finish/Re-auth packet is the same as the Identifier value in the EAP-Initiate/Re-auth packet.
EAP Finish/Re-auth数据包中的标识符值与EAP Initiate/Re-auth数据包中的标识符值相同。
If an authenticator receives a valid duplicate EAP-Initiate/Re-auth message for which it has already sent an EAP-Finish/Re-auth message, it MUST resend the EAP-Finish/Re-auth message without reprocessing the EAP-Initiate/Re-auth message. To facilitate this, the authenticator SHALL store a copy of the EAP-Finish/Re-auth message for a finite amount of time. The actual value of time is a local matter; this specification recommends a value of 100 milliseconds.
如果验证器接收到有效的重复EAP Initiate/Re-auth消息，并且已为该消息发送了EAP Finish/Re-auth消息，则必须在不重新处理EAP Initiate/Re-auth消息的情况下重新发送EAP Finish/Re-auth消息。为便于此，认证者应在有限的时间内存储EAP完成/重新认证消息的副本。时间的实际价值是一个局部问题；本规范建议的值为100毫秒。
The lower layer may provide facilities for exchanging information between the peer and the authenticator about support for ERP, for the authenticator to send the domain name information and channel binding information to the peer.
较低层可以提供用于在对等方和认证方之间交换关于支持ERP的信息的设施，以便认证方将域名信息和信道绑定信息发送给对等方。
Note that to support ERP, lower-layer specifications may need to be revised. Specifically, RFC 5996 must be updated to include EAP code values higher than 4 in order to use ERP with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may also be updated to support peer-initiated ERP for optimized operation. Other lower layers may need similar revisions.
请注意，为了支持ERP，可能需要修改下层规范。具体而言，必须更新RFC 5996，以包含高于4的EAP代码值，以便将ERP与Internet密钥交换协议版本2（IKEv2）一起使用。IKEv2也可以更新，以支持同行发起的ERP，从而优化操作。其他较低层可能需要类似的修订。
Our analysis indicates that some EAP implementations are not RFC 3748 compliant in that instead of silently dropping EAP packets with code values higher than 4, they may consider it an error. To accommodate such non-compliant EAP implementations, additional guidance has been provided below. Furthermore, it may not be easy to upgrade all the peers in some cases. In such cases, authenticators may be configured to not send EAP-Initiate/Re-auth-Start messages; peers may learn whether an authenticator supports ERP via configuration or from advertisements at the lower layer.
我们的分析表明，一些EAP实现不符合RFC 3748，而不是默默地丢弃具有高于4的代码值的EAP包，它们可能认为是错误。为适应此类不合规的EAP实施，下文提供了额外的指导。此外，在某些情况下升级所有对等点可能并不容易。在这种情况下，认证器可被配置为不发送EAP发起/重新认证开始消息；对等方可以通过配置或从较低层的广告了解验证器是否支持ERP。
In order to accommodate implementations that are not compliant to RFC 3748, such lower layers SHOULD ensure that both parties support ERP; this is trivial, for instance, when using a lower layer that is known to always support ERP. For lower layers where ERP support is not guaranteed, ERP support may be indicated through signaling (e.g., piggybacked on a beacon) or through negotiation. Alternatively, clients may recognize environments where ERP is available based on preconfiguration. Other similar mechanisms may also be used. When ERP support cannot be verified, lower layers may mandate falling back to full EAP authentication to accommodate EAP implementations that are not compliant to RFC 3748.
为了适应不符合RFC 3748的实施，此类较低层应确保双方支持ERP；例如，当使用始终支持ERP的较低层时，这是微不足道的。对于不能保证ERP支持的较低层，可以通过信令（例如，在信标上搭载）或协商来指示ERP支持。或者，客户可以根据预配置识别ERP可用的环境。也可以使用其他类似的机制。当无法验证ERP支持时，较低层可能要求退回到完整的EAP认证，以适应不符合RFC 3748的EAP实施。
AAA transport of ERP messages is specified by Hoeper, et al. [RFC5749] and Bournelle, et al. [DIAMETER-ERP].
Hoeper等人[RFC5749]和Bournelle等人[DIAMETER-ERP]规定了ERP消息的AAA传输。
This section provides an analysis of the protocol in accordance with the AAA key management guidelines described by Housley & Aboba [RFC4962].
本节根据Housley&Aboba[RFC4962]所述的AAA密钥管理指南对协议进行分析。
Cryptographic algorithm independence
密码算法独立性
ERP satisfies this requirement. The algorithm chosen by the peer for the MAC generation 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 indicating a failure. Algorithm agility for the KDF is specified in Salowey, et al. [RFC5295]. Only when the algorithms used are
ERP满足这一要求。对等方为MAC生成选择的算法在EAP Initiate/Re-auth消息中指示。如果所选算法不可接受，EAP服务器将返回一条EAP Finish/Re auth消息，指示失败。Salowey等人[RFC5295]中规定了KDF的算法敏捷性。仅当使用的算法是
deemed acceptable does the server proceed with the derivation of keys and verification of the proof of possession of relevant key material presented by the peer. A full-blown negotiation of algorithms cannot be provided in a single round-trip protocol. Hence, while the protocol provides algorithm agility, it does not provide true negotiation.
如果认为可以接受，服务器是否继续推导密钥并验证对等方提供的相关密钥材料的占有证明。一个完整的算法协商不能在单一的往返协议中提供。因此，虽然协议提供了算法灵活性，但它不提供真正的协商。
Strong, fresh session keys
强大、新鲜的会话密钥
ERP results in the derivation of strong, fresh keys that are unique for the given session. An rMSK is always derived on demand when the peer requires a key with a new authenticator. The derivation ensures that the compromise of one rMSK does not result in the compromise of another rMSK at any time.
ERP导致派生出对给定会话唯一的强、新密钥。当对等方需要具有新身份验证器的密钥时，总是根据需要派生rMSK。该推导确保一个rMSK的折衷在任何时候都不会导致另一个rMSK的折衷。
Limited key scope
有限的关键范围
The scope of all the keys derived by ERP is well defined. The rRK and rIK are never shared with any entity and always remain on the peer and the server. The rMSK is provided only to the authenticator through which the peer performs the ERP exchange. No other authenticator is authorized to use that rMSK.
ERP派生的所有键的范围都有很好的定义。rRK和rIK从不与任何实体共享，始终保留在对等方和服务器上。rMSK仅提供给认证者，对等方通过认证者执行ERP交换。没有其他验证器被授权使用该rMSK。
Replay detection mechanism
重播检测机制
For replay protection of ERP messages, a sequence number associated with the rIK is used. The sequence number is maintained by the peer and the server and is initialized to zero when the rIK is generated. The peer increments the sequence number by one after it sends an ERP message. The server sets the expected sequence number to the received sequence number plus one after verifying the validity of the received message and responds to the message.
对于ERP消息的重播保护，使用与rIK关联的序列号。序列号由对等方和服务器维护，并在生成rIK时初始化为零。对等方在发送ERP消息后将序列号增加1。在验证接收到的消息的有效性后，服务器将预期序列号设置为接收到的序列号加上一，并响应消息。
Authenticating all parties
认证各方
ERP provides mutual authentication of the peer and the server. Both parties need to possess the key material that resulted from a previous EAP exchange in order to successfully derive the required keys. Also, both the EAP re-authentication Response and the EAP re-authentication Information messages are integrity protected so that the peer and the server can verify each other. When the ERP exchange is executed with a local ER server, the peer and the local server mutually authenticate each other via that exchange in the same manner. The peer and the authenticator authenticate each other in the secure association protocol executed by the lower layer, just as in the case of a regular EAP exchange.
ERP提供对等方和服务器的相互身份验证。双方需要拥有先前EAP交换产生的关键材料，以便成功获得所需的关键。此外，EAP重新认证响应和EAP重新认证信息消息都受到完整性保护，以便对等方和服务器可以相互验证。当使用本地ER服务器执行ERP交换时，对等方和本地服务器以相同的方式通过该交换相互认证。对等方和认证方在由较低层执行的安全关联协议中相互认证，就像在常规EAP交换中一样。
Peer and authenticator authorization
对等和身份验证器授权
The peer and authenticator demonstrate possession of the same key material without disclosing it, as part of the lower-layer secure association protocol. Channel binding with ERP may be used to verify consistency of the identities exchanged, when the identities used in the lower layer differ from those exchanged within the AAA protocol.
作为低层安全关联协议的一部分，对等方和认证方在不公开的情况下证明拥有相同的密钥材料。当较低层中使用的身份与AAA协议中交换的身份不同时，可使用与ERP的信道绑定来验证交换的身份的一致性。
Key material confidentiality
关键材料保密性
The peer and the server derive the keys independently using parameters known to each entity. The AAA server sends the DSRK of a domain to the corresponding local ER server via the AAA protocol. Likewise, the ER server sends the rMSK to the authenticator via the AAA protocol.
对等方和服务器使用每个实体已知的参数独立地派生密钥。AAA服务器通过AAA协议将域的DSRK发送到相应的本地ER服务器。同样，ER服务器通过AAA协议将rMSK发送给认证器。
Note that compromise of the DSRK results in compromise of all keys derived from it. Moreover, there is no forward secrecy within ERP. Thus, compromise of a DSRK retroactively compromises all ERP keys.
请注意，DSRK的折衷会导致从它派生的所有密钥的折衷。此外，ERP中没有前向保密。因此，DSRK的泄露会追溯到所有ERP密钥。
It is RECOMMENDED that the AAA protocol be protected using IPsec or Transport Layer Security (TLS) so that the keys are protected in transit. Note, however, that keys may be exposed to AAA proxies along the way, and compromise of any of those proxies may result in compromise of keys being transported through them.
建议使用IPsec或传输层安全性（TLS）保护AAA协议，以便在传输过程中保护密钥。但是，请注意，密钥可能会在传输过程中暴露给AAA代理，任何代理的泄露都可能导致密钥通过它们传输。
The home EAP server MUST NOT hand out a given DSRK to a local domain server more than once, unless it can verify that the entity receiving the DSRK after the first time is the same entity that received the DSRK originally. If the home EAP server verifies authorization of a local domain server, it MAY hand out the DSRK to that domain more than once. In this case, the home EAP server includes the Authorization Indication TLV to assure the peer that DSRK delivery is secure.
家庭EAP服务器不得多次向本地域服务器分发给定的DSRK，除非它能够验证第一次之后接收DSRK的实体与最初接收DSRK的实体相同。如果家庭EAP服务器验证本地域服务器的授权，它可能会多次向该域分发DSRK。在这种情况下，家庭EAP服务器包括授权指示TLV，以确保对等方DSRK交付是安全的。
Confirming cryptosuite selection
确认加密套件选择
Cryptographic algorithms for integrity and key derivation in the context of ERP MAY be the same as that used by the EAP method. In that case, the EAP method is responsible for confirming the cryptosuite selection. Furthermore, the cryptosuite is included in the ERP exchange by the peer and confirmed by the server. The protocol allows the server to reject the cryptosuite selected by the peer and provide alternatives. When a suitable rIK is not available for the
ERP上下文中完整性和密钥派生的密码算法可能与EAP方法使用的密码算法相同。在这种情况下，EAP方法负责确认cryptosuite选择。此外，加密套件由对等方包含在ERP交换中，并由服务器确认。该协议允许服务器拒绝对等方选择的cryptosuite并提供替代方案。当没有合适的rIK可用于
peer, the alternatives may be sent in an unprotected fashion. The peer is allowed to retry the exchange using one of the allowed cryptosuites. However, in this case, any en route modifications to the list sent by the server will go undetected. If the server does have an rIK available for the peer, the list will be provided in a protected manner and this issue does not apply.
对等，备选方案可能以不受保护的方式发送。允许对等方使用允许的加密套件之一重试交换。但是，在这种情况下，服务器发送的对列表的任何途中修改都不会被检测到。如果服务器确实有可供对等方使用的rIK，则该列表将以受保护的方式提供，此问题不适用。
Uniquely named keys
唯一命名的密钥
All keys produced within the context of ERP can be referred to uniquely as specified in this document. Also, the key names do not reveal any part of the key material.
在ERP上下文中生成的所有密钥都可以按照本文档中的规定进行唯一引用。此外，密钥名称不会显示密钥材质的任何部分。
Preventing the domino effect
防止多米诺效应
The compromise of one peer does not result in the compromise of key material held by any other peer in the system. Also, the rMSK is meant for a single authenticator and is not shared with any other authenticator. Hence, the compromise of one authenticator does not lead to the compromise of sessions or keys held by any other authenticator in the system, and ERP thereby allows prevention of the domino effect by appropriately defining key scope.
一个对等方的泄露不会导致系统中任何其他对等方持有的关键材料泄露。此外，rMSK用于单个验证器，不与任何其他验证器共享。因此，一个身份验证器的泄露不会导致系统中任何其他身份验证器持有的会话或密钥泄露，因此ERP通过适当定义密钥范围允许防止domino效应。
However, if keys are transported using hop-by-hop protection, compromise of a proxy may result in compromise of key material, e.g., the DSRK being sent to a local ER server.
但是，如果使用逐跳保护传输密钥，则代理的泄露可能导致密钥材料的泄露，例如，将DSRK发送到本地ER服务器。
Binding a key to its context
将密钥绑定到其上下文
All the keys derived for ERP are bound to the appropriate context using appropriate key labels. The lifetime of a child key is less than or equal to that of its parent key as specified in RFC 4962 [RFC4962]. The key usage, lifetime, and the parties that have access to the keys are specified.
为ERP派生的所有键都使用适当的键标签绑定到适当的上下文。子密钥的生存期小于或等于RFC 4962[RFC4962]中指定的父密钥的生存期。指定了密钥使用、生存期以及有权访问密钥的各方。
Confidentiality of identity
身份保密
Deployments where privacy is a concern may find that the use of the rIKname-NAI to route ERP messages serves their privacy requirements. Note that it is plausible to associate multiple runs of ERP messages, since the rIKname is not changed as part of ERP. There was no consensus for that requirement at the time of development of this specification. If the rIKname is not used and the Peer-ID is used instead, the ERP exchange will reveal the Peer-ID over the wire.
涉及隐私的部署可能会发现，使用rIKname NAI路由ERP消息符合其隐私要求。请注意，关联多个ERP消息运行是合理的，因为rIKname没有作为ERP的一部分更改。在制定本规范时，未就该要求达成一致意见。如果不使用rIKname，而是使用对等ID，ERP交换将通过线路显示对等ID。
Authorization restriction
授权限制
All the derived keys are limited in lifetime by that of the parent key or by server policy. Any domain-specific keys are further restricted for use only in the domain for which the keys are derived. All the keys specified in this document are meant for use in ERP only. Other restrictions on the use of session keys may be imposed by the specific lower layer but are out of scope for this specification.
所有派生密钥的生存期都受到父密钥的生存期或服务器策略的限制。任何特定于域的密钥都进一步限制仅在为其派生密钥的域中使用。本文档中指定的所有密钥仅供ERP使用。会话密钥使用的其他限制可能由特定的较低层施加，但超出本规范的范围。
Preventing a DoS attack
防止拒绝服务攻击
A denial-of-service (DoS) attack on the peer may be possible when using the EAP-Initiate/Re-auth message. An attacker may send a bogus EAP-Initiate/Re-auth message, which may be carried by the authenticator in a AAA-Request to the server; in response, the server may send in a AAA reply an EAP-Finish/ Re-auth message indicating failure. Note that such attacks may be possible with the EAPoL-Start capability of IEEE 802.11 and other similar facilities in other link layers and where the peer can initiate EAP authentication. An attacker may use such messages to start an EAP method run, which fails and may result in the server sending a rejection message, thus resulting in the link-layer connections being terminated.
使用EAP Initiate/Re-auth消息时，可能会对对等方发起拒绝服务（DoS）攻击。攻击者可以向服务器发送伪造的EAP Initiate/Re-auth消息，该消息可能由认证者在AAA请求中携带；作为响应，服务器可以在AAA回复中发送EAP Finish/Re auth消息，指示失败。请注意，IEEE 802.11的EAPoL启动功能和其他链路层中的其他类似设施以及对等方可以发起EAP身份验证时，可能会发生此类攻击。攻击者可使用此类消息启动EAP方法运行，该方法运行失败，并可能导致服务器发送拒绝消息，从而导致链路层连接终止。
To prevent such DoS attacks, an ERP failure should not result in deletion of any authorization state established by a full EAP exchange. Alternatively, the lower layers and AAA protocols may define mechanisms to allow two link-layer Security Associations (SAs) derived from different EAP key material for the same peer to exist so that smooth migration from the current link-layer SA to the new one is possible during rekey. These mechanisms prevent the link-layer connections from being terminated when a re-authentication procedure fails due to a bogus EAP-Initiate/Re-auth message.
为防止此类DoS攻击，ERP故障不应导致删除由完整EAP交换建立的任何授权状态。或者，较低层和AAA协议可以定义机制，以允许从同一对等方的不同EAP密钥材料派生的两个链路层安全关联（SA）存在，以便在重新密钥期间可以从当前链路层SA平滑迁移到新的链路层SA。这些机制防止在由于虚假EAP Initiate/re-auth消息导致重新身份验证过程失败时终止链路层连接。
Key material transport
关键材料运输
When a DSRK is sent from the home EAP server to a local domain server or when an rMSK is sent from an ER server to an authenticator, in the absence of end-to-end security between the entity that is sending the key and the entity receiving the key, it is plausible for other entities to get access to keys being sent to an ER server in another domain. This mode of key transport is similar to that of MSK transport in the context of EAP authentication. We further observe that ERP is for access authentication and does not support end-to-end data security. In typical implementations, the traffic is in the clear beyond
当DSRK从家庭EAP服务器发送到本地域服务器时，或者当rMSK从ER服务器发送到验证器时，在发送密钥的实体和接收密钥的实体之间缺乏端到端安全性的情况下，其他实体可以访问发送到另一个域中的ER服务器的密钥。这种密钥传输模式类似于EAP身份验证上下文中的MSK传输模式。我们进一步观察到，ERP用于访问身份验证，不支持端到端数据安全。在典型的实现中，通信量处于清晰的范围内
the access control enforcement point (the authenticator or an entity delegated by the authenticator for access control enforcement). The model works as long as entities in the middle of the network do not use keys intended for other parties to steal service from an access network. If that is not achievable, key delivery must be protected in an end-to-end manner.
访问控制实施点（身份验证器或由身份验证器授权的用于访问控制实施的实体）。只要网络中间的实体不使用用于其他方从接入网络窃取服务的密钥，该模型就起作用。如果无法实现，则必须以端到端的方式保护密钥传递。
The previous version of this document -- [RFC5296] -- performed the following IANA [IANA] actions:
本文档的早期版本--[RFC5296]--执行了以下IANA[IANA]操作：
1. It registered Packet Codes "Initiate" and "Finish" in the EAP Registry. Those codes are referred to as "EAP-Initiate" and "EAP-Finish" throughout this document.
1. 它在EAP注册表中注册了数据包代码“Initiate”和“Finish”。这些代码在本文件中称为“EAP启动”和“EAP完成”。
2. It created a Message Types table in the EAP Registry and registered several items in that table. Those items are referred to as "Re-auth-start" and "Re-auth" throughout this document.
2. 它在EAP注册表中创建了一个消息类型表，并在该表中注册了若干项。这些项目在本文件中称为“重新授权开始”和“重新授权”。
3. It created an EAP-Initiate and Finish Attributes table in the EAP registry and registered several items in that table. Those items are recorded in this document in Section 5.3.4.
3. 它在EAP注册表中创建了一个EAP Initiate和Finish Attributes表，并在该表中注册了若干项。这些项目记录在本文件第5.3.4节中。
4. It created a Re-authentication Cryptosuites table in the EAP registry and registered several items in that table. Those items are recorded in this document at the end of Section 5.3.2.
4. 它在EAP注册表中创建了一个重新身份验证Cryptosuites表，并在该表中注册了若干项。这些项目记录在本文件第5.3.2节末尾。
5. It registered two items in the USRK Key Labels registry:
5. 它在USRK密钥标签注册表中注册了两项：
* Re-auth usage label "EAP Re-authentication Root Key@ietf.org", recorded in this document in Section 4.1.
* 重新验证使用标签“EAP重新验证根”Key@ietf.org“，记录在本文件第4.1节中。
* DSRK-authorized delivery key "DSRK Delivery Authorized Key@ietf.org", recorded in this document in the description of "Authorization Indication" in Section 5.3.3.
* DSRK授权交付密钥“DSRK授权交付Key@ietf.org，记录在本文件第5.3.3节“授权指示”的说明中。
Barry Leiba contributed all of the text in Section 9 and, as Applications Area Director, insisted upon its inclusion as a condition of publication.
Barry Leiba贡献了第9节中的所有文本，作为应用领域总监，他坚持将其作为出版条件。
This document is largely based upon RFC 5296; thanks to all who participated in that effort (see Appendix A). In addition, thanks to Yaron Sheffer, Sebastien Decugis, Ralph Droms, Stephen Farrell, Charlie Kaufman, and Yoav Nir for (mostly) useful comments and review.
本文件主要基于RFC 5296；感谢所有参与这项工作的人（见附录A）。此外，感谢亚龙·谢弗、塞巴斯蒂安·德库吉斯、拉尔夫·德罗姆斯、斯蒂芬·法雷尔、查理·考夫曼和约阿夫·奈尔（主要）提供了有用的评论和评论。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[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月。
[DIAMETER-ERP] Bournelle, J., Morand, L., Decugis, S., Wu, Q., and G. Zorn, "Diameter Support for the EAP Re-authentication Protocol (ERP)", Work in Progress, June 2012.
[DIAMETER-ERP]Bournelle，J.，Morand，L.，Decugis，S.，Wu，Q.，和G.Zorn，“EAP再认证协议（ERP）的DIAMETER支持”，正在进行的工作，2012年6月。
[IANA] "Internet Assigned Numbers Authority", <http://www.iana.org/>.
[IANA]“互联网分配号码管理局”<http://www.iana.org/>.
[IEEE_802.1X] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Std 802.1X-2010, February 2010.
[IEEE_802.1X]电气和电子工程师协会，“局域网和城域网IEEE标准：基于端口的网络访问控制”，IEEE标准802.1X-2010，2010年2月。
[IKE-EXT-for-ERP] Nir, Y. and Q. Wu, "An IKEv2 Extension for Supporting ERP", Work in Progress, May 2012.
[IKE EXT for ERP]Nir，Y.和Q.Wu，“支持ERP的IKEv2扩展”，正在进行的工作，2012年5月。
[MSKHierarchy] Lopez, R., Skarmeta, A., Bournelle, J., Laurent-Maknavicus, M., and J. Combes, "Improved EAP keying framework for a secure mobility access service", IWCMC '06, Proceedings of the 2006 International Conference on Wireless Communications and Mobile Computing, New York, NY, USA, 2006.
[MSKHierarchy]Lopez，R.，Skarmeta，A.，Bournelle，J.，Laurent Maknavicus，M.，和J.Combes，“用于安全移动接入服务的改进EAP键控框架”，IWCM'06，2006年无线通信和移动计算国际会议记录，美国纽约，2006年。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187]Arkko，J.和H.Haverinen，“第三代认证和密钥协议（EAP-AKA）的可扩展认证协议方法”，RFC 4187，2006年1月。
[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月。
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
[RFC5169]Clancy，T.，Nakhjiri，M.，Narayanan，V.，和L.Dondeti，“移交密钥管理和重新认证问题声明”，RFC 5169，2008年3月。
[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月。
[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月。
[RFC5749] Hoeper, K., Ed., Nakhjiri, M., and Y. Ohba, Ed., "Distribution of EAP-Based Keys for Handover and Re-Authentication", RFC 5749, March 2010.
[RFC5749]Hoeper，K.，Ed.，Nakhjiri，M.，和Y.Ohba，Ed.，“用于切换和重新认证的基于EAP的密钥的分发”，RFC 5749，2010年3月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 2011.
[RFC6440]Zorn，G.，Wu，Q.，和Y.Wang，“EAP重新认证协议（ERP）本地域名DHCPv6选项”，RFC 64402011年12月。
In writing this document, we benefited from discussing the problem space and the protocol itself with a number of folks including Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of the HOKEY Working Group. Credit for the idea to use EAP-Initiate/ Re-auth-Start goes to Charles Clancy, and credit for the idea to use multiple link-layer SAs to mitigate DoS attacks goes to Yoshi Ohba. Katrin Hoeper suggested the use of the windowing technique to handle multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for the suggestion to use hexadecimal encoding for the rIKname when sent as part of the keyName-NAI field. Thanks to Bernard Aboba for suggestions in clarifying the EAP lock-step operation, and to Joe Salowey and Glen Zorn for help in specifying AAA transport of ERP messages. Thanks to Sam Hartman for the DSRK Authorization Indication mechanism.
在撰写本文件时，我们受益于与许多人讨论了问题空间和协议本身，包括伯纳德·阿博巴、贾里·阿尔科、山姆·哈特曼、罗斯·霍斯利、乔·萨洛维、杰西·沃克、查尔斯·克兰西、米切拉·范德韦恩、凯达尔·冈卡、帕拉·阿加什、迪内什·达尔马祖、帕西·艾隆、丹·哈金斯、约希·奥巴、格伦·佐恩、，Alan DeKok、Katrin Hoeper和HOKEY工作组的其他参与者。Charles Clancy提出了使用EAP Initiate/Re-auth Start的想法，而Yoshi Ohba提出了使用多链路层SAs来缓解DoS攻击的想法。Katrin Hoeper建议使用窗口技术来处理多个同时的ER交换。非常感谢Pasi Eronen的建议，在作为keyName NAI字段的一部分发送时，对rIKname使用十六进制编码。感谢Bernard Aboba在澄清EAP锁定步骤操作方面提出的建议，以及Joe Salowey和Glen Zorn在指定ERP消息的AAA传输方面提供的帮助。感谢Sam Hartman提供的DSRK授权指示机制。
0. Authenticator --> Peer: EAP-Initiate/Re-auth-Start [Optional]
0. 验证器-->对等：EAP启动/重新验证启动[可选]
1. Peer --> Authenticator: EAP-Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, Auth-tag*)
1. 对等-->身份验证器：EAP启动/重新身份验证（SEQ，keyName NAI，cryptosuite，身份验证标签*）
1a. Authenticator --> Re-auth-Server:
AAA-Request
{
Authenticator-Id,
EAP-Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,
Auth-tag*)
}
1a. Authenticator --> Re-auth-Server:
AAA-Request
{
Authenticator-Id,
EAP-Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,
Auth-tag*)
}
2. ER-Server --> Authenticator: AAA-Response { rMSK, EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], Auth-tag*) }
2. ER服务器-->身份验证器：AAA响应{rMSK，EAP完成/重新身份验证（SEQ，keyName NAI，cryptosuite，[CB Info]，auth tag*））
2b. Authenticator --> Peer:
EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info],
Auth-tag*)
2b. Authenticator --> Peer:
EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info],
Auth-tag*)
* Auth-tag computation is over the entire EAP-Initiate/Finish message; the code values for Initiate and Finish are different, and thus reflection attacks are mitigated.
* 验证标记计算覆盖整个EAP启动/完成消息；Initiate和Finish的代码值不同，因此可以减轻反射攻击。
Authors' Addresses
作者地址
Zhen Cao China Mobile No. 32, Xuanwumenxi Ave., Xicheng District Beijing 100053 P.R. China EMail: caozhen@chinamobile.com
中国北京市西城区宣武门西路32号中国移动真曹100053电子邮件：caozhen@chinamobile.com
Baohong He China Academy of Telecommunication Research Beijing P.R. China Phone: +86 10 62300050 EMail: hebaohong@catr.cn
中国电信研究院北京分院电话：+86 10 62300050电子邮件：hebaohong@catr.cn
Yang Shi Huawei Technologies Co., Ltd. 156 Beiqing Road, Zhongguancun, Haidian District Beijing P.R. China Phone: +86 10 60614043 EMail: shiyang1@huawei.com
杨氏华为技术有限公司中国北京市海淀区中关村北青路156号电话：+86 10 60614043电子邮件：shiyang1@huawei.com
Qin Wu (editor) Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, JiangSu 210012 China Phone: +86-25-84565892 EMail: bill.wu@huawei.com
秦武（编辑）江苏省南京市雨花区软件大道101号华为技术有限公司210012中国电话：+86-25-84565892电子邮件：比尔。wu@huawei.com
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 909 201060 EMail: glenzorn@gmail.com
格伦·佐恩（编辑）网络禅227/358泰国曼谷塔农·桑法乌特·邦纳10260泰国电话：+66（0）909 201060电子邮件：glenzorn@gmail.com