跳到主要内容

4. GROUPKEY-PUSH 消息

GDOI 使用组通信安全地发送控制信息.通常会通过 IP 组播分发 GROUPKEY-PUSH 消息, 但如果无法使用 IP 组播, 也可以通过单播交付方式 "push".GROUPKEY-PUSH 消息替换 Re-key SA KEK 或 KEK 数组, 和/或创建新的 Data-security SA.

Member                               GCKS or Delegate
------                               ----------------

                    <---- HDR*, SEQ, SA, KD, [CERT,] SIG

注: 由 Re-key SA KEK 保护; 加密发生在 HDR 之后.

HDR 在下文定义.SEQ payload 在 Payloads section 中定义.SA 定义 Re-key SA 和/或 Data-security SA 的策略 (例如保护套件) 和属性 (例如 SPI).GCKS 或委托方可选地提供 CERT payload, 用于验证 SIG.KD 是 Payloads section 中描述的密钥下载 payload.

SIG payload 是对加密前完整消息 (包括头部但不包括 SIG payload 本身) 的哈希所作的签名, 并在哈希输入前加上字符串 "rekey".该前缀字符串确保 Rekey 数据报的签名不能用于 GDOI 协议中的任何其他目的.

如果 SA 定义 LKH KEK 数组或单个 KEK, 则 KD 包含用于新 Re-key SA 的 KEK 或 KEK 数组, 该新 Re-key SA 具有新的 cookie 对.当 KD payload 承载新的 SA KEK attribute (section 5.3) 时, Re-key SA 会被具有相同组标识符 (section 3.2 消息 1 中指定的 ID) 的新 SA 替换, 并递增相同的序列计数器, 该计数器在 section 3.2 的消息 4 中初始化.如果 SA 定义 SA TEK payload, 则这会通知成员已创建新的 Data-security SA, 其密钥材料由 KD 承载 (Section 5.5).

如果 SA 定义了较大的 LKH KEK 数组 (例如在组初始化和批量重加密期间), 数组的不同部分 MAY 在不同的唯一 GROUPKEY-PUSH 数据报中发送.不过, 每个 GROUPKEY-PUSH 数据报 MUST 是格式完整的 GROUPKEY-PUSH 数据报.因此, 每个数据报都包含一个序列号以及 SA payload 中的策略, 这些策略对应于 KD payload 中发送的 KEK 数组部分.

4.1. 完美前向保密 (PFS)​

GROUPKEY-PUSH 消息由组 KEK 保护, 但在所有情况下, GROUPKEY-PUSH 消息都会在其他信息之外承载新的密钥下载.若要使 GROUPKEY-PUSH 消息具有 PFS, 必须由新生成的秘密来保护密钥下载.该问题有待进一步研究.

4.2. 前向和后向访问控制​

通过 GROUPKEY-PUSH, GDOI 支持 LKH 等算法, 这些算法具备以下属性: 被移出组的成员不能访问新的组密钥 (前向访问控制), 新加入组的成员不能访问旧的组密钥 (后向访问控制)."forward access control" 和 "backward access control" 与 PFS 概念无关, 在文献中曾被称为 "perfect forward security" 和 "perfect backward security" [RFC2627].

文献中还提出了除 LKH 之外提供前向和后向访问控制的组管理算法, 包括 OFT [OFT] 和 Subset Difference [NNL].这些算法可以与 GDOI 一起使用, 但并未作为本文的一部分加以规定.

对组管理算法的支持通过 SA_KEK payload 中发送的 KEY_MANAGEMENT_ALGORITHM attribute 提供.GDOI 规定了一种使用 LKH 实现前向和后向访问控制的方法.其他使用 LKH 的方法, 以及 OFT 或 Subset Difference 等其他组管理算法, 可以作为后续文档的一部分加入 GDOI.任何此类新增内容 MUST 依据 [RFC2434] 中定义的 Standards Action.

4.2.1. 前向访问控制要求​

当使用组管理算法更改组成员关系时, 通常也需要新的 SA_TEK (及其关联密钥).新的 SA 和密钥确保被拒绝访问的成员不再能够参与该组.

如果前向访问控制是该组所需的属性, 则更改组成员关系的 GROUPKEY-PUSH 消息中 MUST NOT 包含新的 SA_TEK 以及 KD payload 中的关联密钥包.之所以需要这样做, 是因为 SA_TEK 策略以及 KD payload 中的关联密钥包并未由新的 KEK 保护.第二条 GROUPKEY-PUSH 消息可以交付新的 SA_TEKS 及其关联密钥, 因为它将由新的 KEK 保护, 因而对被拒绝访问的成员不可见.

如果该组的前向访问控制策略包括向被拒绝访问该组的成员隐藏组策略变更, 则 GCKS MUST 发送两条连续的 GROUPKEY-PUSH 消息来更改组 KEK.第一条 GROUPKEY-PUSH 消息为该组创建新的 KEK.被拒绝访问的组成员将无法访问新的 KEK, 但会看到组策略, 因为该 GROUPKEY-PUSH 消息由当前 KEK 保护.随后一条包含已变更组策略且再次更改 KEK 的 GROUPKEY-PUSH 消息允许实现完整的前向访问控制.GROUPKEY-PUSH 消息 MUST NOT 在不创建新 KEK 的情况下更改策略.

如果 GDOI 中加入了使用 LKH 的其他方法或其他组管理算法, 则这些方法 MAY 移除上述关于必须使用多条 GROUPKEY-PUSH 消息的限制, 前提是这些方法规定如何在单条 GROUPKEY-PUSH 消息中维护前向访问控制策略.

4.3. 密钥管理委托​

GDOI 支持通过 PKI 的委托能力来委托 GROUPKEY-PUSH 数据报.不过, GDOI 并未明确规定 GCKS 如何识别委托方, 而是将其留给特定 GDOI 实现所使用的 PKI.

4.4. 签名密钥的使用​

GCKS SHOULD NOT 使用与 GROUPKEY-PULL POP payload 中用于授权的密钥相同的密钥来签署 GROUPKEY-PUSH 消息中的 SIG payload.如果必须使用同一密钥, 则 POP payload 所基于的哈希函数 SHOULD 与 SIG payload 所基于的哈希函数不同.

最后于 更新