Skip to main content

3. GROUPKEY-PULL Exchange

The goal of the GROUPKEY-PULL exchange is to establish a Re-key and/or Data-security SAs at the member for a particular group. A Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange downloads the data security keys (TEKs) and/or group key encrypting key (KEK) or KEK array under the protection of the Phase 1 SA.

3.1. Authorization​

There are two alternative means for authorizing the GROUPKEY-PULL message. First, the Phase 1 identity can be used to authorize the Phase 2 (GROUPKEY-PULL) request for a group key. Second, a new identity can be passed in the GROUPKEY-PULL request. The new identity could be specific to the group and use a certificate that is signed by the group owner to identify the holder as an authorized group member. The Proof-of-Possession payload validates that the holder possesses the secret key associated with the Phase 2 identity.

3.2. Messages​

The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a which is the "key" in the keyed hash used in the GROUPKEY-PULL HASH payloads. When using the Phase 1 defined in this document, SKEYID_a is derived according to [RFC2409]. As with the IKE HASH payload generation [RFC 2409 section 5.5], each GROUPKEY-PULL message hashes a uniquely defined set of values. Nonces permute the HASH and provide some protection against replay attacks. Replay protection is important to protect the GCKS from attacks that a key management server will attract.

The GROUPKEY-PULL uses nonces to guarantee "liveliness", or against replay of a recent GROUPKEY-PULL message. The replay attack is only useful in the context of the current Phase 1. If a GROUPKEY-PULL message is replayed based on a previous Phase 1, the HASH calculation will fail due to a wrong SKEYID_a. The message will fail processing before the nonce is ever evaluated. In order for either peer to get the benefit of the replay protection, it must postpone as much processing as possible until it receives the message in the protocol that proves the peer is live. For example, the Responder MUST NOT compute the shared Diffie-Hellman number (if KE payloads were included) or install the new SAs until it receives a message with Nr included properly in the HASH payload.

Nonces require an additional message in the protocol exchange to ensure that the GCKS does not add a group member until it proves liveliness. The GROUPKEY-PULL member-initiator expects to find its nonce, Ni, in the HASH of a returned message. And the GROUPKEY-PULL GCKS responder expects to see its nonce, Nr, in the HASH of a returned message before providing group-keying material as in the following exchange.

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]

Hashes are computed as follows:

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 is constructed as described in Section 5.7.

Note: Protected by the Phase 1 SA, encryption occurs after HDR

HDR is an ISAKMP header payload that uses the Phase 1 cookies and a message identifier (M-ID) as in IKE [RFC2409]. Note that nonces are included in the first two exchanges, with the GCKS returning only the SA policy payload before liveliness is proven. The HASH payloads [RFC2409] prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the exchange identified by message id, M-ID. Once liveliness is established, the last message completes the real processing of downloading the KD payload.

In addition to the Nonce and HASH payloads, the member-initiator identifies the group it wishes to join through the ISAKMP ID payload. The GCKS responder informs the member of the current value of the sequence number in the SEQ payload; the sequence number orders the GROUPKEY-PUSH datagrams (section 4); the member MUST check to see that the sequence number is greater than in the previous SEQ payload the member holds for the group (if it holds any) before installing any new SAs. The SEQ payload MUST be present if the SA payload contains an SA KEK attribute.

3.2.1. Perfect Forward Secrecy​

Perfect Forward Secrecy (PFS) for the GROUPKEY-PULL is achieved by the optional inclusion of the Key Exchange (KE) payload as described in RFC 2409. If the KE is used, there is a Diffie-Hellman exchange as part of the GROUPKEY-PULL. This ensures that the TEK or KEK cannot be recovered without access to the Diffie-Hellman key agreement.

3.2.2. ISAKMP Header Initialization​

The HDR fields for the GROUPKEY-PULL are initialized as follows.

  • The cookies are from Phase 1. Each GROUPKEY-PULL shares the Phase 1 cookies.
  • The message ID is randomly generated by the initiator and is used to match REQUEST and REPLY.
  • The next payload is HASH.
  • Exchange Type is GDOI_GROUPKEY_PULL (value 32).

3.3. Initiator Operations​

The GROUPKEY-PULL initiator MUST generate a nonce, Ni, and protect all messages with a Phase 1 SA. The Phase 1 SA provides encryption and data origin authentication for all GROUPKEY-PULL payloads.

3.4. Receiver Operations​

The GROUPKEY-PULL responder (GCKS) MUST verify all HASH payloads and then decrypt subsequent payloads. The GCKS MUST check that the nonces, Ni and Nr, in the HASH computations match the nonces sent in the cleartext payloads. If the HASH payload verification fails, the GCKS MUST reject the message and MAY audit the event.

The GCKS MUST validate the authorization of group members through policy outside the scope of this document.

Last updated on