Skip to main content

3. GROUPKEY-PULL Exchange (GROUPKEY-PULL交换)

GROUPKEY-PULL交换的目标是在特定群组的成员处建立重密钥 (Re-key) 和/或数据安全SA。第1阶段SA保护GROUPKEY-PULL; 对于给定的第1阶段SA，可以 (MAY) 有多个GROUPKEY-PULL交换。GROUPKEY-PULL交换在第1阶段SA的保护下下载数据安全密钥 (TEKs) 和/或群组密钥加密密钥 (KEK) 或KEK数组。

3.1. Authorization (授权)​

授权GROUPKEY-PULL消息有两种可选方法。首先，可以使用第1阶段身份 (Phase 1 Identity) 来授权群组密钥的第2阶段 (GROUPKEY-PULL) 请求。其次，可以在GROUPKEY-PULL请求中传递新的身份。新身份可以特定于群组，并使用由群组所有者签名的证书 (Certificate) 来将持有者标识为授权的群组成员。拥有证明载荷 (Proof-of-Possession Payload) 验证持有者拥有与第2阶段身份关联的密钥。

3.2. Messages (消息)​

GROUPKEY-PULL是第2阶段交换。第1阶段计算SKEYID_a，它是GROUPKEY-PULL HASH载荷中使用的密钥哈希中的"密钥"。当使用本文档中定义的第1阶段时，SKEYID_a根据 [RFC2409] 派生。与IKE HASH载荷生成 [RFC 2409第5.5节] 一样，每个GROUPKEY-PULL消息对唯一定义的一组值进行哈希。随机数 (Nonces) 排列HASH并提供一些针对重放攻击 (Replay Attacks) 的保护。重放保护对于保护GCKS免受密钥管理服务器将吸引的攻击非常重要。

GROUPKEY-PULL使用随机数来保证"活性" (Liveliness)，或防止重放最近的GROUPKEY-PULL消息。重放攻击仅在当前第1阶段的上下文中有用。如果基于先前的第1阶段重放GROUPKEY-PULL消息，由于错误的SKEYID_a，HASH计算将失败。消息将在评估随机数之前失败处理。为了让任一对等方获得重放保护的好处，它必须 (MUST) 推迟尽可能多的处理，直到它在协议中接收到证明对等方处于活动状态的消息。例如，响应方禁止 (MUST NOT) 计算共享的Diffie-Hellman数 (如果包含KE载荷) 或安装新的SA，直到它接收到在HASH载荷中正确包含Nr的消息。

