doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc8052.txt b/doc/rfc/rfc8052.txt
new file mode 100644
index 0000000..dec2326
--- /dev/null
+++ b/doc/rfc/rfc8052.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           B. Weis
+Request for Comments: 8052                                    M. Seewald
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                                  H. Falk
+                                                                   SISCO
+                                                               June 2017
+
+
+             Group Domain of Interpretation (GDOI) Protocol
+                Support for IEC 62351 Security Services
+
+Abstract
+
+   The IEC 61850 power utility automation family of standards describes
+   methods using Ethernet and IP for distributing control and data
+   frames within and between substations.  The IEC 61850-90-5 and IEC
+   62351-9 standards specify the use of the Group Domain of
+   Interpretation (GDOI) protocol (RFC 6407) to distribute security
+   transforms for some IEC 61850 security protocols.  This memo defines
+   GDOI payloads to support those security protocols.
+
+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
+   http://www.rfc-editor.org/info/rfc8052.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 1]
+
+RFC 8052               GDOI Support for IEC 62351              June 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
+   (http://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 Language . . . . . . . . . . . . . . . . . .   4
+     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.3.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  IEC 61850 Protocol Information  . . . . . . . . . . . . . . .   5
+     2.1.  ID Payload  . . . . . . . . . . . . . . . . . . . . . . .   5
+     2.2.  SA TEK Payload  . . . . . . . . . . . . . . . . . . . . .   6
+     2.3.  KD Payload  . . . . . . . . . . . . . . . . . . . . . . .  11
+   3.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .  16
+   Appendix A.  Example ID, SA TEK, and KD Payloads for IEC 61850  .  19
+   Appendix B.  Implementation Considerations  . . . . . . . . . . .  23
+     B.1.  DER Length Fields . . . . . . . . . . . . . . . . . . . .  23
+     B.2.  Groups with Multiple Senders  . . . . . . . . . . . . . .  23
+   Appendix C.  Data Attribute Format  . . . . . . . . . . . . . . .  23
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
+
+1.  Introduction
+
+   Power substations use Generic Object Oriented Substation Events
+   (GOOSE) protocol [IEC-61850-8-1] to distribute control information to
+   groups of devices using a multicast strategy.  Sources within the
+   power substations also distribute IEC 61850-9-2 sampled values data
+   streams [IEC-61850-9-2].  The IEC 62351-9 standard [IEC-62351-9]
+   describes key management methods for the security methods protecting
+   these IEC 61850 messages, including methods of device authentication
+   and authorization, and methods of policy and keying material
+
+
+
+Weis, et al.                 Standards Track                    [Page 2]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   agreement for IEC 61850 message encryption and data integrity
+   protection.  These key management methods include the use of GDOI
+   [RFC6407] to distribute the security policy and session keying
+   material used to protect IEC 61850 messages when the messages are
+   sent to a group of devices.
+
+   The protection of the messages is defined in IEC 62351-6
+   [IEC-62351-6], IEC 61850-8-1 [IEC-61850-8-1], and IEC 61850-9-2
+   [IEC-61850-9-2].  Protected IEC 61850 messages typically include the
+   output of a Message Authentication Code (MAC) and may also be
+   encrypted using a symmetric cipher such as the Advanced Encryption
+   Standard (AES).
+
+   Section 5.5.2 of RFC 6407 specifies that the following information
+   needs to be provided in order to fully define a new security
+   protocol:
+
+   o  The Protocol-ID for the particular security protocol
+
+   o  The SPI Size
+
+   o  The method of SPI generation
+
+   o  The transforms, attributes, and keys needed by the security
+      protocol
+
+   This document defines GDOI payloads to distribute policy and keying
+   material to protect IEC 61850 messages and defines the necessary
+   information to ensure interoperability between IEC 61850
+   implementations.
+
+   This memo extends RFC 6407 in order to define extensions needed by
+   IEC 62351-9.  With the current IANA registry rules set up by RFC
+   6407, this requires "Standards Action" [RFC5226] by the IETF; this
+   document satisfies that requirement.  As the relevant IEC
+   specifications are not available to the IETF community, it is not
+   possible for this RFC to fully describe the security considerations
+   that apply.  Therefore, implementers need to depend on the security
+   analysis within the IEC specifications.  As two different Standards
+   Development Organizations are involved here, and since group key
+   management is inherently complex, it is possible that some security
+   issues have not been identified, so additional analysis of the
+   security of the combined set of specifications may be advisable.
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 3]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+1.1.  Requirements Language
+
+   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.  Terminology
+
+   The following key terms are used throughout this document:
+
+   Generic Object Oriented Substation Events:  Power substation control
+         model defined as per IEC 61850.
+
+   IEC 61850 message:  A message in the IEC 61850 family of protocols
+         carrying control or data frames between substation devices.
+
+1.3.  Acronyms
+
+   The following acronyms are used throughout this document:
+
+   AES     Advanced Encryption Standard
+
+   GCKS    Group Controller/Key Server
+
+   GDOI    Group Domain of Interpretation
+
+   GM      Group Member
+
+   GOOSE   Generic Object Oriented Substation Events
+
+   KD      Key Download
+
+   KEK     Key Encryption Key
+
+   MAC     Message Authentication Code
+
+   SA      Security Association
+
+   SPI     Security Parameter Index
+
+   TEK     Traffic Encryption Key
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 4]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+2.  IEC 61850 Protocol Information
+
+   The following subsections describe the GDOI payload extensions that
+   are needed in order to distribute security policy and keying material
+   for the IEC 62351 Security Services.  The Identification (ID) Payload
+   is used to describe an IEC 62351 GDOI group.  The Security
+   Association (SA) Traffic Encryption Key (TEK) payload is used to
+   describe the policy defined by a Group Controller/Key Server (GCKS)
+   for a particular IEC 62351 traffic selector.  No changes are required
+   to the Key Download (KD) Payload, but a mapping of IEC 62351 keys to
+   the KD payload key types is included.
+
+   All multi-octet fields are in network byte order.
+
+2.1.  ID Payload
+
+   The ID payload in a GDOI GROUPKEY-PULL exchange allows the Group
+   Member (GM) to declare the group it would like to join.  A group is
+   defined by an ID payload as defined in GDOI [RFC6407] and reproduced
+   in Figure 1.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Next Payload  !   RESERVED    !         Payload Length        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !    ID Type    !      DOI-Specific ID Data = 0                 !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ~                       Identification Data                     ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                 Figure 1: RFC 6407 Identification Payload
+
+   An ID Type name of ID_OID (value 13) is defined in this memo to
+   specify an Object Identifier (OID) [ITU-T-X.683] encoded using
+   Distinguished Encoding Rules (DER) [ITU-T-X.690].  Associated with
+   the OID may be an OID-Specific Payload DER encoded as further
+   defining the group.  Several OIDs are specified in [IEC-62351-9] for
+   use with IEC 61850.  Each OID represents a GOOSE or Sampled Value
+   protocol, and in some cases IEC 61850 also specifies a particular
+   multicast destination address to be described in the OID-Specific
+   Payload field.  The format of the ID_OID Identification Data is
+   specified as shown in Figure 2.
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 5]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !  OID Length   !                       OID                     ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !  OID-Specific Payload Length  !     OID-Specific Payload      ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                   Figure 2: ID_OID Identification Data
+
+   The ID_OID Identification Data fields are defined as follows:
+
+   o  OID Length (1 octet) -- Length of the OID field.
+
+   o  OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER
+      [ITU-T-X.690].
+
+   o  OID-Specific Payload Length (2 octets) -- Length of the OID-
+      Specific payload.  Set to zero if the OID does not require an OID-
+      Specific payload.
+
+   o  OID-Specific Payload (variable) -- OID-specific selector encoded
+      in DER.  If OID-Specific Payload Length is set to zero, this field
+      does not appear in the ID payload.
+
+2.2.  SA TEK Payload
+
+   The SA TEK payload contains security attributes for a single set of
+   policy associated with a group TEK.  The type of policy to be used
+   with the TEK is described by a Protocol-ID field included in the SA
+   TEK.  As shown in Figure 3 reproduced from RFC 6407, each Protocol-ID
+   describes a particular TEK Protocol-Specific Payload definition.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Next Payload  !   RESERVED    !         Payload Length        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Protocol-ID   !       TEK Protocol-Specific Payload           ~
+     +-+-+-+-+-+-+-+-+                                               ~
+     ~                                                               ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                     Figure 3: RFC 6407 SA TEK Payload
+
+   The Protocol-ID name of GDOI_PROTO_IEC_61850 (value 3) is defined in
+   this memo for the purposes of distributing IEC 61850 policy.  A
+   GDOI_PROTO_IEC_61850 SA TEK includes an OID and (optionally) an OID-
+
+
+
+Weis, et al.                 Standards Track                    [Page 6]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   Specific payload that together define the selectors for the network
+   traffic.  The selector fields are followed by security policy fields
+   indicating how the specified traffic is to be protected.  The
+   GDOI_PROTO_IEC_61850 TEK Protocol-Specific Payload is defined as
+   shown in Figure 4.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !  OID Length   !                       OID                     ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !  OID-Specific Payload Length  !     OID-Specific Payload      ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                              SPI                              !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !           Auth Alg            !            Enc Alg            !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                    Remaining Lifetime Value                   !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                      SA Data Attributes                       ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                    Figure 4: IEC 61850 SA TEK Payload
+
+   The GDOI_PROTO_IEC_61850 SA TEK payload fields are defined as
+   follows:
+
+   o  OID Length (1 octet) -- Length of the OID field.
+
+   o  OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER.
+      OIDs defined in IEC 61850 declare the type of IEC 61850 message to
+      be protected, as defined by [IEC-62351-9].
+
+   o  OID-Specific Payload Length (2 octets) -- Length of the OID-
+      Specific payload.  This field is set to zero if the policy does
+      not include an OID-Specific payload.
+
+   o  OID-Specific Payload (variable) -- The traffic selector (e.g.,
+      multicast address) specific to the OID encoded using DER.  Some
+      OID policy settings do not require the use of an OID-Specific
+      payload, in which case this field is not included in the TEK and
+      the OID-Specific Payload Length is set to zero.
+
+   o  SPI (4 octets) -- Identifier for the Current Key. This field
+      represents an SPI.
+
+   o  Auth Alg (2 octets) -- Authentication Algorithm ID.  Valid values
+      are defined in Section 2.2.2.
+
+
+
+Weis, et al.                 Standards Track                    [Page 7]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   o  Enc Alg (2 octets) -- Confidentiality Algorithm ID.  Valid values
+      are defined in Section 2.2.3.
+
+   o  Remaining Lifetime value (4 octets) -- The number of seconds
+      remaining before this TEK expires.  A value of zero (0) shall
+      indicate that the TEK does not have an expire time.
+
+   o  SA Data Attributes (variable length) -- Contains zero or more
+      attributes associated with this SA.  Section 2.2.4 defines
+      attributes.
+
+2.2.1.  Selectors
+
+   The OID and (optionally) an OID-Specific payload together define the
+   selectors for the network traffic.  While they may match the OID and
+   OID-Specific payload that the GM had previously requested in the ID
+   payload, there is no guarantee that this will be the case.  Including
+   selectors in the SA TEK is important for at least the following
+   reasons:
+
+   o  The Key Server (KS) policy may direct the KS to return multiple
+      TEKs, each representing different traffic selectors, and it is
+      important that every GM receiving the set of TEKs explicitly
+      identify the traffic selectors associated with the TEK.
+
+   o  The KS policy may include the use of a GDOI GROUPKEY-PUSH message,
+      which distributes new or replacement TEKs to group members.  Since
+      the GROUPKEY-PUSH message does not contain an ID payload, the TEK
+      definition must include the traffic selectors.
+
+2.2.2.  Authentication Algorithms
+
+   This memo defines the following authentication algorithms for use
+   with this TEK.  These algorithms are defined in [IEC-TR-61850-90-5],
+   including requirements on one or more algorithms defined as mandatory
+   to implement.
+
+   o  NONE.  Specifies that an authentication algorithm is not required,
+      or when the accompanying confidentiality algorithm includes
+      authentication (e.g., AES-GCM-128).  See Section 3 for cautionary
+      notes regarding using this value without any confidentiality
+      algorithm.
+
+   o  HMAC-SHA256-128.  Specifies the use of SHA-256 [FIPS180-4]
+      combined with HMAC [RFC2104].  The output is truncated to 128
+      bits, as per [RFC2104].  The key size is the size of the hash
+      value produced by SHA-256 (256 bits).
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 8]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   o  HMAC-SHA256.  Specifies the use of SHA-256 [FIPS180-4] combined
+      with HMAC [RFC2104].  The key size is the size of the hash value
+      produced by SHA-256 (256 bits).
+
+   o  AES-GMAC-128.  Specifies the use of AES [FIPS197] in the Galois
+      Message Authentication Code (GMAC) mode [SP.800-38D] with a
+      128-bit key size.
+
+   o  AES-GMAC-256.  Specifies the use of AES [FIPS197] in the Galois
+      Message Authentication Code (GMAC) mode [SP.800-38D] with a
+      256-bit key size.
+
+2.2.3.  Confidentiality Algorithms
+
+   This memo defines the following confidentiality algorithms for use
+   with this TEK.  These algorithms are defined in [IEC-TR-61850-90-5],
+   including requirements on one or more algorithms defined as mandatory
+   to implement.
+
+   o  NONE.  Specifies that confidentiality is not required.  Note: See
+      Section 3 for guidance on cautionary notes regarding using this
+      value.
+
+   o  AES-CBC-128.  Specifies the use of AES [FIPS197] in the Cipher
+      Block Chaining (CBC) mode [SP.800-38A] with a 128-bit key size.
+      This encryption algorithm does not provide authentication and MUST
+      NOT be used with the NONE authentication algorithm.
+
+   o  AES-CBC-256.  Specifies the use of AES [FIPS197] in the Cipher
+      Block Chaining (CBC) mode [SP.800-38A] with a 256-bit key size.
+      This encryption algorithm does not provide authentication and MUST
+      NOT be used with the NONE authentication algorithm.
+
+   o  AES-GCM-128.  Specifies the use of AES [FIPS197] in the Galois/
+      Counter Mode (GCM) mode [SP.800-38D] with a 128-bit key size.
+      This encryption algorithm provides authentication and is used with
+      a NONE authentication algorithm.
+
+   o  AES-GCM-256.  Specifies the use of AES [FIPS197] in the Galois/
+      Counter Mode (GCM) mode [SP.800-38D] with a 256-bit key size.
+      This encryption algorithm provides authentication and is used with
+      a NONE authentication algorithm.
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                    [Page 9]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+2.2.4.  SA Attributes
+
+   The following attributes may be present in an SA TEK.  The attributes
+   must follow the format described in Appendix C).
+
+2.2.4.1.  SA Time Activation Delay (SA_ATD)
+
+   A GCKS will sometimes distribute an SA TEK in advance of when it is
+   expected to be used.  This is communicated to group members using the
+   SA Activation Time Delay (SA_ATD) attribute.  When a GM receives an
+   SA_TEK with this attribute, it waits for the number of seconds
+   contained within the attribute before installing it for either
+   transmitting or receiving.
+
+   This Activation Time Delay attribute applies only this SA, and MAY be
+   used in either a GROUPKEY-PULL or GROUPKEY-PUSH exchange.  RFC 6407
+   also describes an ACTIVATION_TIME_DELAY attribute for the Group
+   Associated Policy (GAP) payload, which is applied to all Security
+   Associations and is restricted to use in a GROUPKEY-PUSH message.  If
+   both attributes are included in a GROUPKEY-PUSH payload, the value
+   contained in SA_ATD will be used.
+
+2.2.4.2.  Key Delivery Assurance (SA_KDA)
+
+   Group policy can include notifying a multicast source ("Publisher")
+   of an indication of whether multicast receivers ("Subscribers") have
+   previously received the SA TEK.  This notification allows a Publisher
+   to set a policy as to whether to activate the new SA TEK or not based
+   on the percentage of Subscribers that are able to receive packets
+   protected by the SA TEK.  The attribute value is a number between 0
+   and 100 (inclusive).
+
+2.2.5.  SPI Discussion
+
+   As noted in Section 1, RFC 6407 requires that characteristics of an
+   SPI must be defined.  An SPI in a GDOI_PROTO_IEC_61850 SA TEK is
+   represented as a Key Identifier (KeyID).  The SPI size is 4 octets.
+   The SPI is unilaterally chosen by the GCKS using any method chosen by
+   the implementation.  However, an implementation needs to take care
+   not to duplicate an SPI value that is currently in use for a
+   particular group.
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 10]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+2.3.  KD Payload
+
+   The KD payload contains group keys for the policy specified in the SA
+   Payload.  It is comprised of a set of Key Packets, each of which hold
+   the keying material associated with an SPI (i.e., an IEC 61850 Key
+   Identifier).  The RFC 6407 KD payload format is reproduced in
+   Figure 5.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Next Payload  !   RESERVED    !         Payload Length        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Number of Key Packets         !            RESERVED2          !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ~                    Key Packets                                ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                           Figure 5: KD Payload
+
+   Each Key Packet holds the keying material associated with a
+   particular IEC 61850 Key Identifier, although GDOI refers to it as an
+   SPI.  The keying material is described in a set of attributes
+   indicating an encryption key, integrity key, etc., in accordance with
+   the security policy of the group as defined by the associated SA
+   Payload.  Each Key Packet has the following format, reproduced in
+   Figure 6.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !   KD Type     !   RESERVED    !       Key Packet Length       !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !    SPI Size   !                   SPI (variable)              ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ~                    Key Packet Attributes                      ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                           Figure 6: Key Packet
+
+   No changes are needed to GDOI in order to distribute IEC 61850 keying
+   material, but the keys MUST be distributed as defined in Section 5.6
+   of RFC 6407.  The KD Type MUST be TEK (1).
+
+   A key associated with an IEC 61850 authentication algorithm
+   (distributed in the Auth Alg field) MUST be distributed as a
+   TEK_INTEGRITY_KEY attribute.  The value of the attribute is
+   interpreted according to the type of key distributed in the SA TEK:
+
+
+
+Weis, et al.                 Standards Track                   [Page 11]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   o  HMAC-SHA256-128, HMAC-SHA256.  The value is 32 octets.
+
+   o  AES-GMAC-128.  The value is 20 octets.  The first 16 octets are
+      the 128-bit AES key, and the remaining four octets are used as the
+      salt value in the nonce.
+
+   o  AES-GMAC-256.  The value is 36 octets.  The first 32 octets are
+      the 256-bit AES key, and the remaining four octets are used as the
+      salt value in the nonce.
+
+   A key associated with an IEC 61850 confidentiality algorithm
+   (distributed in the Enc Alg SA TEK field) MUST be distributed as a
+   TEK_ALGORITHM_KEY attribute.  The value of the attribute is
+   interpreted according to the type of key distributed in the SA TEK:
+
+   o  AES-CBC-128.  The value is 16 octets.
+
+   o  AES-CBC-256.  The value is 32 octets.
+
+   o  AES-GCM-128.  The value is 20 octets.  The first 16 octets are the
+      128-bit AES key, and the remaining four octets are used as the
+      salt value in the nonce.
+
+   o  AES-GCM-256.  The value is 36 octets.  The first 32 octets are the
+      256-bit AES key, and the remaining four octets are used as the
+      salt value in the nonce.
+
+3.  Security Considerations
+
+   GDOI is a Security Association (SA) management protocol for groups of
+   senders and receivers.  This protocol performs authentication of
+   communicating protocol participants (Group Member, Group Controller/
+   Key Server).  GDOI provides confidentiality of key management
+   messages, and it provides source authentication of those messages.
+   GDOI includes defenses against man-in-middle, connection-hijacking,
+   replay, reflection, and denial-of-service (DOS) attacks on unsecured
+   networks.  GDOI assumes that the network is not secure and may be
+   under the complete control of an attacker.  The Security
+   Considerations described in RFC 6407 are relevant to the distribution
+   of GOOSE and sampled values policy as defined in this memo.
+
+   Message Authentication is an optional property for IEC 62351 Security
+   Services; however, when encryption is used, authentication MUST also
+   be provided by using an authenticated encryption algorithm such as
+   AES-GCM-128 or by using a specific authentication algorithm such as
+   HMAC-SHA-256.  Setting the authentication algorithm to NONE but
+   setting the confidentiality algorithm to an algorithm that does not
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 12]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   include authentication (i.e., is marked with an N in the
+   "Authenticated Encryption" column of the "IEC 62351-9 Confidentiality
+   Values" registry) is not safe and MUST NOT be done.
+
+   When Message Authentication is used, a common practice is to truncate
+   the output of a MAC and include some of the bits in the integrity
+   protection field of the data security transform.  Current guidance in
+   [RFC2104] is to truncate no less than half of the length of the hash
+   output.  The authentication algorithm HMAC-SHA256-128 defined in this
+   memo truncates the output to exactly half of the output, which
+   follows this guidance.
+
+   Confidentiality is an optional security property for IEC 62351
+   Security Services.  Confidentiality Algorithm IDs SHOULD be included
+   in the IEC 61850 SA TEK payload if the IEC 61850 messages are
+   expected to traverse public network links and are not protected by
+   another level of encryption (e.g., an encrypted Virtual Private
+   Network).  Current cryptographic advice indicates that the use of
+   AES-CBC-128 for confidentiality is sufficient for the foreseeable
+   future [SP.800-131A], but some security policies may require the use
+   of AES-CBC-256.
+
+   IEC 62351 Security Services describe a variety of policy choices for
+   protecting network traffic, including the option of specifying no
+   protection at all.  This is enabled with the use of NONE as an
+   authentication algorithm and/or confidentiality algorithm.  The
+   following guidance is given regarding the use of NONE.
+
+   o  Setting both the authentication algorithm and confidentiality
+      algorithm to NONE is possible but NOT RECOMMENDED.  Setting such a
+      policy is sometimes necessary during a migration period, when
+      traffic is being protected incrementally and some traffic has not
+      yet been scheduled for protection.  Alternatively, site security
+      policy for some packet flows requires inspection of packet data on
+      the private network followed by network-layer encryption before
+      delivery to a public network.
+
+   o  Setting the confidentiality algorithm to NONE but setting the
+      authentication algorithm to a MAC can be an acceptable policy in
+      the following conditions: the disclosed information in the data
+      packets is comprised of raw data values and the disclosure of the
+      data files is believed to be of no more value to an observer than
+      traffic analysis on the frequency and size of packets protected
+      for confidentiality.  Alternatively, site security policy for some
+      packet flows requires inspection of packet data on the private
+      network followed by network-layer encryption before delivery to a
+      public network.
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 13]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   o  Setting the authentication algorithm to NONE but setting the
+      confidentiality algorithm to an algorithm that does not include
+      authentication is not safe and MUST NOT be done.
+
+4.  IANA Considerations
+
+   The "Group Domain of Interpretation (GDOI) Payloads" registry
+   [GDOI-REG] has been updated as described below.  The terms "Expert
+   Review", "Reserved", and "Private Use" are used as defined in
+   [RFC5226].
+
+   o  GDOI_PROTO_IEC_61850 (value 3) has been added to the "SA TEK
+      Payload Values - Protocol-ID" registry.
+
+   o  A new "IEC 62351-9 Authentication Values" registry has been
+      created.  This registry defines Auth Alg values.  Initial values
+      for the registry are given below; future assignments are to be
+      made through "Expert Review" [RFC5226].
+
+      Name                         Value
+      ----                         -----
+      Reserved                       0
+      NONE                           1
+      HMAC-SHA256-128                2
+      HMAC-SHA256                    3
+      AES-GMAC-128                   4
+      AES-GMAC-256                   5
+      Unassigned                  6-61439
+      Reserved for Private Use  61440-65535
+
+   o  A new "IEC 62351-9 Confidentiality Values" registry has been
+      created.  This registry defines Enc Alg values.  Initial values
+      for the registry are given below; future assignments are to be
+      made through "Expert Review" [RFC5226].
+
+      Name                         Value     Authenticated Encryption
+      ----                         -----     ------------------------
+      Reserved                       0
+      NONE                           1
+      AES-CBC-128                    2                 N
+      AES-CBC-256                    3                 N
+      AES-GCM-128                    4                 Y
+      AES-GCM-256                    5                 Y
+      Unassigned                  6-61439
+      Reserved for Private Use  61440-65535
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 14]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   o  A new "GDOI SA TEK Attributes" registry has been created.  This
+      registry defines SA TEK attributes.  Initial values for the
+      registry are given below; future assignments are to be made
+      through "Expert Review" [RFC5226].  In the table, attributes that
+      are defined as Type/Value (TV) are marked as Basic (B); attributes
+      that are defined as Type/Length/Value (TLV) are marked as Variable
+      (V).
+
+      Attribute                    Value           Type
+      ---------                    -----           ----
+      Reserved                       0
+      SA_ATD                         1               V
+      SA_KDA                         2               B
+      Unassigned                  3-28671
+      Reserved for Private Use   28672-32767
+
+   o  A new "ID Types" registry has been created for the Identification
+      Payload when the DOI is GDOI.  This registry is taken from the
+      "IPSEC Identification Type" registry for the IPsec DOI
+      [IPSEC-DOI-REG].  Values 1-12 are defined identically to the
+      equivalent values in the "IPSEC Identification Type" registry.
+      Value 13 (ID_OID) is defined in this memo.  Initial values for the
+      registry are given below; future assignments are to be made
+      through "Expert Review" [RFC5226].
+
+      Name                          Value
+      ----                          -----
+      Reserved                        0
+      ID_IPV4_ADDR                    1
+      ID_FQDN                         2
+      ID_USER_FQDN                    3
+      ID_IPV4_ADDR_SUBNET             4
+      ID_IPV6_ADDR                    5
+      ID_IPV6_ADDR_SUBNET             6
+      ID_IPV4_ADDR_RANGE              7
+      ID_IPV6_ADDR_RANGE              8
+      ID_DER_ASN1_DN                  9
+      ID_DER_ASN1_GN                  10
+      ID_KEY_ID                       11
+      ID_LIST                         12
+      ID_OID                          13
+      Unassigned                   14-61439
+      Reserved for Private Use   61440-65535
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 15]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+5.  References
+
+5.1.  Normative References
+
+   [IEC-62351-9]
+              International Electrotechnical Commission, "Power systems
+              management and associated information exchange - Data and
+              communications security - Part 9: Cyber security key
+              management for power system equipment", IEC 62351-9:2017,
+              May 2017.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
+              of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
+              October 2011, <http://www.rfc-editor.org/info/rfc6407>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <http://www.rfc-editor.org/info/rfc8174>.
+
+5.2.  Informative References
+
+   [FIPS180-4]
+              National Institute of Standards and Technology, "Secure
+              Hash Standard", FIPS PUB 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <http://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.180-4.pdf>.
+
+   [FIPS197]  National Institute of Standards and Technology, "Advanced
+              Encryption Standard (AES)", FIPS PUB 197, November 2001,
+              <http://csrc.nist.gov/publications/fips/fips197/
+              fips-197.pdf>.
+
+   [GDOI-REG]
+              IANA, "Group Domain of Interpretation (GDOI) Payloads",
+              <http://www.iana.org/assignments/gdoi-payloads>.
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 16]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   [IEC-61850-8-1]
+              International Electrotechnical Commission, "Communication
+              networks and systems for power utility automation - Part
+              8-1: Specific communication service mapping (SCSM) -
+              Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC
+              8802-3", IEC 61850-8-1, June 2011.
+
+   [IEC-61850-9-2]
+              International Electrotechnical Commission, "Communication
+              networks and systems for power utility automation - Part
+              9-2: Specific communication service mapping (SCSM) -
+              Sampled values over ISO/IEC 8802-3", IEC 61850-2,
+              September 2011.
+
+   [IEC-62351-6]
+              International Electrotechnical Commission, "Power systems
+              management and associated information exchange - Data and
+              communications security - Part 6: Security for IEC 61850",
+              IEC 62351-6, June 2007.
+
+   [IEC-TR-61850-90-5]
+              International Electrotechnical Commission, "Communication
+              networks and systems for power utility automation - Part
+              90-5: Use of IEC 61850 to transmit synchrophasor
+              information according to IEEE C37.118", IEC TR 62351-90-5,
+              May 2012.
+
+   [IPSEC-DOI-REG]
+              IANA, "'Magic Numbers' for ISAKMP Protocol",
+              <http://www.iana.org/assignments/isakmp-registry>.
+
+   [ITU-T-X.683]
+              International Telecommunications Union, "Information
+              technology - Abstract Syntax Notation One (ASN.1):
+              Parameterization of ASN.1 specifications",
+              ITU-T Recommendation X.683, August 2015,
+              <https://www.itu.int/rec/T-REC-X.683-201508-I/en>.
+
+   [ITU-T-X.690]
+              International Telecommunications Union, "Information
+              technology - ASN.1 encoding rules: Specification of Basic
+              Encoding Rules (BER), Canonical Encoding Rules (CER) and
+              Distinguished Encoding Rules (DER)", ITU-T Recommendation
+              X.690, August 2015,
+              <https://www.itu.int/rec/T-REC-X.690-201508-I/en>.
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 17]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              DOI 10.17487/RFC2104, February 1997,
+              <http://www.rfc-editor.org/info/rfc2104>.
+
+   [SP.800-131A]
+              Barker, E. and A. Roginsky, "Transitions: Recommendation
+              for Transitioning the Use of Cryptographic Algorithms and
+              Key Lengths", NIST Special Publication 800-131A,
+              DOI 10.6028/NIST.SP.800-131Ar1, November 2015,
+              <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
+              NIST.SP.800-131Ar1.pdf>.
+
+   [SP.800-38A]
+              Dworkin, M., "Recommendation for Block Cipher Modes of
+              Operation: Methods and Techniques", NIST Special
+              Publication 800-38A, DOI 10.6028/NIST.SP.800-38A, December
+              2001, <http://nvlpubs.nist.gov/nistpubs/Legacy/SP/
+              nistspecialpublication800-38a.pdf>.
+
+   [SP.800-38D]
+              Dworkin, M., "Recommendation for Block Cipher Modes of
+              Operation: Galois/Counter Mode (GCM) and GMAC", NIST
+              Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
+              November 2007,
+              <http://nvlpubs.nist.gov/nistpubs/Legacy/SP/
+              nistspecialpublication800-38d.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 18]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+Appendix A.  Example ID, SA TEK, and KD Payloads for IEC 61850
+
+   An Intelligent Electronic Device (IED) begins a GROUPKEY-PULL
+   exchange and requests keys and security policy for
+   61850_UDP_ADDR_GOOSE (OID = 1.2.840.10070.61850.8.1.2 as defined in
+   [IEC-61850-9-2]) and IP multicast address 233.252.0.1 encoded as
+   specified in [IEC-61850-9-2].
+
+   OID and OID-Specific Payload protocol fields are variable-length
+   fields.  To improve readability, their representations in Figures 7
+   and 8 are "compressed", as indicated by a trailing "~" for these
+   fields.  Implementations should be aware that because these fields
+   are variably sized, some payload fields may not be conveniently
+   aligned on an even octet.
+
+   Note: The actual DER for the OID-Specific Payload field is defined in
+   [IEC-62351-6].
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Next Payload  !   RESERVED    !         Payload Length        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! ID Type=13    !     DOI-Specific ID Data = 0                  !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! OID Len=13    ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02>  ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! OID-Specific Payload Len      ! OID SP=<DER for 233.252.0.1>  ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                  Figure 7: Sample Identification Payload
+
+   The Key Server responds with the following SA TEK payload including
+   two GDOI_PROTO_IEC_61850 Protocol-Specific TEK payloads in the second
+   GROUPKEY-PULL message.  The first one is to be activated immediately
+   and has a lifetime of 3600 seconds (0x0E10) remaining.  The second
+   has a lifetime of 12 hours (0xA8C0) and should be activated in 3300
+   seconds (0x0CE4), which gives a 5-minute (300-second) overlap of the
+   two SAs.
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 19]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Next Payload  !   RESERVED    !         Payload Length        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                             DOI = 2                           !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                         Situation = 0                         !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! SA Attr NP=16 (SA TEK)        !          RESERVED2            !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! NP=16 (SA TEK)!   RESERVED    !         Payload Length        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Prot-ID=3     !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! OID Len=13    ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02>  ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! OID-Specific Payload Len      !OID SP=<DER for 233.252.0.1>   ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                            SPI=1                              !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !  AuthAlg=1 (HMAC-SHA256-128)  !    EncAlg=2  (AES-CBC-128)    !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !              Remaining Lifetime=0x0E01                        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! SA Attr NP=16 (SA TEK)        !          RESERVED2            !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! NP=0          !   RESERVED    !         Payload Length        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Prot-ID=3     !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! OID Len=13    ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02>  ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! OID-Specific Payload Len      !OID SP=<DER for 233.252.0.1>   ~
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                            SPI=2                              !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !       AuthAlg=0 (NONE)        !    EncAlg=4 (AES-GCM-128)     !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !              Remaining Lifetime=0xA8C0                        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !       Type=1 (SA_ATD)         !           Length=4            !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                        Value=0x0CE4                           !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                   Figure 8: Sample IEC 61850 SA Payload
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 20]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   The IED acknowledges that it is capable and willing to use this
+   policy in the third GROUPKEY-PULL message.  In response, the KS sends
+   a KD payload to the requesting IED.  This concludes the GROUPKEY-PULL
+   exchange.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 21]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Next Payload  !   RESERVED    !         Payload Length        !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! Number of Key Packets=2       !            RESERVED2          !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !   KD Type=1   !   RESERVED    !        Key Packet Length      !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !   SPI Size=4  !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                            SPI=1                              !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! TYPE=TEK_INTEGRITY_KEY (2)    ! LENGTH=32 (256-bit key)       !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                                                               !
+     !                                                               !
+     !                                                               !
+     !                        HMAC-SHA256 Key                        !
+     !                                                               !
+     !                                                               !
+     !                                                               !
+     !                                                               !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! TYPE=TEK_ALGORITHM_KEY (1)    ! LENGTH=16                     !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                                                               !
+     !                        AES-CBC-128 Key                        !
+     !                                                               !
+     !                                                               !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !   KD Type=1   !   RESERVED    !        Key Packet Length      !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !   SPI Size=4  !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                            SPI=2                              !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     ! TYPE=TEK_ALGORITHM_KEY (1)    ! LENGTH=20                     !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+     !                                                               !
+     !                    AES-GCM-128 Key & Salt                     !
+     !                                                               !
+     !                                                               !
+     !                                                               !
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
+
+                        Figure 9: Sample KD Payload
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 22]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+Appendix B.  Implementation Considerations
+
+   Several topics have been suggested as useful for implementers.
+
+B.1.  DER Length Fields
+
+   The ID and SA TEK payloads defined in this memo include explicit
+   lengths for fields formatted as DER.  This includes the OID Length
+   and OID-Specific Payload Length fields shown in Figures 2 and 4.
+   Strictly speaking, these lengths are redundant since the length of
+   the DER value is also encoded within the DER fields.  It would be
+   possible to determine the lengths of the fields from those encoded
+   values.  However, many implementations will find the explicit length
+   fields convenient when constructing and sanity checking the GDOI
+   messages including these payloads.  Implementations will thus be
+   spared from manipulating the DER itself when performing activities
+   that do not otherwise require parsing in order to obtain values
+   therein.
+
+B.2.  Groups with Multiple Senders
+
+   GCKS policy may specify more than one protected type of IEC 61850
+   message within a GDOI group.  This is represented within a GDOI SA
+   Payload by the presence of an SA TEK payload for each multicast group
+   that is protected as part of group policy.  The OID contained in each
+   of the SA TEK payloads may be identical, but the value of each OID-
+   Specific Payload would be unique.  Typically, the OID-Specific
+   payload defines a destination address, and there is typically a
+   single sender to that destination address.
+
+Appendix C.  Data Attribute Format
+
+   Data attributes attached to an SA TEK following the data attribute
+   format are described in this section.  Data attributes can be in
+   Type/Value (TV) format (useful when a value is defined to be less
+   than two octets in size) or in Type/Length/Value (TLV) form.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !A!       Attribute Type        !    AF=0  Attribute Length     !
+   !F!                             !    AF=1  Attribute Value      !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   .                   AF=0  Attribute Value                       .
+   .                   AF=1  Not Transmitted                       .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 10: Data Attributes
+
+
+
+Weis, et al.                 Standards Track                   [Page 23]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+   The Data Attributes fields are defined as follows:
+
+   o  Attribute Type (2 octets) -- Unique identifier for each type of
+      attribute.  These attributes are defined as part of the DOI-
+      specific information.  The most significant bit, or Attribute
+      Format (AF), indicates whether the data attributes follow the
+      Type/Length/Value (TLV) format or a shortened Type/Value (TV)
+      format.  If the AF bit is a zero (0), then the data attributes are
+      of the Type/Length/Value (TLV) form.  If the AF bit is a one (1),
+      then the data attributes are of the Type/Value form.
+
+   o  Attribute Length (2 octets) -- Length in octets of the Attribute
+      Value.  When the AF bit is a one (1), the Attribute Value is only
+      2 octets, and the Attribute Length field is not present.
+
+   o  Attribute Value (variable length) -- Value of the attribute
+      associated with the DOI-specific Attribute Type.  If the AF bit is
+      a zero (0), this field has a variable length defined by the
+      Attribute Length field.  If the AF bit is a one (1), the Attribute
+      Value has a length of 2 octets.
+
+Acknowledgements
+
+   The authors thank Sean Turner, Steffen Fries, Yoav Nir, Vincent Roca,
+   Dennis Bourget, and David Boose for their thoughtful reviews, each of
+   which resulted in substantial improvements to this memo.  Joe Salowey
+   provided valuable guidance as document shepherd during the
+   publication process.  The authors are indebted to Kathleen Moriarty
+   for her agreement to sponsor the publication of the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 24]
+
+RFC 8052               GDOI Support for IEC 62351              June 2017
+
+
+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
+
+
+   Maik Seewald
+   Cisco Systems
+   Am Soeldnermoos 17
+   D-85399 Hallbergmoos
+   Germany
+
+   Phone: +49 619 6773 9655
+   Email: maseewal@cisco.com
+
+
+   Herb Falk
+   SISCO
+   6605 19-1/2 Mile Road
+   Sterling Heights, MI  48314
+   United States of America
+
+   Phone: +1 586 254 0020 x105
+   Email: herb@sisconet.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weis, et al.                 Standards Track                   [Page 25]
+