摘要

  • IESG 于 2026 年 8 月 24 日批准 draft-ietf-ipsecme-ikev2-pqc-auth-12 成为 Proposed Standard。证据冻结日为 8 月 27 日；当时文档仍是进入 RFC Editor 队列的活跃 Internet-Draft，尚未获得 RFC 编号。
  • 草案规定如何通过 IKEv2 现有 Digital Signature 方法使用纯模式 ML-DSA 与 SLH-DSA。它没有证明任何网关实际选中这些算法、让大尺寸认证报文通过真实路径、验证 AUTH、建立 IKE SA，或授权 Child SA 承载流量。

两个绿色状态，两个不同结果

迁移审查表里，两台 VPN 网关都显示“后量子就绪”。资产清单里都有一份 ML-DSA 凭据，软件版本也都能识别相关算法。若只看配置，两台设备没有差别。

报文记录却把它们分开。第一台按本地策略回退到 ECDSA，真实 AUTH 中选择的就是传统签名。第二台开始发送体积更大的后量子认证材料，但分片没有在实际网络路径上完整重组。两次连接都没有由 ML-DSA 完成对端认证。

这是一项分析性测试，不是某家厂商或运营方的事故。它揭示这次 IETF 进展真正带来的问题：什么证据才足以允许管理层写下“该隧道已使用后量子签名认证”？

答案不能是一封标准流程公告，也不能是一张功能勾选截图。它必须从文档版本一直连到凭据、双方信号、实际选择、路径交付、签名验证和安全关联结果。

IESG 批准的边界

8 月 24 日的 IESG 公告确认，IP Security Maintenance and Extensions 工作组提交的第 12 版草案获批成为 Proposed Standard。该机制没有另造一套 IKEv2 核心流程，而是把后量子签名放入既有的通用认证框架，并明确说明 ML-DSA 与 SLH-DSA 的使用方式。

文档状态不能省略。8 月 27 日，Datatracker 显示其 IESG 状态为 RFC Ed Queue，RFC Editor 正等待参考文献核查与格式处理。草案日期为 8 月 21 日，到期日写明 2027 年 2 月 22 日。在正式出版前，文本仍可能调整。现在称它为“已发布 RFC”会把一个真实的流程状态抹掉。

草案的 IANA Considerations 还明确表示不申请新的 IANA 分配。它组合已有机制：IANA 现有注册表中的 Digital Signature 认证方法值为 14，IKEV2_FRAGMENTATION_SUPPORTED 通知值为 16430，SIGNATURE_HASH_ALGORITHMS 为 16431，SUPPORTED_AUTH_METHODS 为 16443，Identity 哈希值为 5。这些编号让实现能够互认语义，却不记录任何一次连接实际发了什么。

真正的签名选择写在 AUTH 里

IKEv2 把密钥协商与身份认证分成相邻但不同的阶段。IKE_SA_INIT 协商密码参数、交换 nonce 和密钥交换值。IKE_AUTH 传递身份与认证证据，并通常同时协商首个 Child SA。

RFC 7427 提供了本次扩展所需的通用 Digital Signature 方法。Authentication Data 先放入 DER 编码的 AlgorithmIdentifier，再放签名值。要判断一次 AUTH 究竟使用 ML-DSA-44、ML-DSA-65、ML-DSA-87，还是某组 SLH-DSA 参数，应读取这个实际传输的标识符。

新草案为 ML-DSA 与 SLH-DSA 规定纯模式。它们直接处理与该会话绑定的签名字节，而不是接受外部先算好的摘要。因此，支持这类签名的双方必须在 SIGNATURE_HASH_ALGORITHMS 中包括 Identity 哈希 5；若对端未宣布 Identity 5，就不能使用依赖它的算法。

但 Identity 5 不是签名算法名。它只说明输入保持原样。监控系统在两个方向看见 5，证明的是先决条件；AlgorithmIdentifier、所呈现证书和验证结果才证明本次选择与接受。

宣布支持不是完成协商

草案给出两种帮助对端选择合适密钥类型的机制。Certificate Request 可以表达可接受的证书颁发路径；RFC 9593 定义的 SUPPORTED_AUTH_METHODS 可以按偏好顺序宣布认证方法或签名方案。

RFC 9593 同时指出，发送该通知以及采用其中信息，对双方都是可选行为。它能减少拥有多种凭据时的盲试，却不构成对未来 AUTH 的承诺。设备可能宣布 ML-DSA，随后依据策略选择 ECDSA；也可能呈现无法建立信任路径的证书，或在验证阶段失败。这些结果不能合并成“支持”。

算法标准化还处在更前一层。FIPS 204 定义 ML-DSA，FIPS 205 定义 SLH-DSA；RFC 9881 与 RFC 9909 规定 PKIX 使用的标识符、编码和用途限制。它们不会自动生成私钥、签发证书、配置可信根、保证密码模块吞吐，或证明两种实现可以完成 IKE_AUTH。

因此，生产清单至少应把密钥标识、证书指纹、签发链、key usage、密码提供方、软件构建版本和具体连接策略绑定在一起。

报文大小让路径本身成为证据

这次变化不是简单增加一个开关。草案列出的尺寸很具体：ML-DSA-44 公钥为 1,312 字节，签名为 2,420 字节；即使最小的 SLH-DSA 签名也约有 7,856 字节。证书链还会继续增加负载。

因此，实现该机制的对端必须支持 IKEv2 报文分片。RFC 7383 要求在 IKE_SA_INIT 阶段宣布 IKEV2_FRAGMENTATION_SUPPORTED，随后可以把含 Encrypted payload 的报文分片；IKE_SA_INIT 自身不能使用这套分片格式。

能力信号仍不等于交付。网关可能正确分片，而防火墙、NAT、负载均衡器或丢包路径让接收端无法完整重组。若使用可靠传输，或实现确知 PMTU 足够大，也可能无需分片。审计要记录双方是否宣布支持、实际分片数量与大小、重传、重组状态，以及最终以哪条响应结束交换。

后量子密钥交换不等于后量子签名

许多迁移报告把两种非对称功能压缩成一个“抗量子”标签。密钥交换为共享秘密和机密性服务；签名认证则依据身份、凭据和会话记录证明对端。

RFC 9370 增加 IKEv2 多重密钥交换，并明确说明其紧迫目标是机密性，不处理认证。RFC 8784 把额外预共享密钥混入 IKEv2，但保留而不是替代既有认证检查。因此，一次连接可以在密钥建立中包含后量子或混合成分，AUTH 却仍由 ECDSA 或 RSA 签名。

反过来也一样：看见 ML-DSA AUTH，并不能推断密钥交换使用了哪组算法。两条轴必须分别报告。

AUTH 成功仍不是业务终点

签名验证成功，证明的是本次会话的签名字节在已接受凭据下成立。它不会自动授权所有流量选择器、子网、用户或应用。IKEv2 甚至允许 IKE SA 已建立，而首个 Child SA 创建失败。

一条可复核的声明应连接八份记录：实现的精确草案或 RFC 版本；软件与密码提供方；私钥引用和证书链；双方的 Identity 与认证方法信号；AUTH 中实际选择的 AlgorithmIdentifier；分片、重组和验证结果；IKE SA 的认证身份与回退决定；Child SA 流量选择器、策略结果和实际受保护流量。只有走完整条链，“后量子认证”才是运行事实。

来源