Network Working Group
Internet Engineering Task Force (IETF)                           B. Weis
Internet-Draft
Request for Comments: 8263                                 Cisco Systems
Intended status:
Category: Standards Track                                      U. Mangla
Expires: March 12, 2018
ISSN: 2070-1721                                    Juniper Networks Inc.
                                                                 T. Karl
                                                        Deutsche Telekom
                                                           N. Maheshwari
                                                       September 8,
                                                           November 2017

               GDOI

          Group Domain of Interpretation (GDOI) GROUPKEY-PUSH
                        Acknowledgement Message
                      draft-weis-gdoi-rekey-ack-07

Abstract

   The Group Domain of Interpretation (GDOI) includes the ability for of a
   Group Controller/Key Server (GCKS) to provide a set of current Group
   Member (GM) devices with additional security associations (e.g., to
   rekey expiring security associations).  This memo adds the ability of
   a GCKS to request that the GM devices to return an acknowledgement of
   receipt of its rekey message, message and specifies the acknowledgement
   method.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 12, 2018.
   https://www.rfc-editor.org/info/rfc8263.

Copyright Notice

   Copyright (c) 2017 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)
   (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements notation Notation . . . . . . . . . . . . . . . . . .   3
     1.2.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   4   3
   2.  Acknowledgement Message Request . . . . . . . . . . . . . . .   4
     2.1.  REKEY_ACK_KEK_SHA256 Type . . . . . . . . . . . . . . . .   5
     2.2.  REKEY_ACK_LKH_SHA256 Type . . . . . . . . . . . . . . . .   5
     2.3.  REKEY_ACK_KEK_SHA512 Type . . . . . . . . . . . . . . . .   5
     2.4.  REKEY_ACK_LKH_SHA512 Type . . . . . . . . . . . . . . . .   6
   3.  GROUPKEY-PUSH Acknowledgement Message . . . . . . . . . . . .   6
     3.1.  HDR . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  HASH  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  SEQ . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.4.  ID  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Group Member Operations . . . . . . . . . . . . . . . . . . .   8
   5.  GCKS Operations . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Management Considerations . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.1.  Protection of the GROUPKEY-PUSH ACK . . . . . . . . . . .  11
     7.2.  Transmitting a GROUPKEY-PUSH ACK  . . . . . . . . . . . .  12
     7.3.  Receiving a GROUPKEY-PUSH ACK . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  References  . . . . . . . . . . . . . . . . . . . . . .  13
   10. References . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . .  14
     10.1.  Normative References . . . . . . . . . . . . .  14
   Acknowledgements  . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14 . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The Group Domain of Interpretation (GDOI) [RFC6407] is a group key
   management method by which a Group Controller/Key Server (GCKS)
   distributes security associations (i.e., cryptographic policy and
   keying material) to a set of Group Member (GM) devices.  The GDOI
   meets the requirement of the Multicast requirements set forth in [RFC4046] ("Multicast Security
   (MSEC) Group Key Management
   Architecture [RFC4046], and defines both Architecture"), including a Registration
   Protocol and a Rekey Protocol.  The GDOI describes the Rekey Protocol
   as a GROUPKEY-PUSH message.

   A GDOI GCKS uses a GROUPKEY-PUSH message (Section 4 of [RFC6407]) to
   alert group members GMs to updates in policy for the group, including new policy
   and keying material, replacement policy and keying material, and
   indications of deleted policy and keying material.  Usually  Usually, the GCKS
   does not require a notification that the group member GM actually received the
   policy.  However, in some cases it is beneficial for a GCKS to be
   told by each receiving GM that it received the rekey message and and, by implication
   implication, has reacted to the policy contained within.  For
   example, a GCKS policy can use the acknowledgements to determine
   which GMs are receiving the current group policy and which GMs are no
   longer participating in the group.

   This memo introduces a method by which a GM returns an acknowledgment
   message
   Acknowledgement Message to the GCKS.  Initially  Initially, a GCKS requests that
   a GM to acknowledge GROUPKEY-PUSH messages as part of a distributed
   group policy.  Then
   (shown  Then, as shown in Figure 1) 1, when the GCKS delivers a
   GROUPKEY-PUSH message, each GM that honors the GCKS request returns a
   GROUPKEY-PUSH Acknowledgement Message.  The rest of this memo
   describes this method in detail.

                GCKS                          GM1       GM2
                 |                             |         |
                 |                 +---------->|         |
                 |   GROUPKEY-PUSH |           |         |
                 |-----------------+           |         |
                 |                 |           |         |
                 |                 +-------------------->|
                 |                             |         |
                 |<----------------------------|         |
                 |      GROUPKEY-PUSH ACK      |         |
                 |                             |         |
                 |<--------------------------------------|
                 |      GROUPKEY-PUSH ACK      |         |

                    Figure 1: GROUPKEY-PUSH Rekey Event

   Implementation of the GROUPKEY-PUSH Acknowledgement Message is
   OPTIONAL.

1.1.  Requirements notation Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Acronyms and Abbreviations

   The following acronyms and abbreviations are used throughout this
   document.

   ACK   Acknowledgement Message

   D     Delete Payload

   GCKS  Group Controller/Key Server

   GDOI  Group Domain of Interpretation

   GM    Group Member

   HDR   Header Payload

   IV    Initialization Vector

   KD    Key Download Payload

   KDF   Key Derivation Function

   KEK   Key Encryption Key

   LKH   Logical Key Hierarchy

   MSEC  Multicast Security

   SA    Security Association

   SEQ   Sequence Number Payload

   SIG   Signature Payload

   SPI   Security Parameter Index

2.  Acknowledgement Message Request

   When a GM is ready to join a group, it contacts the GCKS with a
   GROUPKEY-PULL Registration Protocol.  When the GCKS has authenticated
   and verified that the GM is an authorized member of the group group, it
   downloads several sets of policy in a Security Association (SA)
   payload.  If the group includes the use of a GROUPKEY-PUSH Rekey
   Protocol, the SA payload includes an SA Key Encryption Key (KEK)
   payload (Section 5.3 of [RFC6407]).  When necessary necessary, the
   GROUPKEY-PUSH Rekey Protocol also contains an SA payload that
   includes the SA KEK policy.  The SA KEK policy indicates how the GM
   will be receiving and handling the GROUPKEY-PUSH Rekey Protocol.

   When the GCKS policy includes the use of the GROUPKEY-PUSH
   Acknowledgement Message, the GCKS reports this policy to the GM
   within the SA KEK policy.  The GCKS includes a new KEK Attribute attribute with
   the name KEK_ACK_REQUESTED (value TBD-1), (9), which indicates that the GM is
   requested to return a GROUPKEY-PUSH Acknowledgement Message.

   As part of the SA KEK policy, the GCKS specifies information on the
   keying material, material that is used to protect the GROUPKEY-PUSH Rekey
   Protocol (e.g., the presence of a KEK Management Algorithm). management algorithm).  Parts
   of
   these this information are used by a GM to derive the ack_key (defined
   in Section 3.2), which protects the GROUPKEY-PUSH Acknowledgement
   Message.  There are different types of Rekey Acknowledgement
   messages, which
   Messages; they share an identical message format but differ in the
   used
   keying material. material used.

   The following values of the KEK_ACK_REQUESTED attribute are defined
   in this memo.

2.1.  REKEY_ACK_KEK_SHA256 Type

   This type of Rekey ACK is used when the KEK KD Download Type
   (Section 5.6.2 of [RFC6407]) is part of the group policy.  The prf
   (defined in Section 3.2) is PRF-HMAC-SHA-256 [RFC4868].  The base_key
   (also defined in Section 3.2) is the KEK_ALGORITHM_KEY used to
   decrypt the GROUPKEY-PUSH message.  Note that for some algorithms the
   KEK_ALGORITHM_KEY will include an explicit Initialization Vector (IV)
   before the actual key (Section 5.6.2.1 of [RFC6407]), but it is not
   used in the definition of the base_key.

2.2.  REKEY_ACK_LKH_SHA256 Type

   This type of Rekey ACK can be used when the KEK_MANAGEMENT_ALGORITHM
   KEK attribute with a value representing the Logical Key Hierarchy
   (LKH) is part of the group policy (Section 5.3.1.1 of [RFC6407]).
   The prf is PRF-HMAC-SHA-256.  The base_key is the Key Data field
   value taken from the first LKH Key structure in an LKH_DOWNLOAD_ARRAY
   attribute (see Section 5.6.3.1 of [RFC6407]).  This is a secret
   symmetric key that the GCKS shares with the group member. GM.  Note that for some
   algorithms the LKH Key structure will include an explicit IV before
   the actual key (Section 5.6.3.1 of [RFC6407]), but it is not used in
   the definition of the base_key.

2.3.  REKEY_ACK_KEK_SHA512 Type

   This type of Rekey ACK is identical to the REKEY_ACK_KEK_SHA256 Type,
   except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]).

