摘要
- RFC 9820 没有把 EAP 方法成功或 MSK 导出当成受保护会话的全部事实。认证器发送受 OSCORE 保护的 Step 7，端点核验后再返回受保护的 Step 8
2.04 Changed；两次核验共同形成双向持有证明。 - 相同的安全上下文不是通往所有应用资源的通行证。引导授权、单个资源策略、会话寿命、重新认证、代际替换和强制删除各有自己的决策者与完成条件。
- 最小可辩护证据应连接 CoAP 资源代次、EAP 结果、非秘密派生谱系、算法协商、Recipient ID、Step 7/8 核验、有效策略、删除回执与独立流量观察，并且绝不记录 MSK。
缓存看见的是旧现在，控制器写下的是新现在
设想一个受限设备正在重新认证。原来的 OSCORE 上下文还有几分钟寿命，新 EAP 方法已经报告成功，控制器于是覆盖了数据库里的代次编号。与此同时，Step 8 尚未被控制器验证，一台资源服务器仍按旧策略缓存接受旧上下文。随后发生了一次不可逆的配置写入。
如果日志只保留设备名和一个 authenticated=true，这次写入会被错误地解释为“新会话已经授权”。协议事实却更细：旧代次仍可能有效；新方法只是得出本地结果；端点也许已经核验 Step 7；认证器还没有拿到返回证据；应用资源又有自己的许可判断。
RFC 9820 规定了在受限环境中以 CoAP 承载 EAP 的认证服务。IoT 设备是 EAP peer，同时又是 CoAP server；Controller 是 EAP authenticator，同时又作为 CoAP client 发起请求。pass-through 模式还可让后端 AAA 服务器参与方法执行与授权数据提供。
角色交叉意味着“客户端成功”这种表述没有审计价值。它没有说明指的是 CoAP 角色、EAP 角色、商业设备还是拥有政策权的组织。RFC Editor 信息页与 IETF Datatracker 文档页把 RFC 9820 列为 IETF Standards Track 规范，源自 ACE 工作组并于 2025 年 9 月发布。这个地位证明规范经过相应程序，不证明某个产品实现、某台设备加入、某次访问获准或某项业务结果发生。
一次交换的顺序由会消失的资源承载
CoAP-EAP 不是在一个永久 URL 后面暗中递增状态。peer 每处理一步，就为下一步建立新的 CoAP 资源，并删除上一步资源；响应中的 Location-Path 或 Location-Query 指向下一个可接受位置。
因此资源代次本身就是会话转录的一部分。发往已删除代次的迟到请求不能凭到达时间重新变成“当前”。活动认证期间重复出现的初始触发需要静默丢弃。会话结束后到来的旧触发可能让认证器误以为新交换已经开始，而 peer 对预期资源给出不存在的回应。
RFC 7252 定义 CoAP 的请求、响应与可靠性语义；RFC 4137 描述 EAP peer 与 authenticator 状态机。RFC 9820 把它们组合起来，却没有让其中任何一个状态机消失。
可追溯记录至少要保留双方协议角色、当前和被销毁的资源代次、请求/响应标识、EAP 转移、CoAP 结果、传输观察与时钟。重试落到不同代次时，还要说明它是被拒绝、被丢弃，还是被解释成一次新认证。
Step 7 把本地结论送到另一端接受检验
EAP 方法成功后，authenticator 获得方法导出的 MSK、EAP Success 消息以及 Session-Lifetime 等授权信息。RFC 5247 提供 EAP 密钥管理框架；RFC 9820 要求所用方法能够导出至少 64 octets 的 MSK 和 EMSK。
认证器手里出现 MSK，并不等于双方已经装入兼容的应用保护上下文。RFC 9820 使用 MSK、密码套件协商转录和规定的上下文字符串派生 OSCORE Master Secret 与 Master Salt。此前交换的 Recipient ID 决定发送和接收方向。RFC 5869 定义 HKDF，RFC 8613 定义保护 CoAP 消息的 OSCORE 上下文。
随后 authenticator 以 OSCORE 保护的 POST 发送 EAP Success。peer 只有取得自己一侧的 MSK、用相同输入派生上下文并成功核验请求，才能把这个消息当作另一种成功指示。
所以 Step 7 不是给既成事实套一层加密包装。它是第一位跨端证人：认证器的本地结论必须在 peer 一侧经兼容上下文验证，才成为对方能够接受的状态。
Step 8 把证明送回发起方
peer 在 EAP 成功并核验 Step 7 后，返回同样受 OSCORE 保护的 2.04 Changed。authenticator 再核验这份响应，才获得双方能够使用同一派生 Master Secret 的返回证据。
至少五个事件不能合成一个绿灯：方法得出成功；MSK 被导出；本地派生完成；peer 核验 Step 7；authenticator 核验 Step 8。丢失最后一个事件不会把前四个改成失败，却会使“双向确认完成”这句话失去依据。
密码套件协商进入派生输入。转录被修改时，两端生成不同上下文，受保护消息便无法通过验证。IANA CoRE Parameters 与 IANA EAP Parameters 为算法和方法代码提供注册表；注册条目不证明某个运行端选择、支持或执行了什么。
审计回执可以保存协商转录哈希、方法和套件标识、双方 Recipient ID、EAP 会话标识、派生代次、二次核验结果以及执行版本。它不应保存 MSK。为了证明没有丢证据而把会话秘密复制到日志，只会制造新的控制面。
同一把保护钥匙没有取得所有资源的决定权
Step 8 之后，最后一个 CoAP-EAP 资源必须以 OSCORE 保护。RFC 9820 允许同一上下文保护其他资源，但前提是应用策略允许。
这个前提划出权限边界。认证说明某种方法对 peer 得出什么结论；密钥确认说明两端能否共同使用派生保护；应用授权说明现在是否允许该 peer 读写这个资源；结果则说明应用最终做了什么。这些判断可以共享证据，不能互相冒名。
在 AAA 架构中，负责 peer 的组织可通过 RADIUS 或 Diameter 提供引导授权数据；standalone 模式下，数据可以位于 authenticator。引导完成后仍可能需要更细粒度授权。RFC 9200 给出 ACE 场景中的 OAuth 授权机制，但引用规范不能代替一次实际 token 判断或资源策略回执。
拥有 MSK 的 Controller 不自动拥有组织政策。发出属性的 AAA 服务器不证明属性已经执行。能验证 OSCORE 的资源服务器也不证明目标操作在许可集合中。真正的回执还需连接政策版本、决策主体、请求、执行结果与独立观察。
认证期间，为承载 CoAP-EAP 所需的 IP 连通性可以存在，但未保护流量应限于认证交换。看到 EAP Success 就开放整段网络，会把方法层的成功扩大成网络层和应用层的授权。
重新认证创造的是两个同时存在的状态
没有提供 Session-Lifetime 时，RFC 9820 依照 RFC 5247 的建议采用八小时默认值。它是协议默认，不是所有部署的安全目标，也不是某个设备实际使用了八小时的证据。
重新认证期间，当前 CoAP-EAP 状态与新候选状态同时活动。新交换完整成功后，旧状态才被删除并替换；新交换失败时，旧状态仍可使用，直到到期或以后续期成功。
因此“续期开始”与“新代次生效”之间存在实质差距。记录要区分旧代次、新候选、方法结果、Step 7/8、激活时间、旧上下文最后一次被接受、撤销和到期。若两个代次同时能处理流量，还要说明这是否符合设计，以及哪类不可逆操作被允许。
这里最能体现运行代码优先：配置可能宣称代次 42 已经替换 41，真正作出资源决定的二进制仍可能接受 41。证据图必须跟随执行中的上下文，而不是按控制平面的级别授予其“唯一现实”。
删除超时只会首先制造本地事实
强制退出时，authenticator 向最后一个 CoAP-EAP 状态资源发送受 OSCORE 保护的 DELETE；peer 返回受保护的 2.02 Deleted。如果响应在 EXCHANGE_LIFETIME 内没有到达，authenticator 会删除自己的本地状态。
本地清理是合理的资源管理，却不证明 peer 收到 DELETE、清除了上下文或停止发送。在网络分区中，认证器可以把会话标成“已驱逐”，peer 仍保留状态，应用缓存仍保留授权，网络也可能继续转发包。
完整链条应保留删除决策者和理由、目标代次、DELETE 发出、peer 接收、peer 本地结果、保护响应、认证器核验、超时、本地清理、下游策略失效、后续拒绝和独立观察到的流量停止。不能取得全部数据时，结论必须标明是已知、推断还是未知。
找到服务还不等于找到正确权威
RFC 9820 把 authenticator 或中介的发现机制留在范围之外。一个设备发现某地址提供 CoAP-EAP，不等于它证明该地址就是组织指定的权限主体。RFC 6677 提供 EAP channel binding 机制，包括有助于暴露下层标识不一致的要素；实际会话仍要保存适用方法、AAA 路径与核验结果。
RFC 9820 说明，peer 可以因为自己的 AAA 服务器信任持有 MSK 的 authenticator 而信任它。这是密钥架构内有条件的委托，不是“可信控制器”四个字。记录必须指明谁委托、经过哪台 AAA、使用哪份配置、落到哪个会话。
伪造大量 Step 0 还可能耗尽认证器状态。规范建议限速，并在收到 EAP-Response/Identity 前尽量少保留状态。限速计数只能证明负载控制执行过，不能证明每个源的身份。
最小实验必须故意让各层意见不一致
实验至少使用一个 peer、一个 authenticator、一条 pass-through AAA 路径、两个不同策略的应用资源和一个独立包观察者。先跑通正常路径，再改变套件转录、丢失 Step 7、丢失 Step 8、重放过期资源代次、重复初始触发、让新认证失败、测量代际重叠、拒绝第二资源，并分别测试有确认与无确认的删除。
每个场景都比较五个表面：EAP 状态、CoAP 资源代次、OSCORE 核验、应用政策和实际流量。测试输出若只剩 success / failure，便没有回答最重要的问题：哪一层在什么时间知道什么。
最有价值的场景不是所有组件一起失败，而是旧代次在一个缓存继续有效、新候选只完成方法、控制器已经改名、应用完成不可逆动作。它暴露“同名状态”怎样掩盖不同权威。
来源没有证明什么
RFC 9820 没有点名任何产品、运营商或实际部署，也没有提供互操作活动、能耗、延迟、丢包、接纳数量或攻击测量。示例用于解释协议，并非生产遥测。
Datatracker 历史、引用 RFC 9820 的文档与 RFC 9820 的引用列表描述文档谱系。RFC Editor errata 检索是编辑状态面，不是安全评分。
RFC 3748 给出更广义的 EAP 框架。规范的存在不能证明某台设备身份、某次授权或某个行动结果。
来源
会员简报
档案背景详情
使用相应会员等级登录，即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance