摘要
- 按 RFC 9838 所述的基础前向访问控制流程,改变成员关系的重换钥先建立新 KEK,随后另一条重换钥消息才在新 KEK 保护下交付新的 TEK 策略与密钥。
- 组播
GSA_REKEY不被确认,也可能丢失。重复发送逐比特相同的密文和使用GSA_NEXT_SPI能帮助恢复,却不能证明每个成员在某一时刻已经安装新状态。 - ATD 推迟新安全关联启用,DTD 推迟旧安全关联删除。排除证明必须覆盖这段有意保留的重叠窗口,不能只引用工单关闭时间。
控制器显示“成员已移除”时,真正的安全问题才刚开始:谁已经拿到新 KEK,谁又已经在新 KEK 下拿到 TEK,旧关联何时失效?
RFC 9838 规定了使用 IKEv2 的组密钥管理 G-IKEv2。RFC Editor 记录显示其于 2025 年 11 月作为 Standards Track 发布,并废止 RFC 6407。这证明规范已经形成,不证明任何实际成员已经成功排除。
它承接 RFC 3740、RFC 4046 与 RFC 5374 所述的 MSEC 架构。组控制器与密钥服务器 GCKS 对组成员 GM 进行认证和授权,再下发组安全关联 GSA,其中可包含数据安全关联和用于组播重换钥的关联。
注册建立初始状态,重换钥改变状态。IKEv2 提供双方安全通道,IPsec 架构、AH 与 ESP 提供安全关联与报文保护语义。进入群组后,困难变成如何让很多接收端在没有集体回执的条件下收敛。
执行移除的第一条消息仍活在旧信任里
前向访问控制是让被移除成员无法得到新的组密钥;后向访问控制是让新成员无法得到旧组密钥。RFC 9838 明确说明,这两者与 IKEv2 的完全前向保密并非同一概念。
改变成员关系的重换钥消息仍由当前 KEK 保护。若把新 TEK 策略和密钥塞进同一条消息,被移除者因为仍持有旧 KEK,照样能够读到。因此,要求前向访问控制时,成员变更消息不得携带新 TEK 材料;第二条消息才能在新 KEK 保护下交付它。
若连新策略本身也不能让被移除者看见,要求更严格:GCKS 必须连续发送两条都会更换 KEK 的消息。第一条建立被移除者得不到的 KEK,但策略仍在旧 KEK 下可见;第二条再次更换 KEK,并携带已变更策略。规范还要求,策略不得在没有新 KEK 的情况下变化。
“两次”不是对未来所有算法的断言。RFC 9838 允许后续 LKH 方法或其他组管理算法在说明如何用单条消息维持前向访问控制时取消多消息限制。RFC 2627 提供逻辑密钥层级的背景。这里需要审计的是当前基础流程,而不是给算法发展设上限。
发出三份副本也不是收到三份回执
GCKS 可以使用单播带内交换,也可使用组播 GSA_REKEY。后者是单向伪交换,没有确认。网络丢掉一条消息,就可能让仍有资格的成员继续停留在旧策略。
为降低丢失风险,服务器可以在数秒内发送多份逐比特相同的加密消息,避免不同接收时间显著扭曲安全关联寿命计算。它也可以通过 GSA_NEXT_SPI 提前告知未来 SPI,使监听成员发现漏收并恢复。
这些机制证明服务器采取了缓解措施,不证明全体成员安装完成。“已发送”与“已接收”、“已安装”、“已启用”必须是不同字段。否则,控制平面的重复次数会被误当成数据平面的收敛证据。
RFC 7383 所述 IKE 分片也暴露同一问题。组播没有响应,GCKS 无法先发未分片消息再判断是否需要分片,也不能使用基于响应的 PMTU 机制,只能依靠预设阈值。成员数、密钥层级和载荷大小都可能改变关键消息完整到达的概率。
可用性重叠不能从撤权报表中消失
激活时间延迟 ATD 规定发送者收到新关联后等待多久才开始使用;停用时间延迟 DTD 规定成员收到删除请求后等待多久才清除旧数据安全关联。这是为持续服务保留的过渡区,也是风险窗口。
因此,一份可信记录至少要区分:授权撤销、新 KEK 生成、新 TEK 安装、新关联启用、旧关联删除。若要证明真实排除,还应观察旧凭证最后一次成功参与组通信的时间。前五项是控制状态,第六项才把声明接到运行现实。
计数器型加密又引入 Sender-ID 与 nonce 状态。RFC 9838 采用 RFC 6054 的方法,为每个发送者配置唯一标识,并在每次注册时分配新值,因为 GCKS 无法可靠知道发送者已经用过哪些 nonce。Sender-ID 空间耗尽时,GCKS 必须排除全部成员,迫使其在新数据安全关联下重新注册。RFC 8221 的算法要求与 RFC 8750 的隐式 IV 不能替代这本状态账。
抗重放也并非一个组级布尔值。多个发送者共享同一安全关联时,各自独立递增序列号,接收者未必能维护有意义的共同窗口。是否启用检查由接收者本地决定;若需要更强保证,GCKS 可以把发送者拆到不同关联,代价是更多状态与运维负担。
IANA IKEv2 参数登记表记录协议分配,RFC 8174说明 MUST 等规范词的效力,RFC 6407保留被废止前身的历史。它们都不是某个终端已经换钥的观测记录。
Heng Lu 所说的最小初始规范、局部未来决策在这里非常具体:共同规范定义安全语义,承担后果的运营者决定可接受的排除期限并提供证据。运行代码优先要求把已安装密钥和真实通信置于工单状态之上;以现实而非倡议为产品则防止把 Standards Track 标签包装成已经部署的保证。
来源
- https://www.rfc-editor.org/rfc/rfc9838.html
- https://www.rfc-editor.org/info/rfc9838
- https://www.rfc-editor.org/rfc/rfc7296.html
- https://www.rfc-editor.org/rfc/rfc4301.html
- https://www.rfc-editor.org/rfc/rfc4302.html
- https://www.rfc-editor.org/rfc/rfc4303.html
- https://www.rfc-editor.org/rfc/rfc3740.html
- https://www.rfc-editor.org/rfc/rfc4046.html
- https://www.rfc-editor.org/rfc/rfc5374.html
- https://www.rfc-editor.org/rfc/rfc6054.html
- https://www.rfc-editor.org/rfc/rfc2627.html
- https://www.rfc-editor.org/rfc/rfc6407.html
- https://www.rfc-editor.org/rfc/rfc7383.html
- https://www.rfc-editor.org/rfc/rfc8750.html
- https://www.rfc-editor.org/rfc/rfc8221.html
- https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml
- https://www.rfc-editor.org/rfc/rfc8174.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
