Network Working Group P. Eronen
Request for Comments: 4739 Nokia
Category: Experimental J. Korhonen
TeliaSonera
November 2006
Network Working Group P. Eronen
Request for Comments: 4739 Nokia
Category: Experimental J. Korhonen
TeliaSonera
November 2006
Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol
Internet密钥交换（IKEv2）协议中的多个身份验证交换
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider.
Internet密钥交换（IKEv2）协议支持多种认证各方的机制，包括使用公钥证书的签名、共享机密和可扩展认证协议（EAP）方法。目前，每个端点仅使用这些机制中的一种进行自身身份验证。本文档指定了对IKEv2的扩展，该扩展允许使用多个身份验证交换，使用不同的机制或相同的机制。例如，此扩展允许对客户端主机执行基于证书的身份验证，然后对用户执行EAP身份验证。使用后端身份验证服务器时，它们可以属于不同的管理域，例如网络访问提供商和服务提供商。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Usage Scenarios ............................................4
1.2. Terminology ................................................5
2. Solution ........................................................5
2.1. Solution Overview ..........................................5
2.2. Example 1: Multiple EAP Authentications ....................6
2.3. Example 2: Mixed EAP and Certificate Authentications .......7
2.4. Example 3: Multiple Initiator Certificates .................8
2.5. Example 4: Multiple Responder Certificates .................8
3. Payload Formats .................................................9
3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload .....................9
3.2. ANOTHER_AUTH_FOLLOWS Notify Payload ........................9
4. IANA Considerations .............................................9
5. Security Considerations .........................................9
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
1. Introduction ....................................................3
1.1. Usage Scenarios ............................................4
1.2. Terminology ................................................5
2. Solution ........................................................5
2.1. Solution Overview ..........................................5
2.2. Example 1: Multiple EAP Authentications ....................6
2.3. Example 2: Mixed EAP and Certificate Authentications .......7
2.4. Example 3: Multiple Initiator Certificates .................8
2.5. Example 4: Multiple Responder Certificates .................8
3. Payload Formats .................................................9
3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload .....................9
3.2. ANOTHER_AUTH_FOLLOWS Notify Payload ........................9
4. IANA Considerations .............................................9
5. Security Considerations .........................................9
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
IKEv2 [IKEv2] supports several mechanisms for parties involved in the IKE_SA (IKE security association). These include signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods.
IKEv2[IKEv2]为IKE_SA（IKE安全协会）中涉及的各方支持多种机制。其中包括具有公钥证书的签名、共享机密和可扩展身份验证协议（EAP）方法。
Currently, each endpoint uses only one of these mechanisms to authenticate itself. However, there are scenarios where making the authorization decision in IKEv2 (whether to allow access or not) requires using several of these methods.
目前，每个端点仅使用这些机制中的一种进行自身身份验证。但是，在某些情况下，在IKEv2中做出授权决策（是否允许访问）需要使用以下几种方法。
For instance, it may be necessary to authenticate both the host (machine) requesting access, and the user currently using the host. These two authentications would use two separate sets of credentials (such as certificates and associated private keys) and might even use different authentication mechanisms.
例如，可能需要对请求访问的主机（计算机）和当前使用该主机的用户进行身份验证。这两种身份验证将使用两组独立的凭据（例如证书和相关私钥），甚至可能使用不同的身份验证机制。
To take another example, when an operator is hosting a Virtual Private Network (VPN) gateway service for a third party, it may be necessary to authenticate the client to both the operator (for billing purposes) and the third party's Authentication, Authorization, and Accounting (AAA) server (for authorizing access to the third party's internal network).
举另一个例子，当运营商为第三方托管虚拟专用网络（VPN）网关服务时，可能需要向运营商（出于计费目的）和第三方的认证、授权和计费（AAA）服务器验证客户端（用于授权访问第三方的内部网络）。
This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user.
本文档指定了对IKEv2的扩展，该扩展允许使用多个身份验证交换，使用不同的机制或相同的机制。例如，此扩展允许对客户端主机执行基于证书的身份验证，然后对用户执行EAP身份验证。
Each authentication exchange requiring communication with backend AAA servers may be directed to different backend AAA servers, located even in different administrative domains. However, details of the communication between the IKEv2 gateway and the backend authentication servers are beyond the scope of this document. In particular, this document does not specify any changes to existing AAA protocols, and it does not require the use of any particular AAA protocol.
每个需要与后端AAA服务器通信的身份验证交换可能被定向到不同的后端AAA服务器，甚至位于不同的管理域中。但是，IKEv2网关和后端身份验证服务器之间的通信细节超出了本文档的范围。特别是，本文档未指定对现有AAA协议的任何更改，也不要求使用任何特定的AAA协议。
In case of several EAP authentications, it is important to notice that they are not a "sequence" (as described in Section 2.1 of [EAP]), but separate independent EAP conversations, which are usually also terminated in different EAP servers. Multiple authentication methods within a single EAP conversation are still prohibited as described in Section 2.1 of [EAP]. Using multiple independent EAP conversations is similar to the separate Network Access Provider (NAP) and Internet Service Provider (ISP) authentication exchanges
在多个EAP认证的情况下，需要注意的是，它们不是一个“序列”（如[EAP]第2.1节所述），而是独立的EAP对话，通常也在不同的EAP服务器中终止。如[EAP]第2.1节所述，仍然禁止在单个EAP对话中使用多种身份验证方法。使用多个独立的EAP对话类似于单独的网络访问提供商（NAP）和互联网服务提供商（ISP）身份验证交换
planned for [PANA]. The discovery of the appropriate EAP server for each EAP authentication conversation is based on AAA routing.
计划于[泛亚]。为每个EAP身份验证会话发现适当的EAP服务器是基于AAA路由的。
Figure 1 shows an example architecture of an operator-hosted VPN scenario that could benefit from a two-phase authentication within the IKEv2 exchange. First, the client authenticates towards the Network Access Provider (NAP) and gets access to the NAP-hosted VPN gateway. The first-phase authentication involves the backend AAA server of the NAP. After the first authentication, the client initiates the second authentication round that also involves the Third Party's backend AAA server. If both authentications succeed, the required IPsec tunnels are set up and the client can access protected networks behind the Third Party.
图1显示了运营商托管VPN场景的示例体系结构，该场景可以从IKEv2交换中的两阶段身份验证中获益。首先，客户端向网络访问提供商（NAP）进行身份验证，并访问NAP承载的VPN网关。第一阶段身份验证涉及NAP的后端AAA服务器。在第一次身份验证之后，客户机发起第二轮身份验证，这也涉及到第三方的后端AAA服务器。如果两次身份验证都成功，则将设置所需的IPsec隧道，并且客户端可以访问第三方后面的受保护网络。
Client *Network Access Provider*
+---------+ +---------+ +-----+
| | | NAP's | | NAP |
|Protected| IPsec SAs | Tunnel | AAA Protocol | AAA |
|Endpoint |<------------------>|Endpoint |<------------>|Serv/|
| | | | |Proxy|
+---------+ +---------+ +-----+
^ ^
IPsec or / AAA |
Leased Line / Protocol |
/ |
v |
+---------+ *Third Party* v
|3rd Party| +-----+
Protected | Tunnel | | 3rd |
Subnet <----|Endpoint | |Party|
| | | AAA |
+---------+ +-----+
Client *Network Access Provider*
+---------+ +---------+ +-----+
| | | NAP's | | NAP |
|Protected| IPsec SAs | Tunnel | AAA Protocol | AAA |
|Endpoint |<------------------>|Endpoint |<------------>|Serv/|
| | | | |Proxy|
+---------+ +---------+ +-----+
^ ^
IPsec or / AAA |
Leased Line / Protocol |
/ |
v |
+---------+ *Third Party* v
|3rd Party| +-----+
Protected | Tunnel | | 3rd |
Subnet <----|Endpoint | |Party|
| | | AAA |
+---------+ +-----+
Figure 1: Two-phase authentication used to gain access to the Third Party network via Network Access Provider. AAA traffic goes through NAP's AAA server.
图1：用于通过网络访问提供商访问第三方网络的两阶段身份验证。AAA流量通过NAP的AAA服务器。
The NAP's AAA server can be used to proxy the AAA traffic to the Third Party's backend AAA server. Alternatively, the AAA traffic from the NAP's tunnel endpoint could go directly to the Third Party's backend AAA servers. However, this is more or less an AAA routing issue.
NAP的AAA服务器可用于将AAA流量代理到第三方的后端AAA服务器。或者，来自NAP的隧道端点的AAA流量可以直接进入第三方的后端AAA服务器。然而，这或多或少是一个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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
The terms and abbreviations "authenticator", "backend authentication server", "EAP server", and "peer" in this document are to be interpreted as described in [EAP].
本文件中的术语和缩写“authenticator”、“backend authentication server”、“EAP server”和“peer”应按照[EAP]中所述进行解释。
When messages containing IKEv2 payloads are described, optional payloads are shown in brackets (for instance, "[FOO]"), and a plus sign indicates that a payload can be repeated one or more times (for instance, "FOO+").
当描述包含IKEv2有效载荷的消息时，可选有效载荷显示在括号中（例如，“[FOO]”），加号表示有效载荷可以重复一次或多次（例如，“FOO+”）。
The peers announce support for this IKEv2 extension by including a MULTIPLE_AUTH_SUPPORTED notification in the IKE_SA_INIT response (responder) and the first IKE_AUTH request (initiator).
对等方通过在IKE_SA_INIT响应（响应方）和第一个IKE_AUTH请求（发起方）中包含支持多个_AUTH_的通知来宣布对该IKEv2扩展的支持。
If both peers support this extension, either of them can announce that it wishes to have a second authentication by including an ANOTHER_AUTH_FOLLOWS notification in any IKE_AUTH message that contains an AUTH payload. This indicates that the peer sending the ANOTHER_AUTH_FOLLOWS wishes to authenticate another set of credentials to the other peer. The next IKE_AUTH message sent by this peer will contain a second identity payload (IDi or IDr) and starts another authentication exchange. The IKE_AUTH phase is considered successful only if all the individual authentication exchanges complete successfully.
如果两个对等方都支持此扩展，则它们中的任何一方都可以通过在包含身份验证有效负载的任何IKE身份验证消息中包含另一个身份验证通知来宣布希望进行第二次身份验证。这表示发送另一个身份验证的对等方希望向另一个对等方验证另一组凭据。该对等方发送的下一个IKE_AUTH消息将包含第二个身份有效负载（IDi或IDr），并启动另一个身份验证交换。只有当所有单独的身份验证交换成功完成时，IKE_身份验证阶段才被视为成功。
It is assumed that both peers know what credentials they want to present; there is no negotiation about, for instance, what type of authentication is to be done. As in IKEv2, EAP-based authentication is always requested by the initiator (by omitting the AUTH payload).
假设两个对等点都知道他们想要呈现什么凭证；例如，关于要进行什么类型的身份验证，没有任何协商。与IKEv2一样，启动器始终请求基于EAP的身份验证（通过省略身份验证有效负载）。
The AUTH payloads are calculated as specified in [IKEv2] Sections 2.15 and 2.16, where IDi' refers to the latest IDi payload sent by the initiator, and IDr' refers to the latest IDr payload sent by the responder. If EAP methods that do not generate shared keys are used, it is possible that several AUTH payloads with identical contents are sent. When such EAP methods are used, the purpose of the AUTH payload is simply to delimit the authentication exchanges, and ensure that the IKE_SA_INIT request/response messages were not modified.
按照[IKEv2]第2.15节和第2.16节的规定计算验证有效载荷，其中IDi'指的是发起者发送的最新IDi有效载荷，IDr'指的是响应者发送的最新IDr有效载荷。如果使用不生成共享密钥的EAP方法，则可能会发送具有相同内容的多个身份验证有效负载。当使用这样的EAP方法时，AUTH有效负载的目的只是界定身份验证交换，并确保IKE_SA_INIT请求/响应消息未被修改。
This example shows certificate-based authentication of the responder followed by an EAP authentication exchange (messages 1-10). When the first EAP exchange is ending (the initiator is sending its AUTH payload), the initiator announces that it wishes to have a second authentication exchange by including an ANOTHER_AUTH_FOLLOWS notification (message 9).
此示例显示响应程序的基于证书的身份验证，然后是EAP身份验证交换（消息1-10）。当第一次EAP交换结束时（启动器正在发送其身份验证有效负载），启动器通过包含另一个身份验证通知（消息9），宣布希望进行第二次身份验证交换。
After this, a second authentication exchange begins. The initiator sends a new IDi payload but no AUTH payload (message 11), indicating that EAP will be used. After that, another EAP authentication exchange follows (messages 12-18).
在此之后，开始第二次身份验证交换。启动器发送一个新的IDi负载，但没有验证负载（消息11），指示将使用EAP。之后，另一个EAP身份验证交换随之进行（消息12-18）。
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERTREQ+], [IDr],
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
EAP(Request) }
5. HDR, SK { EAP(Response) } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Success) }
9. HDR, SK { AUTH,
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 10. HDR, SK { AUTH }
11. HDR, SK { IDi } -->
<-- 12. HDR, SK { EAP(Request) }
13. HDR, SK { EAP(Response) } -->
<-- 14. HDR, SK { EAP(Request) }
15. HDR, SK { EAP(Response) } -->
<-- 16. HDR, SK { EAP(Success) }
17. HDR, SK { AUTH } -->
<-- 18. HDR, SK { AUTH, SA, TSi, TSr }
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERTREQ+], [IDr],
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
EAP(Request) }
5. HDR, SK { EAP(Response) } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Success) }
9. HDR, SK { AUTH,
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 10. HDR, SK { AUTH }
11. HDR, SK { IDi } -->
<-- 12. HDR, SK { EAP(Request) }
13. HDR, SK { EAP(Response) } -->
<-- 14. HDR, SK { EAP(Request) }
15. HDR, SK { EAP(Response) } -->
<-- 16. HDR, SK { EAP(Success) }
17. HDR, SK { AUTH } -->
<-- 18. HDR, SK { AUTH, SA, TSi, TSr }
Example 1: Certificate-based authentication of the responder, followed by two EAP authentication exchanges.
示例1：响应者基于证书的身份验证，然后是两个EAP身份验证交换。
Another example is shown below: here both the initiator and the responder are first authenticated using certificates (or shared secrets); this is followed by an EAP authentication exchange.
另一个例子如下所示：在这里，启动器和响应程序都首先使用证书（或共享机密）进行身份验证；然后是EAP身份验证交换。
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Request) }
9. HDR, SK { EAP(Response) } -->
<-- 10. HDR, SK { EAP(Success) }
11. HDR, SK { AUTH } -->
<-- 12. HDR, SK { AUTH, SA, TSi, TSr }
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Request) }
9. HDR, SK { EAP(Response) } -->
<-- 10. HDR, SK { EAP(Success) }
11. HDR, SK { AUTH } -->
<-- 12. HDR, SK { AUTH, SA, TSi, TSr }
Example 2: Certificate-based (or shared-secret-based) authentication of the initiator and the responder, followed by an EAP authentication exchange.
示例2：发起方和响应方基于证书（或基于共享机密）的身份验证，然后是EAP身份验证交换。
This example shows yet another possibility: the initiator has two different certificates (and associated private keys), and authenticates both of them to the responder.
此示例显示了另一种可能性：启动器具有两个不同的证书（以及相关的私钥），并向响应者验证这两个证书。
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi, [CERT+], AUTH } -->
<-- 6. HDR, SK { SA, TSi, TSr }
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi, [CERT+], AUTH } -->
<-- 6. HDR, SK { SA, TSi, TSr }
Example 3: Two certificate-based authentications of the initiator, and one certificate-based authentication of the responder.
示例3：发起方的两个基于证书的身份验证和响应方的一个基于证书的身份验证。
This example shows yet another possibility: the responder has two different certificates (and associated private keys), and authenticates both of them to the initiator.
此示例显示了另一种可能性：响应者有两个不同的证书（以及相关的私钥），并向启动器验证这两个证书。
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
N(ANOTHER_AUTH_FOLLOWS) }
5. HDR, SK { } -->
<-- 6. HDR, SK { IDr, [CERT+], AUTH,
SA, TSi, TSr }
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
N(ANOTHER_AUTH_FOLLOWS) }
5. HDR, SK { } -->
<-- 6. HDR, SK { IDr, [CERT+], AUTH,
SA, TSi, TSr }
Example 4: Two certificate-based authentications of the responder, and one certificate-based authentication of the initiator.
示例4：响应程序的两个基于证书的身份验证，以及启动器的一个基于证书的身份验证。
The MULTIPLE_AUTH_SUPPORTED notification is included in the IKE_SA_INIT response or the first IKE_AUTH request to indicate that the peer supports this specification. The Notify Message Type is MULTIPLE_AUTH_SUPPORTED (16404). The Protocol ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type.
IKE_SA_INIT响应或第一个IKE_AUTH请求中包含支持多个身份验证的通知，以指示对等方支持此规范。Notify消息类型支持多重身份验证（16404）。协议ID和SPI大小字段必须设置为零，并且没有与此通知类型关联的数据。
The ANOTHER_AUTH_FOLLOWS notification payload is included in an IKE_AUTH message containing an AUTH payload to indicate that the peer wants to continue with another authentication exchange. The Notify Message Type is ANOTHER_AUTH_FOLLOWS (16405). The Protocol ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type.
另一个验证有效负载包含在包含验证有效负载的IKE验证消息中，以指示对等方希望继续进行另一个验证交换。通知消息类型是下面的另一种验证（16405）。协议ID和SPI大小字段必须设置为零，并且没有与此通知类型关联的数据。
This document defines two new IKEv2 notifications, MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS, whose values are allocated from the "IKEv2 Notify Message Types" namespace defined in [IKEv2].
本文档定义了两个新的IKEv2通知，支持多个_AUTH_，随后是另一个_AUTH_，其值是从[IKEv2]中定义的“IKEv2通知消息类型”命名空间中分配的。
This document does not define any new namespaces to be managed by IANA.
本文档未定义任何要由IANA管理的新名称空间。
Security considerations for IKEv2 are discussed in [IKEv2]. The reader is encouraged to pay special attention to considerations relating to the use of EAP methods that do not generate shared keys. However, the use of multiple authentication exchanges results in at least one new security consideration.
[IKEv2]中讨论了IKEv2的安全注意事项。鼓励读者特别注意与使用不生成共享密钥的EAP方法有关的注意事项。但是，使用多个身份验证交换会导致至少一个新的安全考虑。
In normal IKEv2, the responder authenticates the initiator before revealing its identity (except when EAP is used). When multiple authentication exchanges are used to authenticate the initiator, the responder has to reveal its identity before all of the initiator authentication exchanges have been completed.
在正常的IKEv2中，响应者在显示启动器身份之前对其进行身份验证（使用EAP时除外）。当使用多个身份验证交换对启动器进行身份验证时，响应者必须在完成所有启动器身份验证交换之前显示其身份。
The authors would like to thank Bernard Aboba, Jari Arkko, Spencer Dawkins, Lakshminath Dondeti, Henry Haverinen, Russ Housley, Mika Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, Magnus Nystrom, Mohan Parthasarathy, and Juha Savolainen for their valuable comments.
作者要感谢伯纳德·阿博巴、贾里·阿尔科、斯宾塞·道金斯、拉克希米娜·唐德蒂、亨利·哈夫里宁、罗斯·霍斯利、米卡·朱特森维塔、查理·考夫曼、泰罗·基维宁、约阿夫·尼尔、马格纳斯·尼斯特罗姆、莫汉·帕塔萨拉蒂和朱哈·萨沃莱宁的宝贵评论。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[EAP]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[PANA] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005.
[PANA]Yegin，A.，Ohba，Y.，Penno，R.，Tsirtsis，G.，和C.Wang，“承载网络接入认证（PANA）要求的协议”，RFC 4058，2005年5月。
Authors' Addresses
作者地址
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com
Jouni Korhonen TeliaSonera P.O. Box 970 FIN-00051 Sonera Finland
Jouni Korhonen TeliaSonera邮政信箱970 FIN-00051芬兰索内拉
EMail: jouni.korhonen@teliasonera.com
EMail: jouni.korhonen@teliasonera.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。