Internet Engineering Task Force (IETF) B. Weis
Request for Comments: 6407 S. Rowles
Obsoletes: 3547 Cisco Systems
Category: Standards Track T. Hardjono
ISSN: 2070-1721 MIT
October 2011 The Group Domain of Interpretation
This document describes the Group Domain of Interpretation (GDOI)
protocol specified in RFC 3547. The GDOI provides group key
management to support secure group communications according to the
architecture specified in RFC 4046. The GDOI manages group security
associations, which are used by IPsec and potentially other data
security protocols. This document replaces RFC 3547.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 507.4. Forward and Backward Access Control . . . . . . . . . . . 517.5. Derivation of Keying Material . . . . . . . . . . . . . . 538. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 538.1. Additions to Current Registries . . . . . . . . . . . . . 538.2. New Registries . . . . . . . . . . . . . . . . . . . . . . 548.3. Cleanup of Existing Registries . . . . . . . . . . . . . . 559. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5710. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5710.1. Normative References . . . . . . . . . . . . . . . . . . . 5710.2. Informative References . . . . . . . . . . . . . . . . . . 58Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 62Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 621. Introduction
Secure group and multicast applications require a method by which
each group member shares common security policy and keying material.
This document describes the Group Domain of Interpretation (GDOI),
which is an Internet Security Association and Key Management Protocol
(ISAMKP) [RFC2408] Domain of Interpretation (DOI), a group key
management system. The GDOI distributes security associations (SAs)
for IPsec Authentication Header (AH) [RFC4302] and Encapsulating
Security Payload (ESP) [RFC4303] protocols and potentially other data
security protocols used in group applications. The GDOI uses the
group key management model defined in [RFC4046], and described more
generally by "The Multicast Group Security Architecture" [RFC3740].
In this group key management model, the GDOI protocol participants
are a Group Controller/Key Server (GCKS) and a group member (GM). A
group member contacts ("registers with") a GCKS to join the group.
During the registration, mutual authentication and authorization are
achieved, after which the GCKS distributes current group policy and
keying material to the group member over an authenticated and
encrypted session. The GCKS may also initiate contact ("rekeys")
with group members to provide updates to group policy.
ISAKMP defines two "phases" of negotiation (Section 2.3 of
[RFC2408]). A Phase 1 security association provides mutual
authentication and authorization, and a security association that is
used by the protocol participants to execute a Phase 2 exchange.
This document incorporates (i.e., uses but does not redefine) the
Phase 1 security association definition from the Internet DOI
[RFC2407], [RFC2409]. Although RFCs 2407, 2408, and 2409 were
obsoleted by [RFC4306] (and subsequently [RFC5996]), they are used by
this document because the protocol definitions remain relevant for
ISAKMP protocols other than IKEv2.
The GDOI includes two new Phase 2 ISAKMP exchanges (protocols), as
well as necessary new payload definitions to the ISAKMP standard
(Section 2.1 of [RFC2408]). These two new protocols are:
1. The GROUPKEY-PULL registration protocol exchange. This exchange
uses "pull" behavior since the member initiates the retrieval of
these SAs from a GCKS. It is protected by an ISAKMP Phase 1
protocol, as described above. At the culmination of a GROUPKEY-
PULL exchange, an authorized group member has received and
installed a set of SAs that represent group policy, and it is
ready to participate in secure group communications.
2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is
a datagram initiated ("pushed") by the GCKS, usually delivered to
group members using a IP multicast address. The rekey protocol
is an ISAKMP protocol, where cryptographic policy and keying
material ("Rekey SA") are included in the group policy
distributed by the GCKS in the GROUPKEY-PULL exchange. At the
culmination of a GROUPKEY-PUSH exchange, the key server has sent
group policy to all authorized group members, allowing receiving
group members to participate in secure group communications. If
a group management method is included in group policy (as
described in Section 7.4), at the conclusion of the GROUPKEY-PUSH
exchange, some members of the group may have been de-authorized
and no longer able to participate in the secure group
| +--------------------+ |
| +------>| GDOI GCKS |<------+ |
| | +--------------------+ | |
| | | | |
| GROUPKEY-PULL | GROUPKEY-PULL |
| PROTOCOL | PROTOCOL |
| | | | |
| v GROUPKEY-PUSH v |
| +-----------------+ PROTOCOL +-----------------+ |
| | | | | | |
| | GDOI GM(s) |<-------+-------->| GDOI GM(S) | |
| | | | | |
| +-----------------+ +-----------------+ |
| | ^ |
| v | |
| +-Data Security Protocol (e.g., ESP)-+ |
Figure 1. Group Key Management Model
Although the GROUPKEY-PUSH protocol specified by this document can be
used to refresh the Rekey SA protecting the GROUPKEY-PUSH protocol,
the most common use of GROUPKEY-PUSH is to establish keying material
and policy for a data security protocol.
GDOI defines several payload types used to distribute policy and
keying material within the GROUPKEY-PULL and GROUPKEY-PUSH protocols:
Security Association (SA), SA KEK, SA TEK, Group Associated Policy
(GAP), Sequence Number (SEQ), and Key Download (KD). Format and
usage of these payloads are defined in later sections of this memo.
In summary, GDOI is a group security association management protocol:
all GDOI messages are used to create, maintain, or delete security
associations for a group. As described above, these security
associations protect one or more data security protocol SAs, a Rekey
SA, and/or other data shared by group members for multicast and
groups security applications.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The following key terms are used throughout this document.
Data-Security SA The security policy distributed by a GDOI GCKS
describing traffic that is expected to be protected by group
members. This document described the distribution of IPsec AH
and ESP Data-Security SAs.
Group Controller/Key Server A device that defines group policy and
distributes keys for that policy [RFC3740].
Group Member. An authorized member of a secure group, sending and/or
receiving IP packets related to the group.
GROUPKEY-PULL. A protocol used by a GDOI group member to request
group policy and keying material.
GROUPKEY-PUSH. A protocol used by a GDOI GCKS to distribute updates
of group policy and keying material to authorized group
Key Encrypting Key. The symmetric cipher key used to protect the
Logical Key Hierarchy. A group management method defined in Section
5.4 of [RFC2627].
Rekey SA. The security policy protecting a GROUPKEY-PUSH protocol.
SA Attribute Payload A payload that follows the Security Association
payload and that describes group security attributes associated
with the security association. SA Attribute payloads include
the SAK, SAT, and GAP payloads.
Security Parameter Index An arbitrary value that is used by a
receiver to identify a security association such as an IPsec
ESP Security Association or a Rekey SA.
Traffic Encryption Key. The symmetric cipher key used to protect a
data security protocol (e.g., IPsec ESP).
1.3. Acronyms and Abbreviations
The following acronyms and abbreviations are used throughout this
AH IP Authentication Header
ATD Activation Time Delay
DOI Domain of Interpretation
DTD Deactivation Time Delay
ESP IP Encapsulating Security Payload
GCKS Group Controller/Key Server
GDOI Group Domain of Interpretation
GAP Group Associated Policy Payload
GM Group Member
GSPD Group Security Policy Database
IV Initialization Vector
KD Key Download Payload
KEK Key Encryption Key
LKH Logical Key Hierarchy
SA Security Association
SAK SA KEK Payload
SEQ Sequence Number Payload
SAT SA TEK Payload
SPI Security Parameter Index
SSIV Sender-Specific IV
TEK Traffic Encryption Key
2. GDOI Phase 1 Protocol
The GDOI GROUPKEY-PULL exchange is a Phase 2 protocol that MUST be
protected by a Phase 1 protocol. The Phase 1 protocol can be any
protocol that provides for the following protections:
o Peer Authentication
o Message Integrity
The following sections describe one such Phase 1 protocol. Other
protocols which may be potential Phase 1 protocols are described in
Appendix A. However, the use of the protocols listed there are not
considered part of this document.
This document defines how the ISAKMP Phase 1 exchanges as defined in
[RFC2409] can be used a Phase 1 protocol for GDOI. The following
sections define characteristics of the ISAKMP Phase 1 protocols that
are unique for these exchanges when used for GDOI.
Section 7.1 describes how the ISAKMP Phase 1 protocols meet the
requirements of a GDOI Phase 1 protocol.
2.1. DOI value
The Phase 1 SA payload has a DOI value. That value MUST be the GDOI
DOI value as defined later in this document.
2.2. UDP port
IANA has assigned port 848 for the use of GDOI; this allows for an
implementation to use separate ISAKMP implementations to service GDOI
and the Internet Key Exchange Protocol (IKE) [RFC5996]. A GCKS
SHOULD listen on this port for GROUPKEY-PULL exchanges, and the GCKS
MAY use this port to distribute GROUPKEY-PUSH messages. An ISAKMP
Phase 1 exchange implementation supporting NAT traversal [RFC3947]
MAY move to port 4500 to process the GROUPKEY-PULL exchange.
3. GROUPKEY-PULL Exchange
The goal of the GROUPKEY-PULL exchange is to establish a Rekey 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.
It is important that a group member explicitly trust entities that it
expects to act as a GCKS for a particular group. When no
authorization is performed, it is possible for a rogue GDOI
participant to perpetrate a man-in-the-middle attack between a group
member and a GCKS [MP04]. A group member MUST specifically list each
authorized GCKS in its Group Peer Authorization Database (GPAD)
[RFC5374]. A group member MUST ensure that the Phase 1 identity of
the GCKS is an authorized GCKS.
It is important that a GCKS explicitly authorize group members before
providing them with group policy and keying material. A GCKS
implementation SHOULD have a method of authorizing group members
(e.g., by maintaining an authorization list). When the GCKS performs
authorization, it MUST use the Phase 1 identity to authorize the
GROUPKEY-PULL request for group policy and keying material.
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a,
which is the "key" in the keyed hash used in the ISAKMP HASH payloads
[RFC2408] included in GROUPKEY-PULL messages. When using the Phase 1
defined in this document, SKEYID_a is derived according to [RFC2409].
Each GROUPKEY-PULL message hashes a uniquely defined set of values
(described below) and includes the result in the HASH payload.
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 "liveness" as well as
against replay of a recent GROUPKEY-PULL message. The replay attack
is only possible 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 GCKS MUST NOT adjust its internal state (e.g., keeping a record
of the GM) until it receives a message with Nr included properly in
the HASH payload. This requirement ensures that replays of GDOI
messages will not cause the GCKS to change the state of the group
until it has confirmation that the initiating group member is live.
Group Member GCKS
(1) HDR*, HASH(1), Ni, ID -->
(2) <-- HDR*, HASH(2), Nr, SA
(3) HDR*, HASH(3) [,GAP] -->
(4) <-- HDR*, HASH(4), [SEQ,] KD
* Protected by the Phase 1 SA; encryption occurs after HDR
Figure 2. GROUPKEY-PULL ExchangeFigure 2 demonstrates the four messages that are part of a GROUPKEY-
PULL exchange. HDR is an ISAKMP header payload that uses the Phase 1
cookies and a message identifier (M-ID) as in ISAKMP. Following each
HDR is a set of payloads conveying requests (messages 1 and 3
originated by the group member), or group policy and/or keying
material (messages 2 and 4 originated by the GCKS).
Hashes are computed in the manner described within [RFC2409]. The
HASH computation for each message is unique; it is shown in Figure 2
and below as HASH(n) where (n) represents the GROUPKEY-PULL message
number. Each HASH calculation is a pseudo-random function ("prf")
over the message ID (M-ID) from the ISAKMP header concatenated with
the entire message that follows the hash including all payload
headers, but excluding any padding added for encryption. The GM
expects to find its nonce, Ni, in the HASH of a returned message, and
the GCKS expects to see its nonce, Nr, in the HASH of a returned
message. HASH(2), HASH(3), and HASH(4) also include nonce values
previously passed in the protocol (i.e., Ni or Nr minus the payload
header). The nonce passed in Ni is represented as Ni_b, and the
nonce passed in Nr is represented as Nr_b. The HASH payloads prove
that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the
exchange identified by message ID, M-ID.
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 [ | GAP ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ ] | KD)
In addition to the Nonce and HASH payloads, the GM identifies the
group it wishes to join through the ISAKMP ID payload.
The GCKS informs the member of the cryptographic policies of the
group in the SA payload, which describes the DOI, KEK, and/or TEK
keying material, authentication transforms, and other group policy.
Each SPI is also determined by the GCKS and downloaded in the SA
payload chain (see Section 5.2). The SA KEK attribute contains the
ISAKMP cookie pair for the Rekey SA, which is not negotiated but
downloaded. Each SA TEK attribute contains a SPI as defined in
Section 5.5 of this document.
After receiving and parsing the SA payload, the GM responds with an
acknowledgement message proving its liveness. It optionally includes
a GAP payload requesting resources.
The GCKS informs the GM of the value of the sequence number in the
SEQ payload. This sequence number provides anti-replay state
associated with a KEK, and its knowledge ensures that the GM will not
accept GROUPKEY-PUSH messages sent prior to the GM joining the group.
The SEQ payload has no other use and is omitted from the GROUPKEY-
PULL exchange when a KEK attribute is not included in the SA payload.
When a SEQ payload is included in the GROUPKEY-PULL exchange, it
includes the most recently used sequence number for the group. At
the conclusion of a GROUPKEY-PULL exchange, the initiating group
member MUST NOT accept any rekey message with both the KEK attribute
SPI value and a sequence number less than or equal to the one
received during the GROUPKEY-PULL exchange. When the first group
member initiates a GROUPKEY-PULL exchange, the GCKS provides a
Sequence Number of zero, since no GROUPKEY-PUSH messages have yet
been sent. Note the sequence number increments only with GROUPKEY-
PUSH messages. The GROUPKEY-PULL exchange distributes the current
sequence number to the group member. The sequence number resets to a
value of one with the usage of a new KEK attribute. Thus, the first
packet sent for a given Rekey SA will have a Sequence Number of 1.
The sequence number increments with each successive rekey.
The GCKS always returns a KD payload containing keying material to
the GM. If a Rekey SA is defined in the SA payload, then KD will
contain the KEK; if one or more Data-Security SAs are defined in the
SA payload, KD will contain the TEKs.
3.2.1. ISAKMP Header Initialization
Cookies are used in the ISAKMP header to identify a particular GDOI
Next Payload identifies an ISAKMP or GDOI payload (see Section 5).
Major Version is 1 and Minor Version is 0 according to ISAKMP
(Section 3.1 of [RFC2408]).
The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange.
Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of
[RFC2408]). The Commit flag is not useful because there is no
synchronization between the GROUPKEY-PULL exchange and the data
traffic protected by the policy distributed by the GROUPKEY-PULL
3.3. Group Member Operations
Before a GM contacts the GCKS, it needs to determine the group
identifier and acceptable Phase 1 policy via an out-of-band method.
Phase 1 is initiated using the GDOI DOI in the SA payload. Once
Phase 1 is complete, the GM state machine moves to the GDOI protocol.
To construct the first GDOI message, the GM chooses Ni, creates a
nonce payload, builds an identity payload including the group
identifier, and generates HASH(1).
Upon receipt of the second GDOI message, the GM validates HASH(2),
extracts the nonce Nr, and interprets the SA payload (including its
SA Attribute payloads) . The SA payload contains policy describing
the security protocol and cryptographic protocols used by the group.
This policy describes the Rekey SA (if present), Data-Security SAs,
and other group policy. If the policy in the SA payload is
acceptable to the GM, it continues the protocol. Otherwise, the GM
SHOULD tear down the Phase 1 session after notifying the GCKS with an
ISAKMP Informational Exchange containing a Delete payload.
When constructing the third GDOI message, it first reviews each Data-
Security SA given to it. If any describe the use of a counter mode
cipher, the GM determines whether it requires more than one Sender-ID
(SID) (see Section 3.5). If so, it requests the required number of
Sender-IDs for its exclusive use within the counter mode nonce as
described in Section 5.4 of this document. The GM then completes
construction of the third GDOI message by creating HASH(3).
Upon receipt of the fourth GDOI message, the GM validates HASH(4).
If the SEQ payload is present, the sequence number included in the
SEQ payload asserts the lowest acceptable sequence number present in
a future GROUPKEY-PUSH message. But if the KEK associated with this
sequence number had been previously installed, due to the
asynchronous processing of GROUPKEY-PULL and GROUPKEY-PUSH messages,
this sequence number may be lower than the sequence number contained
in the most recently received GROUPKEY-PUSH message. In this case,
the sequence number value in the SEQ payload MUST be considered stale
The GM interprets the KD key packets, where each key packet includes
the keying material for SAs distributed in the SA payload. Keying
material is matched by comparing the SPI in each key packet to SPI
values previously sent in the SA payloads. Once TEKs and policy are
matched, the GM provides them to the data security subsystem, and it
is ready to send or receive packets matching the TEK policy. If this
group has a KEK, the KEK policy and keys are marked as ready for use,
and the GM knows to expect a sequence number not less than the one
distributed in the SEQ payload. The GM is now ready to receive
If the KD payload included an LKH array of keys, the GM takes the
last key in the array as the group KEK. The array is then stored
without further processing.
3.4. GCKS Operations
The GCKS passively listens for incoming requests from group members.
The Phase 1 authenticates the group member and sets up the secure
session with them.
Upon receipt of the first GDOI message, the GCKS validates HASH(1)
and extracts the Ni and group identifier in the ID payload. It
verifies that its database contains the group information for the
group identifier and that the GM is authorized to participate in the
The GCKS constructs the second GDOI message, including a nonce Nr,
and the policy for the group in an SA payload, followed by SA
Attribute payloads (i.e, SA KEK, GAP, and/or SA TEK payloads)
according to the GCKS policy. (See Section 5.2.1 for details on how
the GCKS chooses which payloads to send.)
Upon receipt of the third GDOI message, the GCKS validates HASH(3).
If the message includes a GAP payload, it caches the requests
included in that payload for the use of constructing the fourth GDOI
The GCKS constructs the fourth GDOI message, including the SEQ
payload (if the GCKS sends rekey messages), and the KD payload
containing keys corresponding to policy previously sent in the SA TEK
and SA KEK payloads. If a group management algorithm is defined as
part of group policy, the GCKS will first insert the group member
into the group management structure (e.g., a leaf in the LKH tree),
and then create an LKH array of keys and include it in the KD
payload. The first key in the array is associated with the group
member leaf node, followed by each LKH node above it in the tree,
culminating with the root node (which is also the KEK). If one or
more Data-Security SAs distributed in the SA payload included a
counter mode of operation, the GCKS includes at least one SID value
in the KD payload, and possibly more depending on a request received
in the third GDOI message.
3.5. Counter-Modes of Operation
Several new counter-based modes of operation have been specified for
ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309],
AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These
counter-based modes require that no two senders in the group ever
send a packet with the same Initialization Vector (IV) using the same
cipher key and mode. This requirement is met in GDOI when the
following requirements are met:
o The GCKS distributes a unique key for each Data-Security SA.
o The GCKS uses the method described in [RFC6054], which assigns
each sender a portion of the IV space by provisioning each sender
with one or more unique SID values.
When at least one Data-Security SA included in the group policy
includes a counter-mode, the GCKS automatically allocates and
distributes one SID to each group member acting in the role of sender
on the Data-Security SA. The SID value is used exclusively by the
group member to which it was allocated. The group member uses the
same SID for each Data-Security SA specifying the use of a counter-
based mode of operation. A GCKS MUST distribute unique keys for each
Data-Security SA including a counter-based mode of operation in order
to maintain a unique key and nonce usage.
When a group member receives a Data-Security SA in a SA TEK payload
for which it is a sender, it can choose to request one or more SID
values. Requesting a value of 1 is not necessary since the GCKS will
automatically allocate exactly one to the sending group member. A
group member MUST request as many SIDs matching the number of
encryption modules in which it will be installing the TEKs in the
outbound direction. Alternatively, a group member MAY request more
than one SID and use them serially. This could be useful when it is
anticipated that the group member will exhaust their range of Data-
Security SA nonces using a single SID too quickly (e.g., before the
time-based policy in the TEK expires).
When group policy includes a counter-based mode of operation, a GCKS
SHOULD use the following method to allocate SID values, which ensures
that each SID will be allocated to just one group member.
1. A GCKS maintains a SID-counter, which records which SIDs have
been allocated. SIDs are allocated sequentially, with the first
SID allocated to be zero.
2. Each time a SID is allocated, the current value of the counter is
saved and allocated to the group member. The SID-counter is then
incremented in preparation for the next allocation.
3. When the GCKS distributes a Data-Security SA specifying a
counter-based mode of operation, and a group member is a sender,
a group member may request a count of SIDs in a GAP payload.
When the GCKS receives this request, it increments the SID-
counter once for each requested SID, and distributes each SID
value to the group member.
4. A GCKS allocates new SID values for each GROUPKEY-PULL exchange
originated by a sender, regardless of whether a group member had
previously contacted the GCKS. In this way, the GCKS does not
have a requirement of maintaining a record of which SID values it
had previously allocated to each group member. More importantly,
since the GCKS cannot reliably detect whether the group member
had sent data on the current group Data-Security SAs, it does not
know which Data-Security counter-mode nonce values a group member
has used. By distributing new SID values, the key server ensures
that each time a conforming group member installs a Data-Security
SA it will use a unique set of counter-based mode nonces.
5. When the SID-counter maintained by the GCKS reaches its final SID
value, no more SID values can be distributed. Before
distributing any new SID values, the GCKS MUST delete the Data-
Security SAs for the group, followed by creation of new Data-
Security SAs, and resetting the SID-counter to its initial value.
6. The GCKS SHOULD send a GROUPKEY-PUSH message deleting all Data-
Security SAs and the Rekey SA for the group. This will result in
the group members initiating a new GROUPKEY-PULL exchange, in
which they will receive both new SID values and new Data-Security
SAs. The new SID values can safely be used because they are only
used with the new Data-Security SAs. Note that deletion of the
Rekey SA is necessary to ensure that group members receiving a
GROUPKEY-PUSH exchange before the re-register do not
inadvertently use their old SIDs with the new Data-Security SAs.
Using the method above, at no time can two group members use the same
IV values with the same Data-Security SA key.
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 Rekey SA KEK or KEK array, and/or it creates a new Data-
<---- HDR*, SEQ, [D,] SA, KD, SIG
* Protected by the Rekey SA KEK; encryption occurs after HDR
Figure 3. GROUPKEY-PUSH Message
HDR is defined below. The SEQ payload is defined in Section 5
("Payloads"). One or more D (Delete) payloads (further described in
Section 5.9) optionally specify the deletion of existing group
policy. The SA defines the group policy for replacement Rekey SA
and/or Data-Security SAs as described in Section 5, with the KD
providing keying material for those SAs.
The SIG payload includes a signature of a hash of the entire
GROUPKEY-PUSH message (excepting the SIG payload octets) before it
has been encrypted. The HASH is taken over the string 'rekey', the
GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG
payload. The prefixed string ensures that the signature of the Rekey
datagram cannot be used for any other purpose in the GDOI protocol.
The SIG payload is created using the signature of the above hash,
with the receiver verifying the signature using a public key
retrieved in a previous GDOI exchange. The current KEK (also
previously distributed in a GROUPKEY-PULL exchange or GROUPKEY-PUSH
message) encrypts all the payloads following the GROUPKEY-PUSH HDR.
Note: The rationale for this order of operations is given in
If the SA defines the use of a single KEK or an LKH KEK array, KD
MUST contain a corresponding KEK or KEK array for a new Rekey SA,
which has a new cookie pair. When the KD payload carries a new SA
KEK attribute (Section 5.3), a Rekey 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. Note the first packet for
the given Rekey SA encrypted with the new KEK attribute will have a
Sequence number of 1. 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.6).
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. Use of Signature Keys
A signing key should not be used in more than one context (e.g., used
for host authentication and also for message authentication). Thus,
the GCKS SHOULD NOT use the same key to sign the SIG payload in the
GROUPKEY-PUSH message as was used for authentication in the GROUPKEY-
4.2. ISAKMP Header Initialization
Unlike ISAKMP, the cookie pair is completely determined by the GCKS.
The cookie pair in the GDOI ISAKMP header identifies the Rekey SA to
differentiate the secure groups managed by a GCKS. Thus, GDOI uses
the cookie fields as an SPI.
Next Payload identifies an ISAKMP or GDOI payload (see Section 5).
Major Version is 1 and Minor Version is 0 according to ISAKMP
(Section 3.1 of [RFC2408]).
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message.
Flags MUST have the Encryption bit set according to Section 3.1 of
[RFC2408]. All other bits MUST be set to zero.
Message ID MUST be set to zero.
Length is according to ISAKMP (Section 3.1 of [RFC2408]).
4.3. GCKS Operations
GCKS 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 that is 1 greater than the previous rekey datagram. If the
message is using the new KEK attribute for the first time, the SEQ is
reset to 1 in this message.
An SA payload is then added. This is identical in structure and
meaning to an SA payload sent in a GROUPKEY-PULL exchange. If there
are changes to the KEK (including due to group members being
excluded, 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
KEKs (or a KEK update array) are included. A KEK update array is
created by first determining which group members have been excluded,
generating new keys as necessary, and then distributing LKH update
arrays sufficient to provide the new KEK to remaining group members
(see Section 5.4.1 of [RFC2627] for details). TEKs are also sent for
each SA_TEK attribute included in the SA payload.
In the penultimate step, the GCKS creates the SIG payload and adds it
to the datagram.
Lastly, the payloads following the HDR are encrypted using the
current KEK. The datagram can now be sent.
4.4. Group Member Operations
A group member receiving the GROUPKEY-PUSH datagram matches the
cookie pair in the ISAKMP HDR to an existing SA. The message is
decrypted, and the form of the datagram is validated. This weeds out
obvious ill-formed messages (which may be sent as part of a denial-
of-service attack on the group).
The sequence number in the SEQ payload is validated to ensure that it
is greater than the previously received sequence number. The SIG
payload is then validated. If the signature fails, the message is
The SA and KD payloads are processed, which results in a new GDOI
Rekey SA (if the SA payload included an SA_KEK attribute) and/or new
Data-Security SAs being added to the system. If the KD payload
includes an LKH update array, the group member compares the LKH ID in
each key update packet to the LKH IDs that it holds. If it finds a
match, it decrypts the key using the key prior to it in the key array
and stores the new key in the LKH key array that it holds. The final
decryption yields the new group KEK.
If the SA payload includes one or more Data-Security SAs including a
counter-mode of operation and if the receiving group member is a
sender for that SA, the group member uses its current SID value with
the Data-Security SAs to create counter-mode nonces. If it is a
sender and does not hold a current SID value, it MUST NOT install the
Data-Security SAs. It MAY initiate a GROUPKEY-PULL exchange to the
GCKS in order to obtain a SID value (along with current group