2.4.  REKEY_ACK_LKH_SHA512 Type

   This type of Rekey ACK is identical to the REKEY_ACK_LKH_SHA256 Type,
   except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]).

3.  GROUPKEY-PUSH Acknowledgement Message

   The GROUPKEY-PUSH message defined in [RFC6407] is reproduced in
   Figure 2.  The SA and Key Download (KD) payloads contain the actual
   policy and keying material being distributed to the GM.  The Sequence
   Number (SEQ) payload contains a sequence number that is used by the
   GM for replay protection.  This sequence number defines a unique
   rekey message delivered to that GM.  One or more Delete (D) payloads
   optionally specify the deletion of the existing group policy.  The
   Signature (SIG) payload includes a signature of a hash of the entire
   GROUPKEY-PUSH message (excepting the SIG payload octets) before it
   has been encrypted encrypted.

         GM                  GCKS
         --                  ----
                             <---- HDR*, SEQ, [D,] SA, KD, SIG

         * Protected by the Rekey SA KEK; encryption occurs after HDR

              Figure 2: GROUPKEY-PUSH from Message (from RFC 6407 6407)

   When the GM has received a KEK_ACK_REQUESTED attribute in an SA KEK
   and it chooses to respond, it returns the value of the Sequence
   Number taken from the GROUPKEY-PUSH message to the GCKS along with
   its identity.  This tuple alerts the GCKS that the GM has received
   the GROUPKEY-PUSH message and implemented the policy contained
   therein.  The GROUPKEY-PUSH Acknowledgement Message is shown in
   Figure 3.

                      GM                              GCKS
                      --                              ----
                         HDR, HASH, SEQ, ID   ---->

              Figure 3: GROUPKEY-PUSH Acknowledgement Message

   The IP header for the GROUPKEY-PUSH Acknowledgement Message is
   constructed as if it were a reply to the GROUPKEY-PUSH message.  That
   is, the Source Address source address of the GROUPKEY-PUSH message becomes the
   Destination Address
   destination address of the GROUPKEY-PUSH Acknowledgement Message Message, and
   the GM includes its own IP address as the Source Address source address of the
   GROUPKEY-PUSH Acknowledgement Message.  The Source source port in the
   GROUPKEY-PUSH message UDP header becomes the Destination destination port of the
   GROUPKEY-PUSH Acknowledgement Message UDP header, and the Destination destination
   port of the GROUPKEY-PUSH message UDP header becomes the Source source port
   of the GROUPKEY-PUSH Acknowledgement Message UDP header.

   The following sections describe the payloads in the GROUPKEY-PUSH
   Acknowledgement Message.