随机数需要在协议交换中增加一条消息，以确保GCKS在证明活性之前不会添加群组成员。GROUPKEY-PULL成员发起方期望在返回消息的HASH中找到其随机数Ni。GROUPKEY-PULL GCKS响应方期望在返回消息的HASH中看到其随机数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(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载荷按照第5.7节中的描述构造。

* 受第1阶段SA保护，加密发生在HDR之后

HDR是ISAKMP头载荷，使用第1阶段cookies和消息标识符 (Message Identifier, M-ID)，如IKE [RFC2409] 中所述。请注意，随机数包含在前两次交换中，GCKS在证明活性之前仅返回SA策略载荷。HASH载荷 [RFC2409] 证明对等方具有第1阶段密钥 (SKEYID_a) 和由消息ID (M-ID) 标识的交换的随机数。一旦建立活性，最后一条消息完成下载KD载荷的实际处理。

除了随机数和HASH载荷外，成员发起方通过ISAKMP ID载荷标识它希望加入的群组。GCKS响应方通过SEQ载荷将序列号 (Sequence Number) 的当前值告知成员; 序列号对GROUPKEY-PUSH数据报进行排序 (第4节); 成员必须 (MUST) 检查序列号是否大于成员为该群组持有的前一个SEQ载荷中的序列号 (如果持有的话)，然后再安装任何新的SA。如果SA载荷包含SA KEK属性，则必须 (MUST) 存在SEQ载荷。GCKS响应方通过SA载荷将群组的加密策略告知成员，该载荷描述了DOI、KEK和/或TEK密钥材料以及认证转换 (Authentication Transforms)。SPI也由GCKS确定并在SA载荷链中下载 (参见第5.2节)。SA KEK属性包含重密钥SA的ISAKMP cookie对，该cookie对不是协商的而是下载的。SA TEK属性包含本文档第5.4节中定义的SPI。第二条消息下载此SA载荷。如果在SA载荷中定义了重密钥SA，则KD将包含KEK; 如果在SA载荷中定义了一个或多个数据安全SA，KD将包含TEK。如果特定群组有初始TEK集，这很有用，可以避免未来TEK GROUPKEY-PUSH消息的需要 (第4节中描述)。

如上所述，成员可以 (MAY) 在GROUPKEY-PULL交换中的可选CERT载荷中建立与第1阶段身份不同的身份。当成员传递新CERT时，拥有证明 (Proof of Possession, POP) 载荷会伴随它。POP载荷证明成员或GCKS已使用认证它的密钥。当成员传递由群组所有者签名的CERT以证明其授权时，POP_I是包含包括随机数Ni和Nr的哈希的ISAKMP SIG载荷，由成员签名。当GCKS传递由群组所有者签名的CERT以证明其为特定群组提供密钥的权限时，POP_R包含包括连接的随机数Ni和Nr的哈希，由GCKS签名。POP载荷使用随机数对，经过伪随机函数 (Pseudo-random Function, prf) 转换并加密，旨在抵御第1阶段密钥的泄露。CERT和POP载荷的实现是可选的 (OPTIONAL)。

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

如果需要PFS并且在交换中使用可选的KE载荷，则双方计算DH密钥并使用它来保护KD中包含的新密钥材料。GCKS响应方将DH密钥与KD载荷进行异或 (XOR) 并将其发送给成员发起方，成员发起方通过重复此操作来恢复KD，如Oakley IEXTKEY过程 [RFC2412] 中所述。KE载荷的实现是可选的 (OPTIONAL)。

3.2.2. ISAKMP Header Initialization (ISAKMP头初始化)​

Cookies在ISAKMP头中用作弱形式的拒绝服务保护 (Denial of Service Protection)。GDOI GROUPKEY-PULL交换根据ISAKMP [RFC2408] 使用cookies。

Next Payload标识ISAKMP或GDOI载荷 (参见第5.0节)。

Major Version为1，Minor Version为0，根据ISAKMP [RFC2408第3.1节]。

Exchange Type对于GDOI GROUPKEY-PULL交换的值为32。

Flags、Message ID和Length根据ISAKMP [RFC2408第3.1节]。

3.3. Initiator Operations (发起方操作)​

在群组成员 (GDOI发起方) 联系GCKS之前，它必须 (MUST) 通过带外方法 (Out-of-band Method) (如SDP) 确定群组标识符 (Group Identifier) 和可接受的第1阶段策略。使用SA载荷中的GDOI DOI发起第1阶段。一旦第1阶段完成，发起方状态机转移到GDOI协议。

为了构造第一条GDOI消息，发起方选择Ni并创建随机数载荷，构建包括群组标识符的身份载荷，并生成HASH(1)。

在接收到第二条GDOI消息后，发起方验证HASH(2)，提取随机数Nr，并解释SA载荷。如果SA载荷中的策略可接受 (例如，发起方可以支持安全协议和加密协议)，则发起方继续协议。

如果群组策略使用证书进行授权，发起方生成包括Ni和Nr的哈希并对其签名。这成为POP载荷的内容。如果需要，构造CERT载荷，该载荷持有与用于签署POP载荷的私钥对应的公钥。

发起方通过包括CERT和POP载荷 (如果需要) 并创建HASH(3) 来构造第三条GDOI消息。

在接收到第四条GDOI消息后，发起方验证HASH(4)。如果响应方发送了CERT和POP_R载荷，则验证POP签名。

如果存在SEQ载荷，则必须 (MUST) 根据此群组先前接收的任何序列号检查SEQ载荷中的序列号。如果小于先前接收的号码，则应将其视为过时并忽略。如果两个GROUPKEY-PULL消息并行发生，并且在从GCKS返回两个GROUPKEY-PULL消息的结果之间序列号发生变化，则可能发生这种情况。

发起方解释KD密钥数据包，将密钥数据包中的SPI与先前在SA载荷中发送的标识特定策略的SPI匹配。对于TEK，一旦密钥和策略匹配，发起方就准备好发送或接收与TEK策略匹配的数据包。(如果先前已为此TEK策略接收策略和密钥，发起方可以 (MAY) 决定忽略此TEK策略，以防它过时。) 如果此群组有KEK，则将KEK策略和密钥标记为准备使用。

3.4. Receiver Operations (接收方操作)​

GCKS (响应方) 被动地侦听来自群组成员的传入请求。第1阶段认证群组成员并与它们建立安全会话。

当GCKS接收到第一条GDOI消息时，它验证HASH(1)，提取Ni，并解释ID载荷以确定请求的群组。如果GCKS愿意为该群组提供密钥，它生成Nr并构造包含群组策略的SA载荷，然后发送HASH(2)。

在接收到第三条GDOI消息后，GCKS验证HASH(3)。如果存在CERT和POP_I载荷，GCKS验证POP签名。

GCKS构造第四条消息，包括当前序列号 (在SEQ载荷中，如果定义了KEK)、密钥材料 (在KD载荷中)，以及可选的CERT和POP_R载荷 (如果需要)，并发送HASH(4)。

Last updated on