摘要

  • draft-ietf-lake-authkem-edhoc-01 规定：发起方验证 message_4_KEM 后才认证响应方；响应方必须再验证 message_5_KEM，才能认证发起方。
  • 第三条消息可以同时具备保密性和完整性，却仍不能认证发起方。最终应用密钥必须等到双向认证、握手记录完整性、凭据真实性和持钥证明全部成立后再生成与持久化。

最容易被误判的是握手中段

第三条消息处理完毕时，系统看起来已经掌握了许多“成功”信号。双方完成了一次临时 KEM 交换；发起方检查了响应方凭据，向其静态公钥封装秘密，并把自己的凭据标识放进受保护的密文；响应方也成功解封装和解密。若监控系统只有一个绿色状态，此刻很可能就亮灯。

这张收据开得太早。

9 月 28 日提交的 LAKE KEM 认证 rev01明确写道：保护消息 3 的密钥不能用来认证发起方。响应方此时尚未发出证明自身的 MAC，发起方也还没有发出自己的 MAC。KEM 私钥持有者必须先收到对端向其静态公钥生成的封装，才有材料证明自己掌握对应私钥，因此方案需要额外两条消息。

Datatracker把它列为 LAKE 工作组的活跃 Internet-Draft，IESG 状态只是 I-D Exists。正文希望进入 Standards Track，但它不是 RFC、获批标准、产品实现或部署结果。若未更新或推进，当前版本将在 2027 年 4 月 1 日到期。

两个方向，各有一张完成收据

消息 1 携带临时 KEM 公钥。响应方据此生成封装，在消息 2 中返回密文和自己的凭据标识。发起方若要在下一条消息披露自身凭据，必须先取回响应方凭据，完成验证，并按本地策略接受它。草案特别区分了“密码学有效”和“可信且属于预期对象”：一份签名正确的凭据，仍可能来自不受信或接错的对端。

发起方随后向响应方静态 KEM 公钥封装 ss_R，在消息 3 中发送相应密文和受保护的自身凭据。响应方能够解封装，只能说明它掌握相应私钥材料；并不等于身份绑定已闭合。message_4_KEM 中的显式 MAC 才让发起方认证响应方。完成该验证后，发起方才可保存 PRK_out 或应用密钥。

另一个方向仍然未完成。响应方必须等到 message_5_KEM，验证发起方的 MAC 后，才能认证发起方。草案承认，潜在的错绑攻击可能一直到这两个最终检查才暴露。因此，在握手完成前，EAD 应视为未受保护，密钥材料不应持久化。

一个全局 authenticated=true 无法表达这种时间窗：一端已经确认对端，另一端还没有。成功解封装也回答不了秘密究竟绑定哪一个身份、哪份信任策略、哪段握手记录，以及随后允许执行什么操作。

“后量子”不替代每次会话的新鲜度

新密钥日程把一份临时 KEM 贡献和两份静态 KEM 派生秘密混合起来。草案要求每次会话都重新向静态公钥生成封装；ss_I、ss_R 及其密文不得跨会话复用。它还要求 KEM 具备 IND-CCA2 安全性，并把共享秘密以密码学方式绑定到接收者公钥，因为 IND-CCA2 本身不能排除重新封装与未知密钥共享。

RFC 9935与 FIPS 203定义 ML-KEM，却不会替某把公钥证明组织身份。SP 800-227说明 KEM 的安全使用；RFC 9528仍是 EDHOC 基线。新草案提出的是 LAKE 的记录、凭据和确认顺序，并没有给出部署、互操作或性能结论。

安全章节还主动排除了“不可否认性”。该方法只提供隐式参与证明。即便 LAKE 对端通过认证，也不会自动获得修改路由、安装软件、转移资金或驱动物理设备的权限。运营账本必须分别记录：方法与套件、凭据标识及本地验证结果、消息 2 至 5 的处理状态、MAC_2 与 MAC_3 的验证、不可泄密的会话新鲜度标识、允许持久化密钥的转移点、应用授权、受保护请求与响应，以及最终效果。

BTW 此前对 RFC 9668的报道处理的是另一个边界：把 EDHOC 消息 3 与首个 OSCORE 请求合包，不代表应用已经执行。此次草案把边界向前推了一层：在其 KEM 方法里，消息 3 连认证本身都尚未完成。

运行代码优先要求真正中断消息 4/5、重放封装、替换凭据、制造套件不匹配，再观察系统留下什么状态。最小初始规范支持只共享两条薄规则：显式完成状态和每会话新封装；具体信任策略仍由本地决定。现实层级则阻止持钥、可信身份、授权与实际结果互相借用权威。

来源