摘要

  • RFC 9867 让 IKEv2 可以在 IKE_INTERMEDIATE 或 CREATE_CHILD_SA 中混入 PPK，也可以在创建、重建 Child SA 或重建 IKE SA 时使用新的 PPK。
  • CREATE_CHILD_SA 响应即使没有返回 PPK 身份，普通 IKEv2 流程仍可能创建新的 SA。若这种回退违反发起方的强制策略，发起方可以马上删除刚创建的 SA。
  • 每个 SA 都需要一张区分选择、确认、授权、创建、接受、使用和删除的 PPK 混入凭据。这是 Daniel Kade 的编辑建议，不是 RFC 字段或 IETF 命令。

“SA 创建成功”很容易被当作终局证据：对端作出了响应，密钥材料经过计算，SPI 进入状态表，自动化系统也拿到了一个可以计数的成功事件。几个月后，迁移报告可能据此声称，这条连接已经完成后量子增强。

RFC 9867 暴露了这种推理缺少的中间层。响应方可能不支持扩展、没有配置相应功能、找不到发起方提供的 PPK 身份，或者双方在同名身份下保存了不同密钥值。在 PPK 为可选项时，协议仍可继续，新的 SA 也仍可成立。交换的成功是真实事实，PPK 没有参与同样是真实事实。

一条逻辑连接包含多条密钥谱系

IKEv2 并不是只产生一个永久不变的“隧道”。它建立 IKE SA，完成双方认证，创建 Child SA，也允许分别重建 Child SA 与 IKE SA。因此，“这个隧道用了 PPK”少了三个必要限定：具体是哪一个 SA、在哪一次交换、进入了哪一轮密钥派生。

RFC 8784 先定义了一种把预共享密钥混入 IKEv2 会话密钥的方法。它以初始建立阶段为前提，但不能用该 PPK 保护最初的 IKE SA 本身。RFC 9867 没有取代它，而是增加两条路径。记录系统必须保留实际路径，不能把所有结果归为一个“PPK 已启用”标签。

第一条路径使用 RFC 9242 定义、发生在认证前的 IKE_INTERMEDIATE。发起方可提供一个或多个 PPK 身份，响应方从中选择并返回确认值。PPK 在 IKE_AUTH 前参与运算，因此能为初始 IKE SA 以及认证交换提供额外保护。如果同一阶段还有其他中间密钥交换导致重新计算，RFC 9867 要求 PPK 操作必须是进入下一次交换前的最后一次重算。先后次序不是实现细节，而是安全主张的一部分。

第二条路径使用 CREATE_CHILD_SA。它允许在不拆掉整个现有 IKE 关系的前提下，用新的 PPK 创建或重建 Child SA，或者重建 IKE SA。这为轮换提供了可操作性，也意味着同一控制关系之下可以同时存在不同谱系：旧的 IKE SA、继续运行的旧 Child SA、新 Child SA 和重建后的 IKE SA，不能自动继承同一个保护结论。

RFC 9370 关于多重密钥交换的机制，以及 RFC 9838 对传统与后量子混合方案的术语，都提供了重要背景。但算法清单只能说明能力，成功协商只能说明事件发生；两者都不能单独证明某份贡献确实进入某一个 SA 的密钥。

身份匹配、数值确认与使用授权并非一件事

RFC 9867 使用两个登记过的 IKEv2 通知：USE_PPK_INT 的值为 16445，PPK_IDENTITY_KEY 的值为 16446。IANA 注册表能证明这些参数的正式分配。它们是可观察的协议元素，却不是 PPK 秘密本身，更不能成为在日志中保存秘密的理由。

确认值取协商伪随机函数针对规定上下文计算结果的前八个八位组。它可以发现一种重要错误：双方选中了看似相同的 PPK 身份，但实际持有的 PPK 值不同。这比“配置里找到了同名条目”更强，却仍未证明该密钥获准用于随后认证出来的对端身份。

在 IKE_INTERMEDIATE 阶段，响应方可能必须先选择 PPK，随后才通过认证知道发起方是谁。身份明确后，本地策略可能发现，这把 PPK 不应该授权给该对端。RFC 9867 表示此时应当中止，同时也允许在本地策略同意时继续。找到材料、确认数值相同、识别对端、批准这组对应关系，是四个不同判断。