3.1.  HDR

   The message begins with a header as defined for the GDOI GROUPKEY-
   PUSH
   GROUPKEY-PUSH message in Section 4.1 4.2 of [RFC6407].  The fields in the
   HDR MUST be initialized as follows.  The Cookies cookies of a GROUPKEY-PUSH
   message act as a Security Parameter Index (SPI) and are copied to the
   Acknowledgement Message.  Next Payload  "Next Payload" identifies a Hash "Hash (HASH)"
   payload (value 8) [ISAKMP-NP].  Major Version is 1 and Minor Version
   is 0.  The Exchange Type has value 35 for the GDOI GROUPKEY-PUSH
   Acknowledgment
   Acknowledgement Message.  Flags are set to 0.  Message ID MUST be set
   to zero. 0.  Length is according to Section 4.1 4.2 of [RFC6407]). [RFC6407].

3.2.  HASH

   The HASH payload is the same one used in the GDOI GROUPKEY-PULL
   exchange defined in Section 3.2 of [RFC6407].  The hash data in the
   HASH payload is created as follows:

        HASH = prf(ack_key, SEQ | ID)

   where:

   o  prf  "prf" is specific to the KEK_ACK_REQUESTED value, value and is described
      as part of that description.

   o  "|" indicates concatenation.

   o  SEQ  "SEQ" and ID "ID" represent the bytes comprising the Sequence Number
      and Identification Payloads payloads.

   The ack_key is computed from a Key Derivation Function (KDF) that
   conforms to KDF in Feedback Mode feedback mode as defined in NIST SP800-108
   [SP800-108]
   [SP800-108], where the length of the derived keying material is the
   same as the output of the prf, there is no initialization vector, IV, and the optional
   counter is not used.  Note: When the derived ack_key is smaller than
   the prf block size (i.e., 512 bits for PRF-HMAC-SHA-
   256), PRF-HMAC-SHA-256), it is zero filled
   zero-filled to the right, as specified in Section 2.1.2 of [RFC4868].

        ack_key = prf(base_key, "GROUPKEY-PUSH ACK" | SPI | L)

   where:

   o  prf  "prf" is specific to the KEK_ACK_REQUESTED value, value and is described
      as part of that description.

   o  base_key  "base_key" is specific to the KEK_ACK_REQUESTED value, value and is
      described as part of that description.  If the base_key is smaller
      than the prf block size (i.e., 512 bits for PRF-HMAC-SHA-256),
      then it is zero filled zero-filled to the right, as specified in Section 2.1.2
      of [RFC4868].

   o  "|" indicates concatenation.

   o  "GROUPKEY-PUSH ACK" is a label encoded as a null terminated null-terminated ASCII
      string.

   o  SPI  "SPI" (per [RFC6407]) is the Initiator Cookie followed by the
      Responder Cookie taken from the GROUPKEY-PUSH message HDR, which
      describes the Context context of the key usage.

   o  L  "L" is a length field matching the number of bits in the ack_key.
      L MUST match the length of the base_key (i.e., 512 bits for PRF-
      HMAC-SHA-256).
      PRF-HMAC-SHA-256).  The value L is represented as two octets in
      network byte order (that is, most significant byte first).

