摘要

  • RFC 10020 分别定义 CoAP 组、应用组与安全组。三者可以是多对多、一对多、多对一或一对一，具体部署如何对应，由配置者决定，并非协议天然保证。
  • Group OSCORE 能证明受保护消息来自安全组内某个可识别的成员，但 RFC 明确指出：安全组成员资格不能代替应用资源的访问控制。安全传输、发送者身份和操作权限是三项证据。

控制台显示一条“已验证”的指令：签名有效，发送设备的身份明确，接收设备也持有当前的 Group OSCORE 材料。问题是，其中一台接收设备早已从业务编组中移出。它没有从组播监听名单退出，应用路径也没有关闭，安全组密钥更没有及时轮换。

密码学没有失败。失败的是把三张名单当成了一张。

RFC 10020 正面承认这种边界。它是 2026 年 7 月发布的 IETF 标准轨道文件，规定 CoAP 群组通信，废止 RFC 7390，并更新 RFC 7252 与 RFC 7641。文件把 UDP/IP 组播作为群组请求的默认传输方式，同时避免用一个模糊的“组成员”状态覆盖所有权力关系。

三种组，三个问题

CoAP 组由一组端点构成，这些端点被配置为接收发往某个 IP 组播地址和 UDP 端口的 CoAP 群组消息。它回答的是网络问题：哪些端点正在这个地址和端口上监听？组 URI 可以写入组播地址或组主机名；没有另行指定时，CoAP 使用默认 UDP 端口 5683。

应用组由共享某种应用功能的 CoAP 服务器端点构成。它们通过共同的资源实现那项功能。它回答的是业务与功能问题：哪些服务器应当理解这个路径与方法，并按该应用的规则处理？应用组名称可以显式出现在 URI 路径，也可以由请求内容和部署上下文推导。

安全组由持有共同安全材料的端点构成，成员据此保护和验证消息。它回答的是密码学参与问题：谁能在这套安全上下文中生成或处理有效消息？一个端点可以加入多个安全组。

三者并无自动继承关系。RFC 10020 允许它们多对多、一对多、多对一或一对一。为了减少存储和更新成本，多个应用组可以复用一个安全组；为兼容不同算法能力，同一个应用组也可以使用多个安全组。配置实体根据具体部署建立映射。

发送方与接收方名单也不能互相推导。RFC 10020 讨论的是任意源组播（Any-Source Multicast）：发送源可以是、也可以不是目的 IP 组播的成员，而且发送源数量不受这个模型本身限制。把“正在监听”解释成“有权发送”，从网络层开始就已越界。

身份认证停在资源授权之前

安全群组通信采用 RFC 10021 所定义的 Group OSCORE。它建立在 RFC 8613 的 OSCORE 之上，并使用包括 RFC 9052 在内的 COSE 结构，在应用层保护 CoAP 消息。群组模式使用发送端自己的私钥签名；成对模式为一对一通信推导密钥。

这给出了一项边界清楚的保证。接收端可以验证：消息确实由 OSCORE 安全组中某个具体、可识别的端点产生。共享对称材料本身只能做到组级认证，Group OSCORE 进一步提供来源认证。不过，它不认证报文所携带的源 IP 地址和 UDP 端口。

更关键的是，安全组成员资格不是应用资源的通行证。RFC 10020 明确说，不建议用不同安全组的成员关系来落实同一应用组内部的访问策略。成员资格只授予交换受保护消息与认证组成员的能力；是否可以使用应用资源，属于另一个安全域，应依据资源属性或专门的访问控制凭证单独执行。

因此，“签名是否有效”回答的是：在这次密钥周期里，谁发了消息。“是否允许执行”回答的是：此身份此刻能否对这个 URI 路径使用这个方法，且其业务范围是否仍然有效。拿前一个答案替代后一个答案，就把密钥分发系统意外变成了权限系统。

RFC 9200 的 ACE 框架可以支持端点向 Group Manager 申请加入安全组时的认证与授权。但获准领取群组安全材料，并不自动等于获准操作这套材料保护的每项资源。加入权、消息真实性与资源使用权必须保留各自的审批和证据。

名单漂移可能始于出厂之前

RFC 10020 使用“配置实体”这个中性称呼，因为建立三种组的未必是同一主体。应用、用户、开发者、云服务、调试或开通工具以及其他参与者都可能配置群组。配置也可能发生在软件创建、工厂生产、经销商处理、首次部署或现场重配等不同阶段。

文件特别指出，不同配置实体之间可能只有极少协调，甚至没有协调。工厂植入安全身份，集成商分配组播地址，云端应用确定资源编组，后来维护人员又只更新其中一层——每个动作单看都合理，合在一起却可能留下仍可达、仍可验签但已经不该执行的端点。

