Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 6867 Check Point
Category: Experimental Q. Wu
ISSN: 2070-1721 Huawei
January 2013
Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 6867 Check Point
Category: Experimental Q. Wu
ISSN: 2070-1721 Huawei
January 2013
An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)
支持EAP重新认证协议（ERP）的Internet密钥交换协议版本2（IKEv2）扩展
Abstract
摘要
This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696.
本文档更新了RFC 5996中描述的Internet密钥交换协议版本2（IKEv2）。此扩展允许使用可扩展认证协议（EAP）重新认证协议扩展创建和认证IKE安全关联（SA），如RFC 6696中所述。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc6867.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6867.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
IKEv2, as specified in [RFC5996], allows (Section 2.16) authentication of the initiator using an EAP method. Using EAP significantly increases the count of round trips required to establish the IPsec SA and also may require user interaction. This makes it inconvenient to allow a single remote access client to create multiple IPsec tunnels with multiple IPsec gateways that belong to the same domain.
[RFC5996]中规定的IKEv2允许（第2.16节）使用EAP方法对启动器进行身份验证。使用EAP会显著增加建立IPsec SA所需的往返次数，还可能需要用户交互。这使得允许单个远程访问客户端使用属于同一域的多个IPsec网关创建多个IPsec隧道变得不方便。
The EAP Re-authentication Protocol (ERP), as described in [RFC6696], allows an EAP peer to authenticate to multiple authenticators while performing the full EAP method only once. Subsequent authentications require fewer round trips and no user interaction.
如[RFC6696]所述，EAP重新认证协议（ERP）允许EAP对等方在仅执行一次完整EAP方法的同时向多个认证方进行认证。后续身份验证需要更少的往返次数，并且不需要用户交互。
Bringing these two technologies together allows a remote access IPsec client to create multiple tunnels with different gateways that belong to a single domain as well as using the keys from other contexts of using EAP, such as network access within the same domain, to transparently connect to VPN gateways within this domain.
将这两种技术结合在一起，允许远程访问IPsec客户端使用属于单个域的不同网关创建多个隧道，并使用来自使用EAP的其他上下文（例如同一域内的网络访问）的密钥透明地连接到此域内的VPN网关。
Additionally, it allows for faster set up of new tunnels when previous tunnels have been torn down due to things like network outage, device suspension, or a temporary move out of range. This is similar to the session resumption mechanism described in [RFC5723]. One exception being that instead of a ticket stored by the client, the re-authentication Master Session Key (rMSK) (see Section 4.6 of [RFC6696]) is used as the session key stored on both the client and the Authentication, Authorization, and Accounting (AAA) server.
此外，当以前的隧道由于网络中断、设备暂停或临时移动超出范围而被拆除时，它允许更快地建立新的隧道。这类似于[RFC5723]中描述的会话恢复机制。一个例外情况是，重新认证主会话密钥（rMSK）（参见[RFC6696]第4.6节）用作存储在客户端和认证、授权和计费（AAA）服务器上的会话密钥，而不是客户端存储的票据。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This work is motivated by the following scenarios:
这项工作的动机是以下场景：
o Multiple tunnels for a single remote access VPN client. Suppose a company has offices in New York City, Paris, and Shanghai. For historical reasons, the email server is located in the Paris office, most of the servers hosting the company's intranet are located in Shanghai, and the finance department servers are in New York City. An employee using a remote access VPN may need to connect to servers from all three locations. While it is possible to connect to a single gateway, and have that gateway route the requests to the other gateways (perhaps through site to site VPN), this is not efficient; it is more desirable to have the client initiate three different tunnels. It is, however, not desirable to have the user type in a password three times.
o 单个远程访问VPN客户端的多个隧道。假设一家公司在纽约、巴黎和上海设有办事处。由于历史原因，电子邮件服务器位于巴黎办事处，托管公司内部网的大多数服务器位于上海，财务部服务器位于纽约市。使用远程访问VPN的员工可能需要从所有三个位置连接到服务器。虽然可以连接到单个网关，并让该网关将请求路由到其他网关（可能通过站点到站点VPN），但这并不高效；更可取的做法是让客户启动三个不同的隧道。但是，不希望用户在密码中输入三次。
o Roaming. In these days of mobile phones and tablets, users often move from the wireless LAN in their office, where access may be granted through 802.1x, to a cellular network, where a VPN is necessary, and back again. Both the VPN server and the 802.1x access point are authenticators that connect to the same AAA servers. So it makes sense to make the transition smooth, without requiring user interaction. The device still needs to detect whether it is within the protected network, in which case it should not use VPN. However, this process is beyond the scope of this document. [SECBEAC] is a now-abandoned attempt at this.
o 漫游。在如今的移动电话和平板电脑时代，用户经常从办公室的无线局域网（可以通过802.1x进行访问）移动到需要VPN的蜂窝网络，然后再移动回来。VPN服务器和802.1x接入点都是连接到相同AAA服务器的身份验证程序。因此，在不需要用户交互的情况下，平滑过渡是有意义的。设备仍然需要检测它是否在受保护的网络内，在这种情况下，它不应该使用VPN。但是，此过程超出了本文件的范围。[SECBEAC]现在已经放弃了这一尝试。
o Resumption. If a device gets disconnected from an IKE peer, ERP can be used to reconnect to the same gateway without user intervention.
o 恢复。如果设备与IKE对等设备断开连接，则可以使用ERP重新连接到同一网关，而无需用户干预。
Supporting EAP Re-authentication Extension (ERX) requires an EAP payload in the first IKE_AUTH request. This is a deviation from the rules in [RFC5996], so support needs to be indicated through a Notify payload in the IKE_SA_INIT response. This Notify serves the same purpose as the EAP-Initiate/Re-auth-Start message of ERX, as specified in Section 5.3.1 of [RFC6696]. The "Domain Name" field contains the content of the Domain-Name TLV as specified in Section 5.3.1.1 of the same document.
支持EAP重新认证扩展（ERX）需要在第一个IKE_认证请求中使用EAP有效负载。这与[RFC5996]中的规则有偏差，因此需要通过IKE_SA_INIT响应中的Notify负载来指示支持。根据[RFC6696]第5.3.1节的规定，此通知与ERX的EAP Initiate/Re-auth Start消息的用途相同。“域名”字段包含同一文件第5.3.1.1节中规定的域名TLV的内容。
A supporting initiator that has unexpired keys for this domain will send the EAP-Initiate/Re-auth message in an EAP payload in the first IKE_AUTH request.
具有此域未过期密钥的支持启动器将在第一个IKE_auth请求中发送EAP有效负载中的EAP Initiate/Re auth消息。
The responder sends the EAP payload content to a backend AAA server. If that server has a valid rMSK for that session, it sends those along with an EAP-Finish/Re-auth message. The responder then forwards the EAP-Finish/Re-auth message to the initiator in an EAP payload within the first IKE_AUTH response.
响应者将EAP有效负载内容发送到后端AAA服务器。如果该服务器具有该会话的有效rMSK，则它会将其与EAP Finish/Re auth消息一起发送。然后，响应者在第一个IKE_auth响应内将EAP完成/重新验证消息转发给EAP有效负载中的启动器。
The initiator then sends an additional IKE_AUTH request that includes the AUTH payload, which has been calculated using the rMSK in the role of the MSK as described in Sections 2.15 and 2.16 of [RFC5996]. The responder replies similarly, and the IKE_AUTH exchange is finished.
然后，发起者发送一个额外的IKE_认证请求，该请求包括认证有效负载，该有效负载已使用[RFC5996]第2.15和2.16节中所述的MSK角色中的rMSK进行计算。响应者以类似方式回复，IKE_身份验证交换完成。
If the backend AAA server does not have valid keys for the Re-auth-Start message, it sends back a normal EAP request, and no rMSK key. EAP flow continues as in [RFC5996].
如果后端AAA服务器没有用于重新验证启动消息的有效密钥，它将发回一个正常的EAP请求，并且没有rMSK密钥。EAP流程继续进行，如[RFC5996]所示。
The following figure is adapted from Appendixes C.1 and C.3 of [RFC5996], with most of the optional payloads removed. Note that the EAP-Initiate/Re-auth message is added.
下图改编自[RFC5996]的附录C.1和C.3，删除了大部分可选有效载荷。请注意，添加了EAP Initiate/Re-auth消息。
IKE_SA_INIT Exchange:
| init request --> SA, KE, Ni,
|
| init response <-- SA, KE, Nr,
| N[ERX_SUPPORTED]
IKE_SA_INIT Exchange:
| init request --> SA, KE, Ni,
|
| init response <-- SA, KE, Nr,
| N[ERX_SUPPORTED]
IKE_AUTH Exchanges:
| first request --> EAP(EAP-Initiate/Re-auth),
| IDi,
| SA, TSi, TSr
|
| first response <-- IDr, [CERT+], AUTH,
| EAP(EAP-Finish/Re-auth)
|
| last request --> AUTH
|
| last response <-- AUTH,
| SA, TSi, TSr
IKE_AUTH Exchanges:
| first request --> EAP(EAP-Initiate/Re-auth),
| IDi,
| SA, TSi, TSr
|
| first response <-- IDr, [CERT+], AUTH,
| EAP(EAP-Finish/Re-auth)
|
| last request --> AUTH
|
| last response <-- AUTH,
| SA, TSi, TSr
The IDi payload MUST have ID Type ID_RFC822_ADDR, and the data field MUST contain the same value as the KeyName-NAI TLV in the EAP-Initiate/Re-auth message. See Section 3.2 for details.
IDi有效负载必须具有ID类型ID \u RFC822 \u ADDR，并且数据字段必须包含与EAP Initiate/Re auth消息中的KeyName NAI TLV相同的值。详见第3.2节。
Section 3.16 of [RFC5996] enumerates the EAP codes in EAP messages that are carried in EAP payloads. The enumeration goes only to 4. It is not clear whether or not that list is supposed to be exhaustive.
[RFC5996]第3.16节列举了EAP有效载荷中携带的EAP消息中的EAP代码。枚举仅限于4。目前尚不清楚这份清单是否应该详尽无遗。
To clarify, an implementation conforming to this specification MUST accept and transmit EAP messages with at least the codes for Initiate and Finish (5 and 6) from Section 5.3 of [RFC6696], in addition to the four codes enumerated in [RFC5996]. This document is intentionally silent about other EAP codes that are not enumerated in those documents.
为了澄清，除[RFC5996]中列举的四个代码外，符合本规范的实现必须接受并传输EAP消息，其中至少包含[RFC6696]第5.3节中的启动和完成代码（5和6）。本文件有意对这些文件中未列举的其他EAP代码保持沉默。
The authors, as well as participants of the HOKEY and IPsecME working groups, believe that all use cases for this extension to IKE have a single backend AAA server doing both the authentication and the re-authentication. The reasoning behind this is that IKE runs over the Internet and would naturally connect to the user's home network.
作者以及HOKEY和IPSECMC工作组的参与者认为，IKE扩展的所有用例都有一个后端AAA服务器来执行身份验证和重新身份验证。背后的原因是IKE通过互联网运行，自然会连接到用户的家庭网络。
This section addresses instances where this is not the case.
本节介绍了情况并非如此的情况。
Section 5.3.2 of [RFC6696] describes the EAP-Initiate/Re-auth packet, which, in the case of IKEv2, is carried in the first IKE_AUTH request. This packet contains the KeyName-NAI TLV. This TLV contains the username used in authentication. It is relayed to the AAA server in the AccessRequest message and is returned from the AAA server in the AccessAccept message.
[RFC6696]的第5.3.2节描述了EAP Initiate/Re-auth数据包，在IKEv2的情况下，该数据包在第一个IKE_-auth请求中携带。此数据包包含密钥名NAI TLV。此TLV包含身份验证中使用的用户名。它在AccessRequest消息中中继到AAA服务器，并在AccessAccept消息中从AAA服务器返回。
The username part of the Network Access Identifier (NAI) within the TLV is the EMSKName [RFC5295] encoded in hexadecimal digits. The domain part is the domain name of the home domain of the user. The username part is ephemeral in the sense that a new one is generated for each full authentication. This ephemeral value is not a good basis for making policy decisions, and it is also a poor source of user identification for the purposes of logging.
TLV中网络访问标识符（NAI）的用户名部分是十六进制编码的EMSKName[RFC5295]。域部分是用户的主域的域名。用户名部分是短暂的，因为每次完整身份验证都会生成一个新的用户名。这个短暂的值不是做出决策的良好基础，也是用于日志记录的用户标识的不良来源。
Instead, it is up to the implementation in the IPsec gateway to make policy decisions based on other factors. The following list is by no means exhaustive:
相反，由IPsec网关中的实现根据其他因素做出策略决策。以下列表并非详尽无遗：
o In some cases, the home domain name may be enough to make policy decisions. If all users with a particular home domain get the same authorization, then policy does not depend on the real username. Meaningful logs can still be issued by correlating VPN gateway IKE events with AAA servers access records.
o 在某些情况下，主域名可能足以做出决策。如果具有特定主域的所有用户都获得相同的授权，则策略不依赖于实际用户名。通过将VPN网关IKE事件与AAA服务器访问记录关联，仍然可以发布有意义的日志。
o Sometimes users receive different authorizations based on groups to which they belong. The AAA server can communicate such information to the VPN gateway, for example, using the CLASS attribute [RFC2865] in RADIUS and Diameter [RFC6733]. Logging again depends on correlation with AAA servers.
o 有时，用户会根据所属的组接收不同的授权。AAA服务器可以使用RADIUS和Diameter[RFC6733]中的CLASS属性[RFC2865]将此类信息传送到VPN网关。日志记录同样取决于与AAA服务器的相关性。
o AAA servers may support extensions that allow them to communicate with their clients (in our case -- the VPN gateway) to push user information. For example, a certain product integrates a RADIUS server with the Lightweight Directory Access Protocol (LDAP) [RFC4511], so a client could query the server using LDAP and receive the real record for this user. Others may provide this data through vendor-specific extensions to RADIUS or Diameter.
o AAA服务器可能支持扩展，允许它们与客户端（在我们的例子中是VPN网关）通信以推送用户信息。例如，某个产品将RADIUS服务器与轻量级目录访问协议（LDAP）[RFC4511]集成，因此客户机可以使用LDAP查询服务器并接收该用户的真实记录。其他人可以通过供应商特定的半径或直径扩展来提供此数据。
In any case, authorization is a major issue in deployments, if the backend AAA server supporting the re-authentication is different from the AAA server that had supported the original authentication. It is up to the re-authenticating AAA server to provide the necessary information for authorization. A conforming implementation of this protocol MAY reject initiators for which it is unable to make policy decisions because of these reasons.
在任何情况下，如果支持重新身份验证的后端AAA服务器与支持原始身份验证的AAA服务器不同，则授权是部署中的一个主要问题。由重新认证的AAA服务器提供授权所需的信息。本协议的一致性实现可能会拒绝由于这些原因而无法做出策略决定的发起方。
The Notify payload is as described in [RFC5996]:
通知有效负载如[RFC5996]所述：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! ERX Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Name !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! ERX Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Name !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - MUST be zero, as this message is related to an IKE SA.
o 协议ID（1个八位字节）-必须为零，因为此消息与IKE SA相关。
o Security Parameter Index (SPI) Size (1 octet) - MUST be zero, in conformance with Section 3.10 of [RFC5996].
o 安全参数索引（SPI）大小（1个八位字节）-必须为零，符合[RFC5996]第3.10节的规定。
o ERX Notify Message Type (2 octets) - MUST be 16427, the value assigned for ERX.
o ERX通知消息类型（2个八位字节）-必须是为ERX分配的值16427。
o Domain Name (variable) - contains the domain name or realm, as these terms are used in [RFC6696] and encoded as ASCII, as specified in [RFC4282].
o 域名（变量）-包含域名或领域，因为这些术语在[RFC6696]中使用，并按照[RFC4282]中的规定编码为ASCII。
This specification changes the behavior of IKE peers, both initiators and responders. The behavior of backend AAA servers is not changed by this specification, but they are required to support [RFC6696]. The same goes for the EAP client, if it's not integrated into the IKE initiator (for example, if the EAP client is an operating system component).
此规范更改IKE对等方的行为，包括发起方和响应方。本规范未改变后端AAA服务器的行为，但要求它们支持[RFC6696]。如果EAP客户端未集成到IKE启动器中（例如，如果EAP客户端是一个操作系统组件），则EAP客户端也是如此。
This specification is silent about key storage and key lifetimes on either the EAP client or the EAP server. These issues are covered in Sections 3, 4, and 5 of [RFC6696]. The key lifetime may be communicated from the AAA server to the EAP client via the Lifetime attribute in the EAP-Finish/Re-auth message. If the server does not have a valid key, while the client does have one, regular EAP is used (see Section 3). This should not happen if lifetimes are communicated. In such a case, the IKEv2 initiator / EAP client MAY alert the user and MAY log the event. Note that this does not necessarily indicate an attack. It could simply be a loss of state on the AAA server.
本规范不涉及EAP客户端或EAP服务器上的密钥存储和密钥生存期。[RFC6696]的第3、4和5节介绍了这些问题。密钥生存期可以通过EAP Finish/Re auth消息中的生存期属性从AAA服务器传送到EAP客户端。如果服务器没有有效密钥，而客户端有，则使用常规EAP（参见第3节）。如果生命周期得到沟通，则不应发生这种情况。在这种情况下，IKEv2启动器/EAP客户端可能会提醒用户并记录事件。请注意，这并不一定表示攻击。这可能只是AAA服务器上的状态丢失。
The protocol extension described in this document extends the authentication from one EAP context, which may or may not be part of IKEv2, to an IKEv2 context. Successful completion of the protocol proves to the authenticator, which in our case is a VPN gateway, that the supplicant or VPN client has authenticated in some other EAP context.
本文档中描述的协议扩展将身份验证从一个EAP上下文（可能是也可能不是IKEv2的一部分）扩展到一个IKEv2上下文。协议的成功完成向身份验证器（在我们的例子中是VPN网关）证明了请求方或VPN客户端已经在其他EAP上下文中进行了身份验证。
The protocol supplies the authenticator with the domain name with which the supplicant has authenticated, but does not supply it with a specific identity. Instead, the gateway receives an EMSKName, which is an ephemeral ID. With this variant of the IKEv2 protocol, the initiator never sends its real identity on the wire while the server does. This is different from the usual IKEv2 practice of the initiator revealing its identity first.
该协议向验证器提供请求者已使用其进行身份验证的域名，但不向其提供特定标识。相反，网关接收一个EMSKName，它是一个短暂的ID。使用IKEv2协议的这种变体，当服务器发送时，启动器从不在线路上发送其真实身份。这与通常的IKEv2实践不同，即发起者首先显示其身份。
If the domain name is sufficient to make access control decisions, this is enough. If not, then the gateway needs to find out either the real name or authorization information for that particular user. This may be done using the AAA protocol or by some other federation protocol, which is out of scope for this specification.
如果域名足以做出访问控制决策，这就足够了。如果没有，那么网关需要找出该特定用户的真实姓名或授权信息。这可以使用AAA协议或其他一些联邦协议来完成，这超出了本规范的范围。
IANA has assigned a notify message type of 16427 from the "IKEv2 Notify Message Types - Status Types" registry with the name "ERX_SUPPORTED".
IANA已从“IKEv2 notify message Types-Status Types”注册表分配了一个名为“ERX_SUPPORTED”的通知消息类型16427。
The authors would like to thank Yaron Sheffer for comments and suggested text that have contributed to this document.
作者要感谢Yaron Sheffer对本文件的评论和建议文本。
Thanks also to Juergen Schoenwaelder for his OPS-DIR review comments.
还感谢Juergen Schoenwaeld的OPS-DIR评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[RFC5295]Salowey，J.，Dondeti，L.，Narayanan，V.，和M.Nakhjiri，“从扩展主会话密钥（EMSK）派生根密钥的规范”，RFC 52952008年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP Extensions for the EAP Re-authentication Protocol (ERP)", RFC 6696, July 2012.
[RFC6696]Cao，Z.，He，B.，Shi，Y.，Wu，Q.，和G.Zorn，“EAP再认证协议（ERP）的EAP扩展”，RFC 66962012年7月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[RFC5723]Sheffer，Y.和H.Tschofenig，“互联网密钥交换协议第2版（IKEv2）会话恢复”，RFC 57232010年1月。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733]Fajardo，V.，Arkko，J.，Loughney，J.，和G.Zorn，“直径基准协议”，RFC 67332012年10月。
[SECBEAC] Sheffer, Y. and Y. Nir, "Secure Beacon: Securely Detecting a Trusted Network", Work in Progress, June 2009.
[SECBEAC]Sheffer，Y.和Y.Nir，“安全信标：安全检测可信网络”，正在进行的工作，2009年6月。
Authors' Addresses
作者地址
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 67897 Israel
以色列特拉维夫Hasolelim街5号Yoav Nir Check Point软件技术有限公司67897
EMail: ynir@checkpoint.com
EMail: ynir@checkpoint.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, JiangSu 210012 China
中国江苏省南京市雨花区软件大道101号秦武华为技术有限公司210012
EMail: sunseawq@huawei.com
EMail: sunseawq@huawei.com