tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6407

Proposed STD
Pages: 64
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: MSEC

The Group Domain of Interpretation

Part 1 of 3, p. 1 to 19
None       Next RFC Part

Obsoletes:    3547

Top       ToC       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.

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       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       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       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",
   document are to be interpreted as described in [RFC2119].

Top      ToC       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

   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       Page 7 
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

   SID   Sender-ID

   SPI   Security Parameter Index

   SSIV  Sender-Specific IV

   TEK   Traffic Encryption Key

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

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       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       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       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       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

   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

Top      ToC       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       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       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       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       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

   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       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 RFC Part