3.3.  SEQ

   The Sequence Number Payload payload is defined in Section 5.7 of [RFC6407].
   The value in the GROUPKEY-PUSH SEQ payload is copied to the
   GROUPKEY-PUSH ACK SEQ payload.

3.4.  ID

   The Identification payload is used as defined in Section 5.1 of
   [RFC6407].  The ID payload contains an ID Type of ID_IPV4_ADDR,
   ID_IPV6_ADDR, or ID_OID as defined in [RFC8052] for GDOI exchanges [RFC8052]. exchanges.
   The Protocol ID and Port fields MUST be set to 0.  The address
   provided in the ID payload represents the IP address of the GM, GM and
   MUST match the source IP address used for the most recent
   GROUPKEY-PULL exchange.

4.  Group Member Operations

   When a GM receives an SA KEK payload (in a GROUPKEY-PULL exchange or
   GROUPKEY-PUSH message) including a KEK_ACK_REQUESTED attribute, it
   records in its group state some indication that it is expected to
   return a GROUPKEY-PUSH ACK message. ACK.  A GM recognizing the attribute MUST
   honor the KEK_ACK_REQUESTED attribute by returning
   Acknowledgments, Acknowledgements,
   because it can be expected that the GCKS is likely to take some
   policy-specific action regarding non-responsive unresponsive GMs, including ceasing
   to deliver GROUPKEY-PUSH messages to it.

   If a GM cannot respond with the requested type of Acknowledgement, it
   continues with protocol exchange and participates in the group.  In
   any case, if a GM stops receiving GROUPKEY-PUSH messages from a GCKS GCKS,
   it will re-register before existing security associations SAs expire, so omitting the
   sending of Acknowledgements should not be critical.

   When a GM receives a GROUPKEY-PUSH message that contains a
   KEK_ACK_REQUESTED attribute in the SA KEK payload, it processes the
   message according to RFC 6407.  When it concludes successful
   processing of the message, it formulates the GROUPKEY-PUSH ACK
   messages ACKs as
   described in Section 3 and delivers the message to the GCKS from
   which the GROUPKEY-PUSH message was received.  A GROUPKEY-
   PUSH GROUPKEY-PUSH ACK message is
   sent even if the GROUPKEY-PUSH message contains a Delete payload for
   the KEK used to protect the GROUPKEY-PUSH message.

