摘要

  • HASH(1) 把发起方提案和 Ni 绑定到既有 Phase 1 状态，HASH(2) 把响应方选择和 Nr 绑定到同一次 Quick Mode，HASH(3) 则让响应方确认发起方已经获得两个 nonce。
  • 第三条消息没有第四条对称回执。即使三条消息全部通过验证，SA 是否写入两端内核、选择器是否生效、保护数据包是否通过、应用是否可用，仍需各自的运行证据。

第三条消息之后，发起方和响应方拥有的知识并不对称。两边都可以计算 HASH(3)，但只有响应方接收它。计算能力可以对称，收据却由消息方向决定。

RFC 2409 把此前分开的组件拼成 IKE。RFC 2408 提供 ISAKMP 的消息框架和状态管理，不指定唯一的认证与密钥交换。RFC 2407 给 IPsec 提案、转换和身份字段赋予领域含义。IKE 采用 Oakley 与 SKEME 的部分机制，规定可以真正互通的交换顺序与派生规则。

Phase 1 建立双向、经过认证的 ISAKMP SA。Main Mode 必须实现，Aggressive Mode 建议实现。二者都从临时 Diffie-Hellman 交换产生经过认证的密钥材料，但身份保护与消息安排不同。

Quick Mode 只用于 Phase 2。它借用 Phase 1 已经建立的认证上下文，为 AH、ESP 等非 ISAKMP 服务协商 SA。昂贵的首次认证因此能支撑多次较短的子协商。

父状态与子状态有不同坐标。Initiator Cookie 与 Responder Cookie 的组合定位 ISAKMP SA；Message ID 定位某一次 Quick Mode。第一条 Phase 2 消息的 IV 由 Phase 1 最后一个 CBC 输出块和该 Message ID 派生，所以同一父 SA 下可以并发多个 Quick Mode，而不共用一条连续 IV 链。

Message ID 找到正确状态，却不自己完成认证。它被纳入 HASH 输入，才与具体消息内容形成密码绑定。字段因此从“索引”进入“被认证的索引”，仍不会自动变成主体身份、政策许可或安装证明。

第一条消息是 HDR*, HASH(1), SA, Ni，还可以附带 KE、IDci 与 IDcr。ISAKMP 头之后的载荷由 Phase 1 SA 保护。HASH 必须紧随头部，SA 必须紧随 HASH。

HASH(1) 覆盖 Message ID 和 HASH 之后的完整消息，包括各载荷头，但不包括加密填充。响应方由此知道：掌握 Phase 1 认证状态的一方，在这次 Message ID 下提交了这些提案、nonce 与可选身份。

这并不等于提案被允许。响应方仍按本地政策选择。它也不表示 AH 或 ESP SA 已经存在于任何运行表中。被认证的是请求，不是请求造成的效果。

第二条消息带回 HASH(2)、响应方选择的 SA 和 Nr。计算在消息内容之前加入 Ni。RFC 2409 把这一加入描述为活性证明：响应不是脱离当前挑战的旧录音。

发起方验证 HASH(2) 后，可以证明持有 Phase 1 状态的响应方看到了自己的 nonce，作出了选择，并给出新的 Nr。两边若对提案解释一致，便拥有派生同一候选 KEYMAT 所需的输入。

第三条消息只有受保护的 HASH(3)。它把一个零字节、Message ID、Ni 与 Nr 输入 PRF。响应方若验证成功，就能证明发起方已经收到 Nr，且仍拥有构造结果所需的认证状态。

证据到此停在响应方。基础 Quick Mode 没有第四条消息告诉发起方：“我已收到并验证 HASH(3)。”这不是说协议承诺了第四条消息而遗漏它，而是说三消息定义本身不包含双向闭环回执。

发起方可以从后续受保护流量、超时与重传或其他控制消息获得新线索。RFC 2408 的 Commit 与 CONNECTED 也另行处理准备状态，但最后消息仍可能丢失。那些是额外证据，不会倒流进 HASH(3)。

即使存在第四条网络确认，它也不会自动证明两个内核安装成功。IKE 守护进程协商密钥与参数；内核或硬件加速器维护真正处理 AH/ESP 包的 SA、SPI、选择器、序列状态、寿命与路由关系。

守护进程收到消息，不等于系统调用成功。系统调用成功，不等于出入两个方向的 SA 都一致。SA 一致，不等于第一包已经通过。第一包通过，也不等于应用获得了可用服务。

两个 nonce 的作用同样精确。Ni 与 Nr 提供新鲜度，阻止旧消息重放制造伪 SA，并参与 KEYMAT 派生。没有 Quick Mode KE 时，KEYMAT 使用 SKEYID_d、协议、SPI 与两个 nonce。

