摘要

  • RFC 9594 中，授权服务器只决定客户端是否可以访问群组成员资源；KDC 仍须验证 Join 请求，成功后才建立成员记录并返回应用配置文件所定义的密钥状态。
  • 有效令牌、当前成员、已安装的密钥版本和成功的群组操作是四个不同事实，任何一个都不能自动继承前一个的证明力。

设想一个受限设备拿到签名正确、范围正确、尚未过期的访问令牌。身份平台会把它标成绿色，审计系统也可能立即写下“已加入群组”。但此时设备也许还没有把令牌交给 KDC；即便已经交付，安全关联可能没有建成；即便 Join 返回成功，设备也可能尚未安装响应中的密钥。

RFC 9594 的价值就在于拒绝把这些时刻压扁成一个状态。它规定两个阶段：第一阶段按照 ACE 框架，由客户端、授权服务器和充当资源服务器的 KDC 完成授权；第二阶段才由 KDC 向客户端实际分发群组密钥材料和配置参数。获得“可以申请”的权力，不等于完成“已经成为成员”的事实。

授权服务器决定谁可以敲门

授权服务器根据策略判断客户端能否访问某个群组成员资源，以及允许申请哪些角色。客户端通常把令牌提交到 KDC 的 /authz-info，随后按照所选 ACE 传输配置文件建立或继续使用安全关联。RFC 9202 与 RFC 9203 分别给出 DTLS 和 OSCORE 的做法。

这些步骤都不是 Join。真正的加入请求发送到 /ace-group/GROUPNAME。KDC 要把请求中的群组、范围与角色同已保存的授权相核对，并执行基础规范及应用配置文件要求的验证。只有成功处理后，KDC 才把客户端加入当前成员集合，并返回群组密钥材料以及必要的个体材料、凭据、策略或持有证明。

因此，一个真实有效的令牌仍不能证明 KDC 已收到它，不能证明安全关联仍有效，不能证明 Join 已发送或被接受，也不能证明节点资源已经创建、凭据验证通过，或者密钥已在客户端激活。令牌只能为授权服务器亲自观察到的那一次策略决定作证。

稳定的名字背后可以是轮换的状态

GROUPNAME 标识 KDC 托管的成员资源，一旦建立便保持不变。节点名及其 URI 中的 NODENAME 也保持不变，并且在当前成员中唯一。这种稳定性让管理操作可以持续指向同一对象。

但密码学状态并不稳定。num 参数标记当前群组密钥材料的版本。群组标识符、个体密钥信息、对端凭据和策略都必须放在应用配置文件与当前版本的上下文里解释。两个客户端可以指向相同 GROUPNAME，却暂时持有不同的可用密钥状态。

RFC Editor 的 8239 号技术勘误正好说明版本上下文的重要性：规范中的一段凭据检索示例漏掉了格式要求的 num，勘误将其补回。8864 号勘误则修正了空凭据过滤器的描述。研究时两条都仍处于“Reported”状态，不能被夸大成某个产品漏洞；它们只说明，不带版本的凭据清单不足以复原运行事实。

应用配置文件不是附件，而是合同的一部分

RFC 9594 并未强制所有群组采用同一种安全协议。它统一 KDC 资源、操作、通用 CBOR 消息结构、错误与 IANA 注册表，然后把具体安全做法交给应用配置文件。

配置文件必须明确群组密钥类型和编码、群组与节点标识格式、凭据表示、持有证明方法、群组策略、重密钥消息保护、KDC 支持的资源以及客户端所需能力。ace_groupcomm_profile 的注册值可以命名这份具体合同，却不会替实现者完成合同。

所以，“符合 RFC 9594”不是充分的运营断言。审计还要问：使用哪个配置文件、哪些参数与资源、如何校验 KDC 和成员凭据、密钥安装在哪个版本完成。最小初始规范的原则在这里十分清楚：公共层只承载必须共同的内容，把专业选择留给可被点名、可被测试的配置文件。若产品界面只显示 RFC 标签而隐藏配置文件，分工就变成了责任空洞。

版本加一不等于所有成员同步加一

群组密钥材料在到期时必须更新，也可以定期更新。若应用要求后向安全，新成员加入时可能需要新材料，使其无法解读加入前的通信；若要求前向安全，成员离开或被驱逐时可能需要新材料，使旧状态无法解读未来通信。

KDC 在分发新材料前先把 NUM 递增，并向群组分发 NUM+1。分发可能需要面向不同成员的多条消息。RFC 9594 明确认可暂时失配：一部分成员已经拿到新版本，另一部分仍停在旧版本。重密钥完成后，KDC 才删除旧材料，并应持久保存新材料。

本文不重复 RFC 9838 文章关于成员移除后 KEK—TEK 两阶段排除的专属论点。RFC 9594 在这里拥有更窄的边界：KDC 内部的版本递增和成员表变化，不能证明每台客户端同时完成了接收、验证与激活。版本号、发送回执、本地安装和恢复请求需要分开记录。

Dispatcher 能送达流量，却不能授予成员资格

加入之后，客户端可通过 Dispatcher 参与一对多通信。在组播场景中，这个角色可以隐含在传输里；在发布—订阅或中继架构中，它可能是显式的代理。RFC 9594 把显式 Dispatcher 视为不可信路径中间者：它能看到并转发受保护消息，但没有群组密钥，不能读取明文。

处于传输路径上不等于拥有成员真相。代理可以转发一条消息，却无法证明目标都处于同一 num；中继可以覆盖多个节点，却无法证明应用接受。RFC 10020 的既有文章已经专门讨论“受保护群组消息不等于接收端行动”。本文停在更早的控制面：授权怎样成为成员，成员怎样成为已安装的具体配置文件状态。

过渡账本应记录证据，而不是秘密

可审计链条应保存令牌标识或哈希、签发者、受众、范围、角色与到期时间；KDC 接收结果；传输配置文件与安全关联标识；Join 请求标识；GROUPNAME 与 NODENAME；应用配置文件；num；凭据与持有证明的验证结果；本地安装结果；策略版本；重密钥起止；恢复尝试；以及最后一次确认使用。绝不能为了审计方便而记录密钥本身。

每一层只为自己观察到的事实负责。AS 证明策略决定，KDC 证明接纳和分发，客户端证明验证与安装，Dispatcher 证明转发，应用证明最终效果。这正是《heng-lu-note》反复强调的现实分层：记录可以描述现实，却不能凭权威外观创造下一层现实；真正运行的代码才证明允许的状态迁移已经发生。

来源