RFC4739：Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol，November 2006
本备忘录的状态
本备忘录定义了 Internet 社区的实验协议。它没有指定任何类型的 Internet 标准。要求讨论并提出改进建议。本备忘录的分发不受限制。
版权声明
版权所有 (C) IETF 信托 (2006)。
梗概
互联网密钥交换 (Internet Key Exchange，IKEv2) 协议支持多种认证各方的机制，包括使用公钥证书签名、共享密钥和可扩展认证 (Extensible Authentication Protocol，EAP) 方法。目前，每个端点只使用其中一种机制来认证自己。本文档规定了 IKEv2 的扩展，它允许使用多重认证交换，使用不同的机制或相同的机制。例如，此扩展允许对客户端主机执行基于证书的认证，然后对用户进行 EAP 认证。使用后端认证服务器时，它们可以属于不同的管理域，例如网络访问提供商和服务提供商。
1、 简介
IKEv2 [IKEv2] 支持参与 IKE_SA（IKE 安全关联）的各方的多种机制。其中包括带有公钥证书的签名、共享密钥和可扩展身份认证 (EAP) 方法。
目前，每个端点只使用其中一种机制来认证自己。但是，在某些情况下，在 IKEv2 中做出授权决定（是否允许访问）需要使用其中的几种方法。
例如，可能需要对请求访问的主机（机器）和当前使用主机的用户进行认证。这两种认证将使用两组独立的凭据（例如证书和关联的私钥），甚至可能使用不同的认证机制。
再举一个例子，当运营商为第三方托管虚拟专用网 (Virtual Private Network，VPN) 网关服务时，可能需要同时向运营商（出于计费目的）和第三方的认证、授权和计费 (Authentication, Authorization, and Accounting，AAA) 服务器（用于授权访问第三方内部网络）。
本文档规定了 IKEv2 的扩展，它允许使用多重认证交换，使用不同的机制或相同的机制。例如，此扩展允许对客户端主机执行基于证书的认证，然后对用户进行 EAP 认证。
需要与后端 AAA 服务器通信的每个认证交换可能会被定向到不同的后端 AAA 服务器，甚至位于不同的管理域中。但是，IKEv2 网关和后端认证服务器之间的通信细节超出了本文档的范围。特别是，本文档没有指定对现有 AAA 协议的任何更改，也不需要使用任何特定的 AAA 协议。
在多个 EAP 认证的情况下，重要的是要注意它们不是一个“序列”（如 [EAP] 的第 2.1 节所述），而是单独的独立 EAP 会话，这些会话通常也在不同的 EAP 服务器中终止。如 [EAP] 的第 2.1 节所述，仍然禁止在单个 EAP 会话中使用多种认证方法。使用多个独立的 EAP 对话类似于为 [PANA] 计划的单独的网络访问提供商 (Network Access Provider，NAP) 和互联网服务提供商 (Internet Service Provider，ISP) 认证交换。为每个 EAP 认证会话发现适当的 EAP 服务器是基于 AAA 路由。
1.1、 使用场景
图 1 显示了运营商托管 VPN 场景的示例架构，该场景可以从 IKEv2 交换中的两阶段认证中受益。首先，客户端向网络访问提供商 (NAP) 进行认证，并获得对 NAP 托管的 VPN 网关的访问权限。第一阶段认证涉及 NAP 的后端 AAA 服务器。在第一次认证之后，客户端发起第二轮认证，也涉及第三方的后端 AAA 服务器。如果两个认证都成功，则设置所需的 IPsec 隧道，并且客户端可以访问第三方背后的受保护网络。
图 1：用于通过网络访问提供商访问第三方网络的两阶段认证。AAA 流量通过 NAP 的 AAA 服务器。
NAP 的 AAA 服务器可用于将 AAA 流量代理到第三方的后端 AAA 服务器。或者，来自 NAP 隧道端点的 AAA 流量可以直接进入第三方的后端 AAA 服务器。然而，这或多或少是一个 AAA 路由问题。
1.2、 术语
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是被解释为 [KEYWORDS] 中的描述。
本文档中的术语和缩写“authenticator”、“backend authentication server”、“EAP server”和“peer”应按照[EAP]中的描述进行解释。
当描述包含 IKEv2 有效负载的消息时，可选有效负载显示在括号中（例如，“[FOO]”），加号表示有效负载可以重复一次或多次（例如，“FOO+”）。
2、 解决方案
2.1、 解决方案概述
对等方通过在 IKE_SA_INIT 响应（响应者）和第一个 IKE_AUTH 请求（发起者）中包含 MULTIPLE_AUTH_SUPPORTED 通知来宣布支持此 IKEv2 扩展。
如果两个对等体都支持此扩展，则它们中的任何一个都可以通过在包含 AUTH 有效负载的任何 IKE_AUTH 消息中包含 ANOTHER_AUTH_FOLLOWS 通知来宣布它希望进行第二次认证。这表明发送 ANOTHER_AUTH_FOLLOWS 的对等方希望向其他对等方认证另一组凭据。此对等方发送的下一个 IKE_AUTH 消息将包含第二个身份有效负载（IDi 或 IDr）并开始另一个认证交换。仅当所有单独的认证交换成功完成时，IKE_AUTH 阶段才被认为是成功的。
假设双方都知道他们想要出示什么凭证；例如，没有关于要进行哪种类型的认证的协商。与 IKEv2 一样，发起方始终请求基于 EAP 的认证（通过省略 AUTH 有效负载）。
AUTH 有效载荷按照 [IKEv2] 第 2.15 和 2.16 节的规定计算，其中 IDi' 指的是发起方发送的最新 IDi 有效载荷，IDr' 指的是响应方发送的最新 IDr 有效载荷。如果使用不生成共享密钥的 EAP 方法，则可能会发送多个具有相同内容的 AUTH 有效负载。当使用这样的 EAP 方法时，AUTH 有效负载的目的只是限定认证交换，并确保 IKE_SA_INIT 请求/响应消息没有被修改。
2.2、 示例 1：多个 EAP 认证
此示例显示响应者的基于证书的认证，然后是 EAP 认证交换（消息 1-10）。当第一次 EAP 交换结束时（发起方正在发送其 AUTH 有效负载），发起方通过包含 ANOTHER_AUTH_FOLLOWS 通知（消息 9）宣布它希望进行第二次认证交换。
此后，开始第二次认证交换。发起者发送一个新的 IDi 有效负载但没有 AUTH 有效负载（消息 11），表明将使用 EAP。之后，接下来是另一个 EAP 认证交换（消息 12-18）。
示例 1：响应者的基于证书的认证，然后是两次 EAP 认证交换。
2.3、 示例 2：混合 EAP 和证书认证
另一个示例如下所示：这里发起者和响应者都首先使用证书（或共享密钥）进行认证；随后是 EAP 认证交换。
示例 2：发起者和响应者的基于证书（或基于共享密钥）的认证，然后是 EAP 认证交换。
2.4、 示例 3：多个发起者证书
这个例子展示了另一种可能性：发起者有两个不同的证书（和相关的私钥），并且向响应者认证它们。
示例 3：发起者的两个基于证书的认证，以及响应者的一个基于证书的认证。
2.5、 示例 4：多个响应者证书
这个例子展示了另一种可能性：响应者有两个不同的证书（和相关的私钥），并向发起者认证这两个证书。
示例 4：响应者的两个基于证书的认证，以及发起者的一个基于证书的认证。
3、 有效载荷格式
3.1、 MULTIPLE_AUTH_SUPPORTED 通知负载
MULTIPLE_AUTH_SUPPORTED 通知包含在 IKE_SA_INIT 响应或第一个 IKE_AUTH 请求中，以指示对等方支持此规范。通知消息类型为 MULTIPLE_AUTH_SUPPORTED (16404)。协议 ID 和 SPI 大小字段必须设置为零，并且没有与此通知类型关联的数据。
3.2、 ANOTHER_AUTH_FOLLOWS 通知负载
ANOTHER_AUTH_FOLLOWS 通知负载包含在包含 AUTH 负载的 IKE_AUTH 消息中，以指示对等方想要继续进行另一个认证交换。通知消息类型为 ANOTHER_AUTH_FOLLOWS (16405)。协议 ID 和 SPI 大小字段必须设置为零，并且没有与此通知类型关联的数据。
4、 IANA 考虑因素
本文档定义了两个新的 IKEv2 通知，MULTIPLE_AUTH_SUPPORTED 和 ANOTHER_AUTH_FOLLOWS，它们的值是从 [IKEv2] 中定义的“IKEv2 通知消息类型”命名空间分配的。
本文档未定义任何由 IANA 管理的新命名空间。
5、 安全考虑
IKEv2 的安全考虑在 [IKEv2] 中讨论。鼓励读者特别注意与使用不生成共享密钥的 EAP 方法相关的注意事项。然而，使用多重认证交换会导致至少一个新的安全考虑。
在正常的 IKEv2 中，响应者在显示其身份之前对发起者进行认证（使用 EAP 时除外）。当使用多重认证交换对发起者进行认证时，响应者必须在所有发起者认证交换完成之前透露其身份。
6、 致谢
作者要感谢 Bernard Aboba、Jari Arkko、Spencer Dawkins、Lakshminath Dondeti、Henry Haverinen、Russ Housley、Mika Joutsenvirta、Charlie Kaufman、Tero Kivinen、Yoav Nir、Magnus Nystrom、Mohan Parthasarathy 和 Juha Savolainen 的宝贵意见。
7、 参考文献
7.1、 规范性参考
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
7.2、 参考资料
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [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.
完整的版权声明
版权所有 (C) IETF 信托 (2006)。
本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文档和此处包含的信息按“原样”提供，贡献者、他/她代表或由（如果有）赞助的组织、互联网协会、IETF 信托和互联网工程工作组免责声明所有明示或暗示的保证，包括但不限于使用此处信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性的保证。
知识产权
IETF 对可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或在此类权利下的任何许可可能或可能不会的程度不持任何立场能得到的;它也不表示它已做出任何独立努力来确定任何此类权利。有关 RFC 文档中权利的程序信息，请参见 BCP 78 和 BCP 79。
向 IETF 秘书处披露的 IPR 披露副本以及任何保证可用的许可，或试图获得本规范的实施者或用户使用此类专有权利的一般许可或许可的结果，可以获得来自位于 http://www.ietf.org/ipr 的 IETF 在线 IPR 存储库。
IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施该标准可能需要的技术的其他专有权利。请将信息发送至 IETF，地址为 ietf-ipr@ietf.org。
致谢
RFC Editor 功能的资金目前由 Internet Society 提供。
