摘要

  • IETF LAKE 工作组于 2026 年 9 月 8 日启动 draft-ietf-lake-authz-08 的工作组最后征求意见，截止日期是 9 月 22 日；它仍是拟走标准轨道的互联网草案。
  • 在 ELA 常规流程中，设备 U 在 EDHOC 第三条消息里发送 ID_CRED_I，域认证方 V 将其交给注册服务器 W；W 出具的凭证到第四条消息才由 V 送回 U。
  • 草案明确承认：U 在确认整套授权能否成功前，已经向通过认证的 V 披露身份；它允许用仅限入网阶段的身份降低关联风险。
  • Daniel Kade 建议用隐私受限的入网回执分别保存认证、授权、拒绝和身份切换结果。这是编辑建议，并非草案要求。

工作组最后征求意见通知要求参与者在 9 月 22 日前表达支持，或说明反对理由并提出解决办法。Datatracker 历史把 9 月 8 日的状态变化记为从“WG Document”进入“In WG Last Call”。这表示文件进入集中审议，不表示意见已经收束。当前文档页仍把第 08 版列为活跃互联网草案，目标是 Proposed Standard，而不是已获 IESG 批准的 RFC。

ELA 全称 Lightweight Authorization using EDHOC。它面向链路、计算和消息大小都受限制的设备，希望把认证、授权与首次入网尽量合并到一次 EDHOC 往返中。参与者有三个：新设备 U、控制目标网络入口的域认证方 V，以及位于较宽松网络一侧的注册服务器 W。

三者的信任来源并不相同。第 08 版假设 U 已经保存 W 的公钥和位置，这是明确的预置关系；V 与 W 可借助 Web PKI 等机制建立隐含关系；U 与 V 则无需事先相识。ELA 的任务，是利用前两条关系为第三条关系提供条件。

第三条消息已经带走设备标识

V 在 EDHOC 第二条消息中向 U 证明其认证凭据。U 随后发出第三条消息，其中既有 ID_CRED_I，也有交给 ELA 的外部授权数据。后者包括 W 的位置和新生成的 DH 公钥或 KEM 密文，用来为即将返回的凭证建立独立保护。

V 再向 W 发送凭证请求。请求包含所选密码套件、绑定前两条 EDHOC 消息的 H_12、临时密钥材料、ID_CRED_I，以及是否需要 W 一并取回 U 完整凭据的标志。W 将 H_12 与设备标识关联，查找并执行适用于 U 的授权策略。策略可以限制允许的身份、时间窗口或可接受的 V；具体策略本身不在草案范围内。

W 若批准，会向 V 返回必要的设备凭据，并按应用需要生成给 U 的凭证。这个凭证表达的并不是“V 认识 U”，而是“W 已授权 V”。其认证数据绑定当前握手、U 的标识和 V 的凭据；可选授权范围对 V 保持不透明，只由 U 与 W 读取。V 把它装入 EDHOC 第四条消息送给 U。

RFC 9528定义的基础 EDHOC 把第四条消息设为可选。ELA 常规流程却不能省略它，因为第三方授权凭证就在这里到达。草案只有在 U 完成第四条消息及外部授权数据处理后，才说 U 与 V 都已获准交互。

这段空隙里存在两种不同状态。U 已用密码学方法认证 V，但尚未收到 W 对 V 的授权；与此同时，U 的标识已经被 V 接收，也已随凭证请求交给 W。验证某把私钥的控制者是谁，并不等于第三方已允许该控制者接纳这台设备。

身份保护不等于身份从未披露

这里不能把 EDHOC 的身份保护描述成失效。外部窃听者与未经认证的一方看不到同样的信息，消息也受到机密性和完整性保护。草案写得更准确：U 会在不知道 ELA 授权流程能否完成之前，把身份告诉一个已经认证的 V。

草案给出一个有针对性的选项。U 可以在首次入网时使用专门的 onboarding 身份，等安全通道建立后再换用不同的运营身份。这样，即使 W 拒绝请求，或 U 找错了入口，先前披露的信息也不必直接成为设备日常运行中的长期标识。

但“可以换身份”并没有自动解决记录问题。V 与 W 是否保存原始 ID_CRED_I、保存多久、能否跨域关联、如何证明临时身份已经停用，都仍由部署方决定。协议保护一条传输路径，组织则决定留下什么记忆。

ELA 所用“凭证”也不能与其他标准中的同名对象混为一谈。RFC 8366定义制造商签名的 voucher artifact，用于把待入网设备安全分配给所有者并固定域证书；ELA 只说自己的凭证具有类似作用、而且更紧凑，并未采用同一格式。RFC 8995给出 BRSKI 中设备、注册方和制造商授权服务之间的三方结构，还单独讨论审计与隐私。RFC 9031展示另一种受限网络入网机制。它们帮助理解制度背景，却不替代 ELA 的实际消息顺序。

被拒绝的握手也完成了一次信息流动

W 可能认识 ID_CRED_I，却因策略拒绝 U 入网。这时接口返回 HTTP 403 或 CoAP 4.03。W 还可以为 U 加密一段可操作的拒绝信息，例如建议改试另一个 V，由当前 V 通过 EDHOC Access denied 错误转交。

拒绝并不等于网络故障。它说明 W 成功处理了请求、找到了相应身份，却没有授权。另一些失败可能发生在取回 U 凭据、验证凭据、校验凭证或等待 W 的过程中。若系统都记成“握手失败”，既无法诊断，也看不出设备身份究竟在哪一步已被谁处理。

IETF 126 LAKE 会议记录显示，与会者讨论后仍决定让 EDHOC 与 ELA 使用不同临时密钥，现场出现一些支持进入最后征求意见的信号，主席随后表示将启动该程序。LAKE 工作组现在负责评估共同规范是否成熟；身份留存的日常治理仍不能外包给这一状态标签。

回执应保存顺序，也应设计遗忘

一份合比例的入网回执不需要复制原始 ID_CRED_I。它可以保存仅适用于本次尝试的单向句柄、V 凭据指纹、W 信任锚与访问端点版本、H_12、策略版本、U 使用的是临时还是运营身份类别，以及一个受控结果：凭证接受、策略拒绝、重定向、凭据失败或超时。

若临时身份后来被运营身份取代，回执应证明切换已发生，却不保留可导出的对应表。留存截止时间与删除结果也应成为明确字段。完整证书、凭证明文、原始设备标识和可用于跨域追踪的映射，不应进入普通运营日志。

以上回执结构是 Daniel Kade 的编辑提议，不属于第 08 版规范。ELA 明确把授权策略留在范围之外。正因如此，部署方必须把“已经认证”“W 已授权”“策略已接受”和“身份已删除”分别保留为事实，不能用一次握手成功替代全部答案。

来源