自动化最容易在这里失真。密钥库说“已找到”，确认机制说“数值相同”，认证说“这是某个对端”，策略引擎才有权说“允许使用”。若系统只保存一个成功布尔值，就无法还原每一步是谁作出的决定。

先创建、后拒绝、再删除的真实状态

最尖锐的例子发生在 CREATE_CHILD_SA。发起方请求使用新的 PPK。响应方若不支持、未配置、无匹配身份或数值不一致，就不会在响应中带回 PPK_IDENTITY_KEY，但普通 IKEv2 处理仍可能生成新的 SA。

如果发起方的 PPK 策略是可选的，它可以接受并使用这个 SA。如果策略是强制的，同一个 SA 就不符合要求，发起方可以立即将其删除。两边都可能完全遵守协议，可是只看创建事件的仪表盘会把后一种短暂对象误判为增强成功。

因此，至少有三个时间点不可合并：SA 何时创建、本地策略何时判定缺少 PPK 证据、SA 何时被接受或删除。数据面也需要回答：删除前是否有包通过？故障切换是否曾安装它？本地删除后，对端是否仍认为它有效？RFC 规定交换行为，运营者仍需为自己的风险主张收集证据。

“强制”也必须有主体与范围。它可能只适用于某个对端、某类流量、某次重建或迁移的某一阶段，不能从软件支持 PPK 这一事实中推导出来。可选回退可能是清醒的互操作策略。治理错误不是存在回退，而是用回退结果冒充更强状态已经得到证明。

记录密钥转换，但绝不记录密钥

本文提出的 PPK 混入凭据 是一种编辑控制记录，不是 RFC 9867 规定的字段，也不是新增协议或集中采集命令，绝不能包含 PPK 秘密。

对每一个新建或重建 SA，凭据应记录交换类型及父 IKE SA 的谱系，说明走的是 RFC 8784 还是 RFC 9867 的哪条路径。它可以保存非秘密身份或经过隐私设计的指纹、提供与选择状态、确认结果，以及认证身份何时可用。双方可观察到的强制或可选策略、策略版本、决定者和例外负责人也应分开记录。

接着是派生顺序。如果多个中间交换都改变了密钥，PPK 是否按该路径的要求成为最后一次重算？SPI 和 SA 标识可把记录绑定到对象，却不能自己证明运算。创建、安装、接受、首次用包、最后用包和删除应是不同状态，还要附上回退或删除原因、回滚决定与下次复核时间。

凭据必须承认观察边界。抓包可以显示通知和流量，却未必看到实现内部的私有密钥计划。实现可以证明贡献已应用，同时不泄露秘密。跨厂商主张则依赖边界清楚的信任。每条观察都应标明来源组件，推断必须明示为推断。

真正有用的问题不是“IKE 是否成功”，而是：针对这个 SA、这条谱系和这版策略，有什么证据表明预期 PPK 在正确时点进入正确派生，随后这个 SA 又经历了什么？

迁移结论要落到具体 SA

后量子动机同样不能被口号化。RFC 9867 说明，当前一般不认为对公钥机制构成威胁的密码学相关量子计算机，会以相同方式影响对称密码原语。把强 PPK 在认证前混入，因而可以增加一条保护路径。这并不等于声称此类计算机已经存在，也没有给出时间表，更没有认证任何产品“量子安全”。

“新的 PPK”也必须确实不同。再次使用原来的 PPK，并不能实现这条新鲜轮换路径的意义。密钥的熵、保管、分发与泄露响应仍是运营责任，交换成功无法替它们作证。

可靠的迁移报告不应使用全网统一的形容词，而应统计每个 SA 的准确路径与结果：RFC 8784、IKE_INTERMEDIATE、带新 PPK 的重建、可选回退、确认失败，或者创建后因强制策略立即删除。这些差异不是需要抹平的脏数据，而是实际决策表面。

协议之所以允许在能力不齐时继续，是因为网络需要互通。治理的任务，是保留它究竟以何种方式继续。RFC 9867 给出了灵活的转换机制，却没有允许任何人把“已创建”扩写成尚未收集的证据。

来源