跳到主要内容

2.16. Extensible Authentication Protocol Methods (可扩展认证协议方法)

2.16. Extensible Authentication Protocol Methods (可扩展认证协议方法)​

除公钥签名与共享秘密认证外, IKE 还支持 RFC 3748 [EAP] 所定义的方法. 这些方法通常不对称 (面向用户向服务器认证), 且可能非双向. 因此, 通常仅用于让发起方向响应方认证, 并且必须与基于公钥签名的响应方向发起方认证配合使用. 这些方法常与所谓 "传统认证 (Legacy Authentication)" 机制相关联.

本文档引用 [EAP] 意在将来新增方法时无需修订本规范, 但此处仍记录若干较简单变体. [EAP] 定义需要可变消息数量的认证协议. 可扩展认证在 IKE 中通过额外的 IKE_AUTH 交换实现, 必须完成这些交换才能初始化 IKE SA.

发起方若在 IKE_AUTH 交换的第一条消息中省略 AUTH 载荷, 即表示希望使用 EAP. (注意: 非 EAP 认证时 AUTH 载荷为必需, 故本文档其余部分未将其标为可选.) 通过包含 IDi 载荷但不包含 AUTH 载荷, 发起方声明了身份但未证明. 若响应方愿意使用 EAP 方法, 将在 IKE_AUTH 响应中放置 Extensible Authentication Protocol (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 初始建立的每一对消息的消息号递增; 第一对 IKE_AUTH 消息的 ID 为 1, 第二对为 2, 依此类推.

对于在认证副作用下创建共享密钥的 EAP 方法, 该共享密钥必须由发起方与响应方共同用于按 2.15 节共享秘密语法在消息 7 与 8 中生成 AUTH 载荷. 来自 EAP 的共享密钥即 EAP 规范中名为 MSK 的字段. IKE 交换期间生成的此共享密钥不得用于任何其他目的.

不建立共享密钥的 EAP 方法不应使用, 因为若在其他未使用服务器认证隧道的协议中使用, 会遭受多种中间人攻击 [EAPMITM]. 详见安全考虑一节. 若使用不生成共享密钥的 EAP 方法, 消息 7 与 8 中的 AUTH 载荷必须分别使用 SK_pi 与 SK_pr 生成.

使用 EAP 的 IKE SA 发起方必须能够将初始协议交换扩展为至少十次 IKE_AUTH 交换, 以应对响应方发送通知消息或重试认证提示的情况. 所选 EAP 认证方法定义的协议交换一旦成功结束, 响应方必须发送含 Success 消息的 EAP 载荷. 类似地, 若认证失败, 响应方必须发送含 Failure 消息的 EAP 载荷. 响应方可以随时通过发送含 Failure 消息的 EAP 载荷终止 IKE 交换.

在上述扩展交换之后, 包含 EAP Success 消息的那条消息之后的两条消息中必须包含 EAP 的 AUTH 载荷.

当发起方认证使用 EAP 时, IDi 载荷内容可能仅用于认证, 授权与计费 (Authentication, Authorization, and Accounting, AAA) 路由以及选择 EAP 方法. 该值可能与 EAP 方法认证的实际身份不同. 策略查找与访问控制决策必须使用经认证的真实身份. EAP 服务器常实现在与 IKEv2 响应方通信的独立 AAA 服务器中. 此时, 若经认证身份与 IDi 载荷不同, 必须由 AAA 服务器传送给 IKEv2 响应方.

最后于 更新