Skip to main content

GDOI GROUPKEY-PUSH Acknowledgement Message
draft-weis-gdoi-rekey-ack-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8263.
Expired & archived
Authors Brian Weis , Umesh Mangla , Nilesh Maheshwari , Thomas Karl
Last updated 2015-09-10 (Latest revision 2015-03-09)
RFC stream (None)
Formats
Reviews
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 8263 (Proposed Standard)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-weis-gdoi-rekey-ack-02
Network Working Group                                            B. Weis
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                               U. Mangla
Expires: September 10, 2015                                N. Maheshwari
                                                   Juniper Networks Inc.
                                                                 T. Karl
                                                        Deutsche Telekom
                                                           March 9, 2015

               GDOI GROUPKEY-PUSH Acknowledgement Message
                      draft-weis-gdoi-rekey-ack-02

Abstract

   The Group Domain of Interpretation (RFC 6407) includes the ability
   for 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 the GM devices to return an
   acknowledgement of receipt of its rekey 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 of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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 September 10, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Weis, et al.           Expires September 10, 2015               [Page 1]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

   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

   2.  Acknowledgement Message Request  . . . . . . . . . . . . . . .  5
     2.1.  REKEY_ACK_KEK Type . . . . . . . . . . . . . . . . . . . .  5
     2.2.  REKEY_ACK_LKH Type . . . . . . . . . . . . . . . . . . . .  5

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

   5.  GCKS Operations  . . . . . . . . . . . . . . . . . . . . . . . 10

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
     6.1.  Protection of the GROUPKEY-PUSH ACK  . . . . . . . . . . . 11
     6.2.  Transmitting a GROUPKEY-PUSH ACK . . . . . . . . . . . . . 12
     6.3.  Receiving a GROUPKEY-PUSH ACK  . . . . . . . . . . . . . . 12

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Weis, et al.           Expires September 10, 2015               [Page 2]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

