4.7. GCKS Operations

GCKS or its delegate may initiate a Rekey message for one of several reasons, e.g., the group membership has changed or keys are due to expire.

To begin the rekey datagram the GCKS builds an ISAKMP HDR with the correct cookie pair, and a SEQ payload that includes a sequence number which is one greater than the previous rekey datagram.

An SA payload is then added. This is identical in structure and meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there are changes to the KEK (in the case of a static KEK) or in group membership (in the case of LKH) an SA_KEK attribute is added to the SA. If there are one or more new TEKs then SA_TEK attributes are added to describe that policy.

A KD payload is then added. This is identical in structure and meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an SA_KEK attribute was included in the SA payload then corresponding KEK keys (or a KEK array) is included. TEK keys are sent for each SA_TEK attribute included in the SA payload.

A CERT payload is added if the initiator needs to provide its certificate.

In the penultimate step, the initiator hashes the string "rekey" followed by the key management message already formed. The hash is signed, placed in a SIG payload and added to the datagram.

Lastly, the payloads following the HDR are encrypted using the current KEK encryption key. The datagram can now be sent.