跳到主要内容

3. GROUPKEY-PULL 交换

GROUPKEY-PULL 交换的目标是在成员端为特定组建立 Re-key SA 和/或 Data-security SA.Phase 1 SA 保护 GROUPKEY-PULL; 对于给定 Phase 1 SA, MAY 存在多个 GROUPKEY-PULL 交换.GROUPKEY-PULL 交换在 Phase 1 SA 的保护下下载数据安全密钥 (TEK) 和/或组密钥加密密钥 (KEK) 或 KEK 数组.

3.1. 授权​

授权 GROUPKEY-PULL 消息有两种可选方式.第一, 可以使用 Phase 1 身份来授权针对组密钥的 Phase 2 (GROUPKEY-PULL) 请求.第二, 可以在 GROUPKEY-PULL 请求中传递新的身份.该新身份可以专属于该组, 并使用由组所有者签名的证书将持有者标识为已授权的组成员.Proof-of-Possession payload 验证持有者确实持有与 Phase 2 身份关联的秘密密钥.

3.2. 消息​

GROUPKEY-PULL 是一个 Phase 2 交换.Phase 1 计算 SKEYID_a, 它是 GROUPKEY-PULL HASH payload 中所用 keyed hash 的 "key".使用本文定义的 Phase 1 时, SKEYID_a 按照 [RFC2409] 派生.与 IKE HASH payload 生成方式一样 [RFC 2409 section 5.5], 每条 GROUPKEY-PULL 消息都对一组唯一规定的值进行哈希.Nonce 会扰动 HASH, 并对重放攻击提供一定保护.重放保护很重要, 因为它可保护 GCKS 免受密钥管理服务器会吸引的攻击.

GROUPKEY-PULL 使用 nonce 来保证 "liveliness", 即防止近期 GROUPKEY-PULL 消息被重放.重放攻击只在当前 Phase 1 的上下文中有用.如果基于先前 Phase 1 重放 GROUPKEY-PULL 消息, HASH 计算会因为 SKEYID_a 错误而失败.该消息会在评估 nonce 之前就处理失败.为了让任一对等体获得重放保护的好处, 它必须尽可能推迟处理, 直到收到协议中证明对等体仍然活跃的消息.例如, Responder 在收到 HASH payload 中正确包含 Nr 的消息之前, MUST NOT 计算共享 Diffie-Hellman 数值 (如果包含 KE payload) 或安装新的 SA.

Nonce 要求协议交换中增加一条消息, 以确保 GCKS 在组成员证明活跃性之前不会将其加入组.GROUPKEY-PULL 成员发起方期望在返回消息的 HASH 中看到自己的 nonce, Ni.GROUPKEY-PULL GCKS 响应方则期望在提供组密钥材料之前, 在返回消息的 HASH 中看到自己的 nonce, Nr, 如下列交换所示.

Initiator (Member)                   Responder (GCKS)
------------------                   ----------------
HDR*, HASH(1), Ni, ID     -->
                          <--     HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I]     -->
   [,CERT] [,POP_I]
                          <--     HDR*, HASH(4),[KE_R,][SEQ,]
                                    KD [,CERT] [,POP_R]

HASH 的计算如下:

HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | CERT ] [ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ] KD [ | CERT ] [ | POP_R])

POP payload 按 Section 5.7 所述构造.

注: 由 Phase 1 SA 保护, 加密发生在 HDR 之后.

HDR 是 ISAKMP header payload, 与 IKE [RFC2409] 一样使用 Phase 1 cookie 和消息标识符 (M-ID).注意, nonce 包含在前两次交换中, GCKS 在活跃性被证明之前只返回 SA policy payload.HASH payload [RFC2409] 证明对等体拥有 Phase 1 secret (SKEYID_a), 以及由 message id, M-ID 标识的该交换的 nonce.一旦建立活跃性, 最后一条消息完成下载 KD payload 的实际处理.

除 Nonce 和 HASH payload 外, 成员发起方还通过 ISAKMP ID payload 标识它希望加入的组.GCKS 响应方向成员告知 SEQ payload 中序列号的当前值; 该序列号对 GROUPKEY-PUSH 数据报排序 (section 4); 成员在安装任何新 SA 之前, MUST 检查该序列号是否大于该成员为该组持有的先前 SEQ payload 中的序列号 (如果有).如果 SA payload 包含 SA KEK attribute, 则 SEQ payload MUST 存在.

3.2.1. 完美前向保密 (Perfect Forward Secrecy)​

GROUPKEY-PULL 的完美前向保密 (Perfect Forward Secrecy, PFS) 通过可选地包含 RFC 2409 所述的 Key Exchange (KE) payload 来实现.如果使用 KE, 则 GROUPKEY-PULL 中会包含一次 Diffie-Hellman 交换.这确保在无法访问 Diffie-Hellman 密钥协商结果时, 不能恢复 TEK 或 KEK.

3.2.2. ISAKMP 头部初始化​

GROUPKEY-PULL 的 HDR 字段初始化如下.

  • cookie 来自 Phase 1.每个 GROUPKEY-PULL 共享 Phase 1 cookie.
  • message ID 由发起方随机生成, 并用于匹配 REQUEST 和 REPLY.
  • next payload 为 HASH.
  • Exchange Type 为 GDOI_GROUPKEY_PULL (值 32).

3.3. 发起方操作​

GROUPKEY-PULL 发起方 MUST 生成 nonce, Ni, 并使用 Phase 1 SA 保护所有消息.Phase 1 SA 为所有 GROUPKEY-PULL payload 提供加密和数据源认证.

3.4. 接收方操作​

GROUPKEY-PULL 响应方 (GCKS) MUST 验证所有 HASH payload, 然后解密后续 payload.GCKS MUST 检查 HASH 计算中的 nonce, Ni 和 Nr, 是否与明文 payload 中发送的 nonce 匹配.如果 HASH payload 验证失败, GCKS MUST 拒绝该消息, 并且 MAY 审计该事件.

GCKS MUST 通过本文范围之外的策略验证组成员的授权.

最后于 更新