1.  Introduction

   The Group Domain of Interpretation (RFC 6407) 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.  GDOI meets
   the requirement of the Multicast Security (MSEC) Group Key Management
   Architecture [RFC4046], and defines both a Registration Protocol and
   Rekey Protocol.  GDOI describes the Rekey Protocol as a GROUPKEY-PUSH
   message.

   A GDOI GCKS uses a GROUPKEY-PUSH message to alert group members 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 group member 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 members may no longer be
   members of the group.

   This memo introduces a method by which a GM returns an acknowledgment
   message to the GCKS.  Initially a GCKS requests GM to acknowledge
   GROUPKEY-PUSH messages as part of distributed group policy.  Then
   (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.

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

                    Figure 1: GROUPKEY-PUSH Rekey Event

   Implementation of the GROUPKEY-PUSH Acknowledgement Message is
   OPTIONAL.

Weis, et al.           Expires September 10, 2015               [Page 3]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Weis, et al.           Expires September 10, 2015               [Page 4]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

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
   download 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 KEK payload (Section 5.3 of
   [RFC6407]).  When necessary the GROUPKEY-PUSH Rekey Protocol also
   contains an SA payload that includes 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 (value TBD-1), which indicates that the GM
   is requested to return a GROUPKEY-PUSH Acknowledgement Message.  A GM
   receiving the KEK_ACK_REQUESTED attribute can choose to ignore it,
   thus appearing as if it does not support the KEK_ACK_REQUESTED
   attribute.  However, GCKS policy may consider a non-responsive GM to
   no longer desire to be a member of the group.

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

2.1.  REKEY_ACK_KEK Type

   This type of Rekey ACK indicates the message defined in this memo,
   where the base_key (defined in Section 3.2) is the KEK_ALGORITHM_KEY
   used to decrypt the GROUPKEY-PUSH message.  Note that the
   KEK_ALGORITHM_KEY may include an explicit 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 Type

   This type of Rekey ACK can be used when the KEK_MANAGEMENT_ALGORITHM
   KEK attribute has a value representing LKH.  The base_key is the Key
   Data taken from the first LKH Key structure in an LKH_DOWNLOAD_ARRAY
   attribute (see Section 5.6.3.1 of [RFC6407]).  This is a private key
   that the GCKS shares with the group member.  Note that the LKH Key
   structure may 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.

Weis, et al.           Expires September 10, 2015               [Page 5]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

3.  GROUPKEY-PUSH Acknowledgement Message

   The GROUPKEY-PUSH message defined in [RFC6407] is reproduced in
   Figure 2.  The SA and KD payloads contain the actual policy and
   keying material being distributed to the GM.  The 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.

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

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

                   Figure 2: GROUPKEY-PUSH from RFC 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 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.

Weis, et al.           Expires September 10, 2015               [Page 6]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

3.1.  HDR

   The message begins with a header as defined for the GDOI GROUPKEY-
   PUSH message in Section 4.1 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 payload (8).
   Major Version is 1 and Minor Version is 0.  The Exchange Type has
   value 35 for the GDOI GROUPKEY-PUSH Acknowledgment Message.  Flags
   are set to 0.  Message ID MUST be set to zero.  Length is according
   to Section 4.1 of [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 is PRF-HMAC-SHA-256 [RFC4868].

   o  "|" indicates concatenation.

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

   The ack_key is computed from a 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 initialization vector, 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 PRF-HMAC-SHA-256 [RFC4868].

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

Weis, et al.           Expires September 10, 2015               [Page 7]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

   o  "|" indicates concatenation.

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

   o  SPI is the Initiator Cookie followed by the Responder Cookie taken
      from the GROUPKEY-PUSH message HDR, which describes the Context of
      the key usage.

   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 when PRF-
      HMAC-SHA-256 is the prf).  The value L is represented as two
      octets

3.3.  SEQ

   The Sequence Number Payload is defined in [RFC6407].  The value in
   the GROUPKEY-PUSH SEQ payload is copied to the 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 or
   ID_IPV6_ADDR as defined for GDOI exchanges
   [I-D.weis-gdoi-iec62351-9].  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.

Weis, et al.           Expires September 10, 2015               [Page 8]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

4.  Group Member Operations

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

   If a GM does not intend to respond with Acknowledgements, or 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 security associations expire, so omitting
   sending Acknowledgements should not be critical.

   When a GM receives a GROUPKEY-PUSH message, it processes the message
   according to RFC 6407.  When it concludes successful processing of
   the message, it formulates the GROUPKEY-PUSH ACK messages as
   described in Section 3 and delivers the message to the GCKS from
   which the GROUPKEY-PUSH message was received.  A 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.

Weis, et al.           Expires September 10, 2015               [Page 9]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

5.  GCKS Operations

   When a GCKS policy includes requesting a GROUPKEY-PUSH ACK message
   from Group Members, 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 SA
   KEK, as described in Section 2.

   When a GCKS receives a GROUPKEY-PUSH ACK message (identified by an
   Exchange type of GROUPKEY-PUSH-ACK), it first verifies that the group
   policy includes receiving GROUPKEY-PUSH ACK messages.  If not, the
   message is discarded.

   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
   serial number.  The GCKS MAY be configured with additional policy
   actions such as alerting its 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
   chosen not to respond will not receive newer group policy until it
   initiates contact with the GCKS again.

   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 time to acknowledge receiving
   the GROUPKEY-PUSH message.

Weis, et al.           Expires September 10, 2015              [Page 10]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

6.  Security Considerations

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

6.1.  Protection of the GROUPKEY-PUSH ACK

   The GROUPKEY-PUSH ACK message is an ISAKMP [RFC2408] message.
   Message authentication and Man-in-the-Middle Attack Protection is
   provided by the inclusion of a HASH payload, which includes the
   output of an HMAC computation (PRF-HMAC-SHA-256) over the bytes of
   the message.

   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 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 may not receive replacement security
   associations.  However, this adds no 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
   individual GM.

   Confidentiality is not provided for the GROUPKEY-PUSH ACK message.
   The contents of the message can be observed by a passive attacker,
   which includes the hash value, the sequence number of in the
   GROUPKEY-PUSH message to which it is acknowledging receipt, and the
   identity of the GM.  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 sequence number does reveal the sequence number that
   was included in the GROUPKEY-PUSH, which was previously not available
   to the attacker.  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, there is no
   direct value that the attacker derives from the knowledge of the
   sequence number.

Weis, et al.           Expires September 10, 2015              [Page 11]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

6.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 is
   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
   threats 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 of a GROUPKEY-
   PUSH message described in Section 7.3 of [RFC6407].

6.3.  Receiving a GROUPKEY-PUSH ACK

   A GCKS receiving ACK messages 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 from
   each GM to which it was sent.  That is, needs to ensure it has
   sufficient resources (e.g., receive queue size) so that it does not
   unnecessarily drop ACK messages.  An 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.

   GCKS implementations SHOULD keep a record (e.g., a hash value) of
   recently received GROUPKEY-PUSH Acknowledgment messages and reject
   duplicate messages prior to performing cryptographic operations.
   This enables an early discard of the replayed messages.

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

Weis, et al.           Expires September 10, 2015              [Page 12]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

7.  IANA Considerations

   The following additions are made to the GDOI Payloads [GDOI-REG]
   registry.

   A new attribute is added to the SA KEK Payload Values - KEK
   Attributes registry.  The ID Class name is KEK_ACK_REQUESTED with a
   value of TBD-1, and is a Basic attribute.  Values for this attribute
   are shown in the following table.  The terms Reserved, Unassigned,
   and Private Use are to be applied as defined in [RFC5226].  The
   registration procedure is Specification Required.

                       Value            Type
                      -------           ----
                         0              Reserved
                         1              REKEY_ACK_KEK
                         2              REKEY_ACK_LKH
                        3-128           Unassigned
                      129-255           Private Use

   A new registry is added to GDOI Payloads [GDOI-REG] defining
   Additional Exchange values for the GDOI DOI.  The registration
   procedure is Specification Required.  The terms Reserved and
   Unassigned are to be applied as defined in [RFC5226].

             Value                      Phase        Reference
             ----                       -----        ---------
             GROUPKEY-PULL               32           RFC 6407
             GROUPKEY-PUSH               33           RFC 6407
             Reserved                    34
             GROUPKEY-PUSH-ACK           35           RFC XXXX
             Unassigned                36-239

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

Weis, et al.           Expires September 10, 2015              [Page 13]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

8.  Acknowledgements

   Mike Hamada provided many useful technical and editorial comments and
   suggestions for improvement.

Weis, et al.           Expires September 10, 2015              [Page 14]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

9.  References

9.1.  Normative References

   [I-D.weis-gdoi-iec62351-9]
              Weis, B., Seewald, M., and H. Falk, "GDOI Protocol Support
              for IEC 62351 Security Services",
              draft-weis-gdoi-iec62351-9-04 (work in progress),
              May 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
              of Interpretation", RFC 6407, October 2011.

9.2.  Informative References

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

   [RFC2408]  Maughan, D., Schneider, M., and M. Schertler, "Internet
              Security Association and Key Management Protocol
              (ISAKMP)", RFC 2408, November 1998.

   [RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
              "Multicast Security (MSEC) Group Key Management
              Architecture", RFC 4046, April 2005.

   [SP800-108]
              Chen, L., "Recommendation for Key Derivation Using
              Pseudorandom Functions", United States of America,
              National Institute of Science and Technology, NIST Special
              Publication 800-108, November 2008, <http://www.iana.org/
              assignments/gdoi-payloads/gdoi-payloads.xml>.

Weis, et al.           Expires September 10, 2015              [Page 15]
Internet-Draft              GROUPKEY-PUSH ACK                 March 2015

Authors' Addresses

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

   Phone: +1-408-526-4796
   Email: bew@cisco.com

   Umesh Mangla
   Juniper Networks Inc.
   1133 Innovation Way
   Sunnyvale, California  94089
   USA

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

   Nilesh Maheshwari
   Juniper Networks Inc.
   1133 Innovation Way
   Sunnyvale, California  94089
   USA

   Phone: +1-408-936-7570
   Email: nileshm@juniper.net

   Thomas Karl
   Deutsche Telekom
   Landgrabenweg 151
   Bonn,   53227
   Germany

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

Weis, et al.           Expires September 10, 2015              [Page 16]