in Index   Prev   Next

RFC 6407

The Group Domain of Interpretation

Pages: 64
Proposed Standard
Obsoletes:  3547
Part 1 of 3 – Pages 1 to 19
None   None   Next

Top   ToC   RFC6407 - Page 1
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 Notice 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 ( 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.
Top   ToC   RFC6407 - Page 2
   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 7 2. GDOI Phase 1 Protocol . . . . . . . . . . . . . . . . . . . . 8 2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 9 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Group Member Operations . . . . . . . . . . . . . . . . . 12 3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 13 3.5. Counter-Modes of Operation . . . . . . . . . . . . . . . . 14 4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 16 4.1. Use of Signature Keys . . . . . . . . . . . . . . . . . . 17 4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 17 4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 17 4.4. Group Member Operations . . . . . . . . . . . . . . . . . 18 5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 19 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20 5.2. Security Association Payload . . . . . . . . . . . . . . . 20 5.3. SA KEK Payload . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 27 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 44 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 45 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 47 7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 48
Top   ToC   RFC6407 - Page 3
     7.3.  GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 50
     7.4.  Forward and Backward Access Control  . . . . . . . . . . . 51
     7.5.  Derivation of Keying Material  . . . . . . . . . . . . . . 53
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 53
     8.1.  Additions to Current Registries  . . . . . . . . . . . . . 53
     8.2.  New Registries . . . . . . . . . . . . . . . . . . . . . . 54
     8.3.  Cleanup of Existing Registries . . . . . . . . . . . . . . 55
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 57
     10.2. Informative References . . . . . . . . . . . . . . . . . . 58
   Appendix A.  GDOI Applications . . . . . . . . . . . . . . . . . . 62
   Appendix B.  Significant Changes from RFC 3547 . . . . . . . . . . 62

1. 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.
Top   ToC   RFC6407 - Page 4
   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
Top   ToC   RFC6407 - Page 5
      |                                                              |
      |                    +--------------------+                    |
      |            +------>|     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].
Top   ToC   RFC6407 - Page 6

1.2. Terminology

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 members. Key Encrypting Key. The symmetric cipher key used to protect the GROUPKEY-PUSH message. 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).
Top   ToC   RFC6407 - Page 7

1.3. Acronyms and Abbreviations

The following acronyms and abbreviations are used throughout this document. 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 SID Sender-ID SPI Security Parameter Index SSIV Sender-Specific IV TEK Traffic Encryption Key
Top   ToC   RFC6407 - Page 8
   TLV   Type/Length/Value

   TV    Type/Value

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 Confidentiality 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.
Top   ToC   RFC6407 - Page 9


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.

3.1. Authorization

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.

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 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.
Top   ToC   RFC6407 - Page 10
   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 Exchange

   Figure 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)
Top   ToC   RFC6407 - Page 11
   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 session. The GDOI GROUPKEY-PULL exchange uses cookies according to ISAKMP [RFC2408].
Top   ToC   RFC6407 - Page 12
   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
Top   ToC   RFC6407 - Page 13
   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
   and ignored.

   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
   GROUPKEY-PUSH messages.

   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 group. 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 message. 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
Top   ToC   RFC6407 - Page 14
   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).
Top   ToC   RFC6407 - Page 15
   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.
Top   ToC   RFC6407 - Page 16
   Using the method above, at no time can two group members use the same
   IV values with the same Data-Security SA key.


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- Security SA. GM GCKS -- ---- <---- 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 Section 7.3.5. 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
Top   ToC   RFC6407 - Page 17
   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- PULL exchange.

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.
Top   ToC   RFC6407 - Page 18
   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 discarded. 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
Top   ToC   RFC6407 - Page 19
   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

(page 19 continued on part 2)

Next Section