[要約] RFC 4535は、グループセキュアアソシエーションキーマネジメントプロトコル（GSAKMP）に関するものであり、グループセキュリティアソシエーションの鍵管理を提供することを目的としています。
Network Working Group H. Harney
Request for Comments: 4535 U. Meth
Category: Standards Track A. Colegrove
SPARTA, Inc.
G. Gross
IdentAware
June 2006
GSAKMP: Group Secure Association Key Management Protocol
GSAKMP：グループセキュアアソシエーションキー管理プロトコル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys.
このドキュメントは、Group Secure Association Key Management Protocol（GSAKMP）を指定します。GSAKMPは、ネットワーク上で暗号化グループを作成および管理するためのセキュリティフレームワークを提供します。グループポリシーを広め、ユーザーを認証するメカニズム、グループの確立と回復中のアクセス制御決定を実行するためのルール、グループメンバーの妥協から回復する能力、グループセキュリティ機能の委任、およびグループを破壊する能力を提供します。また、グループキーも生成します。
Table of Contents
目次
1. Introduction ....................................................7
1.1. GSAKMP Overview ............................................7
1.2. Document Organization ......................................9
2. Terminology .....................................................9
3. Security Considerations ........................................12
3.1. Security Assumptions ......................................12
3.2. Related Protocols .........................................13
3.2.1. ISAKMP .............................................13
3.2.2. FIPS Pub 196 .......................................13
3.2.3. LKH ................................................13
3.2.4. Diffie-Hellman .....................................14
3.3. Denial of Service (DoS) Attack ............................14
3.4. Rekey Availability ........................................14
3.5. Proof of Trust Hierarchy ..................................15
4. Architecture ...................................................15
4.1. Trust Model ...............................................15
4.1.1. Components .........................................15
4.1.2. GO .................................................16
4.1.3. GC/KS ..............................................16
4.1.4. Subordinate GC/KS ..................................17
4.1.5. GM .................................................17
4.1.6. Assumptions ........................................18
4.2. Rule-Based Security Policy ................................18
4.2.1. Access Control .....................................19
4.2.2. Authorizations for Security-Relevant Actions .......20
4.3. Distributed Operation .....................................20
4.4. Concept of Operation ......................................22
4.4.1. Assumptions ........................................22
4.4.2. Creation of a Policy Token .........................22
4.4.3. Creation of a Group ................................23
4.4.4. Discovery of GC/KS .................................24
4.4.5. GC/KS Registration Policy Enforcement ..............24
4.4.6. GM Registration Policy Enforcement .................24
4.4.7. Autonomous Distributed GSAKMP Operations ...........24
5. Group Life Cycle ...............................................27
5.1. Group Definition ..........................................27
5.2. Group Establishment .......................................27
5.2.1. Standard Group Establishment .......................28
5.2.1.1. Request to Join ...........................30
5.2.1.2. Key Download ..............................31
5.2.1.3. Request to Join Error .....................33
5.2.1.4. Key Download - Ack/Failure ................34
5.2.1.5. Lack of Ack ...............................35
5.2.2. Cookies: Group Establishment with Denial of
Service Protection .................................36
5.2.3. Group Establishment for Receive-Only Members .......39
5.3. Group Maintenance .........................................39
5.3.1. Group Management ...................................39
5.3.1.1. Rekey Events ..............................39
5.3.1.2. Policy Updates ............................40
5.3.1.3. Group Destruction .........................40
5.3.2. Leaving a Group ....................................41
5.3.2.1. Eviction ..................................41
5.3.2.2. Voluntary Departure without Notice ........41
5.3.2.3. De-Registration ...........................41
5.3.2.3.1. Request to Depart ..............41
5.3.2.3.2. Departure_Response .............43
5.3.2.3.3. Departure_ACK ..................44
6. Security Suite .................................................45
6.1. Assumptions ...............................................45
6.2. Definition Suite 1 ........................................45
7. GSAKMP Payload Structure .......................................47
7.1. GSAKMP Header .............................................47
7.1.1. GSAKMP Header Structure ............................47
7.1.1.1. GroupID Structure .........................51
7.1.1.1.1. UTF-8 ..........................51
7.1.1.1.2. Octet String ...................52
7.1.1.1.3. IPv4 Group Identifier ..........52
7.1.1.1.4. IPv6 Group Identifier ..........53
7.1.2. GSAKMP Header Processing ...........................53
7.2. Generic Payload Header ....................................55
7.2.1. Generic Payload Header Structure ...................55
7.2.2. Generic Payload Header Processing ..................56
7.3. Policy Token Payload ......................................56
7.3.1. Policy Token Payload Structure .....................56
7.3.2. Policy Token Payload Processing ....................57
7.4. Key Download Payload ......................................58
7.4.1. Key Download Payload Structure .....................58
7.4.1.1. Key Datum Structure .......................61
7.4.1.2. Rekey Array Structure .....................63
7.4.2. Key Download Payload Processing ....................63
7.5. Rekey Event Payload .......................................64
7.5.1. Rekey Event Payload Structure ......................64
7.5.1.1. Rekey Event Header Structure .............66
7.5.1.2. Rekey Event Data Structure ...............67
7.5.1.2.1. Key Package Structure ..........68
7.5.2. Rekey Event Payload Processing .....................69
7.6. Identification Payload ....................................71
7.6.1. Identification Payload Structure ...................71
7.6.1.1. ID_U_NAME Structure .......................74
7.6.2. Identification Payload Processing ..................74
7.6.2.1. ID_U_NAME Processing ......................75
7.7. Certificate Payload .......................................75
7.7.1. Certificate Payload Structure ......................75
7.7.2. Certificate Payload Processing .....................77
7.8. Signature Payload .........................................78
7.8.1. Signature Payload Structure ........................78
7.8.2. Signature Payload Processing .......................80
7.9. Notification Payload ......................................81
7.9.1. Notification Payload Structure .....................81
7.9.1.1. Notification Data - Acknowledgement
(ACK) Payload Type ........................83
7.9.1.2. Notification Data -
Cookie_Required and Cookie Payload Type ...83
7.9.1.3. Notification Data - Mechanism
Choices Payload Type ......................84
7.9.1.4. Notification Data - IPv4 and IPv6
Value Payload Types .......................85
7.9.2. Notification Payload Processing ....................85
7.10. Vendor ID Payload ........................................86
7.10.1. Vendor ID Payload Structure .......................86
7.10.2. Vendor ID Payload Processing ......................87
7.11. Key Creation Payload .....................................88
7.11.1. Key Creation Payload Structure ....................88
7.11.2. Key Creation Payload Processing ...................89
7.12. Nonce Payload ............................................90
7.12.1. Nonce Payload Structure ...........................90
7.12.2. Nonce Payload Processing ..........................91
8. GSAKMP State Diagram ...........................................92
9. IANA Considerations ............................................95
9.1. IANA Port Number Assignment ...............................95
9.2. Initial IANA Registry Contents ............................95
10. Acknowledgements ..............................................96
11. References ....................................................97
11.1. Normative References .....................................97
11.2. Informative References ...................................98
Appendix A. LKH Information ......................................100
A.1. LKH Overview .............................................100
A.2. LKH and GSAKMP ...........................................101
A.3. LKH Examples .............................................102
A.3.1. LKH Key Download Example ..........................102
A.3.2. LKH Rekey Event Example ..........................103
List of Figures
図のリスト
1 GSAKMP Ladder Diagram .........................................28
2 GSAKMP Ladder Diagram with Cookies ............................37
3 GSAKMP Header Format ..........................................47
4 GroupID UTF-8 Format ..........................................51
5 GroupID Octet String Format ...................................52
6 GroupID IPv4 Format ...........................................52
7 GroupID IPv6 Format ...........................................53
8 Generic Payload Header ........................................55
9 Policy Token Payload Format ...................................56
10 Key Download Payload Format ...................................58
11 Key Download Data Item Format .................................59
12 Key Datum Format ..............................................61
13 Rekey Array Structure Format ..................................63
14 Rekey Event Payload Format ....................................64
15 Rekey Event Header Format .....................................66
16 Rekey Event Data Format .......................................68
17 Key Package Format ............................................68
18 Identification Payload Format .................................72
19 Unencoded Name (ID-U-NAME) Format .............................74
20 Certificate Payload Format ....................................76
21 Signature Payload Format ......................................78
22 Notification Payload Format ...................................81
23 Notification Data - Acknowledge Payload Type Format ...........83
24 Notification Data - Mechanism Choices Payload Type Format......84
25 Vendor ID Payload Format ......................................86
26 Key Creation Payload Format ...................................88
27 Nonce Payload Format ..........................................90
28 GSAKMP State Diagram ..........................................92
29 LKH Tree .....................................................100
30 GSAKMP LKH Tree ..............................................101
List of Tables
テーブルのリスト
1 Request to Join (RTJ) Message Definition ......................30
2 Key Download (KeyDL) Message Definition .......................31
3 Request to Join Error (RTJ-Err) Message Definition ............33
4 Key Download - Ack/Failure (KeyDL-A/F) Message Definition .....34
5 Lack of Ack (LOA) Message Definition ..........................35
6 Cookie Download Message Definition ............................37
7 Rekey Event Message Definition ................................40
8 Request_to_Depart (RTD) Message Definition ....................42
9 Departure_Response (DR) Message Definition ....................43
10 Departure_ACK (DA) Message Definition .........................44
11 Group Identification Types ....................................48
12 Payload Types .................................................49
13 Exchange Types ................................................49
14 Policy Token Types ............................................57
15 Key Download Data Item Types ..................................60
16 Cryptographic Key Types .......................................62
17 Rekey Event Types .............................................66
18 Identification Classification .................................72
19 Identification Types ..........................................73
20 Certificate Payload Types .....................................77
21 Signature Types ...............................................79
22 Notification Types ............................................82
23 Acknowledgement Types .........................................83
24 Mechanism Types ...............................................84
25 Nonce Hash Types ..............................................85
26 Types Of Key Creation Information .............................89
27 Nonce Types ...................................................91
28 GSAKMP States .................................................93
29 State Transition Events .......................................94
GSAKMP provides policy distribution, policy enforcement, key distribution, and key management for cryptographic groups. Cryptographic groups all share a common key (or set of keys) for data processing. These keys all support a system-level security policy so that the cryptographic group can be trusted to perform security-relevant services.
GSAKMPは、暗号化グループの政策分布、政策執行、主要な分配、および主要な管理を提供します。暗号化グループはすべて、データ処理の共通キー（またはキーのセット）を共有しています。これらのキーはすべて、システムレベルのセキュリティポリシーをサポートしているため、暗号化グループがセキュリティ関連サービスを実行することを信頼できるようにします。
The ability of a group of entities to perform security services requires that a Group Secure Association (GSA) be established. A GSA ensures that there is a common "group-level" definition of security policy and enforcement of that policy. The distribution of cryptographic keys is a mechanism utilizing the group-level policy enforcements.
エンティティのグループがセキュリティサービスを実行する能力は、グループセキュアーアソシエーション（GSA）を確立する必要があります。GSAは、セキュリティポリシーとそのポリシーの執行に一般的な「グループレベル」の定義があることを保証します。暗号化キーの分布は、グループレベルのポリシー執行を利用するメカニズムです。
Protecting group information requires the definition of a security policy and the enforcement of that policy by all participating parties. Controlling dissemination of cryptographic key is the primary mechanism to enforce the access control policy. It is the primary purpose of GSAKMP to generate and disseminate a group key in a secure fashion.
グループ情報を保護するには、セキュリティポリシーの定義と、すべての参加当事者によるそのポリシーの執行が必要です。暗号化キーの普及の制御は、アクセス制御ポリシーを実施するための主要なメカニズムです。GSAKMPの主な目的は、安全な方法でグループキーを生成し、広めることです。
GSAKMP separates group security management functions and responsibilities into three major roles:1) Group Owner, 2) Group Controller Key Server, and 3) Group Member. The Group Owner is responsible for creating the security policy rules for a group and expressing these in the policy token. The Group Controller Key Server (GC/KS) is responsible for creating and maintaining the keys and enforcing the group policy by granting access to potential Group Members (GMs) in accordance with the policy token. To enforce a group's policy, the potential Group Members need to have knowledge of the access control policy for the group, an unambiguous identification of any party downloading keys to them, and verifiable chains of authority for key download. In other words, the Group Members need to know who potentially will be in the group and to verify that the key disseminator is authorized to act in that capacity.
GSAKMPは、グループセキュリティ管理機能と責任を3つの主要な役割に分けます：1）グループ所有者、2）グループコントローラーキーサーバー、3）グループメンバー。グループの所有者は、グループのセキュリティポリシールールを作成し、ポリシートークンでこれらを表現する責任があります。グループコントローラーキーサーバー（GC/KS）は、ポリシートークンに従って潜在的なグループメンバー（GMS）へのアクセスを許可することにより、キーの作成と維持とグループポリシーの実施を担当します。グループのポリシーを実施するには、潜在的なグループメンバーは、グループのアクセス制御ポリシーの知識、鍵をダウンロードする鍵の明確な識別、およびキーダウンロードのための検証可能な権限チェーンを持つ必要があります。言い換えれば、グループメンバーは、グループ内に誰がいるかを知り、主要な普及者がその能力で行動することを許可されていることを確認する必要があります。
In order to establish a Group Secure Association (GSA) to support these activities, the identity of each party in the process MUST be unambiguously asserted and authenticated. It MUST also be verified that each party is authorized, as defined by the policy token, to function in his role in the protocol (e.g., GM or GC/KS).
これらの活動をサポートするためにグループセキュアアソシエーション（GSA）を設立するために、プロセスにおける各当事者の身元は明確に主張され、認証されなければなりません。また、ポリシートークンで定義されているように、各当事者がプロトコル（GMまたはGC/KSなど）での役割で機能することを許可されていることを確認する必要があります。
The security features of the establishment protocol for the GSA include
GSAのための設立プロトコルのセキュリティ機能には
- Group policy identification
- グループポリシーの識別
- Group policy dissemination
- グループポリシーの普及
- GM to GC/KS SA establishment to protect data
- データを保護するためのGMからGC/KS SAの確立
- Access control checking
- アクセス制御チェック
GSAKMP provides mechanisms for cryptographic group creation and management. Other protocols may be used in conjunction with GSAKMP to allow various applications to create functional groups according to their application-specific requirements. For example, in a small-scale video conference, the organizer might use a session invitation protocol like SIP [RFC3261] to transmit information about the time of the conference, the address of the session, and the formats to be used. For a large-scale video transmission, the organizer might use a multicast announcement protocol like SAP [RFC2974].
GSAKMPは、暗号化グループの作成と管理のメカニズムを提供します。他のプロトコルをGSAKMPと組み合わせて使用して、さまざまなアプリケーションがアプリケーション固有の要件に従って機能グループを作成できるようにすることができます。たとえば、小規模ビデオ会議では、主催者はSIP [RFC3261]などのセッション招待プロトコルを使用して、会議の時間、セッションのアドレス、および使用する形式に関する情報を送信する場合があります。大規模なビデオトランスミッションの場合、オーガナイザーはSAP [RFC2974]のようなマルチキャストアナウンスプロトコルを使用する場合があります。
This document describes a useful default set of security algorithms and configurations, Security Suite 1. This suite allows an entire set of algorithms and settings to be described to prospective group members in a concise manner. Other security suites MAY be defined as needed and MAY be disseminated during the out-of-band announcement of a group.
このドキュメントでは、セキュリティアルゴリズムと構成の有用なデフォルトセットであるセキュリティスイート1について説明します。このスイートでは、アルゴリズムと設定のセット全体を、将来のグループメンバーに簡潔に説明できます。他のセキュリティスイートは、必要に応じて定義される場合があり、グループの帯域外発表中に普及する場合があります。
Distributed architectures support large-scale cryptographic groups. Secure distributed architectures require authorized delegation of GSA actions to network resources. The fully specified policy token is the mechanism to facilitate this authorization. Transmission of this policy token to all joining GMs allows GSAKMP to securely support distributed architectures and multiple data sources.
分散アーキテクチャは、大規模な暗号化グループをサポートしています。安全な分散アーキテクチャには、ネットワークリソースへのGSAアクションの承認された委任が必要です。完全に指定されたポリシートークンは、この承認を促進するメカニズムです。このポリシートークンのすべてのGMSへの送信により、GSAKMPは分散アーキテクチャと複数のデータソースを安全にサポートできます。
Many-to-many group communications require multiple data sources. Multiple data sources are supported because the inclusion of a policy token and policy payloads allow group members to review the group access control and authorization parameters. This member review process gives each member (each potential source of data) the ability to determine if the group provides adequate protection for member data.
多くのグループコミュニケーションには、複数のデータソースが必要です。ポリシートークンとポリシーのペイロードを含めることで、グループメンバーがグループアクセス制御と承認パラメーターを確認できるため、複数のデータソースがサポートされています。このメンバーレビュープロセスにより、各メンバー（各潜在的なデータソース）が、グループがメンバーデータに適切な保護を提供するかどうかを判断する機能を提供します。
The remainder of this document is organized as follows:Section 2 presents the terminology and concepts used to present the requirements of this protocol. Section 3 outlines the security considerations with respect to GSAKMP. Section 4 defines the architecture of GSAKMP. Section 5 describes the group management life cycle. Section 6 describes the Security Suite Definition. Section 7 presents the message types and formats used during each phase of the life cycle. Section 8 defines the state diagram for the protocol.
このドキュメントの残りの部分は次のように整理されています。セクション2は、このプロトコルの要件を提示するために使用される用語と概念を示しています。セクション3では、GSAKMPに関するセキュリティ上の考慮事項の概要を説明します。セクション4では、GSAKMPのアーキテクチャを定義しています。セクション5では、グループ管理のライフサイクルについて説明します。セクション6では、セキュリティスイートの定義について説明します。セクション7では、ライフサイクルの各フェーズで使用されるメッセージの種類と形式を示します。セクション8では、プロトコルの状態図を定義します。
The following terminology is used throughout this document.
このドキュメント全体で次の用語が使用されています。
Requirements Terminology: Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
要件の用語：キーワード「必須」、「必要はない」、「必須」、「は」、「そうは思わない」、「そうでない」、「可能な」、このドキュメントに表示されることは、[RFC2119]で説明されているように解釈されるべきです。
Certificate: A data structure used to verifiably bind an identity to a cryptographic key (e.g., X.509v3).
証明書：アイデンティティを暗号化キー（例：x.509v3）に検証するために使用されるデータ構造。
Compromise Recovery: The act of recovering a secure operating state after detecting that a group member cannot be trusted. This can be accomplished by rekey.
妥協回復：グループメンバーが信頼できないことを検出した後、安全な動作状態を回復する行為。これはRekeyによって達成できます。
Cryptographic Group: A set of entities sharing or desiring to share a GSA.
暗号化グループ：GSAを共有または共有したいエンティティのセット。
Group Controller Key Server (GC/KS): A group member with authority to perform critical protocol actions including creating and distributing keys and building and maintaining the rekey structures. As the group evolves, it MAY become desirable to have multiple controllers perform these functions.
グループコントローラーキーサーバー（GC/ks）：キーの作成と配布、再キー構造の構築、維持など、重要なプロトコルアクションを実行する権限を持つグループメンバー。グループが進化するにつれて、複数のコントローラーにこれらの機能を実行させることが望ましい場合があります。
Group Member (GM): A Group Member is any entity with access to the group keys. Regardless of how a member becomes a part of the group or how the group is structured, GMs will perform the following actions:
グループメンバー（GM）：グループメンバーは、グループキーにアクセスできるエンティティです。メンバーがどのようにグループの一部になるか、またはグループがどのように構成されているかに関係なく、GMSは次のアクションを実行します。
- Authenticate and validate the identities and the authorizations of entities performing security-relevant actions
- セキュリティ関連のアクションを実行するエンティティのアイデンティティと承認を認証および検証する
- Accept group keys from the GC/KS
- GC/ksのグループキーを受け入れます
- Request group keys from the GC/KS
- GC/ksからグループキーをリクエストします
- Enforce the cooperative group policies as stated in the group policy token
- グループポリシートークンに記載されているように、協同組合グループのポリシーを実施する
- Perform peer review of key management actions
- 主要な管理アクションのピアレビューを実行します
- Manage local key
- ローカルキーを管理します
Group Owner (GO): A Group Owner is the entity authorized for generating and modifying an authenticatable policy token for the group, and notifying the GC/KS to start the group.
グループ所有者（GO）：グループ所有者は、グループの認証可能なポリシートークンを生成および変更し、GC/KSにグループを開始することを許可されたエンティティです。
Group Policy: The Group Policy completely describes the protection mechanisms and security-relevant behaviors of the group. This policy MUST be commonly understood and enforced by the group for coherent secure operations.
グループポリシー：グループポリシーは、グループの保護メカニズムとセキュリティ関連行動を完全に説明しています。このポリシーは、一貫した安全な運用のためにグループによって一般的に理解され、施行されなければなりません。
Group Secure Association (GSA): A GSA is a logical association of users or hosts that share cryptographic key(s). This group may be established to support associations between applications or communication protocols.
Group Secure Association（GSA）：GSAは、暗号化キーを共有するユーザーまたはホストの論理的な関連付けです。このグループは、アプリケーションまたは通信プロトコル間の関連性をサポートするために確立できます。
Group Traffic Protection Key (GTPK): The key or keys created for protecting the group data.
グループトラフィック保護キー（GTPK）：グループデータを保護するために作成されたキーまたはキー。
Key Datum: A single key and its associated attributes for its usage.
キーデータム：単一のキーとその使用に関する関連属性。
Key Encryption Key (KEK): Key used in an encryption mechanism for wrapping another key.
キー暗号化キー（KEK）：別のキーをラッピングするための暗号化メカニズムで使用されるキー。
Key Handle: The identifier of a particular instance or version of a key.
キーハンドル：特定のインスタンスまたはキーのバージョンの識別子。
Key ID: The identifier for a key that MUST stay static throughout the life cycle of this key.
キーID：このキーのライフサイクルを通して静的にとどまる必要があるキーの識別子。
Key Package: Type/Length/Data format containing a Key Datum.
キーパッケージ：キーデータムを含むタイプ/長さ/データ形式。
Logical Key Hierarchy (LKH) Array: The group of keys created to facilitate the LKH compromise recovery methodology.
論理キー階層（LKH）アレイ：LKH妥協回復方法を促進するために作成されたキーのグループ。
Policy Token (PT): The policy token is a data structure used to disseminate group policy and the mechanisms to enforce it. The policy token is issued and signed by an authorized Group Owner. Each member of the group MUST verify the token, meet the group join policy, and enforce the policy of the group (e.g., encrypt application data with a specific algorithm). The group policy token will contain a variety of information including:
ポリシートークン（PT）：ポリシートークンは、グループポリシーとそれを実施するメカニズムを広めるために使用されるデータ構造です。ポリシートークンは、認可されたグループ所有者によって発行および署名されます。グループの各メンバーは、トークンを検証し、グループに参加するポリシーを満たし、グループのポリシーを実施する必要があります（たとえば、特定のアルゴリズムを使用してアプリケーションデータを暗号化します）。グループポリシートークンには、次のようなさまざまな情報が含まれます。
- GSAKMP protocol version
- GSAKMPプロトコルバージョン
- Key creation method
- キー作成方法
- Key dissemination policy
- 主要な普及ポリシー
- Access control policy
- アクセス制御ポリシー
- Group authorization policy
- グループ認証ポリシー
- Compromise recovery policy
- 妥協回復ポリシー
- Data protection mechanisms
- データ保護メカニズム
Rekey: The act of changing keys within a group as defined by policy.
Rekey：ポリシーで定義されているグループ内でキーを変更する行為。
Rekey Array: The construct that contains all the rekey information for a particular member.
Rekey Array：特定のメンバーのすべてのReke情報を含む構成。
Rekey Key: The KEK used to encrypt keys for a subset of the group.
Rekey Key：Kekは、グループのサブセットのキーを暗号化するために使用されていました。
Subordinate Group Controller Key Server (S-GC/KS): Any group member having the appropriate processing and trust characteristics, as defined in the group policy, that has the potential to act as a S-GC/KS. This will allow the group processing and communication requirements to be distributed equitably throughout the network (e.g., distribute group key). The optional use of GSAKMP with Subordinate Group Controller Key Servers will be documented in a separate paper.
下位グループコントローラーキーサーバー（S-GC/ks）：S-GC/ksとして機能する可能性のあるグループポリシーで定義されている適切な処理および信頼の特性を有するグループメンバー。これにより、グループの処理と通信の要件をネットワーク全体に公平に分配できます（たとえば、グループキーを分散します）。下位グループコントローラーキーサーバーを使用したGSAKMPのオプションの使用は、別の論文に文書化されます。
Wrapping KeyID: The Key ID of the key used to wrap a Key Package.
Lapping KeyID：キーパッケージをラップするために使用されるキーのキーID。
Wrapping Key Handle: The key handle of the key used to wrap the Key Package.
キーハンドルのラッピング：キーパッケージをラップするために使用されるキーのキーハンドル。
In addition to the specification of GSAKMP itself, the security of an implemented GSAKMP system is affected by supporting factors. These are discussed here.
GSAKMP自体の仕様に加えて、実装されたGSAKMPシステムのセキュリティは、サポート要因の影響を受けます。これらについてはここで説明します。
The following assumptions are made as the basis for the security discussion:
次の仮定は、セキュリティディスカッションの基礎として行われます。
1. GSAKMP assumes its supporting platform can provide the process and data separation services at the appropriate assurance level to support its groups.
1. GSAKMPは、サポートプラットフォームが適切な保証レベルでプロセスおよびデータ分離サービスを提供して、グループをサポートできると想定しています。
2. The key generation function of the cryptographic engine will only generate strong keys.
2. 暗号化エンジンのキー生成関数は、強力なキーのみを生成します。
3. The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source [RFC4086].
3. このプロトコルのセキュリティは、ランダムに選択されたパラメーターのランダム性に大きく依存しています。これらは、強力なランダムまたは適切に播種された擬似ランダム源[RFC4086]によって生成される必要があります。
4. The security of a group can be affected by the accuracy of the system clock. Therefore, GSAKMP assumes that the system clock is close to correct time. If a GSAKMP host relies on a network time service to set its local clock, then that protocol must be secure against attackers. The maximum allowable clock skew across the group membership is policy configurable, with a default of 5 minutes.
4. グループのセキュリティは、システムクロックの精度によって影響を受ける可能性があります。したがって、GSAKMPは、システムクロックが正しい時間に近いと想定しています。GSAKMPホストがネットワークタイムサービスに依存してローカルクロックを設定する場合、そのプロトコルは攻撃者に対して安全でなければなりません。グループメンバーシップ全体で最大許容時計が歪むのは、5分間のデフォルトで構成可能です。
5. As described in the message processing section, the use of the nonce value used for freshness along with a signature is the mechanism used to foil replay attacks. In any use of nonces, a core requirement is unpredictability of the nonce, from an attacker's viewpoint. The utility of the nonce relies on the inability of an attacker either to reuse old nonces or to predict the nonce value.
5. メッセージ処理セクションで説明されているように、署名とともに鮮度に使用されるノンセ値の使用は、リプレイ攻撃を阻止するために使用されるメカニズムです。Noncesの使用において、コア要件は、攻撃者の観点からのNonCEの予測不可能性です。NonCeの有用性は、攻撃者が古いNoncesを再利用するか、NonCe値を予測できないことに依存しています。
6. GSAKMP does not provide identity protection.
6. GSAKMPはアイデンティティ保護を提供しません。
7. The group's multicast routing infrastructure is not secured by GSAKMP, and therefore it may be possible to create a multicast flooding denial of service attack using the multicast application's data stream. Either an insider (i.e., a rogue GM) or a non-member could direct the multicast routers to spray data at a victim system.
7. グループのマルチキャストルーティングインフラストラクチャはGSAKMPによって保護されていないため、マルチキャストアプリケーションのデータストリームを使用して、マルチキャストの洪水拒否攻撃を作成することが可能です。インサイダー（つまり、不正なGM）または非会員のいずれかが、マルチキャストルーターを被害者システムにスプレーするように指示することができます。
8. The compromise of a S-GC/KS forces the re-registration of all GMs under its control. The GM recognizes this situation by finding the S-GC/KS's certificate on a CRL as supplied by a service such as LDAP.
8. S-GC/KSの妥協により、すべてのGMの再登録が制御されています。GMは、LDAPなどのサービスによって提供されるCRLに関するS-GC/KSの証明書を見つけることにより、この状況を認識します。
9. The compromise of the GO forces termination of the group. The GM recognizes this situation by finding the GO's certificate on a Certificate Revocation List (CRL) as supplied by a service such as LDAP.
9. GO力の妥協案は、グループの終了です。GMは、LDAPなどのサービスが提供する証明書取消リスト（CRL）にGOの証明書を見つけることにより、この状況を認識します。
GSAKMP derives from two (2) existing protocols: ISAKMP [RFC2408] and FIPS Pub 196 [FIPS196]. In accordance with Security Suite 1, GSAKMP implementations MUST support the use of Diffie-Hellman key exchange [DH77] for two-party key creation and MAY use Logical Key Hierarchy (LKH) [RFC2627] for rekey capability. The GSAKMP design was also influenced by the following protocols: [HHMCD01], [RFC2093], [RFC2094], [BMS], and [RFC2412].
GSAKMPは、2つの既存のプロトコル、ISAKMP [RFC2408]とFIPS Pub 196 [FIPS196]に由来しています。セキュリティスイート1に従って、GSAKMPの実装は、2パーティのキー作成のためにDiffie-Hellman Key Exchange [DH77]の使用をサポートする必要があり、再キー機能のために論理キー階層（LKH）[RFC2627]を使用する場合があります。GSAKMPの設計は、[HHMCD01]、[RFC2093]、[RFC2094]、[BMS]、および[RFC2412]の次のプロトコルの影響も受けました。
ISAKMP provides a flexible structure of chained payloads in support of authenticated key exchange and security association management for pairwise communications. GSAKMP builds upon these features to provide policy enforcement features in support of diverse group communications.
ISAKMPは、ペアワイズ通信のための認証されたキーエクスチェンジおよびセキュリティ協会の管理をサポートするために、チェーンズペイロードの柔軟な構造を提供します。GSAKMPは、これらの機能に基づいて、多様なグループコミュニケーションをサポートする政策執行機能を提供します。
FIPS Pub 196 provides a mutual authentication protocol.
FIPS Pub 196は、相互認証プロトコルを提供します。
When group policy dictates that a recovery of the group security is necessary after the discovery of the compromise of a GM, then GSAKMP relies upon a rekey capability (i.e., LKH) to enable group recovery after a compromise [RFC2627]. This is optional since in many instances it may be better to destroy the compromised group and rebuild a secure group.
グループポリシーがGMの妥協の発見後にグループセキュリティの回復が必要であると指示する場合、GSAKMPは妥協後のグループ回復を可能にするためにRekey機能（つまりLKH）に依存します[RFC2627]。多くの場合、妥協したグループを破壊し、安全なグループを再構築する方が良いかもしれないので、これはオプションです。
A Group may rely upon two-party key creation mechanisms, i.e., Diffie-Hellman, to protect sensitive data during download.
グループは、ダウンロード中に機密データを保護するために、2パーティのキー作成メカニズム、つまりDiffie-Hellmanに依存する場合があります。
The information in this section borrows heavily from [IKEv2], as this protocol has already worked through similar issues and GSAKMP is using the same security considerations for its purposes. This section will contain paraphrased sections of [IKEv2] modified for GSAKMP as appropriate.
このセクションの情報は[IKEV2]から大きく借用しています。このプロトコルはすでに同様の問題を通じて機能しており、GSAKMPはその目的で同じセキュリティ上の考慮事項を使用しています。このセクションには、必要に応じてGSAKMP用に変更された[IKEV2]の言い換えられたセクションが含まれています。
The strength of a key derived from a Diffie-Hellman exchange using specific p and g values depends on the inherent strength of the values, the size of the exponent used, and the entropy provided by the random number generator used. A strong random number generator combined with the recommendations from [RFC3526] on Diffie-Hellman exponent size is recommended as sufficient. An implementation should make note of this conservative estimate when establishing policy and negotiating security parameters.
特定のpおよびg値を使用したdiffie-hellman交換から派生したキーの強度は、値の固有の強度、使用される指数のサイズ、および使用される乱数ジェネレーターによって提供されるエントロピーに依存します。Diffie-Hellmanの指数サイズに関する[RFC3526]の推奨事項と組み合わせた強力な乱数ジェネレーターは、十分に推奨されます。実装は、ポリシーを確立し、セキュリティパラメーターを交渉する際に、この保守的な見積もりに注意する必要があります。
Note that these limitations are on the Diffie-Hellman values themselves. There is nothing in GSAKMP that prohibits using stronger values, nor is there anything that will dilute the strength obtained from stronger values. In fact, the extensible framework of GSAKMP encourages the definition of more Security Suites.
これらの制限は、Diffie-Hellmanの価値自体にあることに注意してください。GSAKMPには、より強力な値を使用して禁止することも何もありません。また、より強い値から得られた強度を希釈するものもありません。実際、GSAKMPの拡張可能なフレームワークは、より多くのセキュリティスイートの定義を奨励しています。
It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents MUST NOT be derived from long-lived secrets such as the seed to a pseudo-random generator that is not erased after use.
この交換のdiffie-hellman指数は、使用後に記憶から消去されると想定されています。特に、これらの指数は、使用後に消去されない擬似ランダムジェネレーターの種などの長寿命の秘密から導き出されてはなりません。
This GSAKMP specification addresses the mitigation for a distributed IP spoofing attack (a subset of possible DoS attacks) in Section 5.2.2, "Cookies: Group Establishment with Denial of Service Protection".
このGSAKMP仕様は、セクション5.2.2、「Cookies：サービス保護の拒否を伴うグループ確立」の分散IPスプーフィング攻撃（考えられるDOS攻撃のサブセット）の軽減に対処しています。
In addition to GSAKMP's capability to do rekey operations, GSAKMP MUST also have the capability to make this rekey information highly available to GMs. The necessity of GMs receiving rekey messages requires the use of methods to increase the likelihood of receipt of rekey messages. These methods MAY include multiple transmissions of the rekey message, posting of the rekey message on a bulletin board, etc. Compliant GSAKMP implementations supporting the optional rekey capability MUST support retransmission of rekey messages.
GSAKMPが再キーを行う機能に加えて、GSAKMPには、この再キー情報をGMSが非常に利用できるようにする機能も必要です。GMSのREKEYメッセージを受信する必要性には、Rekeyメッセージの受信の可能性を高めるためのメソッドを使用する必要があります。これらの方法には、Rekeyメッセージの複数の送信、掲示板へのRekeyメッセージの投稿などが含まれる場合があります。オプションのReke機能をサポートする準拠のGSAKMP実装は、Rekeメッセージの再送信をサポートする必要があります。
As defined by [HCM], security group policy MUST be defined in a verifiable manner. GSAKMP anchors its trust in the creator of the group, the GO.
[HCM]で定義されているように、セキュリティグループポリシーは検証可能な方法で定義する必要があります。GSAKMPは、グループの作成者であるGOに信頼を固定しています。
The policy token explicitly defines all the parameters that create a secure verifiable infrastructure. The GSAKMP Policy Token is issued and signed by the GO. The GC/KS will verify it and grant access to GMs only if they meet the rules of the policy token. The new GMs will accept access only if 1) the token verifies, 2) the GC/KS is an authorized disseminator, and 3) the group mechanisms are acceptable for protecting the GMs data.
ポリシートークンは、安全に検証可能なインフラストラクチャを作成するすべてのパラメーターを明示的に定義します。GSAKMPポリシートークンは、外出先で発行および署名されます。GC/KSは、それを検証し、Policyトークンのルールを満たしている場合にのみGMSへのアクセスを許可します。新しいGMは、1）トークンが検証され、2）GC/KSが認定普及である場合にのみアクセスを受け入れます。3）グループメカニズムはGMSデータを保護するために許容されます。
This architecture presents a trust model for GSAKMP and a concept of operations for establishing a trusted distributed infrastructure for group key and policy distribution.
このアーキテクチャは、GSAKMPの信頼モデルと、グループキーおよびポリシー分布のための信頼できる分散インフラストラクチャを確立するための運用の概念を提示します。
GSAKMP conforms to the IETF MSEC architectural concepts as specified in the MSEC Architecture document [RFC3740]. GSAKMP uses the MSEC components to create a trust model for operations that implement the security principles of mutual suspicion and trusted policy creation authorities.
GSAKMPは、MSECアーキテクチャドキュメント[RFC3740]で指定されているように、IETF MSECアーキテクチャの概念に準拠しています。GSAKMPは、MSECコンポーネントを使用して、相互の疑いと信頼できる政策作成当局のセキュリティ原則を実装する運用の信頼モデルを作成します。
The trust model contains four key components:
Trustモデルには4つの重要なコンポーネントが含まれています。
- Group Owner (GO),
- グループ所有者（go）、
- Group Controller Key Server (GC/KS),
- グループコントローラーキーサーバー（GC/ks）、
- Subordinate GC/KS (S-GC/KS), and
- 下位GC/KS（S-GC/KS）、および
- Group Member (GM).
- グループメンバー（GM）。
The goal of the GSAKMP trust model is to derive trust from a common trusted policy creation authority for a group. All security-relevant decisions and actions implemented by GSAKMP are based on information that ultimately is traceable to and verified by the trusted policy creation authority. There are two trusted policy creation authorities for GSAKMP: the GO (policy creation authority) and the PKI root that allows us to verify the GO.
GSAKMP Trustモデルの目標は、グループの共通の信頼された政策作成権限から信頼を導き出すことです。GSAKMPによって実施されたすべてのセキュリティ関連の決定と行動は、最終的に信頼された政策作成当局によって追跡可能で検証された情報に基づいています。GSAKMPには2つの信頼できる政策作成当局があります。GO（政策作成権限）と、GOを検証できるPKIルートです。
The GO is the policy creation authority for the group. The GO has a well-defined identity that is relevant to the group. That identity can be of a person or of a group-trusted component. All potential entities in the group have to recognize the GO as the individual with authority to specify policy for the group.
GOは、グループの政策作成権限です。GOには、グループに関連する明確に定義されたアイデンティティがあります。そのアイデンティティは、人またはグループ信頼されたコンポーネントのものである可能性があります。グループ内のすべての潜在的なエンティティは、グループのポリシーを指定する権限を持つ個人としてのGOを認識しなければなりません。
The policy reflects the protection requirements of the data in a group. Ultimately, the data and the application environment drives the security policy for the group.
ポリシーは、グループ内のデータの保護要件を反映しています。最終的に、データとアプリケーション環境は、グループのセキュリティポリシーを推進します。
The GO has to determine the security rules and mechanisms that are appropriate for the data being protected by the group keys. All this information is captured in a policy token (PT). The GO creates the PT and signs it.
GOは、グループキーによって保護されているデータに適したセキュリティルールとメカニズムを決定する必要があります。このすべての情報は、ポリシートークン（PT）でキャプチャされます。GOはPTを作成し、署名します。
The GC/KS is authorized to perform several functions: key creation, key distribution, rekey, and group membership management.
GC/KSは、キー作成、キーディストリビューション、REKEY、およびグループメンバーシップ管理のいくつかの機能を実行することを許可されています。
As the key creation authority, the GC/KS will create the set of keys for the group. These keys include the Group Traffic Protection Keys (GTPKs) and first-tier rekey keys. There may be second-tier rekey trees if a distributed rekey management structure is required for the group.
主要な創造機関として、GC/KSはグループのキーのセットを作成します。これらのキーには、グループトラフィック保護キー（GTPK）と第1層のRekeyキーが含まれます。グループに分散したReke管理構造が必要な場合、2層のRekeyツリーがある場合があります。
As the key distribution (registration) authority, it has to notify the group of its location for registration services. The GC/KS will have to enforce key access control as part of the key distribution and registration processes.
主要な配布（登録）当局として、登録サービスの場所をグループに通知する必要があります。GC/KSは、キーディストリビューションと登録プロセスの一部としてキーアクセス制御を実施する必要があります。
As the group rekey authority, it performs rekey in order to change the group's GTPK. Change of the GTPK limits the exposure of data encrypted with any single GTPK.
Group Reke Authorityとして、グループのGTPKを変更するためにRekeyを実行します。GTPKの変更により、単一のGTPKで暗号化されたデータの露出が制限されます。
Finally, as the group membership management authority, the GC/KS can manage the group membership (registration, eviction, de-registration, etc.). This may be done in part by using a key tree approach, such as Logical Key Hierarchies (LKH), as an optional approach.
最後に、グループメンバーシップ管理局として、GC/KSはグループメンバーシップ（登録、立ち退き、解体など）を管理できます。これは、オプションのアプローチとして、論理キー階層（LKH）などのキーツリーアプローチを使用して部分的に実行できます。
A subordinate GC/KS is used to distribute the GC/KS functionality across multiple entities. The S-GC/KS will have all the authorities of the GC/KS except one: it will not create the GTPK. It is assumed here that the group will transmit data with a single GTPK at any one time. This GTPK comes from the GC/KS.
下位のGC/KSを使用して、複数のエンティティにGC/KS機能を分布させます。S-GC/KSには、GC/KSのすべての当局が1つを除いて、GTPKを作成しません。ここでは、グループが一度に単一のGTPKでデータを送信すると想定されています。このGTPKはGC/KSから来ています。
Note that relative to the GC/KS, the S-GC/KS is responsible for an additional security check: the S-GC/KS must register as a member with the GC/KS, and during that process it has to verify the authority of the GC/KS.
GC/KSと比較して、S-GC/KSは追加のセキュリティチェックの原因です。S-GC/KSはGC/KSのメンバーとして登録する必要があり、そのプロセス中に権限を検証する必要があります。GC/ksの。
The GM has two jobs: to make sure all security-relevant actions are authorized and to use the group keys properly. During the registration process, the GM will verify that the PT is signed by a recognized GO. In addition, it will verify that the GC/KS or S-GC/KS engaged in the registration process is authorized, as specified in the PT. If rekey and new PTs are distributed to the group, the GM will verify that they are proper and all actions are authorized.
GMには2つのジョブがあります。すべてのセキュリティ関連アクションが承認されていることを確認し、グループキーを適切に使用することです。登録プロセス中、GMはPTが認識されたGOによって署名されていることを確認します。さらに、PTで指定されているように、登録プロセスに従事するGC/KSまたはS-GC/KSが承認されていることが確認されます。Rekeyおよび新しいPTがグループに配布される場合、GMはそれらが適切であり、すべてのアクションが承認されていることを確認します。
The GM is granted access to group data through receipt of the group keys This carries along with it a responsibility to protect the key from unauthorized disclosure.
GMは、グループキーを受信してグループデータへのアクセスを許可されます。これには、不正な開示からキーを保護する責任があります。
GSAKMP does not offer any enforcement mechanisms to control which GMs are multicast speakers at a given moment. This policy and its enforcement depend on the multicast application and its protocols. However, GSAKMP does allow a group to have one of three Group Security Association multicast speaker configurations:
GSAKMPは、特定の瞬間にどのGMがマルチキャストスピーカーであるかを制御するための施行メカニズムを提供しません。このポリシーとその施行は、マルチキャストアプリケーションとそのプロトコルに依存します。ただし、GSAKMPでは、グループが3つのグループセキュリティアソシエーションマルチキャストスピーカー構成のいずれかを持つことができます。
- There is a single GM authorized to be the group's speaker. There is one multicast application SA allocated by the GO in support of that speaker. The PT initializes this multicast application SA and identifies the GM that has been authorized to be speaker. All GMs share a single TPK with that GM speaker. Sequence number checking for anti-replay protection is feasible and enabled by default. This is the default group configuration. GSAKMP implementations MUST support this configuration.
- グループのスピーカーであることが許可された単一のGMがあります。そのスピーカーをサポートするためにGOによって割り当てられたマルチキャストアプリケーションが1つあります。PTは、このマルチキャストアプリケーションSAを初期化し、スピーカーであることが許可されているGMを識別します。すべてのGMは、そのGMスピーカーと単一のTPKを共有しています。アンチレプレイ保護のシーケンス番号チェックは実行可能であり、デフォルトで有効になります。これがデフォルトのグループ構成です。GSAKMPの実装は、この構成をサポートする必要があります。
- The GO authorizes all of the GMs to be group speakers. The GO allocates one multicast application SA in support of these speakers. The PT initializes this multicast application SA and indicates that any GM can be a speaker. All of the GMs share a single GTPK and other SA state information. Consequently, some SA security features such as sequence number checking for anti-replay protection cannot be supported by this configuration. GSAKMP implementations MUST support this group configuration.
- GOは、すべてのGMSがグループスピーカーになることを許可します。GOは、これらのスピーカーをサポートする1つのマルチキャストアプリケーションSAを割り当てます。PTは、このマルチキャストアプリケーションSAを初期化し、GMがスピーカーになる可能性があることを示します。すべてのGMSは、単一のGTPKおよびその他のSA状態情報を共有しています。したがって、この構成では、アンチレプレイ保護のシーケンス番号チェックなどの一部のSAセキュリティ機能をサポートすることはできません。GSAKMPの実装は、このグループ構成をサポートする必要があります。
- The GO authorizes a subset of the GMs to be group speakers (which may be the subset composed of all GMs). The GO allocates a distinct multicast application SA for each of these speakers. The PT identifies the authorized speakers and initializes each of their multicast application Security Associations. The speakers still share a common TPK across their SA, but each speaker has a separate SA state information instance at every peer GM. Consequently, this configuration supports SA security features, such as sequence number checking for anti-replay protection, or source authentication mechanisms that require per-speaker state at the receiver. The drawback of this configuration is that it does not scale to a large number of speakers. GSAKMP implementations MAY support this group configuration.
- GOは、GMSのサブセットがグループスピーカーであることを承認します（これはすべてのGMで構成されるサブセットである可能性があります）。GOは、これらのスピーカーごとに異なるマルチキャストアプリケーションSAを割り当てます。PTは、承認されたスピーカーを識別し、マルチキャストアプリケーションセキュリティ協会のそれぞれを初期化します。スピーカーは依然としてSA全体で共通のTPKを共有していますが、各スピーカーにはすべてのピアGMに別のSA状態情報インスタンスがあります。したがって、この構成は、アンチレプレイ保護のシーケンス番号チェックや、受信者でスピーカーごとの状態を必要とするソース認証メカニズムなど、SAセキュリティ機能をサポートします。この構成の欠点は、多数のスピーカーにスケーリングしないことです。GSAKMP実装は、このグループ構成をサポートする場合があります。
The assumptions for this trust model are that:
この信頼モデルの仮定は次のとおりです。
- the GCKS is never compromised,
- GCKSが妥協することはありません、
- the GO is never compromised,
- GOが妥協することはありません、
- the PKI, subject to certificate validation, is trustworthy,
- 証明書の検証の対象となるPKIは信頼できます、
- The GO is capable of creating a security policy to meet the demands of the group,
- GOは、グループの要求を満たすためにセキュリティポリシーを作成することができます。
- the compromises of a group member will be detectable and reported to the GO in a trusted manner,
- グループメンバーの妥協は検出可能になり、信頼できる方法でGOに報告されます。
- the subsequent recovery from a compromise will deny inappropriate access to protected data to the compromised member,
- 妥協からのその後の回復は、保護されたデータへの不適切なアクセスを侵害したメンバーへの不適切なアクセスを否定します。
- no security-relevant actions depend on a precise network time,
- セキュリティ関連のアクションは、正確なネットワーク時間に依存しません。
- there are confidentiality, integrity, multicast source authentication, and anti-replay protection mechanisms for all GSAKMP control messages.
- すべてのGSAKMP制御メッセージには、機密性、完全性、マルチキャストソース認証、およびレプレイ防止メカニズムがあります。
The trust model for GSAKMP revolves around the definition and enforcement of the security policy. In fact, the use of the key is only relevant, in a security sense, if it represents the successful enforcement of the group security policy.
GSAKMPの信頼モデルは、セキュリティポリシーの定義と施行を中心に展開します。実際、キーの使用は、グループセキュリティポリシーの成功した施行を表す場合、セキュリティの意味でのみ関連します。
Group operations lend themselves to rule-based security policy. The need for distribution of data to many endpoints often leads to the defining of those authorized endpoints based on rules. For example, all IETF attendees at a given conference could be defined as a single group.
グループ運用は、ルールベースのセキュリティポリシーに役立ちます。多くのエンドポイントにデータを配布する必要性は、多くの場合、ルールに基づいてそれらの承認されたエンドポイントの定義につながります。たとえば、特定の会議のすべてのIETF参加者は、単一のグループとして定義できます。
If the security policy rules are to be relevant, they must be coupled with validation mechanisms. The core principle here is that the level of trust one can afford a security policy is exactly equal to the level of trust one has in the validation mechanism used to prove that policy. For example, if all IETF attendees are allowed in, then they could register their identity from their certificate upon check-in to the meetings. That certificate is issued by a trusted policy creation authority (PKI root) that is authorized to identify someone as an IETF attendee. The GO could make admittance rules to the IETF group based on the identity certificates issued from trusted PKIs.
セキュリティポリシールールが関連する場合、それらは検証メカニズムと結合する必要があります。ここでのコアの原則は、セキュリティポリシーを提供する信頼のレベルは、そのポリシーを証明するために使用される検証メカニズムにおける信頼のレベルと正確に等しいということです。たとえば、すべてのIETF参加者が許可されている場合、会議にチェックインすると証明書から身元を登録できます。その証明書は、誰かをIETFの参加者として識別することが許可されている信頼できる政策作成局（PKIルート）によって発行されます。GOは、信頼できるPKIから発行された身元証明書に基づいて、IETFグループに入場規則を作成する可能性があります。
In GSAKMP, every security policy rule is coupled with an explicit validation mechanism. For interoperability considerations, GSAKMP requires that its supporting PKI implementations MUST be compliant to RFC 3280.
GSAKMPでは、すべてのセキュリティポリシールールが明示的な検証メカニズムと組み合わされています。相互運用性の考慮事項のために、GSAKMPは、そのサポートPKI実装がRFC 3280に準拠している必要があることを要求しています。
If a GM's public key certificate is revoked, then the entity that issues that revocation SHOULD signal the GO, so that the GO can expel that GM. The method that signals this event to the GO is not standardized by this specification.
GMの公開鍵証明書が取り消された場合、その取り消しを発行するエンティティは、GOがそのGMを追放できるように、GOを通知する必要があります。このイベントをGOにシグナルにする方法は、この仕様によって標準化されていません。
A direct mapping of rule to validation mechanism allows the use of multiple rules and PKIs to create groups. This allows a GO to define a group security policy that spans multiple PKI domains, each with its own Certificate Authority public key certificate.
ルールの検証メカニズムへの直接マッピングにより、複数のルールとPKIを使用してグループを作成できます。これにより、複数のPKIドメインにまたがるグループセキュリティポリシーを定義することができます。
The access control policy for the group keys is equivalent to the access control policy for the multicast application data the keys are protecting.
グループキーのアクセス制御ポリシーは、キーが保護しているマルチキャストアプリケーションデータのアクセス制御ポリシーと同等です。
In a group, each data source is responsible for ensuring that the access to the source's data is appropriate. This implies that every data source should have knowledge of the access control policy for the group keys.
グループでは、各データソースは、ソースのデータへのアクセスが適切であることを確認する責任があります。これは、すべてのデータソースがグループキーのアクセス制御ポリシーの知識を持つ必要があることを意味します。
In the general case, GSAKMP offers a suite of security services to its applications and does not prescribe how they use those services.
一般的なケースでは、GSAKMPはアプリケーションに一連のセキュリティサービスを提供し、それらのサービスの使用方法を規定していません。
GSAKMP supports the creation of GSAs with multiple data sources. It also supports architectures where the GC/KS is not itself a data source. In the multiple data source architectures GSAKMP requires that the access control policy is precisely defined and distributed to each data source. The reference for this data structure is the GSAKMP Policy Token [RFC4534].
GSAKMPは、複数のデータソースを使用してGSAの作成をサポートしています。また、GC/KS自体がデータソースではないアーキテクチャもサポートしています。複数のデータソースアーキテクチャでは、GSAKMPでは、アクセス制御ポリシーが各データソースに正確に定義され、配布される必要があります。このデータ構造の参照は、GSAKMPポリシートークン[RFC4534]です。
A critical aspect of the GSAKMP trust model is the authorization of security-relevant actions. These include download of group key, rekey, and PT creation and updates. These actions could be used to disrupt the secure group, and all entities in the group must verify that they were instigated by authorized entities within the group.
GSAKMP Trustモデルの重要な側面は、セキュリティ関連のアクションの承認です。これらには、Group Key、Rekey、Ptの作成と更新のダウンロードが含まれます。これらのアクションを使用して安全なグループを破壊することができ、グループ内のすべてのエンティティがグループ内の認定エンティティによって扇動されたことを確認する必要があります。
Scalability is a core feature of GSAKMP. GSAKMP's approach to scalable operations is the establishment of S-GC/KSes. This allows the GSAKMP systems to distribute the workload of setting up and managing very large groups.
スケーラビリティは、GSAKMPのコア機能です。スケーラブル操作に対するGSAKMPのアプローチは、S-GC/KSESの確立です。これにより、GSAKMPシステムは、非常に大きなグループのセットアップと管理のワークロードを配布できます。
Another aspect of distributed S-GC/KS operations is the enabling of local management authorities. In very large groups, subordinate enclaves may be best suited to provide local management of the enclaves' group membership, due to a direct knowledge of the group members.
分散されたS-GC/KS運用のもう1つの側面は、地元の管理当局を可能にすることです。非常に大きなグループでは、グループメンバーの直接的な知識のために、エンクレーブのグループメンバーシップのローカルマネジメントを提供するのに最適なエンクレーブが最適になる可能性があります。
One of the critical issues involved with distributed operation is the discovery of the security infrastructure location and security suite. Many group applications that have dynamic interactions must "find" each other to operate. The discovery of the security infrastructure is just another piece of information that has to be known by the group in order to operate securely.
分散操作に関連する重要な問題の1つは、セキュリティインフラストラクチャの場所とセキュリティスイートの発見です。動的な相互作用を持つ多くのグループアプリケーションは、互いに「見つけ」に動作する必要があります。セキュリティインフラストラクチャの発見は、安全に動作するためにグループが知っている必要がある別の情報にすぎません。
There are several methods for infrastructure discovery:
インフラストラクチャの発見にはいくつかの方法があります。
- Announcements
- 発表
- Anycast
- Anycast
- Rendezvous points / Registration
- ランデブーポイント /登録
One method for distributing the security infrastructure location is to use announcements. The SAP is commonly used to announce the existence of a new multicast application or service. If an application uses SAP [RFC2974] to announce the existence of a service on a multicast channel, that service could be extended to include the security infrastructure location for a particular group.
セキュリティインフラストラクチャの場所を配布する1つの方法は、発表を使用することです。SAPは、一般的に新しいマルチキャストアプリケーションまたはサービスの存在を発表するために使用されます。アプリケーションがSAP [RFC2974]を使用してマルチキャストチャネルでサービスの存在を発表する場合、そのサービスを拡張して特定のグループのセキュリティインフラストラクチャの場所を含めることができます。
Announcements can also be used by GSAKMP in one of two modes: expanding ring searches (ERSes) of security infrastructure and ERSes for infrastructure discovery. In either case, the GSAKMP would use a multicast broadcast that would slowly increase in its range by incremental multicast hops. The multicast source controls the packet's multicast range by explicitly setting its Time To Live count.
GSAKMPは、2つのモードのいずれかでGSAKMPで使用することもできます。インフラストラクチャの発見のためのセキュリティインフラストラクチャのリング検索（ERSES）およびERSESの拡大（ERS）。どちらの場合でも、GSAKMPはマルチキャストブロードキャストを使用して、増分マルチキャストホップによってその範囲が徐々に増加します。マルチキャストソースは、ライブカウントの時間を明示的に設定することにより、パケットのマルチキャスト範囲を制御します。
An expanding ring announcement operates by the GC/KS announcing its existence for a particular group. The number of hops this announcement would travel would be a locally configured number. The GMs would listen on a well-known multicast address for GC/KSes that provide service for groups of interest. If multiple GC/KSes are found that provide service, then the GM would pick the closest one (in terms of multicast hops). The GM would then send a GSAKMP Request to Join message (RTJ) to the announced GC/KS. If the announcement is found to be spurious, then that is reported to the appropriate management authorities. The ERA concept is slightly different from SAP in that it could occur over the data channel multicast address, instead of a special multicast address dedicated for the SAP service.
拡大するリングアナウンスは、特定のグループの存在を発表するGC/KSによって機能します。この発表が移動するホップの数は、ローカルで構成された数値になります。GMSは、関心のあるグループにサービスを提供するGC/KSEの有名なマルチキャストアドレスで聴きます。サービスを提供する複数のGC/KSEが見つかった場合、GMは（マルチキャストホップに関して）最も近いものを選択します。GMはGSAKMPリクエストを送信して、発表されたGC/KSにメッセージ（RTJ）に参加します。発表が偽物であることが判明した場合、それは適切な管理当局に報告されます。ERAの概念は、SAPサービス専用の特別なマルチキャストアドレスではなく、データチャネルマルチキャストアドレスで発生する可能性があるという点で、SAPとはわずかに異なります。
An expanding ring search operates in the reverse order of the ERA. In this case, the GM is the announcing entity. The (S-)GC/KSes listen for the requests for service, specifically the RTJ. The (S-)GC/KS responds to the RTJ. If the GM receives more than one response, it would either ignore the responses or send NACKs based on local configuration.
拡大するリング検索は、時代の逆の順序で動作します。この場合、GMは発表されているエンティティです。（S-）GC/KSEは、特にRTJのサービスのリクエストを聞きます。（S-）GC/KSはRTJに応答します。GMが複数の応答を受信した場合、応答を無視するか、ローカル構成に基づいてNACKを送信します。
Anycast is a service that is very similar to ERS. It also can be used to provide connection to the security infrastructure. In this case, the GM would send the RTJ to a well-known service request address. This anycast service would route the RTJ to an appropriate GC/KS. The anycast service would have security infrastructure and network connectivity knowledge to facilitate this connection.
Anycastは、ERSに非常に似たサービスです。また、セキュリティインフラストラクチャへの接続を提供するためにも使用できます。この場合、GMはRTJを有名なサービス要求アドレスに送信します。このAnycastサービスは、RTJを適切なGC/KSにルーティングします。Anycastサービスには、この接続を促進するために、セキュリティインフラストラクチャとネットワーク接続の知識があります。
Registration points can be used to distribute many group-relevant data, including security infrastructure. Many group applications rely on well-known registration points to advertise the availability of groups. There is no reason that GSAKMP could not use the same approach for advertising the existence and location of the security infrastructure. This is a simple process if the application being supported already supports registration. The GSAKMP infrastructure can always provide a registration site if the existence of this security infrastructure discovery hub is needed. The registration of S-GC/KSes at this site could be an efficient way to allow GM registration.
登録ポイントは、セキュリティインフラストラクチャを含む多くのグループ関連データを配布するために使用できます。多くのグループアプリケーションは、よく知られている登録ポイントに依存して、グループの可用性を宣伝しています。GSAKMPがセキュリティインフラストラクチャの存在と場所を宣伝するために同じアプローチを使用できなかった理由はありません。これは、サポートされているアプリケーションがすでに登録をサポートしている場合、簡単なプロセスです。GSAKMPインフラストラクチャは、このセキュリティインフラストラクチャディスカバリーハブの存在が必要な場合、常に登録サイトを提供できます。このサイトでのS-GC/KSEの登録は、GM登録を可能にする効率的な方法である可能性があります。
GSAKMP infrastructure discovery can use whatever mechanism suits a particular multicast application's requirements, including mechanisms that have not been discussed by this architecture. However, GSAKMP infrastructure discovery is not standardized by this version of the GSAKMP specification.
GSAKMPインフラストラクチャの発見は、このアーキテクチャで議論されていないメカニズムを含む、特定のマルチキャストアプリケーションの要件に合ったあらゆるメカニズムを使用できます。ただし、GSAKMPインフラストラクチャの発見は、このバージョンのGSAKMP仕様によって標準化されていません。
This concept of operation shows how the different roles in GSAKMP interact to set up a secure group. This particular concept of operation focuses on a secure group that utilizes the distributed key dissemination services of the S-GC/KS.
この操作の概念は、GSAKMPのさまざまな役割がどのように対話して安全なグループをセットアップするかを示しています。この特定の操作概念は、S-GC/KSの分散キー普及サービスを利用する安全なグループに焦点を当てています。
The most basic assumption here is that there is one or more trustworthy PKIs for the group. That trusted PKI will be used to create and verify security policy rules.
ここで最も基本的な仮定は、グループに1つ以上の信頼できるPKIがあるということです。信頼できるPKIは、セキュリティポリシールールを作成および検証するために使用されます。
There is a GO that all GMs recognize as having group policy creation authority. All GM must be securely pre-configured to know the GO public key.
すべてのGMがグループ政策作成権限を持っていると認識していることがあります。すべてのGMは、GOの公開キーを知るために安全に事前に構成されている必要があります。
All GMs have access to the GO PKI information, both the trusted anchor public keys and the certificate path validation rules.
すべてのGMは、信頼できるアンカーパブリックキーと証明書パス検証ルールの両方で、GO PKI情報にアクセスできます。
There is sufficient connectivity between the GSAKMP entities.
GSAKMPエンティティ間に十分な接続性があります。
- The registration SA requires that GM can connect to the GC/KS or S-GC/KS using either TCP or UDP.
- 登録SAでは、GMがTCPまたはUDPを使用してGC/KSまたはS-GC/KSに接続できることが必要です。
- The Rekey SA requires that the data-layer multicast communication service be available. This can be multicast IP, overlay networks using TCP, or NAT tunnels.
- Rekey SAは、データレイヤーマルチキャスト通信サービスを利用できるようにする必要があります。これは、マルチキャストIP、TCPを使用したオーバーレイネットワーク、またはNATトンネルです。
- GSAKMP can support many different data-layer secure applications, each with unique connectivity requirements.
- GSAKMPは、それぞれが独自の接続要件を備えたさまざまなデータレイヤーセキュアアプリケーションをサポートできます。
The GO creates and signs the policy token for a group. The policy token contains the rules for access control and authorizations for a particular group.
GOは、グループのポリシートークンを作成して署名します。ポリシートークンには、特定のグループのアクセス制御と承認に関するルールが含まれています。
The PT consists of the following information:
PTは次の情報で構成されています。
- Identification: This allows an unambiguous identification of the PT and the group.
- 識別：これにより、PTとグループの明確な識別が可能になります。
- Access Control Rules: These rules specify who can have access to the group keys.
- アクセス制御ルール：これらのルールは、グループキーにアクセスできる人を指定します。
- Authorization Rules: These rules specify who can be a S-GC/KS.
- 承認規則：これらのルールは、誰がS-GC/ksになる可能性があるかを指定します。
- Mechanisms: These rules specify the security mechanisms that will be used by the group. This is necessary to ensure there is no weak link in the group security profile. For example, for IPsec, this could include SPD/SAD configuration data.
- メカニズム：これらのルールは、グループが使用するセキュリティメカニズムを指定します。これは、グループセキュリティプロファイルに弱いリンクがないことを確認するために必要です。たとえば、IPSECの場合、これにはSPD/SAD構成データが含まれます。
- Source authentication of the PT to the GO: The PT is a CMS signed object, and this allows all GMs to verify the PT.
- PTのGO：PTのソース認証は、CMS署名されたオブジェクトであり、これによりすべてのGMがPTを検証できます。
The PT is sent to a potential GC/KS. This can occur in several ways, and the method of transmittal is outside the scope of GSAKMP. The potential GC/KS will verify the GO signature on the PT to ensure that it comes from a trusted GO. Next, the GC/KS will verify that it is authorized to become the GC/KS, based on the authorization rules in the PT. Assuming that the GC/KS trusts the PT, is authorized to be a GC/KS, and is locally configured to become a GC/KS for a given group and the GO, then the GC/KS will create the keys necessary to start the group. The GC/KS will take whatever action is necessary (if any) to advertise its ability to distribute key for the group. The GC/KS will then listen for RTJs.
PTは潜在的なGC/KSに送信されます。これはいくつかの方法で発生する可能性があり、透過方法はGSAKMPの範囲外です。潜在的なGC/KSは、PTのGO署名を検証して、信頼できるGOから来ることを確認します。次に、GC/KSは、PTの承認ルールに基づいて、GC/KSになることが許可されていることを確認します。GC/KSがPTを信頼し、GC/KSであることが許可されており、特定のグループのGC/KSになるようにローカルに構成されていると仮定すると、GC/KSは開始するために必要なキーを作成します。グループ。GC/KSは、グループのキーを配布する能力を宣伝するために必要なアクション（もしあれば）を実行します。GC/KSはRTJを聴きます。
The PT has a sequence number. Every time a PT is distributed to the group, the group members verify that the sequence number on the PT is increasing. The PT lifetime is not limited to a particular time interval, other than by the lifetimes imposed by some of its attributes (e.g., signature key lifetime). The current PT sequence number is downloaded to the GM in the "Key Download" message. Also, to avoid replay attacks, this sequence number is never reset to a lower value (i.e., rollover to zero) as long as the group identifier remains valid and in use. The GO MUST preserve this sequence number across re-boots.
PTにはシーケンス番号があります。PTがグループに配布されるたびに、グループメンバーは、PTのシーケンス番号が増加していることを確認します。PT寿命は、その属性の一部（例えば、署名キーライフタイムなど）によって課される寿命を除いて、特定の時間間隔に限定されません。現在のPTシーケンス番号は、「キーダウンロード」メッセージでGMにダウンロードされます。また、リプレイ攻撃を回避するために、グループ識別子が有効で使用されている限り、このシーケンス番号が低い値（つまり、ロールオーバーからゼロまで）にリセットされることはありません。GOは、再起動全体にこのシーケンス番号を保持する必要があります。
Potential GMs will receive notice of the new group via some mechanism: announcement, Anycast, or registration look-up. The GM will send an RTJ to the GC/KS.
潜在的なGMSは、アナウンス、アニキャスト、または登録検索など、いくつかのメカニズムを介して新しいグループの通知を受け取ります。GMはGC/KSにRTJを送信します。
The GC/KS may or may not require cookies, depending on the DoS environment and the local configuration.
GC/KSは、DOS環境とローカル構成に応じて、Cookieを必要とする場合と必要になる場合があります。
Once the RTJ has been received, the GC/KS will verify that the GM is allowed to have access to the group keys. The GC/KS will then verify the signature on the RTJ to ensure it was sent by the claimed identity. If the checks succeed, the GC/KS will ready a Key Download message for the GM. If not, the GC/KS can notify the GM of a non-security-relevant problem.
RTJを受信すると、GC/KSはGMがグループキーにアクセスできることを確認します。GC/KSは、RTJの署名を検証して、請求されたIDによって送信されたことを確認します。チェックが成功した場合、GC/KSはGMのキーダウンロードメッセージを準備します。そうでない場合、GC/KSはGMにセキュリティに関連しない問題を通知できます。
Upon receipt of the Key Download message, the GM will verify the signature on the message. Then the GM will retrieve the PT from the Key Download message and verify that the GO created and signed the PT. Once the PT is verified as valid, the GM will verify that the GC/KS is authorized to distribute key for this group. Then the GM will verify that the mechanisms used in the group are available and acceptable for protection of the GMs data (assuming the GM is a data source). The GM will then accept membership in this group.
キーダウンロードメッセージを受信すると、GMはメッセージの署名を確認します。次に、GMはキーダウンロードメッセージからPTを取得し、GOが作成および署名されたPTを確認します。PTが有効であると確認されると、GMはGC/KSがこのグループのキーを配布することを許可されていることを確認します。GMは、GMSデータの保護のためにグループで使用されているメカニズムが利用可能であり、許容できることを確認します（GMがデータソースであると仮定します）。GMはこのグループのメンバーシップを受け入れます。
The GM will then check to see if it is allowed to be a S-GC/KS for this group. If the GM is allowed to be a S-GC/KS AND the local GM configuration allows the GM to act as a S-GC/KS for this group, then the GM changes its operating state to S-GC/KS. The GO needs to assign the authority to become a S-GC/KS in a manner that supports the overall group integrity and operations.
GMは、このグループのS-GC/KSであることが許可されているかどうかを確認します。GMがS-GC/KSになり、ローカルGM構成によりGMがこのグループのS-GC/KSとして機能するようにすると、GMはその動作状態をS-GC/KSに変更します。GOは、グループ全体の整合性と運用をサポートする方法でS-GC/KSになる権限を割り当てる必要があります。
In autonomous mode, each S-GC/KS operates a largely self-contained sub-group for which the Primary-GC/KS delegates the sub-group's membership management responsibility to the S-GC/KS. In general, the S-GC/KS locally handles each Group Member's registration and de-registration without any interaction with the Primary-GC/KS. Periodically, the Primary-GC/KS multicasts a Rekey Event message addressed only to its one or more S-GC/KS.
自律モードでは、各S-GC/KSは、プライマリGC/KSがサブグループのメンバーシップ管理責任をS-GC/KSに委任する大部分が自己完結型のサブグループを動作させます。一般に、S-GC/ksは、プライマリGC/ksとの相互作用なしに、各グループメンバーの登録と登録解除をローカルに処理します。定期的に、プライマリGC/KSマルチキャストは、1つ以上のS-GC/KSにのみアドレス指定されたRekeyイベントメッセージをマルチキャストします。
After a S-GC/KS successfully processes a Rekey Event message from the Primary-GC/KS, the S-GC/KS transmits to its sub-group its own Rekey Event message containing a copy of the group's new GTPK and policy token. The S-GC/KS encrypts its Rekey Event message's sub-group key management information using Logical Key Hierarchy or a comparable rekey protocol. The S-GC/KS uses the rekey protocol to realize forward and backward secrecy, such that only the authorized sub-group members can decrypt and acquire access to the new GTPK and policy token. The frequency at which the Primary-GC/KS transmits a Rekey Event message is a policy token parameter.
S-GC/KSがプライマリGC/KSからのRekeyイベントメッセージを正常に処理した後、S-GC/KSは、グループの新しいGTPKとポリシートークンのコピーを含む独自のRekeyイベントメッセージをサブグループに送信します。S-GC/KSは、論理キー階層または同等のRekeyプロトコルを使用して、Rekey Event Messageのサブグループのキー管理情報を暗号化します。S-GC/KSはRekeプロトコルを使用して前方および後方の秘密を実現するため、認定されたサブグループメンバーのみが新しいGTPKおよびポリシートークンへのアクセスを復号化して取得できます。プライマリGC/KSがREKEYイベントメッセージを送信する頻度は、ポリシートークンパラメーターです。
For the special case of a S-GC/KS detecting an expelled or compromised group member, a mechanism is defined to trigger an immediate group rekey rather than wait for the group's rekey period to elapse. See below for details.
S-GC/KSの特別なケースでは、グループメンバーの排出または侵害されたグループメンバーを検出すると、グループの再キー期間が経過するのを待つのではなく、即時のグループレキーをトリガーするメカニズムが定義されます。詳細については、以下をご覧ください。
Each S-GC/KS will be registered by the GC/KS as a management node with responsibility for GTPK distribution, access control policy enforcement, LKH tree creation, and distribution of LKH key arrays. The S-GC/KS will be registered into the primary LKH tree as an endpoint. Each S-GC/KS will hold an entire LKH key array for the GC's LKH key tree.
各S-GC/KSは、GTPK分布、アクセス制御ポリシーの執行、LKHツリーの作成、LKHキーアレイの配布の責任を持つ管理ノードとしてGC/KSによって登録されます。S-GC/KSは、エンドポイントとしてプライマリLKHツリーに登録されます。各S-GC/KSは、GCのLKHキーツリーのLKHキーアレイ全体を保持します。
For the purpose of clarity, the process of creating a distributed GSAKMP group will be explained in chronological order.
明確にするために、分散型GSAKMPグループを作成するプロセスは、時系列で説明されます。
First, the Group Owner will create a policy token that authorizes a subset of the group's membership to assume the role of S-GC/KS.
まず、グループの所有者は、S-GC/KSの役割を引き受けるためにグループのメンバーシップのサブセットを承認するポリシートークンを作成します。
The GO needs to ensure that the S-GC/KS rules in the policy token will be stringent enough to ensure trust in the S-GC/KSes. This policy token is handed off to the primary GC.
GOは、ポリシートークンのS-GC/KSルールがS-GC/KSESへの信頼を確保するのに十分な厳格であることを確認する必要があります。このポリシートークンは、プライマリGCに引き渡されます。
The GC will create the GTPK and initial LKH key tree. The GC will then wait for a potential S-GC/KS to send a Request to Join (RTJ) message.
GCはGTPKと初期LKHキーツリーを作成します。GCは、潜在的なS-GC/KSが参加するリクエスト（RTJ）メッセージを送信するのを待ちます。
A potential S-GC/KS will eventually send an RTJ. The GC will enforce the access control policy as defined in the policy token. The S-GC/KS will accept the role of S-GC/KS and create its own LKH key tree for its sub-group membership.
潜在的なS-GC/KSは最終的にRTJを送信します。GCは、ポリシートークンで定義されているように、アクセス制御ポリシーを実施します。S-GC/KSは、S-GC/KSの役割を受け入れ、サブグループメンバーシップのために独自のLKHキーツリーを作成します。
The S-GC/KS will then offer registration services for the group. There are local management decisions that are optional to control the scope of group members that can be served by a S-GC/KS. These are truly local management issues that allow the administrators of an S-GC/KS to restrict service to potential GMs. These local controls do not affect the overall group security policy, as defined in the policy token.
S-GC/KSは、グループに登録サービスを提供します。S-GC/ksが提供できるグループメンバーの範囲を制御するためにオプションのローカル管理の決定があります。これらは、S-GC/KSの管理者がサービスを潜在的なGMに制限できるようにする真のローカル管理の問題です。これらのローカルコントロールは、ポリシートークンで定義されているように、グループ全体のセキュリティポリシーに影響しません。
A potential Group Member will send an RTJ to the S-GC/KS. The S-GC/KS will enforce the entire access control policy as defined in the PT. The GM will receive an LKH key array that corresponds to the LKH tree of the S-GC/KS. The key tree generated by the S-GC/KS is independent of the key tree generated by the GC/KS; they share no common keys.
潜在的なグループメンバーは、S-GC/ksにRTJを送信します。S-GC/KSは、PTで定義されているように、アクセス制御ポリシー全体を実施します。GMには、S-GC/ksのLKHツリーに対応するLKHキー配列が届きます。S-GC/KSによって生成されたキーツリーは、GC/KSによって生成されたキーツリーとは無関係です。彼らは一般的な鍵を共有していません。
The GM then has the keys it needs to receive group traffic and be subject to rekey from the S-GC/KS. For the sake of this discussion, let's assume the GM is to be expelled from the group membership.
GMには、グループトラフィックを受信し、S-GC/KSからの再キーの対象となるために必要なキーがあります。この議論のために、GMがグループメンバーシップから追放されると仮定しましょう。
The S-GC/KS will receive notification that the GM is to be expelled. This mechanism is outside the scope of this protocol.
S-GC/KSは、GMが追放されるという通知を受け取ります。このメカニズムは、このプロトコルの範囲外です。
Upon notification that a GM that holds a key array within its LKH tree is to be expelled, the S-GC/KS does two things. First, the S-GC/KS initiates a de-registration exchange with the GC/KS identifying the member to be expelled. (The S-GC/KS proxies a Group Member's de-registration informing the GC/KS that the Group Member has been expelled from the group.) Second, the S-GC/KS will wait for a rekey action by the GC/KS. The immediacy of the rekey action by the GC/KS is a management decision at the GC/KS. Security is best served by quick expulsion of untrusted members.
LKHツリー内にキー配列を保持するGMが追放されることを通知すると、S-GC/KSは2つのことを行います。まず、S-GC/KSは、排出されるメンバーを識別するGC/KSとの登録解除交換を開始します。（S-GC/KSは、グループメンバーがグループから追放されたことをGC/KSに通知するグループメンバーの登録を依頼します。）次に、S-GC/KSはGC/KSによる再キーアクションを待ちます。GC/KSによるREKEYアクションの即時性は、GC/KSの管理上の決定です。セキュリティは、信頼されていないメンバーの迅速な追放によって最適に提供されます。
Upon receipt of the de-registration notification from the S-GC/KS, the GC/KS will register the member to be expelled. The GC/KS will then follow group procedure for initiating a rekey action (outside the scope of this protocol). The GC/KS will communicate to the GO the expelled member's information (outside the scope of this protocol). With this information, the GO will create a new PT for the group with the expelled GM identity added to the excluded list in the group's access control rules. The GO provides this new PT to the GC/KS for distribution with the Rekey Event Message.
S-GC/KSからの登録解除通知を受け取ると、GC/KSは追放されるメンバーを登録します。GC/KSは、REKEYアクションを開始するためのグループ手順に従います（このプロトコルの範囲外）。GC/KSは、追放されたメンバーの情報（このプロトコルの範囲外）に通信します。この情報を使用すると、GOは、グループのアクセス制御ルールに除外されたリストに排出されたGM IDが追加されたグループの新しいPTを作成します。GOは、REKEYイベントメッセージを使用して、この新しいPTをGC/KSに提供します。
The GC/KS will send out a rekey operation with a new PT. The S-GC/KS will receive the rekey and process it. At the same time, all other S-GC/KSes will receive the rekey and note the excluded GM identity. All S-GC/KSes will review local identities to ensure that the excluded GM is not a local member. If it is, then the S-GC/KS will create a rekey message. The S-GC/KSes must always create a rekey message, whether or not the expelled Group Member is a member of their subtrees.
GC/KSは、新しいPTを使用してRekey操作を送信します。S-GC/KSはRekeyを受け取り、処理します。同時に、他のすべてのS-GC/KSEはRekeyを受け取り、除外されたGMアイデンティティに注意します。すべてのS-GC/KSEは、除外されたGMがローカルメンバーでないことを確認するためにローカルアイデンティティを確認します。もしそうなら、S-GC/KSはRekeyメッセージを作成します。S-GC/KSEは、追放されたグループメンバーがサブツリーのメンバーであるかどうかにかかわらず、常に再キーメッセージを作成する必要があります。
The S-GC/KS will then create a local rekey message. The S-GC/KS will send the wrapped Group TPK to all members of its local LKH tree, except the excluded member(s).
S-GC/KSは、ローカルレキーメッセージを作成します。S-GC/KSは、除外されたメンバーを除き、ラップグループTPKをローカルLKHツリーのすべてのメンバーに送信します。
The management of a cryptographic group follows a life cycle: group definition, group establishment, and security-relevant group maintenance. Group definition involves defining the parameters necessary to support a secure group, including its policy token. Group establishment is the process of granting access to new members. Security-relevant group maintenance messages include rekey, policy changes, member deletions, and group destruction. Each of these life cycle phases is discussed in the following sections.
暗号化グループの管理は、グループ定義、グループ設立、セキュリティ関連グループのメンテナンスというライフサイクルに従います。グループ定義には、ポリシートークンを含む安全なグループをサポートするために必要なパラメーターを定義することが含まれます。グループ設立は、新しいメンバーへのアクセスを付与するプロセスです。セキュリティ関連のグループメンテナンスメッセージには、Rekey、ポリシーの変更、メンバーの削除、グループの破壊が含まれます。これらのライフサイクルフェーズのそれぞれについては、次のセクションで説明します。
The use and processing of the optional Vendor ID payload for all messages can be found in Section 7.10.
すべてのメッセージのオプションのベンダーIDペイロードの使用と処理は、セクション7.10に記載されています。
A cryptographic group is established to support secure communications among a group of individuals. The activities necessary to create a policy token in support of a cryptographic group include:
個人グループ間の安全な通信をサポートするために、暗号化グループが設立されています。暗号化グループをサポートしてポリシートークンを作成するために必要なアクティビティは次のとおりです。
- Determine Access Policy: identify the entities that are authorized to receive the group key.
- アクセスポリシーの決定：グループキーを受け取ることが許可されているエンティティを特定します。
- Determine Authorization Policy: identify which entities are authorized to perform security-relevant actions, including key dissemination, policy creation, and initiation of security-management actions.
- 認可ポリシーを決定する：主要な普及、政策作成、セキュリティ管理訴訟の開始など、セキュリティ関連のアクションを実行する権限を与えられているエンティティを特定します。
- Determine Mechanisms: define the algorithms and protocols used by GSAKMP to secure the group.
- メカニズムの決定：GSAKMPがグループを保護するために使用するアルゴリズムとプロトコルを定義します。
- Create Group Policy Token: format the policies and mechanisms into a policy token, and apply the GO signature.
- グループポリシートークンの作成：ポリシーとメカニズムをポリシートークンにフォーマットし、GO署名を適用します。
GSAKMP Group Establishment consists of three mandatory-to-implement messages: the Request to Join, the Key Download, and the Key Download Ack/Failure. The exchange may also include two OPTIONAL error messages: the Request to Join Error and the Lack_of_Ack messages. Operation using the mandatory messages only is referred to as "Terse Mode", while inclusion of the error messaging is referred to as "Verbose Mode". GSAKMP implementations MUST support Terse Mode and MAY support Verbose Mode. Group Establishment is discussed in Section 5.2.1.
GSAKMPグループの設立は、3つの必須から実装されるメッセージで構成されています。結合リクエスト、キーダウンロード、キーダウンロードACK/障害です。Exchangeには、2つのオプションのエラーメッセージが含まれている場合があります。エラーの結合リクエストとlack_of_ackメッセージ。必須メッセージのみを使用した操作は「terseモード」と呼ばれ、エラーメッセージの包含は「冗長モード」と呼ばれます。GSAKMPの実装は、Terseモードをサポートする必要があり、冗長モードをサポートする場合があります。グループ設立については、セクション5.2.1で説明します。
A group is set in Terse or Verbose Mode by a policy token parameter. All (S-)GC/KSes in a Verbose Mode group MUST support Verbose Mode. GSAKMP allows Verbose Mode groups to have GMs that do not support Verbose Mode. Candidate GMs that do not support Verbose Mode and receive a RTJ-Error or Lack-of-Ack message must handle these messages gracefully. Additionally, a GM will not know ahead of time that it is interacting with the (S-)GC/KS in Verbose or Terse Mode until the policy token is received.
グループは、ポリシートークンパラメーターによって簡潔または冗長モードで設定されます。すべての（s-）verboseモードグループのGC/KSEは、冗長モードをサポートする必要があります。GSAKMPにより、冗長モードグループは、冗長モードをサポートしないGMを持つことができます。冗長モードをサポートせず、RTJ-Errorまたはof-of-of-of-of-of-of-of-of-ofのメッセージを受信する候補GMは、これらのメッセージを優雅に処理する必要があります。さらに、GMは、ポリシートークンを受信するまで、冗長モードまたは簡潔なモードで（S-）GC/KSと相互作用していることを事前に知りません。
For denial of service protection, a Cookie Exchange MAY precede the Group Establishment exchange. The Cookie Exchange is described in Section 5.2.2.
サービス保護の拒否のために、Cookie Exchangeがグループ設立交換に先行する場合があります。Cookie Exchangeについては、セクション5.2.2で説明しています。
Regardless of mode, any error message sent between component members indicates the first error encountered while processing the message.
モードに関係なく、コンポーネントメンバー間で送信されたエラーメッセージは、メッセージの処理中に遭遇した最初のエラーを示します。
After the out-of-band receipt of a policy token, a potential Group Controller Key Server (GC/KS) verifies the token and its eligibility to perform GC/KS functionality. It is then permitted to create any needed group keys and begin to establish the group.
ポリシートークンの帯域外受領後、潜在的なグループコントローラーキーサーバー（GC/KS）がトークンとGC/KS機能を実行する適格性を検証します。その後、必要なグループキーを作成し、グループの確立を開始することが許可されます。
The GSAKMP Ladder Diagram, Figure 1, illustrates the process of establishing a cryptographic group. The left side of the diagram represents the actions of the GC/KS. The right side of the diagram represents the actions of the GMs. The components of each message shown in the diagram are presented in Sections 5.2.1.1 through 5.2.1.5.
GSAKMPはしご図、図1は、暗号化グループを確立するプロセスを示しています。図の左側は、GC/ksのアクションを表します。図の右側は、GMSのアクションを表します。図に示す各メッセージのコンポーネントは、セクション5.2.1.1から5.2.1.5に示されています。
CONTROLLER Mandatory/ MESSAGE MEMBER
Optional
!<-M----------Request to Join-------------!
<Process> ! !
<RTJ> ! !
!--M----------Key Download--------------->!
! !<Process KeyDL>
!--O-------Request to Join Error--------->! or
! ! <Proc RTJ-Err>
!<-M----Key Download - Ack/Failure--------!
<Process >! !
<KeyDL-A/F>! !
!--O------Lack of Acknowledgement-------->!
! ! <Proc LOA>
!<=======SHARED KEYED GROUP SESSION======>!
Figure 1: GSAKMP Ladder Diagram
図1：GSAKMPはしご図
The Request to Join message is sent from a potential GM to the GC/KS to request admission to the cryptographic group. The message contains key creation material, freshness data, an optional selection of mechanisms, and the signature of the GM.
メッセージに参加するリクエストは、潜在的なGMからGC/KSに送信され、暗号化グループへの入場をリクエストします。このメッセージには、主要な作成資料、鮮度データ、オプションのメカニズムの選択、およびGMの署名が含まれています。
The Key Download message is sent from the GC/KS to the GM in response to an accepted Request to Join. This GC/KS-signed message contains the identifier of the GM, freshness data, key creation material, encrypted keys, and the encrypted policy token. The policy token is used to facilitate well-ordered group creation and MUST include the group's identification, group permissions, group join policy, group controller key server identity, group management information, and digital signature of the GO. This will allow the GM to determine whether group policy is compatible with local policy.
キーダウンロードメッセージは、参加するための受け入れられたリクエストに応じて、GC/ksからGMに送信されます。このGC/KS署名メッセージには、GMの識別子、鮮度データ、キー作成資料、暗号化されたキー、暗号化されたポリシートークンが含まれています。ポリシートークンは、適切に秩序あるグループの作成を促進するために使用され、グループの識別、グループ参加、グループに参加するポリシー、グループコントローラーのキーサーバーのアイデンティティ、グループ管理情報、およびGOのデジタル署名を含める必要があります。これにより、GMはグループポリシーがローカルポリシーと互換性があるかどうかを判断できます。
The Request to Join Error message is sent from the GC/KS to the GM in response to an unaccepted Request to Join. This message is not signed by the GC/KS for two reasons: 1) the GM, at this point, has no knowledge of who is authorized to act as a GC/KS, and so the signature would thus be meaningless to the GM, and 2) signing responses to denied join requests would provide a denial of service potential. The message contains an indication of the error condition. The possible values for this error condition are: Invalid-Payload-Type, Invalid-Version, Invalid-Group-ID, Invalid-Sequence-ID, Payload-Malformed, Invalid-ID-Information, Invalid-Certificate, Cert-Type-Unsupported, Invalid-Cert-Authority, Authentication-Failed, Certificate-Unavailable, Unauthorized-Request, Prohibited-by-Group-Policy, and Prohibited-by-Locally-Configured-Policy.
エラーメッセージに参加するリクエストは、GC/ksからGMに送信されます。このメッセージは、2つの理由でGC/KSによって署名されていません。1）GMは、この時点で、GC/KSとして行動することを許可されている人に関する知識がないため、署名はGMにとって意味がありません。2）拒否された参加リクエストへの応答に署名すると、サービスの拒否の可能性が得られます。メッセージには、エラー条件の表示が含まれています。このエラー条件の可能な値は、無効なペイロードタイプ、無効なバージョン、無効なグループID、ペイロードマルフォーム、無効なID情報、無効な認証、cert-type-unsupported、無効なcert-authority、認証faid、証明書が利用できない、不正な要求、グループごとの禁止、そして主張による禁止されたポリティ。
The Key Download Ack/Failure message indicates Key Download receipt status at the GM. It is a GM-signed message containing freshness data and status.
キーダウンロードACK/障害メッセージは、GMでのキーダウンロード領収書ステータスを示します。これは、新鮮さのデータとステータスを含むGM署名メッセージです。
The Lack_of_Ack message is sent from the GC/KS to the GM in response to an invalid or absent Key Download Ack/Failure message. The signed message contains freshness and status data and is used to warn the GM of impending eviction from the group if a valid Key Download Ack/Failure is not sent. Eviction means that the member will be excluded from the group after the next Rekey Event. The policy of when a particular group needs to rekey itself is stated in the policy token. Eviction is discussed further in Section 5.3.2.1.
RECO_OF_ACKメッセージは、無効または存在しないキーダウンロードACK/障害メッセージに応じて、GC/KSからGMに送信されます。署名されたメッセージには、新鮮さとステータスデータが含まれており、有効なキーダウンロードACK/障害が送信されない場合、GMにグループからの差し迫った立ち退きのGMに警告するために使用されます。立ち退きとは、次のRekeyイベントの後、メンバーがグループから除外されることを意味します。特定のグループが自体を再キーする必要がある場合のポリシーは、ポリシートークンに記載されています。立ち退きは、セクション5.3.2.1でさらに議論されています。
For the following message structure sections, details about payload format and processing can be found in Section 7. Each message is identified by its exchange type in the header of the message. Nonces MUST be present in the messages unless synchronization time is available to the system.
次のメッセージ構造セクションでは、ペイロード形式と処理の詳細はセクション7に記載されています。各メッセージは、メッセージのヘッダーの交換タイプによって識別されます。システムが同期時間を使用できない限り、メッセージにはメッセージに存在する必要があります。
The exchange type for Request to Join is eight (8).
参加するリクエストの交換タイプは8（8）です。
The components of a Request to Join Message are shown in Table 1.
メッセージに参加するリクエストのコンポーネントを表1に示します。
Table 1: Request to Join (RTJ) Message Definition
表1：参加する（RTJ）メッセージ定義のリクエスト
Message Name : Request to Join (RTJ) Dissection : {HDR-GrpID, Key Creation, Nonce_I, [VendorID], : [Notif_Mechanism_Choices], [Notif_Cookie], : [Notif_IPValue]} SigM, [Cert] Payload Types : GSAKMP Header, Key Creation, [Nonce], [Vendor ID], Signature, [Certificate], [Notifications]
メッセージ名：結合（RTJ）解剖のリクエスト：{HDR-GRPID、KEY CREATION、NONCE_I、[VENDORID]、：[Notif_Mechanism_Choices]、[Notif_Cookie]、：[notif_ipvalue]} sigm、[cert]ペイロードタイプ：gsakmp header、キー作成、[nonce]、[ベンダーID]、署名、[証明書]、[通知]
SigM : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
As shown by Figure 1, a potential GM MUST generate and send an RTJ message to request permission to join the group. At a minimum, the GM MUST be able to manually configure the destination for the RTJ. As defined in the dissection of the RTJ message, this message MUST contain a Key Creation payload for KEK determination. A Nonce payload MUST be included for freshness and the Nonce_I value MUST be saved for potential later use. The GC/KS will use this supplied nonce only if the policy token for this group defines the use of nonces versus synchronization time. An OPTIONAL Notification payload of type Mechanism Choices MAY be included to identify the mechanisms the GM wants to use. Absence of this payload will cause the GC/KS to select appropriate default policy-token-specified mechanisms for the Key Download.
図1に示すように、潜在的なGMは、グループに参加する許可を要求するためにRTJメッセージを生成して送信する必要があります。少なくとも、GMはRTJの宛先を手動で構成できる必要があります。RTJメッセージの分析で定義されているように、このメッセージにはKEK決定のためのキー作成ペイロードが含まれている必要があります。NonCeペイロードは新鮮さのために含める必要があり、潜在的な使用のためにNonCE_I値を保存する必要があります。GC/ksは、このグループのポリシートークンが非sesと同期時間の使用を定義している場合にのみ、この供給された非CEを使用します。GMが使用したいメカニズムを特定するために、タイプメカニズムの選択肢のオプションの通知ペイロードを含めることができます。このペイロードがないと、GC/KSがキーダウンロードのために適切なデフォルトのポリシートークンが指定されたメカニズムを選択します。
In response, the GC/KS accepts or denies the request based on local configuration. <Process RTJ> indicates the GC/KS actions that will determine if the RTJ will be acted upon. The following checks SHOULD be performed in the order presented.
これに応じて、GC/KSはローカル構成に基づいて要求を受け入れるか拒否します。<プロセスRTJ>は、RTJが作用するかどうかを決定するGC/KSアクションを示します。次のチェックを提示された順序で実行する必要があります。
In this procedure, the GC/KS MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, then the identity of the sender is extracted from the Signature payload. This identity MUST be used to perform access control checks and find the GMs credentials (e.g., certificate) for message verification. It MUST also be used in the Key Download message. Then, the GC/KS will verify the signature on the message to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If the message signature verifies, the GC/KS then confirms that all required payloads are present and properly formatted based upon the mechanisms announced and/or requested. If all checks pass, the GC/KS will create and send the Key Download message as described in Section 5.2.1.2.
この手順では、GC/KSは、メッセージヘッダーが適切に形成されていることを確認し、GroupIDの値をチェックすることにより、このメッセージがこのグループ向けであることを確認する必要があります。ヘッダーチェックが通過すると、送信者の身元が署名ペイロードから抽出されます。このIDは、アクセス制御チェックを実行し、メッセージ検証のためにGMS資格情報（証明書など）を見つけるために使用する必要があります。また、キーダウンロードメッセージにも使用する必要があります。次に、GC/KSは、メッセージの署名を確認して、その信ity性を確保します。GC/KSは、既知のルートから検証済みの認証資料を使用する必要があります。メッセージの署名が検証された場合、GC/KSは、必要なすべてのペイロードが存在し、発表および/または要求されたメカニズムに基づいて適切にフォーマットされていることを確認します。すべてのチェックが合格した場合、GC/KSはセクション5.2.1.2で説明されているように、キーダウンロードメッセージを作成および送信します。
If the GM receives no response to the RTJ within the GM's locally configured timeout value, the GM SHOULD resend the RTJ message up to three (3) times.
GMがGMのローカルで構成されたタイムアウト値内でRTJに応答しない場合、GMはRTJメッセージを最大3回再送信する必要があります。
NOTE: At any one time, a GC/KS MUST process no more than one (1) valid RTJ message from a given GM per group until its pending registration protocol exchange concludes.
注：いつでも、GC/KSは、保留中の登録プロトコル交換が終了するまで、グループごとに特定のGMから1つの有効なRTJメッセージを処理する必要があります。
If any error occurs during RTJ message processing, and the GC/KS is running in Terse Mode, the registration session MUST be terminated, and all saved state information MUST be cleared.
RTJメッセージ処理中にエラーが発生し、GC/KSがTerseモードで実行されている場合、登録セッションを終了する必要があり、すべての保存された状態情報をクリアする必要があります。
The OPTIONAL Notification payload of type Cookie is discussed in Section 5.2.2.
タイプCookieのオプションの通知ペイロードについては、セクション5.2.2で説明します。
The OPTIONAL Notification payload of type IPValue may be used for the GM to convey a specific IP value to the GC/KS.
タイプIPValueのオプションの通知ペイロードをGMに使用して、GC/KSに特定のIP値を伝えることができます。
The exchange type for Key Download is nine (9).
キーダウンロードの交換タイプは9（9）です。
The components of a Key Download Message are shown in Table 2:
キーダウンロードメッセージのコンポーネントを表2に示します。
Table 2: Key Download (KeyDL) Message Definition
表2：キーダウンロード（keydl）メッセージ定義
Message Name : Key Download (KeyDL) Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], Key Creation, (Policy Token)*, (Key Download)*, [VendorID]} SigC, [Cert] Payload Types : GSAKMP Header, Identification, [Nonce], Key Creation, Policy Token, Key Download, [Vendor ID], Signature, [Certificate]
メッセージ名：キーダウンロード（keydl）quationection：{hdr-grpid、member id、[nonce_r、nonce_c]、key creation、（policy token）*、（key download）*、[vendorid]} sigc、[cert]ペイロードタイプ：gsakmpヘッダー、識別、[nonce]、キー作成、ポリシートークン、キーダウンロード、[ベンダーID]、署名、[証明書]
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
(data)* : Indicates encrypted information
In response to a properly formed and verified RTJ message, the GC/KS creates and sends the KeyDL message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Key Creation material, encrypted policy token, encrypted key information, and signature information. If synchronized time is not available, the Nonce payloads MUST be included in the message for freshness.
適切に形成および検証されたRTJメッセージに応じて、GC/KSはKeyDLメッセージを作成および送信します。メッセージの分析で定義されているように、このメッセージには、GM識別、キー作成資料、暗号化されたポリシートークン、暗号化されたキー情報、および署名情報：次の情報を保持するためにペイロードを含める必要があります。同期された時間が利用できない場合、NONCEペイロードは新鮮さのメッセージに含める必要があります。
If present, the nonce values transmitted MUST be the GC/KS's generated Nonce_R value and the combined Nonce_C value that was generated by using the GC/KS's Nonce_R value and the Nonce_I value received from the GM in the RTJ.
存在する場合、送信されたNonCE値は、GC/KSのNonCE_R値とRTJのGMから受信したNonCE_I値を使用して生成されたGC/KSの生成されたNonCE_R値と、COMBINED NONCE_C値でなければなりません。
If two-party key determination is used, the key creation material supplied by the GM and/or the GC/KS will be used to generate the key. Generation of this key is dependent on the key exchange, as defined in Section 7.11, "Key Creation Payload". The policy token and key material are encrypted in the generated key.
2パーティのキー決定が使用される場合、GMおよび/またはGC/KSが提供するキー作成資料を使用してキーを生成します。このキーの生成は、セクション7.11「キー作成ペイロード」で定義されているように、キー交換に依存します。ポリシートークンとキー資料は、生成されたキーで暗号化されています。
The GM MUST be able to process the Key Download message. <Process KeyDL> indicates the GM actions that will determine how the Key Download message will be acted upon. The following checks SHOULD be performed in the order presented.
GMは、キーダウンロードメッセージを処理できる必要があります。<ProcessKeyDL>は、キーダウンロードメッセージがどのように機能するかを決定するGMアクションを示します。次のチェックを提示された順序で実行する必要があります。
In this procedure, the GM will verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity.
この手順では、GMはメッセージヘッダーが適切に形成されていることを確認し、GroupIDの値をチェックすることにより、このメッセージがこのグループ向けであることを確認します。ヘッダーチェックが合格した場合、GMは、識別ペイロードのメンバーIDをそのIDと比較することにより、このメッセージがそれ自体を意図していることを確認する必要があります。
After identification confirmation, the freshness values are checked. If using nonces, the GM MUST use its saved Nonce_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it to the received Nonce_C value. If not using nonces, the GM MUST check the timestamp in the Signature payload to determine if the message is new.
識別確認後、新鮮さの値がチェックされます。NONSを使用している場合、GMは保存されたNonCE_I値を使用し、受信したGC/KS NonCE_R値を抽出し、組み合わせたNonCE_C値を計算し、受信したNonCE_C値と比較する必要があります。Noncesを使用していない場合、GMは署名ペイロードのタイムスタンプをチェックして、メッセージが新しいかどうかを判断する必要があります。
After freshness is confirmed, the signature MUST be verified to ensure its authenticity. The GM MUST use verified and trusted authentication material from a known root. If the message signature verifies, the key creation material is extracted from the Key Creation payload to generate the KEK. This KEK is then used to decrypt the policy token data. The signature on the policy token MUST be verified. Access control checks MUST be performed on both the GO and the GC/KS to determine both their authorities within this group. After all these checks pass, the KEK can then be used to decrypt and process the key material from the Key Download payload. If all is successful, the GM will create and send the Key Download - Ack/Failure message as described in Section 5.2.1.4.
新鮮さが確認された後、その信ity性を確保するために署名を検証する必要があります。GMは、既知のルートから検証された信頼できる認証資料を使用する必要があります。メッセージの署名が検証された場合、キー作成資料がキー作成ペイロードから抽出され、KEKを生成します。このKEKは、ポリシートークンデータを復号化するために使用されます。ポリシートークンの署名を検証する必要があります。このグループ内の両方の当局を決定するには、GOとGC/KSの両方でアクセス制御チェックを実行する必要があります。これらすべてのチェックが通過した後、KEKを使用して、キーダウンロードペイロードからキーマテリアルを復号化および処理できます。すべてが成功した場合、GMはセクション5.2.1.4で説明されているように、キーダウンロード - ACK/故障メッセージを作成して送信します。
The Policy Token and Key Download Payloads are sent encrypted in the KEK generated by the Key Creation Payload information using the mechanisms defined in the group announcement. This guarantees that the sensitive policy and key data for the group and potential rekey data for this individual cannot be read by anyone but the intended recipient.
ポリシートークンとキーダウンロードペイロードは、グループ発表で定義されたメカニズムを使用して、キー作成ペイロード情報によって生成されたKEKで暗号化された[暗号]を送信されます。これにより、グループの機密ポリシーと重要なデータ、およびこの個人の潜在的な再キーデータは、意図した受信者以外の人が読むことができないことが保証されます。
If any error occurs during KeyDL message processing, regardless of whether the GM is in Terse or Verbose Mode, the registration session MUST be terminated, the GM MUST send a Key Download - Ack/Failure message, and all saved state information MUST be cleared. If in Terse Mode, the Notification Payload will be of type NACK to indicate termination. If in Verbose Mode, the Notification Payload will contain the type of error encountered.
GMがTerseモードか冗長モードであるかに関係なく、KeyDLメッセージ処理中にエラーが発生した場合、登録セッションを終了する必要があり、GMはキーダウンロード-ACK/障害メッセージを送信する必要があり、すべての保存された状態情報をクリアする必要があります。Terseモードの場合、通知ペイロードは終了を示すためにタイプNACKのものになります。冗長モードの場合、通知ペイロードには、遭遇するエラーのタイプが含まれます。
The exchange type for Request to Join Error is eleven (11).
エラーに参加するリクエストの交換タイプは11です（11）。
The components of the Request to Join Error Message are shown in Table 3:
エラーメッセージに参加するリクエストのコンポーネントを表3に示します。
Table 3: Request to Join Error (RTJ-Err) Message Definition
表3：エラー（rtj-err）メッセージの定義に参加するリクエスト
Message Name : Request to Join Error (RTJ-Err)
Dissection : {HDR-GrpID, [Nonce_I], Notification, [VendorID]}
Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID]
In response to an unacceptable RTJ, the GC/KS MAY send a Request to Join Error (RTJ-Err) message containing an appropriate Notification payload. Note that the RTJ-Err message is not a signed message for the following reasons: the lack of awareness on the GM's perspective of who is a valid GC/KS as well as the need to protect the GC/KS from signing messages and using valuable resources. Following the sending of an RTJ-Err, the GC/KS MUST terminate the session, and all saved state information MUST be cleared.
容認できないRTJに応じて、GC/KSは、適切な通知ペイロードを含むエラー（RTJ-ERR）メッセージに参加するリクエストを送信する場合があります。RTJ-ERRメッセージは、次の理由で署名されたメッセージではないことに注意してください。GMの視点に関する認識の欠如は、誰が有効なGC/KSであるか、およびGC/KSを署名メッセージから保護し、価値のある使用から保護する必要性資力。RTJ-ERRの送信後、GC/KSはセッションを終了する必要があり、保存されたすべての状態情報をクリアする必要があります。
Upon receipt of an RTJ-Err message, the GM will validate the following: the GroupID in the header belongs to a group to which the GM has sent an RTJ, and, if present, the Nonce_I matches a Nonce_I sent in an RTJ to that group. If the above checks are successful, the GM MAY terminate the state associated with that GroupID and nonce. The GM SHOULD be capable of receiving a valid KeyDownload message for that GroupID and nonce after receiving an RTJ-Err for a locally configured amount of time.
RTJ-errメッセージを受信すると、GMは次のことを検証します。ヘッダーのGroupIDは、GMがRTJを送信したグループに属し、存在する場合、NonCE_IはRTJで送信されたNonCE_Iと一致します。グループ。上記のチェックが成功した場合、GMはそのGroupIDおよびNonCEに関連する状態を終了する場合があります。GMは、ローカルで構成された時間の間RTJ-ERRを受信した後、そのGroupIDおよびNonCEに対して有効なキーダウンロードメッセージを受信できる必要があります。
The exchange type for Key Download - Ack/Failure is four (4).
キーダウンロードの交換タイプ-ACK/障害は4（4）です。
The components of the Key Download - Ack/Failure Message are shown in Table 4:
キーダウンロードのコンポーネント-ACK/障害メッセージを表4に示します。
Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition
表4：キーダウンロード-ACK/障害（keydl -a/f）メッセージの定義
Message Name : Key Download - Ack/Failure (KeyDL-A/F)
Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
ID], Signature
SigM : Signature of Group Member
{}SigX : Indicates fields used in Signature
In response to a properly processed KeyDL message, the GM creates and sends the KeyDL-A/F message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: Notification payload of type Acknowledgement (ACK) and signature information. If synchronized time is not available, the Nonce payload MUST be present for freshness, and the nonce value transmitted MUST be the GM's generated Nonce_C value. If the GM does not receive a KeyDL message within a locally configured amount of time, the GM MAY send a new RTJ. If the GM receives a valid LOA (see Section 5.2.1.5) message from the GC/KS before receipt of a KeyDL message, the GM SHOULD send a KeyDL-A/F message of type NACK followed by a new RTJ.
適切に処理されたKeyDLメッセージに応じて、GMはKeyDL-A/Fメッセージを作成および送信します。メッセージの分析で定義されているように、このメッセージには、次の情報を保持するためにペイロードを含める必要があります：型承認の通知（ACK）および署名情報。同期された時間が利用できない場合、鮮度のためにノンセペイロードが存在する必要があり、送信されたNonCE値はGMの生成されたNonCE_C値でなければなりません。GMがローカルで構成された時間内にKeyDLメッセージを受信しない場合、GMは新しいRTJを送信する場合があります。GMがkeyDLメッセージを受信する前にGC/ksから有効なLOA（セクション5.2.1.5を参照）メッセージを受信した場合、GMはタイプNACKのKeyDL-A/Fメッセージを送信する必要があります。
The GC/KS MUST be able to process the KeyDL-A/F message. <Process KeyDL-A/F> indicates the GC/KS actions that will determine how the KeyDL-A/F message will be acted upon. The following checks SHOULD be performed in the order presented.
GC/KSは、keydl-a/fメッセージを処理できる必要があります。<process keydl-a/f>は、keydl-a/fメッセージがどのように行動されるかを決定するGC/ksアクションを示します。次のチェックを提示された順序で実行する必要があります。
In this procedure, the GC/KS will verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GC/KS MUST check the message for freshness. If using nonces, the GC/KS MUST use its saved Nonce_C value and compare it for equality with the received Nonce_C value. If not using nonces, the GC/KS MUST check the timestamp in the Signature payload to determine if the message is new. After freshness is confirmed, the signature MUST be verified to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If the message signature verifies, the GC/KS processes the Notification payload. If the notification type is of type ACK, then the registration has completed successfully, and both parties SHOULD remove state information associated with this GM's registration.
この手順では、GC/KSは、メッセージヘッダーが適切に形成されていることを確認し、GroupIDの値をチェックすることにより、このメッセージがこのグループ向けであることを確認します。ヘッダーチェックが通過する場合、GC/KSはメッセージに新鮮さを確認する必要があります。NONSを使用している場合、GC/KSは保存されたNonCE_C値を使用し、受信したNonCE_C値と等しい場合を比較する必要があります。Noncesを使用していない場合、GC/KSは、署名ペイロードのタイムスタンプをチェックして、メッセージが新しいかどうかを判断する必要があります。新鮮さが確認された後、その信ity性を確保するために署名を検証する必要があります。GC/KSは、既知のルートから検証済みの認証資料を使用する必要があります。メッセージの署名が検証された場合、GC/KSは通知ペイロードを処理します。通知タイプがACKタイプの場合、登録は正常に完了し、両当事者はこのGMの登録に関連する州の情報を削除する必要があります。
If the GC/KS does not receive a KeyDL-A/F message of proper form or is unable to correctly process the KeyDL-A/F message, the Notification payload type is any value except ACK; or if no KeyDL-A/F message is received within the locally configured timeout, the GC/KS MUST evict this GM from the group in the next policy-defined Rekey Event. The GC/KS MAY send the OPTIONAL Lack_of_Ack message if running in Verbose Mode as defined in Section 5.2.1.5.
GC/KSが適切なフォームのKeyDL-A/Fメッセージを受け取らない場合、またはKeyDL-A/Fメッセージを正しく処理できない場合、通知ペイロードタイプはACK以外の値です。または、ローカルで構成されたタイムアウト内でKeyDL-A/Fメッセージが受信されない場合、GC/KSは次のポリシー定義のRekeyイベントでこのGMをグループから追い出す必要があります。GC/KSは、セクション5.2.1.5で定義されているように、冗長モードで実行されている場合、オプションのlack_of_ackメッセージを送信する場合があります。
The exchange type for Lack of Ack is twelve (12).
ACKの欠如の交換タイプは12（12）です。
The components of a Lack of Ack Message are shown in Table 5:
ACKメッセージの欠如のコンポーネントを表5に示します。
Table 5: Lack of Ack (LOA) Message Definition
表5：ACK（LOA）メッセージの定義の欠如
Message Name : Lack of Ack (LOA) Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], Notification, [VendorID]} SigC, [Cert] Payload Types : GSAKMP Header, Identification, [Nonce], Notification, [Vendor ID], Signature, [Certificate]
メッセージ名：ACK（LOA）解剖の欠如：{HDR-GRPID、メンバーID、[NonCe_r、NonCe_C]、Notification、[Vendorid]} Sigc、[cert] Payloadタイプ：GSAKMPヘッダー、識別、[NONCE]、通知、[ベンダーID]、署名、[証明書]
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
If the GC/KS's local timeout value expires prior to receiving a KeyDL-A/F from the GM, the GC/KS MAY create and send a LOA message to the GM. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Notification of error, and signature information.
GC/KSのローカルタイムアウト値がGMからKeyDL-A/Fを受信する前に有効期限が切れた場合、GC/KSはGMにLOAメッセージを作成して送信する場合があります。メッセージの分析で定義されているように、このメッセージには、GM識別、エラーの通知、および署名情報を保持するためにペイロードを含める必要があります。
If synchronized time is not available, the Nonce payloads MUST be present for freshness, and the nonce values transmitted MUST be the GC/KS's generated Nonce_R value and the combined Nonce_C value which was generated by using the GC/KS's Nonce_R value and the Nonce_I value received from the GM in the RTJ. These values were already generated during the Key Download message phase.
同期された時間が利用できない場合、鮮度のためにノンセペイロードが存在する必要があり、送信されたNonCE値はGC/KSの生成されたNonCE_R値と、GC/KSのNonCE_R値とnonCE_I値を使用して生成された結合されたノンセ_C値でなければなりませんRTJのGMから受信。これらの値は、キーダウンロードメッセージフェーズ中に既に生成されました。
The GM MAY be able to process the LOA message based upon local configuration. <Process LOA> indicates the GM actions that will determine how the LOA message will be acted upon. The following checks SHOULD be performed in the order presented.
GMは、ローカル構成に基づいてLOAメッセージを処理できる場合があります。<プロセスLOA>は、LOAメッセージがどのように機能するかを決定するGMアクションを示します。次のチェックを提示された順序で実行する必要があります。
In this procedure, the GM MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity. After identification confirmation, the freshness values are checked. If using nonces, the GM MUST use its save Nonce_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it to the received Nonce_C value. If not using nonces, the GM MUST check the timestamp in the Signature payload to determine if the message is new. After freshness is confirmed, access control checks MUST be performed on the GC/KS to determine its authority within this group. Then signature MUST be verified to ensure its authenticity, The GM MUST use verified and trusted authentication material from a known root.
この手順では、GMはメッセージヘッダーが適切に形成されていることを確認し、GroupIDの値をチェックすることにより、このメッセージがこのグループ向けであることを確認する必要があります。ヘッダーチェックが合格した場合、GMは、識別ペイロードのメンバーIDをそのIDと比較することにより、このメッセージがそれ自体を意図していることを確認する必要があります。識別確認後、新鮮さの値がチェックされます。NONSを使用している場合、GMはその保存NonCE_I値を使用し、受信したGC/KS NonCE_R値を抽出し、組み合わせたNonCE_C値を計算し、受信したNonCE_C値と比較する必要があります。Noncesを使用していない場合、GMは署名ペイロードのタイムスタンプをチェックして、メッセージが新しいかどうかを判断する必要があります。新鮮さが確認された後、このグループ内の権限を決定するには、GC/KSでアクセス制御チェックを実行する必要があります。次に、その信頼性を確保するために署名を検証する必要があり、GMは既知のルートから検証済みおよび信頼できる認証資料を使用する必要があります。
If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that session.
チェックが成功した場合、GMはそのセッションのKeyDL-A/Fを再送信する必要があります。
This section defines an OPTIONAL capability that MAY be implemented into GSAKMP when using IP-based groups. The information in this section borrows heavily from [IKEv2] as this protocol has already worked through this issue and GSAKMP is copying this concept. This section will contain paraphrased sections of [IKEv2] modified for GSAKMP to define the purpose of Cookies.
このセクションでは、IPベースのグループを使用するときにGSAKMPに実装できるオプションの機能を定義します。このセクションの情報は[IKEV2]から大きく借用しています。このプロトコルはすでにこの問題を通じて機能しており、GSAKMPはこの概念をコピーしています。このセクションには、GSAKMPがCookieの目的を定義するために変更された[IKEV2]の言い換えられたセクションが含まれます。
An optional Cookie mode is being defined for the GSAKMP to help against DoS attacks.
GSAKMPがDOS攻撃を支援するために、オプションのCookieモードが定義されています。
The term "cookies" originates with Karn and Simpson [RFC2522] in Photuris, an early proposal for key management with IPSec. The ISAKMP fixed message header includes two eight-octet fields titled "cookies". Instead of placing this cookie data in the header, in GSAKMP this data is moved into a Notification payload.
「Cookies」という用語は、IPSECの主要な管理の初期の提案であるPhyurisのKarnとSimpson [RFC2522]に由来しています。ISAKMP固定メッセージヘッダーには、「Cookies」というタイトルの2つの8オクテットフィールドが含まれています。このCookieデータをヘッダーに配置する代わりに、GSAKMPでは、このデータは通知ペイロードに移動されます。
An expected attack against GSAKMP is state and CPU exhaustion, where the target GC/KS is flooded with Request to Join requests from forged IP addresses. This attack can be made less effective if a GC/KS implementation uses minimal CPU and commits no state to the communication until it knows the initiator potential GM can receive packets at the address from which it claims to be sending them. To accomplish this, the GC/KS (when operating in Cookie mode) SHOULD reject initial Request to Join messages unless they contain a Notification payload of type "cookie". It SHOULD instead send a Cookie Download message as a response to the RTJ and include a cookie in a notify payload of type Cookie_Required. Potential GMs who receive such responses MUST retry the Request to Join message with the responder-GC/KS-supplied cookie in its notification payload of type Cookie, as defined by the optional Notification payload of the Request to Join Msg in Section 5.2.1.1. This initial exchange will then be as shown in Figure 2 with the components of the new message Cookie Download shown in Table 6. The exchange type for Cookie Download is ten (10).
GSAKMPに対する予想される攻撃は、状態およびCPU疲労であり、ターゲットGC/KSは、偽造IPアドレスからのリクエストに参加するリクエストであふれています。GC/KSの実装が最小限のCPUを使用し、イニシエーターの潜在的なGMがそれらを送信していると主張するアドレスでパケットを受信できることがわかるまで、コミュニケーションに状態をコミットしない場合、この攻撃は効果を低下させることができます。これを達成するために、GC/KS（Cookieモードで操作する場合）は、「Cookie」の通知ペイロードが含まれていない限り、メッセージに参加するための初期リクエストを拒否する必要があります。代わりに、RTJへの応答としてCookieダウンロードメッセージを送信し、Cookie_Requiredタイプの通知ペイロードにCookieを含める必要があります。そのような応答を受け取る潜在的なGMは、セクション5.2.1.1に参加するリクエストのオプションの通知ペイロードで定義されているように、タイプCookieの通知ペイロードで、Responder-GC/KS-Supplied Cookieでメッセージを結合するリクエストを再試行する必要があります。この最初の交換は、図2に示すように、表6に示す新しいメッセージCookieダウンロードのコンポーネントとともに、Cookieダウンロードの交換タイプは10（10）です。
CONTROLLER MESSAGE MEMBER
in Cookie Mode
!<--Request to Join without Cookie Info---!
<Gen Cookie>! !
<Response >! !
!----------Cookie Download--------------->!
! ! <Process CD>
!<----Request to Join with Cookie Info----!
<Process> ! !
<RTJ > ! !
!-------------Key Download--------------->!
! ! <Proc KeyDL>
!<-----Key Download - Ack/Failure--------!
<Process >! !
<KeyDL-A/F>! !
!<=======SHARED KEYED GROUP SESSION======>!
Figure 2: GSAKMP Ladder Diagram with Cookies
図2：Cookieを備えたGSAKMPラダー図
Table 6: Cookie Download Message Definition
表6：クッキーのダウンロードメッセージの定義
Message Name : Cookie Download
Dissection : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]}
Payload Types : GSAKMP Header, Notification, [Vendor ID]
The first two messages do not affect any GM or GC/KS state except for communicating the cookie.
最初の2つのメッセージは、Cookieの通信を除いて、GMまたはGC/KS状態には影響しません。
A GSAKMP implementation SHOULD implement its GC/KS cookie generation in such a way as not to require any saved state to recognize its valid cookie when the second Request to Join message arrives. The exact algorithms and syntax they use to generate cookies does not affect interoperability and hence is not specified here.
GSAKMPの実装では、GC/KS Cookieの生成を実装する必要があります。これにより、メッセージに参加する2番目のリクエストが到着したときに有効なCookieを認識するように保存された状態を要求しないようにします。Cookieを生成するために使用する正確なアルゴリズムと構文は、相互運用性に影響しないため、ここでは指定されません。
The following is an example of how an endpoint could use cookies to implement limited DoS protection.
以下は、エンドポイントがCookieを使用して限られたDOS保護を実装する方法の例です。
A good way to do this is to set the cookie to be:
これを行う良い方法は、クッキーを次のように設定することです。
Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>)
where <secret> is a randomly generated secret known only to the responder GC/KS and periodically changed, Ni is the nonce value taken from the initiator potential GM, and IPi is the asserted IP address of the candidate GM. The IP address is either the IP header's source IP address or else the IP address contained in the optional Notification "IPvalue" payload (if it is present). <SecretVersionNumber> should be changed whenever <secret> is regenerated. The cookie can be recomputed when the "Request to Join with Cookie Info" arrives and compared to the cookie in the received message. If it matches, the responder GC/KS knows that all values have been computed since the last change to <secret> and that IPi MUST be the same as the source address it saw the first time. Incorporating Ni into the hash assures that an attacker who sees only the Cookie_Download message cannot successfully forge a "Request to Join with Cookie Info" message. This Ni value MUST be the same Ni value from the original "Request to Join" message for the calculation to be successful.
<Secret>は、Responder GC/KSのみで知られているランダムに生成された秘密であり、定期的に変更された場合、NIはイニシエーターの潜在的なGMから取得したNonCE値であり、IPIは候補GMの主張されたIPアドレスです。IPアドレスは、IPヘッダーのソースIPアドレスまたはオプションの通知「IPValue」ペイロード（存在する場合）に含まれるIPアドレスのいずれかです。<SecretVersionNumber>は、<secret>が再生されるたびに変更する必要があります。クッキーは、「Cookie情報に参加するリクエスト」が到着し、受信したメッセージのCookieと比較したときに再計算できます。一致する場合、Responder GC/KSは、<secret>への最後の変更以来すべての値が計算されており、IPIが初めて見たソースアドレスと同じでなければならないことを知っています。HashにNiを組み込むと、Cookie_Downloadメッセージのみを見る攻撃者が「Cookie Infoに参加するリクエスト」メッセージを正常に偽造できないことを保証します。このNi値は、計算が成功するための元の「リクエストの参加」メッセージと同じNi値でなければなりません。
If a new value for <secret> is chosen while connections are in the process of being initialized, a "Request to Join with Cookie Info" might be returned with a <SecretVersionNumber> other than the current one. The responder GC/KS in that case MAY reject the message by sending another response with a new cookie, or it MAY keep the old value of <secret> around for a short time and accept cookies computed from either one. The responder GC/KS SHOULD NOT accept cookies indefinitely after <secret> is changed, since that would defeat part of the denial of service protection. The responder GC/KS SHOULD change the value of <secret> frequently, especially if under attack.
接続が初期化されている間に<secret>の新しい値が選択されている場合、「Cookie情報に参加するリクエスト」は、現在のもの以外の<secretVersionNumber>で返される場合があります。その場合のレスポンダーGC/ksは、新しいCookieで別の応答を送信することによりメッセージを拒否するか、<secret>の古い価値を短時間維持し、いずれかから計算されたCookieを受け入れることがあります。レスポンダーGC/ksは、<secret>が変更された後、無期限にCookieを受け入れるべきではありません。レスポンダーGC/KSは、特に攻撃を受けている場合、<secret>の値を頻繁に変更する必要があります。
An alternative example for Cookie value generation in a NAT environment is to substitute the IPi value with the IPValue received in the Notification payload in the RTJ message. This scenario is indicated by the presence of the Notification payload of type IPValue. With this substitution, a calculation similar to that described above can be used.
NAT環境でのCookie値生成の別の例は、IPI値をRTJメッセージの通知ペイロードで受信したIPValueに置き換えることです。このシナリオは、タイプIPValueの通知ペイロードの存在によって示されます。この置換を使用すると、上記の計算と同様の計算を使用できます。
This section describes an OPTIONAL capability that may be implemented in a structured system where the authorized (S-)GC/KS is known in advance through out-of-band means and where synchronized time is available.
このセクションでは、承認された（S-）GC/KSがバンド外の手段を通じて事前に知られており、同期された時間が利用可能な構造化されたシステムに実装される可能性のあるオプションの機能について説明します。
Unlike Standard Group Establishment, in the Receive-Only system, the GMs and (S-)GC/KSes operate in Terse Mode and exchange one message only: the Key Download. Potential new GMs do not send an RTJ. (S-)GC/KSes do not expect Key Download - ACK/Failure messages and do not remove GMs for lack or receipt of the message.
標準グループの確立とは異なり、受信専用システムでは、GMSおよび（S-）GC/KSEはTerseモードで動作し、1つのメッセージのみを交換するキーダウンロードのみを交換します。潜在的な新しいGMはRTJを送信しません。（S-）GC/KSESはキーダウンロードを期待していません - ACK/障害メッセージは、メッセージの不足または受信のためにGMSを削除しません。
Operation is as follows: upon notification via an authorized out-of-band event, the (S-)GC/KS forms and sends a Key Download message to the new member with the Nonce payloads ABSENT. The GM verifies
操作は次のとおりです。承認された帯域外イベントを介して通知すると、（S-）GC/KSは、NONCEペイロードがない状態で新しいメンバーにキーダウンロードメッセージをフォームに送信し、送信します。GMは検証します
- the ID payload identifies that GM
- IDペイロードは、そのGMを識別します
- the timestamp in the message is fresh
- メッセージのタイムスタンプは新鮮です
- the message is signed by an authorized (S-)GC/KS
- メッセージは、承認された（s-）GC/ksによって署名されています
- the signature on the message verifies
- メッセージの署名は検証されます
When using a Diffie-Hellman Key Creation Type for receive-only members, a static-ephemeral model is assumed: the Key Creation payload in the Key Download message contains the (S-)GC/KS's public component. The member's public component is assumed to be obtained through secure out-of-band means.
受信専用メンバーにdiffie-hellmanキー作成タイプを使用する場合、静的な著作権モデルが想定されます。キーダウンロードメッセージのキー作成ペイロードには、（S-）GC/KSのパブリックコンポーネントが含まれます。メンバーのパブリックコンポーネントは、安全な帯域外の手段を通じて取得されると想定されています。
The Group Maintenance phase includes member joins and leaves, group rekey activities, policy updates, and group destruction. These activities are presented in the following sections.
グループのメンテナンスフェーズには、メンバーの参加と葉、グループの再キーのアクティビティ、ポリシーの更新、およびグループの破壊が含まれます。これらのアクティビティは、次のセクションに記載されています。
A Rekey Event is any action, including a compromise report or key expiration, that requires the creation of a new group key and/or rekey information.
Rekeyイベントは、新しいグループキーおよび/またはRekey情報の作成が必要な、妥協レポートやキーの有効期限を含むあらゆるアクションです。
Once an event has been identified (as defined in the group security policy token), the GC/KS MUST create and provide a signed message containing the GTPK and rekey information to the group.
イベントが特定されたら（グループセキュリティポリシートークンで定義されているように）、GC/KSは、GTPKと再キーを含む署名入りのメッセージをグループに作成して提供する必要があります。
Each GM who receives this message MUST verify the signature on the message to ensure its authenticity. If the message signature does not verify, the message MUST be discarded. Upon verification, the GM will find the appropriate rekey download packet and decrypt the information with a stored rekey key(s). If a new Policy Token is distributed with the message, it MUST be encrypted in the old GTPK.
このメッセージを受信した各GMは、その信ity性を確保するために、メッセージの署名を確認する必要があります。メッセージ署名が確認されない場合、メッセージを破棄する必要があります。検証されると、GMは適切なRekeyダウンロードパケットを見つけ、保存されたRekeyキーを使用して情報を復号化します。新しいポリシートークンがメッセージで配布されている場合、古いGTPKで暗号化する必要があります。
The exchange type for Rekey Event is five (5).
Rekeyイベントの交換タイプは5（5）です。
The components of a Rekey Event message are shown in Table 7:
Rekeyイベントメッセージのコンポーネントを表7に示します。
Table 7: Rekey Event Message Definition
表7：再キーイベントメッセージの定義
Message Name : Rekey Event Dissection : {HDR-GrpID, ([Policy Token])*, Rekey Array, [VendorID]}SigC, [Cert] Payload Types : GSAKMP Header, [Policy Token], Rekey Event, [Vendor ID], Signature, [Certificate],
メッセージ名：Rekeyイベント解剖：{hdr-grpid、（[policy token]）*、rekey array、[vendorid]} sigc、[cert]ペイロードタイプ：gsakmpヘッダー、[ポリシートークン]、Rekey Event、[Vendor ID]、署名、[証明書]、
SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
(data)* : Indicates encrypted information
[] : Indicate an optional data item
New policy tokens are sent via the Rekey Event message. These policy updates may be coupled with an existing rekey event or may be sent in a message with the Rekey Event Type of the Rekey Event Payload set to None(0) (see Section 7.5.1).
新しいポリシートークンは、Rekeyイベントメッセージを介して送信されます。これらのポリシーの更新は、既存のRekeyイベントと組み合わされている場合があります。また、RekeyイベントタイプのRekeyイベントペイロードがなし（0）に設定されたメッセージで送信される場合があります（セクション7.5.1を参照）。
A policy token MUST NOT be processed if the processing of the Rekey Event message carrying it fails. Policy token processing is type dependent and is beyond the scope of this document.
ポリシートークンは、それを伝えるRekeyイベントメッセージの処理が失敗した場合、処理してはなりません。ポリシートークン処理はタイプに依存し、このドキュメントの範囲を超えています。
Group destruction is also accomplished via the Rekey Event message. In a Rekey Event message for group destruction, the Sequence ID is set to 0xFFFFFFFF. Upon receipt of this authenticated Rekey Event message, group components MUST terminate processing of information associated with the indicated group.
グループの破壊は、Rekeyイベントメッセージを介しても達成されます。グループ破壊のためのRekeyイベントメッセージでは、シーケンスIDが0xfffffffffに設定されています。この認証されたRekeyイベントメッセージを受信すると、グループコンポーネントは、指定されたグループに関連付けられた情報の処理を終了する必要があります。
There are several conditions under which a member will leave a group: eviction, voluntary departure without notice, and voluntary departure with notice (de-registration). Each of these is discussed in this section.
メンバーがグループを去るいくつかの条件があります：立ち退き、通知なしに自発的な出発、および通知による自発的な出発（登録解除）。これらのそれぞれについては、このセクションで説明します。
At some point in the group's lifetime, it may be desirable to evict one or more members from a group. From a key management viewpoint, this involves revoking access to the group's protected data by "disabling" the departing members' keys. This is accomplished with a Rekey Event, which is discussed in more detail in Section 5.3.1.1. If future access to the group is also to be denied, the members MUST be added to a denied access control list, and the policy token's authorization rules MUST be appropriately updated so that they will exclude the expelled GM(s). After receipt of a new PT, GMs SHOULD evaluate the trustworthiness of any recent application data originating from the expelled GM(s).
グループの生涯のある時点で、グループから1人以上のメンバーを追い出すことが望ましい場合があります。主要な管理の観点から、これには、出発したメンバーの鍵を「無効」することにより、グループの保護されたデータへのアクセスを取り消すことが含まれます。これは、セクション5.3.1.1で詳細に説明するRekeyイベントで実現されます。グループへの将来のアクセスも拒否される場合、メンバーは拒否されたアクセス制御リストに追加されなければならず、ポリシートークンの承認ルールは、追放されたGMを除外するように適切に更新する必要があります。新しいPTを受け取った後、GMは、排出されたGM（S）から発生する最近のアプリケーションデータの信頼性を評価する必要があります。
If a member wishes to leave a group for which membership imposes no cost or responsibility to that member, then the member MAY merely delete local copies of group keys and cease group activities.
メンバーがそのメンバーに費用や責任を課さないグループを辞めたい場合、メンバーは単にグループキーのローカルコピーを削除し、グループアクティビティを停止するだけです。
If the membership in the group does impose cost or responsibility to the departing member, then the member SHOULD de-register from the group when that member wishes to leave. De-registration consists of a three-message exchange between the GM and the member's GC/KS: the Request_to_Depart, Departure_Response, and the Departure_Ack. Compliant GSAKMP implementations for GMs SHOULD support the de-registration messages. Compliant GSAKMP implementations for GC/KSes MUST support the de-registration messages.
グループのメンバーシップが出発メンバーにコストまたは責任を課す場合、メンバーはそのメンバーが去りたいときにグループから登録解除する必要があります。登録は、GMとメンバーのGC/KSの間の3メッセージの交換で構成されています：request_to_depart、deport_response、およびletaple_ack。GMSの準拠のGSAKMP実装は、登録解除メッセージをサポートする必要があります。GC/KSEの準拠のGSAKMP実装は、登録解除メッセージをサポートする必要があります。
The Exchange Type for a Request_to_Depart Message is thirteen (13). The components of a Request_to_Depart Message are shown in Table 8.
request_to_departメッセージの交換タイプは13（13）です。request_to_departメッセージのコンポーネントを表8に示します。
Any GM desiring to initiate the de-registration process MUST generate and send an RTD message to notify the GC/KS of its intent. As defined in the dissection of the RTD message, this message MUST contain payloads to hold the following information: the GC/KS identification and Notification of the desire to leave the group.
登録解除プロセスを開始したいGMは、GC/KSにその意図を通知するためにRTDメッセージを生成および送信する必要があります。RTDメッセージの分析で定義されているように、このメッセージには、次の情報を保持するためにペイロードを含める必要があります。GC/KSの識別とグループを離れたいという欲求の通知。
When synchronization time is not available to the system as defined by the Policy Token, a Nonce payload MUST be included for freshness, and the Nonce_I value MUST be saved for later use. This message MUST then be signed by the GM.
ポリシートークンで定義されているように、システムが同期する時間が利用できない場合、鮮度のためにノンセペイロードを含める必要があり、後で使用するにはnonCE_I値を保存する必要があります。このメッセージは、GMによって署名する必要があります。
Table 8: Request_to_Depart (RTD) Message Definition
表8：request_to_depart（RTD）メッセージ定義
Message Name : Request_to_Depart (RTD) Dissection : {HDR-GrpID, GC/KS_ID, [Nonce_I], Notif_Leave_Group, [VendorID]} SigM, [Cert] Payload Types : GSAKMP Header, Identification, [Nonce], Notification, [Vendor ID], Signature, [Certificate]
メッセージ名：request_to_depart（rtd）quationection：{hdr-grpid、gc/ks_id、[nonce_i]、notif_leave_group、[vendorid]} sigm、[cert]ペイロードタイプ：gsakmpヘッダー、識別、[nonce]、[nonceifification、bendor id]、署名、[証明書]
SigM : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
Upon receipt of the RTD message, the GC/KS MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, then the identifier value in Identification payload is compared to its own, the GC/KS's identity, to confirm that the GM intended to converse with this GC/KS, the GC/KS who registered this member into the group. Then the identity of the sender is extracted from the Signature payload. This identity MUST be used to confirm that this GM is a member of the group serviced by this GC/KS. Then the GC/KS will confirm from the Notification payload that the GM is requesting to leave the group. Then the GC/KS will verify the signature on the message to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If all checks pass and the message is successfully processed, then the GC/KS MUST form a Departure_Response message as defined in Section 5.3.2.3.2.
RTDメッセージを受信すると、GC/KSはメッセージヘッダーが適切に形成されていることを確認し、GroupIDの値をチェックすることにより、このメッセージがこのグループ向けであることを確認する必要があります。ヘッダーチェックが渡された場合、識別ペイロードの識別子値はGC/KSのIDと比較され、GMがこのGC/KSと会話することを意図したことを確認します。。次に、送信者の身元が署名ペイロードから抽出されます。このIDは、このGMがこのGC/KSがサービスを提供するグループのメンバーであることを確認するために使用する必要があります。その後、GC/KSは、通知ペイロードからGMがグループを離れることを要求していることを確認します。GC/KSは、メッセージの署名を検証して、その信頼性を確保します。GC/KSは、既知のルートから検証済みの認証資料を使用する必要があります。すべてのチェックが通過し、メッセージが正常に処理された場合、GC/KSはセクション5.3.2.3.2で定義されているように、dovely_responseメッセージを形成する必要があります。
If the processing of the message fails, the de-registration session MUST be terminated, and all state associated with this session is removed. If the GC/KS is operating in Terse Mode, then no error message is sent to the GM. If the GC/KS is operating in Verbose Mode, then the GC/KS sends a Departure_Response Message with a Notification Payload of type Request_to_Depart_Error.
メッセージの処理が失敗した場合、登録解除セッションを終了する必要があり、このセッションに関連するすべての状態が削除されます。GC/KSがTerseモードで動作している場合、エラーメッセージはGMに送信されません。GC/ksが冗長モードで動作している場合、GC/KSは、タイプrequest_TO_DEPART_ERRORの通知ペイロードを使用して出発_ Responseメッセージを送信します。
The Exchange Type for a Departure_Response Message is fourteen (14). The components of a Departure_Response Message are shown in Table 9.
deprace_responseメッセージの交換タイプは14（14）です。leate_responseメッセージのコンポーネントを表9に示します。
In response to a properly formed and verified RTD message, the GC/KS MUST create and send the DR message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Notification for acceptance of departure, and signature information. If synchronization time is not available, the Nonce payloads MUST be included in the message for freshness.
適切に形成および検証されたRTDメッセージに応じて、GC/KSはDRメッセージを作成して送信する必要があります。メッセージの分析で定義されているように、このメッセージには、GM識別、出発の受け入れ通知、および署名情報を保持するためにペイロードを含める必要があります。同期時間が利用できない場合、NONCEペイロードは新鮮さのメッセージに含める必要があります。
Table 9: Departure_Response (DR) Message Definition
表9：leation_response（DR）メッセージの定義
Message Name : Departure_Response (DR) Dissection : {HDR-GrpID, Member_ID, [Nonce_R, Nonce_C], Notification, [VendorID]} SigC, [Cert] Payload Types : GSAKMP Header, Identification, [Nonce], Notification, [Vendor ID], Signature, [Certificate]
メッセージ名：departing_response（dr）dessection：{hdr-grpid、member_id、[nonce_r、nonce_c]、notification、[vendorid]} sigc、[cert]ペイロードタイプ：gsakmpヘッダー、識別、[nonce]、notification、[vendor id id]、署名、[証明書]
SigC : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX : Indicates fields used in Signature
[] : Indicate an optional data item
If present, the nonce values transmitted MUST be the GC/KS's generated Nonce_R value and the combined Nonce_C value that was generated by using the GC/KS's Nonce_R value and the Nonce_I value received from the GM in the RTD. This Nonce_C value MUST be saved relative to this departing GM's ID.
存在する場合、送信されたNonCE値は、GC/KSのNonCE_R値とRTDのGMから受信したNonCE_I値を使用して生成されたGC/KSの生成されたNonCE_R値と結合されたNonCE_C値でなければなりません。このNonCE_C値は、この出発GMのIDに対して保存する必要があります。
The GM MUST be able to process the Departure_Response message. The following checks SHOULD be performed in the order presented.
GMは、deplation_responseメッセージを処理できる必要があります。次のチェックを提示された順序で実行する必要があります。
The GM MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity. After identification confirmation, the freshness values are checked. If using nonces, the GM MUST use its saved Nonce_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it for equality with the received Nonce_C value. If not using nonces, the GM MUST check the timestamp in the signature payload to determine if the message is new. After freshness is confirmed, confirmation of the identity of the signer of the DR message is the GMs authorized GC/KS is performed. Then, the signature MUST be verified to ensure its authenticity. The GM MUST use verified and trusted authentication material from a known root. If the message signature verifies, then the GM MUST verify that the Notification is of Type Departure_Accepted or Request_to_Depart_Error.
GMは、メッセージヘッダーが適切に形成されていることを確認し、GroupIDの値をチェックすることにより、このメッセージがこのグループ向けであることを確認する必要があります。ヘッダーチェックが合格した場合、GMは、識別ペイロードのメンバーIDをそのIDと比較することにより、このメッセージがそれ自体を意図していることを確認する必要があります。識別確認後、新鮮さの値がチェックされます。Noncesを使用している場合、GMは保存されたNonCE_I値を使用し、受信したGC/KS NonCE_R値を抽出し、Combined NonCE_C値を計算し、受信したNonCE_C値と等式と比較する必要があります。Noncesを使用していない場合、GMは署名ペイロードのタイムスタンプをチェックして、メッセージが新しいかどうかを判断する必要があります。新鮮さが確認された後、DRメッセージの署名者のアイデンティティの確認がGMS認定GC/KSが実行されることです。次に、信頼性を確保するために署名を検証する必要があります。GMは、既知のルートから検証された信頼できる認証資料を使用する必要があります。メッセージの署名が検証された場合、GMは通知がタイプのleate_acceptedまたはrequest_to_depart_errorであることを確認する必要があります。
If the processing is successful, and the Notification payload is of type Departure_Accepted, the member MUST form the Departure_ACK message as defined in Section 5.3.2.3.3. If the processing is successful, and the Notification payload is of type Request_to_Depart_Error, the member MUST remove all state associated with the de-registration session. If the member still desires to De-Register from the group, the member MUST restart the de-registration process.
処理が成功し、通知ペイロードが型出発_Acceptedのタイプである場合、メンバーはセクション5.3.2.3.3で定義されているようにdepart_ackメッセージを形成する必要があります。処理が成功し、通知のペイロードがタイプリクエスト_TO_DEPART_ERRORである場合、メンバーは登録解除セッションに関連するすべての状態を削除する必要があります。メンバーがまだグループから登録解除を希望する場合、メンバーは登録解除プロセスを再開する必要があります。
If the processing of the message fails, the de-registration session MUST be terminated, and all state associated with this session is removed. If the GM is operating in Terse Mode, then a Departure_Ack Message with Notification Payload of type NACK is sent to the GC/KS. If the GM is operating in Verbose Mode, then the GM sends a Departure_Ack Message with a Notification Payload of the appropriate failure type.
メッセージの処理が失敗した場合、登録解除セッションを終了する必要があり、このセッションに関連するすべての状態が削除されます。GMがTerseモードで動作している場合、タイプNACKの通知ペイロードを含む出発_ACKメッセージがGC/KSに送信されます。GMが冗長モードで動作している場合、GMは適切な障害タイプの通知ペイロードを使用して出発_ACKメッセージを送信します。
The Exchange Type for a Departure_ACK Message is fifteen (15). The components of the Departure_ACK Message are shown in Table 10:
出発_ACKメッセージの交換タイプは15（15）です。leation_ackメッセージのコンポーネントを表10に示します。
Table 10: Departure_ACK (DA) Message Definition
表10：departing_ack（da）メッセージの定義
Message Name : Departure_ACK (DA)
Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
ID], Signature
SigM : Signature of Group Member
{}SigX : Indicates fields used in Signature
In response to a properly processed Departure_Response message, the GM MUST create and send the Departure_ACK message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: Notification payload of type Acknowledgement (ACK) and signature information. If synchronization time is not available, the Nonce payload MUST be present for freshness, and the nonce value transmitted MUST be the GM's generated Nonce_C value.
適切に処理されたdeparting_responseメッセージに応じて、GMはdeplated_ackメッセージを作成して送信する必要があります。メッセージの分析で定義されているように、このメッセージには、次の情報を保持するためにペイロードを含める必要があります：型承認の通知（ACK）および署名情報。同期時間が利用できない場合、NonCEペイロードは鮮度のために存在する必要があり、送信されるNonCE値はGMの生成されたNonCE_C値でなければなりません。
Upon receipt of the Departure_ACK, the GC/KS MUST perform the following checks. These checks SHOULD be performed in the order presented.
departing_ackを受け取ると、GC/ksは次のチェックを実行する必要があります。これらのチェックは、提示された順序で実行する必要があります。
In this procedure, the GC/KS MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GC/KS MUST check the message for freshness. If using nonces, the GC/KS MUST use its saved Nonce_C value and compare it to the received Nonce_C value. If not using nonces, the GC/KS MUST check the timestamp in the signature payload to determine if the message is new. After freshness is confirmed, the signature MUST be verified to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If the message signature verifies, the GC/KS processes the Notification payload. If the notification type is of type ACK, this is considered a successful processing of this message.
この手順では、GC/KSは、メッセージヘッダーが適切に形成されていることを確認し、GroupIDの値をチェックすることにより、このメッセージがこのグループ向けであることを確認する必要があります。ヘッダーチェックが通過する場合、GC/KSはメッセージに新鮮さを確認する必要があります。NONSを使用している場合、GC/KSは保存されたNonCE_C値を使用し、受信したNonCE_C値と比較する必要があります。Noncesを使用していない場合、GC/KSは、署名ペイロードのタイムスタンプをチェックして、メッセージが新しいかどうかを判断する必要があります。新鮮さが確認された後、その信ity性を確保するために署名を検証する必要があります。GC/KSは、既知のルートから検証済みの認証資料を使用する必要があります。メッセージの署名が検証された場合、GC/KSは通知ペイロードを処理します。通知タイプがACKタイプの場合、これはこのメッセージの成功した処理と見なされます。
If the processing of the message is successful, the GC/KS MUST remove the member from the group. This MAY involve initiating a Rekey Event for the group.
メッセージの処理が成功した場合、GC/KSはグループからメンバーを削除する必要があります。これには、グループのRekeyイベントの開始が含まれる場合があります。
If the processing of the message fails or if no Departure_Ack is received, the GC/KS MAY issue a LOA message.
メッセージの処理が失敗した場合、または出発_ACKが受信されない場合、GC/KSはLOAメッセージを発行する場合があります。
The Security Definition Suite 1 MUST be supported. Other security suite definitions MAY be defined in other Internet specifications.
セキュリティ定義スイート1をサポートする必要があります。他のセキュリティスイート定義は、他のインターネット仕様で定義される場合があります。
All potential GMs will have enough information available to them to use the correct Security Suite to join the group. This can be accomplished by a well-known default suite, 'Security Suite 1', or by announcing/posting another suite.
すべての潜在的なGMSには、グループに参加するために正しいセキュリティスイートを使用するのに十分な情報が利用可能です。これは、よく知られているデフォルトスイート「セキュリティスイート1」、または別のスイートの発表/投稿によって達成できます。
GSAKMP implementations MUST support the following suite of algorithms and configurations. The following definition of Suite 1 borrows heavily from IKE's Oakley group 2 definition and Oakley itself.
GSAKMPの実装は、以下のアルゴリズムと構成スイートをサポートする必要があります。スイート1の次の定義は、IkeのOakley Group 2の定義とOakley自体から大きく借用しています。
The GSAKMP Suite 1 definition gives all the algorithm and cryptographic definitions required to process group establishment messages. It is important to note that GSAKMP does not negotiate these cryptographic mechanisms. This definition is set by the Group Owner via the Policy Token (passed during the GSAKMP exchange for member verification purposes).
GSAKMPスイート1定義は、グループの確立メッセージを処理するために必要なすべてのアルゴリズムと暗号化の定義を提供します。GSAKMPはこれらの暗号化メカニズムを交渉しないことに注意することが重要です。この定義は、グループ所有者によってポリシートークンを介して設定されます（メンバー検証目的でGSAKMP Exchangeで渡されます）。
The GSAKMP Suite 1 definition is:
GSAKMPスイート1定義は次のとおりです。
Key download and Policy Token encryption algorithm definition: Algorithm: AES Mode: CBC Key Length: 128 bits
キーダウンロードとポリシートークン暗号化アルゴリズム定義：アルゴリズム：AESモード：CBCキー長：128ビット
Policy Token digital signature algorithm is: DSS-ASN1-DER Hash algorithm is: SHA-1
ポリシートークンデジタル署名アルゴリズムは次のとおりです。DSS-ASN1-DERハッシュアルゴリズムは次のとおりです。
Nonce Hash algorithm is: SHA-1
NonCe Hashアルゴリズムは次のとおりです。SHA-1
The Key Creation definition is: Algorithm type is Diffie Hellman MODP group definition g: 2 p: "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1" "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD" "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245" "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED" "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381" "FFFFFFFF FFFFFFFF"
キー作成の定義は次のとおりです。アルゴリズムタイプはディフェルマンMODPグループ定義G：2 P： "FFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1" " B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 "" E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7EDED"" EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 "" fffffff ffffffff ""
NOTE: The p and g values come from IKE [RFC2409], Section 6.2, "Second Oakley Group", and p is 1024 bits long.
注：PおよびG値は、IKE [RFC2409]、セクション6.2、「2番目のオークリーグループ」、Pの長さ1024ビットからのものです。
The GSAKMP message digital signature algorithm is: DSS-SHA1-ASN1-DER
GSAKMPメッセージデジタル署名アルゴリズムは、DSS-SHA1-ASN1-DERです
The digital signature ID type is: ID-DN-STRING
デジタル署名IDタイプは次のとおりです。id-dn-string
A GSAKMP Message is composed of a GSAKMP Header (Section 7.1) followed by at least one GSAKMP Payload. All GSAKMP Payloads are composed of the Generic Payload Header (Section 7.2) followed by the specific payload data. The message is chained by a preceding payload defining its succeeding payload. Payloads are not required to be in the exact order shown in the message dissection in Section 5, provided that all required payloads are present. Unless it is explicitly stated in a dissection that multiple payloads of a single type may be present, no more than one payload of each type allowed by the message may appear. The final payload in a message will point to no succeeding payload.
GSAKMPメッセージは、GSAKMPヘッダー（セクション7.1）で構成され、その後少なくとも1つのGSAKMPペイロードが続きます。すべてのGSAKMPペイロードは、一般的なペイロードヘッダー（セクション7.2）で構成され、その後特定のペイロードデータが続きます。メッセージは、その後のペイロードを定義する前のペイロードによってチェーンされます。ペイロードは、必要なすべてのペイロードが存在する場合、セクション5のメッセージ切開に示されている正確な順序である必要はありません。解剖で明示的に記載されていない限り、単一のタイプの複数のペイロードが存在する可能性があることを明示的に述べていない限り、メッセージで許可されている各タイプのペイロードが1つしか表示されない可能性があります。メッセージ内の最後のペイロードは、後続のペイロードを指しません。
All fields of type integer in the Header and Payload structure that are larger than one octet MUST be converted into Network Byte Order prior to data transmission.
ヘッダーのタイプ整数のすべてのフィールドと1つのオクテットよりも大きいペイロード構造は、データ送信の前にネットワークバイト順に変換する必要があります。
Padding of fields MUST NOT be done as this leads to processing errors.
フィールドのパディングは、処理エラーにつながるため、実行してはなりません。
When a message contains a Vendor ID payload, the processing of the payloads of that message is modified as defined in Section 7.10.
メッセージにベンダーIDペイロードが含まれている場合、そのメッセージのペイロードの処理は、セクション7.10で定義されているように変更されます。
The GSAKMP Header fields are shown in Figure 3 and defined as:
GSAKMPヘッダーフィールドを図3に示し、次のように定義しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! GroupID Type ! GroupID Length! Group ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Next Payload ! Version ! Exchange Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GSAKMP Header Format
図3：GSAKMPヘッダー形式
Group Identification Type (1 octet) - Table 11 presents the group identification types. This field is treated as an unsigned value.
グループ識別タイプ（1オクテット） - 表11は、グループ識別タイプを示しています。このフィールドは、署名されていない値として扱われます。
Table 11: Group Identification Types
表11：グループ識別タイプ
Grp ID Type Value Description
_____________________________________________________________________
Reserved 0
UTF-8 1 Format defined in Section 7.1.1.1.1.
Octet String 2 This type MUST be implemented.
Format defined in Section 7.1.1.1.2.
IPv4 3 Format defined in Section 7.1.1.1.3.
IPv6 4 Format defined in Section 7.1.1.1.4.
Reserved to IANA 5 - 192
Private Use 193 - 255
Group Identification Length (1 octet) - Length of the Group Identification Value field in octets. This value MUST NOT be zero (0). This field is treated as an unsigned value.
グループ識別長（1オクテット） - オクテットのグループ識別値フィールドの長さ。この値はゼロ（0）であってはなりません。このフィールドは、署名されていない値として扱われます。
Group Identification Value (variable length) - Indicates the name/title of the group. All GroupID types should provide unique naming across groups. GroupID types SHOULD provide this capability by including a random element generated by the creator (owner) of the group of at least eight (8) octets, providing extremely low probability of collision in group names. The GroupID value is static throughout the life of the group.
グループ識別値（変動長） - グループの名前/タイトルを示します。すべてのGroupIDタイプは、グループ間で一意の命名を提供する必要があります。GroupIDタイプは、少なくとも8個のオクテットのグループの作成者（所有者）によって生成されたランダムな要素を含めることにより、この機能を提供する必要があり、グループ名の衝突の非常に低い確率を提供します。GroupID値は、グループの生涯を通じて静的です。
Next Payload (1 octet) - Indicates the type of the next payload in the message. The format for each payload is defined in the following sections. Table 12 presents the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのタイプを示します。各ペイロードの形式は、次のセクションで定義されています。表12に、ペイロードタイプを示しています。このフィールドは、署名されていない値として扱われます。
Table 12: Payload Types
表12：ペイロードタイプ
Next_Payload_Type Value
___________________________________
None 0
Policy Token 1
Key Download Packet 2
Rekey Event 3
Identification 4
Reserved 5
Certificate 6
Reserved 7
Signature 8
Notification 9
Vendor ID 10
Key Creation 11
Nonce 12
Reserved to IANA 13 - 192
Private Use 193 - 255
Version (1 octet) - Indicates the version of the GSAKMP protocol in use. The current value is one (1). This field is treated as an unsigned value.
バージョン（1 Octet） - 使用中のGSAKMPプロトコルのバージョンを示します。現在の値は1（1）です。このフィールドは、署名されていない値として扱われます。
Exchange Type (1 octet) - Indicates the type of exchange (also known as the message type). Table 13 presents the exchange type values. This field is treated as an unsigned value.
Exchange Type（1 Octet） - Exchangeのタイプ（メッセージタイプとも呼ばれます）を示します。表13は、交換型の値を示しています。このフィールドは、署名されていない値として扱われます。
Table 13: Exchange Types
表13：交換タイプ
Exchange_Type Value
________________________________________
Reserved 0 - 3
Key Download Ack/Failure 4
Rekey Event 5
Reserved 6 - 7
Request to Join 8
Key Download 9
Cookie Download 10
Request to Join Error 11
Lack of Ack 12
Request to Depart 13
Departure Response 14
Departure Ack 15
Reserved to IANA 16 - 192
Private Use 193 - 255
Sequence ID (4 octets) - The Sequence ID is used for replay protection of group management messages. If the message is not a group management message, this value MUST be set to zero (0). The first value used by a (S-)GC/KS MUST be one (1). For each distinct group management message that this (S-)GC/KS transmits, this value MUST be incremented by one (1). Receivers of this group management message MUST confirm that the value received is greater than the value of the sequence ID received with the last group management message from this (S-)GC/KS. Group Components (e.g., GMs, S-GC/KSes) MUST terminate processing upon receipt of an authenticated group management message containing a Sequence ID of 0xFFFFFFFF. This field is treated as an unsigned integer in network byte order.
シーケンスID（4オクテット） - シーケンスIDは、グループ管理メッセージのリプレイ保護に使用されます。メッセージがグループ管理メッセージでない場合、この値はゼロ（0）に設定する必要があります。A（s-）GC/ksが最初に使用する値は1つでなければなりません。これ（s-）GC/ksが送信するという個別のグループ管理メッセージについて、この値は1つで増分する必要があります。このグループ管理メッセージの受信機は、受信した値が、この（S-）GC/ksからの最後のグループ管理メッセージで受信されたシーケンスIDの値よりも大きいことを確認する必要があります。グループコンポーネント（GMS、S-GC/KSEなど）は、0xffffffffffのシーケンスIDを含む認証されたグループ管理メッセージを受信したときに処理を終了する必要があります。このフィールドは、ネットワークバイトの順序で署名されていない整数として扱われます。
Length (4 octets) - Length of total message (header + payloads) in octets. This field is treated as an unsigned integer in network byte order.
長さ（4オクテット） - オクテットの合計メッセージの長さ（ヘッダーペイロード）。このフィールドは、ネットワークバイトの順序で署名されていない整数として扱われます。
This section defines the formats for the defined GroupID types.
このセクションでは、定義されたGroupIDタイプの形式を定義します。
The format for type UTF-8 [RFC3629] is shown in Figure 4.
タイプのUTF-8 [RFC3629]の形式を図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! UTF-8 String ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: GroupID UTF-8 Format
図4：GroupID UTF-8形式
Random Value (16 octets) - For the UTF-8 GroupID type, the Random Value is represented as a string of exactly 16 hexadecimal digits converted from its octet values in network-byte order. The leading zero hexadecimal digits and the trailing zero hexadecimal digits are always included in the string, rather than being truncated.
ランダム値（16オクテット） - UTF-8 GroupIDタイプの場合、ランダム値は、ネットワークバイトの順序でOctet値から変換された正確な16ヘキサデシマル数字の文字列として表されます。主要なゼロの16進数桁と、後続のゼロ16進数桁は、切り捨てられるのではなく、常に文字列に含まれています。
UTF-8 String (variable length) - This field contains the human readable portion of the GroupID in UTF-8 format. Its length is calculated as the (GroupID Length - 16) for the Random Value field. The minimum length for this field is one (1) octet.
UTF-8文字列（可変長） - このフィールドには、GroupIDの人間の読み取り可能な部分がUTF-8形式で含まれています。その長さは、ランダム値フィールドの（groupID長-16）として計算されます。このフィールドの最小長は1オクテットです。
The format for type Octet String is shown in Figure 5.
タイプのオクテット文字列の形式を図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Octet String ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GroupID Octet String Format
図5：GroupID Octet文字列形式
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
ランダム値（8オクテット）-8 -OCTETネットワークバイト順序形式の符号なしランダム値。
Octet String (variable length) - This field contains the Octet String portion of the GroupID. Its length is calculated as the (GroupID Length - 8) for the Random Value field. The minimum length for this field is one (1) octet.
Octet String（可変長） - このフィールドには、GroupIDのOctet String部分が含まれています。その長さは、ランダム値フィールドの（groupID長-8）として計算されます。このフィールドの最小長は1オクテットです。
The format for type IPv4 Group Identifier is shown in Figure 6.
タイプIPv4グループ識別子の形式を図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv4 Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GroupID IPv4 Format
図6：GroupID IPv4形式
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
ランダム値（8オクテット）-8 -OCTETネットワークバイト順序形式の符号なしランダム値。
IPv4 Value (4 octets) - The IPv4 value in network byte order format. This value MAY contain the multicast address of the group.
IPv4値（4オクテット） - ネットワークバイト順序形式のIPv4値。この値には、グループのマルチキャストアドレスが含まれている場合があります。
The format for type IPv6 Group Identifier is shown in Figure 7.
タイプIPv6グループ識別子の形式を図7に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv6 Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GroupID IPv6 Format
図7：GroupID IPv6形式
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
ランダム値（8オクテット）-8 -OCTETネットワークバイト順序形式の符号なしランダム値。
IPv6 Value (16 octets) - The IPv6 value in network byte order format. This value MAY contain the multicast address of the group.
IPv6値（16オクテット） - ネットワークバイト順序形式のIPv6値。この値には、グループのマルチキャストアドレスが含まれている場合があります。
When processing the GSAKMP Header, the following fields MUST be checked for correct values:
GSAKMPヘッダーを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Group ID Type - The Group ID Type value MUST be checked to be a valid group identification payload type as defined by Table 11. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
1. グループIDタイプ - グループIDタイプ値は、表11で定義されている有効なグループ識別ペイロードタイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
2. GroupID - The GroupID of the received message MUST be checked against the valid GroupIDs of the Group Component. If no match is found, then an error is logged; in addition, if in Verbose Mode, an appropriate message containing notification value Invalid-Group-ID will be sent.
2. GroupID-受信したメッセージのGroupIDは、グループコンポーネントの有効なGroupIDに対してチェックする必要があります。一致が見つからない場合、エラーが記録されます。さらに、冗長モードの場合、通知値を含む適切なメッセージが無効なGroup-IDが送信されます。
3. Next Payload - The Next Payload value MUST be checked to be a valid payload type as defined by Table 12. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Payload-Type will be sent.
3. 次のペイロード - 次のペイロード値は、表12で定義されている有効なペイロードタイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値を含む適切なメッセージが無効なペイロードタイプが送信されます。
4. Version - The GSAKMP version number MUST be checked that its value is one (1). For other values, see below for processing. The GSAKMP version number MUST be checked that it is consistent with the group's policy as specified in its Policy Token. If the version is not supported or authorized, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Version will be sent.
4. バージョン-GSAKMPバージョン番号は、その値が1つであることを確認する必要があります。他の値については、処理については以下を参照してください。GSAKMPバージョン番号は、ポリシートークンで指定されているグループのポリシーと一致していることを確認する必要があります。バージョンがサポートまたは承認されていない場合、エラーが記録されます。冗長モードの場合、通知値を含む適切なメッセージが無効なバージョンが送信されます。
5. Exchange Type - The Exchange Type MUST be checked to be a valid exchange type as defined by Table 13 and MUST be of the type expected to be received by the GSAKMP state machine. If the exchange type is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Exchange-Type will be sent.
5. 交換タイプ - 交換タイプは、表13で定義されている有効な交換タイプであるようにチェックする必要があり、GSAKMPステートマシンが受信すると予想されるタイプでなければなりません。交換タイプが有効でない場合、エラーが記録されます。冗長モードの場合、通知値を含む適切なメッセージが無効な交換タイプが送信されます。
6. Sequence ID - The Sequence ID value MUST be checked for correctness. For negotiation messages, this value MUST be zero (0). For group management messages, this value MUST be greater than the last sequence ID received from this (S-)GC/KS. Receipt of incorrect Sequence ID on group management messages MUST NOT cause a reply message to be generated. Upon receipt of incorrect Sequence ID on non-group management messages, an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Sequence-ID will be sent.
6. シーケンスID-シーケンスID値の正確性を確認する必要があります。交渉メッセージの場合、この値はゼロ（0）でなければなりません。グループ管理メッセージの場合、この値は、この（S-）GC/ksから受信した最後のシーケンスIDよりも大きくなければなりません。グループ管理メッセージに対する誤ったシーケンスIDの受信は、返信メッセージを生成してはなりません。非グループ管理メッセージで誤ったシーケンスIDを受信すると、エラーが記録されます。冗長モードの場合、通知値を含む適切なメッセージが無効なシーケンスIDが送信されます。
The length fields in the GSAKMP Header (Group ID Length and Length) are used to help process the message. If any field is found to be incorrect, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
GSAKMPヘッダー（グループIDの長さと長さ）の長さフィールドは、メッセージの処理を支援するために使用されます。いずれかのフィールドが正しくないことが判明した場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
In order to allow a GSAKMP version one (v1) implementation to interoperate with future versions of the protocol, some ideas will be discussed here to this effect.
GSAKMPバージョン1（V1）の実装を許可するために、プロトコルの将来のバージョンと相互操作するために、この効果についていくつかのアイデアについて説明します。
A (S-)GC/KS that is operating in a multi-versioned group as defined by the Policy Token can take many approaches on how to interact with the GMs in this group for a rekey message.
ポリシートークンで定義されているように、マルチバージョングループで動作している（S-）GC/KSは、このグループのGMと対話する方法について多くのアプローチをとることができます。
One possible solution is for the (S-)GC/KS to send out multiple rekey messages, one per version level that it supports. Then each GM would only process the message that has the version at which it is operating.
可能な解決策の1つは、（S-）GC/KSが複数のRekeyメッセージを送信することです。これは、サポートするバージョンレベルごとに1つです。次に、各GMは、動作しているバージョンを持つメッセージのみを処理します。
An alternative approach that all GM v1 implementations MUST support is the embedding of a v1 message inside a version two (v2) message. If a GM running at v1 receives a GSAKMP message that has a version value greater than one (1), the GM will attempt to process the information immediately after the Group Header as a Group Header for v1 of the protocol. If this is in fact a v1 Group Header, then the remainder of this v1 message will be processed in place. After processing this v1 embedded message, the data following the v1 message should be the payload as identified by the Next Payload field in the original header of the message and will be ignored by the v1 member. However, if the payload following the initial header is not a v1 Group Header, then the GM will gracefully handle the unrecognized message.
すべてのGM V1実装がサポートしなければならない代替アプローチは、バージョン2（V2）メッセージ内にV1メッセージを埋め込むことです。V1で実行されているGMが1（1）を超えるバージョン値を持つGSAKMPメッセージを受信した場合、GMはグループヘッダーの直後にプロトコルのV1のグループヘッダーとして情報を処理しようとします。これが実際にV1グループヘッダーである場合、このV1メッセージの残りの部分が所定の位置に処理されます。このV1埋め込みメッセージを処理した後、V1メッセージに続くデータは、メッセージの元のヘッダーの次のペイロードフィールドで識別されるペイロードである必要があり、V1メンバーによって無視されます。ただし、最初のヘッダーに続くペイロードがV1グループヘッダーではない場合、GMは認識されていないメッセージを優雅に処理します。
Each GSAKMP payload defined in the following sections begins with a generic header, shown in Figure 8, that provides a payload "chaining" capability and clearly defines the boundaries of a payload. The Generic Payload Header fields are defined as follows:
次のセクションで定義されている各GSAKMPペイロードは、図8に示す一般的なヘッダーで始まり、ペイロード「チェーン」機能を提供し、ペイロードの境界を明確に定義します。一般的なペイロードヘッダーフィールドは、次のように定義されています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Generic Payload Header
図8：一般的なペイロードヘッダー
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
When processing the Generic Payload Header, the following fields MUST be checked for correct values:
一般的なペイロードヘッダーを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Next Payload - The Next Payload value MUST be checked to be a valid payload type as defined by Table 12. If the payload type is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Payload-Type will be sent.
1. 次のペイロード - 次のペイロード値は、表12で定義されている有効なペイロードタイプであるようにチェックする必要があります。ペイロードタイプが有効でない場合、エラーが記録されます。冗長モードの場合、通知値を含む適切なメッセージが無効なペイロードタイプが送信されます。
2. RESERVED - This field MUST contain the value zero (0). If the value of this field is not zero (0), then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 予約済み - このフィールドには、値ゼロ（0）を含める必要があります。このフィールドの値がゼロ（0）でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
The length field in the Generic Payload Header is used to process the remainder of the payload. If this field is found to be incorrect, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
一般的なペイロードヘッダーの長さフィールドは、残りのペイロードを処理するために使用されます。このフィールドが正しくないことが判明した場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
The Policy Token Payload contains authenticatable group-specific information that describes the group security-relevant behaviors, access control parameters, and security mechanisms. Figure 9 shows the format of the payload.
ポリシートークンペイロードには、グループセキュリティ関連の動作、アクセス制御パラメーター、セキュリティメカニズムを説明する認証可能なグループ固有の情報が含まれています。図9は、ペイロードの形式を示しています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy Token Type ! Policy Token Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Policy Token Payload Format
図9：ポリシートークンペイロード形式
The Policy Token Payload fields are defined as follows:
ポリシートークンペイロードフィールドは、次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Policy Token Type (2 octets) - Specifies the type of Policy Token being used. Table 14 identifies the types of policy tokens. This field is treated as an unsigned integer in network byte order format.
ポリシートークンタイプ（2オクテット） - 使用されているポリシートークンのタイプを指定します。表14は、ポリシートークンの種類を示しています。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Table 14: Policy Token Types
表14：ポリシートークンタイプ
Policy_Token_Type Value Definition/Defined In
____________________________________________________________________
Reserved 0
GSAKMP_ASN.1_PT_V1 1 All implementations of GSAKMP
MUST support this PT format.
Format specified in [RFC4534].
Reserved to IANA 2 - 49152
Private Use 49153 - 65535
Policy Token Data (variable length) - Contains Policy Token information. The values for this field are token specific, and the format is specified by the PT Type field.
ポリシートークンデータ（変動長） - ポリシートークン情報が含まれています。このフィールドの値はトークン固有であり、形式はPTタイプフィールドによって指定されます。
If this payload is encrypted, only the Policy Token Data field is encrypted.
このペイロードが暗号化されている場合、ポリシートークンデータフィールドのみが暗号化されます。
The payload type for the Policy Token Payload is one (1).
ポリシートークンペイロードのペイロードタイプは1つです。
When processing the Policy Token Payload, the following fields MUST be checked for correct values:
ポリシートークンペイロードを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Policy Token Type - The Policy Token Type value MUST be checked to be a valid policy token type as defined by Table 14. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. ポリシートークンタイプ - ポリシートークンタイプの値は、表14で定義されている有効なポリシートークンタイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
3. Policy Token Data - This Policy Token Data MUST be processed according to the Policy Token Type specified. The type will define the format of the data.
3. ポリシートークンデータ - このポリシートークンデータは、指定されたポリシートークンタイプに従って処理する必要があります。このタイプは、データの形式を定義します。
Refer to the terminology section for the different terms relating to keys used within this section.
このセクション内で使用されるキーに関連するさまざまな用語については、用語セクションを参照してください。
The Key Download Payload contains group keys (e.g., group keys, initial rekey keys, etc.). These key download payloads can have several security attributes applied to them based upon the security policy of the group. Figure 10 shows the format of the payload.
キーダウンロードのペイロードには、グループキー（グループキー、初期リキーキーなど）が含まれています。これらのキーダウンロードペイロードには、グループのセキュリティポリシーに基づいて、いくつかのセキュリティ属性を適用できます。図10は、ペイロードの形式を示しています。
The security policy of the group dictates that the key download payload MUST be encrypted with a key encryption key (KEK). The encryption mechanism used is specified in the Policy Token. The group members MUST create the KEK using the key creation method identified in the Key Creation Payload.
グループのセキュリティポリシーは、キーダウンロードペイロードをキー暗号化キー（KEK）で暗号化する必要があることを規定しています。使用される暗号化メカニズムは、ポリシートークンで指定されています。グループメンバーは、キー作成ペイロードで識別されたキー作成方法を使用してKEKを作成する必要があります。
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 Items ! Key Download Data Items ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Key Download Payload Format
図10：キーダウンロードペイロードフォーマット
The Key Download Payload fields are defined as follows:
キーダウンロードペイロードフィールドは次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Number of Items (2 octets) - Contains the total number of group traffic protection keys and Rekey Arrays being passed in this data block. This field is treated as an unsigned integer in network byte order format.
アイテム数（2オクテット） - このデータブロックで渡されるグループトラフィックキーとRekeyアレイの総数が含まれています。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Key Download Data Items (variable length) - Contains Key Download information. The Key Download Data is a sequence of Type/Length/Data of the Number of Items. The format for each item is defined in Figure 11.
キーダウンロードデータ項目（変動長） - キーダウンロード情報が含まれています。キーダウンロードデータは、アイテム数のタイプ/長さ/データのシーケンスです。各アイテムの形式を図11に定義します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KDD Item Type ! Key Download Data Item Length! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data for Key Download Data Item (Key Datum/Rekey Array) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Key Download Data Item Format
図11：キーダウンロードデータ項目形式
For each Key Download Data Item, the data format is as follows:
キーダウンロードデータ項目ごとに、データ形式は次のとおりです。
Key Download Data (KDD) Item Type (1 octet) - Identifier for the type of data contained in this Key Download Data Item. See Table 15 for the possible values of this field. This field is treated as an unsigned value.
キーダウンロードデータ（KDD）項目タイプ（1オクテット） - このキーダウンロードデータ項目に含まれるデータのタイプの識別子。このフィールドの可能な値については、表15を参照してください。このフィールドは、署名されていない値として扱われます。
Key Download Data Item Length (2 octets) - Length in octets of the Data for the Key Download Data Item following this field. This field is treated as an unsigned integer in network byte order format.
キーダウンロードデータアイテムの長さ（2オクテット） - このフィールドに続くキーダウンロードデータ項目のデータのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Data for Key Download Data Item (variable length) - Contains Keys and related information. The format of this field is specific depending on the value of the Key Download Data Item Type field. For KDD Item Type of GTPK, this field will contain a Key Datum as defined in Section 7.4.1.1. For KDD Item Type Rekey - LKH, this field will contain a Rekey Array as defined in Section 7.4.1.2.
キーダウンロードデータ項目（可変長）のデータ - キーと関連情報が含まれています。このフィールドの形式は、キーダウンロードデータ項目タイプフィールドの値に応じて固有です。GTPKのKDDアイテムタイプの場合、このフィールドにはセクション7.4.1.1で定義されている重要なデータが含まれます。KDDアイテムタイプReke -LKHの場合、このフィールドにはセクション7.4.1.2で定義されているReke配列が含まれます。
Table 15: Key Download Data Item Types
表15：キーダウンロードデータアイテムタイプ
Key Download Data Value Definition
Item Type
_________________________________________________________________
GTPK 0 This type MUST be implemented.
This type identifies that the
data contains group traffic
protection key information.
Rekey - LKH 1 Optional
Reserved to IANA 2 - 192
Private Use 193 - 255
The encryption of this payload only covers the data subsequent to the Generic Payload header (Number of Items and Key Download Data Items fields).
このペイロードの暗号化は、汎用ペイロードヘッダー（アイテムの数とキーダウンロードデータアイテムフィールド）に続くデータのみをカバーします。
The payload type for the Key Download Packet is two (2).
キーダウンロードパケットのペイロードタイプは2つです。
A Key Datum contains all the information for a key. Figure 12 shows the format for this structure.
キーデータムには、キーのすべての情報が含まれています。図12は、この構造の形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Type ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Key Handle ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Key Creation Date ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Key Expiration Date ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Key Datum Format
図12：キーデータム形式
Key Type (2 octets) - This is the cryptographic algorithm for which this key data is to be used. This value is specified in the Policy Token. See Table 16 for the possible values of this field. This field is treated as an unsigned value.
キータイプ（2オクテット） - これは、このキーデータを使用する暗号化アルゴリズムです。この値は、ポリシートークンで指定されています。このフィールドの可能な値については、表16を参照してください。このフィールドは、署名されていない値として扱われます。
Table 16: Cryptographic Key Types
表16：暗号化キータイプ
Cryptographic_Key_Types Value Description/Defined In
____________________________________________________________________
Reserved 0 - 2
3DES_CBC64_192 3 See [RFC2451].
Reserved 4 - 11
AES_CBC_128 12 This type MUST be
supported. See [IKEv2].
AES_CTR 13 See [IKEv2].
Reserved to IANA 14 - 49152
Private Use 49153 - 65535
Key ID (4 octets) - This is the permanent ID of all versions of the key. This value MAY be defined by the Policy Token. This field is treated as an octet string.
キーID（4オクテット） - これは、キーのすべてのバージョンの永続的なIDです。この値は、ポリシートークンによって定義される場合があります。このフィールドは、オクテット弦として扱われます。
Key Handle (4 octets) - This is the value to uniquely identify a version (particular instance) of a key. This field is treated as an octet string.
キーハンドル（4オクテット） - これは、キーのバージョン（特定のインスタンス）を一意に識別する値です。このフィールドは、オクテット弦として扱われます。
Key Creation Date (15 octets) - This is the time value of when this key data was originally generated. This field contains the timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is the numerical value of the month (01 - 12), DD is the day of the month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within the hour (00 - 59), SS is the seconds within the minute (00 - 59), and the letter Z indicates that this is Zulu time. This format is loosely based on [RFC3161].
キー作成日（15オクテット） - これは、このキーデータが元々生成された時の時間値です。このフィールドには、UTF -8形式のタイムスタンプが含まれていますyyyymmddhhmmssz、yyyyは年（0000-9999）、mmは月の数値（01-12）、DDは月（01-31）の日です。HHはその日の時間（00-23）、mmは1時間以内（00-59）、SSは1分以内（00-59）の数秒で、文字ZはこれがZulu時間であることを示します。この形式は、[RFC3161]に大まかに基づいています。
Key Expiration Date (15 octets) - This is the time value of when this key is no longer valid for use. This field contains the timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is the numerical value of the month (01 - 12), DD is the day of the month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within the hour (00 - 59), SS is the seconds within the minute (00 - 59), and the letter Z indicates that this is Zulu time. This format is loosely based on [RFC3161].
キーの有効期限（15オクテット） - これは、このキーが使用に有効でない場合の時間値です。このフィールドには、UTF -8形式のタイムスタンプが含まれていますyyyymmddhhmmssz、yyyyは年（0000-9999）、mmは月の数値（01-12）、DDは月（01-31）の日です。HHはその日の時間（00-23）、mmは1時間以内（00-59）、SSは1分以内（00-59）の数秒で、文字ZはこれがZulu時間であることを示します。この形式は、[RFC3161]に大まかに基づいています。
Key Data (variable length) - This is the actual key data, which is dependent on the Key Type algorithm for its format.
キーデータ（変数長） - これは実際のキーデータであり、その形式のキータイプアルゴリズムに依存します。
NOTE: The combination of the Key ID and the Key Handle MUST be unique within the group. This combination will be used to uniquely identify a key.
注：キーIDとキーハンドルの組み合わせは、グループ内で一意でなければなりません。この組み合わせは、キーを一意に識別するために使用されます。
A Rekey Array contains the information for the set of KEKs that is associated with a Group Member. Figure 13 shows the format for this structure.
Rekeyアレイには、グループメンバーに関連付けられているKEKのセットの情報が含まれています。図13は、この構造の形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rekey Version#! Member ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Number of KEK Keys ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Datum(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Rekey Array Structure Format
図13：Rekey Array構造形式
Rekey Version (1 octet) - Contains the version of the Rekey protocol in which the data is formatted. For Key Download Data Item Type of Rekey - LKH, refer to Section A.2 for a description of this value. This field is treated as an unsigned value.
Rekeyバージョン（1 Octet） - データがフォーマットされているRekeyプロトコルのバージョンが含まれています。キーダウンロードデータアイテムタイプのReke -LKHについては、この値の説明についてはセクションA.2を参照してください。このフィールドは、署名されていない値として扱われます。
Member ID (4 octets) - This is the Member ID of the Rekey sequence contained in this Rekey Array. This field is treated as an octet string. For Key Download Data Item Type of Rekey - LKH, refer to Section A.2 for a description of this value.
メンバーID（4オクテット） - これは、このRekeyアレイに含まれるRekeシーケンスのメンバーIDです。このフィールドは、オクテット弦として扱われます。キーダウンロードデータアイテムタイプのReke -LKHについては、この値の説明についてはセクションA.2を参照してください。
Number of KEK Keys (2 octets) - This value is the number of distinct KEK keys in this sequence. This value is treated as an unsigned integer in network byte order format.
Kek Keysの数（2オクテット） - この値は、このシーケンスの個別のKekキーの数です。この値は、ネットワークバイト順序形式の署名されていない整数として扱われます。
Key Datum(s) (variable length) - The sequence of KEKs in Key Datum format. The format for each Key Datum in this sequence is defined in section 7.4.1.1.
キーデータム（S）（可変長） - キーデータム形式のKEKのシーケンス。このシーケンスの各キーデータムの形式は、セクション7.4.1.1で定義されています。
Key ID (for Key ID within the Rekey) - LKH space, refer to Section A.2 for a description of this value.
キーID（Rekey内のキーIDの場合） - LKHスペース、この値の説明については、セクションA.2を参照してください。
Prior to processing its data, the payload contents MUST be decrypted.
データを処理する前に、ペイロードコンテンツを復号化する必要があります。
When processing the Key Download Payload, the following fields MUST be checked for correct values: 1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
キーダウンロードペイロードを処理する場合、次のフィールドに正しい値を確認する必要があります。1。次のペイロード、予約、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. KDD Item Type - All KDD Item Type fields MUST be checked to be a valid Key Download Data Item type as defined by Table 15. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. KDDアイテムタイプ -すべてのKDDアイテムタイプフィールドは、表15で定義されている有効なキーダウンロードデータアイテムタイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
3. Key Type - All Key Type fields MUST be checked to be a valid encryption type as defined by Table 16. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Key-Information will be sent.
3. キータイプ - すべてのキータイプフィールドは、表16で定義されている有効な暗号化タイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値を含む適切なメッセージが無効なキー情報が送信されます。
4. Key Expiration Date - All Key Expiration Date fields MUST be checked confirm that their values represent a future and not a past time value. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-Key-Information will be sent.
4. 主要な有効期限 - すべての主要な有効期限フィールドは、その値が過去の時間の値ではなく将来を表していることを確認する必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値を含む適切なメッセージが無効なキー情報が送信されます。
The length and counter fields in the payload are used to help process the payload. If any field is found to be incorrect, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
ペイロードの長さとカウンターフィールドは、ペイロードの処理に役立ちます。いずれかのフィールドが正しくないことが判明した場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
Refer to the terminology section for the different terms relating to keys used within this section.
このセクション内で使用されるキーに関連するさまざまな用語については、用語セクションを参照してください。
The Rekey Event Payload MAY contain multiple keys encrypted in Wrapping KEKs. Figure 14 shows the format of the payload. If the data to be contained within a Rekey Event Payload is too large for the payload, the sequence can be split across multiple Rekey Event Payloads at a Rekey Event Data boundary.
Rekey Event Payloadには、Keksのラッピングで暗号化された複数のキーが含まれている場合があります。図14は、ペイロードの形式を示しています。Rekeyイベントに含まれるデータがペイロードに対して大きすぎる場合、Rekeyイベントデータ境界で複数のRekeyイベントペイロードにシーケンスを分割できます。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RekeyEvnt Type! Rekey Event Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Rekey Event Data(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Rekey Event Payload Format
図14：Rekeyイベントペイロード形式
The Rekey Event Payload fields are defined as follows:
Rekeyイベントペイロードフィールドは、次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Rekey Event Type (1 octet) - Specifies the type of Rekey Event being used. Table 17 presents the types of Rekey events. This field is treated as an unsigned value.
Rekey Event Type（1 Octet） - 使用されているRekeyイベントのタイプを指定します。表17は、Rekeyイベントの種類を示しています。このフィールドは、署名されていない値として扱われます。
Rekey Event Header (variable length) - This is the header information for the Rekey Event. The format for this is defined in Section 7.5.1.1, "Rekey Event Header Structure".
Rekey Event Header（可変長） - これは、Rekeyイベントのヘッダー情報です。この形式は、セクション7.5.1.1「Rekey Event Header構造」で定義されています。
Rekey Event Data(s) (variable length) - This is the rekey information for the Rekey Event. The format for this is defined in Section 7.5.1.2, "Rekey Event Data Structure".
Rekey Event Data（S）（可変長） - これは、RekeyイベントのRekey情報です。この形式は、セクション7.5.1.2「Rekey Event Data構造」で定義されています。
The Rekey Event payload type is three (3).
Rekeyイベントペイロードタイプは3つです。
Table 17: Rekey Event Types
表17：再キーイベントタイプ
Rekey_Event_Type Value Definition/Defined In
_____________________________________________________________________
None 0 This type MUST be implemented.
In this case, the size of the Rekey
Event Data field will be zero bytes
long. The purpose of a Rekey Event
Payload with type None is when it is
necessary to send out a new token
with no rekey information. GSAKMP
rekey msg requires a Rekey Event
Payload, and in this instance it
would have rekey data of type None.
GSAKMP_LKH 1 The rekey data will be of
type LKH formatted according to
GSAKMP. The format for this field
is defined in Section 7.5.1.2.
Reserved to IANA 2 - 192
Private Use 193 - 255
The format for the Rekey Event Header is shown in Figure 15.
Rekeyイベントヘッダーの形式を図15に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Group ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group ID Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Time/Date Stamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! RekeyEnt Type ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm Ver ! # of Rekey Event Data(s) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Rekey Event Header Format
図15：Rekeyイベントヘッダー形式
Group Identification Value (variable length) - Indicates the name/title of the group to be rekeyed. This is the same format, length, and value as the Group Identification Value in Section 7.1, "GSAKMP Header".
グループ識別値（変動長） - グループの名前/タイトルを再キーにします。これは、セクション7.1の「GSAKMPヘッダー」のグループ識別値と同じ形式、長さ、および値です。
Time/Date Stamp (15 octets) - This is the time value when the Rekey Event Data was generated. This field contains the timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is the numerical value of the month (01 - 12), DD is the day of the month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within the hour (00 - 59), SS is the seconds within the minute (00 - 59), and the letter Z indicates that this is Zulu time. This format is loosely based on [RFC3161].
時間/日付スタンプ（15オクテット） - これは、Rekeyイベントデータが生成されたときの時間値です。このフィールドには、UTF -8形式のタイムスタンプが含まれていますyyyymmddhhmmssz、yyyyは年（0000-9999）、mmは月の数値（01-12）、DDは月（01-31）の日です。HHはその日の時間（00-23）、mmは1時間以内（00-59）、SSは1分以内（00-59）の数秒で、文字ZはこれがZulu時間であることを示します。この形式は、[RFC3161]に大まかに基づいています。
Rekey Event Type (1 octet) - This is the Rekey algorithm being used for this group. The values for this field can be found in Table 17. This field is treated as an unsigned value.
Rekey Event Type（1 Octet） - これは、このグループに使用されているRekeyアルゴリズムです。このフィールドの値は表17にあります。このフィールドは、署名されていない値として扱われます。
Algorithm Version (1 octet) - Indicates the version of the Rekey Type being used. For Rekey Event Type of GSAKMP_LKH, refer to Section A.2 for a description of this value. This field is treated as an unsigned value.
アルゴリズムバージョン（1 Octet） - 使用されているRekeyタイプのバージョンを示します。GSAKMP_LKHのRekeyイベントタイプについては、この値の説明については、セクションA.2を参照してください。このフィールドは、署名されていない値として扱われます。
# of Rekey Event Data(s) (2 octets) - The number of Rekey Event Data(s) contained in the Rekey Data. This value is treated as an unsigned integer in network byte order.
Rekeyイベントデータの＃（2オクテット） - Rekeyデータに含まれるRekeyイベントデータの数。この値は、ネットワークバイトの順序で署名されていない整数として扱われます。
As defined in the Rekey Event Header, # of Rekey Data(s) field, multiple pieces of information are sent in a Rekey Event Data. Each end user, will be interested in only one Rekey Event Data among all of the information sent. Each Rekey Event Data will contain all the Key Packages that a user requires. For each Rekey Event Data, the data following the Wrapping fields is encrypted with the key identified in the Wrapping Header. Figure 16 shows the format of each Rekey Event Data.
RekeyイベントヘッダーであるRekey Data（S）フィールドの＃で定義されているように、複数の情報がRekeyイベントデータで送信されます。各エンドユーザーは、送信されたすべての情報の中で1つのRekeyイベントデータのみに関心があります。各Rekeyイベントデータには、ユーザーが必要とするすべてのキーパッケージが含まれます。各レキーイベントデータについて、ラッピングフィールドに続くデータは、ラッピングヘッダーで識別されたキーと暗号化されます。図16は、各レキーイベントデータの形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Packet Length ! Wrapping KeyID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Wrapping Key Handle ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! # of Key Packages !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Packages(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Rekey Event Data Format
図16：再キーイベントデータ形式
Packet Length (2 octets) - Length in octets of the Rekey Event Data, which consists of the # of Key Packages and the Key Packages(s). This value is treated as an unsigned integer in network byte order.
パケットの長さ（2オクテット） - キーパッケージの＃とキーパッケージで構成されるRekeyイベントデータのオクテットの長さ。この値は、ネットワークバイトの順序で署名されていない整数として扱われます。
Wrapping KeyID (4 octets) - This is the Key ID of the KEK that is being used for encryption/decryption of the new (rekeyed) keys. For Rekey Event Type of Rekey - LKH, refer to Section A.2 for a description of this value.
Lapping KeyID（4オクテット） - これは、新しい（再キー）キーの暗号化/復号化に使用されているKEKのキーIDです。RekeyのRekeyイベントタイプ-LKHについては、この値の説明については、セクションA.2を参照してください。
Wrapping Key Handle (4 octets) - This is a Key Handle of the KEK that is being used for encryption/decryption of the new (rekeyed) keys. Refer to Section 7.4.1.1 for the values of this field.
キーハンドル（4オクテット） - これは、新しい（再キー付き）キーの暗号化/復号化に使用されているKEKのキーハンドルです。このフィールドの値については、セクション7.4.1.1を参照してください。
# of Key Packages (2 octets) - The number of key packages contained in this Rekey Event Data. This value is treated as an unsigned integer in network byte order.
＃キーパッケージ（2オクテット） - このRekeyイベントデータに含まれるキーパッケージの数。この値は、ネットワークバイトの順序で署名されていない整数として扱われます。
Key Package(s) (variable length) - The type/length/value format of a Key Datum. The format for this is defined in Section 7.5.1.2.1.
キーパッケージ（S）（可変長） - キーデータムのタイプ/長さ/値形式。この形式は、セクション7.5.1.2.1で定義されています。
Each Key Package contains all the information about the key. Figure 17 shows the format for a Key Package.
各キーパッケージには、キーに関するすべての情報が含まれています。図17は、キーパッケージの形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KeyPkg Type ! Key Package Length ! Key Datum ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Key Package Format
図17：キーパッケージ形式
Key Package Type (1 octet) - The type of key in this key package. Legal values for this field are defined in Table 15, Key Download Data Types. This field is treated as an unsigned value.
キーパッケージタイプ（1オクテット） - このキーパッケージのキーのタイプ。このフィールドの法的価値は、キーダウンロードデータ型の表15に定義されています。このフィールドは、署名されていない値として扱われます。
Key Package Length (2 octets) - The length of the Key Datum. This field is treated as an unsigned integer in network byte order format.
キーパッケージの長さ（2オクテット） - キーデータムの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Key Datum (variable length) - The actual data of the key. The format for this field is defined in Section 7.4.1.1, "Key Datum Structure".
キーデータム（変数長） - キーの実際のデータ。このフィールドの形式は、セクション7.4.1.1「キーデータム構造」で定義されています。
When processing the Rekey Event Payload, the following fields MUST be checked for correct values:
Rekeyイベントペイロードを処理する場合、正しい値を次のフィールドに確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Rekey Event Type field within "Rekey Event" payload header - The Rekey Event Type MUST be checked to be a valid rekey event type as defined by Table 17. If the Rekey Event Type is not valid, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
2. 「Rekeyイベント」ペイロードヘッダー内のRekeyイベントタイプフィールド - レキーイベントタイプは、表17で定義されている有効なRekeyイベントタイプであるようにチェックする必要があります。Rekeyイベントタイプが有効でない場合は、モードに関係なく（例：Terseまたは冗長）エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
3. Group ID Value - The Group ID value of the Rekey Event Header received message MUST be checked against the GroupID of the Group Component. If no match is found, the payload is discarded, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
3. グループID値-RekeyイベントヘッダーのグループID値受信メッセージは、グループコンポーネントのGroupIDに対してチェックする必要があります。一致が見つからない場合、ペイロードは破棄され、モード（たとえば、非常に冗長）に関係なく、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
4. Date/Time Stamp - The Date/Time Stamp value of the Rekey Event Header MAY be checked to determine if the Rekey Event generation time is recent relative to network delay and processing times. If the TimeStamp is judged not to be recent, an error is logged. No response error message is generated for receipt of a Group Management Message.
4. 日付/タイムスタンプ - Rekeyイベントヘッダーの日付/時刻スタンプ値をチェックして、Rekeyイベントの生成時間がネットワーク遅延と処理時間と比較して最近であるかどうかを判断できます。タイムスタンプが最近ではないと判断された場合、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
5. Rekey Event Type field within the "Rekey Event Header" - The Rekey Event Type of the Rekey Event Header received message MUST be checked to be a valid rekey event type, as defined by Table 17, and the same value of the Rekey Event Type earlier in this payload. If the Rekey Event Type is not valid or not equal to the previous value of the Rekey Event Type, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
5. 「Rekey Event Header」内のRekeyイベントタイプフィールド-RekeyイベントタイプのRekeyイベントヘッダー受信メッセージは、表17で定義されている有効なRekeyイベントタイプであることを確認する必要があります。このペイロードで。RekeyイベントタイプがRekeyイベントタイプの以前の値と等しくない場合、モード（TerseやVerboseなど）に関係なく、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
6. Algorithm Version - The Rekey Algorithm Version number MUST be checked to ensure that the version indicated is supported. If it is not supported, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
6. アルゴリズムバージョン-Rekeyアルゴリズムバージョン番号を確認して、示されたバージョンがサポートされていることを確認する必要があります。サポートされていない場合は、モード（たとえば、verboseまたはverbose）に関係なく、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
The length and counter fields are used to help process the message. If any field is found to be incorrect, then termination processing MUST be initiated.
長さとカウンターフィールドは、メッセージの処理を支援するために使用されます。いずれかのフィールドが正しくないことが判明した場合、終了処理を開始する必要があります。
A GM MUST process all the Rekey Event Datas as based on the rekey method used there is a potential that multiple Rekey Event Datas are for this GM. The Rekey Event Datas are processed in order until all Rekey Event Datas are consumed.
GMは、このGMに複数のRekeyイベントデータがある可能性があるRekeyメソッドに基づいて、すべてのRekeyイベントデータを処理する必要があります。Rekeyイベントデータは、すべてのRekeyイベントデータが消費されるまで順番に処理されます。
1. Wrapping KeyID - The Wrapping KeyID MUST be checked against the list of stored KEKs that this GM holds. If a match is found, then continue processing this Rekey Event Data. Otherwise, skip to the next Rekey Event Data.
1. ラッピングkeyID-ラッピングキーイドは、このGMが保持している保存されたkeksのリストに対してチェックする必要があります。一致が見つかった場合は、このRekeyイベントデータの処理を続けます。それ以外の場合は、次のRekeyイベントデータにスキップします。
2. Wrapping Handle - If a matching Wrapping KeyID was found, then the Wrapping Handle MUST be checked against the handle of the KEK for which the KeyID was a match. If the handles match, then the GM will process the Key Packages associated with this Rekey Event Data. Otherwise, skip to the next Rekey Event Data.
2. ラッピングハンドル - 一致するラッピングKeyIDが見つかった場合、keyIDが一致していたkekのハンドルに対して、ラッピングハンドルをチェックする必要があります。ハンドルが一致する場合、GMはこのRekeyイベントデータに関連付けられたキーパッケージを処理します。それ以外の場合は、次のRekeyイベントデータにスキップします。
If a GM has found a matching Wrapping KeyID and Wrapping Handle, the GM decrypts the remaining data in this Rekey Event Data according to policy using the KEK defined by the Wrapping KeyID and Handle. After decrypting the data, the GM extracts the # of Key Packages field to help process the subsequent Key Packages. The Key Packages are processed as follows:
GMが一致するラッピングKeyIDとラッピングハンドルを見つけた場合、GMは、ラッピングKeyIDとハンドルで定義されたKEKを使用して、ポリシーに従ってこのRekeyイベントデータの残りのデータを復号化します。データを復号化した後、GMはキーパッケージの＃を抽出し、その後のキーパッケージを処理するのに役立ちます。キーパッケージは次のように処理されます。
1. Key Package Type - The Key Package Type MUST be checked to be a valid key package type as defined by Table 15. If the Key Package Type is not valid, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
1. キーパッケージタイプ - キーパッケージタイプは、表15で定義されている有効なキーパッケージタイプであるようにチェックする必要があります。キーパッケージタイプが有効でない場合は、モード（たとえば、TerseまたはVerbose）に関係なく、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
2. Key Package Length - The Key Package Length is used to process the subsequent Key Datum information.
2. キーパッケージの長さ - キーパッケージの長さは、後続のキーデータム情報を処理するために使用されます。
3. Key Type - The Key Type MUST be checked to be a valid key type as defined by Table 16. If the Key Package Type is not valid, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
3. キータイプ - キータイプは、表16で定義されている有効なキータイプであるようにチェックする必要があります。キーパッケージタイプが有効でない場合は、モード（たとえば、TerseまたはVerbose）に関係なく、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
4. Key ID - The Key ID MUST be checked against the set of Key IDs that this user maintains for this Key Type. If no match is found, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
4. キーID-キーIDは、このキータイプに対してこのユーザーが維持するキーIDのセットに対してチェックする必要があります。一致が見つからない場合は、モード（たとえば、verboseまたはvorbose）に関係なく、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
5. Key Handle - The Key Handle is extracted as is and is used to be the new Key Handle for the Key currently associated with the Key Package's Key ID.
5. キーハンドル - キーハンドルはそのまま抽出され、キーパッケージのキーIDに現在関連付けられているキーの新しいキーハンドルになるために使用されます。
6. Key Creation Date - The Key Creation Date MUST be checked that it is subsequent to the Key Creation Date for the currently held key. If this date is prior to the currently held key, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
6. キー作成日 - キー作成日は、現在開催されているキーのキー作成日に続くことを確認する必要があります。この日付が現在保持されているキーの前にある場合、モード（例：TerseまたはVerbose）に関係なく、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
7. Key Expiration Date - The Key Expiration Date MUST be checked that it is subsequent to the Key Creation Date just received and that the time rules conform with policy. If the expiration date is not subsequent to the creation date or does not conform with policy, then regardless of mode (e.g., Terse or Verbose) an error is logged. No response error message is generated for receipt of a Group Management Message.
7. 主要な有効期限 - キーの有効期限は、受け取ったばかりのキー作成日の後に、時間規則がポリシーに準拠していることを確認する必要があります。有効期限が作成日に続いていない場合、またはポリシーに準拠していない場合、モード（たとえば、TerseまたはVerbose）に関係なく、エラーが記録されます。グループ管理メッセージを受信するために応答エラーメッセージは生成されません。
8. Key Data - The Key Data is extracted based on the length information in the key package.
8. キーデータ - キーデータは、キーパッケージの長さ情報に基づいて抽出されます。
If there were no errors when processing the Key Package, the key represented by the KeyID will have all of its data updated based upon the received information.
キーパッケージの処理時にエラーがなかった場合、KeyIDで表されるキーは、受信した情報に基づいてすべてのデータを更新します。
The Identification Payload contains entity-specific data used to exchange identification information. This information is used to verify the identities of members. Figure 18 shows the format of the Identification Payload.
識別ペイロードには、識別情報を交換するために使用されるエンティティ固有のデータが含まれています。この情報は、メンバーの身元を確認するために使用されます。図18は、識別ペイロードの形式を示しています。
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 Classif ! ID Type ! Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Identification Payload Format
図18：識別ペイロード形式
The Identification Payload fields are defined as follows:
識別ペイロードフィールドは、次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Identification (ID) Classification (1 octet) - Classifies the ownership of the Identification Data. Table 18 identifies possible values for this field. This field is treated as an unsigned value.
識別（ID）分類（1 OCTET） - 識別データの所有権を分類します。表18は、このフィールドの可能な値を識別します。このフィールドは、署名されていない値として扱われます。
Table 18: Identification Classification
表18：識別分類
ID_Classification Value
_______________________________
Sender 0
Receiver 1
Third Party 2
Reserved to IANA 3 - 192
Private Use 193 - 255
Identification (ID) Type (1 octet) - Specifies the type of Identification being used. Table 19 identifies possible values for this type. This field is treated as an unsigned value. All defined types are OPTIONAL unless otherwise stated.
識別（ID）タイプ（1オクテット） - 使用される識別のタイプを指定します。表19は、このタイプの可能な値を識別します。このフィールドは、署名されていない値として扱われます。定義されたすべてのタイプは、特に明記しない限りオプションです。
Identification Data (variable length) - Contains identity information. The values for this field are group specific, and the format is specified by the ID Type field. The format for this field is stated in conjunction with the type in Table 19.
識別データ（変数長） - ID情報が含まれています。このフィールドの値はグループ固有であり、形式はIDタイプフィールドによって指定されます。このフィールドの形式は、表19のタイプと併せて記載されています。
The payload type for the Identification Payload is four (4).
識別ペイロードのペイロードタイプは4（4）です。
Table 19: Identification Types
表19：識別タイプ
ID_Type Value PKIX Cert Description
Field Defined In
_____________________________________________________________________
Reserved 0
ID_IPV4_ADDR 1 SubjAltName See [IKEv2]
iPAddress Section 3.5.
ID_FQDN 2 SubjAltName See [IKEv2]
dNSName Section 3.5.
ID_RFC822_ADDR 3 SubjAltName See [IKEv2]
rfc822Name Section 3.5.
Reserved 4
ID_IPV6_ADDR 5 SubjAltName See [IKEv2]
iPAddress Section 3.5.
Reserved 6 - 8
ID_DER_ASN1_DN 9 Entire Subject, See [IKEv2]
bitwise Compare Section 3.5.
Reserved 10
ID_KEY_ID 11 N/A See [IKEv2]
Reserved 12 - 29 Section 3.5.
Unencoded Name 30 Subject The format for
(ID_U_NAME) this type is
defined in
Section 7.6.1.1.
ID_DN_STRING 31 Subject See [RFC4514].
This type MUST
be implemented.
Reserved to IANA 32 - 192
Private Use 193 - 255
The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19.
タイプの非エンコード名（ID_U_NAME）の形式を図19に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DN Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Unencoded Name (ID-U-NAME) Format
図19：ENCODED NAME（ID-U-Name）形式
Serial Number (20 octets) - The certificate serial number. This field is treated as an unsigned integer in network byte order format.
シリアル番号（20オクテット） - 証明書シリアル番号。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Length (4 octets) - Length in octets of the DN Data field. This field is treated as an unsigned integer in network byte order format.
長さ（4オクテット） - DNデータフィールドのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
DN Data (variable length) - The actual UTF-8 DN value (Subject field) using the slash (/) character for field delimiters (e.g., "/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/ Email=user1@acme.com" without the surrounding quotes).
DNデータ（変数長） - フィールドデリミターのスラッシュ（/）文字を使用した実際のUTF -8 DN値（サブジェクトフィールド）（例： "/c = us/st = md/l = where/o = acme、inc./ou = div1/cn=user1/ email = user1@acme.com "周囲の引用なし）。
When processing the Identification Payload, the following fields MUST be checked for correct values:
識別ペイロードを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Identification Classification - The Identification Classification value MUST be checked to be a valid identification classification type as defined by Table 18. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 識別分類 - 識別分類値は、表18で定義されている有効な識別分類タイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
3. Identification Type - The Identification Type value MUST be checked to be a valid identification type as defined by Table 19. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
3. 識別タイプ - 識別タイプの値は、表19で定義されている有効な識別タイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
4. Identification Data - This Identification Data MUST be processed according to the identification type specified. The type will define the format of the data. If the identification data is being used to find a match and no match is found, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Invalid-ID-Information will be sent.
4. 識別データ - この識別データは、指定された識別型に従って処理する必要があります。このタイプは、データの形式を定義します。識別データが一致を見つけるために使用され、一致が見つからない場合、エラーが記録されます。冗長モードの場合、通知値を含む適切なメッセージが無効なID情報が送信されます。
When processing the Identification Data of type ID_U_NAME, the following fields MUST be checked for correct values:
タイプID_U_NAMEの識別データを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Serial Number - The serial number MUST be a greater than or equal to one (1) to be a valid serial number from a conforming CA [RFC3280]. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
1. シリアル番号 - 適合CA [RFC3280]からの有効なシリアル番号であるために、シリアル番号は1つ以上でなければなりません。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
2. DN Data - The DN data is processed as a UTF-8 string.
2. DNデータ-DNデータはUTF -8文字列として処理されます。
3. The CA MUST be a valid trusted policy creation authority as defined by the Policy Token.
3. CAは、ポリシートークンで定義されているように、有効な信頼できる政策作成権限でなければなりません。
These 2 pieces of information, Serial Number and DN Data, in conjunction, will then be used for party identification. These values are also used to help identify the certificate when necessary.
これらの2つの情報、シリアル番号、およびDNデータは、当事者の識別に使用されます。これらの値は、必要に応じて証明書を識別するのに役立つためにも使用されます。
The Certificate Payload provides a means to transport certificates or other certificate-related information via GSAKMP and can appear in any GSAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g., LDAP [RFC4523]) is not available to distribute certificates. Multiple certificate payloads MAY be sent to enable verification of certificate chains. Conversely, zero (0) certificate payloads may be sent, and the receiving GSAKMP MUST rely on some other mechanism to retrieve certificates for verification purposes. Figure 20 shows the format of the Certificate Payload.
証明書のペイロードは、GSAKMPを介して証明書またはその他の証明書関連情報を輸送する手段を提供し、GSAKMPメッセージに表示できます。証明書のペイロードは、適切なディレクトリサービス（例：LDAP [RFC4523]）が証明書を配布するために利用できない場合はいつでも交換に含める必要があります。証明書チェーンの確認を可能にするために、複数の証明書のペイロードを送信できます。逆に、ゼロ（0）証明書のペイロードが送信される場合があり、受信GSAKMPは検証目的で証明書を取得するために他のメカニズムに依存する必要があります。図20は、証明書のペイロードの形式を示しています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Type ! Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Certificate Payload Format
図20：証明書のペイロード形式
The Certificate Payload fields are defined as follows:
証明書のペイロードフィールドは、次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Certificate Type (2 octets) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. Table 20 presents the types of certificate payloads. This field is treated as an unsigned integer in network byte order format.
証明書タイプ（2オクテット） - このフィールドは、証明書データフィールドに含まれる証明書または証明書関連情報の種類を示します。表20は、証明書のペイロードの種類を示しています。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Type/Encoding field.
証明書データ（変動長） - 証明書データの実際のエンコード。証明書のタイプは、証明書の種類/エンコードフィールドで示されます。
The payload type for the Certificate Payload is six (6).
証明書のペイロードのペイロードタイプは6（6）です。
Table 20: Certificate Payload Types
表20：証明書のペイロードタイプ
Certificate_Type Value Description/
Defined In
_____________________________________________________________________
None 0
Reserved 1 - 3
X.509v3 Certificate 4 This type MUST be
-- Signature implemented.
-- DER Encoding Contains a DER
encoded X.509
certificate.
Reserved 5 - 6
Certificate Revocation List 7 Contains a BER
(CRL) encoded X.509 CRL.
Reserved 8 - 9
X.509 Certificate 10 See [IKEv2], Sec 3.6.
-- Attribute
Raw RSA Key 11 See [IKEv2], Sec 3.6.
Hash and URL of X.509 12 See [IKEv2], Sec 3.6.
Certificate
Hash and URL of X.509 13 See [IKEv2], Sec 3.6.
bundle
Reserved to IANA 14 -- 49152
Private Use 49153 -- 65535
When processing the Certificate Payload, the following fields MUST be checked for correct values:
証明書のペイロードを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Certificate Type - The Certificate Type value MUST be checked to be a valid certificate type as defined by Table 20. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Cert-Type-Unsupported will be sent.
2. 証明書タイプ - 表20で定義されている有効な証明書タイプであるように証明書タイプ値をチェックする必要があります。値が有効でない場合、エラーが記録されます。言語モードの場合、通知値のCERT-TYPE-UNSPORTEDを含む適切なメッセージが送信されます。
3. Certificate Data - This Certificate Data MUST be processed according to the certificate type specified. The type will define the format of the data. Receipt of a certificate of the trusted policy creation authority in a Certificate payload causes the payload to be discarded. This received certificate MUST NOT be used to verify the message. The certificate of the trusted policy creation authority MUST be retrieved by other means.
3. 証明書データ - この証明書データは、指定された証明書タイプに従って処理する必要があります。このタイプは、データの形式を定義します。証明書のペイロードにおける信頼できる政策作成当局の証明書の受領により、ペイロードが破棄されます。この受け取った証明書を使用して、メッセージを確認する必要はありません。信頼された政策作成当局の証明書は、他の手段によって取得されなければなりません。
The Signature Payload contains data generated by the digital signature function. The digital signature, as defined by the dissection of each message, covers the message from the GSAKMP Message Header through the Signature Payload, up to but not including the Signature Data Length. Figure 21 shows the format of the Signature Payload.
署名ペイロードには、デジタル署名機能によって生成されたデータが含まれています。各メッセージの分析によって定義されているデジタル署名は、署名データの長さまでは、署名のペイロードを介してGSAKMPメッセージヘッダーからのメッセージをカバーします。図21は、署名ペイロードの形式を示しています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Type ! Sig ID Type ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Signature Timestamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Signer ID Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signer ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Length ! Signature Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Signature Payload Format
図21：署名ペイロード形式
The Signature Payload fields are defined as follows:
署名ペイロードフィールドは、次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Signature Type (2 octets) - Indicates the type of signature. Table 21 presents the allowable signature types. This field is treated as an unsigned integer in network byte order format.
署名タイプ（2オクテット） - 署名のタイプを示します。表21は、許容可能な署名タイプを示しています。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Table 21: Signature Types
表21：署名タイプ
Signature Type Value Description/
Defined In
_____________________________________________________________________
DSS/SHA1 with ASN.1/DER encoding 0 This type MUST
(DSS-SHA1-ASN1-DER) be supported.
RSA1024-MD5 1 See [RFC3447].
ECDSA-P384-SHA3 2 See [FIPS186-2].
Reserved to IANA 3 - 41952
Private Use 41953 - 65536
Signature ID Type (1 octet) - Indicates the format for the Signature ID Data. These values are the same as those defined for the Identification Payload Identification types, which can be found in Table 19. This field is treated as an unsigned value.
署名IDタイプ（1 Octet） - 署名IDデータの形式を示します。これらの値は、識別ペイロード識別タイプで定義されている値と同じです。これは表19にあります。このフィールドは、署名されていない値として扱われます。
Signature Timestamp (15 octets) - This is the time value when the digital signature was applied. This field contains the timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is the numerical value of the month (01 - 12), DD is the day of the month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within the hour (00 - 59), SS is the seconds within the minute (00 - 59), and the letter Z indicates that this is Zulu time. This format is loosely based on [RFC3161].
署名タイムスタンプ（15オクテット） - これは、デジタル署名が適用されたときの時間値です。このフィールドには、UTF -8形式のタイムスタンプが含まれていますyyyymmddhhmmssz、yyyyは年（0000-9999）、mmは月の数値（01-12）、DDは月（01-31）の日です。HHはその日の時間（00-23）、mmは1時間以内（00-59）、SSは1分以内（00-59）の数秒で、文字ZはこれがZulu時間であることを示します。この形式は、[RFC3161]に大まかに基づいています。
Signer ID Length (2 octets) - Length in octets of the Signer's ID. This field is treated as an unsigned integer in network byte order format.
署名者IDの長さ（2オクテット） - 署名者のIDのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Signer ID Data (variable length) - Data identifying the Signer's ID (e.g., DN). The format for this field is based on the Signature ID Type field and is shown where that type is defined. The contents of this field MUST be checked against the Policy Token to determine the authority and access of the Signer within the context of the group.
署名者IDデータ（変動長） - 署名者のID（DNなど）を識別するデータ。このフィールドの形式は、署名IDタイプフィールドに基づいており、そのタイプが定義されている場所で表示されます。このフィールドの内容は、グループのコンテキスト内で署名者の権限とアクセスを決定するために、ポリシートークンに対してチェックする必要があります。
Signature Length (2 octets) - Length in octets of the Signature Data. This field is treated as an unsigned integer in network byte order format.
署名長（2オクテット） - 署名データのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Signature Data (variable length) - Data that results from applying the digital signature function to the GSAKMP message and/or payload.
署名データ（変数長） - GSAKMPメッセージおよび/またはペイロードにデジタル署名関数を適用したことに起因するデータ。
The payload type for the Signature Payload is eight (8).
署名ペイロードのペイロードタイプは8（8）です。
When processing the Signature Payload, the following fields MUST be checked for correct values:
署名ペイロードを処理する場合、正しい値を次のフィールドに確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Signature Type - The Signature Type value MUST be checked to be a valid signature type as defined by Table 21. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 署名タイプ - 署名タイプの値は、表21で定義されている有効な署名タイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
3. Signature ID Type - The Signature ID Type value MUST be checked to be a valid signature ID type as defined by Table 19. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
3. 署名IDタイプ - 署名IDタイプ値は、表19で定義されている有効な署名IDタイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
4. Signature Timestamp - This field MAY be checked to determine if the transaction signing time is fresh relative to expected network delays. Such a check is appropriate for systems in which archived sequences of events are desired.
4. 署名タイムスタンプ - このフィールドをチェックして、予想されるネットワーク遅延に比べてトランザクション署名時間が新鮮かどうかを判断できます。このようなチェックは、アーカイブされた一連のイベントが望まれるシステムに適しています。
NOTE: The maximum acceptable age of a signature timestamp relative to the local system clock is a locally configured parameter that can be tuned by its GSAKMP management interface.
注：ローカルシステムクロックに比べて署名タイムスタンプの最大許容年齢は、GSAKMP管理インターフェイスで調整できるローカルで構成されたパラメーターです。
5. Signature ID Data - This field will be used to identify the sending party. This information MUST then be used to confirm that the correct party sent this information. This field is also used to retrieve the appropriate public key of the certificate to verify the message.
5. 署名IDデータ - このフィールドは、送信者を識別するために使用されます。次に、この情報を使用して、正しい当事者がこの情報を送信したことを確認する必要があります。このフィールドは、メッセージを確認するために証明書の適切な公開キーを取得するためにも使用されます。
6. Signature Data - This value MUST be compared to the recomputed signature to verify the message. Information on how to verify certificates used to ascertain the validity of the signature can be found in [RFC3280]. Only after the certificate identified by the Signature ID Data is verified can the signature be computed to compare to the signature data for signature verification. A potential error that can occur during signature verification is Authentication-Failed. Potential errors that can occur while processing certificates for signature verification are: Invalid-Certificate, Invalid-Cert-Authority, Cert-Type-Unsupported, and Certificate-Unavailable.
6. 署名データ - この値は、メッセージを確認するために再計算された署名と比較する必要があります。署名の有効性を確認するために使用される証明書を検証する方法に関する情報は、[RFC3280]に記載されています。署名IDデータによって識別された証明書が検証された後にのみ、署名検証の署名データと比較するように署名を計算できます。署名検証中に発生する可能性のある潜在的なエラーは、認証装置です。署名検証の証明書の処理中に発生する可能性のある潜在的なエラーは、無効な認証、無効な容認、証明書のunsupported、および証明書が利用できないことです。
The length fields in the Signature Payload are used to process the remainder of the payload. If any field is found to be incorrect, then termination processing MUST be initiated.
署名ペイロードの長さフィールドは、残りのペイロードを処理するために使用されます。いずれかのフィールドが正しくないことが判明した場合、終了処理を開始する必要があります。
The Notification Payload can contain both GSAKMP and group-specific data and is used to transmit informational data, such as error conditions, to a GSAKMP peer. It is possible to send multiple independent Notification payloads in a single GSAKMP message. Figure 22 shows the format of the Notification Payload.
通知ペイロードには、GSAKMPとグループ固有のデータの両方を含めることができ、エラー条件などの情報データをGSAKMPピアに送信するために使用できます。単一のGSAKMPメッセージで複数の独立した通知ペイロードを送信することができます。図22は、通知ペイロードの形式を示しています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Notification Type ! Notification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Notification Payload Format
図22：通知ペイロード形式
The Notification Payload fields are defined as follows:
通知ペイロードフィールドは、次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Notification Type (2 octets) - Specifies the type of notification message. Table 22 presents the Notify Payload Types. This field is treated as an unsigned integer in network byte order format.
通知タイプ（2オクテット） - 通知メッセージのタイプを指定します。表22は、通知のペイロードタイプを示しています。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Payload Type. Values for this field are Domain of Interpretation (DOI) specific.
通知データ（変動長） - 通知ペイロードタイプに加えて送信される情報またはエラーデータ。このフィールドの値は、解釈のドメイン（DOI）固有です。
The payload type for the Notification Payload is nine (9).
通知ペイロードのペイロードタイプは9（9）です。
Table 22: Notification Types
表22：通知タイプ
Notification Type Value
__________________________________________________________
None 0
Invalid-Payload-Type 1
Reserved 2 - 3
Invalid-Version 4
Invalid-Group-ID 5
Invalid-Sequence-ID 6
Payload-Malformed 7
Invalid-Key-Information 8
Invalid-ID-Information 9
Reserved 10 - 11
Cert-Type-Unsupported 12
Invalid-Cert-Authority 13
Authentication-Failed 14
Reserved 15 - 16
Certificate-Unavailable 17
Reserved 18
Unauthorized-Request 19
Reserved 20 - 22
Acknowledgement 23
Reserved 24 - 25
Nack 26
Cookie-Required 27
Cookie 28
Mechanism Choices 29
Leave Group 30
Departure Accepted 31
Request to Depart Error 32
Invalid Exchange Type 33
IPv4 Value 34
IPv6 Value 35
Prohibited by Group Policy 36
Prohibited by Locally Configured Policy 37
Reserved to IANA 38 - 49152
Private Use 49153 -- 65535
The data portion of the Notification payload of type ACK either serves as confirmation of correct receipt of the Key Download message or, when needed, provides other receipt information when included in a signed message. Figure 23 shows the format of the Notification Data - Acknowledge Payload Type.
タイプACKの通知ペイロードのデータ部分は、キーダウンロードメッセージの正しい受信の確認として機能するか、必要に応じて署名されたメッセージに含まれている場合、他の領収書情報を提供します。図23は、通知データの形式を示しています - ペイロードタイプを確認します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Ack Type ! Acknowledgement Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Notification Data - Acknowledge Payload Type Format
図23：通知データ - ペイロードタイプ形式を確認する
The Notification Data - Acknowledgement Payload Type data fields are defined as follows:
通知データ - 確認ペイロードタイプのデータフィールドは、次のように定義されています。
Ack Type (1 octet) - Specifies the type of acknowledgement. Table 23 presents the Notify Acknowledgement Payload Types. This field is treated as an unsigned value.
ACKタイプ（1 Octet） - 確認のタイプを指定します。表23は、通知の確認ペイロードタイプを示しています。このフィールドは、署名されていない値として扱われます。
Table 23: Acknowledgement Types
表23：確認タイプ
ACK_Type Value Definition
_____________________________________________________
Simple 0 Data portion null. Reserved to IANA 1 - 192 Private Use 193 - 255
単純な0データ部分ヌル。IANA 1-192私的使用193-255に予約
The data portion of the Notification payload of types Cookie_Required and Cookie contain the Cookie value. The value for this field will have been computed by the responder GC/KS and sent to the GM. The GM will take the value received and copy it into the Notification payload Notification Data field of type Cookie that is transmitted in the "Request to Join with Cookie Info" back to the GC/KS. The cookie value MUST NOT be modified.
Cookie_requiredとCookieのタイプの通知ペイロードのデータ部分には、Cookie値が含まれています。このフィールドの値は、レスポンダーGC/ksによって計算され、GMに送信されます。GMは、受信した値を取得し、「Cookie情報に参加するリクエスト」に送信されるタイプCookieの通知ペイロード通知データフィールドにGC/KSに戻ります。Cookie値を変更してはなりません。
The format for this is already described in the discussion on cookies in Section 5.2.2.
このための形式は、セクション5.2.2のCookieに関する議論で既に説明されています。
The data portion of the Notification payload of type Mechanism Choices contains the mechanisms the GM is requesting to use for the negotiation with the GC/KS. This information will be supplied by the GM in a RTJ message. Figure 24 shows the format of the Notification Data - Mechanism Choices Payload Type. Multiple type|length|data choices are strung together in one notification payload to allow a user to transmit all relevant information within one Notification Payload. The length of the payload will control the parsing of the Notification Data Mechanism Choices field.
タイプメカニズムの選択肢の通知ペイロードのデータ部分には、GMがGC/KSとの交渉に使用することを要求しているメカニズムが含まれています。この情報は、GMによってRTJメッセージで提供されます。図24は、通知データ - メカニズムの選択肢ペイロードタイプの形式を示しています。複数のタイプ|長さ|データの選択は、1つの通知ペイロードにまとめられ、ユーザーが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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mech Type ! Mechanism Choice Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..
Figure 24: Notification Data - Mechanism Choices Payload Type Format
図24：通知データ - メカニズムの選択ペイロードタイプ形式
The Notification Data - Mechanism Choices Payload Type data fields are defined as follows:
通知データ - メカニズムの選択ペイロードタイプデータフィールドは、次のように定義されています。
Mechanism Type (1 octet) - Specifies the type of mechanism. Table 24 presents the Notify Mechanism Choices Mechanism Types. This field is treated as an unsigned value.
メカニズムタイプ（1オクテット） - メカニズムのタイプを指定します。表24は、通知メカニズムの選択メカニズムタイプを示しています。このフィールドは、署名されていない値として扱われます。
Table 24: Mechanism Types
表24：メカニズムの種類
Mechanism_Type Value Mechanism Choice
Data Value Table Reference
___________________________________________________________________
Key Creation Algorithm 0 Table 26
Encryption Algorithm 1 Table 16
Nonce Hash Algorithm 2 Table 25
Reserved to IANA 3 - 192
Private Use 193 - 255
Mechanism Choice Data (2 octets) - The data value for the mechanism type being selected. The values are specific to each Mechanism Type defined. All tables necessary to define the values that are not defined elsewhere (in this specification or others) are defined here. This field is treated as an unsigned integer in network byte order format.
メカニズムの選択データ（2オクテット） - 選択されるメカニズムタイプのデータ値。値は、定義された各メカニズムタイプに固有です。他の場所（この仕様など）で定義されていない値を定義するために必要なすべてのテーブルは、ここで定義されています。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Table 25: Nonce Hash Types
表25：非CEハッシュタイプ
Nonce_Hash_Type Value Description
__________________________________________________________________
Reserved 0
SHA-1 1 This type MUST be supported.
Reserved to IANA 2 - 49152
Private Use 49153 - 65535
The data portion of the Notification payload of type IPv4 and IPv6 value contains the appropriate IP value in network byte order. This value will be set by the creator of the message for consumption by the receiver of the message.
タイプIPv4およびIPv6値の通知ペイロードのデータ部分には、ネットワークバイトの順序で適切なIP値が含まれています。この値は、メッセージの受信者による消費のためのメッセージの作成者によって設定されます。
When processing the Notification Payload, the following fields MUST be checked for correct values:
通知のペイロードを処理する場合、正しい値を次のフィールドに確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Notification Type - The Notification type value MUST be checked to be a notification type as defined by Table 22. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. 通知タイプ - 表22で定義されている通知タイプの値を通知タイプにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
3. Notification Data - This Notification Data MUST be processed according to the notification type specified. The type will define the format of the data. When processing this data, any type field MUST be checked against the appropriate table for correct values. If the contents of the Notification Data are not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
3. 通知データ - この通知データは、指定された通知タイプに従って処理する必要があります。このタイプは、データの形式を定義します。このデータを処理する場合、任意のタイプフィールドに適切なテーブルに対して正しい値を確認する必要があります。通知データの内容が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
The Vendor ID Payload contains a vendor-defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. Figure 25 shows the format of the payload.
ベンダーIDペイロードには、ベンダー定義の定数が含まれています。定数は、ベンダーが実装のリモートインスタンスを特定して認識するために使用されます。このメカニズムにより、ベンダーは後方互換性を維持しながら、新しい機能を実験することができます。図25は、ペイロードの形式を示しています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Vendor ID (VID) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Vendor ID Payload Format
図25：ベンダーIDペイロード形式
A Vendor ID payload MAY announce that the sender is capable of accepting certain extensions to the protocol, or it MAY simply identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to send any Vendor ID payload at all.
ベンダーIDペイロードは、送信者が特定の拡張機能をプロトコルに受け入れることができることを発表する場合があります。また、デバッグの支援として実装を単に特定することもできます。ベンダーIDペイロードは、この仕様で定義されている情報の解釈を変更してはなりません。複数のベンダーIDペイロードを送信できます。ベンダーIDペイロードをまったく送信するために実装は必要ありません。
A Vendor ID payload may be sent as part of any message. Receipt of a familiar Vendor ID payload allows an implementation to make use of Private Use numbers described throughout this specification -- private payloads, private exchanges, private notifications, etc. This implies that all the processing rules defined for all the payloads are now modified to recognize all values defined by this Vendor ID for all fields of all payloads. Unfamiliar Vendor IDs MUST be ignored.
ベンダーIDペイロードは、メッセージの一部として送信される場合があります。おなじみのベンダーIDペイロードの受領により、この仕様全体で説明されているプライベート使用番号など、プライベートペイロード、プライベートエクスチェンジ、プライベート通知などを実装できます。これは、すべてのペイロードに対して定義されたすべての処理ルールが変更されたことを意味します。すべてのペイロードのすべてのフィールドに対して、このベンダーIDで定義されたすべての値を認識します。なじみのないベンダーIDは無視する必要があります。
Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts that gain acceptance and are standardized will be given assigned values out of the Reserved to IANA range, and the requirement to use a Vendor ID payload will go away.
このプロトコルを拡張したいインターネットドラフトの作家は、ベンダーIDペイロードを定義して、インターネットドラフトに拡張機能を実装する機能を発表する必要があります。受け入れられ、標準化されたインターネットドラフトには、IANA範囲に予約された値から割り当てられた値が与えられ、ベンダーIDペイロードを使用するための要件はなくなります。
The Vendor ID payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
ベンダーIDペイロードフィールドは、次のように定義されます。次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Vendor ID (variable length) - The Vendor ID value. The minimum length for this field is four (4) octets. It is the responsibility of the person choosing the Vendor ID to assure its uniqueness in spite of the absence of any central registry for IDs. Good practice is to include a company name, a person name, or similar type data. A message digest of a long unique string is preferable to the long unique string itself.
ベンダーID（変動長） - ベンダーID値。このフィールドの最小長は4オクテットです。IDの中央レジストリがないにもかかわらず、ベンダーIDを選択する人の責任です。良い実践は、会社名、個人名、または同様のタイプデータを含めることです。長い一意の文字列のメッセージダイジェストは、長い一意の文字列自体よりも望ましいです。
The payload type for the Vendor ID Payload is ten (10).
ベンダーIDペイロードのペイロードタイプは10（10）です。
When processing the Vendor ID Payload, the following fields MUST be checked for correct values:
ベンダーIDペイロードを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Vendor ID - The Vendor ID Data MUST be processed to determine if the Vendor ID value is recognized by the implementation. If the Vendor ID value is not recognized, then regardless of mode (e.g., Terse or Verbose) this information is logged. Processing of the message MUST continue regardless of recognition of this value.
2. ベンダーID -ベンダーIDデータを処理して、ベンダーID値が実装によって認識されるかどうかを判断する必要があります。ベンダーID値が認識されていない場合、モード（たとえば、TerseまたはVerbose）に関係なく、この情報が記録されます。メッセージの処理は、この値の認識に関係なく続行する必要があります。
It is recommended that implementations that want to use Vendor-ID-specific information attempt to process the Vendor ID payloads of an incoming message prior to the remainder of the message processing. This will allow the implementation to recognize that when processing other payloads it can use the larger set of values for payload fields (Private Use values, etc.) as defined by the recognized Vendor IDs.
ベンダー-ID固有の情報を使用したい実装は、メッセージ処理の残りの前にベンダーIDのペイロードを着信メッセージのペイロードを処理しようとすることをお勧めします。これにより、実装により、他のペイロードを処理するときに、認識されたベンダーIDで定義されているように、ペイロードフィールド（プライベート使用値など）の値のセットを使用できることが認識されます。
The Key Creation Payload contains information used to create key encryption keys. The security attributes for this payload are provided in the Policy Token. Figure 26 shows the format of the payload.
キー作成ペイロードには、キー暗号化キーの作成に使用される情報が含まれています。このペイロードのセキュリティ属性は、ポリシートークンに記載されています。図26は、ペイロードの形式を示しています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Creation Type ! Key Creation Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Key Creation Payload Format
図26：キー作成ペイロード形式
The Key Creation Payload fields are defined as follows:
キー作成ペイロードフィールドは、次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Key Creation Type (2 octets) - Specifies the type of Key Creation being used. Table 26 identifies the types of key creation information. This field is treated as an unsigned integer in network byte order format.
キー作成タイプ（2オクテット） - 使用されるキー作成のタイプを指定します。表26は、主要な作成情報の種類を特定しています。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Key Creation Data (variable length) - Contains Key Creation information. The values for this field are group specific, and the format is specified by the key creation type field.
キー作成データ（変動長） - キー作成情報が含まれています。このフィールドの値はグループ固有であり、形式はキー作成タイプフィールドによって指定されます。
The payload type for the Key Creation Packet is eleven (11).
キー作成パケットのペイロードタイプは11です（11）。
Table 26: Types of Key Creation Information
表26：キー作成情報の種類
Key Creation Type Value Definition/Defined In
_____________________________________________________________________
Reserved 0 - 1
Diffie-Hellman 2 This type MUST be supported.
1024-bit MODP Group Defined in [IKEv2] B.2.
Truncated If the output of the process
is longer than needed for
the defined mechanism, use
the first X low order bits
and truncate the remainder.
Reserved 3 - 13
Diffie-Hellman 14 Defined in [RFC3526].
2048-bit MODP Group If the output of the process
Truncated is longer than needed for
the defined mechanism, use
the first X low order bits
and truncate the remainder.
Reserved to IANA 15 - 49152
Private Use 49153 - 65535
The specifics of the Key Creation Payload are defined in Section 7.11.
キー作成ペイロードの詳細は、セクション7.11で定義されています。
When processing the Key Creation Payload, the following fields MUST be checked for correct values:
キー作成ペイロードを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Key Creation Type - The Key Creation Type value MUST be checked to be a valid key creation type as defined by Table 26. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. キー作成タイプ - キー作成タイプの値は、表26で定義されている有効なキー作成タイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
3. Key Creation Data - This Key Creation Data MUST be processed according to the key creation type specified to generate the KEK to protect the information to be sent in the appropriate message. The type will define the format of the data.
3. キー作成データ - このキー作成データは、適切なメッセージで送信される情報を保護するためにKEKを生成するために指定されたキー作成タイプに従って処理する必要があります。このタイプは、データの形式を定義します。
Implementations that want to derive other keys from the initial Key Creation keying material (for example, DH Secret keying material) MUST define a Key Creation Type other than one of those shown in Table 26. The new Key Creation Type must specify that derivation's algorithm, for which the KEK MAY be one of the keys derived.
最初のキー作成キーイング素材（たとえば、DH Secret Keying Material）から他のキーを導出したい実装は、表26に示すものの1つ以外のキー作成タイプを定義する必要があります。Kekは派生したキーの1つである可能性があります。
The Nonce Payload contains random data used to guarantee freshness during an exchange and protect against replay attacks. Figure 27 shows the format of the Nonce Payload.
NonCeペイロードには、交換中の新鮮さを保証し、リプレイ攻撃から保護するために使用されるランダムデータが含まれています。図27は、NonCeペイロードの形式を示しています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Nonce Type ! Nonce Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Nonce Payload Format
図27：NonCEペイロード形式
The Nonce Payload fields are defined as follows:
NONCEペイロードフィールドは、次のように定義されています。
Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value.
次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドは0になります。このフィールドは「チェーン」機能を提供します。表12は、ペイロードタイプを特定しています。このフィールドは、署名されていない値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
予約済み（1オクテット） - 未使用、0に設定。
Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format.
ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。このフィールドは、ネットワークバイトの順序形式で署名されていない整数として扱われます。
Nonce Type (1 octet) - Specifies the type of nonce being used. Table 27 identifies the types of nonces. This field is treated as an unsigned value.
NonCe Type（1 Octet） - 使用されているNonCEのタイプを指定します。表27は、Noncesのタイプを示しています。このフィールドは、署名されていない値として扱われます。
Table 27: Nonce Types
表27：非CEタイプ
Nonce_Type Value Definition
_____________________________________________________________________
None 0
Initiator (Nonce_I) 1
Responder (Nonce_R) 2
Combined (Nonce_C) 3 Hash (Append
(Initiator_Value,Responder_Value))
The hash type comes from the
Policy (e.g., Security Suite
Definition of Policy Token).
Reserved to IANA 4 - 192
Private Use 192 - 255
Nonce Data (variable length) - Contains the nonce information. The values for this field are group specific, and the format is specified by the Nonce Type field. If no group-specific information is provided, the minimum length for this field is 4 bytes.
NonCeデータ（変数長） - NonCe情報が含まれています。このフィールドの値はグループ固有であり、形式はNonCe型フィールドによって指定されます。グループ固有の情報が提供されていない場合、このフィールドの最小長は4バイトです。
The payload type for the Nonce Payload is twelve (12).
NonCeペイロードのペイロードタイプは12（12）です。
When processing the Nonce Payload, the following fields MUST be checked for correct values:
非CEペイロードを処理する場合、次のフィールドに正しい値を確認する必要があります。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1. 次のペイロード、予約済み、ペイロード長 - これらのフィールドは、セクション7.2.2「一般的なペイロードヘッダー処理」で定義されているように処理されます。
2. Nonce Type - The Nonce Type value MUST be checked to be a valid nonce type as defined by Table 27. If the value is not valid, then an error is logged. If in Verbose Mode, an appropriate message containing notification value Payload-Malformed will be sent.
2. NonCe Type -NonCeタイプの値は、表27で定義されている有効なNonCeタイプであるようにチェックする必要があります。値が有効でない場合、エラーが記録されます。冗長モードの場合、通知値のペイロードマルフォームを含む適切なメッセージが送信されます。
3. Nonce Data - This is the nonce data and it must be checked according to its content. The size of this field is defined in Section 7.12, "Nonce Payload". Refer to Section 5.2, "Group Establishment", for interpretation of this field.
3. NONCEデータ - これはNONCEデータであり、コンテンツに従ってチェックする必要があります。このフィールドのサイズは、セクション7.12「非CEペイロード」で定義されています。この分野の解釈については、セクション5.2「グループ設立」を参照してください。
Figure 28 presents the states encountered in the use of this protocol. Table 28 defines the states. Table 29 defines the transitions.
図28は、このプロトコルの使用で遭遇した状態を示しています。表28は州を定義しています。表29は、遷移を定義しています。
!-----------------> ( )
! !-------------> ( Idle ) <------------------!
! ! ( ) !
! ! ! ! !
! ! ! ! !
! ! (1a) (1) !
! ! ! ! !
! ! ! ! !
! ! V V !
! !---(5a)--- (Wait for ) (Wait for ) ----(5)-----!
! (Group ) (GC/KS Event) <---
! (Membership) ^ ! \ \
! ! ! ! \ \
! ! ! ! \--(2)---\
! (2a) (4)(3)
! ! ! !
! ! ! !
! V ! V
!-------(4a)--- (Wait for ) (Wait for )
(Group ) (Response )
(Membership) (from Key )
/--> (Event ) (Download )
/ /
/ /
/--(3a)---/
Figure 28: GSAKMP State Diagram
図28：GSAKMP状態図
Table 28: GSAKMP States
______________________________________________________________________
Idle : GSAKMP Application waiting for input
______________________________________________________________________
Wait for GC/KS Event : GC/KS up and running, waiting for events
______________________________________________________________________
Wait for Response : GC/KS has sent Key Download,
from Key Download : waiting for response from GM
______________________________________________________________________
Wait for Group : GM in process of joining group
Membership :
______________________________________________________________________
Wait for Group : GM has group key, waiting for
Membership Event : group management messages.
______________________________________________________________________
Table 29: State Transition Events
____________________________________________________________________
Transition 1 : Create group command
______________:_____________________________________________________
:
Transition 2 : Receive bad RTJ
: Receive valid command to change group membership
: Send Compromise message x times
: Member Deregistration
______________:_____________________________________________________
:
Transition 3 : Receive valid RTJ
______________:_____________________________________________________
:
Transition 4 : Timeout
: Receive Ack
: Receive Nack
______________:_____________________________________________________
:
Transition 5 : Delete group command
______________:_____________________________________________________
:
Transition 1a : Join group command
______________:_____________________________________________________
:
Transition 2a : Send Ack
______________:_____________________________________________________
:
Transition 3a : Receipt of group management messages
______________:_____________________________________________________
:
Transition 4a : Delete group command
: Deregistration command
______________:_____________________________________________________
:
Transition 5a : Time out
: Msg failure
: errors
:
____________________________________________________________________
IANA has provided GSAKMP port number 3761 in both the UDP and TCP spaces. All implementations MUST use this port assignment in the appropriate manner.
IANAは、UDPスペースとTCPスペースの両方でGSAKMPポート番号3761を提供しています。すべての実装は、適切な方法でこのポート割り当てを使用する必要があります。
The following registry entries have been created:
次のレジストリエントリが作成されました。
GSAKMP Group Identification Types (Section 7.1.1) GSAKMP Payload Types (Section 7.1.1) GSAKMP Exchange Types (Section 7.1.1) GSAKMP Policy Token Types (Section 7.3.1) GSAKMP Key Download Data Item Types (Section 7.4.1) GSAKMP Cryptographic Key Types (Section 7.4.1.1) GSAKMP Rekey Event Types (Section 7.5.1) GSAKMP Identification Classification (Section 7.6.1) GSAKMP Identification Types (Section 7.6.1) GSAKMP Certificate Types (Section 7.7.1) GSAKMP Signature Types (Section 7.8.1) GSAKMP Notification Types (Section 7.9.1) GSAKMP Acknowledgement Types (Section 7.9.1.1) GSAKMP Mechanism Types (Section 7.9.1.3) GSAKMP Nonce Hash Types (Section 7.9.1.3) GSAKMP Key Creation Types (Section 7.11.1) GSAKMP Nonce Types (Section 7.12.1)
GSAKMPグループ識別タイプ（セクション7.1.1）GSAKMPペイロードタイプ（セクション7.1.1）GSAKMP交換タイプ（セクション7.1.1）GSAKMPポリシートークンタイプ（セクション7.3.1）GSAKMPキーダウンロードデータ項目タイプ（セクション7.4.1）GSAKMP暗号化キータイプ（セクション7.4.1.1）（セクション7.8.1）GSAKMP通知タイプ（セクション7.9.1）GSAKMP確認タイプ（セクション7.9.1.1）GSAKMPメカニズムタイプ（セクション7.9.1.3）GSAKMP NONCE HASHタイプ（セクション7.9.1.3）GSAKMPキー作成タイプ（セクション7.1111111111111.1）GSAKMP NONCEタイプ（セクション7.12.1）
Changes and additions to the following registries are by IETF Standards Action:
次のレジストリの変更と追加は、IETF標準アクションによるものです。
GSAKMP Group Identification Types GSAKMP Payload Types GSAKMP Exchange Types GSAKMP Policy Token Types GSAKMP Key Download Data Item Types GSAKMP Rekey Event Types GSAKMP Identification Classification GSAKMP Notification Types GSAKMP Acknowledgement Types GSAKMP Mechanism Types GSAKMP Nonce Types Changes and additions to the following registries are by Expert Review:
GSAKMPグループ識別タイプGSAKMPペイロードタイプGSAKMP ExchangeタイプGSAKMPポリシートークンタイプ：
GSAKMP Cryptographic Key Types GSAKMP Identification Types GSAKMP Certificate Types GSAKMP Signature Types GSAKMP Nonce Hash Types GSAKMP Key Creation Types
GSAKMP暗号化キータイプGSAKMP識別タイプGSAKMP証明書タイプGSAKMP署名タイプGSAKMP NONCE HASHタイプGSAKMPキー作成タイプ
This document is the collaborative effort of many individuals. If there were no limit to the number of authors that could appear on an RFC, the following, in alphabetical order, would have been listed: Haitham S. Cruickshank of University of Surrey, Sunil Iyengar of University Of Surrey Gavin Kenny of LogicaCMG, Patrick McDaniel of AT&T Labs Research, and Angela Schuett of NSA.
このドキュメントは、多くの個人の共同作業です。RFCに登場する可能性のある著者の数に制限がなかった場合、以下はアルファベット順にリストされていたでしょう：サリー大学のハイサムS.クルックシャンク、ロジカクムのサリー大学ギャビンケニーのスニル・イエンガー、パトリックAT＆T Labs ResearchのMcDanielとNSAのAngela Schuett。
The following individuals deserve recognition and thanks for their contributions, which have greatly improved this protocol: Eric Harder is an author to the Tunneled-GSAKMP, whose concepts are found in GSAKMP as well. Rod Fleischer, also a Tunneled-GSAKMP author, and Peter Lough were both instrumental in coding a prototype of the GSAKMP software and helped define many areas of the protocol that were vague at best. Andrew McFarland and Gregory Bergren provided critical analysis of early versions of the specification. Ran Canetti analyzed the security of the protocol and provided denial of service suggestions leading to optional "cookie protection".
次の個人は、このプロトコルを大幅に改善した貢献に感謝し、貢献に感謝します。EricHarderは、GSAKMPにも概念が見られるTunneled-GSAKMPの著者です。トンネルGSAKMPの著者でもあるロッド・フライシャーとピーター・ラフはどちらもGSAKMPソフトウェアのプロトタイプのコーディングに役立ち、せいぜい曖昧なプロトコルの多くの領域を定義するのに役立ちました。Andrew McFarlandとGregory Bergrenは、仕様の初期バージョンの批判的分析を提供しました。Ran Canettiはプロトコルのセキュリティを分析し、オプションの「Cookie Protection」につながるサービス拒否提案を提供しました。
[DH77] Diffie, W., and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, June 1977.
[DH77] Diffie、W。、およびM. Hellman、「暗号化の新しい方向」、IEEE情報理論、1977年6月。
[FIPS186-2] NIST, "Digital Signature Standard", FIPS PUB 186-2, National Institute of Standards and Technology, U.S. Department of Commerce, January 2000.
[FIPS186-2] NIST、「Digital Signature Standard」、Fips Pub 186-2、国立標準技術研究所、米国商務省、2000年1月。
[FIPS196] "Entity Authentication Using Public Key Cryptography," Federal Information Processing Standards Publication 196, NIST, February 1997.
[FIPS196]「公開キー暗号化を使用したエンティティ認証」、連邦情報処理標準出版196、1997年2月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412] Orman、H。、「The Oakley Key Deicination Protocol」、RFC 2412、1998年11月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627] Wallner、D.、Harder、E。、およびR. Agee、「マルチキャストの重要な管理：問題とアーキテクチャ」、RFC 2627、1999年6月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、ed。、「Lightweight Directory Access Protocol（LDAP）：著名な名前の文字列表現」、RFC 4514、2006年6月。
[RFC4534] Colegrove, A. and H. Harney, "Group Security Policy Token v1", RFC 4534, June 2006.
[RFC4534] Colegrove、A。およびH. Harney、「Group Security Policy Token V1」、RFC 4534、2006年6月。
[BMS] Balenson, D., McGrew, D., and A. Sherman, "Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization", Work in Progress, February 1999.
[BMS] Balenson、D.、McGrew、D。、およびA. Sherman、「大規模な動的グループの重要な管理：一元配置機能ツリーと償却初期化」、1999年2月、作業進行中。
[HCM] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy in Secure Groups", Proceedings of Network and Distributed Systems Security 2001 Internet Society, San Diego, CA, February 2001.
[HCM] H. Harney、A。Colegrove、P。McDaniel、「安全なグループにおける政策の原則」、2001年2月、カリフォルニア州サンディエゴのネットワークおよび分散システムセキュリティ2001インターネットソサエティの議事録。
[HHMCD01] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and P. Dinsmore, "Group Security Policy Token: Definition and Payloads", Work in Progress, August 2003.
[HHMCD01] Hardjono、T.、Harney、H.、McDaniel、P.、Colegrove、A。、およびP. Dinsmore、「グループセキュリティポリシートークン：定義とペイロード」、Progress、Progress、2003年8月。
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093] Harney、H。およびC. Muckenhirn、「グループキー管理プロトコル（GKMP）仕様」、RFC 2093、1997年7月。
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC2094] Harney、H。およびC. Muckenhirn、「グループキー管理プロトコル（GKMP）アーキテクチャ」、RFC 2094、1997年7月。
[RFC2408] Maughan D., Schertler M., Schneider M., and Turner J., "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, Proposed Standard, November 1998
[RFC2408] Maughan D.、Schertler M.、Schneider M.、およびTurner J.、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、1998年11月、標準提案
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Phyuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.
[RFC4523] Zeilenga、K。、「X.509証明書のLightweight Directory Access Protocol（LDAP）スキーマ定義」、RFC 4523、2006年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3161] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「Internet X.509公開キーインフラストラクチャタイムスタンププロトコル（TSP）」、RFC 3161、2001年8月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J.およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T。およびM. Kojo、「インターネットキーエクスチェンジ（IKE）のためのよりモジュラー指数（MODP）Diffie-Hellmanグループ」、RFC 3526、2003年5月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
This appendix will give an overview of LKH, define the values for fields within GSAKMP messages that are specific to LKH, and give an example of a Rekey Event Message using the LKH scheme.
この付録は、LKHの概要を示し、LKHに固有のGSAKMPメッセージ内のフィールドの値を定義し、LKHスキームを使用したRekeyイベントメッセージの例を示します。
LKH provides a topology for handling key distribution for a group rekey. It rekeys a group based upon a tree structure and subgroup keys. In the LKH tree shown in Figure 29, members are represented by the leaf nodes on the tree, while intermediate tree nodes represent abstract key groups. A member will possess multiple keys: the group traffic protection key (GTPK), subgroup keys for every node on its path to the root of the tree, and a personal key. For example, the member labeled as #3 will have the GTPK, Key A, Key D, and Key 3.
LKHは、グループRekeの重要な分布を処理するためのトポロジを提供します。ツリー構造とサブグループキーに基づいてグループを再キーします。図29に示すLKHツリーでは、メンバーはツリー上の葉のノードで表され、中間ツリーノードは抽象的なキーグループを表します。メンバーには、グループトラフィック保護キー（GTPK）、ツリーのルートへのパス上のすべてのノードのサブグループキー、および個人キーの複数のキーがあります。たとえば、＃3とラベル付けされたメンバーには、GTPK、キーA、キーD、およびキー3があります。
root
/ \
/ \
A B
/ \ / \
/ \ / \
C D E F
/ \ / \ / \ / \
/ \ / \ / \ / \
1 2 3 4 5 6 7 8
Figure 29: LKH Tree
図29：LKHツリー
This keying topology provides for a rapid rekey to all but a compromised member of the group. If Member 3 were compromised, the new GTPK (GTPK') would need to be distributed to the group under a key not possessed by Member 3. Additionally, new Keys A and D (Key A' and Key D') would also need to be securely distributed to the other members of those subtrees. Encrypting the GTPK' with Key B would securely distribute that key to Members 5, 6, 7, and 8. Key C can be used to encrypt both the GTPK' and Key A' for Members 1 and 2. Member 3's nearest neighbor, Member 4, can obtain GTPK', Key D', and Key A' encrypted under its personal key, Key 4. At the end of this process, the group is securely rekeyed with Member 3 fully excluded.
このキーイングトポロジーは、グループの妥協したメンバー以外のすべての人に迅速な再キーを提供します。メンバー3が侵害された場合、新しいGTPK（GTPK '）をメンバー3が所有していないキーの下でグループに配布する必要があります。さらに、新しいキーAとD（キーA'およびキーD '）も必要ですこれらのサブツリーの他のメンバーにしっかりと配布されます。キーBを使用してGTPKを暗号化すると、そのキーはメンバー5、6、7、および8に安全に配布されます。キーCを使用して、メンバー1および2のGTPK 'とキーA「」の両方を暗号化できます。4、GTPK '、キーD'を取得し、キーAは、そのプロセスの最後に、そのプロセスの最後に、メンバー3が完全に除外されて安全に再キーされます。
When using LKH with GSAKMP, the following issues require attention:
GSAKMPでLKHを使用する場合、次の問題には注意が必要です。
1. Rekey Version # - The Rekey Version # in the Rekey Array of the Key Download Payload MUST contain the value one (1).
1. Rekeyバージョン＃ - キーダウンロードペイロードのRekeyアレイのRekeyバージョン＃は、値1（1）を含める必要があります。
2. Algorithm Version - The Algorithm Version in the Rekey Event Payload MUST contain the value one (1).
2. アルゴリズムバージョン-Rekeyイベントペイロードのアルゴリズムバージョンには、値1（1）を含める必要があります。
3. Degree of Tree - The LKH tree used can be of any degree; it need not be binary.
3. ツリーの程度 - 使用されるLKHツリーは、どんな程度もあります。バイナリである必要はありません。
4. Node Identification - Each node in the tree is treated as a KEK. A KEK is just a special key. As the rule stated for all keys in GSAKMP, the set of the KeyID and the KeyHandle MUST be unique. A suggestion on how to do this will be given in this section.
4. ノード識別 - ツリー内の各ノードはKEKとして扱われます。ケックは特別な鍵です。ルールがGSAKMPのすべてのキーについて述べたように、KeyIDとKeyHandleのセットは一意でなければなりません。これを行う方法に関する提案は、このセクションで説明します。
5. Wrapping KeyID and Handle - This is the KeyID and Handle of the LKH node used to wrap/encrypt the data in a Rekey Event Data.
5. KeyIDとハンドルのラッピング - これは、Rekeyイベントデータでデータをラップ/暗号化するために使用されるLKHノードのKeyIDとハンドルです。
For the following discussion, refer to Figure 30.
次の説明については、図30を参照してください。
Key: o: a node in the LKH tree N: this line contains the KeyID node number L: this line contains the MemberID number for all leaves ONLY
キー：O：LKHツリーNのノードn：この行にはKeyIDノード番号Lが含まれています。
LEVEL
----
root o
N: / 1 \
/ \
1 o o
N: / 2 \ / 3 \
/ \ / \
2 o o o o
N: /4\ /5\ /6\ /7\
/ \ / \ / \ / \
3 o o o o o o o o
N: 8 9 10 11 12 13 14 15
L: 1 2 3 4 5 6 7 8
Figure 30: GSAKMP LKH Tree
図30：GSAKMP LKHツリー
To guarantee uniqueness of KeyID, the Rekey Controller SHOULD build a virtual tree and label the KeyID of each node, doing a breadth-first search of a fully populated tree regardless of whether or not the tree is actually full. For simplicity of this example, the root of the tree was given KeyID value of one (1). These KeyID values will be static throughout the life of this tree. Additionally, the rekey arrays distributed to GMs requires a MemberID value associated with them to be distributed with the KeyDownload Payload. These MemberID values MUST be unique. Therefore, the set associated with each leaf node (the nodes from that leaf back to the root) are given a MemberID. In this example, the leftmost leaf node is given MemberID value of one (1). These 2 sets of values, the KeyIDs (represented on lines N) and the MemberIDs (represented on line L), will give sufficient information in the KeyDownload and RekeyEvent Payloads to disseminate information. The KeyHandle associated with these keys is regenerated each time the key is replaced in the tree due to compromise.
KeyIDの一意性を保証するために、Rekeyコントローラーは仮想ツリーを構築し、各ノードのKeyIDにラベルを付け、ツリーが実際にいっぱいかどうかに関係なく、完全に人口の多いツリーを幅広く検索する必要があります。この例を簡単にするために、ツリーのルートには1つのKeyID値が与えられました（1）。これらのKeyID値は、このツリーの生涯を通じて静的になります。さらに、GMSに配布されたRekeyアレイには、キーダウンロードペイロードに関連付けられたMemberID値を必要とします。これらのMemberID値は一意でなければなりません。したがって、各リーフノード（その葉からルートに戻るノード）に関連付けられたセットには、メンバーIDが与えられます。この例では、左端の葉のノードには1つのメンバーID値が与えられます（1）。これらの2セットの値、KeyIDS（nで表されます）とMemberIDS（Line Lに表されます）は、キーダウンロードと再キーエレクトペイロードに十分な情報を提供して、情報を広めます。これらのキーに関連付けられたキーハンドルは、妥協のためにキーがツリーに置き換えるたびに再生されます。
Definition of values: 0xLLLL - length value 0xHHHHHHH# - handle value YYYYMMDDHHMMSSZ - time value
値の定義：0xllll-長さの値0xhhhhhhh＃ - ハンドル値yyyymmddhhmmsz-時間値
This section will give an example of the data for the Key Download payload. The GM will be given MemberID 1 and its associated keys. The data shown will be subsequent to the Generic Payload Header.
このセクションでは、キーダウンロードペイロードのデータの例を示します。GMには、MemberID 1とその関連キーが与えられます。表示されているデータは、汎用ペイロードヘッダーの後に行われます。
| GTPK | MemberID 1 | KeyID 2 | KeyID 4 | KeyID 8
|GTPK |MemberID 1 |keyid 2 |keyid 4 |KeyID 8
Number of Items - 0x0002
Item #1:
Key Download Data Item Type - 0x00 (GTPK)
Key Download Data Item Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - KEY1
Key Handle - 0xHHHHHHH0
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Item #2:
Key Download Data Item Type - 0x01 (Rekey - LKH)
Key Download Data Item Length - 0xLLLL
Rekey Version Number - 0x01
Member ID - 0x00000001
Number of KEK Keys - 0x0003
KEK #1:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000002
Key Handle - 0xHHHHHHH2
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
KEK #2:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000004
Key Handle - 0xHHHHHHH4
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
KEK #3:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000008
Key Handle - 0xHHHHHHH8
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
This section will give an example of the data for the Rekey Event payload. The GM with MemberID 6 will be keyed out of the group. The data shown will be subsequent to the Generic Payload Header.
このセクションでは、Rekeyイベントペイロードのデータの例を示します。MemberID 6のGMは、グループからキーが出されます。表示されているデータは、汎用ペイロードヘッダーの後に行われます。
| Rekey Event Type | GroupID | Date/Time | Rekey Type | Algorithm Ver | # of Packets | { (GTPK)2, (GTPK, 3', 6')12, (GTPK, 3')7 }
|再キーイベントタイプ|GroupId |日付/時刻|Rekey Type |アルゴリズムVer |パケットの＃|{（gtpk）2、（gtpk、3 '、6'）12、（gtpk、3 '）7}
This data shows that three packets are being transmitted. Read each packet as:
このデータは、3つのパケットが送信されていることを示しています。各パケットを読む：
a) GTPK wrapped in LKH KeyID 2 b) GTPK, LKH KeyIDs 3' & 6', all wrapped in LKH KeyID 12 c) GTPK and LKH KeyID 3', all wrapped in LKH KeyID 7
a) lkh keyid 2に包まれたgtpk b）gtpk、lkh keyids 3 '＆6'、すべてlkh keyid 12 c）gtpkおよびlkh keyid 3 'に包まれ、すべてlkh keyid 7に包まれています
NOTE: Although in this example multiple keys are encrypted under one key, alternative pairings are legal (e.g., (GTPK)2, (GTPK)3', (3')6', (3')7', (6')12).
注：この例では、複数のキーが1つのキーの下で暗号化されていますが、代替ペアリングは合法です（（gtpk）2、（gtpk）3 '、（3'）6 '、（3'）7 '、（6'）12）。
We will show the format for all header data and packet (b).
すべてのヘッダーデータとパケット（b）の形式を表示します。
Rekey Event Type - 0x01 (GSAKMP`LKH)
GroupID - 0xAABBCCDD
0x12345678
Time/Date Stamp - YYYYMMDDHHMMSSZ
Rekey Event Type - 0x01 (GSAKMP`LKH)
Algorithm Vers - 0x01
# of RkyEvt Pkts - 0x0003
For Packet (b):
Packet Length - 0xLLLL
Wrapping KeyID - 0x000C
Wrapping Key Handle - 0xHHHHHHHD
# of Key Packages - 0x0003
Key Package 1:
Key Pkg Type - 0x00 (GTPK)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - KEY1
Key Handle - 0xHHHHHHH0
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Key Package 2:
Key Pkg Type - 0x01 (Rekey - LKH)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000003
Key Handle - 0xHHHHHHH3
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Key Package 3:
Key Pkg Type - 0x01 (Rekey - LKH)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000006
Key Handle - 0xHHHHHHH6
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Authors' Addresses
著者のアドレス
Hugh Harney (point-of-contact) SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
Hugh Harney（Point-of-Contact）Sparta、Inc。7110 Samuel Morse Drive Columbia、MD 21046
Phone: (443) 430-8032 Fax: (443) 430-8181 EMail: hh@sparta.com
電話：（443）430-8032ファックス：（443）430-8181メール：hh@sparta.com
Uri Meth SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
Uri Meth Sparta、Inc。7110 Samuel Morse Drive Columbia、MD 21046
Phone: (443) 430-8058 Fax: (443) 430-8207 EMail: umeth@sparta.com
電話：（443）430-8058ファックス：（443）430-8207メール：umeth@sparta.com
Andrea Colegrove SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
Andrea Colegrove Sparta、Inc。7110 Samuel Morse Drive Columbia、MD 21046
Phone: (443) 430-8014 Fax: (443) 430-8163 EMail: acc@sparta.com
電話：（443）430-8014ファックス：（443）430-8163メール：acc@sparta.com
George Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833
George Gross Identaware Security 82 Old Mountain Road Lebanon、NJ 08833
Phone: (908) 268-1629 EMail: gmgross@identaware.com
電話：（908）268-1629メール：gmgross@identaware.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。