这种派生刷新 Phase 2 密钥，但不提供独立于 Phase 1 指数运算的 PFS。若加入可选 KE，两边再做一次 Diffie-Hellman，把新的共享秘密纳入 KEYMAT，从而为 Phase 2 密钥提供 PFS。

实现必须支持 KE 选项，但每次交换可以不使用。若使用，相关提案中的 Diffie-Hellman 组必须保持一致。若携带客户端身份，它们也必须对这次协商中的每个 SA 一致适用。

PFS 是历史泄露边界，不是安装回执。它回答日后某个长期秘密泄露时，过去的会话密钥是否仍能保密。它不回答本地 SAD 是否写入、SPD 选择器是否接管流量、硬件是否编程、第一包是否到达。

客户端身份揭示另一层授权问题。Phase 1 认证的可能是网关；Quick Mode 的 IDci 与 IDcr 描述网关代表哪些客户端或流量关系。认证网关身份不等于允许它为任意子网建立 SA。

HASH 可以证明这些身份字段属于被保护的转录，本地政策仍决定它们是否被授权。共同协议保证双方读到同一声明，不替任何组织签署自己的访问规则。

响应方可从提案中选择转换与 SPI，并通过 HASH(2) 认证该选择。发起方通过 HASH(3) 表示看到了选择。之后仍可能因为内存不足、选择器冲突、寿命换算、驱动错误、设备限制或晚到的政策检查而安装失败。

HASH 不可能事后吸收这些结果。它固定已经存在的消息输入。把后续失败隐藏在“Quick Mode complete”状态里，是监控系统扩张了声明，不是协议扩大了证明。

IV 规则也区分“收到”与“推进”。Quick Mode 第一条消息的 IV 来自 Phase 1 最后一个 CBC 块与 Message ID；后续消息使用前一密文块。并发交换各自独立。

实现不应在密文刚到达时就推进运行 IV。消息必须先解密、通过基本合理性检查，并被认定确实推进了 IKE 状态机。重传即使密码有效，也不应重复推进。

因此，同一组件内部已有多层事实：收到字节、解密成功、格式通过、HASH 通过、状态机推进。内核安装、数据包命中与应用结果又是另外三层。一个绿色图标不能替八层事实作证。

UDP 上的最终消息丢失使问题变得具体。发起方发出 HASH(3) 后若没有观察到流量，可能重传。响应方必须把它识别为已处理消息，而不是新的授权或第二次安装。

审计应从两边分别记录。发起方侧：验证 HASH(2)、发出 HASH(3)、派生 KEYMAT、安装出入方向 SA、发送与接收保护包。响应方侧：收到并验证 HASH(3)、完成互补安装、出现匹配计数器。只有关联两份记录，才接近双向结果。

Lu Heng 的现实层次视角能阻止证据借位。Message ID 属于关联，三个 HASH 属于认证转录，nonce 属于新鲜度与派生，政策匹配属于授权，SAD/SPD 变更属于运行代码，ESP 计数器属于包处理，应用探测属于服务结果。

代理问题发生在交接处。凭据管理者拥有 Phase 1 身份绑定，安全团队拥有 Phase 2 权限，IKE 进程拥有协商，内核或加速器拥有安装，网络运营拥有包观察，应用负责人拥有可用性。前一代理成功不授权它替后一代理宣布成功。

最小共同规范只需把消息、计算与顺序说明白，不必统一每个主机的政策库、内核接口与日志系统。本地自主仍然成立，也因此必须承担本地收据的责任。

运行代码优先意味着保存连接链：cookie 对、Phase 1 凭据指纹与认证结果、Message ID、Ni、Nr、KE、提案、SPI、三个 HASH 结果、政策版本、安装请求与回执、运行 SA、选择器、计数器、包裁决和应用探测。

链条完整时，故障不会被笼统叫作“VPN 不通”。若响应方没有 HASH(3)，转录在它那一侧未闭合。若两端守护进程完成而某端没有 SA，问题在安装。若两端均有计数而应用失败，问题位于 IPsec 之后。

RFC 2409 发布于 1998 年 11 月。RFC 4109 后来更新 IKEv1 算法要求。RFC 4306 在 2005 年以 IKEv2 取代分立的 RFC 2407/2408/2409 体系；RFC 7296 后来成为 IKEv2 Internet Standard。2023 年 IESG 把 IKEv1 移至 Historic，RFC 9395 将其弃用并关闭相关注册表。

协议已经成为历史，错误推断仍会出现。第三个 HASH 之后，双方知道的事实并不相同。更没有任何一个 HASH 能替两端内核签收。

来源