Network Working Group V. Narayanan
Request for Comments: 5296 L. Dondeti
Category: Standards Track Qualcomm, Inc.
August 2008
Network Working Group V. Narayanan
Request for Comments: 5296 L. Dondeti
Category: Standards Track Qualcomm, Inc.
August 2008
EAP Extensions for EAP Re-authentication Protocol (ERP)
EAP重新认证协议（ERP）的EAP扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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 not repeat 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重新认证服务器之间进行有效的重新认证。重新认证服务器可以在家庭网络中或者在对等方正在连接的本地网络中。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 6
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 8
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 11
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 12
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 12
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 13
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 14
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 15
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 15
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 20
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 21
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 22
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 23
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 26
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 29
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 31
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 42
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 6
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 8
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 11
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 12
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 12
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 13
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 14
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 15
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 15
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 20
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 21
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 22
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 23
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 26
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 29
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 31
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 42
The Extensible Authentication Protocol (EAP) is a 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 delays in handover times. Some EAP methods specify the use of state from the initial authentication to optimize re-authentications by reducing the computational overhead, but method-specific re-authentication takes at least 2 round trips with the original EAP server in most cases (e.g., [6]). It is also important to note that several methods do not offer support for re-authentication.
当对等方从一个验证器移动到另一个验证器时，希望避免完全EAP认证以支持快速切换。与另一个EAP方法运行的完整EAP交换可能需要多次往返和大量时间才能完成，从而导致切换时间延迟。一些EAP方法指定使用初始身份验证的状态，通过减少计算开销来优化重新身份验证，但在大多数情况下，特定于方法的重新身份验证至少需要与原始EAP服务器进行两次往返（例如，[6]）。还需要注意的是，有几种方法不支持重新身份验证。
Key sharing across authenticators is sometimes used as a practical solution to lower handover times. In that case, compromise of an authenticator results in compromise of keying material established via other authenticators. Other solutions for fast re-authentication exist in the literature [7] [8].
跨认证器的密钥共享有时被用作减少切换时间的实用解决方案。在这种情况下，验证器的泄露导致通过其他验证器建立的密钥材料的泄露。文献[7][8]中还存在其他快速重新认证的解决方案。
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. The EAP re-authentication problem statement is described in detail in [9].
总之，为了实现低延迟切换，需要一种独立于方法的重新认证协议，该协议在不到2次往返中完成，最好是使用本地服务器。EAP重新认证问题陈述在[9]中有详细描述。
This document specifies EAP Re-authentication Extensions (ERXs) for efficient re-authentication using EAP. The protocol that uses these extensions itself is referred to as the EAP Re-authentication Protocol (ERP). It supports EAP method-independent re-authentication 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重新身份验证扩展（ERX），以便使用EAP进行有效的重新身份验证。使用这些扩展本身的协议称为EAP重新认证协议（ERP）。它支持对具有来自先前执行的EAP身份验证的有效、未过期密钥材料的对等方进行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 IEEE802.1x specification must be revised and RFC 4306 must be updated to carry ERP messages.
请注意，为了支持ERP，可能需要修改下层规范，以允许承载代码值大于4的EAP消息，并适应ERP的对等启动性质。具体而言，必须修订IEEE802.1x规范，并更新RFC 4306以承载ERP消息。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This document uses the basic EAP terminology [2] and EMSK keying hierarchy terminology [3]. In addition, this document uses the following terms:
本文件使用基本EAP术语[2]和EMSK键控层次术语[3]。此外，本文件使用以下术语：
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; the home ER server is located on the same backend authentication server as the EAP server in the home domain. The local ER server may not necessarily be a full EAP server.
ER服务器-执行此处描述的ERP服务器部分的实体。此实体可能是也可能不是EAP服务器。除非另有特别说明，否则本文件中对“服务器”的所有引用均指ER服务器。ER服务器是一个逻辑实体；家庭ER服务器与家庭域中的EAP服务器位于同一后端身份验证服务器上。本地ER服务器不一定是完整的EAP服务器。
ERX - EAP re-authentication extensions.
ERX-EAP重新认证扩展。
ERP - EAP Re-authentication Protocol that uses the re-authentication extensions.
ERP-使用重新认证扩展的EAP重新认证协议。
rRK - re-authentication Root Key, derived from the EMSK or 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 [3]; 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 NAI.
keyName NAI-ERP消息通过rIK或DS rIK进行完整性保护。使用rIK或DS rIK保护ERP消息的完整性由EMSKname[3]表示；协议，即ERP；域，表示ER服务器的域名。EMSKname被复制到NAI的用户名部分。
Domain - Refers to a "key management domain" as defined in [3]. 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.
域-指[3]中定义的“密钥管理域”。为简单起见，在本文档中它被称为“域”。术语“主域”和“本地域”用于区分与对等方执行完整EAP交换的原始密钥管理域和对等方在给定时间可能连接到的本地域。
ERP allows a peer and server to mutually verify proof of possession of keying 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 described in RFC 3748 [2]. 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.
ERP允许对等方和服务器相互验证拥有早期EAP方法运行的密钥材料的证据，并在对等方和认证方之间建立安全关联。认证器以类似于RFC 3748[2]中描述的EAP认证器的方式充当重新认证协议的传递实体。ERP是对等方和服务器之间的单次往返交换；它独立于较低层和完整EAP交换期间使用的EAP方法。ER服务器可以位于主域中，或者与对等方和验证器位于相同的（访问的）域中。
Figure 2 shows the protocol exchange. The first time the peer attaches to any network, it performs a full EAP exchange (shown in Figure 1) 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 a re-authentication Root Key (rRK). More precisely, a re-authentication Root Key is derived from the EMSK or from a Domain-Specific Root Key (DSRK), which itself is 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, a re-authentication Integrity Key (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.
图2显示了协议交换。对等方第一次连接到任何网络时，它会与EAP服务器执行完整的EAP交换（如图1所示）；结果，MSK被分发到EAP验证器。然后，认证器和对等方使用MSK根据需要建立TSK。在初始EAP交换时，对等方和服务器还派生EMSK，该EMSK用于派生重新认证根密钥（rRK）。更准确地说，重新认证根密钥是从EMSK或特定于域的根密钥（DSRK）派生出来的，其本身是从EMSK派生出来的。rRK仅对对等方和ER服务器可用，从不分发给任何其他实体。此外，从rRK导出重新认证完整性密钥（rIK）；对等方和ER服务器在执行ERP交换时使用rIK提供占有证明。rIK也从不分发给任何实体，只对对等方和服务器可用。
When the ER server is in the home domain, the peer and the server use the rIK and rRK derived from the EMSK; and when the ER server is not in the home 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服务器在归属域中时，对等方和服务器使用从EMSK派生的rIK和rRK；当ER服务器不在主域中时，它们使用与本地域对应的DS rIK和DS rRK。ER服务器的域由ERP消息中的keyname NAI的realm部分标识。
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 1: EAP Authentication
图1:EAP身份验证
Peer Authenticator Server
==== ============= ======
Peer Authenticator 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 2: ERP Exchange
图2：ERP交换
Two new 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 2; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP re-authentication, or prior to
本文件中规定了两个新的EAP代码EAP Initiate和EAP Finish，用于EAP重新认证。当对等方识别出支持EAP重新认证的目标认证器时，它将执行ERP交换，如图2所示；当对等方连接到支持EAP重新身份验证的新身份验证程序时，或在进行重新身份验证之前，交换本身可能发生
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.
附件对等方自行发起ERP；它还可以响应来自新验证器的EAP Initiate/Re auth Start消息而这样做。EAP Initiate/Re auth Start消息允许验证器触发ERP交换。
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, it will send the EAP-Request/ Identity message. Note that this avoids having two EAP messages in flight at the same time [2]. The authenticator may send the EAP-Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. If the peer does not already know, 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 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 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，以及对等方是否通过另一认证者执行了完整的EAP认证，这似乎是合理的。验证器可以通过发送EAP initiate/Re-auth Start消息来启动ERP交换，如果没有响应，它将发送EAP Request/Identity消息。请注意，这样可以避免同时传输两条EAP消息[2]。认证器可发送EAP Initiate/Re-auth Start消息并等待本地配置的短时间。如果对等方还不知道，则此消息向对等方指示验证器支持ERP。为了响应来自认证器的该触发，对等方可以通过发送EAP initiate/Re-auth消息来启动ERP交换。如果在必要的重新传输之后没有来自对等方的响应（参见第6节），则认证者必须通过发送EAP请求消息（通常是EAP请求/标识消息）来启动EAP。注意，认证器在发送EAP请求/标识消息后可能会收到EAP启动/重新认证消息。如果验证器支持ERP，则必须继续进行ERP交换。当EAP请求/身份超时时，如果ERP交换正在进行或已成功建立重新身份验证MSK，则身份验证方不得关闭连接。
If the authenticator does not support ERP, it drops EAP-Initiate/ Re-auth messages [2] as the EAP code of those packets is greater than 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 stage onwards, 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 in the IEEE 802.1X specification [10].
如果验证器不支持ERP，它会丢弃EAP Initiate/Re-auth消息[2]，因为这些数据包的EAP代码大于4。支持ERP的对等方将通过响应来自认证方的EAP请求/标识消息来耗尽EAP发起/重新认证消息的重新传输，并退回到EAP认证。如果对等方不支持ERP，或者没有来自先前EAP身份验证的未过期密钥材料，则会丢弃EAP Initiate/Re auth Start消息。如果EAP Initiate/Re auth Start消息没有响应，则认证者应发送EAP请求消息（通常为EAP请求/标识）以启动EAP认证。从本阶段开始，RFC 3748规则适用。请注意，这可能会在启动EAP时引入一些延迟。在一些较低的层中，对等方通过发送诸如IEEE 802.1X规范中的EAPoL Start之类的消息来发起EAP，可以最小化甚至避免延迟[10]。
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 [4] field to send
对等方发送EAP Initiate/Re-auth消息，该消息包含用于标识ER服务器域和用于保护消息的rIK的密钥名NAI，以及用于重播保护的序列号。EAP Initiate/Re-auth消息受rIK的完整性保护。验证器使用keyName NAI[4]字段中的域发送
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 a re-authentication MSK (rMSK) from the rRK using the sequence number as an input to the key derivation. The server updates the expected sequence number to the received sequence number plus one.
将消息发送到相应的ER服务器。服务器使用keyName来查找rIK。在验证rIK的占有证明和消息的新鲜度之后，服务器使用序列号作为密钥派生的输入，从rRK派生出重新认证MSK（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. Ongoing work in [11] describes 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成功消息一起传输。[11]中正在进行的工作描述了一种额外的密钥分发协议，可用于将rRK从EAP服务器传输到与EAP服务器共享信任关系的多个不同ER服务器之一。
The peer MAY request the server for the rMSK lifetime. 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 request 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 replay protection 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 defined ER extensions allow executing the ERP with an ER server in the local domain (access network). 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 the lower layer or by means of ERP bootstrapping. 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 3 shows the full EAP and subsequent local ERP exchange; Figure 4 shows it with a local ER server.
定义的ER扩展允许在本地域（访问网络）中使用ER服务器执行ERP。本地ER服务器可以与本地AAA服务器位于同一位置。对等方可以通过较低层或通过ERP引导来了解网络中本地ER服务器的存在以及本地域名（或ER服务器名称）。对等方使用域名和EMSK计算DSRK，并根据该密钥计算DS rRK；对等方还使用keyName NAI领域部分中的域名在本地域中使用ERP。图3显示了完整的EAP和随后的本地ERP交换；图4显示了一个本地ER服务器。
Peer EAP Authenticator Local ER Server Home EAP Server
==== ================= =============== ===============
Peer EAP Authenticator Local ER Server Home EAP Server
==== ================= =============== ===============
<-- EAP-Request/ -- Identity
<--EAP请求/--标识
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity) --AAA(EAP Response/ -->
Identity,
[DSRK Request,
domain name])
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity) --AAA(EAP Response/ -->
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 3: Local ERP Exchange, Initial EAP Exchange
图3：本地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 4: Local ERP Exchange
图4：本地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 authenticator and the home EAP server of the peer). In that case, the ER server requests the DSRK by sending the domain name to the EAP server. In response, the EAP server computes the DSRK by following the procedure specified in [3] and sends the DSRK and the key name, EMSKname, to the ER server in the claimed domain. The local domain is responsible for announcing that same domain name via the lower layer to the peer.
如图4所示，本地ER服务器可能存在于完整EAP交换的路径中（例如，这可能是认证器和对等方的家庭EAP服务器之间的路径中的AAA实体之一，例如AAA代理）。在这种情况下，ER服务器通过向EAP服务器发送域名来请求DSRK。作为响应，EAP服务器按照[3]中指定的过程计算DSRK，并将DSRK和密钥名EMSKname发送到声明域中的ER服务器。本地域负责通过较低层向对等方宣布相同的域名。
If the peer does not know the domain name (did not receive the domain name via the lower-layer announcement, due to a missed announcement or lack of support for domain name announcements in a specific lower layer), it SHOULD initiate ERP bootstrap exchange with the home ER server to obtain the domain name. The local ER server SHALL request the home AAA server for the DSRK by sending the domain name in the AAA message that carries the EAP-Initiate/Re-auth bootstrap message. The local ER server MUST be in the path from the peer to the home ER server. If it is not, it cannot request the DSRK.
如果对等方不知道域名（由于错过公告或缺乏对特定较低层域名公告的支持，未通过较低层公告收到域名），则应启动与家庭ER服务器的ERP引导交换以获取域名。本地ER服务器应通过在承载EAP Initiate/Re auth bootstrap消息的AAA消息中发送域名，向家庭AAA服务器请求DSRK。本地ER服务器必须位于从对等服务器到主ER服务器的路径中。如果不是，则无法请求DSRK。
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, 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对应的序列号（初始化为零）。
Subsequently, when the peer 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.
随后，当对等方连接到本地域内的验证器时，它可以与本地ER服务器执行ERP交换以获得新验证器的rMSK。
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) in accordance with [3] for re-authentication. The USRK designated for re-authentication is the re-authentication root key (rRK). A DSUSRK designated for re-authentication is the DS-
rRK源自第4.1节规定的EMSK或DSRK。出于rRK推导的目的，本文件根据[3]规定了用于重新认证的特定于使用的根密钥（USRK）或特定于域的USRK（DSUSRK）的推导。指定用于重新身份验证的USRK是重新身份验证根密钥（rRK）。指定用于重新身份验证的DSUSRK是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 they are derived for, 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.
特定域中的本地ER服务器可用的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和RMSK。下图显示了带有rRK、rIK和RMSK的密钥层次结构。
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
Figure 5: Re-authentication Key Hierarchy
图5：重新验证密钥层次结构
The derivations in this document are according to [3]. Key derivations and field encodings, where unspecified, default to that document.
本文件中的推导依据[3]。未指定的键派生和字段编码默认为该文档。
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 [3].
根据[3]中的规定推导rRK。
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 [3].
根据[3]从“USRK密钥标签”名称空间分配。
The KDF and algorithm agility for the KDF are as defined in [3].
KDF的KDF和算法敏捷性如[3]中所定义。
An rRK derived from the DSRK is referred to as a DS-rRK in the rest of the document. All 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 derivation of 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 re-authentication Integrity Key (rIK) is used for integrity protecting the ERP exchange. This serves as the proof of possession of valid keying 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 encoded as specified in [3].
长度字段是指rIK的长度，以八位字节为单位，按照[3]中的规定进行编码。
The cryptosuite and length of the rIK are part of the input to the key derivation function to ensure cryptographic separation of keys if different rIKs of different lengths 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.
如果用于不同消息认证码（MAC）算法的不同长度的不同rIK来自同一rRK，则加密套件和rIK长度是密钥派生函数输入的一部分，以确保密钥的加密分离。加密套件编码为8位数字；cryptosuite规范见第5.3.2节。
The rIK is referred to by EMSKname-NAI within the context of ERP messages. The username part of EMSKname-NAI is the EMSKname; the realm is the domain name of the ER server. In case of ERP with the home ER server, the peer uses the realm from its original NAI; in 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 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 whose possession 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
rIK是由对等方和ERP服务器向另一方证明其拥有的密钥。对等方通过计算EAP Initiate/Re-auth消息上的完整性校验和来证明其拥有rIK。当对等方第一次使用rIK时，它可以选择与rIK一起使用的完整性算法。对等方和服务器必须使用具有给定rIK的相同完整性算法
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.
使用该密钥保护的所有ERP消息。对等方和服务器在第一次使用后存储算法信息，并且在该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 case of hash-based MAC algorithms, the key is first hashed to the required key length as specified in [5]. In 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算法，密钥首先散列到[5]中指定的所需密钥长度。对于基于密码的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 EAP Re-auth Protocol exchange.
rMSK在对等机和服务器上派生，并传递给验证器。rMSK是在EAP重新验证协议交换之后派生的。
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. The length field is encoded as specified in [3].
长度字段是指rMSK的长度（以八位字节为单位）。长度字段按照[3]中的规定进行编码。
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. All 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 is used at an authenticator.
o rMSK被交付给验证器，并用于与在验证器上使用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 bootstrapping. In implicit bootstrapping, the local ER server SHOULD include its domain name and SHOULD request the DSRK from the home AAA server during the initial EAP exchange, in the AAA message encapsulating the first EAP Response message sent by the peer. If the EAP exchange is successful, the server sends the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [3]), EMSKname, and DSRK lifetime along with the EAP-Success message. The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding the EAP-Success message to the peer, as specified in [12]. Note that the MSK (also present along 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 via lower-layer announcements. 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.
我们确定了ERP的两种引导类型：显式引导和隐式引导。在隐式引导中，本地ER服务器应包括其域名，并应在初始EAP交换期间，在封装对等方发送的第一个EAP响应消息的AAA消息中从家庭AAA服务器请求DSRK。如果EAP交换成功，服务器将发送本地ER服务器的DSRK（使用[3]中指定的EMSK和域名派生）、EMSKname和DSRK生存期以及EAP成功消息。按照[12]中的规定，在将EAP成功消息转发给对等方之前，本地ER服务器必须提取DSRK、EMSKname和DSRK生存期（如果存在）。请注意，MSK（与EAP成功消息一起出现）通常由EAP验证器提取。对等方通过EAP Initiate/Re-auth Start消息或通过下层公告来学习域名。当域名在完整EAP身份验证期间或之后可供对等方使用时，它会在与新身份验证程序关联时尝试使用ERP。
If the peer does not know the domain name (did not receive the domain name via the lower-layer announcement, due to a missed announcement or lack of support for domain name announcements in a specific lower layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with the bootstrap flag turned on) with the home ER server to obtain the
如果对等方不知道域名（由于错过公告或缺乏对特定较低层中的域名公告的支持，未通过较低层公告收到域名），则应与家庭ER服务器启动ERP引导交换（启用引导标志的ERP交换），以获取
domain name. The local ER server behavior is the same as described above. The peer MAY also initiate bootstrapping to fetch information such as the rRK lifetime from the AAA server.
域名。本地ER服务器行为与上述相同。对等方还可以启动引导以从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 turned on. The bootstrap message is always sent to the home AAA 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 对等方在启动标志打开的情况下发送EAP Initiate/Re-auth消息。引导消息始终发送到家庭AAA服务器，引导消息中的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 When an ERP-capable authenticator receives the EAP-Initiate/ Re-auth message from a peer, it copies the contents of the keyName-NAI into the User-Name attribute of RADIUS [13]. The rest of the process is similar to that described in [14] and [12].
o 当支持ERP的验证器从对等方接收到EAP Initiate/Re auth消息时，它会将keyName NAI的内容复制到RADIUS的用户名属性中[13]。该过程的其余部分类似于[14]和[12]中所述。
o If a local ER server is present, the local ER server MUST include the DSRK request and its domain name in the AAA message encapsulating the EAP-Initiate/Re-auth message sent by the peer.
o 如果存在本地ER服务器，则本地ER服务器必须在AAA消息中包含DSRK请求及其域名，该AAA消息封装了对等方发送的EAP Initiate/Re auth消息。
o Upon receipt of an EAP-Initiate/Re-auth message, the 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 server then verifies to ensure that the cryptosuite used by the peer is acceptable. Next, it verifies the origin authentication of the message by looking up the rIK. If any of the checks fail, the 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消息后，服务器通过评估接收到的序列号是否等于或大于该rIK的预期序列号来验证该消息是新消息还是重播消息。然后服务器进行验证，以确保对等方使用的cryptosuite是可接受的。接下来，它通过查找rIK来验证消息的原始身份验证。如果任何检查失败，服务器将发送一条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 and a DSRK request is received, the server MUST include the domain name to which the DSRK is being sent.
* 如果设置了引导标志并接收到DSRK请求，则服务器必须包括向其发送DSRK的域名。
* If the home ER server verifies the authorization of a local domain 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服务器验证本地域服务器的授权，则其可以包括授权指示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 ERP exchange is successful, and the local ER server sent a DSRK request, the home ER server MUST include the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [3]), EMSKname, and DSRK lifetime along with the EAP-Finish/Re-auth message.
o 如果ERP交换成功，并且本地ER服务器发送了DSRK请求，则家庭ER服务器必须包括本地ER服务器的DSRK（使用[3]中指定的EMSK和域名派生）、EMSKname和DSRK生存期以及EAP完成/重新验证消息。
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth message, in a AAA attribute [12].
o 此外，rMSK与EAP Finish/Re auth消息一起以AAA属性发送[12]。
o The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present), before forwarding the EAP-Finish/Re-auth message to the peer, as specified in [12].
o 按照[12]中的规定，在将EAP Finish/Re auth消息转发给对等方之前，本地ER服务器必须提取DSRK、EMSKname和DSRK生存期（如果存在）。
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 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 the ERP and obtaining relevant keys using RADIUS and Diameter are specified in [12] and [15], respectively.
o [12]和[15]分别规定了封装ERP和使用半径和直径获取相关密钥的程序。
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, 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.
当具有活动rRK和rIK的对等方与支持ERP的新验证器关联时，它可以与该验证器执行ERP交换。ERP通常是由对等方发起的交换，由EAP Initiate/Re-auth和EAP Finish/Re-auth消息组成。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 the 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节的可靠性考虑适用于对等方作为重传实体。
The EAP Re-auth Protocol has the following steps:
EAP重新验证协议具有以下步骤：
The peer sends an EAP-Initiate/Re-auth message. At a minimum, the message SHALL include the following fields:
对等方发送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 over the message.
消息上的身份验证标记。
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 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.
当对等方使用本地ER服务器执行ERP时，它必须使用与本地ER服务器共享的相应DS rIK。对等方应设置生存期标志以从服务器请求密钥生存期。对等方可以使用rRK生存期来知道何时触发EAP方法交换，使用rMSK生存期来知道何时触发另一个ERP交换。
The authenticator copies the contents of the value field of the keyName-NAI TLV into the User-Name RADIUS attribute in the AAA message to the ER server.
验证器将keyName NAI TLV的值字段的内容复制到AAA消息中的用户名RADIUS属性中，并发送到ER服务器。
The 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 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 server MUST then verify to ensure that the cryptosuite used by the peer is acceptable. The 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 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.
服务器使用keyName NAI来查找rIK。它必须首先验证序列号是否等于或大于预期序列号。如果服务器支持大于1的序列号窗口大小，则必须验证序列号是否在该窗口内，并且以前是否未收到该序列号。然后，服务器必须进行验证，以确保对等方使用的cryptosuite是可接受的。然后，服务器使用rIK继续验证消息的完整性，从而验证对等方拥有该密钥的证据。如果这些验证中的任何一个失败，服务器必须发送一条EAP Finish/Re auth消息，其结果标志设置为“1”（失败）。有关故障处理的详细信息，请参阅第5.2.2节。否则，它必须使用序列号作为密钥派生的附加输入，从rRK计算rMSK。
In response to a well-formed EAP Re-auth/Initiate message, the server MUST send an EAP-Finish/Re-auth message with the following considerations:
为了响应格式良好的EAP重新验证/启动消息，服务器必须发送EAP完成/重新验证消息，并考虑以下事项：
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 server supports multiple simultaneous ERP exchanges, it MUST instead update the sequence number window.
用于重播保护的16位序列号，必须与接收到的序列号相同。序列号的本地副本必须增加1。如果服务器支持多个同时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 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生存期。
The server transports the rMSK along with this message to the authenticator. The rMSK is transported in a manner similar to the MSK transport along with the EAP-Success message in a regular EAP exchange.
服务器将rMSK与此消息一起传输到验证器。rMSK以类似于MSK传输的方式在常规EAP交换中与EAP成功消息一起传输。
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.
对等方查找序列号以验证是否期望EAP Finish/Re auth消息，该序列号受keyName NAI保护。然后验证消息的完整性。如果验证失败，对等方记录错误并停止该过程；否则，将进入下一步。
The peer uses the sequence number to compute the rMSK.
对等方使用序列号来计算rMSK。
The lower-layer security association protocol can be triggered at this point.
此时可以触发下层安全关联协议。
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 SEQ number values within a window of allowed values. Recall that the SEQ number allows replay protection. Replay window maintenance mechanisms are a local matter.
为了促进这种操作，ER服务器可以通过在允许的值窗口内接受具有SEQ number值的所有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. 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 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 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进行计算，为后续ERP交换使用适当的rIK。如果所选加密套件中的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 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 imply 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 new 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 RFC 3748 [2].
为ERP的目的定义了两个新的EAP代码：EAP Initiate和EAP Finish。这些消息的数据包格式遵循RFC 3748[2]中定义的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 6: EAP Packet
图6:EAP数据包
Code
密码
5 Initiate
5发起
6 Finish
6完成
Two new code values are defined for the purpose of ERP.
为了ERP的目的，定义了两个新的代码值。
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 a Finish message. Any new (non-retransmission) Initiate message MUST use a new Identifier field.
标识符字段是一个八位字节。如果在等待完成消息时由于超时而重新传输EAP Initiate数据包，则标识符字段必须相同。任何新的（非重传）启动消息都必须使用新的标识符字段。
The Identifier field of the Finish message MUST match that of the currently outstanding Initiate message. A peer or authenticator receiving a Finish message whose Identifier value does not match that of the currently outstanding Initiate message MUST silently discard the packet.
完成消息的标识符字段必须与当前未完成的启动消息的标识符字段匹配。接收到其标识符值与当前未完成的发起消息的标识符值不匹配的完成消息的对等方或验证器必须以静默方式丢弃该数据包。
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 (assigned Type 1) and Re-auth (assigned Type 2).
此字段表示这是ERP交换。为此，本文档中定义了两个类型值——重新授权开始（分配类型1）和重新授权（分配类型2）。
Type-Data
类型数据
The Type-Data field varies with the Type of re-authentication packet.
类型数据字段随重新身份验证数据包的类型而变化。
The EAP-Initiate/Re-auth-Start packet contains the parameters shown in Figure 7.
EAP Initiate/Re auth Start数据包包含图7所示的参数。
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 7: EAP-Initiate/Re-auth-Start Packet
图7:EAP启动/重新验证启动数据包
Type = 1.
类型=1。
Reserved, MUST be zero. Set to zero on transmission and ignored on reception.
保留，必须为零。传输时设置为零，接收时忽略。
One or more 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 [4]. The Domain-Name attribute SHOULD be present in an EAP-Initiate/Re-auth-Start message.
域名：这是TLV有效载荷。类型是4。域名将用作NAI中的领域[4]。域名属性应出现在EAP Initiate/Re-auth Start消息中。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 11 for parameter specification.
此外，可以包括信道绑定信息；有关讨论，请参见第5.5节。有关参数说明，请参见图11。
The authenticator MAY 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 lower-layer support or the ERP bootstrapping exchange.
认证者可以向对等方发送EAP发起/重新认证开始消息以指示对ERP的支持，并且如果对等方已经执行了完全EAP认证并且具有未过期的密钥材料，则认证者可以发起ERP。验证器应包括域名TLV，以允许对等方在没有较低层支持或ERP引导交换的情况下学习该域名。
The authenticator MAY include channel binding information so that the peer can send the information to the server in the EAP-Initiate/ Re-auth message so that the server can verify whether the authenticator is claiming the same identity to both parties.
验证器可以包括信道绑定信息，以便对等方可以在EAP Initiate/Re auth消息中向服务器发送信息，以便服务器可以验证验证器是否向双方声明相同的身份。
The authenticator MAY re-transmit 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 Initiate code value, it silently discards the message. If the peer has already sent the EAP-Initiate/ Re-auth message to begin the ERP exchange, it silently discards the message.
对等方应发送EAP Initiate/Re-auth消息，以响应来自验证器的EAP Initiate/Re-auth Start消息。如果对等方无法识别Initiate code值，则会自动丢弃该消息。如果对等方已发送EAP Initiate/Re-auth消息以开始ERP交换，则会自动丢弃该消息。
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 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 the peer has already initiated an ERP exchange with the home ER server, it MAY choose to not start an ERP exchange with the local ER server.
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 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 the peer has already initiated an ERP exchange with the home ER server, it MAY choose to not start an ERP exchange with the local ER server.translate error, please retry
The EAP-Initiate/Re-auth packet contains the parameters shown in Figure 8.
EAP Initiate/Re-auth数据包包含图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 |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 8: EAP-Initiate/Re-auth Packet
图8: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 rest of the 5 bits are set to 0 and ignored on reception.
其余5位设置为0，接收时忽略。
SEQ: A 16-bit sequence number is used for replay protection. The SEQ number field is initialized to 0 every time a new rRK is derived.
序列号：16位序列号用于重播保护。每次导出新的rRK时，SEQ number字段初始化为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 length and so the username portion takes up 128 octets. If the rIK is
keyName NAI：这是在TLV有效载荷中携带的。类型是1。NAI长度可变，不超过253个八位字节。EMSKname位于NAI的用户名部分，并以十六进制值编码。EMSKname的长度为64位，因此用户名部分占128个八位字节。如果风险是
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 follows [4]. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet.
从EMSK派生，NAI的领域部分是主域名，如果rIK派生自DSRK，则NAI的领域部分是派生DSRK时使用的域名。NAI语法如下[4]。EAP Initiate/Re-auth数据包中应仅存在一个keyName NAI属性。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 11 for parameter specification.
此外，可以包括信道绑定信息；有关讨论，请参见第5.5节。有关参数说明，请参见图11。
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 9.
EAP Finish/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-Finish/Re-auth Packet
图9: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 rest of the 5 bits are set to 0 and ignored on reception.
其余5位设置为0，接收时忽略。
SEQ: A 16-bit sequence number is used for replay protection. The SEQ number field is initialized to 0 every time a new rRK is derived.
序列号：16位序列号用于重播保护。每次导出新的rRK时，SEQ number字段初始化为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 follows [4]. 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派生中使用的域名。NAI语法如下[4]。EAP完成/重新验证消息中应仅存在一个keyName NAI属性实例。
rRK Lifetime: This is a TV payload. The Type is 2. The value field is a 32-bit field and contains 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 is a 32-bit field and contains 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 [4]. 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中的领域[4]。如果设置了引导标志并且本地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 8. 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 to the peer about its cryptographic algorithm capabilities.
加密套件列表：这是TLV有效负载。类型是5。值字段包含一个cryptosuites列表，每个大小为1个八位字节。cryptosuite值如图8所示。如果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 ER 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 that the DSRK is being derived for.
授权指示：这是TLV有效载荷。类型是6。当DSRK被传递到本地ER服务器时，并且如果家庭ER服务器可以验证本地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 11 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节。有关参数说明，请参见图11。服务器发送此信息，以便对等方可以验证在较低层看到的信息（如果支持通道绑定）。
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 10: TV Attribute Format
图10: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 11: TLV Attribute Format
图11: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 and Finish/Re-auth messages. Below are the current assignments (all of them are TLVs):
保留TLV类型范围128-191，以便在EAP Initiate和Finish/Re auth消息中携带通道绑定信息。以下是当前分配（所有分配均为TLV）：
'128' - Called-Station-Id [13]
“128”-被叫站Id[13]
'129' - Calling-Station-Id [13]
“129”-呼叫站Id[13]
'130' - NAS-Identifier [13]
“130”-NAS标识符[13]
'131' - NAS-IP-Address [13]
“131”-NAS IP地址[13]
'132' - NAS-IPv6-Address [16]
“132”-NAS-IPv6-Address[16]
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 per rIK and is initialized to zero in both directions. In the first EAP-Initiate/Re-auth message, the peer uses the sequence number zero or higher. Note that the when the sequence number rotates, the rIK MUST be changed by running 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 accepts sequence numbers greater than or equal to the expected sequence number.
对于重播保护，ERP使用序列号。序列号按rIK进行维护，并在两个方向上初始化为零。在第一条EAP Initiate/Re-auth消息中，对等方使用序列号0或更高。请注意，当序列号旋转时，必须通过运行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 pre-configured number of times before giving up. However, it is plausible that the server itself may have responded to the message and it 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. When the sequence number rotates, 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 in Section 7.15 of [2]. 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 IANA managed based on IETF Consensus [17].
根据[2]第7.15节中的指南，ERP提供了一个受保护的设施来传输通道绑定（CB）信息。TLV类型范围128-191保留为在EAP Initiate/Re-auth和EAP Finish/Re-auth消息中携带CB信息。被叫站Id、主叫站Id、NAS标识符、NAS IP地址和NAS-IPv6-Address是RFC 3748中列出的信道绑定信息的一些示例，它们是分配值128-132。根据IETF共识，IANA管理其他值[17]。
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 may not know whether the peer supports ERP; in those cases, the peer may be silently dropping 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 (this is based on the recommendation of [2]). 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 [2] for additional guidance on setting timers.
重新传输的数据包必须使用相同的标识符值发送，以便将其与新数据包区分开来。默认情况下，如果EAP Initiate消息通过不可靠的较低层发送，则应动态估计重传计时器。建议最多3-5次重传（这是基于[2]的建议）。如果EAP Initiate消息通过可靠的较低层发送，则应将重传计时器设置为无限值，以便在EAP层不会发生重传。请参考RFC 3748[2]了解有关设置计时器的更多指导。
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, the IEEE802.1x specification must be revised to allow carrying EAP messages of the new codes defined in this document in order to support ERP. Similarly, RFC 4306 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，可能需要修改下层规范。具体而言，必须修订IEEE802.1x规范，以允许承载本文件中定义的新代码的EAP消息，以支持ERP。同样，必须更新RFC 4306，以包括高于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; peers may learn whether an authenticator supports ERP via configuration, from advertisements at the lower layer.
我们的分析表明，一些EAP实现不符合RFC 3748，而不是默默地丢弃具有高于4的代码值的EAP包，它们可能认为是错误。为适应此类不合规的EAP实施，下文提供了额外的指导。此外，在某些情况下升级所有对等点可能并不容易。在这种情况下，认证器可被配置为不发送EAP Initiate/Re auth Start；对等方可以从较低层的广告中了解验证器是否通过配置支持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 an 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., piggy-backed on a beacon) or through negotiation. Alternatively, clients may recognize environments where ERP is available based on pre-configuration. 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 in [11] and [12].
[11]和[12]中规定了ERP消息的AAA传输。
This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in [18].
本节根据[18]中规定的AAA密钥管理要求对协议进行了分析。
Cryptographic algorithm independence
密码算法独立性
The EAP Re-auth Protocol 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 with Failure indication. Algorithm agility for the KDF is specified in [3]. Only when the algorithms used are acceptable, the server proceeds with derivation of keys and verification of the proof of possession of relevant keying material 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.
EAP重新认证协议满足这一要求。对等方为MAC生成选择的算法在EAP Initiate/Re-auth消息中指示。如果所选算法不可接受，EAP服务器将返回带有故障指示的EAP Finish/Re auth消息。[3]中规定了KDF的算法灵活性。只有当所使用的算法可接受时，服务器才继续推导密钥，并验证对等方拥有相关密钥材料的证据。一个完整的算法协商不能在单一的往返协议中提供。因此，虽然协议提供了算法灵活性，但它不提供真正的协商。
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 a different rMSK at any time.
ERP导致派生出对给定会话唯一的强、新密钥。当对等方需要具有新身份验证器的密钥时，rMSK总是按需派生。该推导确保一个rMSK的折衷在任何时候都不会导致不同rMSK的折衷。
Limit 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 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。在验证接收到的消息的有效性后，服务器将预期序列号设置为接收到的序列号加上一，并响应消息。
Authenticate all parties
认证各方
The EAP Re-auth Protocol provides mutual authentication of the peer and the server. Both parties need to possess the keying 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.
EAP重新认证协议提供对等方和服务器的相互认证。双方需要拥有先前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 that exchanged within the AAA protocol.
作为低层安全关联协议的一部分，对等方和认证方在不公开的情况下证明拥有相同的密钥材料。当较低层中使用的身份与AAA协议中交换的身份不同时，可使用与ERP的信道绑定来验证交换的身份的一致性。
Keying 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 an DSRK retroactively compromises all ERP keys.
请注意，DSRK的折衷会导致从它派生的所有密钥的折衷。此外，ERP中没有前向保密。因此，DSRK的泄露会追溯到所有ERP密钥。
It is RECOMMENDED that the AAA protocol be protected using IPsec or 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 ER 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 as that received the DSRK originally. If the home ER server verifies authorization of a local domain server, it MAY hand
家庭ER服务器不得多次向本地域服务器分发给定的DSRK，除非它可以验证在第一次之后接收DSRK的实体与最初接收DSRK的实体相同。如果家庭ER服务器验证本地域服务器的授权，它可能会
out the DSRK to that domain more than once. In this case, the home ER server includes the Authorization Indication TLV to assure the peer that DSRK delivery is secure.
多次将DSRK输出到该域。在这种情况下，家庭ER服务器包括授权指示TLV，以确保对等方DSRK交付是安全的。
Confirm cryptosuite selection
确认加密套件选择
Crypto 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 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.
ERP环境下完整性和密钥推导的加密算法可能与EAP方法使用的相同。在这种情况下，EAP方法负责确认cryptosuite选择。此外，加密套件由对等方包含在ERP交换中，并由服务器确认。该协议允许服务器拒绝对等方选择的cryptosuite并提供替代方案。当对等方无法使用合适的rIK时，可以不受保护的方式发送备选方案。允许对等方使用允许的加密套件之一重试交换。但是，在这种情况下，服务器发送的对列表的任何途中修改都不会被检测到。如果服务器确实有可供对等方使用的rIK，则该列表将以受保护的方式提供，此问题不适用。
Uniquely named keys
唯一命名的密钥
All keys produced within the ERP context can be referred to uniquely as specified in this document. Also, the key names do not reveal any part of the keying material.
在ERP上下文中生成的所有密钥都可以按照本文档中的规定进行唯一引用。此外，键名称不会显示键控材质的任何部分。
Prevent the domino effect
防止多米诺效应
The compromise of one peer does not result in the compromise of keying 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. Hence, the EAP Re-auth Protocol allows prevention of the domino effect by appropriately defining key scope.
一个对等方的泄露不会导致系统中任何其他对等方持有的密钥材料泄露。此外，rMSK用于单个验证器，不与任何其他验证器共享。因此，一个验证器的泄露不会导致系统中任何其他验证器持有的会话或密钥泄露。因此，EAP-Re-auth协议允许通过适当定义密钥范围来防止多米诺效应。
However, if keys are transported using hop-by-hop protection, compromise of a proxy may result in compromise of key material, i.e., the DSRK being sent to a local ER server.
然而，如果使用逐跳保护传输密钥，则代理的泄露可能导致密钥材料的泄露，即DSRK被发送到本地ER服务器。
Bind key to its context
将键绑定到其上下文
All the keys derived for ERP are bound to the appropriate context using appropriate key labels. Lifetime of a child key is less than or equal to that of its parent key as specified in RFC 4962 [18]. The key usage, lifetime and the parties that have access to the keys are specified.
为ERP派生的所有键都使用适当的键标签绑定到适当的上下文。子密钥的生存期小于或等于RFC 4962[18]中规定的父密钥的生存期。指定了密钥的使用、生存期和有权访问密钥的各方。
Confidentiality of identity
身份保密
Deployments where privacy is a concern may find the use of 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 the ERP protocol. 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 keys derived 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. Any other restrictions of session keys may be imposed by the specific lower layer and are out of scope for this specification.
所有派生的密钥在生存期内都受到父密钥的生存期或服务器策略的限制。任何特定于域的密钥都进一步限制仅在为其派生密钥的域中使用。本文档中指定的所有密钥仅供ERP使用。会话密钥的任何其他限制可能由特定的较低层施加，超出本规范的范围。
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 RADIUS-Access-Request to the server; in response, the server may send an EAP-Finish/Re-auth with Failure indication in a RADIUS Access-Reject message. Note that such attacks may be plausible 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 RADIUS Access-Reject message, thus resulting in the link-layer connections being terminated.
使用EAP Initiate/Re-auth消息时，可能会对对等方发起拒绝服务（DoS）攻击。攻击者可以向服务器发送伪造的EAP Initiate/Re-auth消息，该消息可能由身份验证器在RADIUS访问请求中携带；作为响应，服务器可以在RADIUS访问拒绝消息中发送EAP Finish/Re auth，并显示失败指示。请注意，在IEEE 802.11的EAPoL启动功能和其他链路层中的其他类似设施以及对等方可以启动EAP身份验证的情况下，此类攻击可能是合理的。攻击者可使用此类消息启动EAP方法运行，该方法运行失败，并可能导致服务器发送RADIUS访问拒绝消息，从而导致链路层连接终止。
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 keying materials for the same peer to exist so that smooth migration from the current link layer SA to the
为防止此类DoS攻击，ERP故障不应导致删除由完整EAP交换建立的任何授权状态。或者，较低层和AAA协议可以定义机制，以允许从同一对等方的不同EAP键控材料派生的两个链路层安全关联（SA）存在，以便从当前链路层SA平滑迁移到该对等方
new one is possible during rekey. These mechanisms prevent the link layer connections from being terminated when a re-authentication procedure fails due to the bogus EAP-Initiate/Re-auth message.
在重新设置密钥期间，可以使用新的密钥。当由于伪EAP Initiate/re-auth消息导致重新身份验证过程失败时，这些机制可防止链路层连接终止。
When a DSRK is sent from a home ER server to a local domain server or when a 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 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.
当DSRK从家庭ER服务器发送到本地域服务器时，或者当rMSK从ER服务器发送到验证器时，在发送密钥的实体和接收密钥的实体之间缺乏端到端安全性的情况下，其他实体可以访问发送到另一域中ER服务器的密钥。这种密钥传输模式类似于EAP身份验证上下文中的MSK传输模式。我们进一步观察到，ERP用于访问身份验证，不支持端到端数据安全。在典型的实现中，通信量在访问控制实施点（认证者或认证者授权的用于访问控制实施的实体）之外的空白处。只要网络中间的实体不使用用于其他方从接入网络窃取服务的密钥，该模型就起作用。如果无法实现，则必须以端到端的方式保护密钥传递。
This document specifies IANA registration of two new 'Packet Codes' from the EAP registry:
本文件规定了EAP注册表中两个新“数据包代码”的IANA注册：
o 5 (Initiate)
o 5（发起）
o 6 (Finish)
o 6（完成）
These values are in accordance with [2].
这些数值符合[2]。
This document also specifies creation of a new table, Message Types, in the EAP registry with the following assigned numbers:
本文档还指定在EAP注册表中创建一个新表Message Types，并使用以下分配的编号：
o 0 Reserved
o 0保留
o 1 (Re-auth-Start, applies to Initiate Code only)
o 1（重新验证启动，仅适用于启动代码）
o 2 (Re-auth, applies to Initiate and Finish Codes)
o 2（重新认证，适用于启动和完成代码）
o 3-191 IANA managed and assigned based on IETF Consensus [17]
o 3-191根据IETF共识管理和分配IANA[17]
o 192-255 Private use
o 192-255私人使用
Next, we specify creation of a new table, EAP Initiate and Finish Attributes, associated with EAP Initiate and Finish messages in the EAP registry with the following assigned numbers.
接下来，我们指定创建一个新表EAP Initiate和Finish Attributes，该表与EAP注册表中的EAP Initiate和Finish消息关联，并带有以下分配的编号。
o 0: Reserved
o 0:保留
o keyName-NAI: This is a TLV payload. The Type is 1.
o keyName NAI：这是TLV有效载荷。类型是1。
o rRK Lifetime: This is a TV payload. The Type is 2.
o rRK寿命：这是一个电视有效载荷。类型是2。
o rMSK Lifetime: This is a TV payload. The Type is 3.
o rMSK寿命：这是一个电视有效载荷。类型是3。
o Domain name: This is a TLV payload. The Type is 4.
o 域名：这是TLV有效载荷。类型是4。
o Cryptosuite list: This is a TLV payload. The Type is 5.
o Cryptosuite列表：这是TLV负载。类型是5。
o Authorization Indication: This is a TLV payload. The Type is 6.
o 授权指示：这是TLV有效载荷。类型是6。
o 7-127: Used to carry other non-channel-binding-related attributes. IANA managed and assigned based on IETF Consensus [17].
o 7-127：用于携带其他非通道绑定相关属性。IANA根据IETF共识进行管理和分配[17]。
o 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. Below are the current assignments (all of them are TLVs):
o TLV类型范围128-191保留为在EAP Initiate/Re-auth和EAP Finish/Re-auth消息中携带CB信息。以下是当前分配（所有分配均为TLV）：
* Called-Station-Id: 128
* 被叫电台号码：128
* Calling-Station-Id: 129
* 电话号码：129
* NAS-Identifier: 130
* NAS标识符：130
* NAS-IP-Address: 131
* NAS IP地址：131
* NAS-IPv6-Address: 132
* NAS-IPv6-IP地址：132
133-191: Used to carry other channel-binding-related attributes. IANA managed and assigned based on IETF Consensus [17].
133-191：用于携带其他通道绑定相关属性。IANA根据IETF共识进行管理和分配[17]。
o 192-255: Reserved for Private use.
o 192-255：保留供私人使用。
We specify creation of another registry, 'Re-authentication Cryptosuites', with the following assigned numbers:
我们指定创建另一个注册表“重新验证加密套件”，并使用以下分配的编号：
o 0: Reserved
o 0:保留
o 1: HMAC-SHA256-64
o 1:HMAC-SHA256-64
o 2: HMAC-SHA256-128
o 2:HMAC-SHA256-128
o 3: HMAC-SHA256-256
o 3:HMAC-SHA256-256
o 4-191: IANA managed and assigned based on IETF consensus [17]
o 4-191：根据IETF共识管理和分配IANA[17]
o 192-255: Reserved for Private use.
o 192-255：保留供私人使用。
Further, this document registers a Re-auth usage label from the "USRK Key Labels" name space with a value
此外，本文档使用值从“USRK密钥标签”名称空间注册重新验证使用标签
EAP Re-authentication Root Key@ietf.org
EAP重新身份验证根目录Key@ietf.org
and DSRK-authorized delivery key from the "USRK Key Labels" name space
以及“USRK密钥标签”名称空间中的DSRK授权交付密钥
DSRK Delivery Authorized Key@ietf.org
DSRK授权交付Key@ietf.org
in accordance with [3].
根据[3]。
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. The credit for the idea to use EAP-Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link-layer SAs idea to mitigate the DoS attack 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 rIKname when sent as part of keyName-NAI field. Thanks to Bernard Aboba for suggestions in clarifying the EAP lock-step operation, and 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工作组的其他参与者。使用EAP Initiate/Re-auth Start的想法归功于Charles Clancy，而使用多链路层SAs来缓解DoS攻击的想法归功于Yoshi Ohba。Katrin Hoeper建议使用窗口技术来处理多个同时的ER交换。非常感谢Pasi Eronen的建议，当作为keyName NAI字段的一部分发送时，rIKname使用十六进制编码。感谢Bernard Aboba在澄清EAP锁定步骤操作方面提出的建议，以及Joe Salowey和Glen Zorn在指定ERP消息的AAA传输方面提供的帮助。感谢Sam Hartman提供的DSRK授权指示机制。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[2] Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[3] 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.
[3] Salowey，J.，Dondeti，L.，Narayanan，V.，和M.Nakhjiri，“从扩展主会话密钥（EMSK）派生根密钥的规范”，RFC 52952008年8月。
[4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[4] Aboba，B.，Beadles，M.，Arkko，J.，和P.Eronen，“网络接入标识符”，RFC 42822005年12月。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[6] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[6] Arkko，J.和H.Haverinen，“第三代认证和密钥协议（EAP-AKA）的可扩展认证协议方法”，RFC 4187，2006年1月。
[7] 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.
[7] Lopez，R.，Skarmeta，A.，Bournelle，J.，Laurent Maknavicus，M.，和J.Combes，“用于安全移动接入服务的改进EAP键控框架”，IWCM'06，2006年无线通信和移动计算国际会议记录，美国纽约，2006年。
[8] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work in Progress, October 2003.
[8] Arbaugh，W.和B.Aboba，“向RADIUS的切换扩展”，正在进行的工作，2003年10月。
[9] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
[9] Clancy，T.，Nakhjiri，M.，Narayanan，V.，和L.Dondeti，“移交密钥管理和重新认证问题声明”，RFC 5169，2008年3月。
[10] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004", December 2004.
[10] 电气和电子工程师协会，“局域网和城域网IEEE标准：基于端口的网络访问控制，IEEE标准802.1X-2004”，2004年12月。
[11] Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management of EAP based keys for handover and re-authentication", Work in Progress, February 2008.
[11] Nakhjiri，M.和Y.Ohba，“用于移交和重新认证的基于EAP的密钥的推导、交付和管理”，正在进行的工作，2008年2月。
[12] Gaonkar, K., Dondeti, L., Narayanan, V., and G. Zorn, "RADIUS Support for EAP Re-authentication Protocol", Work in Progress, February 2008.
[12] Gaonkar，K.，Dondeti，L.，Narayanan，V.，和G.Zorn，“EAP再认证协议的RADIUS支持”，正在进行的工作，2008年2月。
[13] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[13] Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[14] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[14] Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[15] Dondeti, L. and H. Tschofenig, "Diameter Support for EAP Re-authentication Protocol", Work in Progress, November 2007.
[15] Dondeti，L.和H.Tschofenig，“EAP再认证协议的直径支持”，正在进行的工作，2007年11月。
[16] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[16] Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC3162001年8月。
[17] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[17] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[18] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[18] Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start]
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]，身份验证标记*）
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
作者地址
Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
Vidya Narayanan高通公司5775美国加利福尼亚州圣地亚哥Morehouse博士，邮编92121
Phone: +1 858-845-2483
EMail: vidyan@qualcomm.com
Phone: +1 858-845-2483
EMail: vidyan@qualcomm.com
Lakshminath Dondeti Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
Lakshminath Dondeti高通公司5775 Morehouse Dr.圣地亚哥，加利福尼亚州，美国92121
Phone: +1 858-845-1267
EMail: ldondeti@qualcomm.com
Phone: +1 858-845-1267
EMail: ldondeti@qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.