RFC4535 日本語訳
4535 GSAKMP: Group Secure Association Key Management Protocol. H.Harney, U. Meth, A. Colegrove, G. Gross. June 2006. (Format: TXT=240863 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Harney
Request for Comments: 4535 U. Meth
Category: Standards Track A. Colegrove
SPARTA, Inc.
G. Gross
IdentAware
June 2006
コメントを求めるワーキンググループH.ハーニーの要求をネットワークでつないでください: 4535年のU.メタンフェタミンカテゴリ: 規格は総計のG.IdentAware2006年6月にA.コールグローブスパルタInc.を追跡します。
GSAKMP: Group Secure Association Key Management Protocol
GSAKMP: 安全な協会Key Managementプロトコルを分類してください。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはGroup Secure Association Key Managementプロトコル(GSAKMP)を指定します。 GSAKMPはネットワークに関する暗号のグループを創設して、経営するのにセキュリティフレームワークを提供します。 それはグループ方針を広めて、ユーザを認証するためにメカニズムを提供します、とグループはグループ設立、回復、グループのメンバーの感染から回復する能力、グループセキュリティ機能の委譲、および破壊する能力の間、アクセス制御決定を実行するために裁決します。 また、それはグループキーを生成します。
Harney, et al. Standards Track [Page 1] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[1ページ]。
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
1. 序論…7 1.1. GSAKMP概要…7 1.2. 組織を記録してください…9 2. 用語…9 3. セキュリティ問題…12 3.1. セキュリティ仮定…12 3.2. プロトコルを関係づけます…13 3.2.1. ISAKMP…13 3.2.2. FIPSパブ196…13 3.2.3. LKH…13 3.2.4. ディフィー-ヘルマン…14 3.3. サービス妨害(DoS)は攻撃します…14 3.4. Rekeyの有用性…14 3.5. 信頼階層構造の証拠…15 4. アーキテクチャ…15 4.1. 信頼はモデル化されます…15 4.1.1. コンポーネント…15 4.1.2. 行ってください…16 4.1.3. GC/カンザス…16 4.1.4. GC/カンザスを下位に置かせてください…17 4.1.5. GM…17 4.1.6. 仮定…18 4.2. 規則ベースの安全保障政策…18 4.2.1. コントロールにアクセスしてください…19 4.2.2. セキュリティ関連している動作のための承認…20 4.3. 操作を広げます…20 4.4. 操作の概念…22 4.4.1. 仮定…22 4.4.2. 方針トークンの作成…22 4.4.3. グループの創設…23 4.4.4. GC/カンザスの発見…24 4.4.5. GC/カンザス登録方針実施…24 4.4.6. GM登録方針実施…24 4.4.7. 自動分配されたGSAKMP操作…24 5. 寿命サイクルを分類してください…27 5.1. 定義を分類してください…27 5.2. 設立を分類してください…27 5.2.1. 標準のグループ設立…28 5.2.1.1. 接合するよう要求します。30 5.2.1.2. 主要なダウンロード…31 5.2.1.3. 誤りに参加するよう要求します。33 5.2.1.4. キーはダウンロードされます--Ack/失敗。34 5.2.1.5. Ackの不足…35 5.2.2. クッキー: サービス妨害保護との設立を分類してください…36 5.2.3. 受信専用メンバーのための設立を分類してください…39
Harney, et al. Standards Track [Page 2] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[2ページ]。
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
5.3. メインテナンスを分類してください…39 5.3.1. 管理を分類してください…39 5.3.1.1. Rekeyイベント…39 5.3.1.2. 方針アップデート…40 5.3.1.3. 破壊を分類してください…40 5.3.2. グループを出ます…41 5.3.2.1. 追い立て…41 5.3.2.2. 予告のない自発的の出発…41 5.3.2.3. 反-登録…41 5.3.2.3.1. 出発するよう要求します。41 5.3.2.3.2. 出発_応答…43 5.3.2.3.3. _出発ACK…44 6. セキュリティスイート…45 6.1. 仮定…45 6.2. 定義スイート1…45 7. GSAKMP有効搭載量構造…47 7.1. GSAKMPヘッダー…47 7.1.1. GSAKMPヘッダー構造…47 7.1.1.1. GroupID構造…51 7.1.1.1.1. UTF-8…51 7.1.1.1.2. 八重奏ストリング…52 7.1.1.1.3. IPv4は識別子を分類します…52 7.1.1.1.4. IPv6は識別子を分類します…53 7.1.2. GSAKMPヘッダー処理…53 7.2. ジェネリック有効搭載量ヘッダー…55 7.2.1. ジェネリック有効搭載量ヘッダー構造…55 7.2.2. ジェネリック有効搭載量ヘッダー処理…56 7.3. 方針トークン有効搭載量…56 7.3.1. 方針トークン有効搭載量構造…56 7.3.2. 方針トークン有効搭載量処理…57 7.4. 主要なダウンロード有効搭載量…58 7.4.1. 主要なダウンロード有効搭載量構造…58 7.4.1.1. 主要なデータ構造…61 7.4.1.2. Rekeyは構造を整列させます…63 7.4.2. 主要なダウンロード有効搭載量処理…63 7.5. Rekeyイベント有効搭載量…64 7.5.1. Rekeyイベント有効搭載量構造…64 7.5.1.1. Rekeyイベントヘッダー構造…66 7.5.1.2. Rekeyイベントデータ構造…67 7.5.1.2.1. 主要なパッケージ構造…68 7.5.2. Rekeyイベント有効搭載量処理…69 7.6. 識別有効搭載量…71 7.6.1. 識別有効搭載量構造…71 7.6.1.1. ID_U_は構造を命名します…74 7.6.2. 識別有効搭載量処理…74 7.6.2.1. ID_U_は処理を命名します…75 7.7. 有効搭載量を証明してください…75 7.7.1. 有効搭載量構造を証明してください…75
Harney, et al. Standards Track [Page 3] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[3ページ]。
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
7.7.2. 有効搭載量処理を証明してください…77 7.8. 署名有効搭載量…78 7.8.1. 署名有効搭載量構造…78 7.8.2. 署名有効搭載量処理…80 7.9. 通知有効搭載量…81 7.9.1. 通知有効搭載量構造…81 7.9.1.1. 通知データ--承認(ACK)有効搭載量タイプ…83 7.9.1.2. 通知データ--_が必要としたクッキーとクッキー有効搭載量タイプ…83 7.9.1.3. 通知データ--メカニズム選択有効搭載量タイプ…84 7.9.1.4. 通知データ--IPv4とIPv6は有効搭載量タイプを評価します…85 7.9.2. 通知有効搭載量処理…85 7.10. ベンダーID有効搭載量…86 7.10.1. ベンダーID有効搭載量構造…86 7.10.2. ベンダーID有効搭載量処理…87 7.11. 主要な作成有効搭載量…88 7.11.1. 主要な作成有効搭載量構造…88 7.11.2. 主要な作成有効搭載量処理…89 7.12. 一回だけの有効搭載量…90 7.12.1. 一回だけの有効搭載量構造…90 7.12.2. 一回だけの有効搭載量処理…91 8. GSAKMPはダイヤグラムを述べます…92 9. IANA問題…95 9.1. IANAは数の課題を移植します…95 9.2. IANA登録コンテンツに頭文字をつけてください…95 10. 承認…96 11. 参照…97 11.1. 標準の参照…97 11.2. 有益な参照…98 付録A.LKH情報…100 A.1。 LKH概要…100 A.2。 LKHとGSAKMP…101 A.3。 LKHの例…102 A.3.1。 LKHの主要なダウンロードの例…102 A.3.2。 LKH Rekeyイベントの例…103
Harney, et al. Standards Track [Page 4] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[4ページ]。
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
1 GSAKMPラダー図…28 2 クッキーがあるGSAKMPラダー図…37 3 GSAKMPヘッダー形式…47 4 GroupID UTF-8形式…51 5GroupID八重奏記号列の書式…52 6 GroupID IPv4形式…52 7 GroupID IPv6形式…53 8ジェネリック有効搭載量ヘッダー…55 9 方針トークン有効搭載量形式…56 10の主要なダウンロード有効搭載量形式…58 11の主要なダウンロードデータ項目形式…59 12の主要なデータ形式…61 13Rekeyは構造形式を整列させます…63 14Rekeyイベント有効搭載量形式…64 15Rekeyイベントヘッダー形式…66 16Rekeyイベントデータの形式…68 17の主要なパッケージ形式…68 18識別有効搭載量形式…72 19の暗号化されていない名(ID U名)の形式…74 20は有効搭載量書式を証明します…76 21署名有効搭載量形式…78 22通知有効搭載量形式…81 23の通知データ--有効搭載量タイプ形式を承認してください…83 24の通知データ--メカニズム選択有効搭載量は書式をタイプします…84 25ベンダーID有効搭載量形式…86 26の主要な作成有効搭載量形式…88 27の一回だけの有効搭載量形式…90 28GSAKMPはダイヤグラムを述べます…92 29LKH木…100 30GSAKMP LKH木…101
Harney, et al. Standards Track [Page 5] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[5ページ]。
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
1 (RTJ)メッセージ定義に参加するよう要求します。30 2 主要なダウンロード(KeyDL)メッセージ定義…31 3 誤り(RTJ間違える)メッセージ定義に参加するよう要求します。33 4 主要なダウンロード--Ack/失敗(KeyDL-A/F)メッセージ定義…34 5 Ack(LOA)メッセージ定義の不足…35 6 クッキーダウンロードメッセージ定義…37 7 Rekeyイベントメッセージ定義…40 _への8要求_は(RTD)メッセージ定義を去ります…42 9 出発_応答(DR)メッセージ定義…43 10出発_ACK(DA)メッセージ定義…44 11は識別タイプを分類します…48 12の有効搭載量タイプ…49 13はタイプを交換します…49 14の方針トークンタイプ…57 15の主要なダウンロードデータ項目はタイプされます…60 16暗号化キーはタイプされます…62 17のRekeyイベントタイプ…66 18識別分類…72 19の識別タイプ…73 20は有効搭載量タイプを証明します…77 21の署名タイプ…79 22の通知タイプ…82 23の承認タイプ…83 24メカニズムはタイプされます…84 25の一回だけのハッシュタイプ…85 26のタイプの主要な作成情報…89 27一回だけはタイプされます…91 28のGSAKMP州…93 29は変遷イベントを述べます…94
Harney, et al. Standards Track [Page 6] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[6ページ]。
1. Introduction
1. 序論
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.
実体のグループがセキュリティー・サービスを実行する能力は、Group Secure Association(GSA)が設立されるのを必要とします。 GSAは、安全保障政策の一般的な「グループレベル」定義とその方針の実施があるのを確実にします。 暗号化キーの分配はグループレベル方針実施を利用するメカニズムです。
1.1. GSAKMP Overview
1.1. GSAKMP概要
Protecting group information requires the definition of a security policy and the enforcement of that policy by all participating parties. Controlling dissemination of cryptographic key is the primary mechanism to enforce the access control policy. It is the primary purpose of GSAKMP to generate and disseminate a group key in a secure fashion.
保護基情報は安全保障政策の定義とすべての参加団体によるその方針の実施を必要とします。 暗号化キーの普及を制御するのは、アクセス制御方針を実施する一次機構です。 安全なファッションで主要なグループを生成して、広めるのは、GSAKMPのプライマリ目的です。
GSAKMP separates group security management functions and responsibilities into three major roles:1) Group Owner, 2) Group Controller Key Server, and 3) Group Member. The Group Owner is responsible for creating the security policy rules for a group and expressing these in the policy token. The Group Controller Key Server (GC/KS) is responsible for creating and maintaining the keys and enforcing the group policy by granting access to potential Group Members (GMs) in accordance with the policy token. To enforce a group's policy, the potential Group Members need to have knowledge of the access control policy for the group, an unambiguous identification of any party downloading keys to them, and verifiable chains of authority for key download. In other words, the Group Members need to know who potentially will be in the group and to verify that the key disseminator is authorized to act in that capacity.
GSAKMPは3つの主要な役割: 1に)グループセキュリティ管理機能と責任を切り離します。 2歳のグループの所有者) グループコントローラキーサーバ、および3) メンバーを分類してください。 Group Ownerはグループのために安全保障政策規則を作成して、方針トークンでこれらを言い表すのに責任があります。 Group Controller Key Server(GC/カンザス)は、キーを作成して、維持するのに責任があって方針トークンに従って潜在的Groupメンバー(GM)へのアクセスを承諾することによって、グループ方針を実施します。 グループの方針を実施するために、潜在的Groupメンバーはグループのためのアクセス制御方針、それらのキーをダウンロードするどんなパーティーの明確な同定、および主要なダウンロードのための権威の証明可能なチェーンに関する知識も必要とします。 言い換えれば、Groupメンバーは、グループにはだれが潜在的にいるかを知って、主要な宣伝者がその容量で行動するのが認可されることを確かめる必要があります。
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).
これらの活動をサポートするために、Group Secure Association(GSA)を設立するために、プロセスの各当事者のアイデンティティを明白に断言されて、認証しなければなりません。 また、各当事者が認可されていることを確かめなければなりません、方針トークンによって定義されて、プロトコル(例えば、GMかGC/カンザス)における彼の役割で機能するように。
Harney, et al. Standards Track [Page 7] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[7ページ]。
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.
Security Suite1、このドキュメントは役に立つデフォルトセットのセキュリティアルゴリズムと構成について説明します。 このスイートは、アルゴリズムと全体の設定が簡潔に将来のグループのメンバーに説明されるのを許容します。 他のセキュリティスイートは、必要に応じて定義されて、グループのバンドで出ている発表の間、広められるかもしれません。
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.
多くへの多くグループコミュニケーションは複数のデータ送信端末を必要とします。 グループのメンバーが方針トークンと方針ペイロードの包含でグループアクセス制御と承認パラメタを再検討できるので、複数のデータ送信端末が支えられます。 このメンバー吟味の過程はグループがメンバーデータのための適切な保護を提供するかどうか決定する能力を各メンバー(データのそれぞれの可能な源)に与えます。
Harney, et al. Standards Track [Page 8] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[8ページ]。
1.2. Document Organization
1.2. ドキュメント組織
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はSecurity Suite Definitionについて説明します。 セクション7はライフサイクルの各段階の間に使用されるメッセージタイプと形式を提示します。 セクション8はプロトコルのために州のダイヤグラムを定義します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHOULD"、「」 現れる「5月」は中[RFC2119]で説明されるように本書では解釈されることになっているべきです。
Certificate: A data structure used to verifiably bind an identity to
a cryptographic key (e.g., X.509v3).
以下を証明してください。 データ構造は以前は暗号化キー(例えば、X.509v3)へのアイデンティティをよく証明可能に縛っていました。
Compromise Recovery: The act of recovering a secure operating state
after detecting that a group member cannot be trusted. This can
be accomplished by rekey.
回復に感染してください: それを検出して、グループのメンバーを信じられないことができた後に安全な作動状態を回復する行為。 rekeyはこれを達成できます。
Cryptographic Group: A set of entities sharing or desiring to share a
GSA.
暗号のグループ: 共有するか、またはGSAを共有することを望んでいる実体のセット。
Group Controller Key Server (GC/KS): A group member with authority to
perform critical protocol actions including creating and
distributing keys and building and maintaining the rekey
structures. As the group evolves, it MAY become desirable to have
multiple controllers perform these functions.
コントローラの主要なサーバ(GC/カンザス)を分類してください: rekey構造をキーを作成して、分配するのを含んで、建設して、主張する重要なプロトコル動作を実行する権威があるグループのメンバー。 グループが発展するのに従って、複数のコントローラにこれらの機能を実行させるのは望ましくなるかもしれません。
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)を分類してください: Groupメンバーはグループキーへのアクセスがあるあらゆる実体です。 グループがメンバーがどうグループの一部になるか、そして、どう構造化されるかにかかわらず、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/カンザスからグループキーを要求してください。
Harney, et al. Standards Track [Page 9] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[9ページ]。
- 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.
所有者(行く)を分類してください: Group Ownerはグループのために認証可能方針トークンを生成して、変更して、GC/カンザスがグループを始めるように通知するために認可された実体です。
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 Policyはグループの保護メカニズムとセキュリティ関連している振舞いについて完全に説明します。 この方針は、一貫性を持っている安全な操作のためにグループによって一般的に理解されて、励行されなければなりません。
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.
主要なパッケージ: 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:
方針トークン(太平洋標準時の): 方針トークンはそれを実施するためにグループ方針とメカニズムを広めるのに使用されるデータ構造です。 方針トークンは、認可されたGroup Ownerによって発行されて、署名されます。 グループの各メンバーは、トークンについて確かめて、グループに会わなければなりません。方針を接合してください、そして、グループの方針を実施してください(例えば、特定のアルゴリズムでアプリケーションデータを暗号化してください)。 含んでいて、:グループ方針トークンはさまざまな情報を含むでしょう。
Harney, et al. Standards Track [Page 10] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[10ページ]。
- GSAKMP protocol version
- GSAKMPプロトコルバージョン
- Key creation method
- 主要な作成メソッド
- Key dissemination policy
- 主要な普及の方針
- Access control policy
- アクセス制御方針
- Group authorization policy
- グループ承認方針
- Compromise recovery policy
- 感染回復方針
- Data protection mechanisms
- データ保護メカニズム
Rekey: The act of changing keys within a group as defined by policy.
Rekey: 方針で定義されるようにグループの中で転調する行為。
Rekey Array: The construct that contains all the rekey information
for a particular member.
Rekeyは以下を整列させます。 特定のメンバーへのすべてのrekey情報を含む構造物。
Rekey Key: The KEK used to encrypt keys for a subset of the group.
Rekeyキー: 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/カンザス)を下位に置かせてください: それには、どんなグループのメンバーにも適切な処理と信頼の特性がグループ方針で定義されるようにあって、S-GC/カンザスとして機能する可能性があります。 これはネットワーク中で公正に分配されるという要件をグループ処理とコミュニケーションに許容するでしょう(例えば、グループキーを分配してください)。 Subordinate Group Controller Key ServersとのGSAKMPの任意の使用は別々の紙に記録されるでしょう。
Wrapping KeyID: The Key ID of the key used to wrap a Key Package.
ラッピングKeyID: キーのKey IDは以前はよくKeyパッケージを包装していました。
Wrapping Key Handle: The key handle of the key used to wrap the Key
Package.
ラッピングキーハンドル: キーの主要なハンドルは以前はよくKeyパッケージを包装していました。
Harney, et al. Standards Track [Page 11] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[11ページ]。
3. Security Considerations
3. セキュリティ問題
In addition to the specification of GSAKMP itself, the security of
an implemented GSAKMP system is affected by supporting factors.
These are discussed here.
GSAKMP自身の仕様に加えて、実装しているGSAKMPシステムのセキュリティは、要素をサポートすることによって、影響を受けます。 ここでこれらについて議論します。
3.1. Security Assumptions
3.1. セキュリティ仮定
The following assumptions are made as the basis for the security
discussion:
以下の仮定はセキュリティ議論の基礎としてされます:
1. GSAKMP assumes its supporting platform can provide the process
and data separation services at the appropriate assurance level
to support its groups.
1. GSAKMPは、プラットホームをサポートするとグループをサポートするために適切な保証レベルでプロセスとデータ分離サービスを提供できると仮定します。
2. The key generation function of the cryptographic engine will only
generate strong keys.
2. 暗号のエンジンのキー生成機能は強いキーを生成するだけでしょう。
3. The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudo-random
source [RFC4086].
3. このプロトコルのセキュリティは批判的に手当たりしだいに選ばれたパラメタの偶発性に依存しています。 これらは無作為の、または、適切に種を蒔かれた強い擬似ランダムソース[RFC4086]によって生成されるべきです。
4. The security of a group can be affected by the accuracy of the
system clock. Therefore, GSAKMP assumes that the system clock is
close to correct time. If a GSAKMP host relies on a network time
service to set its local clock, then that protocol must be secure
against attackers. The maximum allowable clock skew across the
group membership is policy configurable, with a default of 5
minutes.
4. グループのセキュリティはシステムクロックの精度で影響を受けることができます。 したがって、GSAKMPは、システムクロックが正しい時間の近く間あると仮定します。 GSAKMPホストが地方の時計を設定するためにネットワーク時間指定サービスを当てにするなら、そのプロトコルは攻撃者に対して安全であるに違いありません。 グループ会員資格の向こう側の最大の許容できる時計斜行は5分のデフォルトで構成可能な方針です。
5. As described in the message processing section, the use of the
nonce value used for freshness along with a signature is the
mechanism used to foil replay attacks. In any use of nonces, a
core requirement is unpredictability of the nonce, from an
attacker's viewpoint. The utility of the nonce relies on the
inability of an attacker either to reuse old nonces or to predict
the nonce value.
5. メッセージ処理部で説明されるように、署名に伴う新しさに使用される一回だけの値の使用は反射攻撃をくじくのに使用されるメカニズムです。 一回だけをどんな使用でも、コア要件は攻撃者の観点からの一回だけの予測不可能性です。 一回だけに関するユーティリティは、古い一回だけを再利用するか、または一回だけの値を予測するために攻撃者の無能を当てにします。
6. GSAKMP does not provide identity protection.
6. GSAKMPはアイデンティティ保護を提供しません。
7. The group's multicast routing infrastructure is not secured by
GSAKMP, and therefore it may be possible to create a multicast
flooding denial of service attack using the multicast
application's data stream. Either an insider (i.e., a rogue GM)
or a non-member could direct the multicast routers to spray data
at a victim system.
7. グループのマルチキャストルーティングインフラストラクチャはGSAKMPによって保証されません、そして、したがって、マルチキャストアプリケーションのデータ・ストリームを使用するサービス攻撃のマルチキャスト氾濫否定を作成するのは可能であるかもしれません。 インサイダー(すなわち、凶暴なGM)か非会員のどちらかが、犠牲者システムにデータをスプレーするようマルチキャストルータに指示できました。
Harney, et al. Standards Track [Page 12] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[12ページ]。
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/カンザスの感染はすべてのGMの再登録をコントロールの下に強制します。 GMは、LDAPなどのサービスで供給するようにCRLの上のS-GC/カンザスの証明書を見つけることによって、この状況を認識します。
9. The compromise of the GO forces termination of the group. The GM
recognizes this situation by finding the GO's certificate on a
Certificate Revocation List (CRL) as supplied by a service such
as LDAP.
9. GOの感染はグループの終了を強制します。 GMは、LDAPなどのサービスで供給するようにCertificate Revocation List(CRL)の上のGOの証明書を見つけることによって、この状況を認識します。
3.2. Related Protocols
3.2. 関連プロトコル
GSAKMP derives from two (2) existing protocols: ISAKMP [RFC2408] and FIPS Pub 196 [FIPS196]. In accordance with Security Suite 1, GSAKMP implementations MUST support the use of Diffie-Hellman key exchange [DH77] for two-party key creation and MAY use Logical Key Hierarchy (LKH) [RFC2627] for rekey capability. The GSAKMP design was also influenced by the following protocols: [HHMCD01], [RFC2093], [RFC2094], [BMS], and [RFC2412].
GSAKMPは2(2)存在からプロトコルを引き出します: ISAKMP[RFC2408]とFIPSパブ196[FIPS196]。 Security Suite1によると、GSAKMP実装は、ディフィー-ヘルマンの主要な交換[DH77]の主要な2パーティーの作成の使用をサポートしなければならなくて、rekey能力に、Logical Key Hierarchy(LKH)[RFC2627]を使用するかもしれません。 また、GSAKMPデザインは以下のプロトコルによって影響を及ぼされました: [HHMCD01]、[RFC2093]、[RFC2094]、[BMS]、および[RFC2412。]
3.2.1. ISAKMP
3.2.1. ISAKMP
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はさまざまのグループコミュニケーションを支持して方針実施機能を提供するこれらの特徴を当てにします。
3.2.2. FIPS Pub 196
3.2.2. FIPSパブ196
FIPS Pub 196 provides a mutual authentication protocol.
FIPS Pub196は互いの認証プロトコルを提供します。
3.2.3. LKH
3.2.3. LKH
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]の後にグループ回復を可能にするrekey能力(すなわち、LKH)を当てにします。 多くのインスタンスでは、感染しているグループを破壊して、安全なグループを再建するのが、より良いかもしれないので、これは任意です。
Harney, et al. Standards Track [Page 13] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[13ページ]。
3.2.4. Diffie-Hellman
3.2.4. ディフィー-ヘルマン
A Group may rely upon two-party key creation mechanisms, i.e., Diffie-Hellman, to protect sensitive data during download.
Groupは、ダウンロードの間、極秘データを保護するためにすなわち、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.
このセクションの情報は[IKEv2]から大いに借ります、このプロトコルが既に同様の問題を終えて、GSAKMPが目的に同じセキュリティ問題を使用しているとき。 このセクションはGSAKMPのために適宜変更された[IKEv2]の言い換えられたセクションを含むでしょう。
The strength of a key derived from a Diffie-Hellman exchange using specific p and g values depends on the inherent strength of the values, the size of the exponent used, and the entropy provided by the random number generator used. A strong random number generator combined with the recommendations from [RFC3526] on Diffie-Hellman exponent size is recommended as sufficient. An implementation should make note of this conservative estimate when establishing policy and negotiating security parameters.
ディフィー-ヘルマンの交換から特定のpとg値を使用することで得られたキーの強さを値の固有の強さに依存します、と解説者のサイズは使用して、エントロピーは使用される乱数発生器で前提としました。 ディフィー-ヘルマン解説者サイズで[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の広げることができるフレームワークは、より多くのSecurity Suitesの定義を奨励します。
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.
この交換におけるディフィー-ヘルマン解説者が使用の後にメモリから消されると思われます。 特に、これらの解説者を種子などの長命の秘密から疑似無作為の使用の後に消されないジェネレータまで引き出してはいけません。
3.3. Denial of Service (DoS) Attack
3.3. サービス妨害(DoS)攻撃
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仕様が、分配されたIPスプーフィング攻撃のための緩和がセクション5.2.2で(可能なDoS攻撃の部分集合)であると扱う、「クッキー:」 「サービス妨害保護との設立を分類してください。」
3.4. Rekey Availability
3.4. Rekeyの有用性
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.
また、rekey操作をするGSAKMPの能力に加えて、GSAKMP MUSTには、このrekeyをGMに非常に利用可能な情報にする能力があります。GMがrekeyメッセージを受け取るという必要性はrekeyメッセージの領収書の可能性を広げるメソッドの使用を必要とします。 これらのメソッドはrekeyメッセージの複駆動動力伝達装置、掲示板におけるrekeyメッセージのポスティングなどを含むかもしれません。 任意のrekeyが能力であるとサポートする対応するGSAKMP実装はrekeyメッセージの「再-トランスミッション」をサポートしなければなりません。
Harney, et al. Standards Track [Page 14] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[14ページ]。
3.5. Proof of Trust Hierarchy
3.5. 信頼階層構造の証拠
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 Policy TokenはGOによって発行されて、署名されます。 彼らが方針トークンの規則を満たす場合にだけ、GC/カンザスはそれとGMへの交付金アクセスについて確かめるでしょう。 新しいGMはトークンが確かめる1)、2)GC/カンザスが認可された宣伝者であり、3が)メカニズムがGMデータを保護しながら許容できるグループである場合にだけアクセスを受け入れるでしょう。
4. Architecture
4. アーキテクチャ
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 Architectureドキュメント[RFC3740]の指定されるとしてのIETF MSECアーキテクチャ概念に従います。 GSAKMPは、セキュリティが相互不信と信じられた方針作成当局の原則であると実装する操作のための信頼モデルを創造するのにMSECの部品を使用します。
4.1. Trust Model
4.1. 信頼モデル
4.1.1. Components
4.1.1. コンポーネント
The trust model contains four key components:
信頼モデルは4つの主要なコンポーネントを含んでいます:
- Group Owner (GO),
- 所有者を分類してください(行ってください)。
- Group Controller Key Server (GC/KS),
- コントローラの主要なサーバ(GC/カンザス)を分類してください。
- Subordinate GC/KS (S-GC/KS), and
- そしてGC/カンザス(S-GC/カンザス)が部下になってください。
- 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によって実装された動作は結局信じられた方針作成権威によって起因していて確かめられた情報に基づいています。 GSAKMPの2つの信じられた方針作成当局があります: GO(方針作成権威)と私たちがGOについて確かめることができるPKI根。
Harney, et al. Standards Track [Page 15] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[15ページ]。
4.1.2. GO
4.1.2. 行ってください。
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はグループキーによって保護されるデータに、適切なセキュリティ規則とメカニズムを決定しなければなりません。 方針トークン(太平洋標準時の)でこのすべての情報を得ます。 GOは太平洋標準時を作成して、それに署名します。
4.1.3. GC/KS
4.1.3. GC/カンザス
The GC/KS is authorized to perform several functions: key creation, key distribution, rekey, and group membership management.
GC/カンザスがいくつかの機能を実行するのが認可されます: 主要な作成、主要な分配、rekey、およびグループ会員資格管理。
As the key creation authority, the GC/KS will create the set of keys for the group. These keys include the Group Traffic Protection Keys (GTPKs) and first-tier rekey keys. There may be second-tier rekey trees if a distributed rekey management structure is required for the group.
主要な作成権威として、GC/カンザスはグループのためにキーのセットを創設するでしょう。 これらのキーはGroup Traffic Protectionキーズ(GTPKs)と第1層rekeyキーを含んでいます。 分散rekey経営組織がグループに必要であるなら、2番目の層のrekey木があるかもしれません。
As the key distribution (registration) authority, it has to notify the group of its location for registration services. The GC/KS will have to enforce key access control as part of the key distribution and registration processes.
主要な分配(登録)権威として、それは登録サービスのために位置のグループに通知しなければなりません。 主要な分配と登録の一部が処理されるとき、GC/カンザスは主要なアクセスコントロールを実施しなければならないでしょう。
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.
グループrekey権威として、それは、グループのGTPKを変えるためにrekeyを実行します。 データの暴露がどんな独身のGTPKと共にも暗号化したGTPK限界の変化。
Finally, as the group membership management authority, the GC/KS can manage the group membership (registration, eviction, de-registration, etc.). This may be done in part by using a key tree approach, such as Logical Key Hierarchies (LKH), as an optional approach.
最終的に、グループ会員資格経営権として、GC/カンザスはグループ会員資格(登録、追い立て、反-登録など)に対処できます。 一部主要な木のアプローチを使用することによって、これをするかもしれません、Logical Key Hierarchies(LKH)などのように、任意のアプローチとして。
Harney, et al. Standards Track [Page 16] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[16ページ]。
4.1.4. Subordinate GC/KS
4.1.4. 下位のGC/カンザス
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/カンザスは、複数の実体の向こう側にGC/カンザスの機能性を分配するのに使用されます。 S-GC/カンザスには、1を除いたGC/カンザスのすべての当局があるでしょう: それはGTPKを作成しないでしょう。 ここで、グループがいかなる時も独身のGTPKと共にデータを送ると思われます。 このGTPKはGC/カンザスから来ます。
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/カンザスに比例してS-GC/カンザスは追加セキュリティチェックに責任があることに注意してください: S-GC/カンザスはメンバーとしてGC/カンザスに登録されなければなりません、そして、そのプロセスの間、それはGC/カンザスの権威について確かめなければなりません。
4.1.5. GM
4.1.5. GM
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は、太平洋標準時が認識されたGOによって署名されることを確かめるでしょう。 さらに、登録手続に従事しているGC/カンザスかS-GC/カンザスが認可されていることを確かめるでしょう、太平洋標準時に指定されるように。 rekeyと新しいPTsがグループに分配されると、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によるグループキーThisの領収書によるグループ・データへの与えられたアクセスがそれと共に不当開示からキーを保護する責任を運ぶということです。
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つのGroup Security Associationマルチキャストスピーカー構成の1つを持たせます:
- 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があります。 SAがGOでそのスピーカーを支持して割り当てた1つのマルチキャスト利用があります。 太平洋標準時は、このマルチキャストアプリケーション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
- GOは、GMのすべてがグループのスピーカーであることを認可します。 GOはこれらのスピーカーを支持して1つのマルチキャストのアプリケーションSAを割り当てます。 太平洋標準時は、このマルチキャストアプリケーションSAを初期化して、どんなGMもスピーカーであるかもしれないことを示します。 GMのすべてが独身のGTPKと他のSA州の情報を共有します。 その結果反再生がないかどうかチェックする一連番号などのいくつかのSAセキュリティ機能
Harney, et al. Standards Track [Page 17] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[17ページ]。
protection cannot be supported by this configuration. GSAKMP
implementations MUST support this group configuration.
この構成で保護を後押しされることができません。 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を割り当てます。 太平洋標準時は、認可されたスピーカーを特定して、それぞれの彼らのマルチキャストアプリケーションSecurity Associationsを初期化します。 スピーカーは彼らのSAの向こう側にまだ一般的なTPKを共有していますが、各スピーカーはあらゆる同輩GMに別々のSA州の情報インスタンスを持っています。 その結果、この構成は、SAセキュリティが特徴であるとサポートします、受信機で1スピーカーあたりの状態を必要とする反反復操作による保護、またはソース認証機構がないかどうかチェックする一連番号などのように。この構成の欠点は多くのスピーカーに比例しないということです。 GSAKMP実装はこのグループ構成をサポートするかもしれません。
4.1.6. Assumptions
4.1.6. 仮定
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コントロールメッセージのための秘密性、保全、マルチキャストソース認証、および反反復操作による保護メカニズムがあります。
4.2. Rule-Based Security Policy
4.2. 規則ベースの安全保障政策
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の信頼モデルは安全保障政策の定義と実施を中心題目とします。 事実上、キーの使用は関連しているだけです、セキュリティ意味で、グループ安全保障政策のうまくいっている実施を表すなら。
Harney, et al. Standards Track [Page 18] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[18ページ]。
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は入場を信じられたPKIsから発行されたアイデンティティ証明書に基づく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に実装をサポートするのが、RFC3280に言いなりになるに違いないのを必要とします。
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を追放できるようにその取消しSHOULD信号に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.
合法化メカニズムへの規則のダイレクトマッピングで、複数の規則とPKIsの使用はグループを創設できます。 これで、GOは複数のPKIドメインにかかるグループ安全保障政策を定義できます、それぞれそれ自身のCertificate Authority公開鍵証明書で。
4.2.1. Access Control
4.2.1. アクセス制御
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はアプリケーションへのひとそろいのセキュリティー・サービスを提供して、それらがどうそれらのサービスを利用するかを処方しません。
Harney, et al. Standards Track [Page 19] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[19ページ]。
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は複数のデータ送信端末でGSAsの作成をサポートします。 また、それはGC/カンザスがそれ自体でデータ送信端末でないアーキテクチャをサポートします。 複数のデータ送信端末では、アーキテクチャGSAKMPは、アクセス制御方針が正確に定義されて、各データ送信端末に分配されるのを必要とします。 このデータ構造の参照はGSAKMP Policy Token[RFC4534]です。
4.2.2. Authorizations for Security-Relevant Actions
4.2.2. セキュリティ関連している動作のための承認
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信頼モデルのきわどい局面はセキュリティ関連している動作の承認です。 これらはグループキー、rekey、PT作成、およびアップデートのダウンロードを含んでいます。 安全なグループを混乱させるのにこれらの動作を使用できました、そして、グループにおけるすべての実体がそれらがグループの中の権限のある機関によって扇動されたことを確かめなければなりません。
4.3. Distributed Operation
4.3. 分配された操作
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/カンザス操作のもう一つの側面は現地管理職者当局を可能にすることです。 非常に大きいグループでは、飛び地のグループ会員資格の現地管理職者を提供するために下位の飛び地に合うかもしれないのが最も良い、グループのメンバーに関するダイレクト知識のため。
One of the critical issues involved with distributed operation is the discovery of the security infrastructure location and security suite. Many group applications that have dynamic interactions must "find" each other to operate. The discovery of the security infrastructure is just another piece of information that has to be known by the group in order to operate securely.
分配された操作にかかわる重要な問題の1つはセキュリティインフラストラクチャ位置とセキュリティスイートの発見です。 ダイナミックな相互作用を持っている多くのグループアプリケーションが、作動するために互いを「見つけなければなりません」。 セキュリティインフラストラクチャの発見はしっかりと作動するためにグループによって知られていなければならないただの情報です。
There are several methods for infrastructure discovery:
インフラストラクチャ発見のためのいくつかのメソッドがあります:
- Announcements
- 発表
- Anycast
- Anycast
- Rendezvous points / Registration
- ランデブーポイント/登録
One method for distributing the security infrastructure location is to use announcements. The SAP is commonly used to announce the existence of a new multicast application or service. If an
セキュリティインフラストラクチャ位置を分配するための1つのメソッドは発表を使用することです。 SAPは、新しいマルチキャストアプリケーションの、または、サービスの存在を発表するのに一般的に使用されます。 an
Harney, et al. Standards Track [Page 20] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[20ページ]。
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[RFC2974]を使用して、特定のグループのためのセキュリティインフラストラクチャ位置を含むようにそのサービスは広げることができました。
Announcements can also be used by GSAKMP in one of two modes: expanding ring searches (ERSes) of security infrastructure and ERSes for infrastructure discovery. In either case, the GSAKMP would use a multicast broadcast that would slowly increase in its range by incremental multicast hops. The multicast source controls the packet's multicast range by explicitly setting its Time To Live count.
また、GSAKMPは2つのモードの1つで発表を使用できます: 拡張リングはインフラストラクチャ発見のためにセキュリティインフラストラクチャとERSesの(ERSes)を捜します。 どちらの場合ではも、GSAKMPは増加のマルチキャストホップでゆっくり範囲を増やすマルチキャスト放送を使用するでしょう。 マルチキャストソースは、明らかにTime To Liveカウントを設定することによって、パケットのマルチキャスト範囲を制御します。
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/カンザスのそばで作動します。 この発表が旅行するホップの数は局所的に構成された数でしょう。 GMは興味深いグループにサービスを提供するGC/KSesのためのよく知られるマルチキャストアドレスで聴かれるでしょう。 サービスを提供する複数のGC/KSesが見つけられるなら、GMは最も近い方を選ぶでしょう(マルチキャストホップに関して)。 そして、GMは発表されたGC/カンザスへのJoinメッセージ(RTJ)にGSAKMP Requestを送るでしょう。 発表が偽りであることがわかっているなら、それは適切な経営権に報告されます。 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が1つ以上の応答を受けるなら、それは、応答を無視するか、または地方の構成に基づくNACKsを送るでしょう。
Anycast is a service that is very similar to ERS. It also can be used to provide connection to the security infrastructure. In this case, the GM would send the RTJ to a well-known service request address. This anycast service would route the RTJ to an appropriate GC/KS. The anycast service would have security infrastructure and network connectivity knowledge to facilitate this connection.
AnycastはERSと非常に同様のサービスです。 また、セキュリティインフラストラクチャに接続を提供するのにそれを使用できます。 この場合、GMはよく知られるサービスのリクエストアドレスにRTJを送るでしょう。 このanycastサービスは適切なGC/カンザスにRTJを発送するでしょう。 anycastサービスは、この接続を容易にするためにセキュリティインフラストラクチャを持って、接続性知識をネットワークでつなぐでしょう。
Registration points can be used to distribute many group-relevant data, including security infrastructure. Many group applications rely on well-known registration points to advertise the availability of groups. There is no reason that GSAKMP could not use the same approach for advertising the existence and location of the security infrastructure. This is a simple process if the application being supported already supports registration. The GSAKMP infrastructure can always provide a registration site if the existence of this
セキュリティインフラストラクチャを含む多くのグループ関連しているデータを分配するのに登録ポイントを使用できます。 多くのグループアプリケーションが、グループの有用性の広告を出すためによく知られる登録ポイントを当てにします。 GSAKMPがセキュリティインフラストラクチャの存在と位置の広告を出すための同じアプローチを使用できなかった理由が全くありません。 サポートされるアプリケーションが既に登録をサポートするなら、これは簡単なプロセスです。 GSAKMPインフラストラクチャはこの存在であるならいつも登録サイトを提供できます。
Harney, et al. Standards Track [Page 21] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[21ページ]。
security infrastructure discovery hub is needed. The registration of S-GC/KSes at this site could be an efficient way to allow GM registration.
セキュリティインフラストラクチャ発見ハブが必要です。 このサイトの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仕様のこのバージョンによって標準化されません。
4.4. Concept of Operation
4.4. 操作の概念
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/カンザスの分配された主要な普及のサービスを利用する安全なグループに焦点を合わせます。
4.4.1. Assumptions
4.4.1. 仮定
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信頼できるPKIsがあるという最も基本的な仮定がここにあります。 それは、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があります。 GO公開鍵を知るためにしっかりとすべてのGMをあらかじめ設定しなければなりません。
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/カンザスかS-GC/カンザスに接続できるのを必要とします。
- The Rekey SA requires that the data-layer multicast communication
service be available. This can be multicast IP, overlay networks
using TCP, or NAT tunnels.
- Rekey SAは、データ層のマルチキャスト通信サービスが利用可能であることを必要とします。 これは、マルチキャストIP、TCPを使用するオーバレイネットワーク、またはNATトンネルであるかもしれません。
- GSAKMP can support many different data-layer secure applications,
each with unique connectivity requirements.
- GSAKMPはそれぞれユニークな接続性要件で多くの異なったデータ層の安全なアプリケーションをサポートすることができます。
4.4.2. Creation of a Policy Token
4.4.2. 方針トークンの作成
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はグループのために方針トークンを作成して、署名します。 方針トークンはアクセスコントロールのための規則と特定のグループのための承認を含んでいます。
Harney, et al. Standards Track [Page 22] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[22ページ]。
The PT consists of the following information:
太平洋標準時は以下の情報から成ります:
- Identification: This allows an unambiguous identification of the
PT and the group.
- 識別: これは太平洋標準時、グループの明確な同定を許容します。
- 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/カンザスであるかもしれないかを指定します。
- 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への太平洋標準時のソース認証: 太平洋標準時はオブジェクトであると署名されるCMSです、そして、これはすべてのGMが太平洋標準時について確かめるのを許容します。
4.4.3. Creation of a Group
4.4.3. グループの創設
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.
潜在的GC/カンザスに太平洋標準時を送ります。 これはいくつかの方法で起こることができます、そして、GSAKMPの範囲の外に譲渡のメソッドがあります。 潜在的GC/カンザスは、太平洋標準時にそれが信じられたGOから来るのを保証するためにGO署名について確かめるでしょう。 次に、GC/カンザスは、GC/カンザスになるのが認可されることを確かめるでしょう、太平洋標準時の承認規則に基づいて。 GC/カンザスが太平洋標準時を信じて、GC/カンザスであることが認可されて、与えられたグループとGOのためのGC/カンザスになるように局所的に構成されると仮定すると、GC/カンザスはグループを始めるのに必要な状態でキーを作成するでしょう。 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.
太平洋標準時には、一連番号があります。 太平洋標準時の1時がグループに分配されるときはいつも、グループのメンバーは、太平洋標準時の一連番号が増加していることを確かめます。 PT寿命は特定の時間間隔まで制限されません、属性(例えば、署名の主要な生涯)のいくつかによって課された生涯を除いて。 「主要なダウンロード」メッセージのGMに現在のPT一連番号をダウンロードします。 また、反射攻撃を避けるために、この一連番号も、グループ識別子が有効なままで残っている限り、下側の値(すなわち、ゼロへのロールオーバー)に決してリセットされていて使用中ではありません。 GO MUSTはリブートの向こう側にこの一連番号を保存します。
Harney, et al. Standards Track [Page 23] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[23ページ]。
4.4.4. Discovery of GC/KS
4.4.4. GC/カンザスの発見
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は何らかのメカニズムで新しいグループの通知を受け取るでしょう: 発表、Anycast、または登録ルックアップ。 GMはGC/カンザスにRTJを送るでしょう。
4.4.5. GC/KS Registration Policy Enforcement
4.4.5. GC/カンザス登録方針実施
The GC/KS may or may not require cookies, depending on the DoS environment and the local configuration.
DoS環境と地方の構成によって、GC/カンザスはクッキーを必要とするかもしれません。
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/カンザスは、GMがグループキーに近づく手段を持つことができることを確かめるでしょう。 そして、GC/カンザスは、それが要求されたアイデンティティによって送られたのを保証するためにRTJで署名について確かめるでしょう。 チェックが成功すると、GC/カンザスはGMへのKey Downloadメッセージを準備するでしょう。 そうでなければ、GC/カンザスはセキュリティ関連している非問題についてGMに通知できます。
4.4.6. GM Registration Policy Enforcement
4.4.6. 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.
Key Downloadメッセージを受け取り次第、GMはメッセージで署名について確かめるでしょう。 次に、GMは、Key Downloadメッセージからの太平洋標準時を検索して、GOが太平洋標準時を作成して、署名したことを確かめるでしょう。 太平洋標準時が有効がいったん確かめられると、GMは、GC/カンザスがこのグループのためにキーを分配するのが認可されることを確かめるでしょう。 そして、GMは、GMデータの保護において、グループに使用されるメカニズムが利用可能であって、許容できることを確かめるでしょう(GMを仮定するのは、データ送信端末です)。 そして、GMはこのグループで会員資格を受け入れるでしょう。
The GM will then check to see if it is allowed to be a S-GC/KS for this group. If the GM is allowed to be a S-GC/KS AND the local GM configuration allows the GM to act as a S-GC/KS for this group, then the GM changes its operating state to S-GC/KS. The GO needs to assign the authority to become a S-GC/KS in a manner that supports the overall group integrity and operations.
そして、GMは、このグループに関してそれがS-GC/カンザスであることが許容されているかどうか確認するためにチェックするでしょう。 GMがS-GC/カンザスであることが許容されていて、地方のGM構成が、GMがこのグループのためのS-GC/カンザスとして機能するのを許容するなら、GMは作動状態をS-GC/カンザスに変えます。 GOは、総合的なグループが保全と操作であるとサポートする方法でS-GC/カンザスになる権威を割り当てる必要があります。
4.4.7. Autonomous Distributed GSAKMP Operations
4.4.7. 自動分配されたGSAKMP操作
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/カンザスはPrimary-GC/カンザスがサブグループの会員資格経営者の責任をS-GC/カンザスへ代表として派遣する主に自己充足的なサブグループを経営します。 一般に、S-GC/カンザスはPrimary-GC/カンザスとの少しも相互作用なしでそれぞれのGroupメンバーの登録と反-登録を局所的に扱います。 定期的に、Primary-GC/カンザスマルチキャストa Rekey Eventメッセージは1つ以上のS-GC/カンザスだけに送りました。
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/カンザスが、S-GC/カンザスがPrimary-GC/カンザスからRekey Eventメッセージを首尾よく処理するとそれ自身のサブグループRekeyに伝えた後に
Harney, et al. Standards Track [Page 24] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[24ページ]。
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/カンザスは、Logical Key Hierarchyか匹敵するrekeyプロトコルを使用することでRekey Eventメッセージのサブグループかぎ管理情報を暗号化します。 S-GC/カンザスは前進の、そして、後方の秘密保持がわかるのにrekeyプロトコルを使用します、認可されたサブグループのメンバーだけが新しいGTPKと方針トークンへのアクセスを解読して、取得できるように。 Primary-GC/カンザスがRekey Eventメッセージを送る頻度は方針トークンパラメタです。
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/カンザスの特別なケースにおいて、メカニズムは、グループのrekeyの期間、経過するのを待っているよりむしろ即座のグループrekeyの引き金となるように定義されます。 詳細に関して以下を見てください。
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/カンザスは管理ノードとしてGC/カンザスによってLKHの主要な配列のGTPK分配、アクセス制御方針実施、LKH木の作成、および分配への責任に登録されるでしょう。 S-GC/カンザスは終点としてプライマリ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.
まず最初に、Group Ownerはグループの会員資格の部分集合がS-GC/カンザスの役割を引き受けるのを認可する方針トークンを作成するでしょう。
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/カンザス規則が確実にS-GC/KSesで信頼を確実にするほど厳しくなるようにする必要があります。 この方針トークンはプライマリGCに渡されます。
The GC will create the GTPK and initial LKH key tree. The GC will then wait for a potential S-GC/KS to send a Request to Join (RTJ) message.
GCはGTPKと初期のLKH主要な木を作成するでしょう。 そして、GCは、潜在的S-GC/カンザスがJoin(RTJ)メッセージにRequestを送るのを待つでしょう。
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/カンザスは結局、RTJを送るでしょう。 GCは方針トークンで定義されるようにアクセス制御方針を実施するでしょう。 S-GC/カンザスは、S-GC/カンザスの役割を受け入れて、サブグループ会員資格のためにそれ自身の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/カンザスが役立つことができるグループのメンバーの範囲を制御するために任意の現地管理職者決定があります。 これらはS-GC/カンザスの管理者がサービスを潜在的GMに制限できる本当にローカルの管理問題です。これらの現場制御は総合的なグループ安全保障政策に影響しません、方針トークンで定義されるように。
Harney, et al. Standards Track [Page 25] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[25ページ]。
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.
潜在的GroupメンバーはS-GC/カンザスにRTJを送るでしょう。 S-GC/カンザスは太平洋標準時に定義されるように全体のアクセス制御方針を実施するでしょう。 GMはS-GC/カンザスのLKH木に対応するLKHの主要な配列を受けるでしょう。 S-GC/カンザスによって生成された主要な木はGC/カンザスによって生成された主要な木から独立しています。 彼らはどんな一般的なキーも共有しません。
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/カンザスからそれがグループトラフィックを受けて、rekeyを受けることがあるように必要とするキーを持っています。 この議論のために、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/カンザスは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/カンザスは2つのことをします。 まず最初に、GC/カンザスが追放されるためにメンバーを特定している状態で、S-GC/カンザスは反-登録交換を起こします。 (Groupメンバーがグループから追放されたことをGC/カンザスに知らせるS-GC/カンザスプロキシa Groupメンバーの反-登録。) 2番目に、S-GC/カンザスはGC/カンザスによるrekey動作を待っています。 GC/カンザスによるrekey動作の早急は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/カンザスからの反-登録通知を受け取り次第、GC/カンザスは、追放されるためにメンバーを登録するでしょう。 そして、GC/カンザスはrekey動作(このプロトコルの範囲の外の)を開始するためのグループ手順に従うでしょう。 GC/カンザスは追放されたメンバーの情報(このプロトコルの範囲の外の)をGOに伝えるでしょう。 この情報で、追放されたGMのアイデンティティがグループのアクセス制御規則による除かれたリストに追加されている状態で、GOはグループのために新しいPTを作成するでしょう。 GOは分配のためにRekey Event Messageと共にこの新しいPTをGC/カンザスに提供します。
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/カンザスは新しいPTとのrekey操作を出すでしょう。 S-GC/カンザスは、rekeyを受けて、それを処理するでしょう。 同時に、他のすべてのS-GC/KSesがrekeyを受けて、除かれたGMのアイデンティティに注意するでしょう。 すべてのS-GC/KSesが、除かれたGMが地元のメンバーでないことを保証するために地方のアイデンティティを見直すでしょう。 それがあると、S-GC/カンザスはrekeyメッセージを作成するでしょう。 S-GC/KSesはいつもrekeyメッセージを作成しなければなりません、追放されたGroupメンバーが彼らの下位木のメンバーであるか否かに関係なく。
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/カンザスは除かれたメンバー以外の地元のLKH木のすべてのメンバーに包装されたGroup TPKを送るでしょう。
Harney, et al. Standards Track [Page 26] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[26ページ]。
5. Group Life Cycle
5. 団体生活サイクル
The management of a cryptographic group follows a life cycle: group definition, group establishment, and security-relevant group maintenance. Group definition involves defining the parameters necessary to support a secure group, including its policy token. Group establishment is the process of granting access to new members. Security-relevant group maintenance messages include rekey, policy changes, member deletions, and group destruction. Each of these life cycle phases is discussed in the following sections.
暗号のグループの経営者側はライフサイクルに続きます: 定義、グループ設立、およびセキュリティ関連しているグループメインテナンスを分類してください。 グループ定義は、方針トークンを含む安全なグループをサポートするのに必要なパラメタを定義することを伴います。 グループ設立は新しいメンバーへの与えるアクセスのプロセスです。 セキュリティ関連しているグループメインテナンスメッセージはrekey、政策変更、メンバー削除、およびグループ破壊を含んでいます。 以下のセクションでそれぞれのこれらのライフサイクルフェーズについて議論します。
The use and processing of the optional Vendor ID payload for all messages can be found in Section 7.10.
セクション7.10ですべてのメッセージのための任意のVendor IDペイロードの使用と処理を見つけることができます。
5.1. Group Definition
5.1. グループ定義
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署名を適用してください。
5.2. Group Establishment
5.2. グループ設立
GSAKMP Group Establishment consists of three mandatory-to-implement messages: the Request to Join, the Key Download, and the Key Download Ack/Failure. The exchange may also include two OPTIONAL error messages: the Request to Join Error and the Lack_of_Ack messages. Operation using the mandatory messages only is referred to as "Terse Mode", while inclusion of the error messaging is referred to as "Verbose Mode". GSAKMP implementations MUST support Terse Mode and MAY support Verbose Mode. Group Establishment is discussed in Section 5.2.1.
GSAKMP Group特権階級は3つの実装するために義務的なメッセージから成ります: 接合するという要求、主要なダウンロード、およびキーはAck/失敗をダウンロードします。 また、交換は2つのOPTIONALエラーメッセージを含むかもしれません: Join ErrorへのRequestと_AckメッセージのLack_。 義務的なメッセージだけを使用する操作が「簡潔なモード」と呼ばれます、誤りメッセージングの包含は「冗長モード」と呼ばれますが。 GSAKMP実装は、Terse Modeをサポートしなければならなくて、Verbose Modeをサポートするかもしれません。 セクション5.2.1でグループ特権階級について議論します。
Harney, et al. Standards Track [Page 27] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[27ページ]。
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.
グループはTerseかVerbose Modeに方針トークンパラメタによって設定されます。 Verbose Modeグループにおけるすべての(S)GC/KSesがVerbose Modeをサポートしなければなりません。 GSAKMPはVerbose ModeグループにVerbose ModeをサポートしないGMを持たせます。 Verbose Modeをサポートして、RTJ-誤りかAckのLackメッセージを受け取らない候補GMは優雅にこれらのメッセージを扱わなければなりません。 さらに、GMは、早めに、方針トークンが受け取られているまでVerboseかTerse Modeで(S)GC/カンザスと対話しているのを知らないでしょう。
For denial of service protection, a Cookie Exchange MAY precede the Group Establishment exchange. The Cookie Exchange is described in Section 5.2.2.
サービス保護の否定のために、Cookie ExchangeはGroup特権階級の交換に先行するかもしれません。 Cookie Exchangeはセクション5.2.2で説明されます。
Regardless of mode, any error message sent between component members indicates the first error encountered while processing the message.
モードにかかわらず、コンポーネントメンバーの間に送られたどんなエラーメッセージもメッセージを処理している間に遭遇する最初の誤りを示します。
5.2.1. Standard Group Establishment
5.2.1. 標準のグループ設立
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.
方針トークンのバンドで出ている領収書の後に、潜在的Group Controller Key Server(GC/カンザス)は、GC/カンザスの機能性を実行するためにトークンとその適任について確かめます。 そして、それは、どんな必要なグループキーも作成して、グループを設立し始めるのが許容されています。
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 Ladder Diagram(図1)は暗号のグループを設立するプロセスを例証します。 ダイヤグラムの左側はGC/カンザスの動作を表します。 ダイヤグラムの右側はGMの動作を表します。ダイヤグラムで示されたそれぞれのメッセージの成分はセクション5.2.1で.1〜5.2に提示されます。.1 .5。
CONTROLLER Mandatory/ MESSAGE MEMBER
Optional
!<-M----------Request to Join-------------!
<Process> ! !
<RTJ> ! !
!--M----------Key Download--------------->!
! !<Process KeyDL>
!--O-------Request to Join Error--------->! or
! ! <Proc RTJ-Err>
!<-M----Key Download - Ack/Failure--------!
<Process >! !
<KeyDL-A/F>! !
!--O------Lack of Acknowledgement-------->!
! ! <Proc LOA>
!<=======SHARED KEYED GROUP SESSION======>!
コントローラ義務的な/メッセージメンバー任意で!、<-M----------接合するという要求-------------! <プロセス>!<RTJ>!--M----------主要なダウンロード--------------->! ! <プロセスKeyDL>!--O-------誤りに参加するという要求--------->! または、<がProc RTJ間違える、>!<-M----主要なダウンロード--Ack/失敗--------! <プロセス>!<KeyDL-A/F>! ! --O------承認の不足-------->! ! ! <Proc LOA>!<。=======共有された合わせられたグループセッション======>!
Figure 1: GSAKMP Ladder Diagram
図1: GSAKMPラダー図
Harney, et al. Standards Track [Page 28] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[28ページ]。
The Request to Join message is sent from a potential GM to the GC/KS to request admission to the cryptographic group. The message contains key creation material, freshness data, an optional selection of mechanisms, and the signature of the GM.
暗号のグループに入場を要求するために潜在的GMからGC/カンザスにJoinメッセージへのRequestを送ります。 メッセージは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.
Joinへの受け入れられたRequestに対応してGC/カンザスからGMにKey Downloadメッセージを送ります。 このカンザスによってGC/署名されたメッセージはGM、新しさデータ、主要な作成の材料、暗号化されたキー、および暗号化された方針トークンに関する識別子を含んでいます。 方針トークンは、秩序立っているグループ作成を容易にするのに使用されて、グループの識別、グループ許容を含まなければならなくて、グループはGOの方針、グループコントローラキーサーバのアイデンティティ、グループ経営情報、およびデジタル署名に参加します。 これで、GMは、グループ方針がローカルの方針と互換性があるかどうか決定できるでしょう。
The Request to Join Error message is sent from the GC/KS to the GM in response to an unaccepted Request to Join. This message is not signed by the GC/KS for two reasons: 1) the GM, at this point, has no knowledge of who is authorized to act as a GC/KS, and so the signature would thus be meaningless to the GM, and 2) signing responses to denied join requests would provide a denial of service potential. The message contains an indication of the error condition. The possible values for this error condition are: Invalid-Payload-Type, Invalid-Version, Invalid-Group-ID, Invalid- Sequence-ID, Payload-Malformed, Invalid-ID-Information, Invalid- Certificate, Cert-Type-Unsupported, Invalid-Cert-Authority, Authentication-Failed, Certificate-Unavailable, Unauthorized-Request, Prohibited-by-Group-Policy, and Prohibited-by-Locally-Configured- Policy.
Joinへのunaccepted Requestに対応してGC/カンザスからGMにJoin ErrorメッセージへのRequestを送ります。 このメッセージは2つの理由でGC/カンザスによって署名されません: 1) GMには、ここに、要求が潜在用役力の否定を提供するだろうというGC/カンザスとして機能するのが認可されて、その結果、署名がGMに無意味であるだろう、否定されることへの2つの)署名応答が接合して、だれがそうであるかに関する知識が全くありません。 メッセージはエラー条件のしるしを含んでいます。 このエラー条件のための可能な値は以下の通りです。 無効の有効搭載量タイプ、無効のバージョン、無効のグループID、無効のID情報(本命がサポートされない状態でタイプしていて、無効の本命権威であって、認証で失敗して、証明書入手できなくて、権限のない要求している無効の証明書)がグループ方針で禁止した有効搭載量奇形の無効の系列ID、および禁止されて局所的に構成された方針。
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.
Key Download Ack/失敗メッセージはGMでKey Download領収書状態を示します。 それは新しさデータと状態を含む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.
無効の、または、欠けているKey Download Ack/失敗メッセージに対応して_AckメッセージのLack_をGC/カンザスからGMに送ります。 署名しているメッセージは、新しさと状態データを含んでいて、有効なKey Download Ack/失敗が送られないならグループから追い立てを迫らせるのについてGMに警告するのに使用されます。 追い立ては、メンバーが次のRekey Eventの後のグループから除かれることを意味します。 特定のグループがrekeyにそれ自体を必要とする時に関する方針は方針トークンで述べられています。 セクション5.3.2で、より詳しく.1に追い立てについて議論します。
For the following message structure sections, details about payload format and processing can be found in Section 7. Each message is identified by its exchange type in the header of the message. Nonces MUST be present in the messages unless synchronization time is available to the system.
以下のメッセージ構造部分において、セクション7でペイロード形式と処理に関する詳細を見つけることができます。 各メッセージはメッセージのヘッダーの交換タイプによって特定されます。 同期時間がシステムに有効でない場合、一回だけはメッセージに存在していなければなりません。
Harney, et al. Standards Track [Page 29] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[29ページ]。
5.2.1.1. Request to Join
5.2.1.1. 接合するという要求
The exchange type for Request to Join is eight (8).
JoinへのRequestのための交換タイプは8(8)です。
The components of a Request to Join Message are shown in Table 1.
Join MessageへのRequestの部品はTable1で見せられます。
Table 1: Request to Join (RTJ) Message Definition
テーブル1: (RTJ)メッセージ定義に参加するという要求
Message Name : Request to Join (RTJ)
Dissection : {HDR-GrpID, Key Creation, Nonce_I, [VendorID],
: [Notif_Mechanism_Choices], [Notif_Cookie],
: [Notif_IPValue]} SigM, [Cert]
Payload Types : GSAKMP Header, Key Creation, [Nonce], [Vendor
ID], Signature, [Certificate], [Notifications]
メッセージ名: (RTJ)解剖に参加するという要求: : HDR-GrpID、主要な作成、一回だけ_I、[VendorID]、[Notif_メカニズム_選択]: [Notif_クッキー]、[Notif_IPValue]、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: グループのメンバー本命の署名: 必要なCertificates、ゼロまたは以上、SigX: Signature[]で使用される分野を示します: 任意のデータ項目を示してください。
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決断のためのKey Creationペイロードを含まなければなりません。 新しさのためにNonceペイロードを含まなければなりません、そして、潜在的後の使用のために私が評価するNonce_を取っておかなければなりません。 このグループのための方針トークンが同期時間に対して一回だけの使用を定義する場合にだけ、GC/カンザスはこの供給された一回だけを使用するでしょう。 タイプMechanism ChoicesのOPTIONAL Notificationペイロードは、GMが使用したがっているメカニズムを特定するために含まれるかもしれません。 このペイロードの欠如で、GC/カンザスはKey Downloadのために適切なデフォルト指定された方針トークンメカニズムを選択するでしょう。
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/カンザス動作を示します。 以下は実行されたコネが提示されたオーダーであったならSHOULDをチェックします。
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/カンザスは、メッセージヘッダーが適切に形成されることを確かめて、このメッセージがGroupIDの値をチェックすることによってこのグループのためのものであると確認しなければなりません。 ヘッダーチェックが終わるなら、送付者のアイデンティティはSignatureペイロードから抽出されます。 メッセージ検証に関してアクセス制御チェックを実行して、GM資格証明書が(例えば、証明書)であることがわかるのにこのアイデンティティを使用しなければなりません。 また、Key Downloadメッセージでそれを使用しなければなりません。 そして、GC/カンザスは信憑性を確実にするメッセージで署名について確かめるでしょう。 The
Harney, et al. Standards Track [Page 30] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[30ページ]。
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/カンザスは知られている根から確かめられて信じられた認証の材料を使用しなければなりません。 すべての必要なペイロードが存在していると確認して、適切にベースでフォーマットされて、メカニズムは署名が確かめるメッセージ、GC/カンザスであるなら発表しました。要求にされる。 すべてのチェックが終わると、GC/カンザスは、セクション5.2.1で.2に説明されるようにKey Downloadメッセージを作成して、送るでしょう。
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 SHOULDはRTJメッセージを3(3)回まで再送します。
NOTE: At any one time, a GC/KS MUST process no more than one (1) valid RTJ message from a given GM per group until its pending registration protocol exchange concludes.
以下に注意してください。 いかなる時も、未定の登録プロトコル交換が終わるまで、GC/カンザスは1グループあたり1人の与えられた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/カンザスがTerse Modeへ駆け込んでいるなら、登録セッションを終えなければなりません、そして、州の情報であると保存されたすべてをクリアしなければなりません。
The OPTIONAL Notification payload of type Cookie is discussed in Section 5.2.2.
セクション5.2.2でタイプCookieのOPTIONAL Notificationペイロードについて議論します。
The OPTIONAL Notification payload of type IPValue may be used for the GM to convey a specific IP value to the GC/KS.
GMが特定のIP値をGC/カンザスに伝えるのにタイプIPValueのOPTIONAL Notificationペイロードは使用されるかもしれません。
5.2.1.2. Key Download
5.2.1.2. 主要なダウンロード
The exchange type for Key Download is nine (9).
Key Downloadのための交換タイプは9(9)です。
The components of a Key Download Message are shown in Table 2:
Key Download Messageの部品はTable2で見せられます:
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]
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]
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 : 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
Harney, et al. Standards Track [Page 31] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 31] RFC 4535 GSAKMP June 2006
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
Harney, et al. Standards Track [Page 32] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 32] RFC 4535 GSAKMP June 2006
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.
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.
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.
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.
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.
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.
5.2.1.3. Request to Join Error
5.2.1.3. Request to Join Error
The exchange type for Request to Join Error is eleven (11).
The exchange type for Request to Join Error is eleven (11).
The components of the Request to Join Error Message are shown in Table 3:
The components of the Request to Join Error Message are shown in Table 3:
Table 3: Request to Join Error (RTJ-Err) Message Definition
Table 3: Request to Join Error (RTJ-Err) Message Definition
Message Name : Request to Join Error (RTJ-Err)
Dissection : {HDR-GrpID, [Nonce_I], Notification, [VendorID]}
Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID]
Message Name : Request to Join Error (RTJ-Err) Dissection : {HDR-GrpID, [Nonce_I], Notification, [VendorID]} Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID]
In response to an unacceptable RTJ, the GC/KS MAY send a Request to Join Error (RTJ-Err) message containing an appropriate Notification payload. Note that the RTJ-Err message is not a signed message for the following reasons: the lack of awareness on the GM's perspective of who is a valid GC/KS as well as the need to protect the GC/KS from signing messages and using valuable resources. Following the sending of an RTJ-Err, the GC/KS MUST terminate the session, and all saved state information MUST be cleared.
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.
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
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
Harney, et al. Standards Track [Page 33] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 33] RFC 4535 GSAKMP June 2006
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. 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.
5.2.1.4. Key Download - Ack/Failure
5.2.1.4. Key Download - Ack/Failure
The exchange type for Key Download - Ack/Failure is four (4).
The exchange type for Key Download - Ack/Failure is four (4).
The components of the Key Download - Ack/Failure Message are shown in Table 4:
The components of the Key Download - Ack/Failure Message are shown in Table 4:
Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition
Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition
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
Message Name : Key Download - Ack/Failure (KeyDL-A/F) Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor ID], Signature SigM : Signature of Group Member {}SigX : Indicates fields used in Signature
In response to a properly processed KeyDL message, the GM creates and sends the KeyDL-A/F message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: Notification payload of type Acknowledgement (ACK) and signature information. If synchronized time is not available, the Nonce payload MUST be present for freshness, and the nonce value transmitted MUST be the GM's generated Nonce_C value. If the GM does not receive a KeyDL message within a locally configured amount of time, the GM MAY send a new RTJ. If the GM receives a valid LOA (see Section 5.2.1.5) message from the GC/KS before receipt of a KeyDL message, the GM SHOULD send a KeyDL-A/F message of type NACK followed by a new RTJ.
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.
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.
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.
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
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
Harney, et al. Standards Track [Page 34] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 34] RFC 4535 GSAKMP June 2006
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.
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.
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.
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.
5.2.1.5. Lack of Ack
5.2.1.5. Lack of Ack
The exchange type for Lack of Ack is twelve (12).
The exchange type for Lack of Ack is twelve (12).
The components of a Lack of Ack Message are shown in Table 5:
The components of a Lack of Ack Message are shown in Table 5:
Table 5: Lack of Ack (LOA) Message Definition
Table 5: Lack of Ack (LOA) Message Definition
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]
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]
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 : Signature of Group Controller Key Server Cert : Necessary Certificates, zero or more {}SigX : Indicates fields used in Signature [] : Indicate an optional data item
If the GC/KS's local timeout value expires prior to receiving a KeyDL-A/F from the GM, the GC/KS MAY create and send a LOA message to the GM. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Notification of error, and signature information.
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.
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.
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.
Harney, et al. Standards Track [Page 35] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 35] RFC 4535 GSAKMP June 2006
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.
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.
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.
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.
If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that session.
If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that session.
5.2.2. Cookies: Group Establishment with Denial of Service Protection
5.2.2. Cookies: Group Establishment with Denial of Service Protection
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.
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.
An optional Cookie mode is being defined for the GSAKMP to help against DoS attacks.
An optional Cookie mode is being defined for the GSAKMP to help against DoS attacks.
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.
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.
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
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
Harney, et al. Standards Track [Page 36] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 36] RFC 4535 GSAKMP June 2006
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).
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).
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======>!
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
Figure 2: GSAKMP Ladder Diagram with Cookies
Table 6: Cookie Download Message Definition
Table 6: Cookie Download Message Definition
Message Name : Cookie Download
Dissection : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]}
Payload Types : GSAKMP Header, Notification, [Vendor ID]
Message Name : Cookie Download Dissection : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]} Payload Types : GSAKMP Header, Notification, [Vendor ID]
The first two messages do not affect any GM or GC/KS state except for communicating the cookie.
The first two messages do not affect any GM or GC/KS state except for communicating the cookie.
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.
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.
Harney, et al. Standards Track [Page 37] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 37] RFC 4535 GSAKMP June 2006
The following is an example of how an endpoint could use cookies to implement limited DoS protection.
The following is an example of how an endpoint could use cookies to implement limited DoS protection.
A good way to do this is to set the cookie to be:
A good way to do this is to set the cookie to be:
Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>)
Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>)
where <secret> is a randomly generated secret known only to the responder GC/KS and periodically changed, Ni is the nonce value taken from the initiator potential GM, and IPi is the asserted IP address of the candidate GM. The IP address is either the IP header's source IP address or else the IP address contained in the optional Notification "IPvalue" payload (if it is present). <SecretVersionNumber> should be changed whenever <secret> is regenerated. The cookie can be recomputed when the "Request to Join with Cookie Info" arrives and compared to the cookie in the received message. If it matches, the responder GC/KS knows that all values have been computed since the last change to <secret> and that IPi MUST be the same as the source address it saw the first time. Incorporating Ni into the hash assures that an attacker who sees only the Cookie_Download message cannot successfully forge a "Request to Join with Cookie Info" message. This Ni value MUST be the same Ni value from the original "Request to Join" message for the calculation to be successful.
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.
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.
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.
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.
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.
Harney, et al. Standards Track [Page 38] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 38] RFC 4535 GSAKMP June 2006
5.2.3. Group Establishment for Receive-Only Members
5.2.3. Group Establishment for Receive-Only Members
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.
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.
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.
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.
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
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
- the ID payload identifies that GM
- the ID payload identifies that GM
- the timestamp in the message is fresh
- the timestamp in the message is fresh
- the message is signed by an authorized (S-)GC/KS
- the message is signed by an authorized (S-)GC/KS
- the signature on the message verifies
- 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.
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.
5.3. Group Maintenance
5.3. Group Maintenance
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.
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.
5.3.1. Group Management
5.3.1. Group Management
5.3.1.1. Rekey Events
5.3.1.1. Rekey Events
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.
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.
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.
Harney, et al. Standards Track [Page 39] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 39] RFC 4535 GSAKMP June 2006
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.
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.
The exchange type for Rekey Event is five (5).
The exchange type for Rekey Event is five (5).
The components of a Rekey Event message are shown in Table 7:
The components of a Rekey Event message are shown in Table 7:
Table 7: Rekey Event Message Definition
Table 7: Rekey Event Message Definition
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],
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],
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 : 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
5.3.1.2. Policy Updates
5.3.1.2. Policy Updates
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).
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).
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.
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.
5.3.1.3. Group Destruction
5.3.1.3. Group Destruction
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.
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.
Harney, et al. Standards Track [Page 40] RFC 4535 GSAKMP June 2006
Harney, et al. Standards Track [Page 40] RFC 4535 GSAKMP June 2006
5.3.2. Leaving a Group
5.3.2. Leaving a Group
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.
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.
5.3.2.1. Eviction
5.3.2.1. Eviction
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).
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).
5.3.2.2. Voluntary Departure without Notice
5.3.2.2. Voluntary Departure without Notice
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.
メンバーが会員資格が費用か責任を全くそのメンバーに課さないグループを出たいなら、メンバーは、単に地方のコピーのグループキーを削除して、サークル活動をやめるかもしれません。
5.3.2.3. De-Registration
5.3.2.3. 反-登録
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.
そのメンバーがいなくなりたがっているとき、グループにおける会員資格が出発しているメンバーに費用か責任を課すなら、メンバーSHOULDは反-グループから登録します。 反-登録はGMとメンバーのGC/カンザスの間の3交換処理から成ります: __への要求_が出発して、出発が_応答であり、出発はAckです。 GM SHOULDのための対応するGSAKMP実装は、反-登録がメッセージであるとサポートします。 GC/KSesのための対応するGSAKMP実装は、反-登録がメッセージであるとサポートしなければなりません。
5.3.2.3.1. Request to Depart
5.3.2.3.1. 出発するという要求
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.
_Depart MessageへのRequest_のためのExchange Typeは13(13)です。 _Depart MessageへのRequest_の部品はTable8で見せられます。
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/カンザスに通知するRTDメッセージを生成して、送らなければなりません。 RTDメッセージの解剖で定義されるように、このメッセージは以下の情報を保持するペイロードを含まなければなりません: 仲間から抜ける願望のGC/カンザスの識別とNotification。
Harney, et al. Standards Track [Page 41] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[41ページ]。
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.
Policy Tokenによって定義されるように同期時間がシステムに有効でないときに、新しさのためにNonceペイロードを含まなければなりません、そして、後の使用のために私が評価するNonce_を取っておかなければなりません。 そして、GMはこのメッセージに署名しなければなりません。
Table 8: Request_to_Depart (RTD) Message Definition
テーブル8: _への要求_は(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]
メッセージ名: _への要求_は(RTD)解剖を去ります: [VendorID]、HDR-GrpID、GC/カンザス_ID、[一回だけ_I]、Notif_は_をグループに残します。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: グループのメンバー本命の署名: 必要なCertificates、ゼロまたは以上、SigX: Signature[]で使用される分野を示します: 任意のデータ項目を示してください。
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/カンザスは、メッセージヘッダーが適切に形成されることを確かめて、このメッセージがGroupIDの値をチェックすることによってこのグループのためのものであると確認しなければなりません。 ヘッダーチェックが終わるなら、Identificationペイロードの識別子値はそれ自身のものと比較されています、GC/カンザスのアイデンティティ、それを確認するために、GMがこのメンバーをグループに登録したこのGC/カンザス(カンザス)とGC/話すつもりであったということです。 そして、送付者のアイデンティティはSignatureペイロードから抽出されます。 このGMがこのGC/カンザスによってサービスを提供されたグループのメンバーであると確認するのにこのアイデンティティを使用しなければなりません。 そして、GC/カンザスはGMが要求しているNotificationペイロードから休暇までグループを確認するでしょう。 そして、GC/カンザスは信憑性を確実にするメッセージで署名について確かめるでしょう。 GC/カンザスは知られている根から確かめられて信じられた認証の材料を使用しなければなりません。 すべてのチェックが終わって、メッセージが首尾よく処理されるなら、GC/カンザスは、セクション5.3.2で.2に.3を定義するので、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/カンザスがTerse Modeで作動しているなら、エラーメッセージを全くGMに送りません。 GC/カンザスがVerbose Modeで作動しているなら、GC/カンザスはタイプRequest_のNotification有効搭載量があるDeparture_Response Messageを_Depart_Errorに送ります。
Harney, et al. Standards Track [Page 42] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[42ページ]。
5.3.2.3.2. Departure_Response
5.3.2.3.2. 出発_応答
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 MessageのためのExchange Typeは14(14)です。 Departure_Response Messageの部品はTable9で見せられます。
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/カンザスは、DRメッセージを作成して、送らなければなりません。 メッセージの解剖で定義されるように、このメッセージは以下の情報を保持するペイロードを含まなければなりません: GM識別、出発の承認のためのNotification、および署名情報。 同期時間が有効でないなら、新しさへのメッセージにNonceペイロードを含まなければなりません。
Table 9: Departure_Response (DR) Message Definition
テーブル9: 出発_応答(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]
メッセージ名: 出発_応答(DR)解剖: HDR-GrpID、メンバー_ID[一回だけの_R、一回だけの_C]、通知[VendorID]、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: グループのメンバー本命の署名: 必要なCertificates、ゼロまたは以上、SigX: Signature[]で使用される分野を示します: 任意のデータ項目を示してください。
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/カンザスの発生しているNonce_R価値とGC/カンザスのNonce_Rを使用することによって生成された結合したNonce_C価値が値であったに違いないなら伝わりました、そして、私が評価するNonce_はRTDのGMから受信されました。 GMのIDを去って、これに比例してこのNonce_C値を節約しなければなりません。
The GM MUST be able to process the Departure_Response message. The following checks SHOULD be performed in the order presented.
GMはDeparture_Responseメッセージを処理できなければなりません。 以下は実行されたコネが提示されたオーダーであったならSHOULDをチェックします。
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は、メッセージヘッダーが適切に形成されることを確かめて、このメッセージがGroupIDの値をチェックすることによってこのグループのためのものであると確認しなければなりません。 ヘッダーチェックが終わるなら、GMは、このメッセージがそれ自体のためにIdentificationペイロードでメンバーIDをアイデンティティと比較することによって意図したと確認しなければなりません。 識別確認の後に、新しさ値はチェックされます。 一回だけを使用するなら、GMは、私が評価する保存しているNonce_を使用して、容認されたGC/カンザスNonce_R価値を抽出して、結合したNonce_C値を計算して、平等のために容認されたNonce_C値とそれを比較しなければなりません。 そうでなければ、一回だけを使用して、GMは、メッセージが新しいかどうか決定するために署名ペイロードのタイムスタンプをチェックしなければなりません。 新しさが確認された後に、DRメッセージの署名者のアイデンティティの確認は認可されたGMです。
Harney, et al. Standards Track [Page 43] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[43ページ]。
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/カンザスは実行されます。 そして、信憑性を確実にするために署名について確かめなければなりません。 GMは知られている根から確かめられて信じられた認証の材料を使用しなければなりません。 次に、署名が確かめるメッセージ、GMが、Notificationが_Depart_ErrorへのType Departure_AcceptedかRequest_のものであることを確かめなければならないなら。
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にNotificationペイロードがあるなら、メンバーは、セクション5.3.2で.3に.3を定義するので、Departure_ACKメッセージを形成しなければなりません。 処理がうまくいっていて、_Depart_ErrorへのタイプRequest_にNotificationペイロードがあるなら、メンバーは反-登録セッションに関連しているすべての状態を取り除かなければなりません。 メンバーが、グループからDe登録することをまだ望んでいるなら、メンバーは反-登録手続を再開しなければなりません。
If the processing of the message fails, the de-registration session MUST be terminated, and all state associated with this session is removed. If the GM is operating in Terse Mode, then a Departure_Ack Message with Notification Payload of type NACK is sent to the GC/KS. If the GM is operating in Verbose Mode, then the GM sends a Departure_Ack Message with a Notification Payload of the appropriate failure type.
メッセージの処理が失敗するなら、反-登録セッションを終えなければなりません、そして、このセッションに関連しているすべての状態を取り除きます。 GMがTerse Modeで作動しているなら、タイプナックのNotification有効搭載量があるDeparture_Ack MessageをGC/カンザスに送ります。 GMがVerbose Modeで作動しているなら、GMは適切な失敗タイプのNotification有効搭載量があるDeparture_Ack Messageを送ります。
5.3.2.3.3. Departure_ACK
5.3.2.3.3. 出発_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 MessageのためのExchange Typeは15(15)です。 Departure_ACK Messageの部品はTable10で見せられます:
Table 10: Departure_ACK (DA) Message Definition
テーブル10: 出発_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
メッセージ名: 出発_ACK(DA)解剖: HDR-GrpID、[一回だけの_C]、Notif_Ack[VendorID]、SigM有効搭載量タイプ: GSAKMPヘッダー、[一回だけ]、通知、[ベンダーID]、署名SigM: グループのメンバーの署名、SigX: Signatureで使用される分野を示します。
In response to a properly processed Departure_Response message, the GM MUST create and send the Departure_ACK message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: Notification payload of type Acknowledgement (ACK) and signature information. If synchronization time is not available, the Nonce payload MUST be present for freshness, and the nonce value transmitted MUST be the GM's generated Nonce_C value.
適切に処理されたDeparture_Responseメッセージに対応して、GMは、Departure_ACKメッセージを作成して、送らなければなりません。 メッセージの解剖で定義されるように、このメッセージは以下の情報を保持するペイロードを含まなければなりません: タイプAcknowledgement(ACK)と署名情報の通知ペイロード。 同期時間が有効でないなら、Nonceペイロードは新しさのために存在していなければなりません、そして、一回だけの値はGMの発生しているNonce_Cが値であったに違いないなら送られました。
Harney, et al. Standards Track [Page 44] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[44ページ]。
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/カンザスは以下のチェックを実行しなければなりません。 これらは実行されたコネが提示されたオーダーであったならSHOULDをチェックします。
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/カンザスは、メッセージヘッダーが適切に形成されることを確かめて、このメッセージがGroupIDの値をチェックすることによってこのグループのためのものであると確認しなければなりません。 ヘッダーチェックが終わるなら、GC/カンザスは新しさへのメッセージをチェックしなければなりません。 一回だけを使用するなら、GC/カンザスは、保存しているNonce_C値を使用して、容認されたNonce_C値とそれを比較しなければなりません。 そうでなければ、一回だけを使用して、GC/カンザスは、メッセージが新しいかどうか決定するために署名ペイロードのタイムスタンプをチェックしなければなりません。 新しさが確認された後に、信憑性を確実にするために署名について確かめなければなりません。 GC/カンザスは知られている根から確かめられて信じられた認証の材料を使用しなければなりません。 署名が確かめるメッセージであり、GC/カンザスはNotificationペイロードを処理します。 タイプ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/カンザスはグループからメンバーを免職しなければなりません。 これは、グループのためにRekey Eventを開始することを伴うかもしれません。
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メッセージを発行するかもしれません。
6. Security Suite
6. セキュリティスイート
The Security Definition Suite 1 MUST be supported. Other security suite definitions MAY be defined in other Internet specifications.
Security Definition Suite1をサポートしなければなりません。 他のセキュリティスイート定義は他のインターネット仕様に基づき定義されるかもしれません。
6.1. Assumptions
6.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には、それらに、利用可能なグループに加わるのに正しいSecurity Suiteを使用できるくらいの情報があるでしょう。 別のスイートをよく知られるデフォルトスイート、'セキュリティSuite1'発表するか、または掲示することによって、これを達成できます。
6.2. Definition Suite 1
6.2. 定義スイート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実装はアルゴリズムと構成の以下のスイートを支えなければなりません。 Suite1の以下の定義は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
GSAKMP Suite1定義はすべてのアルゴリズムを与えます、そして、暗号の定義がグループ設立メッセージを処理するのが必要です。 GSAKMPが交渉しないことに注意するのは重要です。
Harney, et al. Standards Track [Page 45] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[45ページ]。
these cryptographic mechanisms. This definition is set by the Group Owner via the Policy Token (passed during the GSAKMP exchange for member verification purposes).
これら、暗号のメカニズムこの定義はPolicy Tokenを通してGroup Ownerによって設定されます(メンバー検証目的へのGSAKMP交換の間、通過されます)。
The GSAKMP Suite 1 definition is:
GSAKMP Suite1定義は以下の通りです。
Key download and Policy Token encryption algorithm definition:
Algorithm: AES
Mode: CBC
Key Length: 128 bits
主要なダウンロードとPolicy Token暗号化アルゴリズム定義: アルゴリズム: AESモード: CBCキー長: 128ビット
Policy Token digital signature algorithm is:
DSS-ASN1-DER
Hash algorithm is:
SHA-1
方針Tokenデジタル署名アルゴリズムは以下の通りです。 DSS-ASN1-DER Hashアルゴリズムは以下の通りです。 SHA-1
Nonce Hash algorithm is:
SHA-1
一回だけのHashアルゴリズムは以下の通りです。 SHA-1
The Key Creation definition is:
Algorithm type is Diffie Hellman
MODP group definition
g: 2
p: "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
"29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
"EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
"E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"
"EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381"
"FFFFFFFF FFFFFFFF"
Key Creation定義は以下の通りです。 アルゴリズムタイプはディフィーのヘルマンの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 49286651ECE65381」"FFFFFFFF FFFFFFFF"」
NOTE: The p and g values come from IKE [RFC2409], Section 6.2,
"Second Oakley Group", and p is 1024 bits long.
以下に注意してください。 値がIKE[RFC2409]、セクション6.2、「第2オークリーグループ」、およびpから来させるpとgは長さ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ストリング
Harney, et al. Standards Track [Page 46] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[46ページ]。
7. GSAKMP Payload Structure
7. GSAKMP有効搭載量構造
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 Messageは少なくとも1GSAKMPの有効搭載量があとに続いたGSAKMP Header(セクション7.1)で構成されます。 すべてのGSAKMP有効搭載量が特定のペイロードデータがあとに続いたGeneric有効搭載量Header(セクション7.2)で構成されます。 メッセージは続くペイロードを定義する前のペイロードによってチェーニングされます。 有効搭載量はセクション5にメッセージ解剖で示された正確なオーダーにあるのに必要ではありません、すべての必要なペイロードが存在していれば。 解剖で単独のタイプの複数のペイロードが存在しているかもしれないと明らかに述べられない場合、メッセージによって許容されたそれぞれのタイプの1個未満のペイロードが現れるかもしれません。 メッセージの最終的なペイロードは続くペイロードを全く示さないでしょう。
All fields of type integer in the Header and Payload structure that are larger than one octet MUST be converted into Network Byte Order prior to data transmission.
データ伝送の前に1つの八重奏より大きいHeaderと有効搭載量構造のタイプ整数のすべての分野をNetwork Byte Orderに変換しなければなりません。
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.
メッセージがVendor IDペイロードを含むとき、そのメッセージのペイロードの処理はセクション7.10で定義されるように変更されています。
7.1. GSAKMP Header
7.1. GSAKMPヘッダー
7.1.1. GSAKMP Header Structure
7.1.1. GSAKMPヘッダー構造
The GSAKMP Header fields are shown in Figure 3 and defined as:
GSAKMP Header分野は、図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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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タイプ!GroupIDの長さ! Group ID Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! Next Payload ! Version ! Exchange Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Sequence ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GSAKMP Header Format
図3: GSAKMPヘッダー形式
Harney, et al. Standards Track [Page 47] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[47ページ]。
Group Identification Type (1 octet) - Table 11 presents the group
identification types. This field is treated as an unsigned
value.
グループIdentification Type(1つの八重奏)--テーブル11はグループ識別タイプを提示します。 この分野は未署名の値として扱われます。
Table 11: Group Identification Types
テーブル11: グループ識別タイプ
Grp ID Type Value Description _____________________________________________________________________
Grp IDタイプ値の記述_____________________________________________________________________
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
予約された0UTF-8 1 Formatはセクション7.1.1で.1に.1を定義しました。 String2Thisがタイプする八重奏を実装しなければなりません。 形式はセクション7.1.1で.2に.1を定義しました。 IPv4 3 Formatはセクション7.1.1で.3に.1を定義しました。 IPv6 4 Formatはセクション7.1.1で.4に.1を定義しました。 IANA5--192私用193--255に予約されます。
Group Identification Length (1 octet) - Length of the Group
Identification Value field in octets. This value MUST NOT be
zero (0). This field is treated as an unsigned value.
Identification Length(1つの八重奏)を分類してください--八重奏における、Group Identification Value分野の長さ。 この値は(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.
グループIdentification Value(可変長)--グループの名前/タイトルを示します。 すべてのGroupIDタイプがグループの向こう側にユニークな命名を提供するべきです。 SHOULDが無作為の要素を含んでいることによってこの能力を提供するGroupIDタイプは、少なくとも8人のグループのクリエイター(所有者)で(8)が八重奏であると生成しました、非常に低い衝突確率をグループ名に提供して。 GroupID値はグループの寿命の間中静的です。
Next Payload (1 octet) - Indicates the type of the next payload in
the message. The format for each payload is defined in the
following sections. Table 12 presents the payload types. This
field is treated as an unsigned value.
次の有効搭載量(1つの八重奏)--メッセージの次のペイロードのタイプを示します。 各ペイロードのための書式は以下のセクションで定義されます。 テーブル12はペイロードタイプを提示します。 この分野は未署名の値として扱われます。
Harney, et al. Standards Track [Page 48] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[48ページ]。
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
0方針トークン1の主要なダウンロードパケット2Rekeyイベント3識別4予約された5証明書6予約された7署名8通知9ベンダーID10の主要な作成11一回だけ12がIANA13--192私用193--255に予約しなかったなにも
Version (1 octet) - Indicates the version of the GSAKMP protocol in
use. The current value is one (1). This field is treated as an
unsigned value.
バージョン(1つの八重奏)--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.
交換Type(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
6--予約された7がダウンロード10が13出発応答14出発Ack15を去るというAck12要求の誤り11不足を接合するよう要求する8の主要なダウンロード9クッキーを接合するよう要求する予約された0--3主要なダウンロードAck/失敗4Rekeyイベント5は私用193--255をIANA16--192まで予約しました。
Harney, et al. Standards Track [Page 49] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[49ページ]。
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つの八重奏)--Sequence IDは集団経営メッセージの反復操作による保護に使用されます。 メッセージが集団経営メッセージでないなら、(0)のゼロを合わせるようにこの値を設定しなければなりません。 (S)GC/カンザスによって使用された最初の値は1つ(1)でなければならない。 この(S)GC/カンザスが伝わるというそれぞれの異なった集団経営メッセージに関しては、この値を1つ(1)増加しなければなりません。 この集団経営メッセージの受信機は、対価領収にIDが最後の集団経営メッセージでこの(S)GC/カンザスから受け取った系列の値よりすばらしいと確認しなければなりません。 グループComponents(例えば、GM、S-GC/KSes)は0xFFFFFFFFのSequence 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つの八重奏)--八重奏における、総メッセージ(ヘッダー+ペイロード)の長さ。 この分野はネットワークバイトオーダーにおける符号のない整数として扱われます。
Harney, et al. Standards Track [Page 50] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[50ページ]。
7.1.1.1. GroupID Structure
7.1.1.1. GroupID構造
This section defines the formats for the defined GroupID types.
このセクションは定義されたGroupIDタイプのためにフォーマットを定義します。
7.1.1.1.1. UTF-8
7.1.1.1.1. UTF-8
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 無作為の値の~+++++++++++++++++++++++++++++++++~~; ストリング
Figure 4: GroupID UTF-8 Format
図4: GroupID UTF-8形式
Random Value (16 octets) - For the UTF-8 GroupID type, the Random
Value is represented as a string of exactly 16 hexadecimal digits
converted from its octet values in network-byte order. The
leading zero hexadecimal digits and the trailing zero hexadecimal
digits are always included in the string, rather than being
truncated.
UTF-8 GroupIDタイプのための無作為のValue(16の八重奏)、まさに16の16進数字のストリングがネットワークバイトオーダーにおける八重奏値から変えたので、Random Valueは表されます。 先行ゼロ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 String(可変長)--この分野はUTF-8形式にGroupIDの人間の読み込み可能な部分を含んでいます。 長さが計算される、(GroupID Length--16) Random Value分野に。 この分野への最小の長さは1(1)八重奏です。
Harney, et al. Standards Track [Page 51] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[51ページ]。
7.1.1.1.2. Octet String
7.1.1.1.2. 八重奏ストリング
The format for type Octet String is shown in Figure 5.
タイプOctet Stringのための書式は図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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Random Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Octet String ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GroupID Octet String Format
図5: GroupID八重奏記号列の書式
Random Value (8 octets) - The 8-octet unsigned random value in
network byte order format.
無作為のValue(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.
八重奏String(可変長)--この分野はGroupIDのOctet String部分を含んでいます。 長さが計算される、(GroupID Length--8) Random Value分野に。 この分野への最小の長さは1(1)八重奏です。
7.1.1.1.3. IPv4 Group Identifier
7.1.1.1.3. IPv4グループ識別子
The format for type IPv4 Group Identifier is shown in Figure 6.
タイプIPv4 Group Identifierのための書式は図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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Random Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IPv4 Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GroupID IPv4 Format
図6: GroupID IPv4形式
Random Value (8 octets) - The 8-octet unsigned random value in
network byte order format.
無作為のValue(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 Value(4つの八重奏)--ネットワークバイトオーダー形式におけるIPv4値。 この値はグループのマルチキャストアドレスを含むかもしれません。
Harney, et al. Standards Track [Page 52] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[52ページ]。
7.1.1.1.4. IPv6 Group Identifier
7.1.1.1.4. IPv6グループ識別子
The format for type IPv6 Group Identifier is shown in Figure 7.
タイプIPv6 Group Identifierのための書式は図7に示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Random Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv6 Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
無作為..値;
Figure 7: GroupID IPv6 Format
図7: GroupID IPv6形式
Random Value (8 octets) - The 8-octet unsigned random value in
network byte order format.
無作為のValue(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 Value(16の八重奏)--ネットワークバイトオーダー形式におけるIPv6値。 この値はグループのマルチキャストアドレスを含むかもしれません。
7.1.2. GSAKMP Header Processing
7.1.2. GSAKMPヘッダー処理
When processing the GSAKMP Header, the following fields MUST be checked for correct values:
GSAKMP Headerを処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
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 Type--Table11によって定義されるように有効なグループ識別ペイロードタイプになるようにGroup ID Type価値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
2. GroupID - The GroupID of the received message MUST be checked
against the valid GroupIDs of the Group Component. If no match
is found, then an error is logged; in addition, if in Verbose
Mode, an appropriate message containing notification value
Invalid-Group-ID will be sent.
2. GroupID--Group Componentの有効なGroupIDsに対して受信されたメッセージのGroupIDをチェックしなければなりません。 マッチが全く見つけられないなら、誤りは登録されます。 Verbose Modeでさらに、通知値のInvalidグループIDを含む適切なメッセージを送るでしょう。
Harney, et al. Standards Track [Page 53] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[53ページ]。
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. 次の有効搭載量--Table12によって定義されるように有効なペイロードタイプになるようにNext有効搭載量価値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Modeで通知値のInvalid有効搭載量タイプを含む適切なメッセージを送るなら。
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バージョン番号をチェックしなければなりません。それは指定されるとしてPolicy Tokenでグループの方針と一致しています。 バージョンがサポートもされませんし、認可もされないなら、誤りは登録されます。 Verbose Modeで通知値のInvalid-バージョンを含む適切なメッセージを送るなら。
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. 交換Type--Exchange TypeはTable13によって定義されるように有効な交換タイプになるようにチェックしなければならなくて、GSAKMP州のマシンによって受け取られると予想されたタイプにはあるに違いありません。 交換タイプが有効でないなら、誤りは登録されます。 Verbose Modeで通知値のInvalid交換タイプを含む適切なメッセージを送るなら。
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--正当性がないかどうかSequence ID価値をチェックしなければなりません。 交渉メッセージに関しては、この値は(0)であるはずがありません。 集団経営メッセージに、この値は最後の系列IDがこの(S)GC/カンザスから受信されたよりすばらしいに違いありません。 集団経営メッセージの不正確なSequence IDの領収書は生成するべき応答メッセージを引き起こしてはいけません。 非集団経営メッセージの不正確なSequence IDを受け取り次第、誤りは登録されます。 Verbose Modeで通知値のInvalid系列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 Header(グループIDのLengthとLength)の長さの分野は、メッセージを処理するのを助けるのに使用されます。 何か分野が不正確であることがわかっているなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
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.
Policy Tokenによって定義されるようにマルチversionedされたグループで作動している(S)GC/カンザスはrekeyメッセージのためにこのグループでどうGMと対話するかにおける多くのアプローチを取ることができます。
Harney, et al. Standards Track [Page 54] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[54ページ]。
One possible solution is for the (S-)GC/KS to send out multiple rekey messages, one per version level that it supports. Then each GM would only process the message that has the version at which it is operating.
1つの可能なソリューションは(S)GC/カンザスが複数のrekeyメッセージ、それがサポートするバージョンレベルあたり1つを出すことです。 そして、各GMはそれが作動しているバージョンを持っているメッセージを処理するだけでしょう。
An alternative approach that all GM v1 implementations MUST support is the embedding of a v1 message inside a version two (v2) message. If a GM running at v1 receives a GSAKMP message that has a version value greater than one (1), the GM will attempt to process the information immediately after the Group Header as a Group Header for v1 of the protocol. If this is in fact a v1 Group Header, then the remainder of this v1 message will be processed in place. After processing this v1 embedded message, the data following the v1 message should be the payload as identified by the Next Payload field in the original header of the message and will be ignored by the v1 member. However, if the payload following the initial header is not a v1 Group Header, then the GM will gracefully handle the unrecognized message.
すべてのGM v1実装がサポートしなければならない代替的アプローチはバージョンtwo(v2)メッセージにおけるv1メッセージの埋め込みです。 v1で経営しているGMがバージョンが1(1)を評価するGSAKMPメッセージを受け取ると、GMは、Group Header直後プロトコルのv1のためのGroup Headerとして情報を処理するのを試みるでしょう。 事実上、これがv1 Group Headerであるなら、このv1メッセージの残りは適所に処理されるでしょう。 処理の後にこのv1がメッセージを埋め込んで、v1メッセージに従うデータは、Next有効搭載量分野によって特定されるようにメッセージのオリジナルのヘッダーのペイロードであるべきであり、v1メンバーによって無視されるでしょう。 しかしながら、初期のヘッダーに続くペイロードがv1 Group Headerでないなら、GMは優雅に認識されていないメッセージを扱うでしょう。
7.2. Generic Payload Header
7.2. ジェネリック有効搭載量ヘッダー
7.2.1. Generic Payload Header Structure
7.2.1. ジェネリック有効搭載量ヘッダー構造
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で見せられたジェネリックヘッダーと共に始まります。 Generic有効搭載量Header分野は以下の通り定義されます:
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!ペイロード長を予約した、!+++++++++++++++++++++++++++++++++
Figure 8: Generic Payload Header
エイト環: ジェネリック有効搭載量ヘッダー
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.
有効搭載量Length(2つの八重奏)--ジェネリックペイロードヘッダーを含む現在のペイロードの八重奏における長さ。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
Harney, et al. Standards Track [Page 55] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[55ページ]。
7.2.2. Generic Payload Header Processing
7.2.2. ジェネリック有効搭載量ヘッダー処理
When processing the Generic Payload Header, the following fields MUST be checked for correct values:
Generic有効搭載量Headerを処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
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. 次の有効搭載量--Table12によって定義されるように有効なペイロードタイプになるようにNext有効搭載量価値をチェックしなければなりません。 ペイロードタイプが有効でないなら、誤りは登録されます。 Verbose Modeで通知値のInvalid有効搭載量タイプを含む適切なメッセージを送るなら。
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)であるなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
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.
Generic有効搭載量Headerの長さの分野は、ペイロードの残りを処理するのに使用されます。 この分野が不正確であることがわかっているなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
7.3. Policy Token Payload
7.3. 方針トークン有効搭載量
7.3.1. Policy Token Payload Structure
7.3.1. 方針トークン有効搭載量構造
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.
Policy Token有効搭載量はグループについて説明する認証可能グループ特有の情報のセキュリティ関連している振舞い、アクセス管理パラメータ、およびセキュリティー対策を含んでいます。図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:
Policy Token有効搭載量分野は以下の通り定義されます:
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はペイロードタイプを特定します。 この分野は未署名の値として扱われます。
Harney, et al. Standards Track [Page 56] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[56ページ]。
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.
有効搭載量Length(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.
方針Token Type(2つの八重奏)--使用されるPolicy Tokenのタイプを指定します。 テーブル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
GSAKMP MUSTの予約された0GSAKMP_ASN.1_PT_V1 1 All実装はこのPT形式をサポートします。 形式は[RFC4534]で指定しました。 IANA2--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.
方針Token Data(可変長)--Policy Token情報を含んでいます。 この分野への値はトークン特有です、そして、形式は太平洋標準時までに指定されます。Type分野。
If this payload is encrypted, only the Policy Token Data field is encrypted.
このペイロードが暗号化されているなら、Policy Token Data分野だけが暗号化されています。
The payload type for the Policy Token Payload is one (1).
Policy Token有効搭載量のためのペイロードタイプは1つ(1)です。
7.3.2. Policy Token Payload Processing
7.3.2. 方針トークン有効搭載量処理
When processing the Policy Token Payload, the following fields MUST be checked for correct values:
Policy Token有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション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. 方針Token Type--Table14によって定義されるように有効な方針トークンタイプになるようにPolicy Token Type値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Mode、適切なメッセージ含有で通知価値有効搭載量の奇形であるなら、送るでしょう。
Harney, et al. Standards Track [Page 57] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[57ページ]。
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. 方針Token Data--指定されたPolicy Token Typeによると、このPolicy Token Dataを処理しなければなりません。 タイプはデータの書式を定義するでしょう。
7.4. Key Download Payload
7.4. 主要なダウンロード有効搭載量
Refer to the terminology section for the different terms relating to keys used within this section.
このセクションの中で使用されたキーに関連して、異なった用語について用語部を参照してください。
7.4.1. Key Download Payload Structure
7.4.1. 主要なダウンロード有効搭載量構造
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.
Key Download有効搭載量はグループキー(例えば、グループキー、初期のrekeyキーなど)を含んでいます。 これらの主要なダウンロードペイロードで、いくつかのセキュリティー属性をそれらにグループの安全保障政策に基づいた状態で適用できます。 図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)で主要なダウンロードペイロードを暗号化しなければならないと決めます。 使用される暗号化メカニズムはPolicy Tokenで指定されます。 Key Creation有効搭載量で特定された主要な作成メソッドを使用して、グループのメンバーは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:
Key Download有効搭載量分野は以下の通り定義されます:
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.
有効搭載量Length(2つの八重奏)--ジェネリックペイロードヘッダーを含む現在のペイロードの八重奏における長さ。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
Harney, et al. Standards Track [Page 58] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[58ページ]。
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.
Items(2つの八重奏)の数--このデータ・ブロックで渡されるグループトラフィックの保護キーとRekey Arraysの総数を含んでいます。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
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.
主要なDownload Data Items(可変長)--Key Download情報を含んでいます。 Key Download DataはItemsのNumberに関するType/長さ/データの系列です。各個条のための書式は図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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++++++++++++++++++! KDD項目タイプ!が合わせる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はデータ項目の長さをダウンロードします! ~ データ..主要..ダウンロード..データ項目..主要..データ..配列
Figure 11: Key Download Data Item Format
図11: 主要なダウンロードデータ項目形式
For each Key Download Data Item, the data format is as follows:
各Key Download Data Itemに関しては、データの形式は以下の通りです:
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.
主要なDownload Data(KDD)項目Type(1つの八重奏)--このKey Download Data Itemに含まれたデータのタイプへの識別子。 この分野の可能な値に関してTable15を見てください。 この分野は未署名の値として扱われます。
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.
主要なDownload Data Item Length(2つの八重奏)--この野原に続くKey Download Data ItemのためのDataの八重奏における長さ。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
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.
Key Download Data Item(可変長)のためのデータ--キーズを含んで、情報について話しました。 Key Download Data Item Type分野の値によって、この分野の形式は特定です。 GTPKのKDD Item Typeに関しては、この分野はセクション7.4.1で.1に定義されるようにKey Datumを含むでしょう。 KDD Item Type Rekey--LKH、この分野はセクション7.4.1で.2を定義するので、Rekey Arrayを含むでしょう。
Harney, et al. Standards Track [Page 59] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[59ページ]。
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
GTPK0Thisタイプを実装しなければなりません。 このタイプは、データがグループトラフィック保護キー情報を含むのを特定します。 Rekey--、LKH1任意である、私用193--255をIANA2--192まで予約します。
The encryption of this payload only covers the data subsequent to the Generic Payload header (Number of Items and Key Download Data Items fields).
このペイロードの暗号化はGeneric有効搭載量ヘッダー(Itemsの数とKey Download Data Items分野)における、その後のデータをカバーするだけです。
The payload type for the Key Download Packet is two (2).
Key Download Packetのためのペイロードタイプは2(2)です。
Harney, et al. Standards Track [Page 60] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[60ページ]。
7.4.1.1. Key Datum Structure
7.4.1.1. 主要なデータ構造
A Key Datum contains all the information for a key. Figure 12 shows the format for this structure.
Key Datumはキーのためのすべての情報を含んでいます。 図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.
主要なType(2つの八重奏)--これは使用されているこの重要なデータがことである暗号アルゴリズムです。 この値はPolicy Tokenで指定されます。 この分野の可能な値に関してTable16を見てください。 この分野は未署名の値として扱われます。
Harney, et al. Standards Track [Page 61] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[61ページ]。
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
予約された0--2 3DES_CBC64_192 3は[RFC2451]を見ます。 _CBC_128 12Thisがタイプする予約された4--11AESをサポートしなければなりません。 [IKEv2]を見てください。 AES_CTR13は[IKEv2]を見ます。 IANA14--49152私用49153--65535に予約されます。
Key ID (4 octets) - This is the permanent ID of all versions of the
key. This value MAY be defined by the Policy Token. This field
is treated as an octet string.
主要なID(4つの八重奏)--これはキーのすべてのバージョンの永久的なIDです。 この値はPolicy Tokenによって定義されるかもしれません。 この分野は八重奏ストリングとして扱われます。
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.
主要なHandle(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].
主要なCreation Date(15の八重奏)--これはこの重要なデータが元々生成された時に関する時間的価値です。 この分野はUTF-8形式YYYYMMDDHHMMSSZにタイムスタンプを含んでいます、そして、MMは月(01--12)の数値です、そして、DDは月(01--31)の日です、そして、HHは日(00--23)の時間です、そして、時間(00--59)中にMMは分です、そして、分(00--59)中にSSは秒です、そして、文字Zはこれがズールー族の時間であることを示します。(そこでは、YYYYが年(0000--9999)です)。 この形式は緩く[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].
主要なExpiration Date(15の八重奏)--これは使用には、このキーがもう有効でない時に関する時間的価値です。 この分野はUTF-8形式YYYYMMDDHHMMSSZにタイムスタンプを含んでいます、そして、MMは月(01--12)の数値です、そして、DDは月(01--31)の日です、そして、HHは日(00--23)の時間です、そして、時間(00--59)中にMMは分です、そして、分(00--59)中にSSは秒です、そして、文字Zはこれがズールー族の時間であることを示します。(そこでは、YYYYが年(0000--9999)です)。 この形式は緩く[RFC3161]に基づいています。
Key Data (variable length) - This is the actual key data, which is
dependent on the Key Type algorithm for its format.
主要なData(可変長)--これは実際のキーデータです。(形式において、そのデータはKey Typeアルゴリズムに依存しています)。
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.
以下に注意してください。 Key IDとKey Handleの組み合わせはグループの中でユニークであるに違いありません。 この組み合わせは、唯一キーを特定するのに使用されるでしょう。
Harney, et al. Standards Track [Page 62] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[62ページ]。
7.4.1.2. Rekey Array Structure
7.4.1.2. Rekey配列構造
A Rekey Array contains the information for the set of KEKs that is associated with a Group Member. Figure 13 shows the format for this structure.
Rekey ArrayはGroupメンバーに関連しているKEKsのセットのための情報を含んでいます。 図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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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配列構造形式
Rekey Version (1 octet) - Contains the version of the Rekey protocol
in which the data is formatted. For Key Download Data Item Type
of Rekey - LKH, refer to Section A.2 for a description of this
value. This field is treated as an unsigned value.
Rekeyバージョン(1つの八重奏)--データがフォーマットされるRekeyプロトコルのバージョンを含んでいます。 RekeyのKey Download Data Item Type--LKH、この価値の記述についてセクションA.2を参照してください。 この分野は未署名の値として扱われます。
Member ID (4 octets) - This is the Member ID of the Rekey sequence
contained in this Rekey Array. This field is treated as an octet
string. For Key Download Data Item Type of Rekey - LKH, refer to
Section A.2 for a description of this value.
メンバーID(4つの八重奏)--これはこのRekey Arrayに含まれたRekey系列のメンバーIDです。 この分野は八重奏ストリングとして扱われます。 RekeyのKey Download Data Item Type--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.
主要なDatum(s)(可変長)--Key Datum形式における、KEKsの系列。 この系列の各Key Datumのための書式はセクション7.4.1で.1に定義されます。
Key ID (for Key ID within the Rekey) - LKH space, refer to Section
A.2 for a description of this value.
主要なID(Rekeyの中のKey IDへの)--LKHスペース、この価値の記述についてセクションA.2を参照してください。
7.4.2. Key Download Payload Processing
7.4.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:
Key Download有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
Harney, et al. Standards Track [Page 63] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[63ページ]。
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション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 Item Type--Table15によって定義されるように有効なKey Download Data ItemタイプになるようにすべてのKDD Item Type分野をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Mode、適切なメッセージ含有で通知価値有効搭載量の奇形であるなら、送るでしょう。
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. 主要なType--Table16によって定義されるように有効な暗号化タイプになるようにすべてのKey Type分野をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Modeで通知の値のInvalid主要な情報を含む適切なメッセージを送るなら。
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. Expiration Dateを合わせてください--すべてのKey Expiration Date分野をチェックしなければなりません。それらの値が未来とどんな過去の時間的価値も表さないと確認してください。 値が有効でないなら、誤りは登録されます。 Verbose Modeで通知値のInvalid重要情報を含む適切なメッセージを送るなら。
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.
ペイロードの長さとカウンタ分野は、ペイロードを処理するのを助けるのに使用されます。 何か分野が不正確であることがわかっているなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
7.5. Rekey Event Payload
7.5. Rekeyイベント有効搭載量
Refer to the terminology section for the different terms relating to keys used within this section.
このセクションの中で使用されたキーに関連して、異なった用語について用語部を参照してください。
7.5.1. Rekey Event Payload Structure
7.5.1. Rekeyイベント有効搭載量構造
The Rekey Event Payload MAY contain multiple keys encrypted in Wrapping KEKs. Figure 14 shows the format of the payload. If the data to be contained within a Rekey Event Payload is too large for the payload, the sequence can be split across multiple Rekey Event Payloads at a Rekey Event Data boundary.
Rekey Event有効搭載量はWrapping KEKsで暗号化された複数のキーを含むかもしれません。 図14はペイロードの書式を示しています。 ペイロードには、Rekey Event有効搭載量の中に含まれるべきデータが大き過ぎるなら、Rekey Event Data境界における複数のRekey Event有効搭載量の向こう側に系列を分けることができます。
Harney, et al. Standards Track [Page 64] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[64ページ]。
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
予約されました!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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!ペイロード長!+++++++++++++++++++++++++++++++++! RekeyEvntはタイプします! イベント..ヘッダー..イベント..データ
Figure 14: Rekey Event Payload Format
図14: Rekeyイベント有効搭載量形式
The Rekey Event Payload fields are defined as follows:
Rekey Event有効搭載量分野は以下の通り定義されます:
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.
有効搭載量Length(2つの八重奏)--ジェネリックペイロードヘッダーを含む現在のペイロードの八重奏における長さ。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
Rekey Event Type (1 octet) - Specifies the type of Rekey Event being
used. Table 17 presents the types of Rekey events. This field
is treated as an unsigned value.
Rekey Event Type(1つの八重奏)--使用されるRekey Eventのタイプを指定します。 テーブル17はRekeyイベントのタイプを提示します。 この分野は未署名の値として扱われます。
Rekey Event Header (variable length) - This is the header information
for the Rekey Event. The format for this is defined in Section
7.5.1.1, "Rekey Event Header Structure".
Rekey Event Header(可変長)--これはRekey Eventのためのヘッダー情報です。 これのための書式はセクション7.5で定義されます。.1 .1 「Rekeyイベントヘッダー構造。」
Rekey Event Data(s) (variable length) - This is the rekey information
for the Rekey Event. The format for this is defined in Section
7.5.1.2, "Rekey Event Data Structure".
Rekey Event Data(s)(可変長)--これはRekey Eventのためのrekey情報です。 これのための書式はセクション7.5で定義されます。.1 .2 「Rekeyイベントデータ構造。」
The Rekey Event payload type is three (3).
Rekey Eventペイロードタイプは3(3)です。
Harney, et al. Standards Track [Page 65] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[65ページ]。
Table 17: Rekey Event Types
テーブル17: Rekeyイベントタイプ
Rekey_Event_Type Value Definition/Defined In _____________________________________________________________________
Rekey_イベント_は/が定義した値の定義をタイプします。_____________________________________________________________________
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
0Thisがタイプしないなにも実装しなければなりません。 この場合、Rekey Event Data分野のサイズはどんなバイト長にもならないでしょう。 タイプNoneに従ったRekey Event有効搭載量の目的はrekey情報なしで新しいトークンを出すのが必要である時です。 GSAKMP rekey msgはRekey Event有効搭載量を必要とします、そして、この場合それには、タイプNoneに関するrekeyデータがあるでしょう。 rekeyデータがあるGSAKMP_LKH1はGSAKMPによると、フォーマットされたLKHをタイプします。 この分野への書式はセクション7.5.1で.2に定義されます。 IANA2--192私用193--255に予約されます。
7.5.1.1. Rekey Event Header Structure
7.5.1.1. Rekeyイベントヘッダー構造
The format for the Rekey Event Header is shown in Figure 15.
Rekey Event Headerのための書式は図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) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
グループ..ID..評価..グループ..ID..値..時間..日付..スタンプ;
Figure 15: Rekey Event Header Format
図15: Rekeyイベントヘッダー形式
Harney, et al. Standards Track [Page 66] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[66ページ]。
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".
グループIdentification Value(可変長)--「再-合わせ」られるためにグループの名前/タイトルを示します。 セクション7.1におけるGroup Identification Value、「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].
時間/日付Stamp(15の八重奏)--Rekey Event Dataが生成されたとき、これは時間的価値です。 この分野はUTF-8形式YYYYMMDDHHMMSSZにタイムスタンプを含んでいます、そして、MMは月(01--12)の数値です、そして、DDは月(01--31)の日です、そして、HHは日(00--23)の時間です、そして、時間(00--59)中にMMは分です、そして、分(00--59)中にSSは秒です、そして、文字Zはこれがズールー族の時間であることを示します。(そこでは、YYYYが年(0000--9999)です)。 この形式は緩く[RFC3161]に基づいています。
Rekey Event Type (1 octet) - This is the Rekey algorithm being used
for this group. The values for this field can be found in Table
17. This field is treated as an unsigned value.
Rekey Event Type(1つの八重奏)--これはこのグループに使用されるRekeyアルゴリズムです。 Table17でこの分野への値を見つけることができます。 この分野は未署名の値として扱われます。
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つの八重奏)--使用されるRekey Typeのバージョンを示します。 GSAKMP_LKHのRekey Event Typeに関しては、この価値の記述についてセクションA.2を参照してください。 この分野は未署名の値として扱われます。
# of Rekey Event Data(s) (2 octets) - The number of Rekey Event
Data(s) contained in the Rekey Data. This value is treated as an
unsigned integer in network byte order.
# Rekey Event Data(s)(2つの八重奏)--Rekey Dataに含まれたRekey Event Data(s)の数。 この値はネットワークバイトオーダーにおける符号のない整数として扱われます。
7.5.1.2. Rekey Event Data Structure
7.5.1.2. Rekeyイベントデータ構造
As defined in the Rekey Event Header, # of Rekey Data(s) field, multiple pieces of information are sent in a Rekey Event Data. Each end user, will be interested in only one Rekey Event Data among all of the information sent. Each Rekey Event Data will contain all the Key Packages that a user requires. For each Rekey Event Data, the data following the Wrapping fields is encrypted with the key identified in the Wrapping Header. Figure 16 shows the format of each Rekey Event Data.
#Rekey Event Headerで定義されるように、Rekey Data(s)分野では、Rekey Event Dataで情報の複数の断片を送ります。 それぞれのエンドユーザは情報のすべて中の1Rekey Event Dataだけに関心があるように送った状態でなるでしょう。 各Rekey Event Dataはユーザが必要とするすべてのKeyパッケージを含むでしょう。 各Rekey Event Dataに関しては、キーがWrapping Headerで特定されている状態で、Wrapping野原に続くデータは暗号化されます。 図16はそれぞれのRekey Event Dataの書式を示しています。
Harney, et al. Standards Track [Page 67] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[67ページ]。
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: Rekeyイベントデータの形式
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.
パケットLength(2つの八重奏)--Rekey Event Dataの八重奏における長さ。(Rekey Event DataはKeyパッケージとKeyパッケージの#、から成ります)。 この値はネットワークバイトオーダーにおける符号のない整数として扱われます。
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.
ラッピングKeyID(4つの八重奏)--これは新しい(「再-合わせ」られる)キーの暗号化/復号化に使用されているKEKのKey IDです。 RekeyのRekey Event Type--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.
ラッピングKey Handle(4つの八重奏)--これは新しい(「再-合わせ」られる)キーの暗号化/復号化に使用されているKEKのKey Handleです。 この値のための.1がさばくセクション7.4.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.
# Keyパッケージ(2つの八重奏)--このRekey Event Dataに含まれた主要なパッケージの数。 この値はネットワークバイトオーダーにおける符号のない整数として扱われます。
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.
主要なパッケージ(可変長)--Key Datumのタイプ/長さ/値の形式。 これのための書式はセクション7.5で定義されます。.1 .2 .1。
7.5.1.2.1. Key Package Structure
7.5.1.2.1. 主要なパッケージ構造
Each Key Package contains all the information about the key. Figure 17 shows the format for a Key Package.
それぞれのKeyパッケージはキーのすべての情報を含んでいます。 図17はKeyパッケージのために書式を示しています。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++++++++++++++++++! KeyPkgタイプ!はパッケージの長さを合わせます!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、データ~+++++++++++++++++++++++++++++++++を合わせてください。
Figure 17: Key Package Format
図17: 主要なパッケージ形式
Harney, et al. Standards Track [Page 68] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[68ページ]。
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.
主要なパッケージType(1つの八重奏)--この主要なパッケージの中のキーのタイプ。 Key Download Data Types、この分野への正当な値はTable15で定義されます。 この分野は未署名の値として扱われます。
Key Package Length (2 octets) - The length of the Key Datum. This
field is treated as an unsigned integer in network byte order
format.
主要なパッケージLength(2つの八重奏)--Key Datumの長さ。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
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".
主要なDatum(可変長)--キーの実際のデータ。 この分野への書式はセクション7.4で定義されます。.1 .1 「主要なデータ構造。」
7.5.2. Rekey Event Payload Processing
7.5.2. Rekeyイベント有効搭載量処理
When processing the Rekey Event Payload, the following fields MUST be checked for correct values:
Rekey Event有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション7.2.2、「ジェネリック有効搭載量ヘッダー処理」で定義されるように処理されます。
2. Rekey Event Type field within "Rekey Event" payload header - The
Rekey Event Type MUST be checked to be a valid rekey event type
as defined by Table 17. If the Rekey Event Type is not valid,
then regardless of mode (e.g., Terse or Verbose) an error is
logged. No response error message is generated for receipt of a
Group Management Message.
2. 「Rekeyイベント」ペイロードヘッダーの中のRekey Event Type分野--Table17によって定義されるように有効なrekeyイベントタイプになるようにRekey Event Typeをチェックしなければなりません。 Rekey Event Typeが有効でないなら、モード(例えば、TerseかVerbose)にかかわらず、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
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 Value--Group ComponentのGroupIDに対してRekey Event Headerの受信されたメッセージのGroup ID価値をチェックしなければなりません。 マッチが全く見つけられないなら、ペイロードが捨てられる、そして、モード(例えば、TerseかVerbose)にかかわらず、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
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. 日付/時間Stamp--Rekey Event HeaderのDate/時間Stamp価値は、Rekey Event世代時間がネットワーク遅延と処理時間に比例して最近かどうか決定するためにチェックされるかもしれません。 TimeStampが最近でないと判断されるなら、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
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
5. 「Rekeyイベントヘッダー」の中のRekey Event Type分野--有効なrekeyイベントタイプになるようにRekey Event Headerの受信されたメッセージのRekey Event Typeをチェックしなければなりません、このペイロードで、より早くTable17、およびRekey Event Typeの同じ値によって定義されるように。 にかかわらずその時、Rekey Event Typeの前の値には有効な同輩がRekey Event Typeであるならいない。
Harney, et al. Standards Track [Page 69] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[69ページ]。
mode (e.g., Terse or Verbose) an error is logged. No response
error message is generated for receipt of a Group Management
Message.
モード、(例えば、TerseかVerbose) 誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
6. Algorithm Version - The Rekey Algorithm Version number MUST be
checked to ensure that the version indicated is supported. If it
is not supported, then regardless of mode (e.g., Terse or
Verbose) an error is logged. No response error message is
generated for receipt of a Group Management Message.
6. アルゴリズムバージョン--示されたバージョンがサポートされるのを保証するためにRekey Algorithmバージョン番号をチェックしなければなりません。 それがサポートされないなら、モード(例えば、TerseかVerbose)にかかわらず、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
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は複数のRekey Event Datasが可能性ですが、このGMのためにメソッドが使用したあるrekeyに基づいているようにすべてのRekey Event Datasを処理しなければなりません。 すべてのRekey Event Datasが消費されるまで、Rekey Event Datasは整然とした状態で処理されます。
1. Wrapping KeyID - The Wrapping KeyID MUST be checked against the
list of stored KEKs that this GM holds. If a match is found,
then continue processing this Rekey Event Data. Otherwise, skip
to the next Rekey Event Data.
1. ラッピングKeyID--このGMが持っている保存されたKEKsのリストに対してWrapping KeyIDをチェックしなければなりません。 マッチが見つけられるなら、このRekey Event Dataを処理し続けてください。 さもなければ、次のRekey Event Dataまでスキップしてください。
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. ラッピングHandle--合っているWrapping KeyIDが見つけられたなら、KeyIDがマッチであったKEKのハンドルに対してWrapping Handleをチェックしなければなりません。 ハンドルが合っていると、GMはこのRekey Event Dataに関連しているKeyパッケージを処理するでしょう。 さもなければ、次のRekey Event Dataまでスキップしてください。
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が合っているWrapping KeyIDとWrapping Handleを見つけたなら、GMは、方針使用に従ったこのRekey Event Dataの残っているデータがWrapping KeyIDとHandleによって定義されたKEKであると解読します。 データを解読した後に、GMは、その後のKeyパッケージを処理するのを助けるためにKeyパッケージ分野の#、を抽出します。 Keyパッケージは以下の通り処理されます:
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. 主要なパッケージType--Table15によって定義されるように有効な主要なパッケージ型式になるようにKeyパッケージTypeをチェックしなければなりません。 KeyパッケージTypeが有効でないなら、モード(例えば、TerseかVerbose)にかかわらず、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
2. Key Package Length - The Key Package Length is used to process
the subsequent Key Datum information.
2. 主要なパッケージLength--KeyパッケージLengthは、その後のKey Datum情報を処理するのに使用されます。
Harney, et al. Standards Track [Page 70] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[70ページ]。
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. 主要なType--Table16によって定義されるように有効な主要なタイプになるようにKey Typeをチェックしなければなりません。 KeyパッケージTypeが有効でないなら、モード(例えば、TerseかVerbose)にかかわらず、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
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--このユーザがこのKey Typeのために維持するKey IDのセットに対してKey IDをチェックしなければなりません。 マッチが全く見つけられないなら、モード(例えば、TerseかVerbose)にかかわらず、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
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. 主要なHandle--Key Handleはそのままで抽出されて、現在KeyパッケージのKey IDに関連しているKeyのための新しいKey Handleであることで使用されています。
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. Creation Dateを合わせてください--Key Creation Dateをチェックしなければなりません。現在主要に保たれるのにおいて、それはKey Creation Dateにその後です。 この日付が現在開催されたキーの前にあるなら、モード(例えば、TerseかVerbose)にかかわらず、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
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. Expiration Dateを合わせてください--Key Expiration Dateをチェックしなければなりません。それはただ受け取られたKey Creation Dateにその後です、そして、時間規則は方針に従います。 有効期限が作成日付にその後でない、または方針に従わないなら、モード(例えば、TerseかVerbose)にかかわらず、誤りは登録されます。 応答エラーメッセージは全くGroup Management Messageの領収書のために生成されません。
8. Key Data - The Key Data is extracted based on the length
information in the key package.
8. 主要なData--Key Dataは主要なパッケージの中の長さの情報に基づいて抽出されます。
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.
Keyパッケージを処理するとき、誤りが全くなかったなら、KeyIDによって表されたキーで、受信された情報に基づいた状態でデータのすべてをアップデートするでしょう。
7.6. Identification Payload
7.6. 識別有効搭載量
7.6.1. Identification Payload Structure
7.6.1. 識別有効搭載量構造
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.
Identification有効搭載量は識別情報を交換するのに使用される実体特有のデータを含んでいます。 この情報は、メンバーのアイデンティティについて確かめるのに使用されます。 図18はIdentification有効搭載量の書式を示しています。
Harney, et al. Standards Track [Page 71] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[71ページ]。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
次..有効搭載量..予約..ペイロード長..ID..ID..タイプ..識別情報
Figure 18: Identification Payload Format
図18: 識別有効搭載量形式
The Identification Payload fields are defined as follows:
Identification有効搭載量分野は以下の通り定義されます:
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.
有効搭載量Length(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つの八重奏)--Identification Dataの所有権を分類します。 テーブル18はこの分野に可能な値を特定します。 この分野は未署名の値として扱われます。
Table 18: Identification Classification
テーブル18: 識別分類
ID_Classification Value
_______________________________
ID_分類値_______________________________
Sender 0
Receiver 1
Third Party 2
Reserved to IANA 3 - 192
Private Use 193 - 255
送付者0受信機1第三者2は私用193--255をIANA3--192まで予約しました。
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つの八重奏)--使用されるIdentificationのタイプを指定します。 テーブル19はこのタイプのために可能な値を特定します。 この分野は未署名の値として扱われます。 別の方法で述べられない場合、すべての定義されたタイプがOPTIONALです。
Harney, et al. Standards Track [Page 72] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[72ページ]。
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.
識別Data(可変長)--アイデンティティ情報を含んでいます。 この分野への値はグループ特有です、そして、形式はID Type分野によって指定されます。 この分野への書式はTable19のタイプに関連して述べられています。
The payload type for the Identification Payload is four (4).
Identification有効搭載量のためのペイロードタイプは4(4)です。
Table 19: Identification Types
テーブル19: 識別タイプ
ID_Type Value PKIX Cert Description
Field Defined In
_____________________________________________________________________
ID_はPKIX本命記述分野が定義した値をタイプします。_____________________________________________________________________
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_IPV4ADDR1SubjAltNameは[IKEv2]iPAddress部3.5を見ます。 ID_FQDN2SubjAltNameは[IKEv2]dNSName部3.5を見ます。 ID_RFC822_ADDR3SubjAltNameは[IKEv2]rfc822Name部3.5を見ます。 予約された4_ID_IPV6ADDR5SubjAltNameは[IKEv2]iPAddress部3.5を見ます。 予約された6--8 See[IKEv2]bitwise Compareセクション3.5にID_DER_ASN1_DN9Entire Subject。 予約された10ID_主要な_ID11、なし、[IKEv2]が12--29部3.5を予約したのを確実にしてください。 暗号化されていないName30Subject、この(_ID_U NAME)タイプのための書式はセクション7.6.1で.1に定義されます。 DN_ストリング31がかけるID_は[RFC4514]を見ます。 このタイプを実装しなければなりません。 IANA32--192私用193--255に予約されます。
Harney, et al. Standards Track [Page 73] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[73ページ]。
7.6.1.1. ID_U_NAME Structure
7.6.1.1. ID_U_名前構造
The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19.
タイプUnencoded Name(_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名)形式
Serial Number (20 octets) - The certificate serial number. This
field is treated as an unsigned integer in network byte order
format.
連続のNumber(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 Data分野の八重奏における長さ。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
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 Data(可変長)、実際のUTF-8 DN値(対象の分野)がフイールド・デリミタにスラッシュ(/)キャラクタを使用する、(」 例えば、/Cが/o=頂上Inc./OU=DIV1/CN=user1/メールが user1@acme.com と等しいところで米国/=MD/第L=と等しい、」、周囲の引用文)
7.6.2. Identification Payload Processing
7.6.2. 識別有効搭載量処理
When processing the Identification Payload, the following fields MUST be checked for correct values:
Identification有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション7.2.2、「ジェネリック有効搭載量ヘッダー処理」で定義されるように処理されます。
Harney, et al. Standards Track [Page 74] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[74ページ]。
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. 識別Classification--Table18によって定義されるように有効な識別分類タイプになるようにIdentification Classification値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
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. 識別Type--Table19によって定義されるように有効な識別タイプになるようにIdentification Type値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
4. Identification Data - This Identification Data MUST be processed
according to the identification type specified. The type will
define the format of the data. If the identification data is
being used to find a match and no match is found, then an error
is logged. If in Verbose Mode, an appropriate message containing
notification value Invalid-ID-Information will be sent.
4. 識別Data--タイプが指定した識別に従って、このIdentification Dataを処理しなければなりません。 タイプはデータの書式を定義するでしょう。 識別情報がマッチを見つけるのに使用されていて、マッチが全く見つけられないなら、誤りは登録されます。 Verbose Modeで通知値のInvalid ID情報を含む適切なメッセージを送るなら。
7.6.2.1. ID_U_NAME Processing
7.6.2.1. ID_U_名前処理
When processing the Identification Data of type ID_U_NAME, the following fields MUST be checked for correct values:
_タイプID U_NAMEのIdentification Dataを処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
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. 連続のNumber--通し番号は、従うカリフォルニア[RFC3280]からの有効な通し番号であるためには1(1)でなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
2. DN Data - The DN data is processed as a UTF-8 string.
2. DN Data--DNデータはUTF-8ストリングとして処理されます。
3. The CA MUST be a valid trusted policy creation authority as
defined by the Policy Token.
3. Policy Tokenによって定義されるようにカリフォルニアは有効な信じられた方針作成権威であるに違いありません。
These 2 pieces of information, Serial Number and DN Data, in conjunction, will then be used for party identification. These values are also used to help identify the certificate when necessary.
そして、2つの情報(接続詞のSerial NumberとDN Data)が、政党帰属意識に使用されるでしょう。 また、これらの値は、必要であるときに、証明書を特定するのを助けるのに使用されます。
7.7. Certificate Payload
7.7. 証明書有効搭載量
7.7.1. Certificate Payload Structure
7.7.1. 証明書有効搭載量構造
The Certificate Payload provides a means to transport certificates or other certificate-related information via GSAKMP and can appear in any GSAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g., LDAP [RFC4523]) is not available to distribute certificates. Multiple
Certificate有効搭載量は、GSAKMPを通して証明書を輸送する手段か他の証明書関連の情報を提供して、どんなGSAKMPメッセージにも現れることができます。 含まれていて、適切なディレクトリサービス(例えば、LDAP[RFC4523])が証明書を配布するために利用可能でないときはいつも、交換でペイロードSHOULDを証明してください。 倍数
Harney, et al. Standards Track [Page 75] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[75ページ]。
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 MUSTは検証目的のための証明書を検索するためにある他のメカニズムを当てにします。 図20はCertificate有効搭載量の書式を示しています。
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:
Certificate有効搭載量分野は以下の通り定義されます:
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.
有効搭載量Length(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.
証明書Type(2つの八重奏)--この分野は証明書かCertificate Data分野に保管されていた証明書関連の情報のタイプを示します。 テーブル20は証明書ペイロードのタイプを提示します。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
Certificate Data (variable length) - Actual encoding of certificate
data. The type of certificate is indicated by the Certificate
Type/Encoding field.
Data(可変長)を証明してください--証明書データの実際のコード化。 証明書のタイプはCertificate Type/コード化分野によって示されます。
The payload type for the Certificate Payload is six (6).
Certificate有効搭載量のためのペイロードタイプは6(6)です。
Harney, et al. Standards Track [Page 76] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[76ページ]。
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
0Reserved1--Thisがあるに違いないのをタイプする3X.509v3 Certificate4--署名が実装しなかったなにも。 -- DER Encoding Contains a DERはX.509証明書をコード化しました。 予約された5--6Certificate Revocation List7Contains a BER(CRL)はX.509 CRLをコード化しました。 X.509証明書10が見る8--予約された9[IKEv2]、秒3.6。 -- 主要な11が見る生のRSA[IKEv2]、秒3.6を結果と考えてください。 12が見るX.509[IKEv2]、秒3.6のハッシュとURL。 X.509 13See[IKEv2]のHashとURLを証明してください、IANA14 -- 49152兵士のUse49153 -- 65535へのSec3.6バンドルReserved
7.7.2. Certificate Payload Processing
7.7.2. 証明書有効搭載量処理
When processing the Certificate Payload, the following fields MUST be checked for correct values:
Certificate有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション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. 証明書Type--Table20によって定義されるように有効な証明書タイプになるようにCertificate Type値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 通知値のCert-タイプVerbose Mode、適切なメッセージ含有でサポートされないなら、送るでしょう。
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
3. 証明書Data--タイプが指定した証明書によると、このCertificate Dataを処理しなければなりません。 タイプはデータの書式を定義するでしょう。 Certificateペイロード原因における信じられた方針作成権威の証明書の領収書
Harney, et al. Standards Track [Page 77] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[77ページ]。
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.
捨てられるべきペイロード。 メッセージについて確かめるのにこの受け取られていている証明書を使用してはいけません。 他の手段で信じられた方針作成権威の証明書を検索しなければなりません。
7.8. Signature Payload
7.8. 署名有効搭載量
7.8.1. Signature Payload Structure
7.8.1. 署名有効搭載量構造
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.
Signature有効搭載量はデジタル署名機能によって生成されたデータを含んでいます。 それぞれのメッセージの解剖で定義されるデジタル署名はGSAKMP Message Headerから上がっていますが、Signature Data Lengthを含んでいないSignature有効搭載量までメッセージをカバーしています。 図21はSignature有効搭載量の書式を示しています。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
Signature有効搭載量分野は以下の通り定義されます:
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にセットしてください。
Harney, et al. Standards Track [Page 78] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[78ページ]。
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.
有効搭載量Length(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.
署名Type(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
0ThisがタイプするASN.1/DERコード化があるDSS/SHA1をサポートしなければなりません(DSS-SHA1-ASN1-DER)。 RSA1024-MD5 1は[RFC3447]を見ます。 ECDSA-P384-SHA3 2は[FIPS186-2]を見ます。 IANA3--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 Type(1つの八重奏)--Signature ID Dataのために書式を示します。 これらの値はものがIdentification有効搭載量Identificationのために、タイプ(Table19で見つけることができる)を定義したのと同じです。 この分野は未署名の値として扱われます。
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].
署名Timestamp(15の八重奏)--デジタル署名が適用されたとき、これは時間的価値です。 この分野はUTF-8形式YYYYMMDDHHMMSSZにタイムスタンプを含んでいます、そして、MMは月(01--12)の数値です、そして、DDは月(01--31)の日です、そして、HHは日(00--23)の時間です、そして、時間(00--59)中にMMは分です、そして、分(00--59)中にSSは秒です、そして、文字Zはこれがズールー族の時間であることを示します。(そこでは、YYYYが年(0000--9999)です)。 この形式は緩く[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 Length(2つの八重奏)--Signerの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 Data(可変長)--SignerのID(例えば、DN)を特定するデータ。 この分野への書式は、Signature ID Type分野に基づいていて、そのタイプがどこで定義されるかが案内されます。 グループの文脈の中でSignerの権威とアクセスを決定するためにPolicy Tokenに対してこの分野のコンテンツをチェックしなければなりません。
Harney, et al. Standards Track [Page 79] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[79ページ]。
Signature Length (2 octets) - Length in octets of the Signature Data.
This field is treated as an unsigned integer in network byte
order format.
署名Length(2つの八重奏)--Signature Dataの八重奏における長さ。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
Signature Data (variable length) - Data that results from applying
the digital signature function to the GSAKMP message and/or
payload.
署名Data(可変長)--それがデジタル署名を適用しながら生じるデータはGSAKMPメッセージ、そして/または、ペイロードに機能します。
The payload type for the Signature Payload is eight (8).
Signature有効搭載量のためのペイロードタイプは8(8)です。
7.8.2. Signature Payload Processing
7.8.2. 署名有効搭載量処理
When processing the Signature Payload, the following fields MUST be checked for correct values:
Signature有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション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. 署名Type--Table21によって定義されるように有効な署名タイプになるようにSignature Type値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Mode、適切なメッセージ含有で通知価値有効搭載量の奇形であるなら、送るでしょう。
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 Type--Table19によって定義されるように有効な署名IDタイプになるようにSignature ID Type価値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Mode、適切なメッセージ含有で通知価値有効搭載量の奇形であるなら、送るでしょう。
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. 署名Timestamp--この分野は、トランザクション署名時間が予想されたネットワーク遅延に比例して新鮮であるかどうか決定するためにチェックされるかもしれません。 イベントの格納された系列が望まれているシステムに、そのようなチェックは適切です。
NOTE: The maximum acceptable age of a signature timestamp
relative to the local system clock is a locally configured
parameter that can be tuned by its GSAKMP management interface.
以下に注意してください。 ローカルシステム時計に比例した署名タイムスタンプの最大の許容できる時代はGSAKMP管理インタフェースで調整できる局所的に構成されたパラメタです。
5. Signature ID Data - This field will be used to identify the
sending party. This information MUST then be used to confirm
that the correct party sent this information. This field is also
used to retrieve the appropriate public key of the certificate to
verify the message.
5. 署名ID Data--この分野は、送付パーティーを特定するのに使用されるでしょう。 そして、正しいパーティーがこの情報を送ったと確認するのにこの情報を使用しなければなりません。 また、この分野は、メッセージについて確かめるために証明書の適切な公開鍵を検索するのに使用されます。
Harney, et al. Standards Track [Page 80] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[80ページ]。
6. Signature Data - This value MUST be compared to the recomputed
signature to verify the message. Information on how to verify
certificates used to ascertain the validity of the signature can
be found in [RFC3280]. Only after the certificate identified by
the Signature ID Data is verified can the signature be computed
to compare to the signature data for signature verification. A
potential error that can occur during signature verification is
Authentication-Failed. Potential errors that can occur while
processing certificates for signature verification are: Invalid-
Certificate, Invalid-Cert-Authority, Cert-Type-Unsupported, and
Certificate-Unavailable.
6. 署名Data--メッセージについて確かめるためにこの値を再計算された署名にたとえなければなりません。 どう証明書について確かめるかに関する情報は、以前はよく[RFC3280]で署名の正当性を見つけることができるのを確かめていました。 Signature ID Dataによって特定された証明書が確かめられた後にだけ署名照合のための署名データと比較するために署名を計算できます。 署名照合の間に発生できる潜在的誤りはAuthenticationによって失敗されています。 署名照合のための証明書を処理している間に発生できる潜在的誤りは以下の通りです。 無効の証明書、本命がサポートされない状態でタイプしていて、証明書入手できない無効の本命権威。
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.
Signature有効搭載量における長さの分野は、ペイロードの残りを処理するのに使用されます。 何か分野が不正確であることがわかっているなら、終了処理を開始しなければなりません。
7.9. Notification Payload
7.9. 通知有効搭載量
7.9.1. Notification Payload Structure
7.9.1. 通知有効搭載量構造
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.
Notification有効搭載量は、GSAKMPとグループ特有のデータの両方を含むことができて、情報のデータを送るのに使用されます、エラー条件などのように、GSAKMP同輩に。 ただ一つのGSAKMPメッセージで複数の独立しているNotificationペイロードを送るのは可能です。 図22はNotification有効搭載量の書式を示しています。
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:
Notification有効搭載量分野は以下の通り定義されます:
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にセットしてください。
Harney, et al. Standards Track [Page 81] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[81ページ]。
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.
有効搭載量Length(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.
通知Type(2つの八重奏)--通知メッセージのタイプを指定します。 テーブル22はNotify有効搭載量Typesを寄贈します。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
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.
通知Data(可変長)--情報か誤りデータはNotify有効搭載量Typeに加えて送られました。 この分野への値はInterpretation(DOI)特有のDomainです。
The payload type for the Notification Payload is nine (9).
Notification有効搭載量のためのペイロードタイプは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
なにもに、1が予約した0の無効の有効搭載量タイプ2--4の5の6の有効搭載量奇形の7 8無効のID情報無効のグループID無効のSequence ID無効の主要な情報9が予約した3の無効のバージョン10--11 13が認証して失敗した本命がサポートされない状態でタイプしている12無効の本命権威14は15を予約しました; - 16 証明書入手できない予約された17の18権限のない要求19予約された20--22承認23予約された24--25ナック26クッキーで必要な27Cookie28メカニズム選択29は誤り32の無効の交換タイプ33IPv4価値34を去るという出発の受け入れられた31要求にグループ30を出ます。
Harney, et al. Standards Track [Page 82] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[82ページ]。
IPv6 Value 35
Prohibited by Group Policy 36
Prohibited by Locally Configured Policy 37
Reserved to IANA 38 - 49152
Private Use 49153 -- 65535
局所的に構成された方針37で禁止されたグループ方針36で禁止されたIPv6値35は私用49153 -- 65535をIANA38--49152まで予約しました。
7.9.1.1. Notification Data - Acknowledgement (ACK) Payload Type
7.9.1.1. 通知データ--承認(ACK)有効搭載量タイプ
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のNotificationペイロードのデータ部は、Key Downloadメッセージの正しい領収書の確認として機能するか、または必要であると、署名しているメッセージに含まれていると、他の領収書情報を提供します。 図23はNotification Dataの書式を示しています--有効搭載量Typeを承認してください。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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タイプ!承認データ~+++++++++++++++++++++++++++++++++
Figure 23: Notification Data - Acknowledge Payload Type Format
図23: 通知データ--有効搭載量タイプ形式を承認してください。
The Notification Data - Acknowledgement Payload Type data fields are defined as follows:
Notification Data--承認有効搭載量Typeデータ・フィールドは以下の通り定義されます:
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 Type(1つの八重奏)--承認のタイプを指定します。 テーブル23はNotify Acknowledgement有効搭載量Typesを寄贈します。 この分野は未署名の値として扱われます。
Table 23: Acknowledgement Types
テーブル23: 承認タイプ
ACK_Type Value Definition
_____________________________________________________
ACK_タイプ値の定義_____________________________________________________
Simple 0 Data portion null.
Reserved to IANA 1 - 192
Private Use 193 - 255
簡単な0Data部分ヌル。 IANA1--192私用193--255に予約されます。
7.9.1.2. Notification Data - Cookie_Required and Cookie Payload Type
7.9.1.2. 通知データ--_が必要としたクッキーとクッキー有効搭載量タイプ
The data portion of the Notification payload of types Cookie_Required and Cookie contain the Cookie value. The value for this field will have been computed by the responder GC/KS and sent to the GM. The GM will take the value received and copy it into the Notification payload Notification Data field of type Cookie that is transmitted in the "Request to Join with Cookie Info" back to the GC/KS. The cookie value MUST NOT be modified.
タイプのCookie_RequiredとCookieのNotificationペイロードのデータ部はCookie値を含んでいます。 この分野への値を応答者GC/カンザスが計算して、GMに送ってしまうでしょう。 GMは、対価領収を取って、「クッキーインフォメーションと一緒になるという要求」でGC/カンザスに送って戻されるタイプCookieのNotificationペイロードNotification Data分野にそれをコピーするでしょう。 クッキー値を変更してはいけません。
Harney, et al. Standards Track [Page 83] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[83ページ]。
The format for this is already described in the discussion on cookies in Section 5.2.2.
これのための形式はセクション5.2.2で既にクッキーについての議論で説明されます。
7.9.1.3. Notification Data - Mechanism Choices Payload Type
7.9.1.3. 通知データ--メカニズム選択有効搭載量タイプ
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.
タイプMechanism ChoicesのNotificationペイロードのデータ部はGMがGC/カンザスとの交渉の使用に要求しているメカニズムを含んでいます。 この情報はRTJメッセージでGMによって提供されるでしょう。 図24はNotification Dataの書式を示しています--メカニズムChoices有効搭載量Type。 複数のタイプ|長さ|データ選択は、ユーザが1Notificationの有効搭載量の中ですべての関連情報を伝えるのを許容するために1個の通知ペイロードで糸でとめ合わせられます。 ペイロードの長さはNotification Data Mechanism Choices分野の構文解析を制御するでしょう。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..
+++++++++++++++++++++++++++++++++! Mechはメカニズム選択をタイプします。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、データ!+++++++++++++++++++++++++++++++++。
Figure 24: Notification Data - Mechanism Choices Payload Type Format
図24: 通知データ--メカニズム選択有効搭載量は書式をタイプします。
The Notification Data - Mechanism Choices Payload Type data fields are defined as follows:
Notification Data--メカニズムChoices有効搭載量Typeデータ・フィールドは以下の通り定義されます:
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.
メカニズムType(1つの八重奏)--メカニズムのタイプを指定します。 テーブル24はNotify Mechanism Choices Mechanism Typesを寄贈します。 この分野は未署名の値として扱われます。
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テーブル25は私用193--255をIANA3--192まで予約しました。
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.
メカニズムChoice Data(2つの八重奏)--選ばれるメカニズムタイプのためのデータ値。 値はMechanism Typeが定義したそれぞれに特定です。 ほかの場所(この仕様か他のもので)で定義されない値を定義するのに必要なすべてのテーブルがここで定義されます。 この分野はネットワークバイトオーダー形式における符号のない整数として扱われます。
Harney, et al. Standards Track [Page 84] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[84ページ]。
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 1 Thisが、タイプする。 IANA2--49152私用49153--65535に予約されます。
7.9.1.4. Notification Data - IPv4 and IPv6 Value Payload Types
7.9.1.4. 通知データ--IPv4とIPv6値の有効搭載量タイプ
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価値のNotificationペイロードのデータ部はネットワークバイトオーダーにおける適切なIP値を含んでいます。 この値はメッセージの受信機によって消費へのメッセージのクリエイターによって設定されるでしょう。
7.9.2. Notification Payload Processing
7.9.2. 通知有効搭載量処理
When processing the Notification Payload, the following fields MUST be checked for correct values:
Notification有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション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. 通知Type--Table22によって定義されるように通知タイプになるようにNotificationタイプ価値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Mode、適切なメッセージ含有で通知価値有効搭載量の奇形であるなら、送るでしょう。
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. 通知Data--タイプが指定した通知によると、このNotification Dataを処理しなければなりません。 タイプはデータの書式を定義するでしょう。 このデータを処理するとき、正しい値がないかどうか適切なテーブルに対してどんなタイプ分野もチェックしなければなりません。 Notification Dataの内容が有効でないなら、誤りは登録されます。 Verbose Mode、適切なメッセージ含有で通知価値有効搭載量の奇形であるなら、送るでしょう。
Harney, et al. Standards Track [Page 85] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[85ページ]。
7.10. Vendor ID Payload
7.10. ベンダーID有効搭載量
7.10.1. Vendor ID Payload Structure
7.10.1. ベンダーID有効搭載量構造
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.
Vendor ID有効搭載量はベンダーによって定義された定数を含んでいます。 定数は、それらの実装のリモートインスタンスを特定して、認識するのにベンダーによって使用されます。 このメカニズムで、ベンダーは後方に互換性を維持している間、新機能を実験できます。 図25はペイロードの書式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Vendor ID (VID) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
次..有効搭載量..予約..ペイロード長..ベンダー..ID
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.
Vendor IDペイロードが、送付者が、ある拡大をプロトコルに受け入れることができると発表するかもしれませんか、またはそれは、実装がデバッグで援助であると単に認識するかもしれません。 Vendor IDペイロードはこの仕様に基づき定義されたどんな情報の解釈も変えてはいけません。 複数のVendor IDペイロードを送るかもしれません。 実装は全くどんなVendor IDペイロードも送るNOT REQUIREDです。
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.
どんなメッセージの一部としてもVendor IDペイロードを送るかもしれません。 身近なVendor IDペイロードの領収書で、実装はこの仕様中で説明された兵士のUse番号を利用できます--個人的なペイロード、私設交換機、個人的な通知など これは、すべてのペイロードのために定義されたすべての処理規則が現在このVendor IDによってすべてのペイロードのすべての分野と定義されたすべての値を認識するように変更されるのを含意します。 なじみのないVendor 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.
このプロトコルを広げたがっているインターネット草稿の作家は、インターネット草稿における拡大を実装する能力を発表するためにVendor IDペイロードを定義しなければなりません。 承認を獲得して、標準化されるインターネット草稿がReservedから割り当てられた値が与えることのようにIANA範囲になると予想されて、Vendor IDペイロードを使用するという要件は遠ざかるでしょう。
The Vendor ID payload fields are defined as follows:
Vendor IDペイロード分野は以下の通り定義されます:
Harney, et al. Standards Track [Page 86] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[86ページ]。
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.
有効搭載量Length(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(可変長)--Vendor ID価値。 この分野への最小の長さは4(4)八重奏です。 IDのためにどんな中央の登録も不在にもかかわらず、ユニークさに保証するのは、人がVendor IDを選ぶ責任です。 良い習慣は会社名、人の名、または同様のタイプデータを含むことになっています。 長いユニークなストリングのメッセージダイジェストは長いユニークなストリング自体より望ましいです。
The payload type for the Vendor ID Payload is ten (10).
Vendor ID有効搭載量のためのペイロードタイプは10(10)です。
7.10.2. Vendor ID Payload Processing
7.10.2. ベンダーID有効搭載量処理
When processing the Vendor ID Payload, the following fields MUST be checked for correct values:
Vendor ID有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション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--Vendor ID価値が実装によって認識されるかどうか決定するためにVendor ID Dataを処理しなければなりません。 Vendor ID価値が認識されないなら、モード(例えば、TerseかVerbose)にかかわらず、この情報は登録されます。 メッセージの処理はこの価値の認識にかかわらず続かなければなりません。
It is recommended that implementations that want to use Vendor-ID- specific information attempt to process the Vendor ID payloads of an incoming message prior to the remainder of the message processing. This will allow the implementation to recognize that when processing other payloads it can use the larger set of values for payload fields (Private Use values, etc.) as defined by the recognized Vendor IDs.
Vendor-ID特殊情報を使用したがっている実装が、メッセージ処理の残りの前に入力メッセージのVendor IDペイロードを処理するのを試みるのは、お勧めです。 これは、他のペイロードを処理するとき、ペイロード分野(個人的なUse値など)に認識されたVendor IDによって定義されるように、より大きい値を使用できると認めるために実装を許容するでしょう。
Harney, et al. Standards Track [Page 87] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[87ページ]。
7.11. Key Creation Payload
7.11. 主要な作成有効搭載量
7.11.1. Key Creation Payload Structure
7.11.1. 主要な作成有効搭載量構造
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.
Key Creation有効搭載量は主要な暗号化キーを作成するのに使用される情報を含んでいます。 このペイロードのためのセキュリティー属性をPolicy Tokenに提供します。 図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:
Key Creation有効搭載量分野は以下の通り定義されます:
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.
有効搭載量Length(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.
主要なCreation Type(2つの八重奏)--使用されるKey Creationのタイプを指定します。 テーブル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.
主要なCreation Data(可変長)--Key Creation情報を含んでいます。 この分野への値はグループ特有です、そして、形式は主要な作成タイプ分野によって指定されます。
The payload type for the Key Creation Packet is eleven (11).
Key Creation Packetのためのペイロードタイプは11(11)です。
Harney, et al. Standards Track [Page 88] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[88ページ]。
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
ディフィー-ヘルマン2Thisがタイプする0--予約された1をサポートしなければなりません。 1024年のビットのMODPグループは[IKEv2]でB.2を定義しました。 端が欠けているIf、プロセスの出力は定義されたメカニズムに必要とされるより長く、最初Xの下位のビットを使用してください、そして、残りに先端を切らせてください。 ディフィー-ヘルマン14が[RFC3526]で定義した3--予約された13。 2048年のビットのMODP Group If、加工処理したTruncatedの出力は定義されたメカニズムに必要とされるより長く、最初Xの下位のビットを使用してください、そして、残りに先端を切らせてください。 IANA15--49152私用49153--65535に予約されます。
7.11.2. Key Creation Payload Processing
7.11.2. 主要な作成有効搭載量処理
The specifics of the Key Creation Payload are defined in Section 7.11.
Key Creation有効搭載量の詳細はセクション7.11で定義されます。
When processing the Key Creation Payload, the following fields MUST be checked for correct values:
Key Creation有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション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. 主要なCreation Type--Table26によって定義されるように有効な主要な作成タイプになるようにKey Creation Type値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Mode、適切なメッセージ含有で通知価値有効搭載量の奇形であるなら、送るでしょう。
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. 主要なCreation Data--適切なメッセージで送られる情報を保護するためにKEKを生成するために指定された主要な作成タイプに従って、このKey Creation Dataを処理しなければなりません。 タイプはデータの書式を定義するでしょう。
Harney, et al. Standards Track [Page 89] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[89ページ]。
Implementations that want to derive other keys from the initial Key Creation keying material (for example, DH Secret keying material) MUST define a Key Creation Type other than one of those shown in Table 26. The new Key Creation Type must specify that derivation's algorithm, for which the KEK MAY be one of the keys derived.
材料(例えば、材料を合わせるDH Secret)を合わせる初期のKey Creationから他のキーを得たがっている実装はTable26に示されたものの1つ以外のKey Creation Typeを定義しなければなりません。 新しいKey Creation Typeがその派生のアルゴリズムを指定しなければならない、どれ、KEK MAY、引き出されたキーの1つになってくださいか。
7.12. Nonce Payload
7.12. 一回だけの有効搭載量
7.12.1. Nonce Payload Structure
7.12.1. 一回だけの有効搭載量構造
The Nonce Payload contains random data used to guarantee freshness during an exchange and protect against replay attacks. Figure 27 shows the format of the Nonce Payload.
Nonce有効搭載量は交換の間、新しさを保証して、反射攻撃から守るのに使用される無作為のデータを含んでいます。 図27はNonce有効搭載量の書式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Nonce Type ! Nonce Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
次..有効搭載量..予約..ペイロード長..一回だけ..タイプ..一回だけ..データ
Figure 27: Nonce Payload Format
図27: 一回だけの有効搭載量形式
The Nonce Payload fields are defined as follows:
Nonce有効搭載量分野は以下の通り定義されます:
Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in
the message, then this field will be 0. This field provides the
"chaining" capability. Table 12 identifies the payload types.
This field is treated as an unsigned value.
次の有効搭載量(1つの八重奏)--メッセージの次のペイロードのペイロードタイプへの識別子。 現在のペイロードがメッセージの最終であるなら、この分野は0になるでしょう。 この分野は「推論」能力を提供します。 テーブル12はペイロードタイプを特定します。 この分野は未署名の値として扱われます。
RESERVED (1 octet) - Unused, set to 0.
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.
有効搭載量Length(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.
一回だけのType(1つの八重奏)--使用される一回だけのタイプを指定します。 テーブル27は一回だけのタイプを特定します。 この分野は未署名の値として扱われます。
Harney, et al. Standards Track [Page 90] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[90ページ]。
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
ハッシュタイプの0Initiator(_一回だけの私)1Responder(一回だけ_R)2Combined(一回だけ_C)3Hash(追加します(創始者_Value、Responder_Value))がPolicy(例えば、Policy TokenのSecurity Suite Definition)から来させないなにも。 IANA4--192私用192--255に予約されます。
Nonce Data (variable length) - Contains the nonce information. The
values for this field are group specific, and the format is
specified by the Nonce Type field. If no group-specific
information is provided, the minimum length for this field is 4
bytes.
一回だけのData(可変長)--一回だけの情報を含んでいます。 この分野への値はグループ特有です、そして、形式はNonce Type分野によって指定されます。 どんなグループ特有の情報も提供しないなら、この分野への最小の長さは4バイトです。
The payload type for the Nonce Payload is twelve (12).
Nonce有効搭載量のためのペイロードタイプは12(12)です。
7.12.2. Nonce Payload Processing
7.12.2. 一回だけの有効搭載量処理
When processing the Nonce Payload, the following fields MUST be checked for correct values:
Nonce有効搭載量を処理するとき、正しい値がないかどうか以下の分野をチェックしなければなりません:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
1. 次の有効搭載量、RESERVED、有効搭載量Length--これらの分野はセクション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. 一回だけのType--Table27によって定義されるように有効な一回だけのタイプになるようにNonce Type値をチェックしなければなりません。 値が有効でないなら、誤りは登録されます。 Verbose Modeで通知を含む適切なメッセージは有効搭載量奇形の意志を評価します。送ります。
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. 一回だけのData--これは一回だけのデータであり、内容によると、それをチェックしなければなりません。 この分野のサイズはセクション7.12、「一回だけの有効搭載量」で定義されます。 この分野の解釈について「設立を分類してください」というセクション5.2を参照してください。
Harney, et al. Standards Track [Page 91] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[91ページ]。
8. GSAKMP State Diagram
8. GSAKMP州のダイヤグラム
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)---/
!----------------->( )!------------->の(活動していません)の<。------------------! ! ! ( ) ! ! ! ! ! ! ! ! ! ! ! ! ! (1a) (1) ! ! ! ! ! ! ! ! ! ! ! ! ! V V!---(5a)--- (待っている、) (待っている、) ----(5)-----! ! (グループ) (GC/カンザスイベント) <-- ! (会員資格) ^ ! \ \ ! ! ! ! \ \ ! ! ! ! \--(2)---\!(2a)(4)(3)!V V!-------(4a)--- (待っている、) (待っている、) (グループ) (応答) (会員資格) (キーからの) /(>(イベント)(ダウンロードします)/////)、(3a)---/
Figure 28: GSAKMP State Diagram
図28: GSAKMP州のダイヤグラム
Harney, et al. Standards Track [Page 92] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[92ページ]。
Table 28: GSAKMP States
______________________________________________________________________
テーブル28: GSAKMP州______________________________________________________________________
Idle : GSAKMP Application waiting for input ______________________________________________________________________
怠けます: 入力を待つGSAKMP Application______________________________________________________________________
Wait for GC/KS Event : GC/KS up and running, waiting for events ______________________________________________________________________
GC/カンザスイベントを待ってください: GC/カンザス活動して、待つ、イベント______________________________________________________________________
Wait for Response : GC/KS has sent Key Download, from Key Download : waiting for response from GM ______________________________________________________________________
応答を待ってください: GC/カンザスはKey DownloadからKey Downloadを送りました: GMから応答を待つこと。______________________________________________________________________
Wait for Group : GM in process of joining group Membership : ______________________________________________________________________
グループを待ってください: グループMembershipを接合するプロセスのGM: ______________________________________________________________________
Wait for Group : GM has group key, waiting for Membership Event : group management messages. ______________________________________________________________________
グループを待ってください: GMには、Membership Eventを待っていて、グループキーがあります: 管理メッセージを分類してください。 ______________________________________________________________________
Harney, et al. Standards Track [Page 93] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[93ページ]。
Table 29: State Transition Events
____________________________________________________________________
テーブル29: 状態遷移イベント____________________________________________________________________
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
:
____________________________________________________________________
変遷1: グループコマンドを作成してください。______________:_____________________________________________________ : 変遷2: 悪いRTJを受けてください: グループ会員資格を変える有効なコマンドを受け取ってください: Compromiseメッセージxに回を送ってください: メンバーDeregistration______________:_____________________________________________________ : 変遷3: 有効なRTJを受けてください。______________:_____________________________________________________ : 変遷4: タイムアウト: Ackを受けてください: ナックを受けてください。______________:_____________________________________________________ : 変遷5: グループコマンドを削除してください。______________:_____________________________________________________ : 変遷1a: グループコマンドに参加してください。______________:_____________________________________________________ : 変遷2a: Ackを送ってください。______________:_____________________________________________________ : 変遷3a: 集団経営メッセージの領収書______________:_____________________________________________________ : 変遷4a: グループコマンドを削除してください: Deregistrationコマンド______________:_____________________________________________________ : 変遷5a: タイムアウト: エムエスジー失敗: 誤り: ____________________________________________________________________
Harney, et al. Standards Track [Page 94] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[94ページ]。
9. IANA Considerations
9. IANA問題
9.1. IANA Port Number Assignment
9.1. IANAポートナンバー課題
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空間の両方でポートNo.3761をGSAKMPに供給しました。 すべての実装が適切な方法でこのポート課題を使用しなければなりません。
9.2. Initial IANA Registry Contents
9.2. 初期のIANA登録コンテンツ
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有効搭載量がGSAKMP交換タイプ(セクション7.1.1)のために、GSAKMPの主要なダウンロードデータ項目タイプ(セクション7.4.1)GSAKMP暗号化キーがタイプするGSAKMP方針トークンタイプ(セクション7.3.1)をタイプする、(セクション7.1.1)(セクション7.4.1.1)GSAKMP RekeyイベントはGSAKMP識別分類(セクション7.6.1)をタイプします(セクション7.5.1); GSAKMP識別がGSAKMP証明書タイプ(セクション7.7.1)のために、GSAKMP通知タイプ(セクション7.9.1)GSAKMP承認がタイプするGSAKMP署名タイプ(セクション7.8.1)をタイプする、(セクション7.6.1)(.1)GSAKMPメカニズムがタイプするセクション7.9.1、(.3の)GSAKMPの一回だけのハッシュがタイプするセクション7.9.1、(セクション7.9.1の.3の)GSAKMPの主要な作成はGSAKMPの一回だけのタイプをタイプします(セクション7.11.1)。(セクション7.12.1)
Changes and additions to the following registries are by IETF Standards Action:
以下の登録への変化と追加がIETF Standards Actionであります:
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 RekeyイベントタイプGSAKMP識別分類GSAKMP通知タイプGSAKMP承認タイプGSAKMPメカニズムタイプGSAKMPをタイプします。
Harney, et al. Standards Track [Page 95] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[95ページ]。
Changes and additions to the following registries are by Expert Review:
以下の登録への変化と追加が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の主要な作成がタイプする一回だけのハッシュタイプをタイプします。
10. Acknowledgements
10. 承認
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の研究室研究のパトリック・マクダニエルのSunilアイアンガー、および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で見つけられるTunneled-GSAKMPの作者です。 ロッドのフレイシャー、Tunneled-GSAKMP作者、およびピーターLoughも、GSAKMPソフトウェアの手本をコード化する際にともに手段になって、プロトコルの多くのせいぜいあいまいであった領域を定義するのを助けました。 アンドリュー・マクファーランドとグレゴリーBergrenは仕様の早めのバージョンの重要な分析を提供しました。 プロトコルのセキュリティを分析して、サービス提案の否定が提供された任意の「クッキー保護」に通じるカネッティを車で送りました。
Harney, et al. Standards Track [Page 96] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[96ページ]。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[DH77] Diffie, W., and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
June 1977.
1977年6月の情報理論に関する[DH77]ディフィー、W.とM.ヘルマン、「暗号に関する新傾向」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パブ186-2、米国商務省標準技術局、米国商務省、2000年1月。
[FIPS196] "Entity Authentication Using Public Key Cryptography,"
Federal Information Processing Standards Publication 196,
NIST, February 1997.
[FIPS196] 「公開鍵暗号を使用する実体認証」、連邦政府の情報処理規格公表196、NIST、2月1997日
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[RFC2412] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、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.エージー、「マルチキャストのための管理を合わせてください」 「問題とアーキテクチャ」、RFC2627、6月1999日
[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.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「分類名のストリング表現」、RFC4514、2006年6月。
[RFC4534] Colegrove, A. and H. Harney, "Group Security Policy Token
v1", RFC 4534, June 2006.
[RFC4534] コールグローブ、A.、およびH.ハーニーは「2006年6月にSecurity Policy Token v1"、RFC4534を分類します」。
Harney, et al. Standards Track [Page 97] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[97ページ]。
11.2. Informative References
11.2. 有益な参照
[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.コールグローブとP.マクダニエルと「安全なグループの方針のプリンシプルズ」とネットワークの議事と2001年の分散システムセキュリティインターネット協会、サンディエゴ(カリフォルニア)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.、コールグローブ、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、「グループKey Managementプロトコル(GKMP)仕様」、RFC2093、1997年7月。
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC2094] ハーニーとH.とC.Muckenhirn、「グループKey Managementプロトコル(GKMP)アーキテクチャ」、RFC2094、1997年7月。
[RFC2408] Maughan D., Schertler M., Schneider M., and Turner J.,
"Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2408, Proposed Standard, November
1998
[RFC2408] Maughan D.、Schertler M.、シュナイダーM.、およびターナーJ.、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、提案された標準、1998年11月
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2451] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、1998年11月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key
Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", RFC
4523, June 2006.
[RFC4523]Zeilenga、K.、「X.509証明書のためのライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)図式定義」、RFC4523、2006年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC2974] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、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公開鍵暗号基盤タイムスタンププロトコル(ティースプーンフル)」、RFC3161(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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Harney, et al. Standards Track [Page 98] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[98ページ]。
[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インチ、RFC3447、2月2003日
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3526] Kivinen、T.、およびM.Kojo、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、2003年5月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3740] HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、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.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
Harney, et al. Standards Track [Page 99] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[99ページ]。
Appendix A. LKH Information
付録A.LKH情報
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の概要を与えて、LKHに特定のGSAKMPメッセージの中の分野と値を定義して、Rekey Event Messageに関する例を出すでしょう。
A.1. LKH Overview
A.1。 LKH概要
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はグループrekeyのために主要な分配を取り扱いのためのトポロジーに提供します。 それは木構造とサブグループキーに基づくグループを「再-合わせ」ます。 図29のLKH木では、メンバーは木の上の葉のノードを代理をされます、中間的木のノードが抽象的な主要なグループを代表しますが。 メンバーは複数のキーを所有するでしょう: グループトラフィック保護キー(GTPK)、木の根への経路のあらゆるノードのためのサブグループキー、および個人的なキー。 例えば、#3としてレッテルを貼られたメンバーはGTPK、Key A、Key D、およびKey3を持つでしょう。
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: LKH木
This keying topology provides for a rapid rekey to all but a compromised member of the group. If Member 3 were compromised, the new GTPK (GTPK') would need to be distributed to the group under a key not possessed by Member 3. Additionally, new Keys A and D (Key A' and Key D') would also need to be securely distributed to the other members of those subtrees. Encrypting the GTPK' with Key B would securely distribute that key to Members 5, 6, 7, and 8. Key C can be used to encrypt both the GTPK' and Key A' for Members 1 and 2. Member 3's nearest neighbor, Member 4, can obtain GTPK', Key D', and Key A' encrypted under its personal key, Key 4. At the end of this process, the group is securely rekeyed with Member 3 fully excluded.
この合わせるトポロジーはグループの感染しているメンバーを除いた皆に急速なrekeyに備えます。 'メンバーであるなら、3は感染されました、新しいGTPK、(GTPK、'、)、メンバー3によって所有されていなかったキーの下のグループに分配されるのが必要でしょう。 'また、さらに、新しいキーズAとD(キーAと'Key D')は、しっかりとそれらの下位木の他のメンバーに分配される必要があるでしょう。 Key Bに伴う'GTPKを暗号化します'はしっかりとメンバー5、6、7、および8のそのキーを分配するでしょう。 'メンバー1のためのGTPKと'Key A'と2の両方を暗号化するのにキーCを使用できます。 個人的なキー(Key4)の下で暗号化された'隣人の最も近くのメンバー3(メンバー4)はGTPKを入手でき'て、Key Dと、'Key A'。 このプロセスの終わりでは、グループは完全に除かれたメンバー3と共にしっかりと「再-合わせ」られます。
Harney, et al. Standards Track [Page 100] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[100ページ]。
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. Key Download有効搭載量のRekey ArrayのRekeyバージョン#は値を含まなければなりません。Rekeyバージョン#--、1(1)。
2. Algorithm Version - The Algorithm Version in the Rekey Event
Payload MUST contain the value one (1).
2. アルゴリズムバージョン--Rekey Event有効搭載量におけるAlgorithmバージョンは値1の(1)を含まなければなりません。
3. Degree of Tree - The LKH tree used can be of any degree; it need
not be binary.
3. Treeの度合い--使用されるLKH木はどんな度合いのものであることができますも。 それは2進である必要はありません。
4. Node Identification - Each node in the tree is treated as a KEK.
A KEK is just a special key. As the rule stated for all keys in
GSAKMP, the set of the KeyID and the KeyHandle MUST be unique. A
suggestion on how to do this will be given in this section.
4. ノードIdentification--木の各ノードはKEKとして扱われます。 KEKはただ特別なキーです。 規則がGSAKMPのすべてのキーのために述べたように、KeyIDとKeyHandleのセットはユニークであるに違いありません。 このセクションでどうこれをするかに関する提案を与えるでしょう。
5. Wrapping KeyID and Handle - This is the KeyID and Handle of the
LKH node used to wrap/encrypt the data in a Rekey Event Data.
5. ラッピングKeyIDとHandle--LKHノードのHandleはRekey Event DataのデータをこれがKeyIDであり、包装するか、または以前はよく暗号化していました。
For the following discussion, refer to Figure 30.
以下の議論について、図30を参照してください。
Key: o: a node in the LKH tree N: this line contains the KeyID node number L: this line contains the MemberID number for all leaves ONLY
キー: o: LKH木Nのノード: この系列はKeyIDノード番号Lを含んでいます: この系列はすべての葉だけの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
レベル---- o Nを根づかせてください: 1/1円/円のo o N: 2 2円/3/\/円/円のo o o o N: 3/4\/5\/6円/7\/円/円/円/円の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木
Harney, et al. Standards Track [Page 101] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[101ページ]。
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.
Rekey Controller SHOULDはKeyIDのユニークさを保証するために、仮想の木を建てて、それぞれのノードのKeyIDをラベルします、木が実際に完全であるかどうかにかかわらず完全に居住された木の横型探索をして。 この例の簡単さにおいて、1つ(1)のKeyID値を木の根に与えました。 これらのKeyID値はこの木の寿命の間中静的になるでしょう。 さらに、配列がGMに分配したrekeyは、それらに関連しているMemberID値がKeyDownload有効搭載量で分配されるのを必要とします。 これらのMemberID値はユニークであるに違いありません。 したがって、それぞれの葉のノード(その葉から根までのノード)に関連しているセットにMemberIDを与えます。 この例では、1つ(1)のMemberID値を一番左葉のノードに与えます。 これらの2セットの値(KeyIDs(系列Nでは、表される)とMemberIDs(系列Lでは、表される))は、情報を広めるためにKeyDownloadとRekeyEventの十分な情報に有効搭載量を与えるでしょう。 これらのキーに関連しているKeyHandleは妥協するのにおいて当然の木でキーを取り替えるたびに作り直されます。
A.3. LKH Examples
A.3。 LKHの例
Definition of values: 0xLLLL - length value 0xHHHHHHH# - handle value YYYYMMDDHHMMSSZ - time value
値の定義: 0xLLLL--長さの値の0xHHHHHHH#--ハンドル値のYYYYMMDDHHMMSSZ--時間的価値
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.
このセクションはKey Downloadペイロードのためのデータに関する例を出すでしょう。 MemberID1とその関連キーをGMに与えるでしょう。 示されたデータはGeneric有効搭載量Headerにその後になるでしょう。
| GTPK | MemberID 1 | KeyID 2 | KeyID 4 | KeyID 8
| GTPK| MemberID1| KeyID2| KeyID4| KeyID8
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: 主要なDownload Data Item Type--0×00 (GTPK)主要なDownload Data Item Length--0xLLLL Key Type--0×03 (3DES'CBC64'192)主要なID--KEY1 Key Handle--0xHHHHHHH0 Key Creation Date--YYYYMMDDHHMMSSZ Key Expiration Date--主要な定義Item#2に基づいて可変なYYYYMMDDHHMMSSZ Key Data:、' 主要なダウンロードデータ項目タイプ--0×01(Rekey--LKH)の主要なダウンロードデータ項目の長さ--0xLLLL Rekeyバージョン番号--0×01メンバーID--0×00000001
Harney, et al. Standards Track [Page 102] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[102ページ]。
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
KEKキーの数--0×0003 KEK#1: 主要なType--0×03 (3DES'CBC64'192)主要なID--0×00000002Key Handle--0xHHHHHHH2 Key Creation Date--YYYYMMDDHHMMSSZ Key Expiration Date--主要な定義KEK#2に基づいて可変なYYYYMMDDHHMMSSZ Key Data:、' 主要なType--0×03 (3DES'CBC64'192)主要なID--0×00000004Key Handle--0xHHHHHHH4 Key Creation Date--YYYYMMDDHHMMSSZ Key Expiration Date--主要な定義KEK#3に基づいて可変なYYYYMMDDHHMMSSZ Key Data:、' 主要なType--0×03 (3DES'CBC64'192)主要なID--0×00000008Key Handle--0xHHHHHHH8 Key Creation Date--YYYYMMDDHHMMSSZ Key Expiration Date--YYYYMMDDHHMMSSZ Key Data--変数主要な定義に基づいて、
A.3.2. LKH Rekey Event Example
A.3.2。 LKH Rekeyイベントの例
This section will give an example of the data for the Rekey Event payload. The GM with MemberID 6 will be keyed out of the group. The data shown will be subsequent to the Generic Payload Header.
このセクションはRekey Eventペイロードのためのデータに関する例を出すでしょう。 MemberID6があるGMはグループから合わせられるでしょう。 示されたデータはGeneric有効搭載量Headerにその後になるでしょう。
| Rekey Event Type | GroupID | Date/Time | Rekey Type |
Algorithm Ver | # of Packets |
{ (GTPK)2, (GTPK, 3', 6')12, (GTPK, 3')7 }
| Rekeyイベントタイプ| GroupID| 日付/時間| Rekeyはタイプします。| アルゴリズムVer| # パケットについて| '(GTPK)2、(GTPK、3、'6')12、(GTPK、3')7
This data shows that three packets are being transmitted. Read each packet as:
このデータは、3つのパケットが伝えられているのを示します。 各パケットを以下と読んでください。
a) GTPK wrapped in LKH KeyID 2 b) GTPK, LKH KeyIDs 3' & 6', all wrapped in LKH KeyID 12 c) GTPK and LKH KeyID 3', all wrapped in LKH KeyID 7
a) LKH KeyID2b)で包装されたGTPK 'すべてが、LKH KeyID12c)でGTPKと、LKH KeyIDs3と'6'と包装しました。 LKH KeyID7ですべて包装された'GTPKとLKH KeyID3'
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、'6、'(3')(3')7'(6')12)。
We will show the format for all header data and packet (b).
私たちはすべてのヘッダー・データとパケット(b)のために書式を示すつもりです。
Harney, et al. Standards Track [Page 103] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[103ページ]。
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
Rekeyイベントタイプ--0×01 (GSAKMP'LKH)GroupID--0xAABBCCDD0x12345678時間/日付のスタンプ--YYYYMMDDHHMMSSZ Rekeyイベントタイプ--0×01 (GSAKMP'LKH)アルゴリズムVers--RkyEvt Pktsの0×01#--0×0003 パケット(b)のために: パケット長--0xLLLLラッピングKeyID--0x000Cのラッピングの主要なハンドル--主要なパッケージの0xHHHHHHHD#--0×0003 主要なパッケージ1: 主要なPkg Type--0×00 (GTPK)パックLength--0xLLLL Key Type--0×03 (3DES'CBC64'192)主要なID--KEY1 Key Handle--0xHHHHHHH0 Key Creation Date--主要な定義Keyパッケージ2に可変で、基づいているYYYYMMDDHHMMSSZ Key Expiration Date(YYYYMMDDHHMMSSZ Key Data):、' 主要なPkg Type--0×01 (Rekey--LKH) パックLength--0xLLLL Key Type--0×03 (3DES'CBC64'192)主要なID--0×00000003Key Handle--0xHHHHHHH3 Key Creation Date--主要な定義Keyパッケージ3に可変で、基づいているYYYYMMDDHHMMSSZ Key Expiration Date(YYYYMMDDHHMMSSZ Key Data):、' 主要なPkg Type--0×01 (Rekey--LKH) パックLength--0xLLLL Key Type--0×03 (3DES'CBC64'192)主要なID--0×00000006Key Handle--0xHHHHHHH6 Key Creation Date--YYYYMMDDHHMMSSZ Key Expiration Date--YYYYMMDDHHMMSSZ Key Data--変数主要な定義に基づいて、
Harney, et al. Standards Track [Page 104] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[104ページ]。
Authors' Addresses
作者のアドレス
Hugh Harney (point-of-contact) SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
ヒュー・ハーニー(連絡先)スパルタInc.7110サミュエル・モースDriveコロンビア、MD 21046
Phone: (443) 430-8032 Fax: (443) 430-8181 EMail: hh@sparta.com
以下に電話をしてください。 (443) 430-8032 Fax: (443) 430-8181 メールしてください: hh@sparta.com
Uri Meth SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
ユリメタンフェタミンスパルタInc.7110サミュエル・モースDriveコロンビア、MD 21046
Phone: (443) 430-8058 Fax: (443) 430-8207 EMail: umeth@sparta.com
以下に電話をしてください。 (443) 430-8058 Fax: (443) 430-8207 メールしてください: umeth@sparta.com
Andrea Colegrove SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
アンドレアコールグローブスパルタInc.7110サミュエル・モースDriveコロンビア、MD 21046
Phone: (443) 430-8014 Fax: (443) 430-8163 EMail: acc@sparta.com
以下に電話をしてください。 (443) 430-8014 Fax: (443) 430-8163 メールしてください: acc@sparta.com
George Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833
ジョージGrossのIdentAwareセキュリティ82の古いMountain Roadレバノン、ニュージャージー 08833
Phone: (908) 268-1629 EMail: gmgross@identaware.com
以下に電話をしてください。 (908) 268-1629 メールしてください: gmgross@identaware.com
Harney, et al. Standards Track [Page 105] RFC 4535 GSAKMP June 2006
ハーニー、他 規格はGSAKMP2006年6月にRFC4535を追跡します[105ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Harney, et al. Standards Track [Page 106]
ハーニー、他 標準化過程[106ページ]
一覧
スポンサーリンク