5.  GCKS Operations

   When a GCKS policy includes requesting a GROUPKEY-PUSH ACK message from Group Members, GMs,
   it includes the KEK_ACK_REQUESTED attribute in the SA KEK payload.
   It does this each time the SA KEK is delivered, in both GROUPKEY-PULL
   exchanges and GROUPKEY-PUSH messages.  The value of the
   KEK_ACK_REQUESTED attribute will depend upon the type of SA
   KEK, KEK
   policy, as described in Section 2.

   When a GCKS receives a GROUPKEY-PUSH ACK message (identified by an Exchange type
   Type of GROUPKEY-PUSH-ACK), it first verifies that the group policy
   includes receiving GROUPKEY-PUSH ACK messages. ACKs.  If not, the message is
   discarded.  GCKS implementations SHOULD keep a record (e.g., a hash
   value) of recently received GROUPKEY-PUSH
   Acknowledgment messages Acknowledgement Messages
   and reject duplicate messages prior to performing cryptographic
   operations.  This enables an early discard of the replayed messages.

   If the message is expected, the GCKS validates the format of the
   message,
   message and verifies that the HASH has been properly constructed as
   described in Section 3.2.  If validation fails, the message is
   discarded.  The GCKS extracts the sequence number and identity of the
   GM from the SEQ and ID payloads payloads, respectively, and records the fact
   that the GM received the GROUPKEY-PUSH message represented by its
   serial
   sequence number.

6.  Management Considerations

   The GCKS manages both group policy and group membership as well as determining which GM devices
   are presently "live" members of a group. the group (i.e., members either
   sending or receiving messages).  Group membership policy includes a strategy to
   ensure that rekey messages with current group policy reach all live group members.
   GMs.  This is discussed briefly in Section 5.3 of the MSEC Group Key
   Management Architecture [RFC4046].  The
   GROUPKEY-PUSH Acknowledgement
   message Message specified in this memo provides
   the GCKS with an additional method to assess if a group member GM is live and has
   received the current group policy.  But it is possible for a rekey
   message or GROUPKEY-
   PUSH GROUPKEY-PUSH Acknowledgement message Message to be discarded in
   the network, which
   results resulting in a live GM appearing to appear be unresponsive.  Also
   Also, a GM might not be able to respond with an a GROUPKEY-PUSH ACK.  So ACK, so
   the GCKS should use caution in using a lack of Acknowledgment an Acknowledgement
   Message as the only factor in determining whether a GM is live.  In
   particular, a GCKS SHOULD NOT consider a GM to have left the group
   until it has received at least one ACK from the GM.

   Some management considerations for determining how a Group Member handle GM handles
   Acknowledgement messages is Messages are as follows:

   o  A GM MUST respond with Acknowledgement messages Messages when requested, as
      a GCKS can subsequently determine when a GM becomes unexpectedly
      non-responsive. becomes
      unresponsive.

   o  A GM receiving a GROUPKEY-PUSH message as a multicast message MAY
      introduce a jitter to the timing of its Acknowledgement message Message to
      help the GCKS better manage replies from group members. GMs.  A GM MUST NOT delay
      sending an Acknowledgment Acknowledgement Message for more than 5 seconds. a GCKS
      SHOULD NOT declare an Acknowledgment Acknowledgement Message as missing until it
      has waited at least 10 seconds.  Implementations SHOULD make these
      timers configurable.

   Some management considerations for determining how the GCKS handles
   Acknowledgement messages is Messages are as follows:

   o  A non-receipt  Non-receipt of an Acknowledgement Message is an indication that a
      GM is unable to respond.  A GCKS SHOULD wait at least several
      seconds before determining non-receipt, as GMs could add jitter to
      the response time before sending an acknowledgement. Acknowledgement Message.

   o  If the GCKS is aware that GMs are expected to respond, then a non-
      receipt
      non-receipt of an Acknowledgement Message SHOULD trigger a logging
      event.  The GCKS MAY be configured with such additional policy
      actions such as transmitting the GROUPKEY-PUSH message several times in
      a short period of time (as suggested in [RFC4046]), which mitigates a
      packet thereby
      mitigating loss of either the GROUPKEY-PUSH message or an
      Acknowledgement message. Message.  Another policy action could be to
      alerting alert
      GCKS administrators of GMs that do not return several consecutive acknowledgement messages
      Acknowledgement Messages or even removing unresponsive GMs from
      the group.  However, a GCKS with a policy of removing GMs from the
      group needs to be aware that a GM that has not responded will not
      receive a newer group policy until it initiates contact with the
      GCKS again.

   o  When a GROUPKEY-PUSH message includes a Delete payload for the KEK
      used to protect the GROUPKEY-PUSH message, the GCKS SHOULD NOT
      itself delete the KEK until it has given GMs the opportunity to
      acknowledge receipt of the GROUPKEY-PUSH message.  This could be
      several seconds, as GMs could add jitter to the response time
      before sending an acknowledgement. Acknowledgement Message.

   o  A GCKS SHOULD log failure events, such as receiving
      Acknowledgement messages Messages for a group in which the GCKS has not
      requested Acknowledgements, receiving malformed Acknowledgement, Acknowledgements,
      and Acknowledgements that fail validation.

