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
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
IEC 62351安全服务的组解释域（GDOI）协议支持
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.
IEC 61850电力设施自动化标准系列描述了使用以太网和IP在变电站内部和变电站之间分配控制和数据帧的方法。IEC 61850-90-5和IEC 62351-9标准规定使用组域解释（GDOI）协议（RFC 6407）为某些IEC 61850安全协议分发安全转换。此备忘录定义了GDOI有效负载以支持这些安全协议。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8052.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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
变电站使用通用面向对象变电站事件（GOOSE）协议[IEC-61850-8-1]，使用多播策略将控制信息分发给设备组。变电站内的电源也分配IEC 61850-9-2采样值数据流[IEC-61850-9-2]。IEC 62351-9标准[IEC-62351-9]描述了保护这些IEC 61850消息的安全方法的密钥管理方法，包括设备认证和授权方法，以及策略和密钥材料的方法
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.
IEC 61850消息加密和数据完整性保护协议。这些密钥管理方法包括使用GDOI[RFC6407]分发安全策略和会话密钥材料，用于在消息发送到一组设备时保护IEC 61850消息。
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).
IEC 62351-6[IEC-62351-6]、IEC 61850-8-1[IEC-61850-8-1]和IEC 61850-9-2[IEC-61850-9-2]中定义了信息保护。受保护的IEC 61850消息通常包括消息认证码（MAC）的输出，并且还可以使用对称密码（例如高级加密标准（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:
RFC 6407第5.5.2节规定，为了全面定义新的安全协议，需要提供以下信息：
o The Protocol-ID for the particular security protocol
o 特定安全协议的协议ID
o The SPI Size
o SPI大小
o The method of SPI generation
o SPI生成方法
o The transforms, attributes, and keys needed by the security protocol
o 安全协议所需的转换、属性和密钥
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.
本文件定义了GDOI有效载荷，用于分发策略和密钥材料，以保护IEC 61850消息，并定义了必要的信息，以确保IEC 61850实施之间的互操作性。
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.
本备忘录扩展了RFC 6407，以定义IEC 62351-9所需的扩展。根据RFC6407建立的当前IANA注册规则，这需要IETF采取“标准行动”[RFC5226]；本文件满足该要求。由于IETF社区无法获得相关IEC规范，因此本RFC不可能完全描述适用的安全注意事项。因此，实现者需要依赖于IEC规范中的安全分析。由于此处涉及两个不同的标准开发组织，并且由于组密钥管理本身就很复杂，因此可能还未发现一些安全问题，因此建议对组合规范集的安全性进行额外分析。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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定义的变电站控制模型。
IEC 61850 message: A message in the IEC 61850 family of protocols carrying control or data frames between substation devices.
IEC 61850报文：IEC 61850协议系列中的报文，在变电站设备之间传输控制或数据帧。
The following acronyms are used throughout this document:
本文件中使用了以下首字母缩略词：
AES Advanced Encryption Standard
高级加密标准
GCKS Group Controller/Key Server
GCKS组控制器/密钥服务器
GDOI Group Domain of Interpretation
GDOI组解释域
GM Group Member
总经理小组成员
GOOSE Generic Object Oriented Substation Events
GOOSE通用面向对象变电站事件
KD Key Download
KD密钥下载
KEK Key Encryption Key
KEK密钥加密密钥
MAC Message Authentication Code
MAC消息认证码
SA Security Association
南非安全协会
SPI Security Parameter Index
安全参数索引
TEK Traffic Encryption Key
TEK流量加密密钥
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.
以下小节描述了分发IEC 62351安全服务的安全策略和密钥材料所需的GDOI有效负载扩展。标识（ID）有效载荷用于描述IEC 62351 GDOI组。安全关联（SA）流量加密密钥（TEK）有效载荷用于描述由组控制器/密钥服务器（GCKS）为特定IEC 62351流量选择器定义的策略。密钥下载（KD）有效载荷无需更改，但包括IEC 62351密钥到KD有效载荷密钥类型的映射。
All multi-octet fields are in network byte order.
所有多个八位字节字段均按网络字节顺序排列。
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.
GDOI GROUPKEY-PULL交换中的ID有效负载允许组成员（GM）声明它想要加入的组。组由GDOI[RFC6407]中定义的ID有效负载定义，并在图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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图1:RFC6407识别有效载荷
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.
本备忘录中定义了ID_OID（值13）的ID类型名称，以指定使用可分辨编码规则（DER）[ITU-T-X.690]编码的对象标识符（OID）[ITU-T-X.683]。与该OID相关联的可以是编码为进一步定义该组的OID特定有效载荷DER。[IEC-62351-9]中规定了与IEC 61850一起使用的几种OID。每个OID表示GOOSE或采样值协议，在某些情况下，IEC 61850还指定了要在OID特定有效负载字段中描述的特定多播目的地地址。ID_OID标识数据的格式如图2所示。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图2：ID\u OID标识数据
The ID_OID Identification Data fields are defined as follows:
ID_OID标识数据字段定义如下：
o OID Length (1 octet) -- Length of the OID field.
o OID长度（1个八位字节）——OID字段的长度。
o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER [ITU-T-X.690].
o OID（变量）——使用DER编码的ASN.1 ObjectIdentifier[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特定有效负载长度（2个八位字节）——OID特定有效负载的长度。如果OID不需要OID特定的有效负载，则设置为零。
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.
o OID特定有效负载（变量）——在DER中编码的OID特定选择器。如果OID特定有效负载长度设置为零，则此字段不会出现在ID有效负载中。
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.
SA TEK有效负载包含与组TEK关联的单个策略集的安全属性。与TEK一起使用的策略类型由SA TEK中包含的协议ID字段描述。如图3所示，复制自RFC6407，每个协议ID描述特定于TEK协议的有效负载定义。
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 ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图3:RFC6407 SA TEK有效载荷
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-
本备忘录中定义了GDOI_PROTO_IEC_61850（值3）的协议ID名称，以分发IEC 61850策略。GDOI_协议IEC_61850 SA TEK包括OID和（可选）OID-
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.
共同定义网络流量选择器的特定负载。选择器字段后面是安全策略字段，指示如何保护指定的通信量。GDOI_协议IEC_61850 TEK协议特定有效载荷的定义如图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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图4:IEC 61850 SA TEK有效载荷
The GDOI_PROTO_IEC_61850 SA TEK payload fields are defined as follows:
GDOI_PROTO_IEC_61850 SA TEK有效载荷字段定义如下：
o OID Length (1 octet) -- Length of the OID field.
o OID长度（1个八位字节）——OID字段的长度。
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（变量）——使用DER编码的ASN.1 ObjectIdentifier。IEC 61850中定义的OID声明了[IEC-62351-9]中定义的要保护的IEC 61850消息的类型。
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特定有效负载长度（2个八位字节）——OID特定有效负载的长度。如果策略不包括OID特定的有效负载，则此字段设置为零。
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 OID特定负载（变量）——特定于使用DER编码的OID的流量选择器（例如，多播地址）。某些OID策略设置不需要使用OID特定的有效负载，在这种情况下，TEK中不包括此字段，并且OID特定的有效负载长度设置为零。
o SPI (4 octets) -- Identifier for the Current Key. This field represents an SPI.
o SPI（4个八位字节）——当前密钥的标识符。此字段表示SPI。
o Auth Alg (2 octets) -- Authentication Algorithm ID. Valid values are defined in Section 2.2.2.
o 认证Alg（2个八位字节）——认证算法ID。有效值在第2.2.2节中定义。
o Enc Alg (2 octets) -- Confidentiality Algorithm ID. Valid values are defined in Section 2.2.3.
o Enc Alg（2个八位字节）——保密算法ID。有效值在第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 剩余寿命值（4个八位字节）——此TEK过期前剩余的秒数。零（0）表示TEK没有到期时间。
o SA Data Attributes (variable length) -- Contains zero or more attributes associated with this SA. Section 2.2.4 defines attributes.
o SA数据属性（可变长度）--包含零个或多个与此SA关联的属性。第2.2.4节定义了属性。
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:
OID和（可选）OID特定负载一起定义网络流量的选择器。虽然它们可能与通用汽车公司先前在ID有效载荷中请求的OID和OID特定有效载荷相匹配，但不能保证情况会如此。将选择器包括在SA TEK中非常重要，至少有以下原因：
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 密钥服务器（KS）策略可指示KS返回多个TEK，每个TEK代表不同的流量选择器，并且接收TEK集的每个GM明确标识与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.
o KS政策可能包括使用GDOI GROUPKEY-PUSH消息，向集团成员分发新的或替换的TEK。由于GROUPKEY-PUSH消息不包含ID有效负载，因此TEK定义必须包括流量选择器。
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.
本备忘录定义了以下用于本TEK的认证算法。这些算法在[IEC-TR-61850-90-5]中有定义，包括对一个或多个算法的要求，这些算法被定义为必须实现的。
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 没有一个指定不需要身份验证算法，或者当伴随的保密算法包括身份验证时（例如，AES-GCM-128）。有关在不使用任何保密算法的情况下使用此值的注意事项，请参见第3节。
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).
o HMAC-SHA256-128。指定结合HMAC[RFC2104]使用SHA-256[FIPS180-4]。根据[RFC2104]，输出被截断为128位。密钥大小是由SHA-256（256位）生成的哈希值的大小。
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 HMAC-SHA256。指定结合HMAC[RFC2104]使用SHA-256[FIPS180-4]。密钥大小是由SHA-256（256位）生成的哈希值的大小。
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-128。指定在Galois消息验证码（GMAC）模式[SP.800-38D]中使用AES[FIPS197]，密钥大小为128位。
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.
o AES-GMAC-256。指定在Galois消息验证码（GMAC）模式[SP.800-38D]中使用AES[FIPS197]，密钥大小为256位。
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.
本备忘录定义了本TEK使用的以下保密算法。这些算法在[IEC-TR-61850-90-5]中有定义，包括对一个或多个算法的要求，这些算法被定义为必须实现的。
o NONE. Specifies that confidentiality is not required. Note: See Section 3 for guidance on cautionary notes regarding using this value.
o 没有一个指定不需要保密性。注：有关使用该值的注意事项指南，请参见第3节。
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-128。指定在密码块链接（CBC）模式[SP.800-38A]中使用AES[FIPS197]，密钥大小为128位。此加密算法不提供身份验证，不能与无身份验证算法一起使用。
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-CBC-256。指定在256位密钥大小的密码块链接（CBC）模式[SP.800-38A]中使用AES[FIPS197]。此加密算法不提供身份验证，不能与无身份验证算法一起使用。
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-128。指定在Galois/计数器模式（GCM）模式[SP.800-38D]中使用AES[FIPS197]，密钥大小为128位。此加密算法提供身份验证，并与无身份验证算法一起使用。
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.
o AES-GCM-256。指定在Galois/计数器模式（GCM）模式[SP.800-38D]中使用256位密钥大小的AES[FIPS197]。此加密算法提供身份验证，并与无身份验证算法一起使用。
The following attributes may be present in an SA TEK. The attributes must follow the format described in Appendix C).
SA TEK中可能存在以下属性。属性必须遵循附录C中描述的格式。
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.
GCKS有时会在预期使用SA TEK之前分发SA TEK。这通过SA激活时间延迟（SA_ATD）属性传达给组成员。当GM接收到带有此属性的SA_TEK时，它会等待该属性中包含的秒数，然后再安装它进行发送或接收。
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.
此激活时间延迟属性仅应用于此SA，并且可以在GROUPKEY-PULL或GROUPKEY-PUSH交换中使用。RFC 6407还描述了组关联策略（GAP）有效负载的激活时间延迟属性，该属性应用于所有安全关联，并限制在GROUPKEY-PUSH消息中使用。如果两个属性都包含在GROUPKEY-PUSH有效负载中，则将使用SA_ATD中包含的值。
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).
组策略可以包括通知多播源（“发布者”）多播接收器（“订户”）之前是否已接收到SA-TEK的指示。此通知允许发布者根据能够接收SA TEK保护的数据包的订户百分比设置是否激活新SA TEK的策略。属性值是介于0和100（包括）之间的数字。
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.
如第1节所述，RFC 6407要求必须定义SPI的特征。GDOI_协议_IEC_61850 SA TEK中的SPI表示为密钥标识符（KeyID）。SPI大小为4个八位字节。SPI由GCK使用实现选择的任何方法单方面选择。但是，实现需要注意不要复制当前用于特定组的SPI值。
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.
KD负载包含SA负载中指定的策略的组密钥。它由一组密钥包组成，每个密钥包保存与SPI（即IEC 61850密钥标识符）相关联的密钥材料。RFC 6407 KD有效负载格式如图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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图5:KD有效载荷
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.
每个密钥包都包含与特定IEC 61850密钥标识符相关联的密钥材料，尽管GDOI将其称为SPI。根据由相关SA有效载荷定义的组的安全策略，在指示加密密钥、完整性密钥等的一组属性中描述密钥材料。每个密钥包具有以下格式，如图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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图6：密钥包
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).
分发IEC 61850键控材料无需更改GDOI，但必须按照RFC 6407第5.6节的规定分发键控材料。KD类型必须为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:
与IEC 61850认证算法相关联的密钥（分布在Auth Alg字段中）必须作为TEK_INTEGRITY_密钥属性分布。属性值根据SA TEK中分布的密钥类型进行解释：
o HMAC-SHA256-128, HMAC-SHA256. The value is 32 octets.
o HMAC-SHA256-128，HMAC-SHA256。该值为32个八位字节。
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-128。值为20个八位字节。前16个八位字节是128位AES密钥，其余四个八位字节用作nonce中的salt值。
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.
o AES-GMAC-256。值为36个八位字节。前32个八位字节是256位AES密钥，其余四个八位字节用作nonce中的salt值。
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:
与IEC 61850保密算法相关的密钥（分布在Enc Alg SA TEK字段中）必须作为TEK_算法_密钥属性分布。属性值根据SA TEK中分布的密钥类型进行解释：
o AES-CBC-128. The value is 16 octets.
o AES-CBC-128。该值为16个八位字节。
o AES-CBC-256. The value is 32 octets.
o AES-CBC-256。该值为32个八位字节。
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-128。值为20个八位字节。前16个八位字节是128位AES密钥，其余四个八位字节用作nonce中的salt值。
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.
o AES-GCM-256。值为36个八位字节。前32个八位字节是256位AES密钥，其余四个八位字节用作nonce中的salt值。
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.
GDOI是针对发送方和接收方组的安全关联（SA）管理协议。此协议执行通信协议参与者（组成员、组控制器/密钥服务器）的身份验证。GDOI提供密钥管理消息的机密性，并提供这些消息的源身份验证。GDOI包括对中间人、连接劫持、重播、反射和对不安全网络的拒绝服务（DOS）攻击的防御。GDOI假设网络不安全，可能完全处于攻击者的控制之下。RFC 6407中描述的安全注意事项与本备忘录中定义的GOOSE和采样值策略的分布相关。
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
消息身份验证是IEC 62351安全服务的可选属性；但是，当使用加密时，还必须使用经验证的加密算法（如AES-GCM-128）或特定的验证算法（如HMAC-SHA-256）来提供验证。将身份验证算法设置为“无”，但将机密性算法设置为不存在的算法
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.
包含身份验证（即，在“IEC 62351-9保密值”注册表的“已验证加密”列中标记为N）是不安全的，不得进行。
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.
使用消息身份验证时，通常的做法是截断MAC的输出，并在数据安全转换的完整性保护字段中包含一些位。[RFC2104]中的当前指导是截断不少于哈希输出长度的一半。本备忘录中定义的身份验证算法HMAC-SHA256-128将输出截短为输出的一半，这符合本指南。
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安全服务的可选安全属性。如果IEC 61850消息预计将穿越公共网络链路，并且不受其他加密级别（例如，加密的虚拟专用网络）的保护，则保密算法ID应包含在IEC 61850 SA TEK有效载荷中。当前的加密建议表明，在可预见的未来，使用AES-CBC-128进行保密已足够[SP.800-131A]，但某些安全策略可能需要使用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.
IEC 62351安全服务描述了保护网络流量的各种策略选择，包括完全不指定保护的选项。这是通过使用NONE作为身份验证算法和/或保密算法实现的。以下是关于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 可以将身份验证算法和机密性算法都设置为“无”，但不建议这样做。在迁移期间设置这样的策略有时是必要的，此时流量将受到增量保护，而某些流量尚未计划进行保护。或者，某些数据包流的站点安全策略要求在发送到公共网络之前，先检查专用网络上的数据包数据，然后进行网络层加密。
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.
o 在以下条件下，将保密算法设置为NONE，但将认证算法设置为MAC可以是可接受的策略：数据分组中公开的信息由原始数据值组成，并且数据文件的公开被认为对观察者的价值不比网络上的流量分析高受保密保护的数据包的频率和大小。或者，某些数据包流的站点安全策略要求在发送到公共网络之前，先检查专用网络上的数据包数据，然后进行网络层加密。
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.
o 将身份验证算法设置为“无”，但将机密性算法设置为不包含身份验证的算法是不安全的，因此不能执行此操作。
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].
“集团解释域（GDOI）有效载荷”注册表[GDOI-REG]已更新，如下所述。术语“专家评审”、“保留”和“私人使用”的定义见[RFC5226]。
o GDOI_PROTO_IEC_61850 (value 3) has been added to the "SA TEK Payload Values - Protocol-ID" registry.
o GDOI_协议IEC_61850（值3）已添加到“SA TEK有效负载值-协议ID”注册表中。
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].
o 已创建新的“IEC 62351-9认证值”注册表。此注册表定义Auth Alg值。注册表的初始值如下所示；未来的任务将通过“专家评审”[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
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].
o 已创建新的“IEC 62351-9保密值”注册表。此注册表定义Enc Alg值。注册表的初始值如下所示；未来的任务将通过“专家评审”[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
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
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).
o 已创建新的“GDOI SA TEK属性”注册表。此注册表定义SA TEK属性。注册表的初始值如下所示；未来的任务将通过“专家评审”[RFC5226]完成。在表中，定义为类型/值（TV）的属性标记为基本（B）；定义为类型/长度/值（TLV）的属性标记为变量（V）。
Attribute Value Type
--------- ----- ----
Reserved 0
SA_ATD 1 V
SA_KDA 2 B
Unassigned 3-28671
Reserved for Private Use 28672-32767
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].
o 当DOI为GDOI时，为标识有效负载创建了一个新的“ID类型”注册表。此注册表取自IPSEC DOI[IPSEC-DOI-REG]的“IPSEC标识类型”注册表。值1-12的定义与“IPSEC标识类型”注册表中的等效值相同。值13（ID_OID）在本备忘录中定义。注册表的初始值如下所示；未来的任务将通过“专家评审”[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
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
[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.
[IEC-62351-9]国际电工委员会，“电力系统管理和相关信息交换-数据和通信安全-第9部分：电力系统设备的网络安全密钥管理”，IEC 62351-9:2017，2017年5月。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<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>.
[RFC6407]Weis，B.，Rowles，S.，和T.Hardjono，“解释的集团领域”，RFC 6407，DOI 10.17487/RFC6407，2011年10月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[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>.
[FIPS180-4]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS.180-42015年8月<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>.
[FIPS197]国家标准与技术研究所，“高级加密标准（AES）”，FIPS PUB 197，2001年11月<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>.
[GDOI-REG]IANA，“集团解释域（GDOI）有效载荷”<http://www.iana.org/assignments/gdoi-payloads>.
[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-8-1]国际电工委员会，“电力设施自动化用通信网络和系统-第8-1部分：专用通信服务映射（SCSM）-到MMS（ISO 9506-1和ISO 9506-2）和ISO/IEC 8802-3的映射”，IEC 61850-8-1，2011年6月。
[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-61850-9-2]国际电工委员会，“电力设施自动化用通信网络和系统-第9-2部分：特定通信服务映射（SCSM）-ISO/IEC 8802-3上的采样值”，IEC 61850-22011年9月。
[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-62351-6]国际电工委员会，“电力系统管理和相关信息交换-数据和通信安全-第6部分：IEC 61850的安全”，IEC 62351-6，2007年6月。
[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.
[IEC-TR-61850-90-5]国际电工委员会，“电力设施自动化用通信网络和系统-第90-5部分：根据IEEE C37.118使用IEC 61850传输同步相量信息”，IEC TR 62351-90-5，2012年5月。
[IPSEC-DOI-REG] IANA, "'Magic Numbers' for ISAKMP Protocol", <http://www.iana.org/assignments/isakmp-registry>.
[IPSEC-DOI-REG]IANA，“ISAKMP协议的“幻数”<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.683]国际电信联盟，“信息技术-抽象语法符号1（ASN.1）：ASN.1规范的参数化”，ITU-T建议X.683，2015年8月<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>.
[ITU-T-X.690]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，2015年8月<https://www.itu.int/rec/T-REC-X.690-201508-I/en>.
[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>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<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-131A]Barker，E.和A.Roginsky，“转换：密码算法和密钥长度使用的转换建议”，NIST特别出版物800-131A，DOI 10.6028/NIST.SP.800-131Ar1，2015年11月<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-38A]德沃金，M.，“分组密码操作模式的建议：方法和技术”，NIST特别出版物800-38A，DOI 10.6028/NIST.SP.800-38A，2001年12月<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>.
[SP.800-38D]德沃金，M.，“分组密码操作模式的建议：Galois/计数器模式（GCM）和GMAC”，NIST特别出版物800-38D，DOI 10.6028/NIST.SP.800-38D，2007年11月<http://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-38d.pdf>。
Appendix A. Example ID, SA TEK, and KD Payloads for IEC 61850
附录A.IEC 61850的示例ID、SA TEK和KD有效载荷
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].
智能电子设备（IED）开始组密钥拉式交换，并请求61850_UDP_ADDR_GOOSE（OID=1.2.840.10070.61850.8.1.2，定义见[IEC-61850-9-2]）和IP多播地址233.252.0.1（编码见[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.
OID和OID特定的有效负载协议字段是可变长度字段。为了提高可读性，图7和图8中的表示被“压缩”，如这些字段的尾随“~”所示。实现应该知道，由于这些字段的大小是可变的，一些有效负载字段可能无法方便地在偶数八位字节上对齐。
Note: The actual DER for the OID-Specific Payload field is defined in [IEC-62351-6].
注：OID特定有效载荷字段的实际DER在[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> ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图7：样本识别有效载荷
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.
密钥服务器响应以下SA TEK有效载荷，包括第二个GROUPKEY-PULL消息中的两个GDOI_PROTO_IEC_61850协议特定TEK有效载荷。第一个将立即激活，剩余寿命为3600秒（0x0E10）。第二个SAs的使用寿命为12小时（0xA8C0），应在3300秒（0x0CE4）内激活，从而使两个SAs重叠5分钟（300秒）。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图8:IEC 61850 SA有效载荷示例
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.
IED承认，它有能力并愿意在第三个GROUPKEY-PULL消息中使用此策略。作为响应，KS向请求的IED发送KD有效载荷。GROUPKEY-PULL交换到此结束。
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 !
! !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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
图9：KD有效载荷示例
Several topics have been suggested as useful for implementers.
有几个主题被认为对实现者有用。
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.
本备忘录中定义的ID和SA TEK有效载荷包括格式为DER的字段的显式长度。这包括图2和图4所示的OID长度和OID特定有效负载长度字段。严格来说，这些长度是多余的，因为DER值的长度也在DER字段中编码。可以根据这些编码值确定字段的长度。然而，许多实现在构造和检查包含这些有效负载的GDOI消息时会发现显式长度字段很方便。因此，当执行不需要解析以获取其中的值的活动时，实现将避免操纵DER本身。
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.
GCKS策略可以在GDOI组中指定多个受保护类型的IEC 61850消息。这在GDOI SA有效负载中表示为每个作为组策略的一部分受到保护的多播组存在SA TEK有效负载。每个SA TEK有效载荷中包含的OID可能相同，但每个OID特定有效载荷的值将是唯一的。通常，OID特定的有效负载定义一个目标地址，并且该目标地址通常只有一个发送方。
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.
本节描述了按照数据属性格式附加到SA TEK的数据属性。数据属性可以是类型/值（TV）格式（当一个值定义为小于两个八位字节时很有用）或类型/长度/值（TLV）格式。
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 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图10：数据属性
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 属性类型（2个八位字节）——每种属性类型的唯一标识符。这些属性被定义为DOI特定信息的一部分。最高有效位或属性格式（AF）指示数据属性是遵循类型/长度/值（TLV）格式还是缩短类型/值（TV）格式。如果AF位为零（0），则数据属性为类型/长度/值（TLV）形式。如果AF位为一（1），则数据属性为类型/值形式。
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 属性长度（2个八位字节）——属性值的八位字节长度。当AF位为1时，属性值仅为2个八位字节，并且属性长度字段不存在。
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.
o 属性值（可变长度）——与DOI特定属性类型关联的属性值。如果AF位为零（0），则该字段具有由属性长度字段定义的可变长度。如果AF位为1，则属性值的长度为2个八位字节。
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.
作者感谢Sean Turner、Steffen Fries、Yoav Nir、Vincent Roca、Dennis Bourget和David Boose的深思熟虑的评论，每一篇评论都为本备忘录带来了实质性的改进。Joe Salowey在出版过程中作为文件管理员提供了宝贵的指导。作者感谢Kathleen Moriarty同意赞助该文件的出版。
Authors' Addresses
作者地址
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 United States of America
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号95134-1706
Phone: +1 408 526 4796
Email: bew@cisco.com
Phone: +1 408 526 4796
Email: bew@cisco.com
Maik Seewald Cisco Systems Am Soeldnermoos 17 D-85399 Hallbergmoos Germany
德国哈尔伯格穆斯17 D-85399思科系统公司
Phone: +49 619 6773 9655
Email: maseewal@cisco.com
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
Herb Falk SISCO 6605美国密歇根州斯特林高地19-1/2英里路，邮编：48314
Phone: +1 586 254 0020 x105
Email: herb@sisconet.com
Phone: +1 586 254 0020 x105
Email: herb@sisconet.com