[要約] RFC 8052は、IEC 62351セキュリティサービスのためのGroup Domain of Interpretation（GDOI）プロトコルのサポートに関するものです。このRFCの目的は、GDOIプロトコルを使用してIEC 62351セキュリティサービスを提供するためのガイドラインを提供することです。
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セキュリティサービスに対するGroup Domain of Interpretation（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標準では、Group Domain of Interpretation（GDOI）プロトコル（RFC 6407）を使用して、一部のIEC 61850セキュリティプロトコルのセキュリティトランスフォームを配布することを指定しています。このメモは、それらのセキュリティプロトコルをサポートするためにGDOIペイロードを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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 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.
変電所は、汎用オブジェクト指向変電所イベント（GOOSE）プロトコル[IEC-61850-8-1]を使用して、マルチキャスト戦略を使用して制御情報をデバイスのグループに配信します。変電所内のソースもIEC 61850-9-2のサンプル値データストリーム[IEC-61850-9-2]を配布します。 IEC 62351-9標準[IEC-62351-9]は、デバイスの認証と承認の方法を含む、これらのIEC 61850メッセージを保護するセキュリティメソッドのキー管理方法、およびIEC 61850メッセージの暗号化とデータのポリシーとキーマテリアル契約の方法を説明しています整合性保護。これらの鍵管理方法には、メッセージがデバイスのグループに送信されるときにIEC 61850メッセージを保護するために使用されるセキュリティポリシーとセッションキーイング資料を配布するためのGDOI [RFC6407]の使用が含まれます。
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）の出力が含まれており、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:
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.
このメモは、IEC 62351-9で必要な拡張を定義するためにRFC 6407を拡張します。 RFC 6407で設定された現在のIANAレジストリルールでは、IETFによる「標準アクション」[RFC5226]が必要です。このドキュメントはその要件を満たしています。関連するIEC仕様はIETFコミュニティでは利用できないため、このRFCでは、適用されるセキュリティの考慮事項を完全に説明することはできません。したがって、実装者はIEC仕様内のセキュリティ分析に依存する必要があります。ここには2つの異なる標準開発組織が関与しており、グループキー管理は本質的に複雑であるため、一部のセキュリティ問題が特定されていない可能性があるため、組み合わせた仕様セットのセキュリティをさらに分析することをお勧めします。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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
AES Advanced Encryption Standard
GCKS Group Controller/Key Server
GCKSグループコントローラー/キーサーバー
GDOI Group Domain of Interpretation
GDOIグループの解釈のドメイン
GM Group Member
GMグループメンバー
GOOSE Generic Object Oriented Substation Events
GOOSE Generic Object Oriented Substationイベント
KD Key Download
KDキーのダウンロード
KEK Key Encryption Key
ケーキの暗号化とは何ですか？
MAC Message Authentication Code
MACメッセージ認証コード
SA Security Association
さ せくりｔｙ あっそしあちおん
SPI Security Parameter Index
SPIセキュリティパラメータインデックス
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）ペイロードは、特定のIEC 62351トラフィックセレクターのグループコントローラー/キーサーバー（GCKS）によって定義されたポリシーを記述するために使用されます。キーダウンロード（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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 1: RFC 6407 Identification Payload
図1：RFC 6407識別ペイロード
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タイプ名ID_OID（値13）が定義されており、Distinguished Encoding Rules（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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 2: ID_OID Identification Data
図2：ID_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 [ITU-T-X.690]を使用してエンコードされたASN.1 ObjectIdentifier。
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フィールドによって記述されます。 RFC 6407から複製された図3に示すように、各プロトコル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 ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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- 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_PROTO_IEC_61850のプロトコルID名（値3）は、IEC 61850ポリシーを配布する目的でこのメモで定義されています。 GDOI_PROTO_IEC_61850 SA TEKには、OIDと（オプションで）OID固有のペイロードが含まれ、ネットワークトラフィックのセレクターを一緒に定義します。セレクタフィールドの後には、指定されたトラフィックをどのように保護するかを示すセキュリティポリシーフィールドが続きます。 GDOI_PROTO_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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 Auth Alg（2 octets）-認証アルゴリズム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に関連付けられた0個以上の属性が含まれます。セクション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固有のペイロードにより、ネットワークトラフィックのセレクターが定義されます。それらは、GMが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のセットを受信するすべての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]で定義されており、実装が必須であると定義されている1つ以上のアルゴリズムの要件を含みます。
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。ガロアメッセージ認証コード（GMAC）モード[SP.800-38D]で128ビットのキーサイズのAES [FIPS197]を使用することを指定します。
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。ガロアメッセージ認証コード（GMAC）モード[SP.800-38D]で256ビットの鍵サイズのAES [FIPS197]を使用することを指定します。
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]で定義されており、実装が必須であると定義されている1つ以上のアルゴリズムの要件を含みます。
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ビットの鍵サイズを指定します。この暗号化アルゴリズムは認証を提供せず、NONE認証アルゴリズムとともに使用してはなりません（MUST NOT）。
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]を使用することを指定します。この暗号化アルゴリズムは認証を提供せず、NONE認証アルゴリズムとともに使用してはなりません（MUST NOT）。
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。ガロア/カウンターモード（GCM）モード[SP.800-38D]でのAES [FIPS197]の使用を128ビットの鍵サイズで指定します。この暗号化アルゴリズムは認証を提供し、NONE認証アルゴリズムとともに使用されます。
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。ガロア/カウンターモード（GCM）モード[SP.800-38D]でのAES [FIPS197]の使用を256ビットの鍵サイズで指定します。この暗号化アルゴリズムは認証を提供し、NONE認証アルゴリズムとともに使用されます。
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アクティベーション時間遅延（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.
このActivation Time Delay属性はこのSAのみに適用され、GROUPKEY-PULLまたはGROUPKEY-PUSH交換で使用される場合があります。 RFC 6407は、グループ関連ポリシー（GAP）ペイロードのACTIVATION_TIME_DELAY属性についても説明しています。これは、すべてのセキュリティアソシエーションに適用され、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_PROTO_IEC_61850 SA TEKのSPIは、キー識別子（KeyID）として表されます。 SPIサイズは4オクテットです。 SPIは、実装によって選択された任意の方法を使用して、GCKSによって一方的に選択されます。ただし、実装では、特定のグループで現在使用されている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キーID）を保持しています。 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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キーIDに関連付けられたキー情報が含まれていますが、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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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: o HMAC-SHA256-128, HMAC-SHA256. The value is 32 octets.
（Auth Algフィールドで配布される）IEC 61850認証アルゴリズムに関連付けられたキーは、TEK_INTEGRITY_KEY属性として配布する必要があります。属性の値は、SA TEKで配布されるキーのタイプに従って解釈されます：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キーで、残りの4オクテットはノンスのソルト値として使用されます。
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キーで、残りの4オクテットはノンスのソルト値として使用されます。
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:
（Enc Alg SA TEKフィールドで配布される）IEC 61850機密性アルゴリズムに関連付けられたキーは、TEK_ALGORITHM_KEY属性として配布する必要があります。属性の値は、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キーで、残りの4オクテットはノンスのソルト値として使用されます。
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キーで、残りの4オクテットはノンスのソルト値として使用されます。
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 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セキュリティサービスのオプションプロパティです。ただし、暗号化を使用する場合は、AES-GCM-128などの認証済み暗号化アルゴリズムを使用するか、HMAC-SHA-256などの特定の認証アルゴリズムを使用して、認証も提供する必要があります。認証アルゴリズムをNONEに設定するが、機密性アルゴリズムを認証を含まないアルゴリズムに設定する（つまり、「IEC 62351-9機密性の値」レジストリの「Authenticated Encryption」列で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セキュリティサービスのオプションのセキュリティプロパティです。機密性アルゴリズムIDは、IEC 61850メッセージがパブリックネットワークリンクを通過することが予想され、別のレベルの暗号化（暗号化された仮想プライベートネットワークなど）によって保護されていない場合に、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 認証アルゴリズムと機密性アルゴリズムの両方をNONEに設定することは可能ですが、お勧めできません。トラフィックが段階的に保護されていて、一部のトラフィックがまだ保護するようにスケジュールされていない移行期間中に、このようなポリシーの設定が必要になる場合があります。または、一部のパケットフローのサイトセキュリティポリシーでは、プライベートネットワーク上のパケットデータを検査してから、パブリックネットワークに配信する前にネットワーク層の暗号化を行う必要があります。
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 認証アルゴリズムをNONEに設定するが、機密性アルゴリズムを認証を含まないアルゴリズムに設定することは安全ではなく、実行してはならない（MUST NOT）。
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].
「Group Domain of Interpretation（GDOI）Payloads」レジストリ[GDOI-REG]が以下のように更新されました。 「エキスパートレビュー」、「予約済み」、および「私的使用」という用語は、[RFC5226]で定義されているとおりに使用されます。
o GDOI_PROTO_IEC_61850 (value 3) has been added to the "SA TEK Payload Values - Protocol-ID" registry.
o GDOI_PROTO_IEC_61850（値3）が「SA TEK Payload Values-Protocol-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
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
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
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ペイロード用に新しい「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
[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] International Electrotechnical Commission、 "Power systems management and associated information exchange-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>.
[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、「RFCで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、「The Group Domain of Interpretation」、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]米国国立標準技術研究所、「Secure Hash Standard」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年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]国立標準技術研究所、「Advanced Encryption Standard（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、「Group Domain of Interpretation（GDOI）Payloads」、<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] International Electrotechnical Commission、 "Communication network and systems for power utility Automation-Part 8-1：Specific Communication Service Mapping（SCSM）-Mappings to MMS（ISO 9506-1 and 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] International Electrotechnical Commission、 "Communication network and systems for power utility Automation-Part 9-2：Specific Communication Service Mapping（SCSM）-Sampled values over ISO / IEC 8802-3"、IEC 61850- 2011年9月2日。
[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] International Electrotechnical Commission、 "Communication network and systems for power utility Automation-Part 90-5：Use of IEC 61850 to transfer synchrophoror information by IEEE C37.118"、IEC TR 62351- 2012年5月90-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-TX.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-TX.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勧告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：Keyed-Hashing for Message Authentication」、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 Special Publication 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] Dworkin、M。、「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>.
[SP.800-38D] Dworkin、M。、「Block Cipher Modes of Operation：Galois / Counter Mode（GCM）and GMAC」、NIST Special Publication 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].
Intelligent Electronic Device（IED）はGROUPKEY-PULL交換を開始し、61850_UDP_ADDR_GOOSE（[IEC-61850-9-2]で定義されているOID = 1.2.840.10070.61850.8.1.2）およびIPマルチキャストアドレス233.252のキーとセキュリティポリシーを要求します。 [IEC-61850-9-2]で指定されているようにエンコードされた0.1。
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> ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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.
キーサーバーは、2番目のGROUPKEY-PULLメッセージ内の2つのGDOI_PROTO_IEC_61850プロトコル固有のTEKペイロードを含む次のSA TEKペイロードで応答します。最初のものはすぐにアクティブ化され、残りのライフタイムは3600秒（0x0E10）です。 2番目のライフタイムは12時間（0xA8C0）であり、3300秒（0x0CE4）でアクティブ化する必要があります。これにより、2つのSAが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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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は、3番目のGROUPKEY-PULLメッセージでこのポリシーを使用する能力があり、喜んでそれを受け入れることを認めます。それに応じて、KSはKDペイロードを要求側のIEDに送信します。これで、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 !
! !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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固有のペイロードは宛先アドレスを定義し、通常、その宛先アドレスへの送信者は1人です。
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）形式（値が2オクテット未満であると定義されている場合に便利です）またはタイプ/長さ/値（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 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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）の場合、このフィールドはAttribute Lengthフィールドで定義された可変長です。 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は、公開プロセス中にドキュメントシェパードとして貴重なガイダンスを提供しました。著者は、文書の発行を後援するという彼女の同意について、キャスリーン・モリアーティに感謝しています。
Authors' Addresses
著者のアドレス
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 United States of America
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
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
Herb Falk SISCO 6605 19-1 / 2 Mile Road Sterling Heights、MI 48314アメリカ合衆国
Phone: +1 586 254 0020 x105
Email: herb@sisconet.com