[RFC6023] 互联网密钥交换版本 2 (IKEv2) 安全协会 (SA) 的Childless 初始化 (翻译）

rfc6023 (ietf.org)

A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)

本文档描述了 Internet 密钥交换版本 2 (IKEv2) 协议的扩展，该协议允许在不生成子 SA 的情况下创建和验证 IKEv2 安全关联 (SA)。

1. 介绍

[RFC5996] 中规定的 IKEv2 要求 IKE_AUTH 交换尝试与 IKEv2 SA 一起创建子 SA。此要求有时不方便或多余，因为某些实现只需要使用 IKEv2 进行身份验证，而其他实现则希望在有任何实际流量需要保护之前设置 IKEv2 SA。本文档中描述的扩展允许创建 IKEv2 SA，而无需尝试创建子 SA。术语 IKEv2、IKEv2 SA 和 Child SA 以及各种 IKEv2 交换在 [RFC5996] 中定义

没有任何子 SA 的 IKEv2 SA 并非徒劳无功。即使没有子 SA，IKEv2 SA 也允许：

o 通过活动检查检查对等方的活动状态。

o 无需公钥操作和用户交互即可快速设置子 SA。

o 对等方的认证。

o 检测 Internet 上两台主机之间的 NAT 。

2. 使用场景

几个场景激发了这个提议：

o 交互式远程访问 VPN：用户告诉客户端“连接”，这可能涉及交互式身份验证。仍然没有流量，但有些可能会晚点来。由于没有流量，网关不可能知道使用什么选择器（如何缩小客户端的提议范围）。

o 位置感知安全，如 [SecureBeacon]。用户在受信任和不受信任的网络之间漫游。而在不可信网络中，所有流量都应该被加密，但在可信网络中，只需要维护 IKEv2 SA。

o 即使没有 IPsec 流量，对等体之间也可能需要 IKEv2 SA。此类 IKEv2 对等方使用活性检查，并向管理员报告“VPN 链接”的状态。

o IKEv2 可用于某些物理安全链路，在这些链路上需要进行身份验证但不需要流量保护。这方面的一个例子是 [3GPP.33.820] 中描述的无源光网络 (PON) 链路。

o 无子 IKEv2 可用于 [RFC5106]，其中我们使用 IKEv2 作为用户身份验证的方法。

o 接收具有无法识别的安全参数索引 (SPI) 的 IPsec 流量的节点应发送 INVALID_SPI 通知。如果该流量来自基于其 IP 地址识别的对等体，则该节点可以设置 IKEv2 SA，以便能够在受保护的INFORMATIONAL交换中发送通知。

o 未来的扩展可能有 IKEv2 SAs 用于为应用程序生成密钥材料，而不需要子 SAs。这类似于 [RFC5705] 在传输层安全 (TLS) 中所做的。

在其中一些情况下，可能会创建一个虚拟的 Child SA 然后将其删除，但这会产生不良的副作用和竞争条件。此外，IKEv2 对等体可能会将 Child SA 的删除视为删除 IKEv2 SA 的原因。

3. 协议大纲

在没有捎带子 SA 协商的情况下是否支持 IKE_AUTH 交换的决定最终取决于响应者。支持的响应者必须在 IKE_SA_INIT 响应中包含第 4 节中描述的通知有效负载。

如果通知包含在 IKE_SA_INIT 响应中，则支持发起方可以发送修改后的 IKE_AUTH 请求，如第 5 节所述。如果通知不存在，发起者不得发送修改后的 IKE_AUTH 请求。

通过在 IKE_SA_INIT 响应中包含通知来通告支持的支持响应者必须处理修改后的 IKE_AUTH 请求，并且必须使用修改后的 IKE_AUTH 响应进行回复。如果发起者没有发送修改后的 IKE_AUTH 请求，这样的响应者不得回复修改后的 IKE_AUTH 响应。

已配置为不支持此协议扩展的支持响应者必须表现得与不支持此扩展相同。如果客户端发送一个 IKE_AUTH 请求（如第 5 节中所述进行修改），则它不得通过通知来通告该能力，并且它应该回复一个 INVALID_SYNTAX 通知负载。

4. CHILLDESS_IKEV2_SUPPORTED 通知

Notify 有效负载如 [RFC5996] 中所述。

o 协议 ID（1 个八位字节）必须为 1，因为该消息与 IKEv2 SA 相关。

o SPI 大小（1 个八位字节）必须为零，符合 [RFC5996] 的第 3.10 节。

o Childless Notify Message Type (2 octets) - 必须是 16418，分配给 CHILDESS_IKEV2_SUPPORTED 的值。

5.修改IKE_AUTH交换

为简洁起见，此处仅介绍 AUTH 交换的可扩展身份验证协议 (EAP) 版本。非 EAP 版本非常相似。下图基于[RFC5996]的附录C.3。

  first request       --> IDi,

                            [N(INITIAL_CONTACT)],

                            [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],

                            [IDr],

                            [CP(CFG_REQUEST)],

                            [V+][N+]

    first response      <-- IDr, [CERT+], AUTH,

                            EAP,

                            [V+][N+]

                      / --> EAP

    repeat 1..N times |

                      \ <-- EAP

    last request        --> AUTH

    last response       <-- AUTH,

                            [CP(CFG_REPLY)],

                            [V+][N+]

请注意缺少的内容：

o 可选通知: IPCOMP_SUPPORTED, USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.
o SA 有效载荷。
o 流量选择器有效载荷。
o 与 Child SA 协商有关的任何通知、扩展负载或 VendorID。

6. 安全考虑

此协议变体继承了 [RFC5996] 中描述的常规 IKEv2 的所有安全属性。

初始交换中携带的新通知通告了能力，不能被对手伪造或添加而不被发现，因为对初始交换的响应是通过 IKE_AUTH 交换的 AUTH 负载认证的。此外，两个对等点都必须配置为使用这种交换的变体，以便响应者接受来自发起者的Childless提议。

7. IANA 考虑

IANA 已从“IKEv2 通知消息类型”注册表中分配了一个名为“CHILDESS_IKEV2_SUPPORTED”且值为“16418”的通知消息类型。