7.  Security Considerations

   There are three areas of security considerations to consider: the
   protection of the GROUPKEY-PUSH ACK message, ACK, whether the GM should transmit a
   GROUPKEY-PUSH ACK, and whether a GCKS should accept a GROUPKEY-PUSH
   ACK.  These are addressed in the following subsections.

   The construction of the HASH defined in this memo uses PRF-HMAC-
   SHA-256
   PRF-HMAC-SHA-256 or PRF-HMAC-SHA-512.  The strength strengths of these PRFs
   PRF-HMAC-SHA-256 and PRF-HMAC-SHA-512 were unquestioned at the time
   this memo was developed.  When a HASH construction is necessary using a different prf,
   prf becomes necessary, a new KEK_ACK_REQUESTED value will be defined
   in a new specification.

7.1.  Protection of the GROUPKEY-PUSH ACK

   The GROUPKEY-PUSH ACK message is an ISAKMP [RFC2408] message. Internet Security Association and Key
   Management Protocol (ISAKMP) message as discussed in [RFC2408].
   (Note: RFC 2408 has been obsoleted by RFC 7296, but only RFC 2408
   applies in this context.)  Message authentication and Man-in-the-Middle Attack Protection is protection
   against man-in-the-middle attacks are provided by the inclusion of a
   HASH payload, which payload that includes the output of an HMAC computation over the
   bytes of the message.

   When

   Because the KEK is a group secret, when the value of REKEY_ACK_KEK is
   specified, because the KEK is a
   group secret impersonation of a victim GM by another authorized GM is
   possible.  However, security considerations of the regarding such an
   impersonation are limited to a false claim that a victim GM has
   received a GROUPKEY-
   PUSH GROUPKEY-PUSH when the victim GM has in fact not received
   it (e.g., because an active attacker has discarded the
   GROUPKEY-PUSH).  If a GCKS policy includes sending retransmissions of
   the GROUPKEY-PUSH message to that victim GM, then the victim GM might
   not receive replacement security
   associations. SAs.  However, this adds no does not introduce any
   additional threats over a use case where the GROUPKEY-PUSH ACK is not
   deployed and GROUPKEY-PUSH messages are withheld from a victim GM by
   an active attacker.  These threats can be mitigated by using a value
   of REKEY_ACK_LKH, due to the use of a secret pairwise key shared
   between the GCKS and an individual GM.

   Confidentiality is not provided for the GROUPKEY-PUSH ACK message. ACK.  The
   contents of the message can be observed by a passive attacker,
   which includes message, including the hash value, the sequence
   number of in from the GROUPKEY-PUSH message to which it is acknowledging
   receipt, and the identity of the GM. GM, can be observed by a passive
   attacker.  Observation of a hash value or set of hash values will not
   compromise the hash key.  The identity of the GM is also available to
   the passive attacker as the source IP address of the packet.  The  Note
   that the sequence number in the GROUPKEY-PUSH ACK does reveal the
   sequence number (previously not available to the attacker) that was
   included in the GROUPKEY-PUSH, which was previously not available
   to the attacker. GROUPKEY-PUSH message.  However, the attacker is
   assumed to not be in possession of the key used to encrypt the message,
   message and thus cannot create a spoofed GROUPKEY-PUSH message.
   Therefore, there is no
   direct value that the attacker derives does not derive any direct value from the knowledge of
   learning the sequence number.

