摘要

  • RFC 9668 可把 EDHOC message_3 与首个 OSCORE 请求合并，在正向角色配置和兼容应用配置文件下，把完整过程压缩到最少两个往返。
  • 客户端推导出安全上下文、服务器验证 message_3、OSCORE 接受请求、应用执行动作和客户端确认响应，是五张不同的回执。

低功耗控制器收到 message_2 后，已经能推导新的 OSCORE Security Context。它随即用这组状态加密了“关闭阀门”的 CoAP 请求，又把 message_3 放在密文前面，一次发出。客户端日志因此写下“安全上下文已建立”。

这句话只描述客户端。此时服务器可能根本没有收到数据包，也可能无法用 kid 找回对应的 EDHOC 会话。即使它成功处理 message_3，后续 OSCORE 检查、应用授权与机械动作仍可能各自失败。

RFC 9668 的价值正在于减少无线链路上的交换。顺序流程要先完成 EDHOC，再开始首个 OSCORE 事务。Initiator 在成功处理 message_2 后已经掌握推导上下文所需的信息，所以可以同步准备 message_3 与受保护请求。二者合并后，密钥建立加一次受保护事务可从三个往返缩短到最少两个。

节省的是空中时间，不是事实层数。

一条消息承载两个语义动作

客户端先构造 message_3，再建立 OSCORE 上下文并保护原始 CoAP 请求。随后它按 EDHOC_MSG_3 | OSCORE_PAYLOAD 的顺序拼接组合载荷。C_R 不放在载荷内，而是作为客户端 OSCORE Sender ID 写入 OSCORE option 的 kid 字段。

编号 21 的空 EDHOC option 标明这个格式。它是 Critical、Safe-to-Forward、属于 Cache-Key、最多出现一次，并且必须为空。它要求服务器先提取 EDHOC 数据，再处理剩余请求。它不是认证徽章，也不是应用批准。

两部分的密码学边界也没有消失。OSCORE 密文并不覆盖 message_3；message_3 使用 EDHOC 自身的保护。传输层面合住了两个对象，安全语义仍各自独立。若监控只保留“组合包已发送”，就主动抹掉了规范最清楚的分界。

服务器必须按顺序穿过九道门

服务器首先确认请求同时带有 OSCORE option 和合法的组合载荷，否则返回 4.00。然后提取 message_3，把 kid 当作 C_R，并据此查找正确的 EDHOC 会话。如果该会话的应用配置文件规定必须发送 message_4，组合流程就应作为客户端错误终止。

会话与配置文件匹配后，服务器才能验证 message_3。失败时要中止会话，不得从该会话建立新的 OSCORE 上下文，并返回未受 OSCORE 保护的 EDHOC 错误。验证成功后，服务器推导上下文、提取 OSCORE 密文、重建请求、移除 EDHOC option，再执行解密、完整性与重放检查。直到这些步骤完成，请求才交给应用。

因此，“服务器有上下文”不等于“请求进入应用”。“请求进入应用”也不等于“应用授权”。每道门都需要自己的时间、结果和关联标识。日志不必保存密钥或原始凭据，但应保存会话代次、transcript 指纹、kid、Partial IV、重放窗口结论、OSCORE 结论和应用事务标识。

kid 尤其值得关注。它既是 OSCORE 发送方标识，又承担 EDHOC 会话定位。RFC 9668 对连接标识增加唯一性约束，避免与现有会话或上下文冲突。单独记录一个字节值没有解释力；必须知道它在什么时间解析成哪一代状态。

受保护响应证明的是响应中所说的内容

当 EDHOC 与 OSCORE 两段处理都成功，服务器必须返回 OSCORE 保护的响应。客户端用新密钥验证它，可以获得 Responder 的密钥确认；OSCORE 也把响应绑定到请求。这样的证据足以说明对端算出了相同的关键材料，并保护响应不被中途篡改。

它仍不能自动证明物理世界已经改变。应用可能用“Changed”表示写入内存、排入队列、提交数据库或发出执行指令。阀门是否到位、作业是否最终落盘、第三方是否接受交易，都属于更远的一层。

应用应使用精确状态：已交付、已授权、已接受、已持久化、已观察、已补偿。密码学能保护这些陈述，却不能替它们扩大含义。如果系统把“受保护响应”直接改写为“动作完成”，它是在象征层替现实层做决定。

超时重试跨越了两种重放边界

受限网络会丢包。组合请求没有响应时，客户端无法立即知道失败发生在哪一层。EDHOC 保证同一会话内的相同 message_3 不会被重复处理；OSCORE 有自己的 replay protection。这两项保护并不自动让业务动作幂等。

例如，首次请求已经通过 OSCORE 并触发一次性动作，但响应在返程丢失。若客户端用新的业务标识重试，应用可能执行第二次。安全的做法是让首次优化请求携带可查询的幂等标识，并把重试决定关联到上一轮已知的最深状态。

对运营人员而言，超时不是结论，而是一段未知区间。告警应该写明“最后确认到 message_3”“最后确认到 OSCORE”“应用已接受但响应未知”，而不是统一写成“安全请求失败”。

尺寸决定优化是否仍然成立

message_3 可能携带较长的证书链或 External Authorization Data。首个应用请求也可能使用 Block-wise。若组合载荷超过 MAX_UNFRAGMENTED_SIZE，客户端必须放弃这次分块尝试，并可退回顺序流程：先发送 message_3 完成 EDHOC，再发送 OSCORE 请求。

这不是偏离标准，而是标准保留给本地部署的未来决定。记录两部分长度、路径 MTU 假设、块号、阈值、回退原因与最终模式，才能判断“两往返”究竟覆盖哪些设备和凭据。只统计成功走优化路径的样本，会把最需要解释的对象排除在外。

RFC 9668 提供了窄而清晰的共同机制。它规定互操作所需的格式与顺序，却没有把某一条线上信号提升为对应用现实的统治权。

来源