[要約] RFC 3547は、グループドメインの解釈に関する仕様であり、セキュリティプロトコルでのグループ鍵の交換と管理を可能にする。目的は、グループ通信のセキュリティを向上させ、グループメンバー間の信頼性と機密性を確保すること。
Network Working Group M. Baugher
Request for Comments: 3547 B. Weis
Category: Standards Track Cisco
T. Hardjono
Verisign
H. Harney
Sparta
July 2003
The Group Domain of Interpretation
解釈のグループドメイン
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members.
このドキュメントでは、安全なグループ通信をサポートするためのグループキー管理の解釈のISAMKPドメイン（DOI）を提示します。GDOIは、IPまたはアプリケーションレイヤーで実行されているIPSECおよび潜在的に他のデータセキュリティプロトコルで使用されるグループセキュリティ協会を管理します。これらのセキュリティ協会は、1つ以上のキー暗号化キー、トラフィック暗号化キー、またはグループメンバーが共有するデータを保護します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. GDOI Applications. . . . . . . . . . . . . . . . . . . . 5
1.2. Extending GDOI . . . . . . . . . . . . . . . . . . . . . 5
2. GDOI Phase 1 protocol. . . . . . . . . . . . . . . . . . . . . 6
2.1. ISAKMP Phase 1 protocol. . . . . . . . . . . . . . . . . 6
2.1.1. DOI value. . . . . . . . . . . . . . . . . . . . 6
2.1.2. UDP port . . . . . . . . . . . . . . . . . . . . 6
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 6
3.1. Authorization. . . . . . . . . . . . . . . . . . . . . . 7
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Perfect Forward Secrecy. . . . . . . . . . . . . 9
3.2.2. ISAKMP Header Initialization . . . . . . . . . . 9
3.3. Initiator Operations . . . . . . . . . . . . . . . . . . 10
3.4. Receiver Operations. . . . . . . . . . . . . . . . . . . 11
4. GROUPKEY-PUSH Message. . . . . . . . . . . . . . . . . . . . . 11
4.1. Perfect Forward Secrecy (PFS). . . . . . . . . . . . . . 12
4.2. Forward and Backward Access Control. . . . . . . . . . . 12
4.2.1. Forward Access Control Requirements. . . . . . . 13
4.3. Delegation of Key Management . . . . . . . . . . . . . . 14
4.4. Use of signature keys. . . . . . . . . . . . . . . . . . 14
4.5. ISAKMP Header Initialization . . . . . . . . . . . . . . 14
4.6. Deletion of SAs. . . . . . . . . . . . . . . . . . . . . 14
4.7. GCKS Operations. . . . . . . . . . . . . . . . . . . . . 15
4.8. Group Member Operations. . . . . . . . . . . . . . . . . 16
5. Payloads and Defined Values. . . . . . . . . . . . . . . . . . 16
5.1. Identification Payload . . . . . . . . . . . . . . . . . 17
5.1.1. Identification Type Values . . . . . . . . . . . 18
5.2. Security Association Payload . . . . . . . . . . . . . . 18
5.2.1. Payloads following the SA payload. . . . . . . . 19
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. KEK Attributes . . . . . . . . . . . . . . . . . 22
5.3.2. KEK_MANAGEMENT_ALGORITHM . . . . . . . . . . . . 22
5.3.3. KEK_ALGORITHM. . . . . . . . . . . . . . . . . . 23
5.3.4. KEK_KEY_LENGTH . . . . . . . . . . . . . . . . . 23
5.3.5. KEK_KEY_LIFETIME . . . . . . . . . . . . . . . . 24
5.3.6. SIG_HASH_ALGORITHM . . . . . . . . . . . . . . . 24
5.3.7. SIG_ALGORITHM. . . . . . . . . . . . . . . . . . 24
5.3.8. SIG_KEY_LENGTH . . . . . . . . . . . . . . . . . 25
5.3.9. KE_OAKLEY_GROUP. . . . . . . . . . . . . . . . . 25
5.4. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . 25
5.4.1. PROTO_IPSEC_ESP. . . . . . . . . . . . . . . . . 26
5.4.2. Other Security Protocols . . . . . . . . . . . . 28
5.5. Key Download Payload . . . . . . . . . . . . . . . . . . 28
5.5.1. TEK Download Type. . . . . . . . . . . . . . . . 30
5.5.2. KEK Download Type. . . . . . . . . . . . . . . . 31
5.5.3. LKH Download Type. . . . . . . . . . . . . . . . 32
5.6. Sequence Number Payload. . . . . . . . . . . . . . . . . 35
5.7. Proof of Possession. . . . . . . . . . . . . . . . . . . 36
5.8. Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 36
6.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . 37
6.1.1. Authentication . . . . . . . . . . . . . . . . . 37
6.1.2. Confidentiality. . . . . . . . . . . . . . . . . 37
6.1.3. Man-in-the-Middle Attack Protection. . . . . . . 38
6.1.4. Replay/Reflection Attack Protection. . . . . . . 38
6.1.5. Denial of Service Protection . . . . . . . . . . 38
6.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . 38
6.2.1. Authentication . . . . . . . . . . . . . . . . . 38
6.2.2. Confidentiality. . . . . . . . . . . . . . . . . 39
6.2.3. Man-in-the-Middle Attack Protection. . . . . . . 39
6.2.4. Replay/Reflection Attack Protection. . . . . . . 39
6.2.5. Denial of Service Protection . . . . . . . . . . 39
6.2.6. Authorization. . . . . . . . . . . . . . . . . . 40
6.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . 40
6.3.1. Authentication . . . . . . . . . . . . . . . . . 40
6.3.2. Confidentiality. . . . . . . . . . . . . . . . . 40
6.3.3. Man-in-the-Middle Attack Protection. . . . . . . 40
6.3.4. Replay/Reflection Attack Protection. . . . . . . 40
6.3.5. Denial of Service Protection . . . . . . . . . . 41
6.3.6. Forward Access Control . . . . . . . . . . . . . 41
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 41
7.1. ISAKMP DOI . . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Payload Types. . . . . . . . . . . . . . . . . . . . . . 42
7.3. New Name spaces. . . . . . . . . . . . . . . . . . . . . 42
7.4. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Intellectual Property Rights Statement . . . . . . . . . . . . 42
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A: Alternate GDOI Phase 1 protocols . . . . . . . . . . . 46
A.1. IKEv2 Phase 1 protocol . . . . . . . . . . . . . . . . . 46
A.2. KINK Protocol. . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 48
This document presents an ISAMKP Domain of Interpretation (DOI) for group key management called the "Group Domain of Interpretation" (GDOI). In this group key management model, the GDOI protocol is run between a group member and a "group controller/key server" (GCKS), which establishes security associations [Section 4.6.2 RFC2401] among authorized group members. ISAKMP defines two "phases" of negotiation [p.16 RFC2408]. The GDOI MUST be protected by a Phase 1 security association. This document incorporates the Phase 1 security association (SA) definition from the Internet DOI [RFC2407, RFC2409]. Other possible Phase 1 security association types are noted in Appendix A. The Phase 2 exchange is defined in this document, and proposes new payloads and exchanges according to the ISAKMP standard [p. 14 RFC2408].
このドキュメントは、「解釈のグループドメイン」（GDOI）と呼ばれるグループキー管理の解釈のISAMKPドメイン（DOI）を提示します。このグループキー管理モデルでは、GDOIプロトコルはグループメンバーと「グループコントローラー/キーサーバー」（GCKS）の間で実行され、認定グループメンバーの間でセキュリティ協会[セクション4.6.2 RFC2401]を確立します。ISAKMPは、交渉の2つの「フェーズ」を定義しています[p.16 RFC2408]。GDOIは、フェーズ1セキュリティ協会によって保護されている必要があります。このドキュメントには、インターネットDOI [RFC2407、RFC2409]からのフェーズ1セキュリティ協会（SA）の定義が組み込まれています。他の可能なフェーズ1セキュリティ関連タイプは付録Aに記載されています。フェーズ2の交換はこのドキュメントで定義されており、ISAKMP標準[p。14 RFC2408]。
There are six new payloads:
6つの新しいペイロードがあります：
1) GDOI SA 2) SA KEK (SAK) which follows the SA payload 3) SA TEK (SAT) which follows the SA payload 4) Key Download Array (KD) 5) Sequence number (SEQ) 6) Proof of Possession (POP)
1) GDOI SA 2）SAペイロード3に続くSA KEK（SAK）SA Payload 4に続くSA TEK（SAT）キーダウンロードアレイ（KD）5）シーケンス番号（SEQ）6）所有証明（POP）
There are two new exchanges.
2つの新しい交換があります。
1) A Phase 2 exchange creates Re-key and Data-Security Protocol SAs.
1) フェーズ2エクスチェンジは、再キーとデータセキュリティプロトコルSASを作成します。
The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for a group's "Re-key" SA and/or "Data-security" SA. The Re-key SA includes a key encrypting key, or KEK, common to the group; a Data-security SA includes a data encryption key, or TEK, used by a data-security protocol to encrypt or decrypt data traffic [Section 2.1 RFC2407]. The SA for the KEK or TEK includes authentication keys, encryption keys, cryptographic policy, and attributes. The GROUPKEY-PULL exchange uses "pull" behavior since the member initiates the retrieval of these SAs from a GCKS.
「GroupKey-Pull」と呼ばれる新しいフェーズ2エクスチェンジは、グループの「Rekey」SAおよび/または「データセキュリティ」SAのキーをダウンロードします。再キーSAには、グループに共通するキー暗号化キー、またはKekが含まれています。データセキュリティSAには、データトラフィックを暗号化または復号化するためにデータセキュリティプロトコルが使用するデータ暗号化キーまたはTEKが含まれます[セクション2.1 RFC2407]。KEKまたはTEKのSAには、認証キー、暗号化キー、暗号化ポリシー、および属性が含まれています。GroupKey-Pull Exchangeは、メンバーがGCKSからこれらのSAの検索を開始するため、「プル」動作を使用します。
2) A datagram subsequently establishes additional Rekey and/or Data-Security Protocol SAs.
2) その後、データグラムが追加のRekeyおよび/またはデータセキュリティプロトコルSASを確立します。
The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the members to create or update a Re-key or Data-security SA. A Re-key SA protects GROUPKEY-PUSH messages. Thus, a GROUPKEY-PULL is necessary to establish at least one Re-key SA in order to protect subsequent GROUPKEY-PUSH messages. The GCKS encrypts the GROUPKEY-PUSH message using the KEK Re-key SA. GDOI accommodates the use of arrays of KEKs for group key management algorithms using the Logical Key Hierarchy (LKH) algorithm to efficiently add and remove group members [RFC2627]. Implementation of the LKH algorithm is OPTIONAL.
GroupKey-Pushデータグラムは、GCKSからメンバーに「プッシュ」され、再キーまたはデータセキュリティSAを作成または更新します。再キーSAは、GroupKey-Pushメッセージを保護します。したがって、後続のGroupKey-Pushメッセージを保護するために、少なくとも1つの再キーSAを確立するには、GroupKey-Pullが必要です。GCKSは、Kek Reke Saを使用してGroupKey-Pushメッセージを暗号化します。GDOIは、論理キー階層（LKH）アルゴリズムを使用して、グループキー管理アルゴリズムにKEKの配列を使用して、グループメンバー[RFC2627]を効率的に追加および削除することに対応します。LKHアルゴリズムの実装はオプションです。
Although the GROUPKEY-PUSH specified by this document can be used to refresh a Re-key SA, the most common use of GROUPKEY-PUSH is to establish a Data-security SA for a data security protocol. GDOI can accommodate future extensions to support a variety of data security protocols. This document only specifies data-security SAs for one security protocol, IPsec ESP. A separate RFC will specify support for other data security protocols such as a future secure Real-time Transport Protocol. A security protocol uses the TEK and "owns" the data-security SA in the same way that IPsec ESP uses the IKE Phase 2 keys and owns the Phase 2 SA; for GDOI, IPsec ESP uses the TEK.
このドキュメントで指定されたGroupKey-Pushは、再キーサを更新するために使用できますが、GroupKey-Pushの最も一般的な使用は、データセキュリティプロトコルのデータセキュリティSAを確立することです。GDOIは、将来の拡張機能に対応して、さまざまなデータセキュリティプロトコルをサポートできます。このドキュメントは、1つのセキュリティプロトコル、IPSEC ESPのデータセキュリティSASのみを指定します。別のRFCは、将来の安全なリアルタイムトランスポートプロトコルなど、他のデータセキュリティプロトコルのサポートを指定します。セキュリティプロトコルは、IPSEC ESPがIKEフェーズ2キーを使用し、フェーズ2 SAを所有するのと同じ方法で、TEKを使用し、データセキュリティSAを「所有」します。GDOIの場合、IPSEC ESPはTekを使用します。
Thus, GDOI is a group security association management protocol: All GDOI messages are used to create, maintain, or delete security associations for a group. As described above, these security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members for multicast and groups security applications.
したがって、GDOIはグループセキュリティ協会の管理プロトコルです。すべてのGDOIメッセージは、グループのセキュリティ協会を作成、維持、または削除するために使用されます。上記のように、これらのセキュリティ協会は、マルチキャストおよびグループセキュリティアプリケーションのグループメンバーが共有する1つ以上のキー暗号化キー、トラフィック暗号化キー、またはデータを保護します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワードは、このドキュメントに表示される場合、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される場合、必要な、要求されてはなりません。
Secure multicast applications include video broadcast and multicast file transfer. In a business environment, many of these applications require network security and may use IPsec ESP to secure their data traffic. Section 5.4.1 specifies how GDOI carries the needed SA parameters for ESP. In this way, GDOI supports multicast ESP with group authentication of ESP packets using the shared, group key (authentication of unique sources of ESP packets is not possible).
安全なマルチキャストアプリケーションには、ビデオブロードキャストとマルチキャストファイル転送が含まれます。ビジネス環境では、これらのアプリケーションの多くはネットワークセキュリティを必要とし、IPSEC ESPを使用してデータトラフィックを保護する場合があります。セクション5.4.1では、GDOIがESPに必要なSAパラメーターをどのように運ぶかを指定します。このようにして、GDOIは、共有グループキーを使用して、ESPパケットのグループ認証でマルチキャストESPをサポートしています（ESPパケットの一意のソースの認証は不可能です）。
GDOI can also secure group applications that do not use multicast transport such as video-on-demand. For example, the GROUPKEY-PUSH message may establish a pair-wise IPsec ESP SA for a member of a subscription group without the need for key management exchanges and costly asymmetric cryptography.
GDOIは、ビデオオンデマンドなどのマルチキャストトランスポートを使用しないグループアプリケーションを保護することもできます。たとえば、GroupKey-Pushメッセージは、主要な管理交換や費用のかかる非対称暗号化を必要とせずに、サブスクリプショングループのメンバーにペアワイズIPSEC ESP SAを確立する場合があります。
Not all secure multicast or multimedia applications can use IPsec ESP. Many Real Time Transport Protocol applications, for example, require security above the IP layer to preserve RTP header compression efficiencies and transport-independence [RFC3550]. A future RTP security protocol may benefit from using GDOI to establish group SAs.
すべての安全なマルチキャストまたはマルチメディアアプリケーションがIPSEC ESPを使用できるわけではありません。たとえば、多くのリアルタイム輸送プロトコルアプリケーションでは、RTPヘッダー圧縮効率と輸送独立[RFC3550]を保持するために、IPレイヤーを超えるセキュリティが必要です。将来のRTPセキュリティプロトコルは、GDOIを使用してグループSASを確立することで恩恵を受ける可能性があります。
In order to add a new data security protocol, a new RFC MUST specify the data-security SA parameters conveyed by GDOI for that security protocol; these parameters are listed in section 5.4.2 of this document.
新しいデータセキュリティプロトコルを追加するには、新しいRFCは、そのセキュリティプロトコルのためにGDOIによって伝えられたデータセキュリティSAパラメーターを指定する必要があります。これらのパラメーターは、このドキュメントのセクション5.4.2にリストされています。
Data security protocol SAs MUST protect group traffic. GDOI provides no restriction on whether that group traffic is transmitted as unicast or multicast packets. However, GDOI MUST NOT be used as a key management mechanism by a data security protocol when the packets protected by the data-security SA are intended to be private and never become part of group communications.
データセキュリティプロトコルSASは、グループトラフィックを保護する必要があります。GDOIは、そのグループトラフィックがユニキャストパケットまたはマルチキャストパケットとして送信されるかどうかに制限を提供しません。ただし、データセキュリティSAによって保護されているパケットがプライベートであり、グループコミュニケーションの一部になることはない場合、GDOIはデータセキュリティプロトコルによって重要な管理メカニズムとして使用されてはなりません。
GDOI is a "phase 2" protocol which MUST be protected by a "phase 1" protocol. The "phase 1" protocol can be any protocol which provides for the following protections:
GDOIは「フェーズ2」プロトコルであり、「フェーズ1」プロトコルによって保護する必要があります。「フェーズ1」プロトコルは、次の保護を提供する任意のプロトコルにすることができます。
o Peer Authentication o Confidentiality o Message Integrity
o ピア認証o機密性oメッセージの整合性
The following sections describe one such "phase 1" protocol. Other protocols which may be potential "phase 1" protocols are described in Appendix A. However, the use of the protocols listed there are not considered part of this document.
次のセクションでは、そのような「フェーズ1」プロトコルの1つについて説明します。潜在的な「フェーズ1」プロトコルである可能性のある他のプロトコルは、付録Aで説明されています。ただし、リストされているプロトコルの使用は、このドキュメントの一部とは見なされません。
This document defines how the ISAKMP phase 1 exchanges as defined in [RFC2409] can be used a "phase 1" protocol for GDOI. The following sections define characteristics of the ISAKMP phase 1 protocols that are unique for these exchanges when used for GDOI.
このドキュメントでは、[RFC2409]で定義されているISAKMPフェーズ1交換をGDOIの「フェーズ1」プロトコルとして使用する方法を定義しています。次のセクションでは、GDOIに使用した場合にこれらの交換に固有のISAKMPフェーズ1プロトコルの特性を定義します。
Section 6.1 describes how the ISAKMP Phase 1 protocols meet the requirements of a GDOI "phase 1" protocol.
セクション6.1では、ISAKMPフェーズ1プロトコルがGDOI「フェーズ1」プロトコルの要件をどのように満たしているかについて説明します。
The Phase 1 SA payload has a DOI value. That value MUST be the GDOI DOI value as defined later in this document.
フェーズ1 SAペイロードにはDOI値があります。この値は、このドキュメントの後半で定義されているように、GDOI DOI値でなければなりません。
GDOI MUST NOT run on port 500 (the port commonly used for IKE). IANA has assigned port 848 for the use of GDOI.
GDOIは、ポート500（IKEに一般的に使用されるポート）で実行してはなりません。IANAは、GDOIを使用するためにポート848を割り当てました。
The goal of the GROUPKEY-PULL exchange is to establish a Re-key and/or Data-security SAs at the member for a particular group. A Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange downloads the data security keys (TEKs) and/or group key encrypting key (KEK) or KEK array under the protection of the Phase 1 SA.
GroupKey-Pull Exchangeの目標は、特定のグループのメンバーに再キーおよび/またはデータセキュリティSASを確立することです。フェーズ1 SAは、GroupKey-Pullを保護します。特定のフェーズ1 SAの複数のグループキープル交換がある場合があります。GroupKey-Pull Exchangeは、フェーズ1 SAの保護下にあるデータセキュリティキー（TEK）および/またはグループキー暗号化キー（KEK）またはKEKアレイをダウンロードします。
There are two alternative means for authorizing the GROUPKEY-PULL message. First, the Phase 1 identity can be used to authorize the Phase 2 (GROUPKEY-PULL) request for a group key. Second, a new identity can be passed in the GROUPKEY-PULL request. The new identity could be specific to the group and use a certificate that is signed by the group owner to identify the holder as an authorized group member. The Proof-of-Possession payload validates that the holder possesses the secret key associated with the Phase 2 identity.
GroupKey-Pullメッセージを承認するための2つの代替手段があります。まず、フェーズ1のIDを使用して、グループキーのフェーズ2（GroupKey-Pull）要求を承認できます。第二に、GroupKey-Pullリクエストで新しいIDを渡すことができます。新しいIDはグループに固有であり、グループ所有者によって署名された証明書を使用して、所有者を認定グループメンバーとして識別することができます。Proof-of-Possessionのペイロードは、保有者がフェーズ2のIDに関連付けられた秘密の鍵を所有していることを検証します。
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a which is the "key" in the keyed hash used in the GROUPKEY-PULL HASH payloads. When using the Phase 1 defined in this document, SKEYID_a is derived according to [RFC2409]. As with the IKE HASH payload generation [RFC 2409 section 5.5], each GROUPKEY-PULL message hashes a uniquely defined set of values. Nonces permute the HASH and provide some protection against replay attacks. Replay protection is important to protect the GCKS from attacks that a key management server will attract.
GroupKey-Pullはフェーズ2の交換です。フェーズ1は、GroupKey-Pullハッシュペイロードで使用されているキー付きハッシュの「キー」であるSkeyid_aを計算します。このドキュメントで定義されているフェーズ1を使用する場合、SkeyID_Aは[RFC2409]に従って導出されます。IKEハッシュペイロード生成[RFC 2409セクション5.5]と同様に、各GroupKey-Pullメッセージは、一意に定義された値のセットをハッシュします。ノンセスはハッシュに迫害し、リプレイ攻撃に対するある程度の保護を提供します。キー管理サーバーが引き付ける攻撃からGCKを保護するには、リプレイ保護が重要です。
The GROUPKEY-PULL uses nonces to guarantee "liveliness", or against replay of a recent GROUPKEY-PULL message. The replay attack is only useful in the context of the current Phase 1. If a GROUPKEY-PULL message is replayed based on a previous Phase 1, the HASH calculation will fail due to a wrong SKEYID_a. The message will fail processing before the nonce is ever evaluated. In order for either peer to get the benefit of the replay protection, it must postpone as much processing as possible until it receives the message in the protocol that proves the peer is live. For example, the Responder MUST NOT compute the shared Diffie-Hellman number (if KE payloads were included) or install the new SAs until it receives a message with Nr included properly in the HASH payload.
GroupKey-PullはNoncesを使用して「活気」を保証するか、最近のGroupKey-Pullメッセージのリプレイに対して保証します。リプレイ攻撃は、現在のフェーズ1のコンテキストでのみ役立ちます。以前のフェーズ1に基づいてGroupKey-Pullメッセージが再生される場合、SkeyID_aが間違っているためにハッシュ計算が失敗します。ノンセが評価される前に、メッセージは処理に失敗します。どちらかのピアがリプレイ保護の利益を得るためには、ピアがライブであることを証明するプロトコルでメッセージを受信するまで、できるだけ多くの処理を延期する必要があります。たとえば、レスポンダーは、共有Diffie-Hellman番号（KEペイロードが含まれている場合）を計算したり、ハッシュペイロードに適切に含まれているNRを含むメッセージを受信するまで新しいSASをインストールしてはなりません。
Nonces require an additional message in the protocol exchange to ensure that the GCKS does not add a group member until it proves liveliness. The GROUPKEY-PULL member-initiator expects to find its nonce, Ni, in the HASH of a returned message. And the GROUPKEY-PULL GKCS responder expects to see its nonce, Nr, in the HASH of a returned message before providing group-keying material as in the following exchange.
Noncesは、GCKSが活気を証明するまでグループメンバーを追加しないことを確認するために、プロトコル交換で追加のメッセージを必要とします。GroupKey-Key-Pullメンバーインティエーターは、返されたメッセージのハッシュで、NOCE、NIを見つけることを期待しています。また、GroupKey-Pull GKCS Responderは、以下の交換のようにグループを維持する材料を提供する前に、返されたメッセージのハッシュでそのノンセ、NRを見ることを期待しています。
Initiator (Member) Responder (GCKS)
------------------ ----------------
HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I] -->
[,CERT] [,POP_I]
<-- HDR*, HASH(4),[KE_R,][SEQ,]
KD [,CERT] [,POP_R]
Hashes are computed as follows:
ハッシュは次のように計算されます。
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | CERT ]
[ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ]
KD [ | CERT ] [ | POP_R])
POP payload is constructed as described in Section 5.7. * Protected by the Phase 1 SA, encryption occurs after HDR
POPペイロードは、セクション5.7で説明されているように構築されます。*フェーズ1 SAによって保護されているため、暗号化はHDRの後に発生します
HDR is an ISAKMP header payload that uses the Phase 1 cookies and a message identifier (M-ID) as in IKE [RFC2409]. Note that nonces are included in the first two exchanges, with the GCKS returning only the SA policy payload before liveliness is proven. The HASH payloads [RFC2409] prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the exchange identified by message id, M-ID. Once liveliness is established, the last message completes the real processing of downloading the KD payload.
HDRは、IKE [RFC2409]のように、フェーズ1 Cookieとメッセージ識別子（M-ID）を使用するISAKMPヘッダーペイロードです。Noncesは最初の2つの交換に含まれており、GCKSは活気が証明される前にSAポリシーペイロードのみを返します。ハッシュペイロード[RFC2409]は、ピアがメッセージID、M-IDで識別される交換のフェーズ1シークレット（SKEYID_A）とNonCEを持っていることを証明しています。活気が確立されると、最後のメッセージはKDペイロードのダウンロードの実際の処理を完了します。
In addition to the Nonce and HASH payloads, the member-initiator identifies the group it wishes to join through the ISAKMP ID payload. The GCKS responder informs the member of the current value of the sequence number in the SEQ payload; the sequence number orders the GROUPKEY-PUSH datagrams (section 4); the member MUST check to see that the sequence number is greater than in the previous SEQ payload the member holds for the group (if it holds any) before installing any new SAs. The SEQ payload MUST be present if the SA payload contains an SA KEK attribute. The GCKS responder informs the member of the cryptographic policies of the group in the SA payload, which describes the DOI, KEK and/or TEK keying material, and authentication transforms. The SPIs are also determined by the GCKS and downloaded in the SA payload chain (see section 5.2). The SA KEK attribute contains the ISAKMP cookie pair for the Re-key SA, which is not negotiated but downloaded. The SA TEK attribute contains an SPI as defined in section 5.4 of this document. The second message downloads this SA payload. If a Re-key SA is defined in the SA payload, then KD will contain the KEK; if one or more Data-security SAs are defined in the SA payload, KD will contain the TEKs. This is useful if there is an initial set of TEKs for the particular group and can obviate the need for future TEK GROUPKEY-PUSH messages (described in section 4).
NonCeおよびHashペイロードに加えて、メンバーイテリアはISAKMP IDペイロードを介して参加したいグループを特定します。GCKSレスポンダーは、配列ペイロードのシーケンス番号の現在の値をメンバーに通知します。シーケンス番号は、GroupKey-Pushデータグラムを注文します（セクション4）。メンバーは、シーケンス番号が新しいSASをインストールする前にグループに対して保持する前のSEQペイロードよりも大きいことを確認する必要があります。SAペイロードにSA kek属性が含まれている場合、seqペイロードが存在する必要があります。GCKSレスポンダーは、DOI、KEK、および/またはTek Keyingマテリアル、および認証変換を説明するSAペイロードのグループの暗号化ポリシーのメンバーに通知します。SPIはGCKSによっても決定され、SAペイロードチェーンにダウンロードされます（セクション5.2を参照）。SA Kek属性には、ReCey SA用のISAKMP Cookieペアが含まれています。SA Tek属性には、このドキュメントのセクション5.4で定義されているSPIが含まれています。2番目のメッセージは、このSAペイロードをダウンロードします。sa saがsaペイロードで定義されている場合、kdにはkekが含まれます。SAペイロードで1つ以上のデータセキュリティSAが定義されている場合、KDにはTEKが含まれます。これは、特定のグループに最初のTEKのセットがあり、将来のTek GroupKey-Pushメッセージの必要性を取り除くことができる場合に役立ちます（セクション4で説明）。
As described above, the member may establish an identity in the GROUPKEY-PULL exchange in an optional CERT payload that is separate from the Phase 1 identity. When the member passes a new CERT, a proof of possession (POP) payload accompanies it. The POP payload demonstrates that the member or GCKS has used the very secret that authenticates it. POP_I is an ISAKMP SIG payload containing a hash including the nonces Ni and Nr signed by the member, when the member passes a CERT, signed by the Group Owner to prove its authorization. POP_R contains the hash including the concatenated nonces Ni and Nr signed by the GCKS, when the GCKS passes a CERT, signed by the group owner, to prove its authority to provide keys for a particular group. The use of the nonce pair for the POP payload, transformed through a pseudo-random function (prf) and encrypted, is designed to withstand compromise of the Phase 1 key. Implementation of the CERT and POP payloads is OPTIONAL.
上記のように、メンバーは、フェーズ1のIDとは別のオプションの証明書ペイロードで、GroupKey-Pull ExchangeのIDを確立することができます。メンバーが新しい証明書を渡すと、所有証明（POP）ペイロードがそれに付随します。ポップペイロードは、メンバーまたはGCKがそれを認証する非常に秘密を使用していることを示しています。POP_Iは、メンバーが署名したNONS NIおよびNRを含むハッシュを含むISAKMP SIGペイロードであり、メンバーが認可を証明するためにグループ所有者によって署名された証明書を通過したとき。POP_Rには、GCKSがグループ所有者が署名した証明書を通過したときに、GCKSが署名した連結されたNONS NIおよびNRを含むハッシュが含まれ、特定のグループにキーを提供する権限を証明します。擬似ランダム関数（PRF）および暗号化されたポップペイロードに変換されたPOPペイロードに使用されているのは、フェーズ1キーの妥協に耐えるように設計されています。CERTおよびPOPペイロードの実装はオプションです。
If PFS is desired and the optional KE payload is used in the exchange, then both sides compute a DH secret and use it to protect the new keying material contained in KD. The GCKS responder will xor the DH secret with the KD payload and send it to the member Initiator, which recovers the KD by repeating this operation as in the Oakley IEXTKEY procedure [RFC2412]. Implementation of the KE payload is OPTIONAL.
PFSが必要であり、オプションのKEペイロードが交換で使用されている場合、両側はDH秘密を計算し、それを使用してKDに含まれる新しいキーイング材料を保護します。GCKSレスポンダーは、KDペイロードでDHシークレットをXRし、メンバーイニシエーターに送信します。これは、Oakley Iextkey手順[RFC2412]のようにこの操作を繰り返すことでKDを回復します。KEペイロードの実装はオプションです。
Cookies are used in the ISAKMP header as a weak form of denial of service protection. The GDOI GROUPKEY-PULL exchange uses cookies according to ISAKMP [RFC2408].
Cookieは、ISAKMPヘッダーで、サービス拒否の保護の弱い形態として使用されます。GDOI GroupKey-Pull Exchangeは、ISAKMP [RFC2408]に従ってCookieを使用しています。
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
次のペイロードは、ISAKMPまたはGDOIペイロードを識別します（セクション5.0を参照）。
Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408, Section 3.1].
メジャーバージョンは1で、マイナーバージョンはISAKMP [RFC2408、セクション3.1]によると0です。
The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange.
交換タイプは、GDOI GroupKey-Pull Exchangeの値32です。
Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section 3.1]
フラグ、メッセージID、および長さはISAKMPに従っています[RFC2408、セクション3.1]
Before a group member (GDOI initiator) contacts the GCKS, it must determine the group identifier and acceptable Phase 1 policy via an out-of-band method such as SDP. Phase 1 is initiated using the GDOI DOI in the SA payload. Once Phase 1 is complete, the initiator state machine moves to the GDOI protocol.
グループメンバー（GDOIイニシエーター）がGCKSに連絡する前に、SDPなどのバンド外のメソッドを介してグループ識別子と許容可能なフェーズ1ポリシーを決定する必要があります。フェーズ1は、SAペイロードでGDOI DOIを使用して開始されます。フェーズ1が完了すると、イニシエーターステートマシンはGDOIプロトコルに移動します。
To construct the first GDOI message the initiator chooses Ni and creates a nonce payload, builds an identity payload including the group identifier, and generates HASH(1).
最初のGDOIメッセージを作成するには、イニシエーターはNIを選択し、非CEペイロードを作成し、グループ識別子を含むIDペイロードを構築し、ハッシュ（1）を生成します。
Upon receipt of the second GDOI message, the initiator validates HASH(2), extracts the nonce Nr, and interprets the SA payload. If the policy in the SA payload is acceptable (e.g., the security protocol and cryptographic protocols can be supported by the initiator), the initiator continues the protocol.
2番目のGDOIメッセージを受信すると、イニシエーターはハッシュ（2）を検証し、ノンセNRを抽出し、SAペイロードを解釈します。SAペイロードのポリシーが許容できる場合（たとえば、セキュリティプロトコルと暗号化プロトコルをイニシエーターによってサポートできます）、イニシエーターはプロトコルを継続します。
If the group policy uses certificates for authorization, the initiator generates a hash including Ni and Nr and signs it. This becomes the contents of the POP payload. If necessary, a CERT payload is constructed which holds the public key corresponding to the private key used to sign the POP payload.
グループポリシーが承認のために証明書を使用している場合、イニシエーターはNiおよびNRを含むハッシュを生成し、それに署名します。これがポップペイロードの内容になります。必要に応じて、ポップペイロードに署名するために使用される秘密鍵に対応する公開キーを保持する証明書のペイロードが構築されます。
The initiator constructs the third GDOI message by including the CERT and POP payloads (if needed) and creating HASH(3).
イニシエーターは、CERTおよびPOPペイロード（必要に応じて）を含めてハッシュ（3）を作成することにより、3番目のGDOIメッセージを作成します。
Upon receipt of the fourth GDOI message, the initiator validates HASH(4). If the responder sent CERT and POP_R payloads, the POP signature is validated.
4番目のGDOIメッセージを受信すると、イニシエーターはハッシュ（4）を検証します。ResponderがCERTおよびPOP_Rペイロードを送信した場合、POP署名が検証されます。
If SEQ payload is present, the sequence number in the SEQ payload must be checked against any previously received sequence number for this group. If it is less than the previously received number, it should be considered stale and ignored. This could happen if two GROUPKEY-PULL messages happened in parallel, and the sequence number changed between the times the results of two GROUPKEY-PULL messages were returned from the GCKS.
配列ペイロードが存在する場合、このグループの以前に受信したシーケンス番号に対して、配列ペイロードのシーケンス番号を確認する必要があります。以前に受け取った数よりも少ない場合は、古くなって無視する必要があります。これは、2つのGroupKey-Pullメッセージが並行して発生し、GCKSから2つのGroupKey-Pullメッセージの結果が返された時間の間にシーケンス数が変更された場合に発生する可能性があります。
The initiator interprets the KD key packets, matching the SPIs in the key packets to SPIs previously sent in the SA payloads identifying particular policy. For TEKs, once the keys and policy are matched, the initiator is ready to send or receive packets matching the TEK policy. (If policy and keys had been previously received for this TEK policy, the initiator may decide instead to ignore this TEK policy in case it is stale.) If this group has a KEK, the KEK policy and keys are marked as ready for use.
イニシエーターはKDキーパケットを解釈し、キーパケットのSPIを以前に特定のポリシーを特定するSAペイロードで以前に送信したSPIに一致させます。TEKの場合、キーとポリシーが一致すると、イニシエーターはTEKポリシーに一致するパケットを送信または受信する準備ができています。（このTEKポリシーのポリシーとキーが以前に受信されていた場合、イニシエーターは、このTEKポリシーが古くなった場合に代わりにこのTEKポリシーを無視することを決定する場合があります。）このグループにKEKがある場合、KEKポリシーとキーは使用の準備ができているとマークされます。
The GCKS (responder) passively listens for incoming requests from group members. The Phase 1 authenticates the group member and sets up the secure session with them.
GCKS（レスポンダー）は、グループメンバーからの着信要求を受動的に耳にします。フェーズ1はグループメンバーを認証し、安全なセッションをセットアップします。
Upon receipt of the first GDOI message the GCKS validates HASH(1), extracts the Ni and group identifier in the ID payload. It verifies that its database contains the group information for the group identifier.
最初のGDOIメッセージを受信すると、GCKSはハッシュ（1）を検証し、IDペイロードでNIおよびグループ識別子を抽出します。これは、そのデータベースにグループ識別子のグループ情報が含まれていることを確認します。
The GCKS constructs the second GDOI message, including a nonce Nr, and the policy for the group in an SA payload, followed by SA TEK payloads for traffic SAs, and SA KEK policy (if the group controller will be sending Re-key messages to the group).
GCKSは、NonCE NRを含む2番目のGDOIメッセージとSAペイロード内のグループのポリシーを構築し、その後、トラフィックSASのSA TEKペイロード、およびSA KEKポリシー（グループコントローラーが再キーメッセージを送信する場合グループ）。
Upon receipt of the third GDOI message the GCKS validates HASH(3). If the initiator sent CERT and POP_I payloads, the POP signature is validated.
3番目のGDOIメッセージを受信すると、GCKSはハッシュ（3）を検証します。イニシエーターがCERTおよびPOP_Iペイロードを送信した場合、POP署名が検証されます。
The GCKS constructs the fourth GDOI message, including the SEQ payload (if the GCKS sends rekey messages), the KD payload containing keys corresponding to policy previously sent in the SA TEK and SA KEK payloads, and the CERT and POP payloads (if needed).
GCKSは、SEQペイロード（GCKSがRekeyメッセージを送信する場合）、SA TEKおよびSA KEKペイロードで以前に送信されたポリシーに対応するKDペイロードを含むKDペイロードを含む4番目のGDOIメッセージを構築します。。
GDOI sends control information securely using group communications. Typically this will be using IP multicast distribution of a GROUPKEY-PUSH message but it can also be "pushed" using unicast delivery if IP multicast is not possible. The GROUPKEY-PUSH message replaces a Re-key SA KEK or KEK array, and/or creates a new Data-security SA.
GDOIは、グループ通信を使用して制御情報を安全に送信します。通常、これはGroupKey-PushメッセージのIPマルチキャスト分布を使用しますが、IPマルチキャストが不可能な場合は、ユニキャスト配信を使用して「プッシュ」することもできます。GroupKey-Pushメッセージは、recey sa kekまたはkekアレイを置き換え、新しいデータセキュリティSAを作成します。
Member GCKS or Delegate
------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
* Protected by the Re-key SA KEK; encryption occurs after HDR
* 再キーケクによって保護されています。暗号化はHDRの後に発生します
HDR is defined below. The SEQ payload is defined in the Payloads section. The SA defines the policy (e.g., protection suite) and attributes (e.g., SPI) for a Re-key and/or Data-security SAs. The GCKS or delegate optionally provides a CERT payload for verification of the SIG. KD is the key download payload as described in the Payloads section.
HDRは以下に定義されています。seqペイロードは、ペイロードセクションで定義されています。SAは、再キーおよび/またはデータセキュリティSASのポリシー（保護スイートなど）と属性（SPIなど）を定義します。GCKSまたは代表者は、オプションでSIGの検証のための証明書ペイロードを提供します。KDは、ペイロードセクションで説明されているキーダウンロードペイロードです。
The SIG payload is a signature of a hash of the entire message before encryption (including the header and excluding the SIG payload itself), prefixed with the string "rekey". The prefixed string ensures that the signature of the Rekey datagram cannot be used for any other purpose in the GDOI protocol.
SIGペイロードは、暗号化前のメッセージ全体のハッシュの署名（ヘッダーを含む、SIGペイロード自体を除く）で、文字列「Reke」を付けたものです。接頭辞付き文字列により、GDOIプロトコルの他の目的にRekeyデータグラムの署名を使用できないことが保証されます。
If the SA defines an LKH KEK array or single KEK, KD contains a KEK or KEK array for a new Re-key SA, which has a new cookie pair. When the KD payload carries a new SA KEK attribute (section 5.3), a Re-key SA is replaced with a new SA having the same group identifier (ID specified in message 1 of section 3.2) and incrementing the same sequence counter, which is initialized in message 4 of section 3.2. If the SA defines an SA TEK payload, this informs the member that a new Data-security SA has been created, with keying material carried in KD (Section 5.5).
SAがLKH KEKアレイまたはシングルKEKを定義する場合、KDには新しいCookieペアを持つ新しいキーSA用のKEKまたはKEKアレイが含まれています。KDペイロードが新しいSA Kek属性（セクション5.3）を運ぶと、同じグループ識別子（セクション3.2のメッセージ1で指定されたID）を持つ新しいSAに置き換えられ、同じシーケンスカウンターを増加させます。セクション3.2のメッセージ4で初期化されました。SAがSA Tekペイロードを定義している場合、これはメンバーに、KDでキーイング素材が運ばれ、新しいデータセキュリティSAが作成されたことを通知します（セクション5.5）。
If the SA defines a large LKH KEK array (e.g., during group initialization and batched rekeying), parts of the array MAY be sent in different unique GROUPKEY-PUSH datagrams. However, each of the GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH datagram. This results in each datagram containing a sequence number and the policy in the SA payload, which corresponds to the KEK array portion sent in the KD payload.
SAが大きなLKH KEKアレイを定義している場合（たとえば、グループ初期化やバッチの再キーイング中に）、アレイの一部を異なるユニークなGroupKey-Pushデータグラムで送信できます。ただし、GroupKey-Pushの各データグラムは、完全に形成されたGroupKey-Pushデータグラムである必要があります。これにより、各データグラムは、SAペイロードにシーケンス番号とポリシーを含む結果として、KDペイロードで送信されたKEKアレイ部分に対応します。
The GROUPKEY-PUSH message is protected by the group KEK though in all cases, the GROUPKEY-PUSH message carries new key downloads, among other information. A freshly generated secret must protect the key download for the GROUPKEY-PUSH message to have PFS. This issue is for further study.
GroupKey-PushメッセージはグループKekによって保護されていますが、すべての場合において、GroupKey-Pushメッセージには新しいキーダウンロードなどがあります。新たに生成された秘密は、PFSを持つためにGroupKey-Pushメッセージのキーダウンロードを保護する必要があります。この問題は、さらなる研究のためです。
Through GROUPKEY-PUSH, the GDOI supports algorithms such as LKH that have the property of denying access to a new group key by a member removed from the group (forward access control) and to an old group key by a member added to the group (backward access control). An unrelated notion to PFS, "forward access control" and "backward access control" have been called "perfect forward security" and "perfect backward security" in the literature [RFC2627].
GroupKey-Pushを介して、GDOIは、グループから削除されたメンバーによる新しいグループキーへのアクセスを拒否する特性（フォワードアクセス制御）とグループに追加されたメンバーによる古いグループキー（古いグループキー）（グループに追加された）（LKHなどのアルゴリズム）をサポートしています。後方アクセス制御）。PFSに対する無関係な概念、「フォワードアクセスコントロール」および「後方アクセス制御」は、文献の「完全なフォワードセキュリティ」と「完全な後方セキュリティ」と呼ばれています[RFC2627]。
Group management algorithms providing forward and backward access control other than LKH have been proposed in the literature, including OFT [OFT] and Subset Difference [NNL]. These algorithms could be used with GDOI, but are not specified as a part of this document.
LKH以外の前方および後方アクセス制御を提供するグループ管理アルゴリズムは、OFT [OFT]やサブセットの差[NNL]を含む文献で提案されています。これらのアルゴリズムはGDOIで使用できますが、このドキュメントの一部として指定されていません。
Support for group management algorithms is supported via the KEY_MANAGEMENT_ALGORITHM attribute which is sent in the SA_KEK payload. GDOI specifies one method by which LKH can be used for forward and backward access control. Other methods of using LKH, as well as other group management algorithms such as OFT or Subset Difference may be added to GDOI as part of a later document. Any such addition MUST be due to a Standards Action as defined in [RFC2434].
グループ管理アルゴリズムのサポートは、sa_kekペイロードで送信されるkey_management_algorithm属性を介してサポートされます。GDOIは、LKHを前方および後方アクセス制御に使用できる1つの方法を指定します。LKHを使用する他の方法、およびOFTやサブセットの差などの他のグループ管理アルゴリズムは、後のドキュメントの一部としてGDOIに追加される場合があります。このような追加は、[RFC2434]で定義されている標準訴訟が原因でなければなりません。
When group membership is altered using a group management algorithm new SA_TEKs (and their associated keys) are usually also needed. New SAs and keys ensure that members who were denied access can no longer participate in the group.
グループ管理アルゴリズムを使用してグループメンバーシップが変更されると、新しいSA_TEK（および関連するキー）も通常必要です。新しいSASとキーは、アクセスを拒否されたメンバーがグループに参加できなくなることを保証します。
If forward access control is a desired property of the group, new SA_TEKs and the associated key packets in the KD payload MUST NOT be included in a GROUPKEY-PUSH message which changes group membership. This is required because the SA_TEK policy and the associated key packets in the KD payload are not protected with the new KEK. A second GROUPKEY-PUSH message can deliver the new SA_TEKS and their associated keys because it will be protected with the new KEK, and thus will not be visible to the members who were denied access.
フォワードアクセス制御がグループの目的のプロパティである場合、新しいSA_TEKSとKDペイロードの関連キーパケットをグループメンバーシップを変更するグループキープッシュメッセージに含めてはなりません。これは、SA_TEKポリシーとKDペイロードの関連するキーパケットが新しいKEKで保護されていないためです。2番目のGroupKey-Pushメッセージは、新しいKekで保護されるため、新しいSA_TEKSとそれに関連するキーを配信できます。したがって、アクセスを拒否されたメンバーには表示されません。
If forward access control policy for the group includes keeping group policy changes from members that are denied access to the group, then two sequential GROUPKEY-PUSH messages changing the group KEK MUST be sent by the GCKS. The first GROUPKEY-PUSH message creates a new KEK for the group. Group members, which are denied access, will not be able to access the new KEK, but will see the group policy since the GROUPKEY-PUSH message is protected under the current KEK. A subsequent GROUPKEY-PUSH message containing the changed group policy and again changing the KEK allows complete forward access control. A GROUPKEY-PUSH message MUST NOT change the policy without creating a new KEK.
グループのフォワードアクセス制御ポリシーには、グループへのアクセスを拒否されたメンバーからグループポリシーの変更を維持することが含まれている場合、グループを変更する2つのシーケンシャルグループプッシュメッセージは、GCKSによって送信されなければなりません。最初のGroupKey-Pushメッセージは、グループの新しいKekを作成します。アクセスが拒否されているグループメンバーは、新しいKEKにアクセスすることはできませんが、現在のKEKの下でGroupKey-Pushメッセージが保護されているため、グループポリシーが表示されます。変化したグループポリシーを含むその後のGroupKey-PushメッセージとKEKを再度変更すると、完全なフォワードアクセス制御が可能になります。GroupKey-Pushメッセージは、新しいKekを作成せずにポリシーを変更してはなりません。
If other methods of using LKH or other group management algorithms are added to GDOI, those methods MAY remove the above restrictions requiring multiple GROUPKEY-PUSH messages, providing those methods specify how forward access control policy is maintained within a single GROUPKEY-PUSH message.
LKHまたは他のグループ管理アルゴリズムをGDOIに使用する他の方法がGDOIに追加された場合、それらの方法は複数のGroupKey-Pushメッセージを必要とする上記の制限を削除する場合があり、それらのメソッドは、単一のGroupKey-Pushメッセージ内でフォワードアクセス制御ポリシーがどのように維持されるかを指定します。
GDOI supports delegation of GROUPKEY-PUSH datagrams through the delegation capabilities of the PKI. However, GDOI does not explicitly specify how the GCKS identifies delegates, but leaves this to the PKI that is used by a particular GDOI implementation.
GDOIは、PKIの委任機能を通じてGroupKey-Pushデータグラムの委任をサポートしています。ただし、GDOIはGCKSが代表者を識別する方法を明示的に指定していませんが、特定のGDOI実装で使用されるPKIにこれを任せます。
The GCKS SHOULD NOT use the same key to sign the SIG payload in the GROUPKEY-PUSH message as was used for authorization in the GROUPKEY-PULL POP payload. If the same key must be used, a different hash function SHOULD be used as a base for the POP payload than is used as a base for the SIG payload.
GCKSは、GroupKey-Pull POPペイロードの承認に使用されたように、GroupKey-PushメッセージのSIGペイロードに署名するために同じキーを使用してはなりません。同じキーを使用する必要がある場合、SIGペイロードのベースとして使用されるよりも、異なるハッシュ関数をポップペイロードのベースとして使用する必要があります。
Unlike ISAKMP or IKE, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Re-key SA to differentiate the secure groups managed by a GCKS. Thus, GDOI uses the cookie fields as an SPI.
ISAKMPやIKEとは異なり、CookieペアはGCKSによって完全に決定されます。GDOI ISAKMPヘッダーのCookieペアは、GCKSによって管理されている安全なグループを区別するためにRekey SAを識別します。したがって、GDOIはSPIとしてCookieフィールドを使用します。
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
次のペイロードは、ISAKMPまたはGDOIペイロードを識別します（セクション5.0を参照）。
Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408, Section 3.1].
メジャーバージョンは1で、マイナーバージョンはISAKMP [RFC2408、セクション3.1]によると0です。
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message.
Exchangeタイプには、GDOI GroupKey-Pushメッセージの値33があります。
Flags MUST have the Encryption bit set according to [RFC2008, Section 3.1]. All other bits MUST be set to zero.
フラグには、[RFC2008、セクション3.1]に従って暗号化ビットを設定する必要があります。他のすべてのビットはゼロに設定する必要があります。
Message ID MUST be set to zero.
メッセージIDはゼロに設定する必要があります。
Length is according to ISAKMP [RFC2408, Section 3.1]
長さはISAKMPによる[RFC2408、セクション3.1]
There are times the GCKS may want to signal to receivers to delete SAs, for example at the end of a broadcast. Deletion of keys may be accomplished by sending an ISAKMP Delete payload [RFC2408, Section 3.15] as part of a GDOI GROUPKEY-PUSH message.
たとえば、放送の終了時に、GCKが受信機にSASを削除するように信号を送信したい場合があります。キーの削除は、GDOI GroupKey-Pushメッセージの一部としてISAKMP削除ペイロード[RFC2408、セクション3.15]を送信することで実現できます。
One or more Delete payloads MAY be placed following the SEQ payload in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to group members, the SA and KD payloads MUST be omitted from the message.
GroupKey-Pushメッセージの配分ペイロードに続いて、1つ以上の削除ペイロードを配置できます。GCKSにグループメンバーに送信するSASがこれ以上ない場合、メッセージからSAとKDのペイロードを省略する必要があります。
The following fields of the Delete Payload are further defined as follows:
削除ペイロードの次のフィールドは、次のようにさらに定義されています。
o The Domain of Interpretation field contains the GDOI DOI.
o 解釈フィールドのドメインには、GDOI DOIが含まれています。
o The Protocol-Id field contains TEK protocol id values defined in Section 5.4 of this document. To delete a KEK SA, the value of zero MUST be used as the protocol id. Note that only one protocol id value can be defined in a Delete payload. If a TEK SA and a KEK SA must be deleted, they must be sent in different Delete payloads.
o プロトコルIDフィールドには、このドキュメントのセクション5.4で定義されているTEKプロトコルID値が含まれています。Kek SAを削除するには、ゼロの値をプロトコルIDとして使用する必要があります。削除ペイロードで定義できるプロトコルID値は1つだけであることに注意してください。Tek SAとKek SAを削除する必要がある場合は、異なる削除ペイロードで送信する必要があります。
GCKS or its delegate may initiate a Rekey message for one of several reasons, e.g., the group membership has changed or keys are due to expire.
GCKSまたはその代表者は、いくつかの理由のいずれかで再キーメッセージを開始する場合があります。たとえば、グループメンバーシップが変更されたか、キーが期限切れになるためです。
To begin the rekey datagram the GCKS builds an ISAKMP HDR with the correct cookie pair, and a SEQ payload that includes a sequence number which is one greater than the previous rekey datagram.
Rekeyデータグラムを開始するために、GCKSは正しいCookieペアを備えたISAKMP HDRと、以前のReke Datagramよりも大きいシーケンス番号を含むSEQペイロードを構築します。
An SA payload is then added. This is identical in structure and meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there are changes to the KEK (in the case of a static KEK) or in group membership (in the case of LKH) an SA_KEK attribute is added to the SA. If there are one or more new TEKs then SA_TEK attributes are added to describe that policy.
その後、SAペイロードが追加されます。これは、GroupKey-Pull Exchangeで送信されたSAペイロードと構造と意味が同一です。KEK（静的KEKの場合）またはグループメンバーシップ（LKHの場合）に変更がある場合、SA_KEK属性がSAに追加されます。1つ以上の新しいTEKがある場合、そのポリシーを説明するためにSA_TEK属性が追加されます。
A KD payload is then added. This is identical in structure and meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an SA_KEK attribute was included in the SA payload then corresponding KEK keys (or a KEK array) is included. TEK keys are sent for each SA_TEK attribute included in the SA payload.
その後、KDペイロードが追加されます。これは、GroupKey-Pull Exchangeで送信されたKDペイロードと構造と意味が同一です。SA_KEK属性がSAペイロードに含まれている場合、対応するKEKキー（またはKEKアレイ）が含まれています。TEKキーは、SAペイロードに含まれる各SA_TEK属性に対して送信されます。
A CERT payload is added if the initiator needs to provide its certificate.
イニシエーターが証明書を提供する必要がある場合、証明書のペイロードが追加されます。
In the penultimate step, the initiator hashes the string "rekey" followed by the key management message already formed. The hash is signed, placed in a SIG payload and added to the datagram.
最後から2番目のステップでは、イニシエーターは文字列「Reke」をハッシュし、その後にすでに形成されているキー管理メッセージが続きます。ハッシュに署名され、SIGペイロードに配置され、データグラムに追加されます。
Lastly, the payloads following the HDR are encrypted using the current KEK encryption key. The datagram can now be sent.
最後に、HDRに続くペイロードは、現在のKek暗号化キーを使用して暗号化されます。これで、データグラムを送信できます。
A group member receiving the GROUPKEY-PUSH datagram matches the cookie pair in the ISAKMP HDR to an existing SA. The message is decrypted, and the form of the datagram is validated. This weeds out obvious ill-formed messages (which may be sent as part of a Denial of Service attack on the group).
GroupKey-Push Datagramを受信したグループメンバーは、ISAKMP HDRのCookieペアと既存のSAに一致します。メッセージは復号化され、データグラムの形式が検証されます。これにより、明らかな不正なメッセージが除去されます（これは、グループに対するサービス拒否攻撃の一部として送信される場合があります）。
The signature of the decrypted message is then validated, possibly using the CERT payload if it is included.
次に、復号化されたメッセージの署名が検証され、おそらくそれが含まれている場合はCERTペイロードを使用します。
The sequence number in the SEQ payload is validated to ensure that it is greater than the previously received sequence number, and that it fits within a window of acceptable values.
配列ペイロードのシーケンス番号は、以前に受信したシーケンス番号よりも大きいことを確認し、許容値のウィンドウ内に収まることを確認するために検証されます。
The SA and KD payloads are processed which results in a new GDOI Rekey SA (if the SA payload included an SA_KEK attribute) and/or new IPsec SAs being added to the system.
SAおよびKDペイロードは処理され、新しいGDOI Reke SA（SAペイロードにSA_KEK属性が含まれている場合）および/または新しいIPSEC SASがシステムに追加されます。
This document specifies use of several ISAKMP payloads, which are defined in accordance with RFC2408. The following payloads are extended or further specified.
このドキュメントは、RFC2408に従って定義されているいくつかのISAKMPペイロードの使用を指定しています。次のペイロードが拡張またはさらに指定されています。
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10
Several new payload formats are required in the group security exchanges.
グループセキュリティ交換には、いくつかの新しいペイロード形式が必要です。
Next Payload Type Value
----------------- -----
SA KEK Payload (SAK) 15
SA TEK Payload (SAT) 16
Key Download (KD) 17
Sequence Number (SEQ) 18
Proof of Possession (POP) 19
The Identification Payload is used to identify a group identity that will later be associated with Security Associations for the group. A group identity may map to a specific IP multicast group, or may specify a more general identifier, such as one that represents a set of related multicast streams.
識別ペイロードは、後にグループのセキュリティ協会に関連付けられるグループIDを識別するために使用されます。グループIDは、特定のIPマルチキャストグループにマッピングされる場合や、関連するマルチキャストストリームのセットを表すものなど、より一般的な識別子を指定する場合があります。
The Identification Payload is defined as follows:
識別ペイロードは次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVE2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Identification Payload fields are defined as follows:
識別ペイロードフィールドは、次のように定義されています。
o 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, this field will be zero (0).
o 次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドはゼロ（0）になります。
o RESERVED (1 octet) -- Unused, must be zero (0).
o 予約済み（1オクテット） - 未使用、ゼロ（0）でなければなりません。
o Payload Length (2 octets) -- Length, in octets, of the identification data, including the generic header.
o ペイロード長（2オクテット） - 一般的なヘッダーを含む識別データの長さ、オクテットの長さ。
o Identification Type (1 octet) -- Value describing the identity information found in the Identification Data field.
o 識別タイプ（1オクテット） - 識別データフィールドにあるID情報を説明する値。
o RESERVED2 (2 octets) -- Unused, must be zero (0).
o Reserved2（2オクテット） - 未使用、ゼロ（0）でなければなりません。
o Identification Data (variable length) -- Value, as indicated by the Identification Type.
o 識別データ（変数長） - 識別タイプで示されているように。
The following table lists the assigned values for the Identification Type field found in the Identification Payload.
次の表には、識別ペイロードで見つかった識別型フィールドに割り当てられた値を示します。
ID Type Value
------- -----
RESERVED 0 - 10
ID_KEY_ID 11
RESERVED 12 - 127
Private Use 128 - 255
In the context of a GDOI ID payload, ID_KEY_ID specifies a four (4)-octet group identifier.
GDOI IDペイロードのコンテキストでは、ID_KEY_IDは4（4）-OCTETグループ識別子を指定します。
The Security Association payload is defined in RFC 2408. For the GDOI, it is used by the GCKS to assert security attributes for both Re-key and Data-security SAs.
セキュリティ協会のペイロードはRFC 2408で定義されています。GDOIの場合、GCKSによって使用されて、再キーとデータセキュリティSAの両方のセキュリティ属性を主張します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DOI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SA Attribute Next Payload ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The Security Association Payload fields are defined as follows:
セキュリティ協会のペイロードフィールドは、次のように定義されています。
o Next Payload (1 octet) -- Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The next payload MUST NOT be a SAK Payload or SAT Payload type, but the next non-Security Association type payload.
o 次のペイロード（1 Octet） - 上記で定義されているように、GroupKey-PullまたはGroupKey-Pushメッセージの次のペイロードを識別します。次のペイロードは、SAKペイロードまたはSATペイロードタイプではなく、次の非セキュリティアソシエーションタイプのペイロードである必要があります。
o RESERVED (1 octet) -- Must be zero.
o 予約済み（1オクテット） - ゼロでなければなりません。
o Payload Length (2 octets) -- Is the octet length of the current payload including the generic header and all TEK and KEK payloads.
o ペイロード長（2オクテット） - 一般的なヘッダーとすべてのTekおよびKekペイロードを含む、現在のペイロードのオクテット長です。
o DOI (4 octets) -- Is the GDOI, which is value 2.
o doi（4オクテット） - はgdoiであり、値2です。
o Situation (4 octets) -- Must be zero.
o 状況（4オクテット） - ゼロでなければなりません。
o SA Attribute Next Payload (1 octet) -- Must be either a SAK Payload or a SAT Payload. See section 5.2.1 for a description of which circumstances are required for each payload type to be present.
o SA属性次のペイロード（1 Octet） - SAKペイロードまたはSATペイロードのいずれかでなければなりません。各ペイロードタイプが存在するために必要な状況の説明については、セクション5.2.1を参照してください。
o RESERVED (2 octets) -- Must be zero.
o 予約済み（2オクテット） - ゼロでなければなりません。
Payloads that define specific security association attributes for the KEK and/or TEKs used by the group MUST follow the SA payload. How many of each payload is dependent upon the group policy. There may be zero or one SAK Payloads, and zero or more SAT Payloads, where either one SAK or SAT payload MUST be present.
グループが使用するKEKおよび/またはTEKの特定のセキュリティ協会属性を定義するペイロードは、SAペイロードに従う必要があります。各ペイロードの数はグループポリシーに依存しています。ゼロまたは1つのSAKペイロード、およびゼロ以上のSATペイロードがある場合があります。
This latitude allows various group policies to be accommodated. For example if the group policy does not require the use of a Re-key SA, the GCKS would not need to send an SA KEK attribute to the group member since all SA updates would be performed using the Registration SA. Alternatively, group policy might use a Re-key SA but choose to download a KEK to the group member only as part of the Registration SA. Therefore, the KEK policy (in the SA KEK attribute) would not be necessary as part of the Re-key SA message SA payload.
この緯度により、さまざまなグループポリシーが対応できます。たとえば、グループポリシーがRECEY SAの使用を必要としない場合、GCKSはすべてのSAアップデートが登録SAを使用して実行されるため、SA KEK属性をグループメンバーに送信する必要はありません。あるいは、グループポリシーはReCey SAを使用する場合がありますが、登録SAの一部としてのみグループメンバーにKEKをダウンロードすることを選択します。したがって、Kekポリシー（SA KEK属性）は、再キーサのメッセージSAペイロードの一部として必要ありません。
Specifying multiple SATs allows multiple sessions to be part of the same group and multiple streams to be associated with a session (e.g., video, audio, and text) but each with individual security association policy.
複数のSATを指定することで、複数のセッションが同じグループの一部になり、複数のストリームがセッション（ビデオ、オーディオ、テキストなど）に関連付けられますが、それぞれが個々のセキュリティ協会のポリシーに関連付けられます。
The SA KEK (SAK) payload contains security attributes for the KEK method for a group and parameters specific to the GROUPKEY-PULL operation. The source and destination identities describe the identities used for the GROUPKEY-PULL datagram.
SA KEK（SAK）ペイロードには、グループキープル操作に固有のグループのKEKメソッドのセキュリティ属性が含まれています。ソースと宛先のアイデンティティは、GroupKey-Pullデータグラムに使用されるIDを説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! !
~ SPI ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! POP Algorithm ! POP Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAK Payload fields are defined as follows:
SAKペイロードフィールドは次のように定義されています。
o Next Payload (1 octet) -- Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next payload types for this message are a SAT Payload or zero to indicate there is no SA TEK payload.
o 次のペイロード（1 Octet） - GroupKey-PullまたはGroupKey-Pushメッセージの次のペイロードを識別します。このメッセージの唯一の有効な次のペイロードタイプは、SAテックペイロードがないことを示すためのSATペイロードまたはゼロです。
o RESERVED (1 octet) -- Must be zero.
o 予約済み（1オクテット） - ゼロでなければなりません。
o Payload Length (2 octets) -- Length of this payload, including the KEK attributes.
o ペイロード長（2オクテット） - KEK属性を含むこのペイロードの長さ。
o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP) for the rekey datagram.
o Protocol（1 Octet） - RekeyデータグラムのIPプロトコルID（UDP/TCPなど）を説明する値。
o SRC ID Type (1 octet) -- Value describing the identity information found in the SRC Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG].
o SRC IDタイプ（1オクテット） - SRC識別データフィールドで見つかったID情報を説明する値。定義された値は、IANA ISAKMPD-REGISTRY [ISAKMP-REG]のIPSEC識別タイプセクションによって指定されます。
o SRC ID Port (2 octets) -- Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field should be ignored.
o SRC IDポート（2オクテット） - ソースIDに関連付けられたポートを指定する値。ゼロの値は、SRC IDポートフィールドを無視する必要があることを意味します。
o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC Identification Data field.
o SRC ID Data Len（1 Octet） - SRC識別データフィールドの長さを指定する値。
o SRC Identification Data (variable length) -- Value, as indicated by the SRC ID Type.
o SRC IDタイプで示されるように、SRC識別データ（変数長） - 値。
o DST ID Type (1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG].
o DST IDタイプ（1 Octet） - DST識別データフィールドで見つかったID情報を説明する値。定義された値は、IANA ISAKMPD-REGISTRY [ISAKMP-REG]のIPSEC識別タイプセクションによって指定されます。
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP).
o DST ID PROT（1 OCTET） - IPプロトコルID（UDP/TCPなど）を説明する値。
o DST ID Port (2 octets) -- Value specifying a port associated with the source Id.
o DST IDポート（2オクテット） - ソースIDに関連付けられたポートを指定する値。
o DST ID Data Len (1 octet) -- Value specifying the length of the DST Identification Data field.
o DST ID Data Len（1 Octet） - DST識別データフィールドの長さを指定する値。
o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type.
o DST IDタイプで示されるDST識別データ（変数長） - 値。
o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI must be the ISAKMP Header cookie pair where the first 8 octets become the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, and the second 8 octets become the "Responder Cookie" in the same HDR. As described above, these cookies are assigned by the GCKS.
o SPI（16オクテット） - KEKのセキュリティパラメーターインデックス。SPIはISAKMPヘッダーCookieペアでなければなりません。最初の8オクテットがGroupKey-PushメッセージISAKMP HDRの「イニシエータークッキー」フィールドになり、2番目の8オクテットが同じHDRの「Responder Cookie」になります。上記のように、これらのCookieはGCKSによって割り当てられます。
o POP Algorithm (2 octets) -- The POP payload algorithm. Defined values are specified in the following table. If no POP algorithm is defined by the KEK policy this field must be zero.
o ポップアルゴリズム（2オクテット） - ポップペイロードアルゴリズム。定義された値を次の表に指定します。KEKポリシーでポップアルゴリズムが定義されていない場合、このフィールドはゼロでなければなりません。
Algorithm Type Value
-------------- -----
RESERVED 0
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
o POP Key Length (2 octets) -- Length of the POP payload key. If no POP algorithm is defined in the KEK policy, this field must be zero.
o ポップキーの長さ（2オクテット） - ポップペイロードキーの長さ。KEKポリシーでポップアルゴリズムが定義されていない場合、このフィールドはゼロでなければなりません。
o KEK Attributes -- Contains KEK policy attributes associated with the group. The following sections describe the possible attributes. Any or all attributes may be optional, depending on the group policy.
o KEK属性 - グループに関連付けられたKEKポリシー属性が含まれています。次のセクションでは、考えられる属性について説明します。グループポリシーに応じて、任意またはすべての属性がオプションである場合があります。
The following attributes may be present in a SAK Payload. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes that are defined as TV are marked as Basic (B); attributes that are defined as TLV are marked as Variable (V).
次の属性は、SAKペイロードに存在する場合があります。属性は、ISAKMP [RFC2408]セクション3.3で定義されている形式に従う必要があります。テーブルでは、テレビとして定義される属性は基本（b）としてマークされています。TLVとして定義される属性は、変数（v）としてマークされます。
ID Class Value Type
-------- ----- ----
RESERVED 0
KEK_MANAGEMENT_ALGORITHM 1 B
KEK_ALGORITHM 2 B
KEK_KEY_LENGTH 3 B
KEK_KEY_LIFETIME 4 V
SIG_HASH_ALGORITHM 5 B
SIG_ALGORITHM 6 B
SIG_KEY_LENGTH 7 B
KE_OAKLEY_GROUP 8 B
The following attributes may only be included in a GROUPKEY-PULL message: KEK_MANAGEMENT_ALGORITHM, KE_OAKLEY_GROUP.
以下の属性は、GroupKey-Pullメッセージにのみ含めることができます：kek_management_algorithm、ke_oakley_group。
The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management algorithm used to provide forward or backward access control (i.e., used to exclude group members). Defined values are specified in the following table.
kek_management_algorithmクラスは、順方向または後方アクセスコントロールを提供するために使用されるグループKEK管理アルゴリズムを指定します（つまり、グループメンバーを除外するために使用）。定義された値を次の表に指定します。
KEK Management Type Value
------------------- -----
RESERVED 0
LKH 1
RESERVED 2-127
Private Use 128-255
The KEK_ALGORITHM class specifies the encryption algorithm using with the KEK. Defined values are specified in the following table.
KEK_ALGORITHMクラスは、KEKで使用して暗号化アルゴリズムを指定します。定義された値を次の表に指定します。
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_AES 3
RESERVED 4-127
Private Use 128-255
A GDOI implementation MUST support the KEK_ALG_3DES algorithm attribute.
GDOI実装は、KEK_ALG_3DESアルゴリズム属性をサポートする必要があります。
If a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys (e.g., LKH), and if the management algorithm does not specify the algorithm for those keys, then the algorithm defined by the KEK_ALGORITHM attribute MUST be used for all keys which are included as part of the management.
複数のキー（例：LKH）を定義するkek_management_algorithmが定義されている場合、管理アルゴリズムがそれらのキーのアルゴリズムを指定していない場合、KEK_ALGORITHM属性によって定義されるアルゴリズムは、すべてのキーに使用される必要があります。管理。
This algorithm specifies DES using the Cipher Block Chaining (CBC) mode as described in [FIPS81].
このアルゴリズムは、[FIPS81]で説明されているように、暗号ブロックチェーン（CBC）モードを使用してDESを指定します。
This algorithm specifies 3DES using three independent keys as described in "Keying Option 1" in [FIPS46-3].
このアルゴリズムは、[FIPS46-3]の「キーイングオプション1」で説明されているように、3つの独立したキーを使用して3DEを指定します。
This algorithm specifies AES as described in [FIPS197]. The mode of operation for AES is Cipher Block Chaining (CBC) as recommended in [AES-MODES].
このアルゴリズムは、[FIPS197]で説明されているAESを指定します。AESの動作モードは、[AES-Modes]で推奨されるように、暗号ブロックチェーン（CBC）です。
The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in bits).
kek_key_lengthクラスは、KEKアルゴリズムのキー長（ビット）を指定します。
The KEK_KEY_LIFETIME class specifies the maximum time for which the KEK is valid. The GCKS may refresh the KEK at any time before the end of the valid period. The value is a four (4) octet number defining a valid time period in seconds.
kek_key_lifetimeクラスは、kekが有効な最大時間を指定します。GCKSは、有効期間の終了前にいつでもKEKを更新する場合があります。値は、秒単位で有効な期間を定義する4つのオクテット数です。
SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The following tables define the algorithms for SIG_HASH_ALGORITHM.
SIG_HASH_ALGORITHM SIGペイロードハッシュアルゴリズムを指定します。次の表は、sig_hash_algorithmのアルゴリズムを定義します。
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
RESERVED 3-127
Private Use 128-255
SIG_HASH_ALGORITHM is not required if the SIG_ALGORITHM is SIG_ALG_DSS or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1.
SIG_ALGORITHMがSIG_ALG_DSSまたはSIG_ALG_ECDSSである場合、SIG_ALGORITHMは必要ありません。これはSIG_HASH_SHA1を意味します。
The SIG_ALGORITHM class specifies the SIG payload signature algorithm. Defined values are specified in the following table.
SIG_ALGORITHMクラスは、SIGペイロード署名アルゴリズムを指定します。定義された値を次の表に指定します。
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
A GDOI implementation MUST support the following algorithm attribute: SIG_ALG_RSA.
GDOI実装は、次のアルゴリズム属性をサポートする必要があります：SIG_ALG_RSA。
This algorithm specifies the RSA digital signature algorithm as described in [RSA].
このアルゴリズムは、[RSA]で説明されているRSAデジタル署名アルゴリズムを指定します。
This algorithm specifies the DSS digital signature algorithm as described in [FIPS186-2].
このアルゴリズムは、[FIPS186-2]で説明されているDSSデジタル署名アルゴリズムを指定します。
This algorithm specifies the Elliptic Curve digital signature algorithm as described in [FIPS186-2].
このアルゴリズムは、[FIPS186-2]で説明されている楕円曲線デジタル署名アルゴリズムを指定します。
The SIG_KEY_LENGTH class specifies the length of the SIG payload key.
SIG_KEY_LENGTHクラスは、SIGペイロードキーの長さを指定します。
The KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute the PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL exchange. This attribute uses the values assigned to Group Definitions in the IANA IPsec-registry [IPSEC-REG].
KE_OAKLEY_GROUPクラスは、GDOI GroupKey-Pull ExchangeのオプションのKEペイロードでPFS秘密を計算するために使用されるOakleyグループを定義します。この属性は、IANA IPSEC-Registry [IPSEC-REG]のグループ定義に割り当てられた値を使用します。
The SA TEK (SAT) payload contains security attributes for a single TEK associated with a group.
SA TEK（SAT）ペイロードには、グループに関連付けられた単一のTEKのセキュリティ属性が含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAT Payload fields are defined as follows:
SATペイロードフィールドは次のように定義されています。
o Next Payload (1 octet) -- Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next payload types for this message are another SAT Payload or zero to indicate there are no more security association attributes.
o 次のペイロード（1 Octet） - GroupKey-PullまたはGroupKey-Pushメッセージの次のペイロードを識別します。このメッセージの有効な次のペイロードタイプは、別のSATペイロードまたはゼロであり、セキュリティ協会の属性がないことを示します。
o RESERVED (1 octet) -- Must be zero.
o 予約済み（1オクテット） - ゼロでなければなりません。
o Payload Length (2 octets) -- Length of this payload, including the TEK Protocol-Specific Payload.
o ペイロード長（2オクテット） - TEKプロトコル固有のペイロードを含むこのペイロードの長さ。
o Protocol-ID (1 octet) -- Value specifying the Security Protocol. The following table defines values for the Security Protocol
o Protocol-ID（1 Octet） - セキュリティプロトコルを指定する値。次の表は、セキュリティプロトコルの値を定義します
Protocol ID Value
----------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP 1
RESERVED 2-127
Private Use 128-255
o TEK Protocol-Specific Payload (variable) -- Payload which describes the attributes specific for the Protocol-ID.
o TEKプロトコル固有のペイロード（変数） - プロトコルIDに固有の属性を説明するペイロード。
The TEK Protocol-Specific payload for ESP is as follows:
ESPのTEKプロトコル固有のペイロードは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAT Payload fields are defined as follows:
SATペイロードフィールドは次のように定義されています。
o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP). A value of zero means that the Protocol field should be ignored.
o プロトコル（1 Octet） - IPプロトコルID（UDP/TCPなど）を説明する値。ゼロの値は、プロトコルフィールドを無視する必要があることを意味します。
o SRC ID Type (1 octet) -- Value describing the identity information found in the SRC Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG].
o SRC IDタイプ（1オクテット） - SRC識別データフィールドで見つかったID情報を説明する値。定義された値は、IANA ISAKMPD-REGISTRY [ISAKMP-REG]のIPSEC識別タイプセクションによって指定されます。
o SRC ID Port (2 octets) -- Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field should be ignored.
o SRC IDポート（2オクテット） - ソースIDに関連付けられたポートを指定する値。ゼロの値は、SRC IDポートフィールドを無視する必要があることを意味します。
o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC Identification Data field.
o SRC ID Data Len（1 Octet） - SRC識別データフィールドの長さを指定する値。
o SRC Identification Data (variable length) -- Value, as indicated by the SRC ID Type. Set to three bytes of zero for multiple-source multicast groups that use a common TEK for all senders.
o SRC IDタイプで示されるように、SRC識別データ（変数長） - 値。すべての送信者に共通のTEKを使用するマルチソースマルチキャストグループの場合、ゼロの3バイトに設定します。
o DST ID Type (1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG].
o DST IDタイプ（1 Octet） - DST識別データフィールドで見つかったID情報を説明する値。定義された値は、IANA ISAKMPD-REGISTRY [ISAKMP-REG]のIPSEC識別タイプセクションによって指定されます。
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP). A value of zero means that the DST Id Prot field should be ignored.
o DST ID PROT（1 OCTET） - IPプロトコルID（UDP/TCPなど）を説明する値。ゼロの値は、DST ID PROTフィールドを無視する必要があることを意味します。
o DST ID Port (2 octets) -- Value specifying a port associated with the source Id. A value of zero means that the DST ID Port field should be ignored.
o DST IDポート（2オクテット） - ソースIDに関連付けられたポートを指定する値。ゼロの値は、DST IDポートフィールドを無視する必要があることを意味します。
o DST ID Data Len (1 octet) -- Value specifying the length of the DST Identification Data field.
o DST ID Data Len（1 Octet） - DST識別データフィールドの長さを指定する値。
o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type.
o DST IDタイプで示されるDST識別データ（変数長） - 値。
o Transform ID (1 octet) -- Value specifying which ESP transform is to be used. The list of valid values is defined in the IPSEC ESP Transform Identifiers section of the IANA isakmpd-registry [ISAKMP-REG].
o Transform ID（1 Octet） - 使用するESP変換を指定する値。有効な値のリストは、IANA ISAKMPD-REGISTRY [ISAKMP-REG]のIPSEC ESP変換識別子セクションで定義されています。
o SPI (4 octets) -- Security Parameter Index for ESP.
o SPI（4オクテット） - ESPのセキュリティパラメーターインデックス。
o RFC 2407 Attributes -- ESP Attributes from RFC 2407 Section 4.5. The GDOI supports all IPSEC DOI SA Attributes for PROTO_IPSEC_ESP excluding the Group Description [RFC2407, section 4.5], which MUST NOT be sent by a GDOI implementation and is ignored by a GDOI implementation if received. All mandatory IPSEC DOI attributes are mandatory in GDOI PROTO_IPSEC_ESP. The Authentication Algorithm attribute of the IPSEC DOI is group authentication in GDOI.
o RFC 2407属性 - RFC 2407セクション4.5からのESP属性。GDOIは、グループの説明[RFC2407、セクション4.5]を除くすべてのIPSEC DOI SA属性をサポートします。すべての必須のIPSEC DOI属性は、GDOI ProTO_IPSEC_ESPで必須です。IPSEC DOIの認証アルゴリズム属性は、GDOIのグループ認証です。
Besides ESP, GDOI should serve to establish SAs for secure groups needed by other Security Protocols that operate at the transport, application, and internetwork layers. These other Security Protocols, however, are in the process of being developed or do not yet exist.
ESPに加えて、GDOIは、トランスポート、アプリケーション、およびインターネットワークレイヤーで動作する他のセキュリティプロトコルが必要とする安全なグループのSASを確立するのに役立つ必要があります。ただし、これらの他のセキュリティプロトコルは、開発されているか、まだ存在していません。
The following information needs to be provided for a Security Protocol to the GDOI.
GDOIへのセキュリティプロトコルのために、以下の情報を提供する必要があります。
o The Protocol-ID for the particular Security Protocol o The SPI Size o The method of SPI generation o The transforms, attributes and keys needed by the Security Protocol
o 特定のセキュリティプロトコル用のプロトコルID o SPIサイズo SPI生成の方法oセキュリティプロトコルで必要な変換、属性、およびキー
All Security Protocols must provide the information in the bulleted list above to guide the GDOI specification for that protocol. Definitions for the support of those Security Protocols in GDOI will be specified in separate documents.
すべてのセキュリティプロトコルは、そのプロトコルのGDOI仕様をガイドするために、上記の箇条書きリストに情報を提供する必要があります。GDOIにおけるこれらのセキュリティプロトコルのサポートの定義は、個別のドキュメントで指定されます。
A Security Protocol MAY protect traffic at any level of the network stack. However, in all cases applications of the Security Protocol MUST protect traffic which MAY be shared by more than two entities.
セキュリティプロトコルは、ネットワークスタックのあらゆるレベルでトラフィックを保護する場合があります。ただし、すべての場合において、セキュリティプロトコルのアプリケーションは、2つ以上のエンティティが共有できるトラフィックを保護する必要があります。
The Key Download Payload contains group keys for the group specified in the SA Payload. These key download payloads can have several security attributes applied to them based upon the security policy of the group as defined by the associated SA Payload.
キーダウンロードペイロードには、SAペイロードで指定されたグループのグループキーが含まれています。これらのキーダウンロードペイロードには、関連するSAペイロードで定義されているグループのセキュリティポリシーに基づいて、いくつかのセキュリティ属性を適用できます。
When included as part of the Re-key SA with an optional KE payload, The Key Download Payload will be xor'ed with the new Diffie-Hellman shared secret. The xor operation will begin at the "Number of Key Packets" field.
オプションのKEペイロードを備えたReke SAの一部として含まれる場合、キーダウンロードペイロードは、新しいDiffie-Hellman共有秘密でXor'edになります。XOR操作は、「キーパケットの数」フィールドで開始されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Number of Key Packets ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The Key Download Payload fields are defined as follows:
キーダウンロードペイロードフィールドは次のように定義されています。
o 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 zero.
o 次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドはゼロになります。
o RESERVED (1 octet) -- Unused, set to zero.
o 予約済み（1オクテット） - 未使用、ゼロに設定。
o Payload Length (2 octets) -- Length in octets of the current payload, including the generic payload header.
o ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。
o Number of Key Packets (2 octets) -- Contains the total number of both TEK and Rekey arrays being passed in this data block.
o キーパケットの数（2オクテット） - このデータブロックで渡されるTekとRekeの両方の配列の総数が含まれています。
o Key Packets Several types of key packets are defined. Each Key Packet has the following format.
o キーパケットいくつかのタイプのキーパケットが定義されています。各キーパケットには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! KD Type ! RESERVED ! KD Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI Size ! SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packet Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
o Key Download (KD) Type (1 octet) -- Identifier for the Key Data field of this Key Packet.
o キーダウンロード（kd）タイプ（1オクテット） - このキーパケットのキーデータフィールドの識別子。
Key Download Type Value
----------------- -----
RESERVED 0
TEK 1
KEK 2
LKH 3
RESERVED 4-127
Private Use 128-255
"KEK" is a single key whereas LKH is an array of key-encrypting keys.
「kek」は単一のキーですが、LKHはキー暗号化キーの配列です。
o RESERVED (1 octet) -- Unused, set to zero.
o 予約済み（1オクテット） - 未使用、ゼロに設定。
o Key Download Length (2 octets) -- Length in octets of the Key Packet data, including the Key Packet header.
o キーダウンロード長（2オクテット） - キーパケットヘッダーを含むキーパケットデータのオクテットの長さ。
o SPI Size (1 octet) -- Value specifying the length in octets of the SPI as defined by the Protocol-Id.
o SPIサイズ（1オクテット） - プロトコルIDで定義されているSPIのオクテットの長さを指定する値。
o SPI (variable length) -- Security Parameter Index which matches a SPI previously sent in an SAK or SAT Payload.
o SPI（可変長） - 以前にSAKまたはSATペイロードで送信されたSPIに一致するセキュリティパラメーターインデックス。
o Key Packet Attributes (variable length) -- Contains Key information. The format of this field is specific to the value of the KD Type field. The following sections describe the format of each KD Type.
o キーパケット属性（可変長） - キー情報が含まれています。このフィールドの形式は、KDタイプフィールドの値に固有です。次のセクションでは、各KDタイプの形式について説明します。
The following attributes may be present in a TEK Download Type. Exactly one attribute matching each type sent in the SAT payload MUST be present. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes defined as TV are marked as Basic (B); attributes defined as TLV are marked as Variable (V).
次の属性は、Tekのダウンロードタイプに存在する場合があります。SATペイロードで送信される各タイプに一致する1つの属性が存在する必要があります。属性は、ISAKMP [RFC2408]セクション3.3で定義されている形式に従う必要があります。テーブルでは、テレビとして定義された属性は基本（b）としてマークされています。TLVとして定義された属性は、変数（v）としてマークされます。
TEK Class Value Type
--------- ----- ----
RESERVED 0
TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 V
If no TEK key packets are included in a Registration KD payload, the group member can expect to receive the TEK as part of a Re-key SA. At least one TEK must be included in each Re-key KD payload. Multiple TEKs may be included if multiple streams associated with the SA are to be rekeyed.
登録KDペイロードにTEKキーパケットが含まれていない場合、グループメンバーは、再キーSAの一部としてTEKを受信することを期待できます。少なくとも1つのTEKを各再キーKDペイロードに含める必要があります。SAに関連付けられた複数のストリームを再キーにする場合、複数のTEKが含まれる場合があります。
The TEK_ALGORITHM_KEY class declares that the encryption key for this SPI is contained as the Key Packet Attribute. The encryption algorithm that will use this key was specified in the SAT payload.
TEK_ALGORITHM_KEYクラスは、このSPIの暗号化キーがキーパケット属性として含まれていることを宣言します。このキーを使用する暗号化アルゴリズムは、SATペイロードで指定されました。
In the case that the algorithm requires multiple keys (e.g., 3DES), all keys will be included in one attribute.
アルゴリズムが複数のキー（3DEなど）を必要とする場合、すべてのキーが1つの属性に含まれます。
DES keys will consist of 64 bits (the 56 key bits with parity bit). Triple DES keys will be specified as a single 192 bit attribute (including parity bits) in the order that the keys are to be used for encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3).
DESキーは64ビット（パリティビットの56キービット）で構成されます。トリプルDESキーは、キーを暗号化に使用する順に、単一の192ビット属性（パリティビットを含む）として指定されます（例：DES_KEY1、DES_KEY2、DES_KEY3）。
The TEK_INTEGRITY_KEY class declares that the integrity key for this SPI is contained as the Key Packet Attribute. The integrity algorithm that will use this key was specified in the SAT payload. Thus, GDOI assumes that both the symmetric encryption and integrity keys are pushed to the member. SHA keys will consist of 160 bits, and MD5 keys will consist of 128 bits.
TEK_INTEGRITY_KEYクラスは、このSPIの整合性キーがキーパケット属性として含まれていることを宣言しています。このキーを使用する整合性アルゴリズムは、SATペイロードで指定されました。したがって、GDOIは、対称暗号化と整合性キーの両方がメンバーにプッシュされると想定しています。SHAキーは160ビットで構成され、MD5キーは128ビットで構成されます。
The TEK_SOURCE_AUTH_KEY class declares that the source authentication key for this SPI is contained in the Key Packet Attribute. The source authentication algorithm that will use this key was specified in the SAT payload.
TEK_SOURCE_AUTH_KEYクラスは、このSPIのソース認証キーがキーパケット属性に含まれていることを宣言します。このキーを使用するソース認証アルゴリズムは、SATペイロードで指定されました。
The following attributes may be present in a KEK Download Type. Exactly one attribute matching each type sent in the SAK payload MUST be present. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes defined as TV are marked as Basic (B); attributes defined as TLV are marked as Variable (V).
次の属性は、KEKダウンロードタイプに存在する場合があります。SAKペイロードで送信された各タイプに一致する1つの属性が存在する必要があります。属性は、ISAKMP [RFC2408]セクション3.3で定義されている形式に従う必要があります。テーブルでは、テレビとして定義された属性は基本（b）としてマークされています。TLVとして定義された属性は、変数（v）としてマークされます。
KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 V
If the KEK key packet is included, there MUST be only one present in the KD payload.
KEKキーパケットが含まれている場合、KDペイロードに1つの存在が必要です。
The KEK_ALGORITHM_KEY class declares the encryption key for this SPI is contained in the Key Packet Attribute. The encryption algorithm that will use this key was specified in the SAK payload.
KEK_ALGORITHM_KEYクラスは、このSPIの暗号化キーがキーパケット属性に含まれていると宣言します。このキーを使用する暗号化アルゴリズムは、SAKペイロードで指定されました。
If the mode of operation for the algorithm requires an Initialization Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY before the actual key.
アルゴリズムの動作モードに初期化ベクトル（IV）が必要な場合、実際のキーの前に明示的なIVをkek_algorithm_keyに含める必要があります。
The SIG_ALGORITHM_KEY class declares that the public key for this SPI is contained in the Key Packet Attribute, which may be useful when no public key infrastructure is available. The signature algorithm that will use this key was specified in the SAK payload.
SIG_ALGORITHM_KEYクラスは、このSPIの公開鍵はキーパケット属性に含まれていることを宣言します。これは、公開キーインフラストラクチャが利用できない場合に役立つ場合があります。このキーを使用する署名アルゴリズムは、SAKペイロードで指定されました。
The LKH key packet is comprised of attributes representing different leaves in the LKH key tree.
LKHキーパケットは、LKHキーツリー内の異なる葉を表す属性で構成されています。
The following attributes are used to pass an LKH KEK array in the KD payload. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes defined as TV are marked as Basic (B); attributes defined as TLV are marked as Variable (V).
次の属性は、KDペイロードのLKH KEKアレイを渡すために使用されます。属性は、ISAKMP [RFC2408]セクション3.3で定義されている形式に従う必要があります。テーブルでは、テレビとして定義された属性は基本（b）としてマークされています。TLVとして定義された属性は、変数（v）としてマークされます。
KEK Class Value Type
--------- ----- ----
RESERVED 0
LKH_DOWNLOAD_ARRAY 1 V
LKH_UPDATE_ARRAY 2 V
SIG_ALGORITHM_KEY 3 V
RESERVED 4-127
Private Use 128-255
If an LKH key packet is included in the KD payload, there must be only one present.
LKHキーパケットがKDペイロードに含まれている場合、存在するのは1つだけです。
This attribute is used to download a set of keys to a group member. It MUST NOT be included in a GROUPKEY-PUSH message KD payload if the GROUPKEY-PUSH is sent to more than the group member. If an LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there must be only one present.
この属性は、グループメンバーにキーのセットをダウンロードするために使用されます。GroupKey-PushがGroupメンバー以上に送信された場合、GroupKey-PushメッセージKDペイロードに含めてはなりません。LKH_DOWNLOAD_ARRAY属性がKDペイロードに含まれている場合、存在するのは1つだけです。
This attribute consists of a header block, followed by one or more LKH keys.
この属性は、ヘッダーブロックで構成され、1つ以上のLKHキーが続きます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The KEK_LKH attribute fields are defined as follows:
KEK_LKH属性フィールドは、次のように定義されています。
o LKH version (1 octet) -- Contains the version of the LKH protocol which the data is formatted in. Must be one.
o LKHバージョン（1 Octet） - データがフォーマットされているLKHプロトコルのバージョンが含まれています。
o Number of LKH Keys (2 octets) -- This value is the number of distinct LKH keys in this sequence.
o LKHキーの数（2オクテット） - この値は、このシーケンスの個別のLKHキーの数です。
o RESERVED (1 octet) -- Unused, set to zero. Each LKH Key is defined as follows:
o 予約済み（1オクテット） - 未使用、ゼロに設定。各LKHキーは次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! Key Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Creation Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key expiration Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o LKH ID (2 octets) -- This is the position of this key in the binary tree structure used by LKH.
o LKH ID（2オクテット） - これは、LKHが使用するバイナリツリー構造のこのキーの位置です。
o Key Type (1 octet) -- This is the encryption algorithm for which this key data is to be used. This value is specified in Section 5.3.3.
o キータイプ（1オクテット） - これは、このキーデータを使用する暗号化アルゴリズムです。この値は、セクション5.3.3で指定されています。
o RESERVED (1 octet) -- Unused, set to zero.
o 予約済み（1オクテット） - 未使用、ゼロに設定。
o Key Creation Date (4 octets) -- This is the time value of when this key data was originally generated. A time value of zero indicates that there is no time before which this key is not valid.
o キー作成日（4オクテット） - これは、このキーデータが元々生成された時の時間値です。ゼロの時間値は、このキーが有効でない時間がないことを示します。
o Key Expiration Date (4 octets) -- This is the time value of when this key is no longer valid for use. A time value of zero indicates that this key does not have an expiration time.
o キーの有効期限（4オクテット） - これは、このキーが使用に有効でない場合の時間値です。ゼロの時間値は、このキーに有効期限がないことを示します。
o Key Handle (4 octets) -- This is the randomly generated value to uniquely identify a key within an LKH ID.
o キーハンドル（4オクテット） - これは、LKH ID内のキーを一意に識別するためのランダムに生成された値です。
o Key Data (variable length) -- This is the actual encryption key data, which is dependent on the Key Type algorithm for its format. If the mode of operation for the algorithm requires an Initialization Vector (IV), an explicit IV MUST be included in the Key Data field before the actual key.
o キーデータ（変数長） - これは、実際の暗号化キーデータであり、その形式のキータイプアルゴリズムに依存します。アルゴリズムの動作モードに初期化ベクトル（IV）が必要な場合、実際のキーの前に明示的なIVをキーデータフィールドに含める必要があります。
The Key Creation Date and Key expiration Dates MAY be zero. This is necessary in the case where time synchronization within the group is not possible.
キー作成日とキーの有効期限はゼロになる場合があります。これは、グループ内の時間同期が不可能な場合に必要です。
The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute contains the Leaf identifier and key for the group member. The rest of the LKH Key structures contain keys along the path of the key tree in order from the leaf, culminating in the group KEK.
LKH_DOWNLOAD_ARRAY属性の最初のLKHキー構造には、グループメンバーのリーフ識別子とキーが含まれています。LKHキー構造の残りの部分には、キーツリーの経路に沿ったキーが葉から順番にキーが含まれており、Kekグループで頂点に達しています。
This attribute is used to update the keys for a group. It is most likely to be included in a GROUPKEY-PUSH message KD payload to rekey the entire group. This attribute consists of a header block, followed by one or more LKH keys, as defined in Section 5.5.3.1
この属性は、グループのキーを更新するために使用されます。グループ全体を再キーするために、グループキープッシュメッセージKDペイロードに含まれる可能性が最も高くなります。この属性は、セクション5.5.3.1で定義されているように、ヘッダーブロックで構成され、1つ以上のLKHキーが続きます。
There may be any number of UPDATE_ARRAY attributes included in a KD payload.
kdペイロードに含まれるupdate_array属性が数多く存在する場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o LKH version (1 octet) -- Contains the version of the LKH protocol which the data is formatted in. Must be one.
o LKHバージョン（1 Octet） - データがフォーマットされているLKHプロトコルのバージョンが含まれています。
o Number of LKH Keys (2 octets) -- This value is the number of distinct LKH keys in this sequence.
o LKHキーの数（2オクテット） - この値は、このシーケンスの個別のLKHキーの数です。
o RESERVED (1 octet) -- Unused, set to zero.
o 予約済み（1オクテット） - 未使用、ゼロに設定。
o LKH ID (2 octets) -- This is the node identifier associated with the key used to encrypt the first LKH Key.
o LKH ID（2オクテット） - これは、最初のLKHキーを暗号化するために使用されるキーに関連付けられたノード識別子です。
o RESERVED2 (2 octets) -- Unused, set to zero.
o Reserved2（2オクテット） - 未使用、ゼロに設定。
o Key Handle (4 octets) -- This is the value to uniquely identify the key within the LKH ID which was used to encrypt the first LKH key.
o キーハンドル（4オクテット） - これは、最初のLKHキーを暗号化するために使用されたLKH ID内のキーを一意に識別する値です。
The LKH Keys are as defined in Section 5.5.3.1. The LKH Key structures contain keys along the path of the key tree in order from the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the group KEK. The Key Data field of each LKH Key is encrypted with the LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first LKH Key is encrypted under the key defined by the LKH ID and Key Handle found in the LKH_UPDATE_ARRAY header.
LKHキーは、セクション5.5.3.1で定義されています。LKHキー構造には、LKH_UPDATE_ARRAYヘッダーにあるLKH IDの順に、キーツリーの経路に沿ったキーが含まれており、グループKekグループで頂点に達しています。各LKHキーのキーデータフィールドは、lkh_update_array属性に先行するLKHキーで暗号化されています。最初のLKHキーは、LKH IDとLKH_UPDATE_ARRAYヘッダーにあるキーハンドルで定義されたキーの下で暗号化されます。
The SIG_ALGORITHM_KEY class declares that the public key for this SPI is contained in the Key Packet Attribute, which may be useful when no public key infrastructure is available. The signature algorithm that will use this key was specified in the SAK payload.
SIG_ALGORITHM_KEYクラスは、このSPIの公開鍵はキーパケット属性に含まれていることを宣言します。これは、公開キーインフラストラクチャが利用できない場合に役立つ場合があります。このキーを使用する署名アルゴリズムは、SAKペイロードで指定されました。
The Sequence Number Payload (SEQ) provides an anti-replay protection for GROUPKEY-PUSH messages. Its use is similar to the Sequence Number field defined in the IPsec ESP protocol [RFC2406].
シーケンス番号ペイロード（SEQ）は、GroupKey-Pushメッセージのレプレイ防止保護を提供します。その使用は、IPSEC ESPプロトコル[RFC2406]で定義されているシーケンス番号フィールドに似ています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sequence Number Payload fields are defined as follows:
シーケンス番号ペイロードフィールドは、次のように定義されています。
o 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 zero.
o 次のペイロード（1オクテット） - メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドはゼロになります。
o RESERVED (1 octet) -- Unused, set to zero.
o 予約済み（1オクテット） - 未使用、ゼロに設定。
o Payload Length (2 octets) -- Length in octets of the current payload, including the generic payload header.
o ペイロード長（2オクテット） - 汎用ペイロードヘッダーを含む、現在のペイロードのオクテットの長さ。
o Sequence Number (4 octets) -- This field contains a monotonically increasing counter value for the group. It is initialized to zero by the GCKS, and incremented in each subsequently-transmitted message. Thus the first packet sent for a given Rekey SA will have a Sequence Number of 1. The GDOI implementation keeps a sequence counter as an attribute for the Rekey SA and increments the counter upon receipt of a GROUPKEY-PUSH message. The current value of the sequence number must be transmitted to group members as a part of the Registration SA SA payload. A group member must keep a sliding receive window. The window must be treated as in the ESP protocol [RFC2406] Section 3.4.3.
o シーケンス番号（4オクテット） - このフィールドには、グループの単調に増加するカウンター値が含まれています。GCKSによってゼロに初期化され、その後に移行された各メッセージでインクリメントされます。したがって、特定のReke SAに送信された最初のパケットには、シーケンス番号があります。GDOI実装は、SequenceカウンターをREKEY SAの属性として保持し、GroupKey-Pushメッセージを受信したときにカウンターを増分します。シーケンス番号の現在の値は、登録SA SAペイロードの一部としてグループメンバーに送信する必要があります。グループメンバーは、スライディング受信ウィンドウを保持する必要があります。ウィンドウは、ESPプロトコル[RFC2406]セクション3.4.3のように扱う必要があります。
The Proof of Possession Payload is used as part of group membership authorization during a GDOI exchange. The Proof of Possession Payload is identical to an ISAKMP SIG payload. However, the usage is entirely different.
所有ペイロードの証明は、GDOI交換中のグループメンバーシップ認可の一部として使用されます。所有ペイロードの証明は、ISAKMP SIGペイロードと同じです。ただし、使用法はまったく異なります。
The GCKS, GCKS delegate or member signs a hash of the following values: POP_HASH = hash("pop" | Ni | Nr) Where hash() is the hash function used with the signature.
GCKS、GCKS代表、またはメンバーは、次の値のハッシュに署名します：pop_hash = hash（ "pop" | ni | nr）ここで、hash（）は署名で使用されるハッシュ関数です。
The "pop" prefix ensures that the signature of the POP payload cannot be used for any other purpose in the GDOI protocol.
「POP」プレフィックスは、POPペイロードの署名をGDOIプロトコルの他の目的に使用できないことを保証します。
The data portion of the Nonce payload (i.e., Ni_b and Nr_b included in the HASHs) MUST be a value between 8 and 128 bytes.
非CEペイロードのデータ部分（つまり、ハッシュに含まれるNI_BおよびNR_B）は、8〜128バイトの値でなければなりません。
GDOI is a security association (SA) management protocol for groups of senders and receivers. Unlike a data security protocol, SA management includes a key establishment protocol to securely establish keys at communication endpoints. This protocol performs entity authentication of the GDOI member or Group Controller/Key Server (GCKS), it provides confidentiality of key management messages, and it provides source authentication of those messages. This protocol also uses best-known practices for defense against man-in-middle, connection hijacking, replay, reflection, and denial-of-service (DOS) attacks on unsecured networks [STS, RFC2522, SKEME]. GDOI assumes the network is not secure and may be under the complete control of an attacker.
GDOIは、送信者とレシーバーのグループ向けのセキュリティ協会（SA）管理プロトコルです。データセキュリティプロトコルとは異なり、SAマネジメントには、通信エンドポイントでキーを安全に確立するための主要な確立プロトコルが含まれています。このプロトコルは、GDOIメンバーまたはグループコントローラー/キーサーバー（GCKS）のエンティティ認証を実行し、キー管理メッセージの機密性を提供し、それらのメッセージのソース認証を提供します。このプロトコルは、無担保ネットワークに対するマンインミドル、接続ハイジャック、リプレイ、リフレクション、およびサービス拒否（DOS）攻撃[STS、RFC2522、Skeme]に対する防御のために、最も有名なプラクティスを使用しています。GDOIは、ネットワークが安全ではないと想定しており、攻撃者の完全な制御下にある可能性があります。
GDOI assumes that the host computer is secure even though the network is insecure. GDOI ultimately establishes keys among members of a group, which MUST be trusted to use those keys in an authorized manner according to group policy. The security of GDOI, therefore, is as good as the degree to which group members can be trusted to protect authenticators, encryption keys, decryption keys, and message authentication keys.
GDOIは、ネットワークが不安定であるにもかかわらず、ホストコンピューターが安全であると想定しています。GDOIは最終的にグループのメンバー間でキーを確立します。これは、グループポリシーに従って許可された方法でそれらのキーを使用することを信頼する必要があります。したがって、GDOIのセキュリティは、認証機、暗号化キー、復号化キー、メッセージ認証キーを保護するためにグループメンバーを信頼できる程度と同じくらい優れています。
There are three phases of GDOI as described in this document: an ISAKMP Phase 1 protocol, a new exchange called GROUPKEY-PULL which is protected by the ISAKMP Phase 1 protocol, and a new message called GROUPKEY-PUSH. Each phase is considered separately below.
このドキュメントで説明されているGDOIには、ISAKMPフェーズ1プロトコル、ISAKMPフェーズ1プロトコルによって保護されているGroupKey-Pullと呼ばれる新しい交換、およびGroupKey-Pushという新しいメッセージの3つのフェーズがあります。各フェーズは、以下で別々に考慮されます。
As described in this document, GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the GROUPKEY-PULL exchange. Therefore all security properties and considerations of those exchanges (as noted in [RFC2409]) are relevant for GDOI.
このドキュメントで説明されているように、GDOIは[RFC2409]で定義されているフェーズ1交換を使用して、グループキープル交換を保護します。したがって、これらの交換のすべてのセキュリティプロパティと考慮事項（[RFC2409]に記載されている）は、GDOIに関連しています。
GDOI may inherit the problems of its ancestor protocols [FS00], such as identity exposure, absence of unidirectional authentication, or stateful cookies [PK01]. GDOI could benefit, however, from improvements to its ancestor protocols just as it benefits from years of experience and work embodied in those protocols. To reap the benefits of future IKE improvements, however, GDOI would need to be revised in a future standards-track RFC, which is beyond the scope of this specification.
GDOIは、アイデンティティ曝露、単方向認証の欠如、またはステートフルクッキー[PK01]など、祖先プロトコル[FS00]の問題を継承する場合があります。しかし、GDOIは、これらのプロトコルで具体化された長年の経験と仕事の恩恵を受けるのと同様に、その祖先プロトコルの改善から利益を得ることができました。ただし、将来のIKE改善の利点を享受するには、GDOIを将来の標準トラックRFCで修正する必要があります。これは、この仕様の範囲を超えています。
Authentication is provided via the mechanisms defined in [RFC2409], namely Pre-Shared Keys or Public Key encryption.
認証は、[RFC2409]で定義されているメカニズム、つまり、事前に共有キーまたは公開キーの暗号化を介して提供されます。
Confidentiality is achieved in Phase 1 through a Diffie-Hellman exchange that provides keying material, and through negotiation of encryption transforms.
機密性は、キーリング素材を提供するDiffie-Hellman交換、および暗号化の変換の交渉を通じて、フェーズ1で達成されます。
The Phase 1 protocol will be protecting encryption and integrity keys sent in the GROUPKEY-PULL protocol. The strength of the encryption used for Phase 1 SHOULD exceed that of the keys send in the GROUPKEY-PULL protocol.
フェーズ1プロトコルは、GroupKey-Pullプロトコルで送信される暗号化と整合性キーを保護します。フェーズ1に使用される暗号化の強度は、GroupKey-Pullプロトコルで送信されるキーの強度を超える必要があります。
A successful man-in-the-middle or connection-hijacking attack foils entity authentication of one or more of the communicating entities during key establishment. GDOI relies on Phase 1 authentication to defeat man-in-the-middle attacks.
成功した中間または接続 - 接続 - ハイジャック攻撃foils主要な施設中の1つ以上の通信エンティティのエンティティ認証。GDOIは、フェーズ1認証に依存して、中間の攻撃を倒すためです。
In a replay/reflection attack, an attacker captures messages between GDOI entities and subsequently forwards them to a GDOI entity. Replay and reflection attacks seek to gain information from a subsequent GDOI message response or seek to disrupt the operation of a GDOI member or GCKS entity. GDOI relies on the Phase 1 nonce mechanism in combination with a hash-based message authentication code to protect against the replay or reflection of previous key management messages.
リプレイ/リフレクション攻撃では、攻撃者がGDOIエンティティ間のメッセージをキャプチャし、その後GDOIエンティティに転送します。リプレイおよびリフレクション攻撃は、その後のGDOIメッセージ応答から情報を取得しようとするか、GDOIメンバーまたはGCKSエンティティの運用を混乱させようとします。GDOIは、以前の主要な管理メッセージのリプレイまたは反映から保護するために、ハッシュベースのメッセージ認証コードと組み合わせてフェーズ1ノンセメカニズムに依存しています。
A denial of service attacker sends messages to a GDOI entity to cause that entity to perform unneeded message authentication operations. GDOI uses the Phase 1 cookie mechanism to identify spurious messages prior to cryptographic hash processing. This is a "weak" form of denial of service protection in that the GDOI entity must check for good cookies, which can be successfully imitated by a sophisticated attacker. The Phase 1 cookie mechanism is stateful, and commits memory resources for cookies, but stateless cookies are a better defense against denial of service attacks.
サービス拒否攻撃者は、GDOIエンティティにメッセージを送信して、そのエンティティに不要なメッセージ認証操作を実行させます。GDOIは、フェーズ1 Cookieメカニズムを使用して、暗号化ハッシュ処理の前に偽のメッセージを特定します。これは、GDOIエンティティが良好なCookieをチェックする必要があるという点で、「弱い」サービス拒否保護の形式です。フェーズ1 Cookieメカニズムはステートフルであり、Cookieのメモリリソースをコミットしますが、ステートレスCookieはサービス拒否攻撃に対するより良い防御です。
The GROUPKEY-PULL exchange allows a group member to request SAs and keys from a GCKS. It runs as a "phase 2" protocol under protection of the Phase 1 security association.
GroupKey-Pull Exchangeを使用すると、グループメンバーはGCKSからSASとキーを要求できます。フェーズ1セキュリティ協会の保護下で「フェーズ2」プロトコルとして実行されます。
Peer authentication is not required in the GROUPKEY-PULL protocol. It is running in the context of the Phase 1 protocol, which has previously authenticated the identity of the peer.
GroupKey-Pullプロトコルでは、ピア認証は必要ありません。以前にピアのアイデンティティを認証していたフェーズ1プロトコルのコンテキストで実行されています。
Message authentication is provided by HASH payloads in each message, where the HASH is defined to be over SKEYID_a (derived in the Phase 1 exchange), the ISAKMP Message-ID, and all payloads in the message. Because only the two endpoints of the exchange know the SKEYID_a value, this provides confidence that the peer sent the message.
メッセージ認証は、各メッセージのハッシュペイロードによって提供されます。ここで、ハッシュはSKEYID_A（フェーズ1エクスチェンジで派生）、ISAKMPメッセージID、およびメッセージ内のすべてのペイロードを超えると定義されます。Exchangeの2つのエンドポイントのみがSKEYID_A値を知っているため、これはピアがメッセージを送信したという自信を提供します。
Confidentiality is provided by the Phase 1 security association, after the manner described in [RFC2409].
機密性は、[RFC2409]に記載されている方法の後、フェーズ1セキュリティ協会によって提供されます。
Message authentication (described above) includes a secret known only to the group member and GCKS when constructing a HASH payload. This prevents man-in-the-middle and connection-hijacking attacks because an attacker would not be able to change the message undetected.
メッセージ認証（上記）には、ハッシュペイロードを構築する際にグループメンバーとGCKSのみに知られている秘密が含まれます。これにより、攻撃者が検出されないメッセージを変更できないため、中間および接続と接続のハイジャック攻撃が防止されます。
Nonces provide freshness of the GROUPKEY-PULL exchange. The group member and GCKS exchange nonce values first two messages. These nonces are included in subsequent HASH payload calculations. The Group member and GCKS MUST NOT perform any computationally expensive tasks before receiving a HASH with its own nonce included. The GCKS MUST NOT update the group management state (e.g., LKH key tree) until it receives the third message in the exchange with a valid HASH payload including its own nonce.
Noncesは、GroupKey-Pull Exchangeの新鮮さを提供します。グループメンバーとGCKSは、NONCE値を最初に2つのメッセージを交換します。これらの非性能は、後続のハッシュペイロード計算に含まれています。グループメンバーとGCKSは、独自の非CEを含むハッシュを受信する前に、計算上の高価なタスクを実行してはなりません。GCKSは、独自の非CEを含む有効なハッシュペイロードを使用して、交換で3番目のメッセージを受信するまで、グループ管理状態（LKHキーツリーなど）を更新してはなりません。
Implementations SHOULD keep a record of recently received GROUPKEY-PULL messages and reject messages that have already been processed. This enables an early discard of the replayed messages.
実装は、最近受信したGroupKey-Pullメッセージの記録を保持し、すでに処理されているメッセージを拒否する必要があります。これにより、再生されたメッセージを早期に破棄できます。
A GROUPKEY-PULL message identifies its messages using a cookie pair from the Phase 1 exchange that precedes it. The cookies provide a weak form of denial of service protection as described above, in the sense that a GROUPKEY-PULL message with invalid cookies will be discarded.
GroupKey-Pullメッセージは、それに先行するフェーズ1エクスチェンジのCookieペアを使用してメッセージを識別します。Cookieは、無効なCookieを含むグループキープルメッセージが破棄されるという意味で、上記のように弱い形式のサービス保護を提供します。
The replay protection mechanisms described above provide the basis for denial of service protection.
上記のリプレイ保護メカニズムは、サービス保護の拒否の基礎を提供します。
The CERT payload in a GROUPKEY-PULL exchange allows a group member or GCKS to submit a certificate containing authorization attributes to the peer as well as identifying a public/private key pair. The GROUPKEY-PULL POP payload enables authorization to be accomplished where the authorization infrastructure is different than the GROUPKEY-PULL authentication infrastructure by proving that it is in possession of the private key.
GroupKey-Key-Pull ExchangeのCERTペイロードにより、グループメンバーまたはGCKがピアに承認属性を含む証明書を提出し、パブリック/プライベートキーペアを識別することができます。GroupKey-Key-Pull Popペイロードにより、秘密鍵が所有されていることを証明することにより、承認インフラストラクチャがGroupKey-Pull認証インフラストラクチャとは異なる場合、承認を達成できます。
The GROUPKEY-PUSH exchange is a single message that allows a GCKS to send SAs and keys to group members. This is likely to be sent to all members using an IP multicast group. This provides an efficient rekey and group membership adjustment capability.
GroupKey-Push Exchangeは、GCKSがSASとキーをグループメンバーに送信できるようにする単一のメッセージです。これは、IPマルチキャストグループを使用してすべてのメンバーに送信される可能性があります。これにより、効率的なRekeyおよびGroupメンバーシップの調整機能が提供されます。
The GROUPKEY-PULL exchange identifies a public key that is used for message authentication. The GROUPKEY-PUSH message is digitally signed using the corresponding private key held by the GCKS or its delegate. This digital signature provides source authentication for the message. Thus, GDOI protects the GCKS from impersonation in group environments.
GroupKey-Pull Exchangeは、メッセージ認証に使用される公開キーを識別します。GroupKey-Pushメッセージは、GCKSまたはその代表者が保有する対応する秘密鍵を使用してデジタルで署名されます。このデジタル署名は、メッセージのソース認証を提供します。したがって、GDOIはGCKSをグループ環境でのなりすましから保護します。
The GCKS encrypts the GROUPKEY-PUSH message with an encryption key that was established by the GROUPKEY-PULL exchange.
GCKSは、GroupKey-Pull Exchangeによって確立された暗号化キーを使用してGroupKey-Pushメッセージを暗号化します。
This combination of confidentiality and message authentication services protects the GROUPKEY-PUSH message from man-in-middle and connection-hijacking attacks.
機密性とメッセージ認証サービスのこの組み合わせは、Man-in-MiddleおよびConnection-Hijacking攻撃からのGroupKey-Pushメッセージを保護します。
The GROUPKEY-PUSH message includes a monotonically increasing sequence number to protect against replay and reflection attacks. A group member will recognize a replayed message by comparing the sequence number to a sliding window, in the same manner as the ESP protocol uses sequence numbers.
GroupKey-Pushメッセージには、リプレイおよび反射攻撃から保護するための単調に増加するシーケンス番号が含まれています。グループメンバーは、ESPプロトコルがシーケンス番号を使用するのと同じ方法で、シーケンス番号をスライドウィンドウと比較することにより、再生されたメッセージを認識します。
Implementations SHOULD keep a record of recently received GROUPKEY-PUSH messages and reject duplicate messages. This enables an early discard of the replayed messages.
実装は、最近受信したGroupKey-Pushメッセージの記録を保持し、重複メッセージを拒否する必要があります。これにより、再生されたメッセージを早期に破棄できます。
A cookie pair identifies the security association for the GROUPKEY-PUSH message. The cookies thus serve as a weak form of denial-of-service protection for the GROUPKEY-PUSH message.
Cookieペアは、GroupKey-Pushメッセージのセキュリティ協会を識別します。したがって、Cookieは、GroupKey-Pushメッセージのサービス拒否保護の弱い形式として機能します。
The digital signature used for message authentication has a much greater computational cost than a message authentication code and could amplify the effects of a denial of service attack on GDOI members who process GROUPKEY-PUSH messages. The added cost of digital signatures is justified by the need to prevent GCKS impersonation: If a shared symmetric key were used for GROUPKEY-PUSH message authentication, then GCKS source authentication would be impossible and any member would be capable of GCKS impersonation.
メッセージ認証に使用されるデジタル署名は、メッセージ認証コードよりもはるかに高い計算コストを持ち、グループキープッシュメッセージを処理するGDOIメンバーに対するサービス拒否攻撃の効果を増幅する可能性があります。Digital Signaturesの追加コストは、GCKSのなりすましを防ぐ必要性によって正当化されます。GroupKey-Pushメッセージ認証に共有対称キーが使用された場合、GCKSソース認証は不可能であり、メンバーはGCKSのなりすましが可能です。
The potential of the digital signature amplifying a denial of service attack is mitigated by the order of operations a group member takes, where the least expensive cryptographic operation is performed first. The group member first decrypts the message using a symmetric cipher. If it is a validly formed message then the sequence number is checked against the replay window. Only if the sequence number is valid is the digital signature verified. Thus in order for a denial of service attack to be mounted, an attacker would need to know both the symmetric encryption key used for confidentiality, and a valid sequence number. Generally speaking this means only current group members can effectively deploy a denial of service attack.
サービス拒否攻撃を増幅するデジタル署名の可能性は、グループメンバーが取る操作の順序によって軽減されます。グループメンバーは、最初に対称的な暗号を使用してメッセージを復号化します。有効に形成されたメッセージの場合、シーケンス番号がリプレイウィンドウに対してチェックされます。シーケンス番号が有効である場合にのみ、デジタル署名が検証されています。したがって、サービスの拒否攻撃を取り付けるためには、攻撃者は、機密性に使用される対称暗号化キーと有効なシーケンス番号の両方を知る必要があります。一般的に言えば、これは現在のグループメンバーのみがサービス拒否攻撃を効果的に展開できることを意味します。
If a group management algorithm (such as LKH) is used, forward access control may not be ensured in some cases. This can happen if some group members are denied access to the group in the same GROUPKEY-PUSH message as new policy and TEKs are delivered to the group. As discussed in Section 4.2.1, forward access control can be maintained by sending multiple GROUPKEY-PUSH messages, where the group membership changes are sent from the GCKS separate from the new policy and TEKs.
グループ管理アルゴリズム（LKHなど）が使用されている場合、場合によってはフォワードアクセス制御が保証されない場合があります。これは、一部のグループメンバーが、新しいポリシーと同じグループキープッシュメッセージでグループへのアクセスを拒否され、TEKがグループに配信された場合に発生する可能性があります。セクション4.2.1で説明したように、グループメンバーシップの変更が新しいポリシーとTEKSとは別のGCKから送信される複数のGroupKey-Pushメッセージを送信することにより、フォワードアクセス制御を維持できます。
An ISAKMP DOI number is needed to identify an SA payload as a GDOI SA payload. The IANA has assigned the value 2 to represent GDOI.
SAペイロードをGDOI SAペイロードとして識別するには、ISAKMP DOI番号が必要です。IANAは、GDOIを表すために値2を割り当てました。
The present document defines new ISAKMP Next Payload types. See Section 5.0 for the payloads defined in this document, including the Next Payload values defined by the IANA to identify these payloads.
現在のドキュメントでは、新しいISAKMP次のペイロードタイプを定義しています。これらのペイロードを識別するためにIANAによって定義された次のペイロード値を含む、このドキュメントで定義されているペイロードについては、セクション5.0を参照してください。
The present document describes many new name spaces for use in the GDOI payloads. Those may be found in subsections under Section 5.0. A new GDOI registry has been created for these name spaces.
現在のドキュメントでは、GDOIペイロードで使用する多くの新しい名前スペースについて説明しています。これらは、セクション5.0に基づくサブセクションにあります。これらの名前スペース用に新しいGDOIレジストリが作成されました。
Portions of name spaces marked "RESERVED" are reserved for IANA allocation. New values MUST be added due to a Standards Action as defined in [RFC2434].
「予約済み」とマークされた名前スペースの一部は、IANAの割り当てのために予約されています。[RFC2434]で定義されている標準アクションのために、新しい値を追加する必要があります。
Portions of name spaces marked "Private Use" may be allocated by implementations for their own purposes.
「プライベート使用」とマークされた名前スペースの一部は、独自の目的のために実装によって割り当てられる場合があります。
The IANA has assigned port 848 for use by GDOI.
IANAは、GDOIが使用するためにポート848を割り当てました。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
The authors thank Ran Canetti, Cathy Meadows, Andrea Colegrove, and Lakshminath Dondeti. Ran has advised the authors on secure group cryptography, which has led to changes in the exchanges and payload definitions. Cathy identified several problems in previous versions of this document, including a replay attack against the proof of possession exchange, as well as several man-in-the-middle attacks. Andrea contributed to the group policy section of this document. Lakshminath identified several protocol issues that needed further specification and helped to resolve them.
著者は、Ran Canetti、Cathy Meadows、Andrea Colegrove、Lakshminath Dondetiに感謝します。RANは、著者に安全なグループ暗号化について助言しました。これにより、交換とペイロードの定義が変更されました。Cathyは、このドキュメントの以前のバージョンで、所有証明の証明に対するリプレイ攻撃や、いくつかの中間の攻撃を含むいくつかの問題を特定しました。アンドレアは、この文書のグループポリシーセクションに貢献しました。Lakshminathは、さらに仕様を必要とするいくつかのプロトコルの問題を特定し、それらの解決に役立ちました。
[AES-MODES] "Recommendation for Block Cipher Modes of Operation", United States of American, National Institute of Science and Technology, NIST Special Publication 800-38A 2001 Edition, December 2001.
[AES-Modes]「Block Cipher Modes of Operationの推奨」、アメリカ合衆国、国立科学技術研究所、NIST Special Publication 800-38A 2001 Edition、2001年12月。
[FIPS46-3] "Data Encryption Standard (DES)", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 46-3, October 1999.
[FIPS46-3]「データ暗号化標準（DES）」、アメリカ合衆国、国立科学技術研究所、連邦情報処理標準（FIPS）46-3、1999年10月。
[FIPS81] "DES Modes of Operation", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 81, December 1980.
[FIPS81]「DES Modes of Operation」、アメリカ合衆国、国立科学技術研究所、連邦情報処理標準（FIPS）81、1980年12月。
[FIPS186-2] "Digital Signature Standard (DSS)", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 186-2, January 2000.
[FIPS186-2]「デジタル署名標準（DSS）」、アメリカ合衆国、国立科学技術研究所、連邦情報処理標準（FIPS）186-2、2000年1月。
[FIPS197] "Advanced Encryption Standard (AES)", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 197, November 2001.
[FIPS197]「Advanced Encryption Standard（AES）」、アメリカ合衆国、国立科学技術研究所、連邦情報処理標準（FIPS）197、2001年11月。
[IPSEC-REG] http://www.iana.org/assignments/ipsec-registry
[ipsec-reg] http://www.iana.org/assignments/ipsec-registry
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[isakmp-reg] http://www.iana.org/assignments/isakmp-registry
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPドメイン」、RFC 2407、1998年11月。
[RFC2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[RFC2408] Maughan、D.、Shertler、M.、Schneider、M.およびJ. Turner、「インターネットセキュリティ協会および主要管理プロトコル」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412] Orman、H。、「The Oakley Key Deicination Protocol」、RFC 2412、1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Phyuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, September 1998.
[RFC2627] Wallner、D.、Harder、E。and R. Agee、「マルチキャストの重要な管理：問題とアーキテクチャ」、RFC 2627、1998年9月。
[RSA] RSA Laboratories, "PKCS #1 v2.0: RSA Encryption Standard", October 1998.
[RSA] RSA Laboratories、「PKCS＃1 V2.0：RSA暗号化標準」、1998年10月。
[FS00] N. Ferguson and B. Schneier, "A Cryptographic Evaluation of IPsec, CounterPane", http://www.counterpane.com/ipsec.html.
[FS00] N.ファーガソンとB.シュナイアー、「IPSEC、カウンターペンの暗号化評価」、http：//www.counterpane.com/ipsec.html。
[GKMARCH] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Group Key Management Architecture", Work in Progress.
[Gkmarch] M. Baugher、R。Canetti、L。Dondeti、F。Lindholm、「Group Key Management Architecture」、Work in Progress。
[IKEv2] D. Harkins, et. al., "Proposal for the IKEv2 protocol", Work In Progress.
[IKEV2] D. Harkins、et。al。、「IKEV2プロトコルの提案」、進行中の作業。
[KINK] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", Work in Progress.
[Kink] M. Thomas、J。Vilhuber、「Kerberized Internet negatiation of Keys（Kink）」、進行中の作業。
[NNL] D. Naor, M. Naor and J. Lotspiech, "Revocation and Tracing Schemes for Stateless Receivers", Advances in Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, pp. 41-62. A full version of the paper appears in http://www.wisdom.weizmann.ac.il/~naor/.
[NNL] D. Naor、M。NaorおよびJ. Lotspiech、「ステートレスレシーバーの取り消しと追跡スキーム」、Cryptogy、Crypto '01、Springer-verlag LNCS 2139、2001、pp。41-62の進歩。ペーパーのフルバージョンは、http：//www.wisdom.weizmann.ac.il/~naor/に表示されます。
[OFT] D. Mcgrew and A. Sherman, "Key Establishment in Large Dynamic Groups Using One-Way Function Trees", Manuscript submitted to IEEE Transactions on Software Engineering. A full version of the paper appears in http://download.nai.com/products/media/nai/ misc/oft052098.ps, 1998
[OFT] D. McGrewおよびA. Sherman、「一方向関数ツリーを使用した大規模なダイナミックグループの主要設立」、原稿はソフトウェアエンジニアリングに関するIEEEトランザクションに提出されました。ペーパーのフルバージョンは、http：//download.nai.com/products/media/nai/ misc/oft052098.ps、1998に掲載されています。
[PK01] R.Perlman, C.Kaufman, "Analysis of the IPsec Key Exchange Standard", WET-ICE conference, 2001. http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
[PK01] R.Perlman、C.Kaufman、「IPSEC Key Exchange Standardの分析」、Wet-Ice Conference、2001。http：//sec.femto.org/wetice-2001/papers/radia-paper.pdf
[RFC2093] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification," RFC 2093, July 1997.
[RFC2093] Harney、H。、およびC. Muckenhirn、「Group Key Management Protocol（GKMP）仕様」、RFC 2093、1997年7月。
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture," RFC 2094, July 1997.
[RFC2094] Harney、H。およびC. Muckenhirn、「グループキー管理プロトコル（GKMP）アーキテクチャ」、RFC 2094、1997年7月。
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367] McDonald、D.、Metz、C。およびB. Phan、「PF_KEY Key Management API、バージョン2」、RFC 2367、1998年7月。
[RFC3550] Schulzrinne, H., Casner, S., Jacobson, V. and R. Frederick, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, June 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Jacobson、V。およびR. Frederick、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 3550、2003年6月。
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996.
[Skeme] H. Krawczyk、「Skeme：インターネット用の多目的な安全なキー交換メカニズム」、ISOCセキュアネットワークおよび分散システムシンポジウム、1996年。
[STS] Diffie, P. van Oorschot, M. J. Wiener, "Authentication and Authenticated Key Exchanges, Designs, Codes and Cryptography", 2, 107-125 (1992), Kluwer Academic Publishers.
[STS] Diffie、P。VanOorschot、M。J。Wiener、「認証と認証された主要な交換、デザイン、コード、暗号化」、2、107-125（1992）、Kluwer Academic Publishers。
Appendix A: Alternate GDOI Phase 1 protocols
付録A：代替GDOIフェーズ1プロトコル
This section describes a manner in which other protocols could be used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1 protocol. However, they are not specified as a part of this document. A separate document MUST be written in order for another protocol to be used as a GDOI Phase 1 protocol.
このセクションでは、ISAKMPフェーズ1プロトコルの代わりに他のプロトコルをGDOIフェーズ1プロトコルとして使用できる方法について説明します。ただし、このドキュメントの一部として指定されていません。別のプロトコルをGDOIフェーズ1プロトコルとして使用するには、別のドキュメントを記述する必要があります。
Other possible phase 1 protocols are also described in [GKMARCH].
他の可能なフェーズ1プロトコルも[GKMARCH]で説明されています。
Any GDOI phase 1 protocol MUST satisfy the requirements specified in Section 2 of this document.
GDOIフェーズ1プロトコルは、このドキュメントのセクション2で指定された要件を満たす必要があります。
Version 2 of the IKE protocol (IKEv2) is a work in progress [IKEv2]. That protocol seeks to simplify the IKE Phase 1 and Phase 2 protocols, and improve the security of the IKE protocol. An IKEv2 Phase 1 negotiates an IPSEC SA during phase 1, which was not possible in IKE. However, IKEv2 also defines a phase 2 protocol. The phase 2 protocol is protected by the Phase 1, similar in concept to how IKE Quick Mode is protected by the IKE Phase 1 protocols in [RFC2409].
IKEプロトコル（IKEV2）のバージョン2は、進行中の作業です[IKEV2]。このプロトコルは、IKEフェーズ1およびフェーズ2プロトコルを簡素化し、IKEプロトコルのセキュリティを改善しようとしています。IKEV2フェーズ1は、IKEでは不可能だったフェーズ1でIPSEC SAと交渉しています。ただし、IKEV2はフェーズ2プロトコルも定義します。フェーズ2プロトコルは、[RFC2409]のIKEフェーズ1プロトコルによってIKEクイックモードが保護される方法と同様のフェーズ1によって保護されています。
IKEv2 may not include a DOI value in the SA payload. However, since GDOI uses a unique port, choice of a phase 2 protocol in the SA payload using a GDOI value is not necessary. It is expected that an IKEv2 Phase 1 protocol definition could be run on the GDOI port. The SA payload in the protocol would be specific to GDOI, or omitted if not needed at all.
IKEV2は、SAペイロードにDOI値を含めない場合があります。ただし、GDOIは一意のポートを使用するため、GDOI値を使用してSAペイロードでフェーズ2プロトコルを選択する必要はありません。IKEV2フェーズ1プロトコル定義をGDOIポートで実行できると予想されます。プロトコルのSAペイロードはGDOIに固有のものであるか、まったく必要でない場合は省略されます。
The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in the same manner as described in this document.
GroupKey-Pullプロトコルは、このドキュメントで説明されているのと同じ方法でIKEV2フェーズ1プロトコルに従います。
A work in progress [KINK] has defined a method of encapsulating an IKE Quick Mode [RFC2409] encapsulated in Kerberos KRB_AP_REQ and KRB_AP_REP payloads. KINK provides a low-latency, computationally inexpensive, easily managed, and cryptographically sound method of setting up IPSec security associations.
進行中の作業[Kink]は、Kerberos KRB_AP_REQおよびKRB_AP_REPペイロードにカプセル化されたIKEクイックモード[RFC2409]をカプセル化する方法を定義しました。Kinkは、IPSECセキュリティアソシエーションをセットアップするための低遅延、計算的に安価で、簡単に管理され、暗号化された健全な方法を提供します。
The KINK message format includes a GDOI field in the KINK header. The [KINK] document defines the DOI for the IPSEC DOI.
Kinkメッセージ形式には、KinkヘッダーにGDOIフィールドが含まれています。[kink]ドキュメントは、ipsec doiのdoiを定義します。
A new DOI for KINK could be defined which would encapsulate a GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP payloads. As such, GDOI would benefit from the computational efficiencies of KINK.
Kerberos KRB_AP_REQおよびKRB_AP_REPペイロードのGroupKey-Pull Exchangeをカプセル化するKink用の新しいDOIを定義できます。そのため、GDOIはキンクの計算効率の恩恵を受けるでしょう。
Authors' Addresses
著者のアドレス
Mark Baugher Cisco Systems 5510 SW Orchid Street Portland, OR 97219, USA
マーク・ボーサー・シスコ・システム5510 SWオーキッド・ストリート・ポートランド、または米国97219
Phone: (503) 245-4543 EMail: mbaugher@cisco.com
電話：（503）245-4543メール：mbaugher@cisco.com
Thomas Hardjono VeriSign 401 Edgewater Place, Suite 280 Wakefield, MA 01880
Thomas Hardjono Verisign 401 Edgewater Place、Suite 280 Wakefield、MA 01880
Phone: 781-245-6996 EMail: thardjono@verisign.com
電話：781-245-6996メール：thardjono@verisign.com
Hugh Harney Sparta 9861 Broken Land Parkway Columbia, MD 21046
ヒュー・ハーニー・スパルタ9861壊れたランドパークウェイコロンビア、メリーランド21046
Phone: (410) 381-9400 x203 EMail: hh@sparta.com
電話：（410）381-9400 x203メール：hh@sparta.com
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA
ブライアン・ワイス・シスコ・システム170 W.タスマン・ドライブ、サンノゼ、CA 95134-1706、米国
Phone: (408) 526-4796 EMail: bew@cisco.com
電話：（408）526-4796メール：bew@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。