4. GROUPKEY-PUSH Message
GDOI sends control information securely using group communications. Typically this will be using IP multicast distribution of a GROUPKEY-PUSH message but it can also be "pushed" using unicast delivery if IP multicast is not possible. The GROUPKEY-PUSH message replaces a Re-key SA KEK or KEK array, and/or creates a new Data-security SA.
Member GCKS or Delegate
------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
Note: Protected by the Re-key SA KEK; encryption occurs after HDR
HDR is defined below. The SEQ payload is defined in the Payloads section. The SA defines the policy (e.g., protection suite) and attributes (e.g., SPI) for a Re-key and/or Data-security SAs. The GCKS or delegate optionally provides a CERT payload for verification of the SIG. KD is the key download payload as described in the Payloads section.
The SIG payload is a signature of a hash of the entire message before encryption (including the header and excluding the SIG payload itself), prefixed with the string "rekey". The prefixed string ensures that the signature of the Rekey datagram cannot be used for any other purpose in the GDOI protocol.
If the SA defines an LKH KEK array or single KEK, KD contains a KEK or KEK array for a new Re-key SA, which has a new cookie pair. When the KD payload carries a new SA KEK attribute (section 5.3), a Re-key SA is replaced with a new SA having the same group identifier (ID specified in message 1 of section 3.2) and incrementing the same sequence counter, which is initialized in message 4 of section 3.2. If the SA defines an SA TEK payload, this informs the member that a new Data-security SA has been created, with keying material carried in KD (Section 5.5).
If the SA defines a large LKH KEK array (e.g., during group initialization and batched rekeying), parts of the array MAY be sent in different unique GROUPKEY-PUSH datagrams. However, each of the GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH datagram. This results in each datagram containing a sequence number and the policy in the SA payload, which corresponds to the KEK array portion sent in the KD payload.
4.1. Perfect Forward Secrecy (PFS)
The GROUPKEY-PUSH message is protected by the group KEK though in all cases, the GROUPKEY-PUSH message carries new key downloads, among other information. A freshly generated secret must protect the key download for the GROUPKEY-PUSH message to have PFS. This issue is for further study.
4.2. Forward and Backward Access Control
Through GROUPKEY-PUSH, the GDOI supports algorithms such as LKH that have the property of denying access to a new group key by a member removed from the group (forward access control) and to an old group key by a member added to the group (backward access control). An unrelated notion to PFS, "forward access control" and "backward access control" have been called "perfect forward security" and "perfect backward security" in the literature [RFC2627].
Group management algorithms providing forward and backward access control other than LKH have been proposed in the literature, including OFT [OFT] and Subset Difference [NNL]. These algorithms could be used with GDOI, but are not specified as a part of this document.
Support for group management algorithms is supported via the KEY_MANAGEMENT_ALGORITHM attribute which is sent in the SA_KEK payload. GDOI specifies one method by which LKH can be used for forward and backward access control. Other methods of using LKH, as well as other group management algorithms such as OFT or Subset Difference may be added to GDOI as part of a later document. Any such addition MUST be due to a Standards Action as defined in [RFC2434].
4.2.1. Forward Access Control Requirements
When group membership is altered using a group management algorithm, new SA_TEKs (and their associated keys) are usually also needed. New SAs and keys ensure that members who were denied access can no longer participate in the group.
If forward access control is a desired property of the group, new SA_TEKs and the associated key packets in the KD payload MUST NOT be included in a GROUPKEY-PUSH message which changes group membership. This is required because the SA_TEK policy and the associated key packets in the KD payload are not protected with the new KEK. A second GROUPKEY-PUSH message can deliver the new SA_TEKS and their associated keys because it will be protected with the new KEK, and thus will not be visible to the members who were denied access.
If forward access control policy for the group includes keeping group policy changes from members that are denied access to the group, then two sequential GROUPKEY-PUSH messages changing the group KEK MUST be sent by the GCKS. The first GROUPKEY-PUSH message creates a new KEK for the group. Group members, which are denied access, will not be able to access the new KEK, but will see the group policy since the GROUPKEY-PUSH message is protected under the current KEK. A subsequent GROUPKEY-PUSH message containing the changed group policy and again changing the KEK allows complete forward access control. A GROUPKEY-PUSH message MUST NOT change the policy without creating a new KEK.
If other methods of using LKH or other group management algorithms are added to GDOI, those methods MAY remove the above restrictions requiring multiple GROUPKEY-PUSH messages, providing those methods specify how forward access control policy is maintained within a single GROUPKEY-PUSH message.
4.3. Delegation of Key Management
GDOI supports delegation of GROUPKEY-PUSH datagrams through the delegation capabilities of the PKI. However, GDOI does not explicitly specify how the GCKS identifies delegates, but leaves this to the PKI that is used by a particular GDOI implementation.
4.4. Use of Signature Keys
The GCKS SHOULD NOT use the same key to sign the SIG payload in the GROUPKEY-PUSH message as was used for authorization in the GROUPKEY-PULL POP payload. If the same key must be used, a different hash function SHOULD be used as a base for the POP payload than is used as a base for the SIG payload.