doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc8263.txt b/doc/rfc/rfc8263.txt
new file mode 100644
index 0000000..219aad1
--- /dev/null
+++ b/doc/rfc/rfc8263.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           B. Weis
+Request for Comments: 8263                                 Cisco Systems
+Category: Standards Track                                      U. Mangla
+ISSN: 2070-1721                                    Juniper Networks Inc.
+                                                                 T. Karl
+                                                        Deutsche Telekom
+                                                           N. Maheshwari
+                                                           November 2017
+
+
+          Group Domain of Interpretation (GDOI) GROUPKEY-PUSH
+                        Acknowledgement Message
+
+Abstract
+
+   The Group Domain of Interpretation (GDOI) includes the ability 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 return an acknowledgement of
+   receipt of its rekey message and specifies the acknowledgement
+   method.
+
+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 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8263.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 1]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+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
+   (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 ....................................................3
+      1.1. Requirements Notation ......................................4
+      1.2. Acronyms and Abbreviations .................................4
+   2. Acknowledgement Message Request .................................5
+      2.1. REKEY_ACK_KEK_SHA256 Type ..................................5
+      2.2. REKEY_ACK_LKH_SHA256 Type ..................................6
+      2.3. REKEY_ACK_KEK_SHA512 Type ..................................6
+      2.4. REKEY_ACK_LKH_SHA512 Type ..................................6
+   3. GROUPKEY-PUSH Acknowledgement Message ...........................6
+      3.1. HDR ........................................................7
+      3.2. HASH .......................................................8
+      3.3. SEQ ........................................................9
+      3.4. ID .........................................................9
+   4. Group Member Operations .........................................9
+   5. GCKS Operations ................................................10
+   6. Management Considerations ......................................10
+   7. Security Considerations ........................................12
+      7.1. Protection of the GROUPKEY-PUSH ACK .......................12
+      7.2. Transmitting a GROUPKEY-PUSH ACK ..........................13
+      7.3. Receiving a GROUPKEY-PUSH ACK .............................13
+   8. IANA Considerations ............................................14
+   9. References .....................................................15
+      9.1. Normative References ......................................15
+      9.2. Informative References ....................................16
+   Acknowledgements ..................................................17
+   Authors' Addresses ................................................17
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 2]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+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 requirements set forth in [RFC4046] ("Multicast Security
+   (MSEC) Group Key Management 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 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, the GCKS
+   does not require a notification that the 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, by
+   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
+   Acknowledgement Message to the GCKS.  Initially, a GCKS requests that
+   a GM acknowledge GROUPKEY-PUSH messages as part of a distributed
+   group policy.  Then, as shown in Figure 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
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 3]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+   Implementation of the GROUPKEY-PUSH Acknowledgement Message is
+   OPTIONAL.
+
+1.1.  Requirements 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
+   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
+
+   GCKS  Group Controller/Key Server
+
+   GDOI  Group Domain of Interpretation
+
+   GM    Group Member
+
+   HDR   Header
+
+   HMAC  Hashed Message Authentication Code
+
+   IV    Initialization Vector
+
+   KD    Key Download
+
+   KDF   Key Derivation Function
+
+   KEK   Key Encryption Key
+
+   LKH   Logical Key Hierarchy
+
+   MSEC  Multicast Security
+
+   PRF   Pseudorandom Function
+
+   SA    Security Association
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 4]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+   SEQ   Sequence Number
+
+   SIG   Signature
+
+   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, 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, 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 with
+   the name KEK_ACK_REQUESTED (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 that is used to protect the GROUPKEY-PUSH Rekey
+   Protocol (e.g., the presence of a KEK management algorithm).  Parts
+   of 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; they share an identical message format but differ in the
+   keying 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 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.
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 5]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+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 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.
+
+         GM                  GCKS
+         --                  ----
+                             <---- HDR*, SEQ, [D,] SA, KD, SIG
+
+         * Protected by the Rekey SA KEK; encryption occurs after HDR
+
+              Figure 2: GROUPKEY-PUSH Message (from RFC 6407)
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 6]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+   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 of the GROUPKEY-PUSH message becomes the
+   destination address of the GROUPKEY-PUSH Acknowledgement Message, and
+   the GM includes its own IP address as the source address of the
+   GROUPKEY-PUSH Acknowledgement Message.  The source port in the
+   GROUPKEY-PUSH message UDP header becomes the destination port of the
+   GROUPKEY-PUSH Acknowledgement Message UDP header, and the destination
+   port of the GROUPKEY-PUSH message UDP header becomes the 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 message in Section 4.2 of [RFC6407].  The fields in the
+   HDR MUST be initialized as follows.  The cookies of a GROUPKEY-PUSH
+   message act as a Security Parameter Index (SPI) and are copied to the
+   Acknowledgement Message.  "Next Payload" identifies a "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
+   Acknowledgement Message.  Flags are set to 0.  Message ID MUST be set
+   to 0.  Length is according to Section 4.2 of [RFC6407].
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 7]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+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" is specific to the KEK_ACK_REQUESTED value and is described
+      as part of that description.
+
+   o  "|" indicates concatenation.
+
+   o  "SEQ" and "ID" represent the bytes comprising the Sequence Number
+      and Identification payloads.
+
+   The ack_key is computed from a Key Derivation Function (KDF) that
+   conforms to KDF in feedback mode as defined in NIST SP800-108
+   [SP800-108], where the length of the derived keying material is the
+   same as the output of the prf, there is no 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), it is
+   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" is specific to the KEK_ACK_REQUESTED value and is described
+      as part of that description.
+
+   o  "base_key" is specific to the KEK_ACK_REQUESTED 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 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 ASCII
+      string.
+
+   o  "SPI" (per [RFC6407]) is the Initiator Cookie followed by the
+      Responder Cookie taken from the GROUPKEY-PUSH message HDR, which
+      describes the context of the key usage.
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 8]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+   o  "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).  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 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.
+   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 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.  A GM recognizing the attribute MUST
+   honor the KEK_ACK_REQUESTED attribute by returning Acknowledgements,
+   because it can be expected that the GCKS is likely to take some
+   policy-specific action regarding 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,
+   it will re-register before existing 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 ACKs as
+   described in Section 3 and delivers the message to the GCKS from
+   which the GROUPKEY-PUSH message was received.  A GROUPKEY-PUSH ACK is
+   sent even if the GROUPKEY-PUSH message contains a Delete payload for
+   the KEK used to protect the GROUPKEY-PUSH message.
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 9]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+5.  GCKS Operations
+
+   When a GCKS policy includes requesting a GROUPKEY-PUSH ACK from 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
+   policy, as described in Section 2.
+
+   When a GCKS receives a GROUPKEY-PUSH ACK (identified by an Exchange
+   Type of GROUPKEY-PUSH-ACK), it first verifies that the group policy
+   includes receiving GROUPKEY-PUSH ACKs.  If not, the message is
+   discarded.  GCKS implementations SHOULD keep a record (e.g., a hash
+   value) of recently received GROUPKEY-PUSH 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 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, respectively, and records the fact
+   that the GM received the GROUPKEY-PUSH message represented by its
+   sequence number.
+
+6.  Management Considerations
+
+   The GCKS manages group policy as well as determining which GM devices
+   are presently "live" members of the group (i.e., members either
+   sending or receiving messages).  Group policy includes a strategy to
+   ensure that rekey messages with current group policy reach all live
+   GMs.  This is discussed briefly in Section 5.3 of [RFC4046].  The
+   GROUPKEY-PUSH Acknowledgement Message specified in this memo provides
+   the GCKS with an additional method to assess if a GM is live and has
+   received the current group policy.  But it is possible for a rekey
+   message or GROUPKEY-PUSH Acknowledgement Message to be discarded in
+   the network, resulting in a live GM appearing to be unresponsive.
+   Also, a GM might not be able to respond with a GROUPKEY-PUSH ACK, so
+   the GCKS should use caution in using a lack of 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.
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 10]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+   Some management considerations for determining how a GM handles
+   Acknowledgement Messages are as follows:
+
+   o  A GM MUST respond with Acknowledgement Messages when requested, as
+      a GCKS can subsequently determine when a GM unexpectedly becomes
+      unresponsive.
+
+   o  A GM receiving a GROUPKEY-PUSH message as a multicast message MAY
+      introduce jitter to the timing of its Acknowledgement Message to
+      help the GCKS better manage replies from GMs.  A GM MUST NOT delay
+      sending an Acknowledgement Message for more than 5 seconds. a GCKS
+      SHOULD NOT declare an 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 are as follows:
+
+   o  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 Message.
+
+   o  If the GCKS is aware that GMs are expected to respond, then
+      non-receipt of an Acknowledgement Message SHOULD trigger a logging
+      event.  The GCKS MAY be configured with such additional policy
+      actions as transmitting the GROUPKEY-PUSH message several times in
+      a short period of time (as suggested in [RFC4046]), thereby
+      mitigating loss of either the GROUPKEY-PUSH message or an
+      Acknowledgement Message.  Another policy action could be to alert
+      GCKS administrators of GMs that do not return several consecutive
+      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 Message.
+
+   o  A GCKS SHOULD log failure events, such as receiving
+      Acknowledgement Messages for a group in which the GCKS has not
+      requested Acknowledgements, receiving malformed Acknowledgements,
+      and Acknowledgements that fail validation.
+
+
+
+Weis, et al.                 Standards Track                   [Page 11]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+7.  Security Considerations
+
+   There are three areas of security considerations to consider: the
+   protection of the GROUPKEY-PUSH 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 or PRF-HMAC-SHA-512.  The strengths of
+   PRF-HMAC-SHA-256 and PRF-HMAC-SHA-512 were unquestioned at the time
+   this memo was developed.  When a HASH construction using a different
+   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 is an 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 protection
+   against man-in-the-middle attacks are provided by the inclusion of a
+   HASH payload that includes the output of an HMAC computation over the
+   bytes of the message.
+
+   Because the KEK is a group secret, when the value of REKEY_ACK_KEK is
+   specified, impersonation of a victim GM by another authorized GM is
+   possible.  However, security considerations regarding such an
+   impersonation are limited to a false claim that a victim GM has
+   received a 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 SAs.  However, this 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.  The
+   contents of the message, including the hash value, the sequence
+   number from the GROUPKEY-PUSH message to which it is acknowledging
+   receipt, and the identity of the 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.  Note
+   that the sequence number in the GROUPKEY-PUSH ACK does reveal the
+   sequence number (previously not available to the attacker) that was
+
+
+
+Weis, et al.                 Standards Track                   [Page 12]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+   included in the GROUPKEY-PUSH message.  However, the attacker is
+   assumed to not be in possession of the key used to encrypt the
+   message and thus cannot create a spoofed GROUPKEY-PUSH message.
+   Therefore, the attacker does not derive any direct value from
+   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 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 message will have been validated, replay protection
+   completed, and the digital signature verified as being genuine.
+   Therefore, the 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,
+   are mitigated.  For more information, see the security considerations
+   for a GROUPKEY-PUSH message as described in Section 7.3 of [RFC6407].
+
+7.3.  Receiving a GROUPKEY-PUSH ACK
+
+   A GCKS receiving 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 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 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 sequence number and identity included in an
+   ACK is a matter of local policy and is outside the scope of this
+   memo.
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 13]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+8.  IANA Considerations
+
+   The following additions have been made to the "Group Domain of
+   Interpretation (GDOI) Payloads" [GDOI-REG] registry.
+
+   A new attribute has been added to the "SA KEK Payload Values - KEK
+   Attributes" registry.  The ID Class name is KEK_ACK_REQUESTED with a
+   value of 9 and is a Basic attribute.
+
+   A new registry defining values for 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", and "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 the GDOI, "GDOI
+   DOI Exchange Types", has been added 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 values used with the ISAKMP GDOI DOI.  The registration
+   procedure is Specification Required.  The terms "Known Unregistered
+   Use" and "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 8263
+             Unassigned                 36-239
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 14]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+9.  References
+
+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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 15]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+9.2.  Informative References
+
+   [GDOI-REG]
+              Internet Assigned Numbers Authority, "Group Domain of
+              Interpretation (GDOI) Payload Type Values", IANA Registry,
+              September 2017, <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,
+              <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,
+              <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 (Revised)", National Institute of
+              Science and Technology, NIST Special Publication 800-108,
+              DOI 10.6028/NIST.SP.800-108, October 2009,
+              <http://nvlpubs.nist.gov/nistpubs/Legacy/SP/
+              nistspecialpublication800-108.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 16]
+
+RFC 8263                    GROUPKEY-PUSH ACK              November 2017
+
+
+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
+   United States of America
+
+   Phone: +1-408-526-4796
+   Email: bew@cisco.com
+
+
+   Umesh Mangla
+   Juniper Networks Inc.
+   1133 Innovation Way
+   Sunnyvale, California  94089
+   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
+   Email: thomas.karl@telekom.de
+
+
+   Nilesh Maheshwari
+
+   Email: nileshm@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 17]
+