7.2.  Transmitting a GROUPKEY-PUSH ACK

   A GM transmits an ACK only when the policy of the most recently
   received SA KEK includes a request by the GCKS for ACKs, and only the ACK
   is only returned after processing the GROUPKEY-PUSH message according
   to Section 4.4 of [RFC6407].  In other words, the form of the GROUPKEY-
   PUSH
   GROUPKEY-PUSH message will have been validated, replay protection
   completed, and the digital signature verified as being genuine.
   Therefore, the
   threats threat of a GM responding to a spoofed or resent
   GROUPKEY-PUSH message, and the possibility of the GM being used to
   propagate a Distributed Denial of Service (DDoS) attack on a GCKS GCKS,
   are mitigated.  For more information, see the security considerations of
   for a GROUPKEY-
   PUSH GROUPKEY-PUSH message as described in Section 7.3 of [RFC6407].

7.3.  Receiving a GROUPKEY-PUSH ACK

   A GCKS receiving ACK messages ACKs will follow the validation steps described in
   Section 5 before interpreting the contents of the message.  The GCKS
   will then be sure to operate only on messages that have been sent by
   an authorized GM.

   A GCKS SHOULD be prepared to receive GROUPKEY-PUSH ACK messages ACKs from each GM
   to which it was sent.  That is, it needs to ensure that it has
   sufficient resources (e.g., receive queue size) so that it does not
   unnecessarily drop ACK messages.  An ACKs.  A GCKS should be aware that a large number
   of replayed or invalid GROUPKEY-PUSH messages could be addressed to
   it.  However, this is no worse a threat than if it received a large
   number of other types of replayed or invalid GDOI or other messages
   containing a HASH payload.

   How a GCKS processes the serial sequence number and identity included in an
   ACK message is a matter of local policy and is outside the scope of this
   memo.

8.  IANA Considerations

   The following additions are have been made to the GDOI Payloads "Group Domain of
   Interpretation (GDOI) Payloads" [GDOI-REG] registry.

   A new attribute is has been added to the SA "SA KEK Payload Values - KEK
   Attributes
   Attributes" registry.  The ID Class name is KEK_ACK_REQUESTED with a
   value of TBD-1, 9 and is a Basic attribute.

   A new registry defining values for KEK_ACK_REQUESTED is needed, and
   these values KEK_ACK_REQUESTED, "SA KEK Payload
   Values - KEK_ACK_REQUESTED", has been added; the initial
   registrations are shown in the following table.  The terms Reserved,
   Unassigned,
   "Reserved", "Unassigned", and Private Use "Private Use" are to be applied as
   defined in [RFC8126].  The registration procedure is Specification
   Required.

                   Value            Type
                  -------           ----           --------------------
                     0              Reserved
                     1              REKEY_ACK_KEK_SHA256
                     2              REKEY_ACK_LKH_SHA256
                     3              REKEY_ACK_KEK_SHA512
                     4              REKEY_ACK_LKH_SHA512
                    5-128           Unassigned
                  129-255           Private Use

   A new registry describing ISAKMP Exchange Types for GDOI is the GDOI, "GDOI
   DOI Exchange Types", has been added to
   GDOI Payloads under the "Group Domain of
   Interpretation (GDOI) Payloads" registry [GDOI-REG].  This new
   registry defines DOI Specific Use values [ISAKMP-EXCH], which are
   Exchange type Type values used with the ISAKMP GDOI DOI.  Its name is "GDOI DOI Exchange Types".  The registration
   procedure is Specification Required.  The terms Known "Known Unregistered Use
   Use" and Unassigned "Unassigned" are to be applied as defined in [RFC8126].

             Value                      Phase        Reference
             ----                       -----
             ----------------------     ------       ---------
             GROUPKEY-PULL                32         RFC 6407
             GROUPKEY-PUSH                33         RFC 6407
             Known Unregistered Use       34
             GROUPKEY-PUSH-ACK            35         RFC XXXX 8263
             Unassigned                 36-239

   [Note to RFC Editor: Please replace XXXX with the number of the RFC
   resulting from this memo, and delete this note.]

