2.16. 可扩展认证协议方法
2.16. 可扩展认证协议方法
除了使用公钥签名和共享密钥进行认证外, IKE 还支持使用 RFC 3748 [EAP] 中定义的方法进行认证。通常, 这些方法是不对称的 (设计用于用户向服务器认证), 并且它们可能不是双向的。由于这个原因, 这些协议通常用于将发起方认证给响应方, 并且必须 (MUST) 与响应方对发起方的基于公钥签名的认证结合使用。这些方法通常与被称为 "遗留认证" (Legacy Authentication) 的机制相关联。
虽然本文档引用 [EAP] 的意图是将来可以添加新方法而无需更新本规范, 但此处记录了一些较简单的变体。 [EAP] 定义了一种需要可变数量消息的认证协议。可扩展认证在 IKE 中作为额外的 IKE_AUTH 交换来实现, 这些交换必须 (MUST) 完成以初始化 IKE SA。
发起方通过从 IKE_AUTH 交换的第一条消息中省略 AUTH 载荷来表明希望使用 EAP。 (注意, 对于非 EAP 认证, AUTH 载荷是必需的, 因此在本文档的其余部分中未被标记为可选。) 通过包含 IDi 载荷但不包含 AUTH 载荷, 发起方声明了一个身份但尚未证明它。如果响应方愿意使用 EAP 方法, 它将在 IKE_AUTH 交换的响应中放置一个可扩展认证协议 (EAP) 载荷, 并推迟发送 SAr2, TSi 和 TSr, 直到发起方认证在后续的 IKE_AUTH 交换中完成。在最小 EAP 方法的情况下, 初始 SA 建立将如下所示:
Initiator Responder
HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr }
如第 2.2 节所述, 当使用 EAP 时, 每一对 IKE SA 初始设置消息的消息编号将递增; 第一对 AUTH 消息的 ID 为 1, 第二对为 2, 依此类推。
对于作为认证的副作用而创建共享密钥的 EAP 方法, 该共享密钥必须 (MUST) 由发起方和响应方都用来使用第 2.15 节为共享密钥指定的语法在第 7 和第 8 条消息中生成 AUTH 载荷。来自 EAP 的共享密钥是 EAP 规范中名为 MSK 的字段。在 IKE 交换期间生成的此共享密钥必须 (MUST NOT) 用于任何其他目的。
不建立共享密钥的 EAP 方法不应该 (SHOULD NOT) 被使用, 因为如果这些 EAP 方法用在其他不使用服务器认证隧道 (server-authenticated tunnel) 的协议中, 它们会受到一些中间人攻击 [EAPMITM]。详见安全考虑部分。如果使用了不生成共享密钥的 EAP 方法, 第 7 和第 8 条消息中的 AUTH 载荷必须 (MUST) 分别使用 SK_pi 和 SK_pr 生成。
使用 EAP 的 IKE SA 的发起方需要能够将初始协议交换扩展到至少十个 IKE_AUTH 交换, 以防响应方发送通知消息和/或重试认证提示。一旦所选 EAP 认证方法定义的协议交换成功终止, 响应方必须 (MUST) 发送包含 Success 消息的 EAP 载荷。类似地, 如果认证方法失败, 响应方必须 (MUST) 发送包含 Failure 消息的 EAP 载荷。响应方可以 (MAY) 在任何时候通过发送包含 Failure 消息的 EAP 载荷来终止 IKE 交换。
在这样一个扩展交换之后, EAP AUTH 载荷必须 (MUST) 包含在包含 EAP Success 消息的那条消息之后的两条消息中。
当发起方认证使用 EAP 时, IDi 载荷的内容可能仅用于认证, 授权和计费 (AAA) 路由目的以及选择要使用哪个 EAP 方法。此值可能与 EAP 方法认证的身份不同。重要的是, 策略查找和访问控制决策使用实际被认证的身份。通常, EAP 服务器实现在一个单独的 AAA 服务器中, 该服务器与 IKEv2 响应方通信。在这种情况下, 如果不同于 IDi 载荷中的身份, 被认证的身份必须从 AAA 服务器发送到 IKEv2 响应方。