Internet Engineering Task Force (IETF) G. Zorn, Ed.
Request for Comments: 6697 Network Zen
Category: Informational Q. Wu
ISSN: 2070-1721 T. Taylor
Huawei
Y. Nir
Check Point
K. Hoeper
Motorola Solutions, Inc.
S. Decugis
INSIDE Secure
July 2012
Internet Engineering Task Force (IETF) G. Zorn, Ed.
Request for Comments: 6697 Network Zen
Category: Informational Q. Wu
ISSN: 2070-1721 T. Taylor
Huawei
Y. Nir
Check Point
K. Hoeper
Motorola Solutions, Inc.
S. Decugis
INSIDE Secure
July 2012
Handover Keying (HOKEY) Architecture Design
切换键控（HOKEY）体系结构设计
Abstract
摘要
The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.
切换键控（HOKEY）工作组寻求在对等方从一个连接点移动到另一个连接点时，将由于身份验证而导致的切换延迟降至最低。在减少切换延迟的两种不同方法上取得了进展：早期身份验证（以便在切换期间不需要执行身份验证）和重用初始身份验证期间生成的加密材料以节省重新身份验证期间的时间。基本假设是，移动主机或“对等方”最初使用可扩展认证协议（EAP）进行认证，该协议在对等方和EAP服务器之间执行，如RFC 3748中所定义。
This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group.
本文件定义了HOKEY体系结构。具体而言，它描述了设计目标、切换键控操作的功能环境、HOKEY体系结构本身要执行的功能，以及将这些功能分配给体系结构组件。它接着说明了体系结构在各种部署场景中的操作，这些场景在HOKEY工作组生成的其他文档中有更全面的描述。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6697.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6697.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................6
3. Design Goals ....................................................6
3.1. Reducing Signaling Overhead ................................7
3.1.1. Minimized Communications with Home Servers ..........7
3.1.2. Minimized User Interaction for Authentication .......7
3.2. Integrated Local Domain Name (LDN) Discovery ...............7
3.3. Fault-Tolerant Re-Authentication ...........................8
3.4. Improved Deployment Scalability ............................8
4. Required Functionality ..........................................8
4.1. Authentication Subsystem Functional Overview ...............8
4.2. Pre-Authentication Function (Direct or Indirect) ...........9
4.3. EAP Re-Authentication Function .............................9
4.4. EAP Authentication Function ...............................10
4.5. Authenticated Anticipatory Keying (AAK) Function ..........10
4.6. Management of EAP-Based Handover Keys .....................10
5. Components of the HOKEY Architecture ...........................11
5.1. Functions of the Peer .....................................12
5.2. Functions of the Serving Authenticator ....................13
5.3. Functions of the Candidate Authenticator ..................14
5.4. Functions of the EAP Server ...............................15
5.5. Functions of the ER Server ................................16
6. Usage Scenarios ................................................16
6.1. Simple Re-Authentication ..................................16
6.2. Intra-Domain Handover .....................................17
6.3. Inter-Domain Handover .....................................17
6.4. Inter-Technology Handover .................................17
7. AAA Considerations .............................................17
7.1. Authorization .............................................17
7.2. Transport Aspect ..........................................18
8. Security Considerations ........................................18
9. Acknowledgments ................................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
1. Introduction ....................................................3
2. Terminology .....................................................6
3. Design Goals ....................................................6
3.1. Reducing Signaling Overhead ................................7
3.1.1. Minimized Communications with Home Servers ..........7
3.1.2. Minimized User Interaction for Authentication .......7
3.2. Integrated Local Domain Name (LDN) Discovery ...............7
3.3. Fault-Tolerant Re-Authentication ...........................8
3.4. Improved Deployment Scalability ............................8
4. Required Functionality ..........................................8
4.1. Authentication Subsystem Functional Overview ...............8
4.2. Pre-Authentication Function (Direct or Indirect) ...........9
4.3. EAP Re-Authentication Function .............................9
4.4. EAP Authentication Function ...............................10
4.5. Authenticated Anticipatory Keying (AAK) Function ..........10
4.6. Management of EAP-Based Handover Keys .....................10
5. Components of the HOKEY Architecture ...........................11
5.1. Functions of the Peer .....................................12
5.2. Functions of the Serving Authenticator ....................13
5.3. Functions of the Candidate Authenticator ..................14
5.4. Functions of the EAP Server ...............................15
5.5. Functions of the ER Server ................................16
6. Usage Scenarios ................................................16
6.1. Simple Re-Authentication ..................................16
6.2. Intra-Domain Handover .....................................17
6.3. Inter-Domain Handover .....................................17
6.4. Inter-Technology Handover .................................17
7. AAA Considerations .............................................17
7.1. Authorization .............................................17
7.2. Transport Aspect ..........................................18
8. Security Considerations ........................................18
9. Acknowledgments ................................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
The Extensible Authentication Protocol (EAP) [RFC3748] is an authentication framework that supports different types of authentication methods. Originally designed for dial-up connections, EAP is now commonly used for authentication in a variety of access networks.
可扩展身份验证协议（EAP）[RFC3748]是一个支持不同类型身份验证方法的身份验证框架。EAP最初设计用于拨号连接，现在常用于各种接入网络中的身份验证。
When a host (or "peer", the term used from this point onward) changes its point of attachment to the network, it must be re-authenticated. If a full EAP authentication must be repeated, several message round trips between the peer and the home EAP server may be involved. The resulting delay will result in degradation -- or, in the worst case, loss of any service session in progress -- if communication is suspended while re-authentication is carried out. The delay is worse if the new point of attachment is in a visited network rather than the peer's home network because of the extra procedural steps involved as well as the probable increase in round-trip time.
当主机（或“对等方”，从这一点开始使用的术语）更改其与网络的连接点时，必须对其重新进行身份验证。如果必须重复完整的EAP身份验证，则可能会涉及对等方和家庭EAP服务器之间的多次消息往返。如果在执行重新身份验证时暂停通信，则由此产生的延迟将导致性能下降，或者在最坏的情况下，丢失正在进行的任何服务会话。如果新的连接点位于访问的网络而不是对等方的家庭网络中，则延迟会更严重，因为涉及额外的程序步骤以及往返时间的可能增加。
Clancy, et al. [RFC5169] describe this problem more fully and establish design goals for solutions to reduce re-authentication delay for transfers within a single administrative domain. They also suggest a number of ways to achieve a solution:
Clancy等人[RFC5169]更全面地描述了这个问题，并为解决方案制定了设计目标，以减少单个管理域内传输的重新认证延迟。他们还提出了一些实现解决方案的方法：
o specification of a method-independent, efficient re-authentication protocol based upon EAP;
o 基于EAP的方法无关、高效的重新认证协议的规范；
o reuse of keying material from the initial EAP authentication;
o 重新使用初始EAP认证中的密钥材料；
o deployment of re-authentication servers local to the peer to reduce round-trip delay; and
o 在对等方本地部署重新认证服务器，以减少往返延迟；和
o specification of the additional protocol needed to allow the EAP server to pass authentication information to the local re-authentication servers.
o 允许EAP服务器将身份验证信息传递到本地重新身份验证服务器所需的附加协议的规范。
Salowey, et al. [RFC5295] tackle the problem of the reuse of keying material by specifying how to derive a hierarchy of cryptographically independent purpose-specific keys from the results of the original EAP authentication, while Cao, et al. [RFC6696] specify a method-independent re-authentication protocol (the EAP Re-authentication Protocol (ERP)) applicable to two specific deployment scenarios:
Salowey等人。[RFC5295]通过指定如何从原始EAP身份验证的结果推导出密码独立的特定用途密钥的层次结构来解决密钥材料的重用问题，而Cao等人。[RFC6696]指定了方法独立的重新身份验证协议（EAP重新身份验证协议（ERP））)适用于两种特定的部署场景：
o where the peer's home EAP server also performs re-authentication; and
o 对等方的家庭EAP服务器也执行重新认证；和
o where a local re-authentication server exists but is co-located with an Authentication, Authorization, and Accounting (AAA) proxy within the domain.
o 存在本地重新身份验证服务器，但与域内的身份验证、授权和记帐（AAA）代理位于同一位置。
Other work provides further pieces of the solution or insight into the problem. For the purpose of this memo, Hoeper, et al. [RFC5749] provide an abstract mechanism for distribution of keying material from the EAP server to re-authentication servers. Ohba, et al. [RFC5836] contrast the EAP Re-authentication (ER) strategy provided by ERP with an alternative strategy called "early
其他工作提供了进一步的解决方案或对问题的洞察。在本备忘录中，Hoeper等人[RFC5749]提供了一种抽象机制，用于将密钥材料从EAP服务器分发到重新认证服务器。Ohba等人[RFC5836]将ERP提供的EAP再认证（ER）策略与另一种称为“早期”的策略进行了对比
authentication". RFC 5836 defines EAP early authentication as the use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival. Hence, the goal of EAP early authentication is to complete all EAP-related communications, including AAA signaling, in preparation for the handover, before the mobile device actually moves. Early authentication includes direct and indirect pre-authentication as well as Authenticated Anticipatory Keying (AAK). All three early authentication mechanisms provide means to securely establish authenticated keying material on a Candidate Attachment Point (CAP) while still being connected to the Serving Attachment Point (SAP) but vary in their respective system assumptions and communication paths. In particular, direct pre-authentication assumes that clients are capable of discovering CAPs and all communications are routed through the SAP. On the other hand, indirect pre-authentication assumes an existing relationship between the SAP and CAP, whereas the discovery and selection of CAPs is outside the scope of AAK. Furthermore, both direct and indirect pre-authentication require a full EAP execution to occur before the handover of the peer takes place, while AAK techniques (like ERP [RFC6696]) use keys derived from the initial EAP authentication.
认证“.RFC 5836将EAP早期认证定义为移动对等方在到达目标连接点之前使用EAP在目标连接点上建立经过认证的密钥材料。因此，EAP早期认证的目标是在移动设备实际移动之前完成所有与EAP相关的通信，包括AAA信令，以准备切换。早期认证包括直接和间接预认证以及认证预期密钥（AAK）。所有三种早期认证机制都提供了在候选连接点（CAP）上安全地建立认证密钥材料的方法，同时仍然连接到服务连接点（SAP），但其各自的系统假设和通信路径不同。特别是，直接预认证假设客户端能够发现CAP，并且所有通信都通过SAP路由。另一方面，间接预认证假设SAP和CAP之间存在关系，而CAP的发现和选择不在AAK的范围内。此外，直接和间接预认证都要求在对等方发生切换之前执行完整的EAP，而AAK技术（如ERP[RFC6696]）使用从初始EAP认证派生的密钥。
Both EAP re-authentication and early authentication enable faster inter-authenticator handovers. However, it is currently unclear how the necessary handover infrastructure can be deployed and integrated into existing EAP infrastructures. In particular, previous work has not described how ER servers that act as endpoints in the re-authentication process should be integrated into local and home domain networks. Furthermore, how EAP infrastructure can support the timely triggering of early authentications and aid with the selection of CAPs is currently unspecified.
EAP重新身份验证和早期身份验证都支持更快的身份验证者间切换。然而，目前尚不清楚如何部署必要的移交基础设施并将其集成到现有的EAP基础设施中。特别是，以前的工作没有描述在重新认证过程中充当端点的ER服务器应该如何集成到本地和家庭域网络中。此外，EAP基础设施如何支持及时触发早期身份验证并帮助选择CAP目前尚未确定。
This document proposes a general HOKEY architecture and demonstrates how it can be adapted to different deployment scenarios. To begin with, Section 3 recalls the design objectives for the HOKEY architecture. Section 4 reviews the functions that must be supported within the architecture. Section 5 describes the components of the HOKEY architecture. Section 6 describes the different deployment scenarios that the HOKEY Working Group has addressed and the information flows that must occur within those scenarios, by reference to the documents summarized above where possible and otherwise within this document itself. Finally, Section 7 provides an analysis of how AAA protocols can be applied in the HOKEY architecture.
本文档提出了一个通用的HOKEY体系结构，并演示了如何使其适应不同的部署场景。首先，第3节回顾了HOKEY架构的设计目标。第4节回顾了体系结构中必须支持的功能。第5节描述了HOKEY体系结构的组件。第6节描述了HOKEY工作组已解决的不同部署场景，以及这些场景中必须出现的信息流，在可能的情况下，参考上文总结的文件以及本文件本身。最后，第7节分析了AAA协议如何应用于HOKEY体系结构。
This document reuses terms defined in Section 2 of Ohba, et al. [RFC5836] and Section 2 of Cao, et al. [RFC6696]. In addition, it defines the following:
本文件重复使用Ohba等[RFC5836]第2节和Cao等[RFC6696]第2节中定义的术语。此外，它还定义了以下内容：
DS-rRK Domain-Specific re-authentication Root Key.
DS rRK特定于域的重新身份验证根密钥。
pMSK pre-established Master Session Key.
pMSK预先建立的主会话密钥。
EAP Early Authentication The use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival; see Ohba, et al. [RFC5836].
EAP早期认证——移动对等方使用EAP在目标连接点到达之前在其上建立经认证的密钥材料；见Ohba等人[RFC5836]。
ER Key Management An instantiation of the mechanism described in Hoeper, et al. [RFC5749] for creating and delivering root keys from an EAP server to an ER server.
ER密钥管理Hoeper等人[RFC5749]中描述的机制的实例，用于创建根密钥并将其从EAP服务器传送到ER服务器。
EAP Re-authentication (ER) The use of keying material derived from an initial EAP authentication to enable single-round-trip re-authentication of a mobile peer. For a detailed description of the keying material, see Section 4 of Cao, et al. [RFC6696].
EAP重新认证（ER）使用源自初始EAP认证的密钥材料，以实现移动对等方的单次往返重新认证。有关键控材料的详细说明，请参见Cao等人的第4节。[RFC6696]。
ER Server A component of the HOKEY architecture that terminates the EAP re-authentication exchange with the peer.
ER服务器HOKEY体系结构的一个组件，用于终止与对等方的EAP重新身份验证交换。
This section investigates the design goals for the HOKEY architecture. These include reducing the signaling overhead for re-authentication and early authentication, integrating local domain name discovery, enabling fault-tolerant re-authentication, and improving deployment scalability. These goals supplement those discussed in Section 4 of RFC 5169. Note that the identification and selection of CAPs is not a goal of the architecture, since those operations are generally specific to the lower layer in use.
本节研究HOKEY架构的设计目标。这些措施包括减少重新身份验证和早期身份验证的信令开销，集成本地域名发现，支持容错重新身份验证，以及提高部署可伸缩性。这些目标补充了RFC 5169第4节中讨论的目标。请注意，CAP的识别和选择不是架构的目标，因为这些操作通常特定于正在使用的较低层。
ERP [RFC6696] requires only one round trip; however, this round trip may require communication between a peer and its home ER and/or home AAA server in explicit bootstrapping and communication between local servers and the home server in implicit bootstrapping even if the peer is currently attached to a visited (local) network. As a result, even this one round trip may introduce long delays because the home ER and home AAA servers may be distant from the peer and the network to which it is attached. To lower signaling overhead, communication with the home ER server and home AAA server should be minimized. Ideally, a peer should only need to communicate with local servers and other local entities.
ERP[RFC6696]只需要一次往返；然而，此往返可能需要对等方与其家庭ER和/或家庭AAA服务器之间在显式引导中进行通信，以及本地服务器与家庭服务器之间在隐式引导中进行通信，即使对等方当前连接到访问的（本地）网络。因此，即使是这一次往返也可能引入长时间延迟，因为家庭ER和家庭AAA服务器可能与对等服务器及其所连接的网络相距较远。为了降低信令开销，应该尽量减少和家庭ER服务器和家庭AAA服务器的通信。理想情况下，对等方只需要与本地服务器和其他本地实体通信。
When the peer is initially attached to the network or moves between heterogeneous networks, full EAP authentication between the peer and EAP server occurs and user interaction may be needed, e.g., a dialog to prompt the user for credentials. To reduce latency, user interaction for authentication at each handover should be minimized. Ideally, user involvement should take place only during initial authentication and subsequent re-authentication should occur transparently.
当对等方最初连接到网络或在异构网络之间移动时，对等方和EAP服务器之间发生完全EAP身份验证，并且可能需要用户交互，例如，提示用户输入凭据的对话框。为了减少延迟，应尽量减少每次切换时用于身份验证的用户交互。理想情况下，用户参与应该只在初始身份验证期间进行，并且随后的重新身份验证应该透明地进行。
ERP bootstrapping must occur before (implicit) or during (explicit) a handover to transport the necessary keys to the local ER server involved. Implicit bootstrapping is preferable because it does not require communication with the home ER server during handover, but it requires that the peer know the domain name of the ER server before the subsequent local ERP exchange happens in order to derive the necessary re-authentication keying material. ERP [RFC6696] does not specify such a domain name discovery mechanism and suggests that the peer may learn the domain name through the EAP-Initiate/Re-auth-Start message or via lower-layer announcements. However, domain name discovery happens after the implicit bootstrapping completes, which may introduce extra latency. To allow more efficient handovers, a HOKEY architecture should support an efficient domain name discovery mechanism (for example, see Zorn, Wu & Wang [RFC6440]) and allow its integration with ERP implicit bootstrapping. Even in the case of explicit bootstrapping, LDN discovery should be optimized such that it does not require contacting the home AAA server, as is currently the case.
ERP引导必须在移交之前（隐式）或期间（显式）进行，以便将必要的密钥传输到相关的本地ER服务器。隐式自举是优选的，因为它在切换期间不需要与归属ER服务器通信，但是它要求对等方在随后的本地ERP交换发生之前知道ER服务器的域名，以便导出必要的重新认证密钥材料。ERP[RFC6696]未指定此类域名发现机制，并建议对等方可通过EAP Initiate/Re-auth Start消息或通过较低层公告来学习域名。但是，域名发现发生在隐式引导完成之后，这可能会引入额外的延迟。为了实现更高效的切换，HOKEY体系结构应该支持高效的域名发现机制（例如，请参阅Zorn，Wu&Wang[RFC6440]），并允许其与ERP隐式引导集成。即使在显式引导的情况下，也应该优化LDN发现，使其不需要联系家庭AAA服务器，就像目前的情况一样。
If all authentication services depend upon a remote server, a network partition can result in the denial of service to valid users. However, if for example an ER server exists in the local network, previously authenticated users can re-authenticate even though a link to the home or main authentication server doesn't exist.
如果所有身份验证服务都依赖于远程服务器，则网络分区可能会导致拒绝向有效用户提供服务。但是，例如，如果本地网络中存在ER服务器，则先前经过身份验证的用户可以重新身份验证，即使不存在到主身份验证服务器或主身份验证服务器的链接。
To provide better deployment scalability, there should be no requirement for the co-location of entities providing handover keying services (e.g., ER servers) and AAA servers or proxies. Separation of these entities may cause problems with routing but allows greater flexibility in deployment and implementation.
为了提供更好的部署可扩展性，不应要求提供切换键控服务的实体（例如ER服务器）和AAA服务器或代理的同一位置。分离这些实体可能会导致路由问题，但允许在部署和实现方面具有更大的灵活性。
The operation of the authentication subsystem provided by HOKEY also depends on the availability of a number of discovery functions:
HOKEY提供的认证子系统的运行还取决于许多发现功能的可用性：
o discovery of CAPs by the peer, by the SAP, or by some other entity;
o 由对等方、SAP或其他实体发现CAP；
o discovery of the authentication services supported at a given CAP;
o 发现给定CAP支持的认证服务；
o discovery of the required server in the home domain when a CAP is not in the same domain as the SAP, or no local server is available;
o 当CAP与SAP不在同一域中，或者没有可用的本地服务器时，在主域中发现所需的服务器；
o peer discovery of the LDN when EAP re-authentication is used with a local server.
o 当EAP重新身份验证用于本地服务器时，LDN的对等发现。
It is assumed that these functions are provided by the environment within which the authentication subsystem operates and are outside the scope of the authentication subsystem itself. LDN discovery is a possible exception.
假设这些功能由认证子系统运行的环境提供，并且不在认证子系统本身的范围内。LDN发现可能是一个例外。
The major functions comprising the authentication subsystem and their interdependencies are discussed in greater detail below.
下面将更详细地讨论组成认证子系统的主要功能及其相互依赖关系。
o When AAA is invoked to authorize network access, it uses one of two services offered by the authentication subsystem: full EAP authentication or EAP re-authentication. Note that although AAA may perform authentication directly in some cases, when EAP is
o 当AAA被调用以授权网络访问时，它使用认证子系统提供的两种服务之一：完全EAP认证或EAP重新认证。请注意，尽管在某些情况下AAA可以直接执行身份验证，但当EAP为
utilized AAA functions only as a transport for EAP messages and the encryption keys (if any) resulting from successful EAP authentication.
已利用的AAA仅作为EAP消息和成功EAP身份验证产生的加密密钥（如果有）的传输。
o Pre-authentication triggers AAA network access authorization at each CAP, which in turn causes full EAP authentication to be invoked.
o 预认证会在每个CAP触发AAA网络访问授权，从而调用完整的EAP认证。
o EAP re-authentication invokes ER key management at the time of authentication to create and distribute keying material to ER servers.
o EAP重新认证在认证时调用ER密钥管理，以创建密钥材料并将其分发到ER服务器。
o AAK relies on ER key management to establish keying material on ER/AAK servers but uses an extension to ER key management to derive and establish keying material on candidate authenticators. AAK uses an extension to EAP re-authentication to communicate with ER/AAK servers.
o AAK依靠ER密钥管理在ER/AAK服务器上建立密钥材料，但使用ER密钥管理的扩展在候选验证器上派生和建立密钥材料。AAK使用EAP重新身份验证的扩展与ER/AAK服务器通信。
EAP authentication, EAP re-authentication, and handover key distribution depend on the routing and secure transport service provided by AAA. Discovery functions and the function of authentication and authorization of network entities (access points, ER servers) are not shown. As stated above, these are external to the authentication subsystem.
EAP身份验证、EAP重新身份验证和切换密钥分配取决于AAA提供的路由和安全传输服务。未显示发现功能以及网络实体（接入点、ER服务器）的身份验证和授权功能。如上所述，它们位于身份验证子系统的外部。
The pre-authentication function is responsible for discovery of CAPs and completion of network access authentication and authorization at each CAP in advance of handover. The operation of this function is described in general terms in Ohba, et al. [RFC5836]. No document is yet available to describe the implementation of pre-authentication in terms of specific protocols; pre-authentication support for the Protocol for Carrying Authentication for Network Access (PANA) [RFC5873] could be part of the solution.
预认证功能负责在切换前发现CAP，并在每个CAP完成网络访问认证和授权。Ohba等人[RFC5836]对该功能的操作进行了概述。目前还没有任何文件可用于说明具体协议中预认证的实施情况；对承载网络访问身份验证（PANA）协议的预身份验证支持[RFC5873]可能是解决方案的一部分。
The EAP re-authentication function is responsible for authenticating the peer at a specific access point using keying material derived from a prior full EAP authentication. RFC 5169 [RFC5169] provides the design objectives for an implementation of this function. ERP [RFC6696] describes a protocol to implement EAP re-authentication.
EAP重新认证功能负责使用先前完整EAP认证衍生的密钥材料在特定接入点对对等方进行认证。RFC 5169[RFC5169]提供了实现该功能的设计目标。ERP[RFC6696]描述了实现EAP重新认证的协议。
The EAP authentication function is responsible for authenticating the peer at a specific access point using a full EAP exchange. Aboba, et al. [RFC3748] define the associated protocol, while Ohba, et al. [RFC5836] describe the use of EAP as part of pre-authentication. Note that the HOKEY Working Group has not specified the non-AAA protocol required to transport EAP frames over IP that is shown in Figures 3 and 5 of Ohba, et al. [RFC5836], although PANA [RFC5873] is a candidate.
EAP身份验证功能负责使用完整的EAP交换对特定接入点的对等方进行身份验证。Aboba等人[RFC3748]定义了相关协议，而Ohba等人[RFC5836]描述了EAP作为预认证的一部分的使用。请注意，HOKEY工作组尚未指定通过IP传输EAP帧所需的非AAA协议，如Ohba等人[RFC5836]的图3和图5所示，尽管PANA[RFC5873]是候选协议。
The AAK function is responsible for pre-placing keying material derived from an initial full EAP authentication on CAPs. The operation is carried out in two steps: ER key management (with trigger not currently specified) places root keys derived from initial EAP authentication onto an ER/AAK server associated with the peer. When requested by the peer, the ER/AAK server derives and pushes predefined master session keys to one or more CAPs. The operation of the AAK function is described in very general terms in Ohba, et al. [RFC5836]. A protocol specification exists (see Cao, et al. [RFC6630]).
AAK职能部门负责在CAPs上预先放置源自初始完整EAP认证的密钥材料。该操作分两步执行：ER密钥管理（当前未指定触发器）将从初始EAP身份验证派生的根密钥放置到与对等方关联的ER/AAK服务器上。当对等方请求时，ER/AAK服务器派生预定义的主会话密钥并将其推送到一个或多个CAP。AAK函数的操作在Ohba等人[RFC5836]中以非常笼统的术语进行了描述。存在协议规范（见Cao等人[RFC6630]）。
Handover key management consists of EAP method-independent key derivation and distribution and comprises the following specific functions:
切换密钥管理包括与EAP方法无关的密钥派生和分发，具体功能如下：
o handover key derivation
o 切换密钥推导
o handover key distribution
o 切换密钥分配
The derivation of handover keys is specified in Salowey, et al. [RFC5295], and AAA-based key distribution is specified in Hoeper, Nakhjiri & Ohba [RFC5749].
Salowey等人[RFC5295]规定了切换密钥的推导，Hoeper、Nakhjiri和Ohba[RFC5749]规定了基于AAA的密钥分配。
This section describes the components of the HOKEY architecture in terms of the functions they perform. The components cooperate as described in this section to carry out the functions described in the previous section. Section 6 describes the different deployment scenarios that are possible using these functions.
本节描述了HOKEY体系结构的组件及其执行的功能。各部件按照本节所述进行配合，以执行上一节所述的功能。第6节描述了使用这些功能可能出现的不同部署场景。
The components of the HOKEY architecture are as follows:
HOKEY架构的组件如下所示：
o the peer;
o 同伴；
o the authenticator, which is a part of the SAP and CAPs;
o 认证器，是SAP和CAPs的一部分；
o the EAP server;
o EAP服务器；
o the ER server; and
o ER服务器；和
o the ER/AAK server [RFC6630], either in the home domain or local to the authenticator.
o ER/AAK服务器[RFC6630]，位于主域中或认证器的本地。
The peer participates in the functions described in Section 4, as shown in Table 1.
对等方参与第4节所述的功能，如表1所示。
+--------------------+----------------------------------------------+
| Function | Peer Role |
+--------------------+----------------------------------------------+
| EAP authentication | Determines that full EAP authentication is |
| | needed based on context (e.g., initial |
| | authentication), prompting from the |
| | authenticator, or discovery that only EAP |
| | authentication is supported. Participates |
| | in the EAP exchange with the EAP server. |
| - | - |
| Direct | Discovers CAPs. Initiates |
| pre-authentication | pre-authentication with each, followed by |
| | EAP authentication as above, but using IP |
| | rather than L2 transport for the EAP frames. |
| - | - |
| Indirect | Enters into a full EAP exchange when |
| pre-authentication | triggered, using either L2 or L3 transport |
| | for the frames. |
| - | - |
| EAP | Determines that EAP re-authentication is |
| re-authentication | possible based on discovery or authenticator |
| | prompting. Participates in ERP exchange |
| | with the ER server. |
| - | - |
| AAK | Determines that AAK is possible based on |
| | discovery or serving authenticator |
| | prompting. Discovers CAPs. Participates in |
| | ERP/AAK exchange, requesting distribution of |
| | keying material to the CAPs. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| Function | Peer Role |
+--------------------+----------------------------------------------+
| EAP authentication | Determines that full EAP authentication is |
| | needed based on context (e.g., initial |
| | authentication), prompting from the |
| | authenticator, or discovery that only EAP |
| | authentication is supported. Participates |
| | in the EAP exchange with the EAP server. |
| - | - |
| Direct | Discovers CAPs. Initiates |
| pre-authentication | pre-authentication with each, followed by |
| | EAP authentication as above, but using IP |
| | rather than L2 transport for the EAP frames. |
| - | - |
| Indirect | Enters into a full EAP exchange when |
| pre-authentication | triggered, using either L2 or L3 transport |
| | for the frames. |
| - | - |
| EAP | Determines that EAP re-authentication is |
| re-authentication | possible based on discovery or authenticator |
| | prompting. Participates in ERP exchange |
| | with the ER server. |
| - | - |
| AAK | Determines that AAK is possible based on |
| | discovery or serving authenticator |
| | prompting. Discovers CAPs. Participates in |
| | ERP/AAK exchange, requesting distribution of |
| | keying material to the CAPs. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 1: Functions of the Peer
表1：对等网络的功能
The serving authenticator participates in the functions described in Section 4, as shown in Table 2.
服务验证器参与第4节中描述的功能，如表2所示。
+--------------------+----------------------------------------------+
| Function | Serving Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | Discovers CAPs. Initiates an EAP exchange |
| pre-authentication | between the peer and the EAP server through |
| | each candidate authenticator. Mediates |
| | between L2 transport of EAP frames on the |
| | peer side and a non-AAA protocol over IP |
| | toward the CAP. |
| - | - |
| EAP | No role. |
| re-authentication | |
| - | - |
| AAK | Mediates between L2 transport of AAK frames |
| | on the peer side and AAA transport toward |
| | the ER/AAK server. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| Function | Serving Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | Discovers CAPs. Initiates an EAP exchange |
| pre-authentication | between the peer and the EAP server through |
| | each candidate authenticator. Mediates |
| | between L2 transport of EAP frames on the |
| | peer side and a non-AAA protocol over IP |
| | toward the CAP. |
| - | - |
| EAP | No role. |
| re-authentication | |
| - | - |
| AAK | Mediates between L2 transport of AAK frames |
| | on the peer side and AAA transport toward |
| | the ER/AAK server. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 2: Functions of the Serving Authenticator
表2：服务验证器的功能
The candidate authenticator participates in the functions described in Section 4, as shown in Table 3.
候选验证器参与第4节中描述的功能，如表3所示。
+--------------------+----------------------------------------------+
| Function | Candidate Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | Invokes AAA network access authentication |
| | and authorization upon handover/initial |
| | attachment. Mediates between L2 transport |
| | of EAP frames on the peer link and AAA |
| | transport toward the EAP server. |
| - | - |
| Direct | Invokes AAA network access authentication |
| pre-authentication | and authorization when the peer initiates |
| | authentication. Mediates between non-AAA L3 |
| | transport of EAP frames on the peer side and |
| | AAA transport toward the EAP server. |
| - | - |
| Indirect | Same as direct pre-authentication, except |
| pre-authentication | that it communicates with the serving |
| | authenticator rather than the peer. |
| - | - |
| EAP | Invokes AAA network access authentication |
| re-authentication | and authorization upon handover. Discovers |
| | or is configured with the address of the ER |
| | server. Mediates between L2 transport of |
| | ERP frames on the peer side and AAA |
| | transport toward the ER server. |
| - | - |
| AAK | Receives and saves the pMSK. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| Function | Candidate Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | Invokes AAA network access authentication |
| | and authorization upon handover/initial |
| | attachment. Mediates between L2 transport |
| | of EAP frames on the peer link and AAA |
| | transport toward the EAP server. |
| - | - |
| Direct | Invokes AAA network access authentication |
| pre-authentication | and authorization when the peer initiates |
| | authentication. Mediates between non-AAA L3 |
| | transport of EAP frames on the peer side and |
| | AAA transport toward the EAP server. |
| - | - |
| Indirect | Same as direct pre-authentication, except |
| pre-authentication | that it communicates with the serving |
| | authenticator rather than the peer. |
| - | - |
| EAP | Invokes AAA network access authentication |
| re-authentication | and authorization upon handover. Discovers |
| | or is configured with the address of the ER |
| | server. Mediates between L2 transport of |
| | ERP frames on the peer side and AAA |
| | transport toward the ER server. |
| - | - |
| AAK | Receives and saves the pMSK. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 3: Functions of the Candidate Authenticator
表3：候选验证器的功能
The EAP server participates in the functions described in Section 4, as shown in Table 4.
EAP服务器参与第4节所述的功能，如表4所示。
+--------------------+----------------------------------------------+
| Function | EAP Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | Terminates EAP signaling between it and the |
| | peer via the candidate authenticator. |
| | Determines whether network access |
| | authentication succeeds or fails. Provides |
| | the MSK to the authenticator (via AAA). |
| - | - |
| Direct | Same as for EAP authentication. |
| pre-authentication | |
| - | - |
| Indirect | Same as for EAP authentication. |
| pre-authentication | |
| - | - |
| EAP | Provides an rRK or DS-rRK to the ER server |
| re-authentication | (via AAA). |
| - | - |
| AAK | Same as for EAP re-authentication. |
| - | - |
| ER key management | Creates an rRK or DS-rRK and distributes it |
| | to the ER server requesting the information. |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| Function | EAP Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | Terminates EAP signaling between it and the |
| | peer via the candidate authenticator. |
| | Determines whether network access |
| | authentication succeeds or fails. Provides |
| | the MSK to the authenticator (via AAA). |
| - | - |
| Direct | Same as for EAP authentication. |
| pre-authentication | |
| - | - |
| Indirect | Same as for EAP authentication. |
| pre-authentication | |
| - | - |
| EAP | Provides an rRK or DS-rRK to the ER server |
| re-authentication | (via AAA). |
| - | - |
| AAK | Same as for EAP re-authentication. |
| - | - |
| ER key management | Creates an rRK or DS-rRK and distributes it |
| | to the ER server requesting the information. |
+--------------------+----------------------------------------------+
Table 4: Functions of the EAP Server
表4:EAP服务器的功能
The ER server participates in the functions described in Section 4, as shown in Table 5.
ER服务器参与第4节中描述的功能，如表5所示。
+--------------------+----------------------------------------------+
| Function | ER Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | No role. |
| pre-authentication | |
| - | - |
| EAP | Acquires an rRK or DS-rRK as applicable when |
| re-authentication | necessary. Terminates ERP signaling between |
| | it and the peer via the candidate |
| | authenticator. Determines whether network |
| | access authentication succeeds or fails. |
| | Provides an MSK to the authenticator. |
| - | - |
| AAK | Acquires an rRK or DS-rRK as applicable when |
| | necessary. Derives pMSKs and passes them to |
| | the CAPs. |
| - | - |
| ER key management | Receives and saves an rRK or DS-rRK as |
| | applicable. |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| Function | ER Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | No role. |
| pre-authentication | |
| - | - |
| EAP | Acquires an rRK or DS-rRK as applicable when |
| re-authentication | necessary. Terminates ERP signaling between |
| | it and the peer via the candidate |
| | authenticator. Determines whether network |
| | access authentication succeeds or fails. |
| | Provides an MSK to the authenticator. |
| - | - |
| AAK | Acquires an rRK or DS-rRK as applicable when |
| | necessary. Derives pMSKs and passes them to |
| | the CAPs. |
| - | - |
| ER key management | Receives and saves an rRK or DS-rRK as |
| | applicable. |
+--------------------+----------------------------------------------+
Table 5: Functions of the ER Server
表5：ER服务器的功能
Depending upon whether a change in a domain or access technology is involved, we have the following usage scenarios.
根据是否涉及域或访问技术的更改，我们有以下使用场景。
The peer remains stationary and re-authenticates to the original access point. Note that in this case, the SAP takes the role of the CAP in the discussion above.
对等方保持静止，并重新认证到原始接入点。注意，在这种情况下，SAP在上述讨论中扮演CAP的角色。
The peer moves between two authenticators in the same domain. In this scenario, the peer communicates with the ER server via the ER authenticator within the same network.
对等方在同一域中的两个身份验证程序之间移动。在此场景中，对等方通过同一网络中的ER验证器与ER服务器通信。
The peer moves between two different domains. In this scenario, the peer communicates with more than one ER server via one or two different ER authenticators. One ER server is located in the current network as the peer, and one is located in the previous network from which the peer moves. Another ER server is located in the home network to which the peer belongs.
对等方在两个不同的域之间移动。在此场景中，对等方通过一个或两个不同的ER验证器与多个ER服务器通信。一个ER服务器作为对等方位于当前网络中，另一个位于对等方移动的前一个网络中。另一个ER服务器位于对等方所属的家庭网络中。
The peer moves between two heterogeneous networks. In this scenario, the peer needs to support at least two access technologies. The coverage of two access technologies usually is overlapped during handover. In this case, only authentication corresponding to intra-domain handover is required; i.e., the peer can communicate with the same local ER server to complete authentication and obtain keying material corresponding to the peer.
对等方在两个异构网络之间移动。在这种情况下，对等方需要支持至少两种访问技术。在切换过程中，两种接入技术的覆盖范围通常是重叠的。在这种情况下，只需要与域内切换相对应的认证；i、 例如，对等方可以与同一本地ER服务器通信，以完成认证并获得对等方对应的密钥材料。
This section provides an analysis of how the AAA protocol can be applied in the HOKEY architecture in accordance with Section 4.1 ("Authentication Subsystem Functional Overview").
本节根据第4.1节（“认证子系统功能概述”）对AAA协议如何应用于HOKEY体系结构进行了分析。
Authorization is a major issue in deployments. Wherever the peer moves around, the home AAA server provides authorization for the peer during its handover. However, it is unnecessary to couple authorization with authentication at every handover, since authorization is only needed when the peer is initially attached to the network or moves between two different AAA domains. The EAP key management document [RFC5247] discusses several vulnerabilities that are common to handover mechanisms. One important issue arises from the way that the authorization decisions might be handled at the AAA server during network access authentication. For example, if AAA proxies are involved, they may also influence authorization decisions. Furthermore, the reasons for choosing a particular decision are not communicated to the AAA clients. In fact, the AAA client only knows the final authorization result. Another issue relates to session management. In some circumstances, when the peer
授权是部署中的一个主要问题。无论对等方在何处移动，家庭AAA服务器都会在其切换期间为对等方提供授权。然而，没有必要在每次切换时将授权与身份验证耦合，因为只有当对等方最初连接到网络或在两个不同的AAA域之间移动时才需要授权。EAP密钥管理文档[RFC5247]讨论了切换机制常见的几个漏洞。一个重要的问题是，在网络访问身份验证期间，授权决策可能在AAA服务器上处理。例如，如果涉及AAA代理，它们也可能影响授权决策。此外，选择特定决策的原因没有传达给AAA客户。事实上，AAA客户端只知道最终的授权结果。另一个问题涉及会话管理。在某些情况下，当同伴
moves from one authenticator to another, the peer may be authenticated by the different authenticator during a period of time, and the authenticator to which the peer is currently attached needs to create a new AAA user session; however, the AAA server should not view these handoffs as different sessions. Otherwise, this may affect user experience and also cause accounting or logging issues. For example, session ID creation, in most cases, is done by each authenticator to which the peer attaches. In this sense, the new authenticator acting as AAA client needs to create a new AAA user session from scratch, which forces its corresponding AAA server to terminate the existing user session with the previous authenticator and set up a new user session with the new authenticator. This may complicate the setup and maintenance of the AAA user session.
从一个验证器移动到另一个验证器，对等体可以在一段时间内由不同的验证器进行认证，并且对等体当前连接到的验证器需要创建新的AAA用户会话；但是，AAA服务器不应将这些切换视为不同的会话。否则，这可能会影响用户体验，并导致记帐或日志记录问题。例如，在大多数情况下，会话ID的创建是由对等方连接到的每个验证器完成的。从这个意义上说，充当AAA客户端的新验证器需要从头创建新的AAA用户会话，这迫使其相应的AAA服务器终止与先前验证器的现有用户会话，并与新验证器建立新的用户会话。这可能会使AAA用户会话的设置和维护复杂化。
The existing AAA protocols can be used to carry EAP and ERP messages between the AAA server and AAA clients. AAA transport of ERP messages is specified in Hoeper, Nakhjiri & Ohba [RFC5749] and Bournelle, et al. [DIAMETER-ERP]. AAA transport of EAP messages is specified in [RFC4072]. Key transport also can be performed through a AAA protocol. Zorn, Wu & Cakulev [DIAMETER-AVP] specify a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery.
现有的AAA协议可用于在AAA服务器和AAA客户端之间传输EAP和ERP消息。Hoeper、Nakhjiri&Ohba[RFC5749]和Bournelle等人[DIAMETER-ERP]中规定了ERP消息的AAA传输。[RFC4072]中规定了EAP消息的AAA传输。密钥传输也可以通过AAA协议执行。Zorn、Wu和Cakulev[DIAMETER-AVP]指定一组属性值对（AVP），提供加密密钥传递的本机DIAMETER支持。
This document does not introduce any new security vulnerabilities.
本文档未引入任何新的安全漏洞。
The authors would like to thank Mark Jones, Zhen Cao, Semyon Mizikovsky, Stephen Farrell, Ondrej Sury, Richard Barnes, Jari Arkko, and Lionel Morand for their reviews and comments.
作者要感谢马克·琼斯、曹震、塞米扬·米齐科夫斯基、斯蒂芬·法雷尔、昂德雷·苏里、理查德·巴恩斯、贾里·阿尔科和莱昂内尔·莫兰的评论和评论。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
[RFC5169]Clancy，T.，Nakhjiri，M.，Narayanan，V.，和L.Dondeti，“移交密钥管理和重新认证问题声明”，RFC 5169，2008年3月。
[RFC5836] Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed., "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
[RFC5836]Ohba，Y.，Ed.，Wu，Q.，Ed.，和G.Zorn，Ed.，“可扩展认证协议（EAP）早期认证问题声明”，RFC 58362010年4月。
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., "EAP Extensions for the EAP Re-authentication Protocol (ERP)", RFC 6696, July 2012.
[RFC6696]Cao，Z.，He，B.，Shi，Y.，Wu，Q.，Ed.，和G.Zorn，Ed.，“EAP再认证协议（ERP）的EAP扩展”，RFC 66962012年7月。
[DIAMETER-AVP] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Work in Progress, August 2011.
[DIAMETER-AVP]Zorn，G.，Wu，Q.，和V.Cakulev，“加密密钥传输的直径属性值对”，正在进行的工作，2011年8月。
[DIAMETER-ERP] Bournelle, J., Morand, L., Decugis, S., Wu, Q., and G. Zorn, "Diameter Support for the EAP Re-authentication Protocol (ERP)", Work in Progress, June 2012.
[DIAMETER-ERP]Bournelle，J.，Morand，L.，Decugis，S.，Wu，Q.，和G.Zorn，“EAP再认证协议（ERP）的DIAMETER支持”，正在进行的工作，2012年6月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Ed.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[RFC5295]Salowey，J.，Dondeti，L.，Narayanan，V.，和M.Nakhjiri，“从扩展主会话密钥（EMSK）派生根密钥的规范”，RFC 52952008年8月。
[RFC5749] Hoeper, K., Ed., Nakhjiri, M., and Y. Ohba, Ed., "Distribution of EAP-Based Keys for Handover and Re-Authentication", RFC 5749, March 2010.
[RFC5749]Hoeper，K.，Ed.，Nakhjiri，M.，和Y.Ohba，Ed.，“用于切换和重新认证的基于EAP的密钥的分发”，RFC 5749，2010年3月。
[RFC5873] Ohba, Y. and A. Yegin, "Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)", RFC 5873, May 2010.
[RFC5873]Ohba，Y.和A.Yegin，“对承载网络接入认证（PANA）协议的预认证支持”，RFC 5873，2010年5月。
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 2011.
[RFC6440]Zorn，G.，Wu，Q.，和Y.Wang，“EAP重新认证协议（ERP）本地域名DHCPv6选项”，RFC 64402011年12月。
[RFC6630] Cao, Z., Deng, H., Wu, Q., and G. Zorn, Ed., "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012.
[RFC6630]Cao，Z.，Deng，H.，Wu，Q.，和G.Zorn，Ed.，“认证预期键控（ERP/AAK）的EAP再认证协议扩展”，RFC 6630，2012年6月。
Authors' Addresses
作者地址
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 909 201060 EMail: glenzorn@gmail.com
格伦·佐恩（编辑）网络禅227/358泰国曼谷塔农·桑法乌特·邦纳10260泰国电话：+66（0）909 201060电子邮件：glenzorn@gmail.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, JiangSu 210012 China Phone: +86-25-84565892 EMail: bill.wu@huawei.com
秦武华为技术有限公司江苏省南京市雨花区软件大道101号210012中国电话：+86-25-84565892电子邮件：比尔。wu@huawei.com
Tom Taylor Huawei Technologies Co., Ltd. Ottawa, Ontario Canada EMail: tom.taylor.stds@gmail.com
Tom Taylor华为技术有限公司加拿大安大略省渥太华电子邮件：Tom.Taylor。stds@gmail.com
Yoav Nir Check Point 5 Hasolelim St. Tel Aviv 67897 Israel EMail: ynir@checkpoint.com
Yoav Nir检查点5 Hasolelim St.特拉维夫67897以色列电子邮件：ynir@checkpoint.com
Katrin Hoeper Motorola Solutions, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 USA EMail: khoeper@motorolasolutions.com>
Katrin Hoeper Motorola Solutions，Inc.地址：美国伊利诺伊州绍姆堡阿尔冈金东路1301号邮编：60196电子邮件：khoeper@motorolasolutions.com>
Sebastien Decugis INSIDE Secure 41 Parc Club du Golf Aix-en-Provence 13856 France Phone: +33 (0)4 42 39 63 00 EMail: sdecugis@freediameter.net
Sebastien Decugis INSIDE Secure 41 Parc Club du Golf Avex en Provence 13856法国电话：+33（0）4 42 39 63 00电子邮件：sdecugis@freediameter.net