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
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).
著作権（C）インターネット協会（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.
この文書では、グループセキュア協会鍵管理プロトコル（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.
1）グループ所有者、2）グループコントローラキーサーバ、および3）グループメンバー：GSAKMPは、三つの主要な役割にグループセキュリティ管理機能と責任を分離します。グループ所有者はグループのセキュリティポリシールールを作成し、ポリシーのトークンでこれらを表現するための責任があります。グループコントローラキーサーバー（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
- GC / KS SAの確立にGMのデータを保護するために、
- 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アクションの委任を許可必要。完全に指定されたポリシーのトークンは、この承認を容易にするための仕組みです。全ての接合のGMにこのポリシートークンの送信は、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].
要件用語：キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "SHOULD NOT" と[RFC2119]で説明したように解釈されるべきであり、この文書に表示される "MAY"。
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.
妥協回復：グループメンバーが信頼できないことを検出した後、安全な運転状態を回復する行為。これは、再入力することによって達成することができます。
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）：グループメンバーはグループキーにアクセスできる任意のエンティティです。かかわらず、メンバーがグループの一部になるかのグループが構造化の方法について、GMが次のアクションを実行します。
- Authenticate and validate the identities and the authorizations of entities performing security-relevant actions
- 認証とアイデンティティとセキュリティ関連のアクションを実行するエンティティの権限を検証
- Accept group keys from the GC/KS
- GC /カンザスからグループ鍵を受け入れます
- 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.
グループセキュア協会（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 Array: The construct that contains all the rekey information for a particular member.
特定のメンバーのためにすべてのキー更新情報が含まれています構造：配列をキーの再生成。
Rekey Key: The KEK used to encrypt keys for a subset of the group.
主キーの再生成：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.
ラッピング鍵ID：キーパッケージをラップするために使用されるキーのキー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.
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.
前記メッセージ処理部で説明したように、署名とともに鮮度のために使用されるノンス値を使用することは、攻撃をリプレイ箔に使用されるメカニズムです。ナンスの使用において、コア要件は、攻撃者の観点からはノンスの予測不可能です。ナンスの有用性は、古いナンスを再利用したりナンス値を予測するために、どちらかの攻撃の無力に依存しています。
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.
グループのGO力終了の9妥協。 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].
ISAKMP [RFC2408]とFIPSパブ196 [FIPS196]：GSAKMPは、2つ（2）既存のプロトコルから派生します。セキュリティスイート1に従い、GSAKMP実装は、二大政党のキーを作成するためのDiffie-Hellman鍵交換の[DH77]の使用をサポートしなければならないと再入力機能のための論理キー階層（LKH）[RFC2627]を使用するかもしれません。 [HHMCD01]、[RFC2093]、[RFC2094]、[BMS]、および[RFC2412]：GSAKMPの設計は、以下のプロトコルによって影響を受けました。
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パブ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は妥協[RFC2627]の後群の回復を可能にするために再入力機能（即ち、LKH）に依存します。多くの場合、妥協のグループを破壊し、安全なグループを再構築した方が良いかもしれないのでこれはオプションです。
A Group may rely upon two-party key creation mechanisms, i.e., Diffie-Hellman, to protect sensitive data during download.
当社グループは、ダウンロード中に機密データを保護するために、2つのパーティの鍵作成メカニズム、すなわち、ディフィー・ヘルマン、に依存していることがあります。
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.
このプロトコルは、既に同様の問題を介して働いており、GSAKMPは、その目的のために同じセキュリティ上の考慮事項を使用しているように、このセクションの情報は、[のIKEv2]から重く借り。このセクションでは、適宜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.
ディフィー・ヘルマン値自体にこれらの制限があることに注意してください。強い値を使用禁止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、「：DoSからの保護の持つグループ設立クッキー」で配布された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はまた、GMのこの再入力情報の可用性を高めるための機能を備えていなければなりません。リキーメッセージを受信のGMの必要性がリキーメッセージの受信の可能性を高めるための方法を使用する必要があります。これらのメソッドは、オプションのキーの再生成機能をサポートするなど対応GSAKMP実装はリキーメッセージの再送信をサポートしなければならない、掲示板上リキーメッセージの投稿、リキーメッセージの複数の送信を含むかもしれません。
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方針トークンが発行され、GOによって署名されています。 GC / KSは、彼らが方針トークンのルールを満たしている場合にのみ、それを検証し、GMのへのアクセスを許可します。新規のGM）が1つだけあればトークンを検証し、アクセスを受け入れる、2）GC /カンザスは、許可ディセミネータであり、3）グループメカニズムは、GMのデータを保護するために許容可能です。
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:
信頼モデルは、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信頼モデルの目標は、グループのための共通の信頼できるポリシー作成機関からの信頼を得ることです。 GSAKMPによって実装されているすべてのセキュリティ関連の決定および行動は、最終的にトレーサブル、信頼ポリシーの作成機関によって検証された情報に基づいています。 GO（ポリシー作成の権限）と私たちはGOを確認することができますPKIルート：2つの信頼さGSAKMPのためのポリシー作成当局があります。
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は、いくつかの機能を実行するために許可されています。
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 /カンザスはグループ用のキーセットを作成します。これらのキーは、グループトラフィック保護キー（GTPKs）と第1層の再入力キーを含んでいます。分散リキー管理構造は、グループのために必要とされる場合には、第2層の再入力木が存在してもよいです。
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.
グループリキー機関として、グループのGTPKを変更するためにリキーを行います。 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 /カンザスはグループメンバーシップ（登録、立ち退き、登録解除など）を管理することができます。これはオプションのアプローチとして、そのような論理鍵階層（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は、1以外GC / KSのすべての権限を持っています：それは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は/ KS GCにメンバーとして登録する必要があり、そのプロセスの間にそれは権限を確認するために持っています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で指定されるように/ KSまたはS-GC / KSは、登録プロセスに従事するGCは、許可されていることを確認します。再入力して、新しいの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グループのSecurity Associationマルチキャストスピーカー構成のいずれかを持つことができません。
- 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つのマルチキャストアプリケーションSAがあります。 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はグループのスピーカーであることをのGMのすべてを許可します。 GOはこれらのスピーカーの支援に1マルチキャストアプリケーションSAを割り当てます。 PTは、このマルチキャストアプリケーションSAを初期化し、任意のGMは、スピーカとすることができることを示しています。 GMのすべてが単一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は、（すべてのGMからなるサブセットであり得る）基スピーカーであることの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.
セキュリティポリシールールは関連性があるとされている場合は、検証メカニズムと結合されなければなりません。ここでのコア原則は、1つのセキュリティポリシーを買う余裕ができ、信頼のレベルは1がそのポリシーを証明するために使用検証メカニズムであり、信頼のレベルに正確に等しいということです。すべてのIETFの参加者がで許可されている場合たとえば、その後、彼らは会議にチェックインの際、その証明書から自分のアイデンティティを登録することができます。その証明書は、IETF出席者として誰かを特定するために許可されている信頼できるポリシーの作成権限（PKIルート）によって発行されます。 GOは、信頼のPKIから発行されたID証明書に基づいて、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の使用を可能にします。これはGOは、独自の認証局の公開鍵証明書を使用して、それぞれを複数の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信頼モデルの重要な側面は、セキュリティ関連のアクションの承認です。これらは、グループキーのダウンロード、リキー、および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動作の別の態様は、ローカル管理当局の有効化です。非常に大規模なグループでは、下位の飛び地が原因グループメンバーの直接の知識に、飛び地のグループメンバーシップのローカル管理を提供するために最も適していることがあります。
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.
分散操作にかかわる重要な問題の一つは、セキュリティインフラストラクチャ位置とセキュリティスイートの発見です。ダイナミックな相互作用を持っている多くのグループアプリケーションが動作するためにお互いを「検索」しなければなりません。セキュリティインフラストラクチャの発見を確実に動作させるためにグループによって知られなければならない情報のちょうど別の部分です。
There are several methods for infrastructure discovery:
インフラストラクチャの検出のためのいくつかの方法があります。
- Announcements
- お知らせ
- 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.
セキュリティインフラストラクチャの場所を配布するための一つの方法は、アナウンスメントを使用することです。 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.
セキュリティインフラストラクチャとインフラストラクチャの検出のためのERSesの拡張リング検索（ERSes）：お知らせは、2つのモードのいずれかでGSAKMPによって使用することができます。いずれの場合も、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で動作します。この発表は、旅行をするだろうホップ数は、ローカルに設定された番号になります。 GMが関心のグループのためのサービスを提供GC / KSESのためのよく知られたマルチキャストアドレスに聞くでしょう。複数のGC / KSESがサービスを提供することが判明している場合、GMは（マルチキャストホップの点で）最も近いものを選ぶだろう。 GMは、その後発表されたGC / KSにメッセージ（RTJ）に参加するGSAKMPリクエストを送信します。発表は偽りであることが判明した場合、そのは、適切な管理当局に報告されます。それは、データチャネルのマルチキャストアドレス上で発生する可能性があるという点で、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.
拡張リング検索はERAの逆の順序で動作します。この場合、GMは発表実体です。 （S-）GC / KSESは、サービスに対する要求は、具体的にRTJを聞きます。 （S-）GC /カンザスは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.
エニーキャストはERSと非常によく似ているサービスです。また、セキュリティインフラストラクチャへの接続を提供するために使用することができます。この場合、GMは、よく知られたサービス要求のアドレスにRTJを送るでしょう。このエニーキャストサービスは、適切なGC / KSへのルートRTJをでしょう。エニーキャストサービスは、この接続を容易にするために、セキュリティインフラストラクチャとネットワーク接続性の知識を持っているでしょう。
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 / KSESの登録は、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は、グループポリシーの作成権限を持つものとして認識GOがあります。すべての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.
- リキー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.
- GOへのPTのソース認証：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は、信頼できるGOから来ていることを確認するために、PTにGO署名を検証します。次に、GC / KSは、PTでの認可規則に基づいて、GC / KS、になることを許可されていることを確認します。 GC / KSはPTを信頼すると仮定すると、GC / KSことを許可され、局所的に与えられたグループのためのGC / KSとGOになるように構成され、次いで、GC / KSの起動に必要なキーを作成しますグループ。 GC /カンザスはグループのために鍵を配布する能力を宣伝するために（もしあれば）必要がある処理を行ないます。 GC /カンザスは、RTJsをリッスンします。
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.
潜在的なGMが、いくつかのメカニズムを介して、新たなグループの通知を受け取ります：発表、エニーキャスト、または登録ルックアップを。 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環境とローカル構成に応じて、クッキーを必要としない場合があります。
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 /カンザスは、それが主張する識別情報によって送信された保証するためにRTJの署名を検証します。チェックが成功した場合、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は、グループで使用されるメカニズムは（GMを仮定すると、データ・ソースである）のGMSデータの保護のために利用可能および許容可能であることを確認します。 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 /カンザスになるための権限を割り当てる必要があります。
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はS-GC / KSにサブグループのメンバーシップの管理責任プライマリ-GC / KS委譲そのため、主に自己完結型のサブグループを運営しています。一般的には、S-GC / KSは、ローカルプライマリ-GC / KSとの対話せずに、各グループメンバーの登録と登録解除を処理します。定期的に、プライマリ-GC / KSマルチキャストリキーイベントメッセージは、その一つ以上のS-GC / KS宛。
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
S-GC / KSが正常プライマリ-GC / KSからリキーイベントメッセージを処理した後、S-GC / KSは、そのサブグループ独自リキーに送信します
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.
グループの新しいGTPKと政策トークンのコピーを含むイベントメッセージ。 S-GC / KSは、そのキーの再生成イベントメッセージの論理キー階層を使用して、サブグループ鍵管理情報または同等のキーの再生成プロトコルを暗号化します。 S-GCは/ KSのみ許可サブグループのメンバーは、復号化し、新しいGTPKとポリシートークンへのアクセスを取得することができるように、前後秘密実現する再入力プロトコルを使用します。プライマリ-GC / KSはリキーイベントメッセージを送信する頻度は、ポリシートークンパラメータです。
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 /カンザスは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は、（RTJ）メッセージへの参加要求を送信するために潜在的なS-GC / KSを待ちます。
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 /カンザスは、グループの登録サービスを提供します。 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 /カンザスにRTJを送信します。 PTで定義されているS-GC / KSは、全体のアクセス制御ポリシーを施行します。 GMは、S-GC / KSのLKH木に対応するLKHキー配列を受け取ります。 S-GC /カンザスによって生成されたキーツリーは、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つのことを行います。まず、メンバーを同定GC / KSとS-GC / KSを開始A登録解除交換が排出されます。 （S-GC / KSプロキシグループメンバーの登録解除は、グループメンバーがグループから追放されたことをGC / KSを知らせる。）第二に、S-GC /カンザスはGC / KSにより、キーの再生成アクションを待ちます。 GC / KSによってリキー行為の即時性は、GC /カンザスでの経営判断です。セキュリティは、最高の信頼できないメンバーの迅速な追放で提供しています。
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 /カンザスは、追放されるメンバーを登録します。 GC / KSは、次に（このプロトコルの範囲外）再入力アクションを開始するためのグループの手順に従います。 GC / KS（このプロトコルの範囲外）GOに排出会員情報を通信します。この情報を使用して、GOはグループのアクセス制御ルールで除外リストに追加追放GMのアイデンティティを持つグループの新しいPTを作成します。 GOはリキーイベントメッセージで配布用GC / KSにこの新しいPTを提供します。
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を再入力操作を送信します。 S-GC / KSはリキーやプロセス、それを受け取ることになります。同時に、他のすべてのS-GC / KSESは再入力を受け取り、除外GMのアイデンティティに注意します。すべてのS-GC / KSESは除外GMが地元のメンバーではないことを確認するために、地元のアイデンティティを確認します。そうである場合、S-GC / KSはリキーメッセージを作成します。 S-GC / KSESは常に排出されたグループメンバーが自分のサブツリーのメンバーであるかどうか、キーの再生成メッセージを作成する必要があります。
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 /カンザスは、ローカルのrekeyメッセージを作成します。 S-GC / KSは除外メンバー（複数可）を除いて、そのローカルLKH木のすべてのメンバーに包まれたグループTPKを送信します。
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.
暗号グループの管理は、ライフサイクルを、次のとおりです。グループ定義、グループの設立、およびセキュリティ関連のグループのメンテナンスを。グループの定義は、その政策のトークンを含む安全なグループをサポートするのに必要なパラメータを、定義が含まれます。グループの設立は新しいメンバーへのアクセスを許可するプロセスです。セキュリティ関連のグループメンテナンスメッセージを再入力、ポリシーの変更、メンバーの削除、およびグループの破壊が含まれます。これらのライフサイクルの各フェーズは、次のセクションで説明します。
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.
参加要求、キーをダウンロードし、キーダウンロードのAck /失敗：GSAKMPグループ設立は3実装に必須のメッセージで構成されています。エラーへの参加を要求してLack_of_Ackメッセージ：交換は2つのオプションのエラーメッセージを含むこともできます。エラーメッセージを含めることを「冗長モード」と呼ばれているが、唯一の「簡潔モード」と呼ばれる必須のメッセージを使用して操作。 GSAKMP実装は簡潔モードをサポートしなければならないし、詳細モードをサポートするかもしれません。グループ設立は、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-）GC / KSES冗長モードをサポートしなければなりません。 GSAKMPは冗長モードグループは、詳細モードをサポートしていないのGMを持つことができます。詳細モードをサポートし、優雅にこれらのメッセージを処理する必要がありますRTJ-エラーまたは不足-の肯定応答メッセージを受信しない候補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.
サービス保護の拒否のために、クッキー取引所グループ設立交換を先行してもよいです。クッキー取引所は、セクション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のアクションを表します。図の右側には、GMのの行動を表しています。図に示した各メッセージの構成要素は、5.2.1.5を介してセクション5.2.1.1に示されています。
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.
メッセージに参加するための要求は、暗号のグループに入場を要求するために、GC / KSに電位GMから送信されます。メッセージは、鍵生成材料、鮮度データ、メカニズムの任意選択、及び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.
キーのダウンロードメッセージが参加する受け付けた要求に応じて、GMにGC / KSから送信されます。このGC / KS-署名されたメッセージは、GM、新鮮さデータ、キー作成材料、暗号化キー、暗号化されたポリシートークンの識別子が含まれています。ポリシートークンが十分に順序付けされたグループの作成を容易にするために使用され、グループの識別を含まなければなりません、グループ許可、グループポリシー、グループコントローラ鍵サーバのID、グループ管理情報、および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.
エラーメッセージへの参加を要求が参加する未承認の要求に応じてGMにGC / KSから送信されます。このメッセージは、二つの理由のためにGC / KSによって署名されていない：1）、GMは、この時点で、GC / KSとして作用することを許可されている人の知識を持たない、したがって署名は、このようにGMに意味がありません及び2）参加拒否された要求への署名応答は、サービス提供能力の否定を提供します。メッセージは、エラー状態の表示を含みます。このエラー条件の可能な値は次のとおりです。無効なペイロード・タイプ、無効-バージョン、無効なグループID、無効な-シーケンス-ID、ペイロード・不正な形式、無効-ID-情報、無効な証明書、証明書タイプ、サポートされていません、および禁止・バイ・ローカルで設定・ポリシー・バイ・グループポリシーの禁止、無効-CERT-権限、認証失敗、証明書利用不可、不正なリクエスト、。
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.
Lack_of_Ackメッセージが無効または不在キーダウンロードのAck /失敗メッセージに応じて、GMにGC / KSから送信されます。署名されたメッセージは、新鮮さとステータスのデータが含まれており、有効なキーダウンロードのAck /失敗が送信されない場合はグループから差し迫った立ち退きのGMを警告するために使用されます。追い出しは、メンバーが次のリキーイベントの後にグループから除外されることを意味します。特定のグループは、それ自体をリキーする必要があるときのポリシーは、ポリシートークンに記載されています。立ち退きは、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]
メッセージ名：{HDR-GRPID、鍵生成、Nonce_I、[ベンダーID]：[Notif_Mechanism_Choices]、[Notif_Cookie]、[Notif_IPValue]} SIGM、[証明書]ペイロードタイプ（RTJ）解剖に参加するための要求GSAKMPヘッダー、鍵の作成、[ナンス]、[ベンダーID]、署名、[証明書]、[通知]
SigM : Signature of Group Member Cert : Necessary Certificates, zero or more {}SigX : Indicates fields used in Signature [] : Indicate an optional data item
SIGM：グループメンバ証明書の署名：必要な証明書、ゼロ又はSigX} {もっと：オプションのデータ項目を指定：[]署名に使用されるフィールドを示し
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_I値は、潜在的な後の使用のために保存しなければなりません。 GC / KSは、このグループのポリシートークンは、同期時間に対する一回だけの使用を定義する場合にのみ、この供給されたnonceを使用します。タイプメカニズムの選択のオプション通知ペイロードは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 /カンザスはローカル設定に基づいて、要求を受け入れるか拒否します。 <プロセス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は、メッセージヘッダが適切に形成されていることを確認し、このメッセージは、グループIDの値をチェックすることによって、このグループのためのものであることを確認しなければなりません。ヘッダチェックが合格した場合、送信者の身元は、署名ペイロードから抽出されます。このIDは、アクセス制御チェックを実行し、メッセージの検証のためのGM認証情報（例えば、証明書）を見つけるために使用されなければなりません。また、キーのダウンロードメッセージに使用しなければなりません。次に、GC /カンザスは、その信憑性を保証するために、メッセージの署名を検証します。ザ・
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が知られているルートから検証し、信頼された認証材を使用しなければなりません。メッセージの署名を検証した場合、GC /カンザスは、すべての必要なペイロードが存在し、適切に発表および/または要求されたメカニズムに基づいてフォーマットされていることを確認します。すべてのチェックに合格した場合、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は、3回にRTJメッセージを再送します。
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 /カンザスはグループごとに与えられたGMから1（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が実行されている場合、登録セッションが終了されなければならない、すべての保存された状態情報をクリアしなければなりません。
The OPTIONAL Notification payload of type Cookie is discussed in Section 5.2.2.
型クッキーのOPTIONAL通知ペイロードは、セクション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のOPTIONAL通知ペイロードは、GC / KSに特異的なIP値を伝達するためにGMのために使用することができます。
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）解剖：{HDR-GRPID、会員ID、[Nonce_R、Nonce_C]、キーの作成、（政策トークン）*、（キーのダウンロード）*、[ベンダーID]} SIGC、[証明書]ペイロードタイプ：GSAKMPヘッダー、識別、[ノンス]、キーの作成、方針トークン、キーダウンロード、[ベンダー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
SIGC：グループコントローラキーサーバ証明書の署名：必要な証明書、ゼロまたはそれ以上の{} SigXは：[]署名に使用されるフィールドを示します任意のデータ項目（データ）を示す*：暗号化された情報を表示し
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.
存在する場合、送信されたノンス値はGC / KSさんのNonce_R値およびGC / KSのNonce_R値を用いて生成されNonce_I値がRTJにGMから受信された合成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.
二大政党のキー決意を使用する場合は、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は、キーのダウンロードメッセージを処理できなければなりません。 <プロセスKeyDL>キーダウンロードメッセージが作用する方法を決定します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は、メッセージヘッダが適切に形成されていることを確認し、このメッセージは、グループIDの値をチェックすることによって、このグループのためのものであることを確認します。ヘッダチェックが合格した場合、GMはこのメッセージをその識別するための識別ペイロードに会員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.
本人確認の後、鮮度値がチェックされます。ナンスを使用する場合、GMは、結合Nonce_C値を計算し、受信したGC / KS Nonce_R値を抽出し、その保存Nonce_I値を使用して、受信したNonce_C値と比較しなければなりません。ナンスを使用していない場合、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.
新鮮さが確認された後、署名は、その信憑性を保証するために検証されなければなりません。 GMが知られているルートから検証し、信頼された認証材を使用しなければなりません。メッセージの署名を検証する場合、鍵生成材料は、KEKを生成する鍵生成ペイロードから抽出されます。このKEKは、ポリシー・トークンデータを復号化するために使用されます。ポリシートークンの署名を検証する必要があります。アクセス制御チェックは、このグループ内での権限の両方を決定するために、GO及びGC / KSの両方で実行されなければなりません。すべてのこれらのチェックに合格した後、KEKは、[キーのダウンロードペイロードからキーマテリアルを復号化して処理するために使用することができます。セクション5.2.1.4で説明したように、ACK /失敗のメッセージ - すべてが成功した場合、GMはキーのダウンロードを作成して送信します。
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.
何らかのエラーがKeyDLメッセージ処理中に発生した場合にかかわらず、GMが簡潔またはVerboseモードであるかどうか、登録セッションが終了しなければならないの、GMは、キーダウンロード送らなければなりません - のAck /失敗メッセージを、そしてすべての保存された状態情報をクリアする必要があります。簡潔モードでの場合は、通知ペイロードは終了を示すために、型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]
メッセージ名：エラーに参加するための要求（RTJ-ERR）解剖：{HDR-GRPID、[Nonce_I]、通知、[ベンダーID]}ペイロードタイプ：GSAKMPヘッダー、[ノンス]通知、[ベンダー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 /カンザスは、適切な通知ペイロードを含むエラー（RTJ-ERR）メッセージに参加するための要求を送信することができます。 RTJ-ERRメッセージは以下の理由により署名されたメッセージではないことに注意してください：有効なGC / KSだけでなく、メッセージに署名し、貴重なを使用してから、GC / KSを保護する必要が誰であるかのGMの視点での意識の欠如資源。 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.
存在する場合、Nonce_IはそれにRTJで送信Nonce_Iと一致し、ヘッダ内のGroupIDがGMがRTJを送信した先のグループに属し、そして：RTJ-ERRメッセージを受信すると、GMは、以下を検証しますグループ。上記のチェックが成功した場合、GMはそのグループIDとナンスに関連した状態を解除することができます。 GMは、時間のローカルに設定量をRTJ-ERRを受信した後、そのグループIDとノンスの有効KeyDownloadメッセージを受信することが可能であるべきです。
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
メッセージ名：主要なダウンロード - ACK /失敗（KeyDL-A / F）解剖：{HDR-GRPID、[Nonce_C]、Notif_Ack、[ベンダーID]} SIGMペイロードタイプ：GSAKMPヘッダー、[ノンス]、通知、[ベンダーID]署名SIGM：グループメンバー{} SigXの署名：署名に使用されるフィールドを示し
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は新しいRTJ続い型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のメッセージを処理できなければなりません。 <プロセス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は、メッセージヘッダが適切に形成されていることを確認し、このメッセージは、グループIDの値をチェックすることによって、このグループのためのものであることを確認します。ヘッダチェックが合格した場合、GC / KSは、新鮮さのためにメッセージをチェックしなければなりません。ナンスを使用している場合は、GC /カンザスは、その保存されたNonce_C値を使用し、受信したNonce_C値と平等のためにそれを比較しなければなりません。ナンスを使用していない場合は、GC / KSは、メッセージが新しいかどうかを決定するために署名ペイロードにタイムスタンプをチェックしなければなりません。新鮮さが確認された後、署名は、その信憑性を保証するために検証されなければなりません。 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は次のポリシー定義リキーイベントのグループからこのGMを退去しなければなりません。セクション5.2.1.5で定義された冗長モードで実行している場合はGC / KSはOPTIONAL Lack_of_Ackメッセージを送信することができます。
The exchange type for Lack of Ack is twelve (12).
肯定応答の欠如のための交換タイプは12（12）です。
The components of a Lack of Ack Message are shown in Table 5:
肯定応答メッセージの欠如の成分は、表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]
メッセージ名：{HDR-GRPID、会員ID、[Nonce_R、Nonce_C]、通知、[ベンダーID]} SIGC、[証明書]ペイロードタイプ：ACK（LOA）解離の欠如GSAKMPヘッダー、同定、[ノンス]、通知、 [ベンダー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
SIGC：グループコントローラキーサーバ証明書の署名：必要な証明書、ゼロまたはそれ以上の{} SigXは：[]署名に使用されるフィールドを示し：オプションのデータ項目を指定します
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 /カンザスのローカルタイムアウト値は、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.
同期時間が利用できない場合、ノンスペイロードは鮮度のために存在していなければなりません、そして送信ノンス値は、GC / KSさんがNonce_R値およびGC / KSのNonce_R値とNonce_I値を用いて生成された合成Nonce_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は、メッセージヘッダが適切に形成されていることを確認し、このメッセージは、グループIDの値をチェックすることによって、このグループのためのものであることを確認しなければなりません。ヘッダチェックが合格した場合、GMはこのメッセージをその識別するための識別ペイロードに会員IDとを比較することによって、それ自体のために意図されたことを確認しなければなりません。本人確認の後、鮮度値がチェックされます。ナンスを使用する場合、GMは、その受信したGC / KS Nonce_R値を抽出し、Nonce_I値を保存を使用しなければならない、合成Nonce_C値を計算し、受信したNonce_C値と比較します。ナンスを使用していない場合、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に実装することができるオプションの機能を定義します。このセクションの情報は、このプロトコルは、すでにこの問題を通じて働いており、GSAKMPはこの概念をコピーしているようでIKEv2]から大いに借ります。このセクションでは、クッキーの目的を定義するGSAKMPために修飾【のIKEv2]のセクションを言い換え含むであろう。
An optional Cookie mode is being defined for the GSAKMP to help against DoS attacks.
オプションのクッキーモードは、DoS攻撃に対して支援するGSAKMPのために定義されています。
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.
用語「クッキー」Photuris、IPSecの持つ鍵管理のための初期の提案でカーンとシンプソン[RFC2522]に由来します。 ISAKMP固定メッセージヘッダは、「クッキー」と題する2つの8オクテットフィールドを含みます。代わりに、ヘッダ内のこのクッキーデータを配置する、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に対する予想される攻撃は、ターゲットGC / KSが偽造IPアドレスからのリクエストへの参加要求が殺到している状態とCPU疲労困憊、です。 GC / KS実装が最小限のCPUを使用し、それはGMが、それはそれらを送信するために主張するからアドレスにパケットを受信できるイニシエータの可能性を知るまで通信に何の状態をコミットしていない場合は、この攻撃はあまり効果的にすることができます。彼らはタイプ「クッキー」の通知ペイロードを含んでいなければ、これを達成するために、GC / KS（クッキーモードで動作）Joinメッセージをするための最初の要求を拒否すべきです。これは、代わりにRTJへの応答として、クッキーダウンロードメッセージを送信し、タイプCookie_Requiredの通知ペイロードでクッキーを含むべきです。セクション5.2.1.1にメッセージに参加するための要求の任意通知ペイロードによって定義されるような応答を受信する可能性のGMは、型クッキーのその通知ペイロードに応答-GC / KS-供給されるクッキーのメッセージに参加するための要求を再試行しなければなりません。クッキーのダウンロードのための交換タイプは、10（10）であり、表6に示す新しいメッセージクッキーダウンロードの構成要素と、図2に示すように、この初期の交換は次になります。
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：クッキーと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]
メッセージ名：クッキーダウンロード解剖：{HDR-GRPID、Notif_COOKIE_REQUIRED、[ベンダーID]}ペイロードタイプ：GSAKMPヘッダー、通知、[ベンダーID]
The first two messages do not affect any GM or GC/KS state except for communicating the cookie.
最初の2件のメッセージがクッキーを通信するため以外の任意の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実装は、メッセージに参加するための第2の要求が到着したときに有効なクッキーを認識するために、任意の保存された状態を必要としないような方法でそのGC / KSクッキーの生成を実装する必要があります。彼らはクッキーを生成するために使用する正確なアルゴリズムと構文は、相互運用性に影響しないので、ここで指定されていません。
The following is an example of how an endpoint could use cookies to implement limited DoS protection.
以下は、エンドポイントが限定されたのDoS保護を実装するためにクッキーを使用することができる方法の一例です。
A good way to do this is to set the cookie to be:
これを行うには良い方法があることを、クッキーを設定することです：
Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>)
クッキー= <SecretVersionNumber> |ハッシュニッケル（Ni | IPI | <秘密>）
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.
<秘密>のみレスポンダGC / KSに知られており、定期的に変更され、ランダムに生成された秘密であり、Niはイニシエータ電位GMから採取されたノンス値、IPIは、候補GMのアサートされたIPアドレスです。 IPアドレスは、IPヘッダの送信元IPアドレスまたは他の任意通知「IPvalue」ペイロード（それが存在する場合）に含まれているIPアドレスのいずれかです。 <秘密>が再生成されるたびに、<SecretVersionNumber>変更する必要があります。クッキーは、「クッキー情報に参加するための要求は」到着したときに再計算し、受信したメッセージの中のクッキーと比較することができます。それが一致した場合、レスポンダーGC / KSは、すべての値が<秘密>への最後の変更以来とIPIはそれが初めて見たソースアドレスと同じでなければならないことを計算されていることを知っています。ハッシュにニッケルを組み込むことだけCookie_Downloadメッセージを見て攻撃者がメッセージ「クッキー情報に参加するための要求を」偽造することはできませんことを保証します。このニッケル値は、成功するために、計算のためのメッセージをオリジナルの「参加要求」から同じニッケル値でなければなりません。
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.
<秘密>の新しい値を選択した場合の接続が初期化される過程にある一方で、「クッキー情報に参加するための要求は、」現在のものより<SecretVersionNumber>他に返されることがあります。その場合のレスポンダーGC / KSは、新しいクッキーを持つ別の応答を送信することにより、メッセージを拒否したり、それは短い時間のために周りの<秘密>の古い値を維持し、1のいずれかから計算されたクッキーを受け入れることができます。それは、サービス保護の拒否の一部を台無しにしてしまうので、<秘密>は、変更された後、レスポンダーGC / KSは、無期限のクッキーを受け入れるべきではありません。レスポンダーGC / KSは、特に攻撃を受けた場合、頻繁に<秘密>の値を変更する必要があります。
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環境でクッキー値を生成するための代替例はIPValueがRTJメッセージで通知ペイロードで受信してIPI値を置換することです。このシナリオでは、タイプ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.
キーのダウンロード：標準グループ設立とは異なり、受信専用のシステムでは、GMのと（S-）GC / KSESは簡潔モードとだけやり取り一つのメッセージで動作します。潜在的な新しいGMがRTJを送信しません。 （S-）GC / KSESキーダウンロード期待していない - ACK /失敗のメッセージを、メッセージの不足や領収書のためのGMを削除しないでください。
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形許可アウト・オブ・バンド・イベントを介して通知されるとノンスペイロード無しで新しいメンバーの鍵ダウンロードメッセージを送信する：操作は以下の通りです。 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 /カンザスの公開コンポーネントが含まれています。会員のパブリックコンポーネントは、セキュアアウトオブバンド手段を介して取得されているものとします。
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.
リキーイベントは、新しいグループキーを作成する必要があり、および/または情報をリキー妥協レポートまたはキーの有効期限、などの任意のアクションです。
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は、その信憑性を保証するために、メッセージの署名を検証しなければなりません。メッセージの署名が検証されない場合は、メッセージを捨てなければなりません。検証の際に、GMは、適切なキー更新のダウンロードパケットを見つけるだろうし、保存された再入力キー（複数可）との情報を復号化します。新しいポリシートークンをメッセージと一緒に配布されている場合、それは古いGTPKで暗号化されなければなりません。
The exchange type for Rekey Event is five (5).
リキーイベントのための交換タイプは5（5）です。
The components of a Rekey Event message are shown in Table 7:
リキーイベントメッセージの構成要素は、表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],
メッセージ名：リキーイベント解剖：{HDR-GRPID、（[ポリシートークン]）*、リキーアレイ、[ベンダーID]} SIGC、[証明書]ペイロードタイプ：GSAKMPヘッダー、[ポリシートークン]、リキーイベント、[ベンダー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
SIGC：グループコントローラキーサーバ証明書の署名：必要な証明書、ゼロまたはそれ以上の{} SigXは：*署名に使用されるフィールド（データ）を示しは：[]暗号化された情報を示し：オプションのデータ項目を指定します
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).
新しいポリシートークンは鍵更新イベントメッセージを介して送信されます。これらのポリシーの更新は、既存のキーの再生成イベントと結合されてもよいし、（セクション7.5.1を参照）該当なし（0）に設定リキーイベントペイロードのリキーイベントタイプのメッセージで送信されてもよいです。
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.
それを運ぶリキーイベントメッセージの処理が失敗した場合の政策トークンが処理されてはなりません。ポリシートークンの処理は種類に依存し、この文書の範囲を超えています。
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.
グループの破壊もリキーイベントメッセージを介して達成されます。グループ破壊のリキーイベントメッセージに、シーケンスIDは0xFFFFFFFFに設定されています。この認証リキーイベントメッセージを受信すると、グループの構成要素は、示された基に関連する情報の処理を終了しなければなりません。
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で詳しく説明されているリキーイベント、で達成されます。グループへの将来のアクセスを拒否することもあれば、メンバーが拒否されたアクセス制御リストに追加する必要があり、それらは追放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.
グループのメンバーシップは、コストや出発メンバーに責任を課す場合は、そのメンバーが去ることを希望する場合、そのメンバーがグループから登録解除すべきです。 Request_to_Depart、Departure_Response、及びDeparture_Ack：登録解除は、GMと会員のGC / KSの間に3つのメッセージ交換から成ります。 GMのための準拠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メッセージを送信しなければならない登録解除プロセスを開始することを望みます。グループを離脱する要望のGC / KS識別および通知：RTDメッセージの解剖で定義されているように、このメッセージは、以下の情報を保持するペイロードを含まなければなりません。
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）解剖：{HDR-GRPID、GC / KS_ID、[Nonce_I]、Notif_Leave_Group、[ベンダーID]} SIGM、[証明書]ペイロードタイプ：GSAKMPヘッダー、同定、[ノンス]、通知、[ベンダーID ]、署名、[証明書]
SigM : Signature of Group Member Cert : Necessary Certificates, zero or more {}SigX : Indicates fields used in Signature [] : Indicate an optional data item
SIGM：グループメンバ証明書の署名：必要な証明書、ゼロ又はSigX} {もっと：オプションのデータ項目を指定：[]署名に使用されるフィールドを示し
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は、メッセージヘッダが適切に形成されていることを確認し、このメッセージは、グループIDの値をチェックすることによって、このグループのためのものであることを確認しなければなりません。ヘッダチェックが合格した場合、識別ペイロードにおけるその後の識別子の値が、それ自身と比較され、GC / KSのアイデンティティは、GMはこのGC / KS、グループにこのメンバーを登録GC / KSと会話することを意図していることを確認します。次に、送信者の身元は、署名ペイロードから抽出されます。このIDは、このGMはこのGC / KSによってサービスグループのメンバーであることを確認するために使用されなければなりません。そして、GC / KSはGMがグループを残すように要求していることを通知ペイロードから確認します。その後、GC /カンザスは、その信憑性を保証するために、メッセージの署名を検証します。 GC / KSが知られているルートから検証し、信頼された認証材を使用しなければなりません。すべてのチェックに合格し、メッセージが正常に処理されている場合、セクション5.3.2.3.2で定義されるように、その後、GC / KSはDeparture_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は簡潔モードで動作している場合は、エラー・メッセージがGMに送信されません。 GC / KSを冗長モードで動作している場合、その後、GCは/ KSは、タイプRequest_to_Depart_Errorの通知ペイロードを持つDeparture_Responseメッセージを送信します。
The Exchange Type for a Departure_Response Message is fourteen (14). The components of a Departure_Response Message are shown in Table 9.
Departure_Responseメッセージの交換タイプは14（14）です。 Departure_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：Departure_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]
メッセージ名：Departure_Response（DR）解剖：{HDR-GRPID、MEMBER_ID、[Nonce_R、Nonce_C]、通知、[ベンダーID]} SIGC、[証明書]ペイロードタイプ：GSAKMPヘッダー、同定、[ノンス]、通知、[ベンダーID ]、署名、[証明書]
SigC : Signature of Group Member Cert : Necessary Certificates, zero or more {}SigX : Indicates fields used in Signature [] : Indicate an optional data item
SIGC：グループメンバ証明書の署名：必要な証明書、ゼロ又はSigX} {もっと：オプションのデータ項目を指定：[]署名に使用されるフィールドを示し
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.
存在する場合、送信されたノンス値はGC / KSさんのNonce_R値およびGC / KSのNonce_R値を用いて生成されNonce_I値がRTDでGMから受信された合成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はDeparture_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
GMは、メッセージヘッダが適切に形成されていることを確認し、このメッセージは、グループIDの値をチェックすることによって、このグループのためのものであることを確認しなければなりません。ヘッダチェックが合格した場合、GMはこのメッセージをその識別するための識別ペイロードに会員IDとを比較することによって、それ自体のために意図されたことを確認しなければなりません。本人確認の後、鮮度値がチェックされます。ナンスを使用する場合、GMは、結合Nonce_C値を計算し、受信したGC / KS Nonce_R値を抽出し、その保存Nonce_I値を使用して、受信したNonce_C値と等しいかどうかを比較しなければなりません。ナンスを使用していない場合、GMは、メッセージが新しいかどうかを判断するために、署名ペイロードにタイムスタンプをチェックしなければなりません。新鮮さが確認された後、DRメッセージの署名者の身元の確認は、GMが許可されています
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.
GC / KSが行われます。次いで、署名は、その信憑性を保証するために検証されなければなりません。 GMが知られているルートから検証し、信頼された認証材を使用しなければなりません。メッセージの署名を検証する場合、GMは通知タイプDeparture_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.
処理が成功し、そして通知ペイロードタイプDeparture_Acceptedである場合、セクション5.3.2.3.3で定義されるように、部材はDeparture_ACKメッセージを形成しなければなりません。処理が成功し、通知ペイロードタイプRequest_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は簡潔モードで動作している場合は、型NACKの通知ペイロードを持つDeparture_Ackメッセージは、GC / KSに送信されます。 GMを冗長モードで動作している場合、GMは、適切な障害のタイプの通知ペイロードを持つDeparture_Ackメッセージを送信します。
The Exchange Type for a Departure_ACK Message is fifteen (15). The components of the Departure_ACK Message are shown in Table 10:
Departure_ACKメッセージの交換タイプは15（15）です。 Departure_ACKメッセージの成分は表10に示します。
Table 10: Departure_ACK (DA) Message Definition
表10：Departure_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
メッセージ名：Departure_ACK（DA）解剖：{HDR-GRPID、[Nonce_C]、Notif_Ack、[ベンダーID]} SIGMペイロードタイプ：GSAKMPヘッダー、[ノンス]、通知、[ベンダーID]、署名SIGM：グループメンバー{の署名} SigX：署名に使用されるフィールドを示し
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.
適切に処理Departure_Responseメッセージに応答して、GMは、作成およびDeparture_ACKメッセージを送らなければなりません。メッセージの解剖で定義されているように、このメッセージは、以下の情報を保持するペイロードを含まなければなりません：タイプ肯定応答（ACK）および署名情報の通知ペイロードを。同期時間が使用できない場合は、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.
Departure_ACKを受信すると、GC /カンザスは、以下のチェックを実行しなければなりません。これらのチェックは、提示された順序で実行する必要があります。
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は、メッセージヘッダが適切に形成されていることを確認し、このメッセージは、グループIDの値をチェックすることによって、このグループのためのものであることを確認しなければなりません。ヘッダチェックが合格した場合、GC / KSは、新鮮さのためにメッセージをチェックしなければなりません。ナンスを使用している場合は、GC /カンザスは、その保存されたNonce_C値を使用し、受信したNonce_C値と比較しなければなりません。ナンスを使用していない場合は、GC / KSは、メッセージが新しいかどうかを決定するために、署名ペイロードにタイムスタンプをチェックしなければなりません。新鮮さが確認された後、署名は、その信憑性を保証するために検証されなければなりません。 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 /カンザスはグループからメンバーを削除する必要があります。これは、グループのためのキーの再生成イベントを開始することを含むことができます。
If the processing of the message fails or if no Departure_Ack is received, the GC/KS MAY issue a LOA message.
メッセージの処理が失敗した場合、または全くDeparture_Ackが受信されない場合は、GC /カンザスは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.
すべての潜在的なGMがグループに参加するために、正しいセキュリティスイートを使用するには、それらに利用可能な十分な情報を持っています。これは、よく知られているデフォルトのスイート、「セキュリティスイート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のオークリーグループ2定義とオークリー自体から大いに借ります。
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交換の際に渡される）を経由して、グループの所有者によって設定されています。
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ハッシュアルゴリズムである：SHA-1
Nonce Hash algorithm is: SHA-1
ノンスハッシュアルゴリズムは次のようになります。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"
鍵生成定義は：アルゴリズムタイプのDiffie HellmanのMODPグループ定義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"
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、「第二オークリーグループ」から来る、そして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ペイロード続いGSAKMPヘッダー（セクション7.1）から構成されています。全てGSAKMPのペイロードはジェネリックペイロードヘッダー（セクション7.2）から構成されている特定のペイロードデータが続きます。メッセージは、その後続のペイロードを定義する先行ペイロードによって連鎖されます。ペイロードは、すべての必要なペイロードが存在することを条件とする、第5のメッセージ解剖に示される正確な順序である必要はありません。それは明示的に単一タイプの複数のペイロードが、存在し得る解剖に記載されない限りメッセージで許可されて各タイプの複数のペイロードが現れなくてもよいです。メッセージの最後のペイロードがない後続ペイロードを指します。
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
セクション7.1.1.1.1で定義された予約済み0 UTF-8 1フォーマット。オクテット文字列2は、このタイプを実装する必要があります。セクション7.1.1.1.2で定義されたフォーマット。 IPv4の3フォーマットは、セクション7.1.1.1.3で定義されています。 IPv6の4フォーマットは、セクション7.1.1.1.4で定義されています。 192私用193 - - 255 IANA 5に予約済み
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.
グループ識別値（可変長） - グループの名前/タイトルを示します。すべてのグループIDの種類は、グループ全体でユニークなネーミングを提供する必要があります。グループIDのタイプは、少なくとも8個のオクテットのグループの作成者（所有者）によって生成されたランダム要素を含むグループ名に衝突の非常に低い確率を提供することによってこの機能を提供すべきです。グループID値は、グループの一生静的です。
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
255 - IANA 13なし0ポリシートークン1主ダウンロードパケット2リキーイベント3身分4予約5証明6予約7シグネチャー8通知9ベンダーID 10鍵生成11ノンス12予約 - 192私用193
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つのオクテット） - 使用中の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.
交換タイプ（1つのオクテット） - （また、メッセージタイプとも呼ばれる）の交換のタイプを示します。表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
3キーをダウンロードACK /失敗4リキーイベント5予約6 - - IANA 16に予約13出発応答14出発のAck 15を出発するのAck 12リクエストのエラー11欠如に参加する10の要求をダウンロード8キーダウンロード9クッキーに参加するための7の要求を0に予約 - 192私用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）に設定しなければなりません。 （S-）GC /カンザスによって使用される最初の値は1（1）でなければなりません。この（S-）GC / KS送信は、この値を1インクリメントしなければならない各異なるグループ管理メッセージ（1）。このグループ管理メッセージの受信機は、受信された値は、IDが、この（S-）GC /カンザスからの最後のグループ管理メッセージで受信したシーケンスの値より大きいことを確認しなければなりません。グループ構成要素（例えば、GMは、S-GC / KSES）は0xFFFFFFFFのシーケンス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.
このセクションでは、定義されたグループIDの種類のためのフォーマットを定義します。
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：グループID 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グループIDタイプの場合、ランダムな値は、ネットワークバイト順でそのオクテット値から変換された正確に16桁の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文字列（可変長） - このフィールドはUTF-8形式でグループIDの人間が読み取り可能な部分を含みます。ランダム値フィールドの - その長さは（16グループIDの長さ）として算出されます。このフィールドの最小長さは、一（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：グループIDオクテット文字列フォーマット
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
ランダムな値（8つのオクテット） - ネットワークバイト順形式の8オクテット符号なしのランダム値。
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.
オクテット文字列（可変長） - このフィールドは、グループIDのオクテット文字列部分を含みます。ランダム値フィールドの - その長さは、（8グループIDの長さ）として算出されます。このフィールドの最小長さは、一（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：グループIDのIPv4フォーマット
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
ランダムな値（8つのオクテット） - ネットワークバイト順形式の8オクテット符号なしのランダム値。
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：グループIDのIPv6フォーマット
Random Value (8 octets) - The 8-octet unsigned random value in network byte order format.
ランダムな値（8つのオクテット） - ネットワークバイト順形式の8オクテット符号なしのランダム値。
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タイプ - 表11により定義される値が有効でない場合、グループIDタイプ値は、エラーが記録され、有効なグループ識別ペイロードタイプであることをチェックしなければなりません。冗長モードであれば、通知値ペイロード不正を含む適切なメッセージが送信されます。
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.グループID - 受信したメッセージのグループIDは、グループコンポーネントの有効GroupIDsに対してチェックしなければなりません。一致が見つからない場合、エラーが記録されます。冗長モードであれば加えて、適切なメッセージを含む通知値無効なグループ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（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）でなければなりません。グループ管理メッセージの場合、この値はIDが、この（S-）GC / KSから受信した最後のシーケンスよりも大きくなければなりません。グループ管理メッセージに不正なシーケンス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 /カンザスはリキーメッセージのこのグループでの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.
一つの可能な解決策は、複数のキーの再生成メッセージを送信する（S-）GC / KS、それがサポートしているバージョンレベルあたり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より大きいバージョン値を有するGSAKMPメッセージを受信した場合（1）、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.
RESERVED（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. RESERVED - このフィールドには、（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.
RESERVED（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
0 GSAKMP_ASN.1_PT_V1 1予約GSAKMPのすべての実装は、このPTのフォーマットをサポートしなければなりません。 [RFC4534]で指定された形式。 IANA 2に予約済み - 49152自家用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 Typeフィールドによって指定されます。
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（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.次のペイロード、RESERVED、ペイロード長 - セクション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.
RESERVED（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つのオクテット） - グループトラフィック保護キーの合計数が含まれており、リキー配列は、このデータ・ブロックに渡されます。このフィールドは、ネットワークバイト順形式の符号なし整数として扱われます。
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.
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.
キーのダウンロードデータ項目（可変長）のためのデータ - キーと関連情報が含まれています。このフィールドの形式は、キーのダウンロードデータ項目のTypeフィールドの値に応じて固有のものです。セクション7.4.1.1で定義されているGTPKのKDDアイテムタイプの場合、このフィールドはキーデータムが含まれています。 KDDアイテムタイプのリキーについて - セクション7.4.1.2で定義されているようLKH、このフィールドはリキー配列が含まれています。
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
GTPK 0このタイプを実装する必要があります。このタイプは、データがグループトラフィック保護キー情報が含まれていることを識別します。キーの再生成 - IANA 2にLKH 1オプション予約 - 192私用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つ（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
2 3DES_CBC64_192 3参照[RFC2451] - 0予約。 4予約 - 11 AES_CBC_128 12このタイプはサポートされなければなりません。 [IKEv2の]を参照してください。 AES_CTR 13は[IKEv2の]を参照してください。 65535から49152自家用49153 - IANA 14に予約済み
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オクテット） - これは、このキーのデータが最初に生成されたときの時間値です。このフィールドは、YYYYは年UTF-8形式のYYYYMMDDHHMMSSZ、（0000から9999）のタイムスタンプが含まれ、MMは月（01から12）の数値であり、DDは月（01から31）の日です、 HHは日（00から23）の時間で、MMは、時間内（00から59）分で、SSは分以内秒（00から59）、および文字Zが、これはズールー族の時間であることを示しています。この形式は緩く[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オクテット） - これは、このキーは使用するため、もはや有効であるときの時間値です。このフィールドは、YYYYは年UTF-8形式のYYYYMMDDHHMMSSZ、（0000から9999）のタイムスタンプが含まれ、MMは月（01から12）の数値であり、DDは月（01から31）の日です、 HHは日（00から23）の時間で、MMは、時間内（00から59）分で、SSは分以内秒（00から59）、および文字Zが、これはズールー族の時間であることを示しています。この形式は緩く[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.
リキーアレイは、グループメンバーに関連付けられているの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 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.
バージョン（1つのオクテット）リキー - データがフォーマットされている再入力プロトコルのバージョンが含まれています。リキーの主要なダウンロードデータ項目タイプの - 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つのオクテット） - これは、この再入力配列に含まれる再入力シーケンスの会員IDです。このフィールドは、オクテット文字列として扱われます。リキーの主要なダウンロードデータ項目タイプの - 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鍵の数（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（リキー内のキー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.次のペイロード、RESERVED、ペイロード長 - セクション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.
リキーイベントペイロードは、ラッピングのKEKで暗号化された複数のキーを含むかもしれません。図14は、ペイロードのフォーマットを示します。データはリキーイベントペイロード内に含まれる場合はペイロードの大きすぎる、シーケンスはリキーイベントデータの境界で複数のリキーイベントペイロードにまたがって分割することができます。
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：リキーイベントペイロードフォーマット
The Rekey Event 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.
RESERVED（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.
イベントの種類（1オクテット）をリキー - 使用されているリキーイベントのタイプを指定します。表17は、キーの再生成イベントのタイプを提示します。このフィールドは、符号なしの値として扱われます。
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".
リキーイベントヘッダー（可変長） - これは、鍵更新イベントのヘッダ情報です。このための書式は、セクション7.5.1.1、「リキーイベントヘッダー構造」に定義されています。
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".
リキーイベントデータ（S）（可変長） - これは、鍵更新イベントの再入力情報です。このための書式は、セクション7.5.1.2、「リキーイベントデータ構造」に定義されています。
The Rekey Event payload type is three (3).
リキーイベントペイロードタイプは3である（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
なし0このタイプは実装されてはなりません。この場合、リキーイベントデータフィールドのサイズはゼロバイト長になります。なし鍵更新情報を新しいトークンを送信する必要があるときに型なしでリキーイベントペイロードの目的です。 GSAKMPはMSGをリキーリキーイベントペイロードを必要とし、この場合には、タイプなしの再入力データを持っているでしょう。 GSAKMP_LKH 1リキーデータはGSAKMPに従ってフォーマット型LKHであろう。このフィールドの形式は、セクション7.5.1.2で定義されています。 192私用193 - - 255 IANA 2に予約済み
The format for the Rekey Event Header is shown in Figure 15.
リキーイベントヘッダーのフォーマットは図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：リキーイベントヘッダー形式
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オクテット） - これはリキーイベントデータが生成された時刻値です。このフィールドは、YYYYは年UTF-8形式のYYYYMMDDHHMMSSZ、（0000から9999）のタイムスタンプが含まれ、MMは月（01から12）の数値であり、DDは月（01から31）の日です、 HHは日（00から23）の時間で、MMは、時間内（00から59）分で、SSは分以内秒（00から59）、および文字Zが、これはズールー族の時間であることを示しています。この形式は緩く[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.
イベントの種類（1オクテット）をリキー - これは、このグループのために使用されている鍵再生成アルゴリズムです。このフィールドの値は、このフィールドは符号なしの値として扱われ、表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つのオクテット） - リキー種類のバージョンが使用されていることを示します。 GSAKMP_LKHのリキーイベントタイプについて、この値の説明については、セクション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.
リキーイベントデータ（複数可）の＃（2つのオクテット） - リキーデータに含まリキーイベントデータ（S）の数。この値は、ネットワークバイト順に符号のない整数として扱われます。
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.
リキーイベントヘッダ、リキーデータ（S）フィールド位で定義されているように、複数の情報がリキーイベントデータで送信されます。各エンドユーザは、送信されたすべての情報の中で唯一1リキーイベントデータに興味を持つだろう。各リキーイベントデータは、ユーザーが必要とするすべてのキーパッケージが含まれています。各リキーイベントデータの場合、ラッピングのフィールドを以下のデータがラッピングヘッダーで識別キーで暗号化されています。図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つのオクテット） - キーパッケージキーパッケージ（複数可）の＃で構成されていリキーイベントデータのオクテット長。この値は、ネットワークバイト順に符号のない整数として扱われます。
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.
ラッピング鍵ID（4つのオクテット） - これは新しい（リキー）鍵の暗号化/復号化のために使用されているKEKのキーIDです。リキーのリキーイベントタイプについて - 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つのオクテット）の＃ - このリキーイベントデータに含まれる主要なパッケージの数。この値は、ネットワークバイト順に符号のない整数として扱われます。
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:
リキー・イベント・ペイロードを処理するとき、次のフィールドが正しい値のためにチェックしなければなりません。
1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
1.次のペイロード、RESERVED、ペイロード長 - セクション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リキーイベントタイプフィールド - 表17で定義されているようリキーイベントの種類が有効でない場合はリキーイベントの種類は、例えば、（その後にかかわらずモードの、有効な再入力イベント型であることをチェックしなければなりません簡潔または冗長）エラーが記録されます。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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値 - リキーイベントヘッダーのグループID値は、メッセージがグループコンポーネントのグループIDに対してチェックしなければなりません受け取りました。一致が見つからない場合、ペイロードは、次に、モードに関わらず（例えば、簡潔又は冗長）エラーが記録され、廃棄されます。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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.日付/タイムスタンプ - リキーイベントヘッダーの日付/タイムスタンプ値は、キーの再生成イベント発生時刻は、ネットワークの遅延や処理時間への最近の相対的であるかを決定するためにチェックされます。タイムスタンプが、最近ではないと判断された場合は、エラーが記録されます。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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.リキーイベントタイプフィールド - リキーイベントヘッダーのリキーイベントタイプは、メッセージは、表17で定義されるように、有効な再入力イベント型であることをチェックし、リキーイベントの同じ値である必要があり、受信しこのペイロードに以前入力します。リキーイベントの種類は、次に、モードに関わらず、無効またはリキーイベントタイプの以前の値に等しくない場合（例えば、簡潔又は冗長）エラーが記録されています。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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.アルゴリズムバージョン - リキーアルゴリズムバージョン番号が示されたバージョンがサポートされていることを確認するためにチェックしなければなりません。それがサポートされていない場合には、モードに関係なく（例えば、簡潔又は冗長）エラーが記録されています。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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のためのものであるという可能性がある使用しなければなりません。すべてのリキーイベント件のデータが消費されるまでリキーイベント件のデータが順番に処理されます。
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.ラッピング鍵ID - ラッピング鍵IDは、このGMが保有する保存されたのKEKのリストと照合しなければなりません。一致が見つかった場合、このリキーイベントデータの処理を続けます。そうでない場合は、次のリキーイベントデータへスキップします。
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はこのリキーイベントデータに関連付けられたキーパッケージを処理します。そうでない場合は、次のリキーイベントデータへスキップします。
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を使用してポリシーに従ってこのリキーイベントデータの残りのデータを復号化し、ハンドル。データを復号化した後、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で定義されたキーパッケージタイプが有効でない場合はキーパッケージタイプは、その後、モードに関係なく（例えば、簡潔または冗長）エラーが記録され、有効なキーパッケージタイプであることをチェックしなければなりません。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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によって定義されるような鍵パッケージ・タイプが有効でない場合はキータイプは、次に、モードに関わらず（例えば、簡潔又は冗長）エラーが記録され、有効なキータイプであることをチェックしなければなりません。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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のセットに対してチェックしなければなりません。一致が見つからない場合、モードに関係なく（例えば、簡潔又は冗長）エラーが記録されています。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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.キー作成日 - キー作成日は、現在開催されたキーのキー作成日以降であることをチェックしなければなりません。この日付は、現在保持されているキーの前であれば、モードに関係なく（例えば、簡潔又は冗長）エラーが記録されています。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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.キーの有効期限日 - キーの有効期限日はそれだけで受信したキー作成日以降であり、時間ルールがポリシーに準拠していることをチェックしなければなりません。有効期限は、作成日以降でない場合、またはポリシーに適合しない場合、モードに関係なく（例えば、簡潔又は冗長）エラーが記録されています。応答なしのエラーメッセージは、グループの管理、メッセージの受信のために生成されません。
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.
エラーがなかった場合はキーパッケージを処理する際に、鍵IDによって表されるキーは、受信した情報に基づいて更新され、そのデータのすべてを持っています。
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.
RESERVED（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つのオクテット） - 識別データの所有権を分類します。表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
送信者0レシーバIANA 3に予約済み1サードパーティの2から192私用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 Typeフィールドによって指定されます。このフィールドの形式は表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
0 ID_IPV4_ADDR 1 SubjAltName参照[IKEv2の] IPアドレスセクション3.5を禁じます。 ID_FQDN 2 SubjAltName [IKEv2の]のdNSNameのセクション3.5を参照してください。 ID_RFC822_ADDR 3 SubjAltName [IKEv2の] rfc822Nameでのセクション3.5を参照してください。 4 ID_IPV6_ADDR 5 SubjAltName参照[IKEv2の] IPアドレスセクション3.5を禁じます。予約済み6から8 ID_DER_ASN1_DN 9被写体全体、[IKEv2の]ビット単位はセクション3.5を比較参照してください。 29セクション3.5 - ID_KEY_ID 11 N 10 /参照[のIKEv2]予約12予約。 （ID_U_NAME）このタイプの符号化されていない名前30件名フォーマットはセクション7.6.1.1で定義されています。 31件名を参照[RFC4514]をID_DN_STRING。このタイプを実装する必要があります。 192私用193 - - 255 IANA 32に予約済み
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：暗号化されていない名前（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値（Subjectフィールド）、スラッシュ（/）は、フィールド区切り文字のための文字（例えば、「/ C = US / ST = MD / L =どこか/ O = ACME社を使用して./OU=DIV1/CN=user1/ Email=user1@acme.com」周囲の引用符なし）。
When processing the Identification 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.次のペイロード、RESERVED、ペイロード長 - セクション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.
前記識別データ - この識別データは、指定された識別タイプに従って処理されなければなりません。タイプは、データのフォーマットを定義します。識別データが一致するものを検索するために使用されていると一致しない場合、エラーが記録されています。冗長モードであれば、通知値無効-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.シリアル番号 - シリアル番号（1）準拠CA [RFC3280]から有効なシリアル番号であることが1以上でなければなりません。値が有効でない場合、エラーが記録されます。冗長モードであれば、通知値ペイロード不正を含む適切なメッセージが送信されます。
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.
情報、シリアル番号およびDNデータのこれらの2個は、一緒に、その後のパーティの識別に使用されるであろう。また、これらの値は、必要なときに証明書を識別するために使用されます。
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
証明書ペイロードはGSAKMPを介して証明書または他の証明書関連情報を搬送する任意のGSAKMPメッセージに表示されることができる手段を提供します。証明書ペイロードは適切なディレクトリ・サービス（例えば、LDAP [RFC4523]）は、証明書を配布するために利用可能ではないときはいつでも交換に含まれるべきです。複数
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.
証明書ペイロードは、証明書チェーンの検証を可能に送信することができます。逆に、ゼロ（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.
RESERVED（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
なし0予約1 - 3のX.509v3証明書4このタイプでなければならない - 署名実現します。 - DERエンコーディングはDERエンコードされたX.509証明書が含まれています。予約5から6証明書失効リスト7は、BER（CRL）がX.509 CRLをエンコードが含まれています。予約8から9 X.509証明書10は、[のIKEv2]、章3.6を参照されたいです。 - 属性生のRSAキー11を参照してください[IKEv2の]、秒3.6。 X.509 12のハッシュとURLは[IKEv2の]、秒3.6を参照してください。 X.509 13の証明書ハッシュとURLは[IKEv2の]、秒3.6を参照してください。 65535から49152自家用49153 - IANA 14に予約済みのバンドル
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.次のペイロード、RESERVED、ペイロード長 - セクション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-タイプサポートされていないを含む適切なメッセージが送信されます。
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.
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.
RESERVED（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
ASN.1 / DERエンコーディング0とDSS / SHA1このタイプMUST（DSS-SHA1-ASN1-DER）がサポートされます。 RSA1024-MD5 1を参照[RFC3447]。 ECDSA-P384-SHA3 2は[FIPS186-2]を参照してください。 IANA 3に予約済み - 41952自家用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つのオクテット） - 署名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オクテット） - これは、デジタル署名が適用された時間値です。このフィールドは、YYYYは年UTF-8形式のYYYYMMDDHHMMSSZ、（0000から9999）のタイムスタンプが含まれ、MMは月（01から12）の数値であり、DDは月（01から31）の日です、 HHは日（00から23）の時間で、MMは、時間内（00から59）分で、SSは分以内秒（00から59）、および文字Zが、これはズールー族の時間であることを示しています。この形式は緩く[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 Typeフィールドに基づいており、その型が定義されているところが示されています。このフィールドの内容は、グループのコンテキスト内で署名者の権限とアクセスを決定する方針トークンに対してチェックしなければなりません。
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.次のペイロード、RESERVED、ペイロード長 - セクション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タイプ - 表19により定義される値が有効でない場合は署名IDタイプ値は、エラーが記録され、その後、有効な署名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.
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.
前記署名データ - この値は、メッセージを確認するために再計算された署名と比較されなければなりません。署名の有効性を確認するために使用される証明書を確認する方法に関する情報は、[RFC3280]で見つけることができます。 IDデータが検証される署名によって識別された証明書は、署名は、署名検証用の署名データと比較するために計算することができた後にのみ。署名の検証中に発生し得る潜在的なエラーは、認証失敗です。署名検証のための証明書を処理中に発生する可能性が潜在的なエラーは、次のとおり無効な証明書、無効-CERT-局、証明書タイプ - サポートされていない、と証明書に使用できません。
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.
RESERVED（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
なし0無効なペイロードタイプ1予約2から3無効バージョン4無効なグループID 5無効-配列番号6ペイロード不正7無効-鍵情報8 10予約無効-ID-情報9から11 Cert-タイプサポートされていない12無効-CERT-局13の認証に失敗した14予約15から16証明書利用不可17リザーブ18不正なリクエスト19リザーブ20から22謝辞23リザーブ24から25のNack 26クッキー要27のクッキー28メカニズムの選択29脱退グループ30出発エラー32無効な取引タイプ33のIPv4値34を出発する31の要求を受け入れ
IPv6 Value 35 Prohibited by Group Policy 36 Prohibited by Locally Configured Policy 37 Reserved to IANA 38 - 49152 Private Use 49153 -- 65535
65535から49152自家用49153 - IANA 38に予約されてローカルに設定されたポリシーで禁止されている37グループポリシー36で禁止されているIPv6の値35
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つのオクテット） - 承認のタイプを指定します。表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データ部はnull。 192私用193 - - 255 IANA 1に予約済み
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およびクッキーの通知ペイロードのデータ部分は、クッキー値を含みます。このフィールドの値は、レスポンダーGC / KSによって計算され、GMに送られてきたでしょう。 GMは、受信した値を取り、バックGC / KSに「クッキー情報を参加要求」で送信されたタイプのクッキーの通知ペイロード通知データフィールドにコピーされます。クッキーの値を変更してはいけません。
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との交渉のために使用することを要求された機構を含んでいます。この情報はRTJメッセージにGMによって供給されることになります。メカニズムの選択ペイロードタイプ - 図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
鍵の作成アルゴリズム0表26暗号化アルゴリズム1つの表16ナンスハッシュアルゴリズム2表IANA 3に予約済み25から192自家用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：ナンスハッシュタイプ
Nonce_Hash_Type Value Description
__________________________________________________________________
Reserved 0 SHA-1 1 This type MUST be supported. Reserved to IANA 2 - 49152 Private Use 49153 - 65535
予約0 SHA-1このタイプはサポートされなければなりません。 IANA 2に予約済み - 49152自家用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.次のペイロード、RESERVED、ペイロード長 - セクション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.
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ペイロードはこの仕様で定義されたすべての情報の解釈を変更しないでください。複数のVendor IDペイロードを送るかもしれません。実装は全くどんなVendor 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:
次のようにベンダーIDペイロードフィールドが定義されています。
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.
RESERVED（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つ（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.次のペイロード、RESERVED、ペイロード長 - セクション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の値が認識されない場合、その後に関係なくモード（例えば、簡潔又は冗長）情報が記録されています。メッセージの処理にかかわらず、この値の認識の継続しなければなりません。
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.
RESERVED（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
予約され、0 - 1のDiffie-Hellmanの2このタイプはサポートされなければなりません。 [IKEv2の] B.2に定義された1024ビットのMODPグループ。プロセスの出力は、より長い定義されたメカニズムのために必要とされる場合は切り捨て、最初のX下位ビットを使用し、残りを切り捨てます。 [RFC3526]で定義されたディフィー - ヘルマン14 13から3を予約します。 2048ビットMODPグループが切り捨てが定義されたメカニズムのために必要なより長いプロセスの出力は、第1のX下位ビットを使用し、残りを切り捨てる場合。 65535から49152自家用49153 - IANA 15に予約済み
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.次のペイロード、RESERVED、ペイロード長 - セクション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秘密鍵素材）から他のキーを導出したい実装は、新しいキー作成タイプは、その導出のアルゴリズムを指定する必要があります。表26に示されたものの以外のキーの作成タイプを定義する必要がありますそのためKEKは、派生鍵の一つであってもよいです。
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.
ナンスペイロードは交換の間に新鮮さを保証し、リプレイ攻撃から保護するために使用されるランダムデータが含まれています。図27は、ノンスペイロードのフォーマットを示します。
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：ナンスペイロードフォーマット
The Nonce 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.
RESERVED（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.
ナンスタイプ（1つのオクテット） - 使用されるノンスのタイプを指定します。表27は、ナンスの種類を識別します。このフィールドは、符号なしの値として扱われます。
Table 27: Nonce Types
表27：タイプ使節
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
なし0イニシエータ（Nonce_I）1レスポンダ（Nonce_R）ハッシュタイプはポリシーから来て2コンバインド（Nonce_C）3ハッシュ（アペンド（Initiator_Value、Responder_Value））（例えば、セキュリティ・スイート方針トークンの定義）。 192私用192 - - 255 IANA 4に予約済み
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.
乱数データ（可変長） - ナンスの情報が含まれています。このフィールドの値は、特定のグループであり、フォーマットはノンスTypeフィールドによって指定されます。いかなるグループ固有の情報が提供されない場合、このフィールドの最小の長さは4バイトです。
The payload type for the Nonce Payload is twelve (12).
ノンスペイロードのペイロードタイプは12（12）です。
When processing the Nonce 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.次のペイロード、RESERVED、ペイロード長 - セクション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.ノンスタイプ - 表27で定義されるような値が有効でない場合ノンスタイプ値は、エラーが記録され、有効なノンスタイプであることが確認されなければなりません。冗長モードであれば、通知値ペイロード不正を含む適切なメッセージが送信されます。
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.乱数データ - これは一回だけのデータであり、その内容に応じてチェックする必要があります。このフィールドのサイズは7.12、「Nonceのペイロード」で定義されています。このフィールドの解釈のために、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）GSAKMPリキーイベントタイプ（7.5.1項）GSAKMP識別分類（7.6.1項）GSAKMP識別タイプ（7.6.1項）GSAKMP証明書の種類（7.7.1項）GSAKMP署名タイプ（7.8.1項）GSAKMPの通知タイプ（7.9.1項）GSAKMP謝辞タイプ（セクション7.9.1.1）GSAKMPメカニズムタイプ（セクション7.9.1.3）GSAKMPナンスハッシュタイプ（セクション7.9.1.3）GSAKMPキー作成タイプ（7.11節0.1）GSAKMPナンスタイプ（セクション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
GSAKMPグループ識別タイプGSAKMPペイロードタイプGSAKMP交換タイプGSAKMP方針トークンタイプGSAKMPキー・データ項目のタイプGSAKMPリキーイベントタイプGSAKMP識別分類GSAKMP通知タイプGSAKMP謝辞種類GSAKMPの機構型GSAKMPナンスのタイプをダウンロード
Changes and additions to the following registries are by Expert Review:
以下のレジストリの変更や追加は、専門家レビューによるものです。
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ナンスハッシュタイプ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に表示される可能性があり、著者の数に制限はありませんでした場合は、以下では、アルファベット順に、リストされているされていたであろう：サリー大学のHaitham S.クルックシャンク、LogicaCMGのサリーギャビン・ケニー大学、パトリックのスニルアイアンガーをAT＆T Labsの研究のマクダニエル、そしてNSAのアンジェラ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".
以下の個人が大幅にこのプロトコルを改善している彼らの貢献、の認識と感謝に値する：エリックはハーダー概念だけでなくGSAKMPに発見されたトンネリング-GSAKMP、と著者です。また、トンネリング・GSAKMP著者ロッドフライシャー、そしてピーター・ラフは、両方のGSAKMPソフトウェアのプロトタイプをコーディングに尽力しており、最高の状態で漠然としたプロトコルの多くの領域を定義助けました。アンドリュー・マクファーランドとグレゴリーBergrenは、仕様の初期バージョンの批判的分析を提供します。カネッティは、プロトコルの安全性を分析し、オプションの「クッキーの保護」につながるサービスの提案の拒否を提供しました。
[DH77] Diffie, W., and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, June 1977.
[DH77]ディフィー、W.、およびM.ヘルマン、 "暗号に関する新"、情報理論、1977年6月にIEEEトランザクション。
[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、「デジタル署名標準」、FIPS PUB 186-2の、米国国立標準技術研究所、商業、2000年1月の米国部門。
[FIPS196] "Entity Authentication Using Public Key Cryptography," Federal Information Processing Standards Publication 196, NIST, February 1997.
[FIPS196]「公開鍵暗号を使用してエンティティの認証、」連邦情報処理規格出版196、NIST、1997年2月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]オーマン、H.、 "OAKLEYキー決意プロトコル"、RFC 2412、1998年11月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627]ウォルナー、D.、ハーダー、E.、およびR.アゲ、 "マルチキャストのためのキー管理：問題とアーキテクチャ"、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.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネット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.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"。、RFC 4514、2006年6月。
[RFC4534] Colegrove, A. and H. Harney, "Group Security Policy Token v1", RFC 4534, June 2006.
[RFC4534] Colegrove、A.およびH.ハーニー、 "グループセキュリティポリシートークン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.、マグリュー、D.、およびA.シャーマン、「大規模な動的グループのためのキー管理：一方向関数の木と償却初期化」、進歩、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.ハーニー、A. Colegrove、P.マクダニエル、「セキュア・グループにおける政策の原則」、ネットワークの議事および分散システムのセキュリティ2001インターネット協会、サンディエゴ、CA、2001年2月。
[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.、ハーニー、H.、マクダニエル、P.、Colegrove、A.、およびP. Dinsmore、 "グループセキュリティポリシートークン：定義とペイロード"、進歩、2003年8月の作業。
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093]ハーニー、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]ハーニー、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]モーガンD.、Schertler M.、シュナイダーM.、およびターナーJ.、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408は、1998年11月、標準を提案しました
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]カーン、P.とW.シンプソン、 "Photuris：セッション鍵管理プロトコル"、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.、 "LDAP（Lightweight Directory Access Protocol）のX.509証明書のためのスキーマ定義"、RFC 4523、2006年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、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]アダムス、C.、カイン、P.、ピンカス、D.、およびR. Zuccherato、 "インターネット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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（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.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、RFC 3526、2003年5月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、RFC 3740、2004年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
Appendix A. LKH Information
付録得。情報を書き込みます
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方式を使用して、キーの再生成イベントメッセージの例を与えます。
A.1. LKH Overview
クラス0.1。概要を書きます
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は、グループキー更新のための鍵の配布を処理するためのトポロジを提供します。これは、ツリー構造とサブグループキーに基づいてグループをキー更新します。中間ツリーノードは抽象キーグループを表している図29に示すLKHツリーで、メンバーは、ツリー上のリーフノードにより表されます。メンバーは、複数のキーを所有します：グループトラフィック保護キー（GTPK）、サブグループキーツリーのルートへのパス上のすべてのノードについて、および個人的なキーを。例えば、＃3とラベル付け部材はGTPK、鍵A、鍵d、およびキー3を有するであろう。
root / \ / \ A B / \ / \ / \ / \ C D E F / \ / \ / \ / \ / \ / \ / \ / \ 1 2 3 4 5 6 7 8
ルート/ \ / \ A B / \ / \ / \ / \ C D E F / \ / \ / \ / \ / \ / \ / \ / \ 1 2 3 4 5 6 7 8
Figure 29: LKH Tree
図29：ツリーを書きます
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 '）はまた、する必要があります確実にそれらのサブツリーの他のメンバーに配布されます。 GTPKを暗号化「キーBとすると、確実に、メンバー5にその鍵を配布6、7、および8キーCがGTPK両方暗号化するために使用することができるであろう」メンバー1および2部材3の最近傍、メンバーの「とキーAをこのプロセスの終わりに、その個人キー、キー4の下で暗号化4は、GTPK「キーD」、およびキーA」を得ることができ、グループが確実に完全に排除部材3とリキーされます。
A.2. LKH and GSAKMP
A.2。 LKHとGSAKMP
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.リキーバージョン＃ - キーのダウンロードペイロードの再入力配列内のリキーのバージョン番号が値1（1）を含まなければなりません。
2. Algorithm Version - The Algorithm Version in the Rekey Event Payload MUST contain the value one (1).
2.アルゴリズムバージョン - リキーイベントペイロード内のアルゴリズムバージョン（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.
前記ノード識別 - ツリー内の各ノードはKEKとして扱われます。 KEKは、単に特殊なキーです。ルールはGSAKMP内のすべてのキーのために述べたように、鍵IDと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.ラッピング鍵IDとハンドル - これが鍵IDとリキーイベントデータ内のデータを暗号化/ラップするために使用LKHノードのハンドルです。
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のノード：この行は、鍵IDノード番号Lが含まれています。この行がONLYすべての葉のためMEMBERID番号が含まれています
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.
鍵IDの一意性を保証するために、リキーコントローラは、仮想ツリーを構築し、各ノードの鍵IDをラベルにかかわらず、木が実際に満杯であるかどうかのフル装備ツリーの幅優先探索を行うべきです。この例の簡略化のため、ツリーのルートは、一（1）のKeyIDを値を与えました。これらのキーID値は、この木の一生静的になります。また、のGMに分配リキーアレイはKeyDownloadペイロードと一緒に配布されるそれらに関連付けられMEMBERID値を必要とします。これらのMEMBERID値は一意である必要があります。したがって、各リーフノード（バックルートにその葉からノード）に関連付けられたセットがMEMBERIDを与えられています。この例では、左端のリーフノードは、1つ（1）のMEMBERID値が与えられます。値のこれらの2セットは、（ラインNで表される）KeyIDsとMemberIDs（ラインL上に表される）は、情報を発信するKeyDownloadとRekeyEventペイロードに十分な情報を与えます。これらのキーに関連付けられているKeyHandleは鍵が妥協によるツリーに交換されるたびに再生成されます。
A.3. LKH Examples
クラス0.3。 Aksamplesを書きます
Definition of values: 0xLLLL - length value 0xHHHHHHH# - handle value YYYYMMDDHHMMSSZ - time value
値の定義： - 長さの値0xHHHHHHH＃ - ハンドル値YYYYMMDDHHMMSSZ - 0xLLLL時間値
A.3.1. LKH Key Download Example
A.3.1。 LKHキーをダウンロードする例
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 |鍵ID 2 |鍵ID 4 |鍵ID 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
アイテムの数 - 0×0002アイテム＃1：キーのダウンロードデータ項目の種類 - $ 00（GTPK）キーをダウンロードするデータ項目の長さ - 0xLLLLキータイプ - 0×03（3DES`CBC64`192）キーID - KEY1キーハンドル - 0xHHHHHHH0キー作成日 - YYYYMMDDHHMMSSZキーの有効期限日 - YYYYMMDDHHMMSSZキーデータ - キー定義アイテム＃2に基づいて、可変、： - 0x01の（リキー - LKH）主要なダウンロードデータ項目の長さ - 0xLLLLリキーバージョン番号 - 0x01のメンバー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
A.3.2. LKH Rekey Event Example
A.3.2。 LKHリキーイベント例
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.
このセクションでは、キーの再生成イベントペイロードのデータの一例を与えます。 MEMBERID 6とGMは、グループのキーアウトされます。示したデータは、ジェネリックペイロードヘッダーに続くであろう。
| Rekey Event Type | GroupID | Date/Time | Rekey Type | Algorithm Ver | # of Packets | { (GTPK)2, (GTPK, 3', 6')12, (GTPK, 3')7 }
|イベントの種類をリキー|グループID |日付/時刻| |タイプのキーの再生成アルゴリズム版|パケットの＃| {（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
LKH KeyIDを2 B）GTPK、LKH KeyIDs 3' および6' 、LKH KeyIDを12 C）GTPKとLKH KeyIDを3' に包ますべて、LKH KeyIDを7に包ますべてに包まA）GTPK
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
キーの再生成イベントの種類 - 0x01の（GSAKMP`LKH）グループID - 0xAABBCCDD 0x12345678の時刻/日付スタンプ - YYYYMMDDHHMMSSZリキーイベントの種類 - 0x01の（GSAKMP`LKH）アルゴリズムのVers - RkyEvtパケット数の0x01の＃ - パケットのための0x0003（B）：パケット長 - 0xLLLLラッピング鍵ID - 0x000Cラッピングキーハンドル - 0x0003キーパッケージ1 - キーパッケージの0xHHHHHHHD番号：キーPKGタイプ - $ 00（GTPK）パック長 - 0xLLLLキータイプ - 0×03（3DES`CBC64`192）キーID - KEY1キーハンドル - 0xHHHHHHH0キー作成日 - YYYYMMDDHHMMSSZキーの有効期限日 - YYYYMMDDHHMMSSZキーデータ - 変数、キー定義に基づいてキーパッケージ2：キーPKGタイプ - 0x01の（リキー - LKH）パック長 - 0xLLLLキータイプ - 0×03（3DES`CBC64`192）キーID - 0x00000003キーハンドル - 0xHHHHHHH3キー作成日 - YYYYMMDDHHMMSSZキーの有効期限日 - YYYYMMDDHHMMSSZキーデータ - 変数、キー定義に基づいてキーパッケージ3：キーPKGタイプ - 0x01の（リキー - LKH）パック長 - 0xLLLLキータイプ - 0×03（3DES` CBC64`192）キーID - 0x00000006キーハンドル - 0xHHHHHHH6キー作成日 - YYY YMMDDHHMMSSZキーの有効期限日 - YYYYMMDDHHMMSSZキーデータ - 変数、キー定義に基づいて、
Authors' Addresses
著者のアドレス
Hugh Harney (point-of-contact) SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
ヒューハーニー（ポイント・オブ・接触）SPARTA、Inc.の7110サミュエル・モールスドライブコロンビア、MD 21046
Phone: (443) 430-8032 Fax: (443) 430-8181 EMail: hh@sparta.com
電話：（443）430-8032ファックス：（443）430-8181 Eメール：hh@sparta.com
Uri Meth SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
ウリメタSPARTA、Inc.の7110サミュエル・モールスドライブコロンビア、MD 21046
Phone: (443) 430-8058 Fax: (443) 430-8207 EMail: umeth@sparta.com
電話：（443）430-8058ファックス：（443）430-8207 Eメール：umeth@sparta.com
Andrea Colegrove SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
アンドレアColegrove SPARTA、Inc.の7110サミュエル・モールスドライブコロンビア、MD 21046
Phone: (443) 430-8014 Fax: (443) 430-8163 EMail: acc@sparta.com
電話：（443）430-8014ファックス：（443）430-8163 Eメール：acc@sparta.com
George Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833
ジョージ・グロスIdentAwareセキュリティ82オールド・マウンテンロードレバノン、NJ 08833
Phone: (908) 268-1629 EMail: gmgross@identaware.com
電話：（908）268-1629 Eメール：gmgross@identaware.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。