9.  Acknowledgements

   Mike Hamada, Adrian Farrel, and Yaron Sheffer provided many useful
   technical and editorial comments and suggestions for improvement.

10.  References

10.1.

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868,
              DOI 10.17487/RFC4868, May 2007, <https://www.rfc-
              editor.org/info/rfc4868>.
              <https://www.rfc-editor.org/info/rfc4868>.

   [RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
              of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
              October 2011, <https://www.rfc-editor.org/info/rfc6407>.

   [RFC8052]  Weis, B., Seewald, M., and H. Falk, "Group Domain of
              Interpretation (GDOI) Protocol Support for IEC 62351
              Security Services", RFC 8052, DOI 10.17487/RFC8052, June
              2017, <https://www.rfc-editor.org/info/rfc8052>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

10.2.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [GDOI-REG]
              Internet Assigned Numbers Authority, "Group Domain of
              Interpretation (GDOI) Payload Type Values", IANA Registry,
              November 2016, <http://www.iana.org/assignments/gdoi-
              payloads/gdoi-payloads.xml>.
              <https://www.iana.org/assignments/gdoi-payloads/>.

   [ISAKMP-EXCH]
              Internet Assigned Numbers Authority, "Internet Key
              Exchange (IKE) Attributes Exchange Type Values",
              IANA Registry, May 2013, <http://www.iana.org/assignments/
              ipsec-registry/ipsec-registry.xhtml#ipsec-registry-17>.
              <https://www.iana.org/assignments/ipsec-registry/>.

   [ISAKMP-NP]
              Internet Assigned Numbers Authority, "Internet Key
              Exchange (IKE) Attributes Next Protocol Types",
              IANA Registry, May 2013, <http://www.iana.org/assignments/
              ipsec-registry/ipsec-registry.xhtml#ipsec-registry-21>.
              <https://www.iana.org/assignments/ipsec-registry/>.

   [RFC2408]  Maughan, D., Schertler, M., Schneider, M., and J. Turner,
              "Internet Security Association and Key Management Protocol
              (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998,
              <https://www.rfc-editor.org/info/rfc2408>.

   [RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
              "Multicast Security (MSEC) Group Key Management
              Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
              <https://www.rfc-editor.org/info/rfc4046>.

   [SP800-108]
              Chen, L., "Recommendation for Key Derivation Using
              Pseudorandom Functions", United States of America, Functions (Revised)", National Institute of
              Science and Technology, NIST Special Publication 800-108,
              DOI 10.6028/NIST.SP.800-108, October 2009,
              <http://dx.doi.org/10.6028/NIST.SP.800-108>.
              <http://nvlpubs.nist.gov/nistpubs/Legacy/SP/
              nistspecialpublication800-108.pdf>.

Acknowledgements

   Mike Hamada, Adrian Farrel, and Yaron Sheffer provided many useful
   technical and editorial comments and suggestions for improvement.

Authors' Addresses

   Brian Weis
   Cisco Systems
   170 W. Tasman Drive
   San Jose, California  95134-1706
   USA
   United States of America

   Phone: +1-408-526-4796
   Email: bew@cisco.com
   Umesh Mangla
   Juniper Networks Inc.
   1133 Innovation Way
   Sunnyvale, California  94089
   USA
   United States of America

   Phone: +1-408-936-1022
   Email: umangla@juniper.net

   Thomas Karl
   Deutsche Telekom
   Landgrabenweg 151
   Bonn  53227
   Germany

   Phone: +49 228 18138122 +49-228-18138122
   Email: thomas.karl@telekom.de

   Nilesh Maheshwari

   Email: nileshm@gmail.com