群组维护因此不只是“加人”和“删人”。它还包括更换安全材料，修改 UDP 端口或 IP 组播地址，调整组 URI，重命名应用组，以及拆分或合并群组。工单只写“设备已退组”，却不说明退出哪一种组、另外两张名单由谁核对，这样的记录无法证明权限真的收回。

安全组还有密钥周期。OSCORE 组必须采用重新换钥机制来实现撤销与更新。如果成员频繁进出、换钥又很慢，运营方可以审慎地积累若干变更后再执行，避免通信长期被换钥过程拖住。代价同样明确：换钥完成之前，刚离开的成员可能继续使用旧材料访问通信；视策略而定，新成员也可能接触加入前的受保护内容。

所以“仍是安全组成员”不是一个没有时间维度的布尔值。记录必须包含密钥 epoch、退组时刻、换钥是否完成，以及哪些成员已经切换。否则，当前成员与尚未被实际撤销的离开者会显示成同一种状态。

没有回复，不代表没有执行

群组请求还会改变审计者能从回复中推断出的事实。客户端通过组播发送一次请求，每台服务器通常分别通过单播返回响应。为了避免受限网络出现响应风暴，群组请求使用 Non-confirmable 消息，服务器在随机 Leisure 时间窗内错开发送；NSTART 和 PROBING_RATE 等拥塞约束仍然有效。

服务器也可以抑制回复。RFC 10020 建议：遇到错误或没有有用内容可回时，应当抑制响应，除非该资源的应用策略明确要求返回。客户端的 No-Response 选项只能在事先认定适合受其影响的资源上使用。

因此，沉默可能表示请求丢失、资源不匹配、拒绝结果被抑制、响应仍在延迟、返回报文丢失，也可能表示操作已经执行但按策略不回复。客户端以新的 Message ID 重发时，处理过第一份请求的服务器可能再次处理第二份。单纯统计收到多少响应，既不能还原接收名单，也不能证明副作用次数。

这正是 Heng Lu 所说的运行代码优先 在群组控制里的含义。配置记录说明系统打算让谁可达、谁提供资源、谁持有密钥；运行证据说明设备实际做了什么。二者都不可少，也不能彼此冒充。

三名单授权回执

可以用一份三名单授权回执把这条证据链保留下来。第一部分记录 CoAP 组：组播地址或主机名、UDP 端口、地址作用域、监听端点、发现来源和配置 epoch。发送端单独记录，因为任意源组播不要求发送者也监听目的组。

第二部分记录应用组与具体资源决定：URI 路径、方法、载荷类别、预期提供该功能的服务器集合、策略版本、接受审查的访问凭证或资源属性、决策结果及有效期。“验签成功”不能自动填进授权结果栏。

第三部分记录安全组：Group Manager、组标识、算法套件、认证到的发送者、OSCORE 密钥 epoch、加入凭据、退组状态、上次换钥及完成范围。发送者身份认证与网络源地址验证应分栏保存；需要证明地址可达时，RFC 9175 的 Echo 选项可以帮助确认已认证请求者确实能在所称地址接收挑战。

结果部分列出预期接收者、已观察处理结果、响应抑制策略、Leisure 窗口、收到的回复、已知丢包、重发与副作用。沉默保持为“尚未确定”，不能被自动写成“未执行”。生命周期部分则把每次名单变化连接到实际配置者，并记录另外两张名单是否完成对账。

这份回执是 Daniel Kade 的编辑性治理建议，不是 RFC 10020 的新增要求。它要防止界面把“地址正确、资源存在、密钥有效”压缩成一个无法追责的绿色图标。

安全组播仍有放大边界

RFC 10020 强烈不建议使用 NoSec 群组通信，只把例外留给范围狭窄、后果明确且无法或无须获得安全保护的步骤，例如某些早期发现。NoSec 群组服务器不得暴露于公共互联网。原因在于组播天然具有倍增效果：攻击者伪造一次请求的源地址，多台服务器就可能把响应发向受害者。

Group OSCORE 通过认证发送者并保护 URI 路径与查询来缩小攻击面，限制响应与 Echo 也能进一步缓解，但不能让风险归零。路径上的攻击者、安全组内部的恶意成员、允许回复的服务器数量与响应大小，仍然决定实际影响。

Heng Lu 的“政策之镜” 提供了更合适的界面标准：系统应显示权力实际分散在哪里。组播配置、应用资源、Group Manager、授权服务、回复策略与运行证据由不同主体控制。“群组健康”这种总标签恰好隐藏了需要追责的差异。

BTW Media 以现实而非倡议为产品 的原则，在这里要求一种克制：组播地址证明目的地配置，Group OSCORE 证明某个安全周期内的发送身份，授权服务证明资源使用权，运行证据证明实际结果。让每项保证只说自己能够证明的事实，才是可信的控制。

来源