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.
著作権（C）インターネット協会（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はIPSECとIPまたはアプリケーション層で動作し、潜在的に他のデータセキュリティプロトコルによって使用されるグループセキュリティアソシエーションを管理します。これらのセキュリティアソシエーションは、一つ以上のキー暗号化キー、トラフィック暗号化キー、またはグループのメンバーによって共有されるデータを保護します。
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].
この文書は、グループ鍵管理のための解釈のISAMKPドメイン（DOI）は「解釈のグループドメイン」（GDOI）と呼ばれる提示します。このグループ鍵管理モデルでは、GDOIプロトコルは、許可グループのメンバー間でセキュリティアソシエーションを確立グループメンバーと「グループコントローラ/鍵サーバ」（GCKS）、[4.6.2 RFC2401]の間で実行されます。 ISAKMPは、交渉の二つの "段階" [P.16のRFC2408]を定義します。 GDOIは、フェーズ1のセキュリティアソシエーションにより保護されなければなりません。このドキュメントはインターネットDOI [RFC2407、RFC2409]からのフェーズ1セキュリティアソシエーション（SA）の定義が組み込まれています。他の可能なフェーズ1のセキュリティアソシエーションタイプは、ISAKMP標準[Pに係るフェーズ2交換は、この文書で定義されている付録Aに述べ、そして新しいペイロードと交換を提案しています。 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
SAペイロードを以下SAペイロード3を以下の1）GDOI 2）KEK（SAK））TEK（SAT）
4) Key Download Array (KD) 5) Sequence number (SEQ) 6) Proof of Possession (POP)
4）鍵ダウンロードアレイ（KD）5）シーケンス番号（SEQ）所有の6）証明（POP）
There are two new exchanges.
二つの新しい交流があります。
1) A Phase 2 exchange creates Re-key and Data-Security Protocol SAs.
1）フェーズ2交換は、再キーとデータ・セキュリティプロトコルのSAを作成します。
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.
グループの「再キー」SAおよび/または「データセキュリティ」SAのためと呼ばれる新しいフェーズ2交換、「GROUPKEY-PULL、」ダウンロードキー。再鍵SAは、グループに共通鍵暗号化キー、またはKEKを含みます。データセキュリティSAは、データトラフィック[セクション2.1 RFC2407]を暗号化または復号化するために、データ・セキュリティプロトコルによって使用されるデータ暗号化キー、またはTEKを含みます。 KEKまたはTEKのためのSAは、認証キー、暗号化キー、暗号化ポリシー、および属性を含んでいます。 GROUPKEYプル交換部材がGCKSからこれらのSAの検索を開始するための動作を「プル」を使用します。
2) A datagram subsequently establishes additional Rekey and/or Data-Security Protocol SAs.
2）データグラムは、その後、追加のリキーおよび/またはデータ・セキュリティプロトコルのSAを確立します。
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データグラムが再キーまたはデータ・セキュリティSAを作成または更新するためにメンバーにGCKSから「プッシュ」されます。再キーSAはGROUPKEY-PUSHメッセージを保護します。このように、GROUPKEY-PULLは、後続GROUPKEY-PUSHメッセージを保護するために、少なくとも1つの再キーSAを確立する必要があります。 GCKSは、KEKの再キーSAを使用してGROUPKEY-PUSHメッセージを暗号化します。 GDOIは[RFC2627]効率的にグループメンバを追加および削除する論理鍵階層（LKH）アルゴリズムを用いてグループ鍵管理アルゴリズムのためのKEKのアレイの使用を収容します。 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が再キーSAをリフレッシュするために使用することができますが、GROUPKEY-PUSHの最も一般的な用途は、データのセキュリティプロトコルのためのデータ・セキュリティSAを確立することです。 GDOIは、データセキュリティのさまざまなプロトコルをサポートするために、将来の拡張に対応することができます。この文書では、唯一のセキュリティプロトコル、IPsecのESPのためのデータ・セキュリティSAを指定します。別のRFCは、このような将来のセキュアリアルタイムトランスポートプロトコルなどの他のデータ・セキュリティ・プロトコルのサポートを指定します。セキュリティプロトコルは、TEKを使用し、IPsecのESPは、IKEフェーズ2つのキーを使用し、フェーズ2 SAを所有しているのと同じように、データ・セキュリティ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メッセージを作成、管理、またはグループのセキュリティアソシエーションを削除するために使用されています。前述したように、これらのセキュリティアソシエーションは、一つ以上のキー暗号化キー、トラフィック暗号化キー、またはマルチキャストおよびグループのセキュリティアプリケーションのためのグループメンバーによって共有されるデータを保護します。
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]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
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のセキュリティプロトコルは、グループSAを確立するためにGDOIを使用してから利益を得ることができます。
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.
データセキュリティプロトコルのSAは、グループトラフィックを保護する必要があります。 GDOIは、そのグループのトラフィックがユニキャストまたはマルチキャストパケットとして送信されるかどうかに制限を提供しません。しかし、GDOIは、データ・セキュリティSAによって保護されたパケットは、グループ通信の一部となり、民間と決してあることが意図されているデータのセキュリティプロトコルによる鍵管理の仕組みとして使用してはいけません。
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は「フェーズ1」プロトコルによって保護されなければならない「フェーズ2」プロトコルです。 「フェーズ1」プロトコルは、以下の保護を提供する任意のプロトコルであってもよいです。
o Peer Authentication o Confidentiality o Message Integrity
メッセージ整合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」プロトコルは、しかしながら、プロトコルの使用は、この文書の一部が考慮されていない記載されている付録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交換の目標は、特定のグループのメンバーで再キーおよび/またはデータ・セキュリティSAを確立することです。フェーズ1 SAはGROUPKEY-PULLを保護します。所与のフェーズ1 SAのための複数のGROUPKEYプル交換があってもよいです。 GROUPKEYプル交換は、データセキュリティキー（のTEK）及び/又はフェーズ1 SAの保護下鍵（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のアイデンティティは、グループキーのフェーズ2（GROUPKEY-PULL）要求を許可するために使用することができます。第二に、新しいアイデンティティがGROUPKEY-PULL要求に渡すことができます。新しいIDは、グループに固有であると承認グループメンバーとしてホルダーを同定するためにグループの所有者によって署名された証明書を使用することができます。実証の所持ペイロードは、所有者がフェーズ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プルHASHペイロードに使用される鍵付きハッシュで「キー」であるSKEYID_aを計算します。この文書で定義されたフェーズ1を使用する場合、SKEYID_aは[RFC2409]に従って導出されます。 IKE HASHペイロード生成[RFC 2409のセクション5.5]と同様に、各GROUPKEYプルメッセージは、値の一意に定義されたセットをハッシュ。ナンスはHASHを並べ替えると、リプレイ攻撃に対するいくつかの保護を提供します。リプレイ保護は、鍵管理サーバが誘致することを攻撃からGCKSを保護することが重要です。
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は、「活気」、または最近のGROUPKEY-PULLメッセージのリプレイに対して保証するためにナンスを使用しています。リプレイ攻撃が原因間違ったSKEYID_aに現在のフェーズ1 GROUPKEY-PULLメッセージは、以前のフェーズ1に基づいて再生される場合は、ハッシュ計算が失敗するのコンテキスト内でのみ有効です。ナンスがこれまでに評価される前にメッセージが処理を失敗します。それはピアがライブであることを証明プロトコルでメッセージを受信するまで再生保護の利益を得るために、ピアのいずれかのためには、それは可能な限り多くの処理を延期しなければなりません。例えば、レスポンダは、ハッシュペイロードに適切に含まれる（KEペイロードが含まれていた場合）、共有のDiffie-Hellman数を計算するかがNRでメッセージを受信するまで、新しいSAをインストールしてはいけません。
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.
ノンスは、活気を証明するまでGCKSがグループメンバを追加しないことを確実にするためにプロトコル交換で追加のメッセージを必要とします。 GROUPKEYプル部材開始剤は、返されるメッセージのハッシュに、そのノンス、ニッケルを見つけることを期待します。そしてGROUPKEYプルGKCS応答者は、次のExchangeのように、グループ鍵材料を提供する前に返されたメッセージのハッシュで、そのナンス、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])
HASH（1）= PRF（SKEYID_a、M-ID |ニッケル| 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
セクション5.7で説明したようにPOPペイロードが構成されています。 *フェーズ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枚のクッキー及びメッセージ識別子（M-ID）を使用するISAKMPヘッダーペイロードです。ナンスは活気があることが証明される前にのみSAポリシーペイロードを返すGCKSと、最初の二つの交換に含まれていることに留意されたいです。 HASHペイロード[RFC2409]は、ピアがフェーズ1シークレット（SKEYID_a）とメッセージID、M-IDによって識別される交換のためのノンスを有することを証明します。活気が確立されると、最後のメッセージは、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
ノンスとHASHペイロードに加えて、部材開始剤は、ISAKMP IDペイロードを介して参加することを希望するグループを識別する。 GCKSレスポンダはSEQペイロードのシーケンス番号の現在の値のメンバーに通知します。シーケンス番号はGROUPKEY-PUSHデータグラム（セクション4）注文します;部材は、シーケンス番号は、任意の新しいSAをインストールする前に、（それがいずれかを保持している場合）、メンバーがグループのために保持する前SEQペイロードよりも大きいことを確認しなければなりません。 SAペイロードはSA KEKの属性が含まれている場合はSEQペイロードが存在しなければなりません。 GCKSレスポンダはDOI、KEKおよび/またはTEKキーイング材料を記述するSAペイロード、のグループの暗号化ポリシーのメンバーに通知し、認証が変換します。 SPIはまた、GCKSによって決定され、SAペイロード鎖（セクション5.2を参照）にダウンロードされます。 SA KEK属性は交渉したがダウンロードされません再キーSA、のためのISAKMPクッキーのペアが含まれています。このドキュメントのセクション5.4で定義されているSA TEK属性は、SPIが含まれています。 2番目のメッセージは、このSAペイロードをダウンロードします。再キーSAはSAペイロードに定義されている場合、KDは、KEKが含まれます。もし一つ以上のデータ・セキュリティ
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).
SAはSAペイロードで定義されている、KDはのTEKが含まれています。そこに特定のグループのためのTEKの最初のセットであり、（セクション4を参照）将来TEK GROUPKEY-PUSHメッセージの必要性をなくすことができれば、これは有用です。
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のアイデンティティから分離されている任意CERTペイロード内GROUPKEYプル交換にアイデンティティを確立することができます。部材が通過するときに新しいCERT、所有の証明（POP）ペイロードは、それに付随します。 POPペイロードは、メンバーまたはGCKSはそれを認証非常に秘密を使用していることを示しています。 POP_I部材がその認可を立証するために、グループの所有者によって署名され、証明書を通過する際に、メンバーによって署名されたノンスNiとNr個を含むハッシュを含むISAKMP SIGペイロードです。 GCKSがグループの所有者によって署名され、証明書を通過する際POP_Rは、特定のグループのための鍵を提供するためにその権限を証明するために、GCKSによって署名された連結ノンス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秘密のXORとオークリー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].
クッキーは、サービス保護の拒否の弱い形態として、ISAKMPヘッダに使用されています。 GDOI GROUPKEYプル交換はISAKMP [RFC2408]に記載のクッキーを使用します。
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交換のために値32を有しています。
Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section 3.1]
フラグは、メッセージID、長さは、[RFC2408、セクション3.1] ISAKMPに従ってれます
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としてアウトオブバンド方式を介してグループ識別子及び許容されるPhase 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を選択し、ノンス、ペイロードを作成し、グループ識別子を含む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.
第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とし、看板、それを含むハッシュを生成します。これは、POPペイロードの内容になります。必要であれば、CERTペイロードはPOPペイロードに署名するために使用される秘密鍵に対応する公開鍵を保持する構成されています。
The initiator constructs the third GDOI message by including the CERT and POP payloads (if needed) and creating HASH(3).
開始剤は、（必要な場合）CERT及びPOPペイロードを含み、HASH（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.
第GDOIメッセージを受信すると、イニシエータはHASH（4）を検証します。レスポンダが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.
SEQペイロードが存在する場合、SEQペイロードのシーケンス番号は、このグループの以前に受信したシーケンス番号と照合されなければなりません。それは以前に受信した数より少ない場合、それは古いとみなされ、無視されるべきです。 2 GROUPKEY-PULLメッセージが並行して起こった場合に発生する可能性があり、かつシーケンス番号が2 GROUPKEY-PULLメッセージの結果がGCKSから返された時間の間に変更しました。
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.
開始剤は、以前に特定のポリシーを識別するSAペイロードで送らのSPIの鍵パケットにSPIを一致、KDキーパケットを解釈します。キーと政策が一致した後の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はHASH（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はノンスNrを含む第2 GDOIメッセージ、及びトラフィックのSA、およびSA KEKポリシーのSA TEKペイロードが続くSAペイロードのグループ（のポリシーを構築しますグループ）。
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.
第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ペイロードを含む第4 GDOIメッセージを構築する（GCKSメッセージをリキー送信する場合）、以前にSA TEK及びSA KEKペイロードで送信ポリシーに対応するキーを含むKDペイロード、及びCERT及びPOPペイロード（必要な場合） 。
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メッセージは再キー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
*再キーSA KEKによって保護されました。暗号化は、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は、再鍵および/またはデータセキュリティSAのポリシー（例えば、保護スイート）と属性（例えば、SPI）を定義します。 GCKSまたは代理人は、必要に応じてSIGの検証のためにCERTペイロードを提供します。 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ペイロード自体を除く含む）暗号化の前にメッセージ全体のハッシュの署名です。接頭文字列は、再入力データグラムの署名がGDOIプロトコルにおいて他の目的に使用することができないことを保証します。
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は、新しいクッキーペアを持つ新しい再鍵SAに対するKEKまたはKEK配列を含んでいます。 KDペイロードが新しいSA KEK属性（セクション5.3）を有する場合、再鍵SAは、新しいSAが同じグループ識別子（セクション3.2のメッセージ1で指定されたID）を有するとされているのと同じシーケンスカウンタをインクリメントで置換されていますセクション3.2のメッセージ4で初期化。 SAはSA TEKペイロードを定義する場合、これはKD（5.5節）で運ばれた材料をキーイングして、新しいデータ・セキュリティSAが作成されたメンバーに通知します。
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データグラムでなければなりません。これは、シーケンス番号とKDペイロードで送らKEKアレイ部に対応するSAペイロードにポリシーを含む各データグラムになります。
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メッセージは、他の情報の中で、新しいキーダウンロードを運ぶもののGROUPKEY-PUSHメッセージはグループKEKによって保護されています。たて生成された秘密は、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_TEKs（およびそれに関連するキー）を使用して変更された場合も通常必要とされています。新しい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.
フォワードアクセスコントロールグループの所望の特性である場合、KDペイロードにおける新しいSA_TEKsと関連するキー・パケットは、グループメンバーシップを変更GROUPKEY-PUSHメッセージに含まれてはいけません。 SA_TEKポリシーとKDペイロード内の関連するキーのパケットが新しいKEKで保護されていないので、これが必要です。それが新しいKEKによって保護されますので、アクセスを拒否されたメンバーには表示されませんので、二GROUPKEY-PUSHメッセージは、新たな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.
グループのための前方アクセス制御ポリシーは、グループへのアクセスを拒否しているメンバーからグループポリシーの変更を維持含まれている場合は、そのグループKEKを変更する二つの連続GROUPKEY-PUSHメッセージはGCKSによって送らなければなりません。最初GROUPKEY-PUSHメッセージは、グループの新しいKEKを作成します。アクセスを拒否されているグループのメンバーは、新しいKEKにアクセスすることはできませんが、GROUPKEY-PUSHメッセージは、現在のKEKの下で保護されているので、グループポリシーが表示されます。変更されたグループポリシーを含有し、再度KEKを変更する後続GROUPKEY-PUSHメッセージは、完全なフォワードアクセス制御を可能にします。 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に添加される場合、これらの方法は、これらの方法は、単一GROUPKEYプッシュメッセージ内に維持される方法フォワードアクセス制御ポリシーを指定提供する、複数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プルPOPペイロードに承認のために使用されたとしてGROUPKEY-PUSHメッセージにSIGのペイロードに署名するために同じキーを使用しないでください。同じキーを使用する必要がある場合、異なるハッシュ関数は、SIGのペイロードのためのベースとして使用されるよりPOPペイロードのためのベースとして使用されるべきです。
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とは異なり、クッキーペアは完全にGCKSによって決定されます。 GDOI ISAKMPヘッダーのクッキー対はGCKSによって管理セキュア・グループを区別するために再鍵SAを識別する。したがって、GDOIはSPIとしてクッキーフィールドを使用しています。
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.
交換タイプは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]
長さは、[RFC2408、セクション3.1] ISAKMPに従います
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.
GCKSは、放送の終了時に、たとえば、SAを削除するために受信機に信号をすることができます時間があります。鍵の削除はGDOI GROUPKEY-PUSHメッセージの一部として、[RFC2408、セクション3.15] ISAKMP削除ペイロードを送信することによって達成することができます。
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メッセージ内SEQペイロード以下に配置されてもよいです。 GCKSがグループメンバーに送信するこれ以上のSAを持っていない場合は、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値が削除ペイロードに定義することができることに留意されたいです。 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.
GCKSが正しいクッキー対でISAKMP HDR、および前リキーデータグラムより1大きいシーケンス番号を含む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交換で送信されたSAペイロードの構造と同義です。 （静的KEKの場合）またはグループメンバーシップ（LKHの場合）KEKに対する変更がある場合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交換で送らKDペイロードへの構造と同義です。 SA_KEK属性が、対応するSAペイロードに含まれていた場合KEK鍵（KEKまたは配列）が含まれます。 TEKキーはSAペイロードに含まれる各SA_TEK属性のために送信されます。
A CERT payload is added if the initiator needs to provide its certificate.
イニシエータは、その証明書を提供する必要がある場合CERTペイロードが追加されます。
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.
最後から二番目のステップにおいて、開始剤は、既に形成されたキー管理メッセージに続く文字列「再入力」をハッシュ。ハッシュは、署名された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データグラムを受信したグループメンバーは、既存のSAにISAKMP HDRにおけるクッキーペアを一致します。メッセージが復号化され、かつデータグラムの形式が検証されます。これは、（グループのサービス拒否攻撃の一部として送信することができる）明らかに病気に形成されたメッセージを雑草。
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.
SEQペイロードのシーケンス番号は、それが以前に受信したシーケンス番号より大きいことを保証するために検証され、それが許容値のウィンドウ内に収まります。
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ペイロードがSA_KEK属性が含まれている場合）SA及びKDペイロードは新しいGDOIリキーSAをもたらす処理され及び/又は新規のIPsec SAがシステムに追加されます。
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を識別するために使用されます。グループIDは、特定のIPマルチキャストグループにマッピングすることができる、または、関連するマルチキャストストリームの集合を表すものなどのより一般的な識別子を指定することができます。
The Identification Payload is defined as follows:
次のように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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! RESERVE2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！次ペイロード！ RESERVED！ペイロード長！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ IDタイプ！ RESERVE2！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜識別データ〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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 RESERVED（1つのオクテット） - 未使用は、ゼロ（0）でなければなりません。
o Payload Length (2 octets) -- Length, in octets, of the identification data, including the generic header.
ペイロード長（2つのオクテット）O - 長、オクテットで、ジェネリックヘッダを含む識別データ、の。
o Identification Type (1 octet) -- Value describing the identity information found in the Identification Data field.
O識別タイプ（1つのオクテット） - 値は、識別データフィールドに見つかった識別情報を記述する。
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フィールドのために割り当てられた値を示しています。
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.
セキュリティアソシエーションペイロードがGDOIについては、RFC 2408で定義されている、セキュリティが再キーとデータ・セキュリティのSAの両方の属性を主張するためにGCKSによって使用されます。
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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！次ペイロード！ RESERVED！ペイロード長！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ DOI！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！状況 ！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！ SAは、次のペイロード属性！ RESERVED2！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！
The Security Association Payload fields are defined as follows:
次のようにSAペイロードフィールドが定義されています。
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つのオクテット） - 上で定義した通りGROUPKEYプルまたはGROUPKEY-PUSHメッセージのための次のペイロードを識別する。次のペイロードはSAKペイロードまたはSATペイロードタイプでもよいが、次の非セキュリティアソシエーション型のペイロードてはなりません。
o RESERVED (1 octet) -- Must be zero.
O RESERVED（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つのオクテット） - 値2であるGDOIあります。
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オクテット）を属性 - SAKペイロードまたはSATペイロードのいずれかでなければなりません。状況が存在すると、各ペイロードタイプのために必要とされるの説明については、セクション5.2.1を参照。
o RESERVED (2 octets) -- Must be zero.
RESERVED（2つのオクテット）O - ゼロでなければなりません。
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ペイロードのいずれかが存在しなければならない0または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.
この緯度は、様々なグループポリシーが収容されることを可能にします。グループポリシーが再キーSAの使用を必要としない場合たとえば、GCKSは、すべてのSAの更新が登録SAを使用して実行されるため、グループメンバーにSA KEK属性を送信する必要はありません。また、グループポリシーが再キーSAを使用するだけで登録SAの一環として、グループメンバーにKEKをダウンロードすることを選択するかもしれません。したがって、（SA KEK属性で）KEKポリシーは、再鍵SAメッセージ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.
複数SATSを指定すると、複数のセッションが同じグループと複数のストリームセッションに関連付けられる（例えば、ビデオ、オーディオ、およびテキスト）が、個々のセキュリティアソシエーションポリシーにそれぞれの一部にすることができます。
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プル動作に固有のパラメータを含んでいます。送信元と送信先のアイデンティティはGROUPKEY-PULLデータグラムのために使用されアイデンティティを記述する。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！次ペイロード！ RESERVED！ペイロード長！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！議定書！ SRC IDタイプ！ SRC IDポート！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！SRC IDデータレン！ SRC識別データ〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！ DST IDタイプ！ DST IDポート！DST IDデータレン！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！ DST識別データ〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！ ！ 〜SPI〜！ ！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！ POPアルゴリズム！キーの長さをPOP！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ 〜KEK属性〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！
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つのオクテット） - GROUPKEYプルまたはGROUPKEY-PUSHメッセージのための次のペイロードを識別する。このメッセージに対してのみ有効次のペイロードタイプにはSA TEKペイロードが存在しないことを示すためにSATのペイロードまたはゼロです。
o RESERVED (1 octet) -- Must be zero.
O RESERVED（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プロトコル（1つのオクテット） - 値の再入力データグラムの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識別データフィールドに見つかった識別情報を記述する。定義された値は、IANAののisakmpd-レジストリにIPSEC識別タイプセクション[ISAKMP-REG]によって指定されます。
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 Portフィールドは無視されるべきであることを意味しています。
o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC Identification Data field.
O SRC IDデータレン（1つのオクテット） - SRC識別データフィールドの長さを指定する値。
o SRC Identification Data (variable length) -- Value, as indicated by the SRC ID Type.
O SRC識別データ（可変長） - SRC IDの種類によって示されるように値。
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つのオクテット） - 値がDST識別データフィールドに見つかった識別情報を記述する。定義された値は、IANAののisakmpd-レジストリにIPSEC識別タイプセクション[ISAKMP-REG]によって指定されます。
o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP).
O DST ID Protの（1つのオクテット） - 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.
DST識別データフィールドの長さを指定する値 - DST IDデータレン（1つのオクテット）O。
o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type.
O DST識別データ（可変長） - DST IDの種類によって示されるように値。
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は、最初の8つのオクテットGROUPKEY-PUSHメッセージISAKMP HDRの「イニシエータクッキー」フィールドとなり、第8オクテットが同じHDRの「レスポンダクッキー」なるISAKMPヘッダークッキーペアでなければなりません。前述したように、これらのクッキーは、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.
POPペイロードアルゴリズム - Oアルゴリズム（2つのオクテット）POP。定義された値を次の表に指定されています。何POPアルゴリズムは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.
POPペイロードキーの長さ - Oキー長（2つのオクテット）POP。何POPアルゴリズムは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.
KEK_MANAGEMENT_ALGORITHM、KE_OAKLEY_GROUP：以下の属性のみGROUPKEYプルメッセージに含まれてもよいです。
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.
KEK_MANAGEMENT_ALGORITHMは、複数のキー（例えば、LKH）を定義し、管理アルゴリズムは、これらのキーのためのアルゴリズムを指定しない場合、その後KEK_ALGORITHM属性によって定義されたアルゴリズムは、の一部として含まれているすべてのキーのために使用されなければならない定義されている場合管理。
This algorithm specifies DES using the Cipher Block Chaining (CBC) mode as described in [FIPS81].
このアルゴリズムは、[FIPS81]に記載されているようにDESは、暗号ブロック連鎖（CBC）モードを使用して指定します。
This algorithm specifies 3DES using three independent keys as described in "Keying Option 1" in [FIPS46-3].
【FIPS46-3]の「オプション1をキーイング」に記載されているように、このアルゴリズムは、3つの独立したキーを使用して、3DESを指定します。
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-MODES]で推奨されているようにAESの動作モードは、暗号ブロック連鎖（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_HASH_SHA1を意味するものではありSIG_ALG_DSSかSIG_ALG_ECDSS、ある場合SIG_HASH_ALGORITHMは必要ありません。
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.
SIG_ALG_RSA：GDOIの実装は次のアルゴリズム属性をサポートしなければなりません。
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クラスはOAKLEYグループがGDOI GROUPKEY-PULL交換のオプションのKEペイロードにPFSの秘密を計算するために使用される定義されています。この属性は、[IPSEC-REG] IANAのIPsec-レジストリにグループの定義に割り当てられた値を使用しています。
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つのオクテット） - GROUPKEYプルまたはGROUPKEY-PUSHメッセージのための次のペイロードを識別する。このメッセージに対してのみ有効な次のペイロードタイプは、セキュリティアソシエーション属性ないもう存在を示すために、別のSATのペイロードまたはゼロです。
o RESERVED (1 octet) -- Must be zero.
O RESERVED（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プロトコル-ID（1つのオクテット） - セキュリティプロトコルを指定する値。次の表は、セキュリティプロトコルの値を定義します
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つのオクテット） - バリュー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識別データフィールドに見つかった識別情報を記述する。定義された値は、IANAののisakmpd-レジストリにIPSEC識別タイプセクション[ISAKMP-REG]によって指定されます。
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 Portフィールドは無視されるべきであることを意味しています。
o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC Identification Data field.
O SRC IDデータレン（1つのオクテット） - 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識別データ（可変長） - SRC IDの種類によって示されるように値。すべての送信者に共通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つのオクテット） - 値がDST識別データフィールドに見つかった識別情報を記述する。定義された値は、IANAののisakmpd-レジストリにIPSEC識別タイプセクション[ISAKMP-REG]によって指定されます。
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つのオクテット） - 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 Portフィールドは無視されるべきであることを意味しています。
o DST ID Data Len (1 octet) -- Value specifying the length of the DST Identification Data field.
DST識別データフィールドの長さを指定する値 - DST IDデータレン（1つのオクテット）O。
o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type.
O DST識別データ（可変長） - DST IDの種類によって示されるように値。
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].
ESPが使用される変換値の指定 - O ID（1オクテット）を形質転換。有効な値のリストは、IANAのisakmpd-レジストリ[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の属性 - ESPは、RFC 2407のセクション4.5からの属性。 GDOIは、すべてのIPSEC DOI SAがGDOI実装によって送ってはいけませんし、受信した場合GDOIの実装によって無視されたグループの説明[RFC2407、セクション4.5]、除くPROTO_IPSEC_ESPの属性をサポートしています。すべての必須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は、トランスポート、アプリケーション、およびインターネット層で動作し、他のセキュリティプロトコルが必要とする安全なグループのためにSAを確立するのに役立つはずです。これらの他のセキュリティプロトコルは、しかし、開発中のプロセスであるか、まだ存在していません。
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
プロトコルID特定のセキュリティプロトコルのためのSPIサイズOセキュリティプロトコルで必要な変換、属性とキーO SPIの生成方法〇〇
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ペイロードを再キーSAの一部として含まれる場合、キーダウンロードペイロードは、新しいDiffie-HellmanのとXORされる秘密を共有しました。 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！次ペイロード！ RESERVED！ペイロード長！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！キーパケット数！ RESERVED2！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ 〜キーパケット〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！
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 RESERVED（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の総数を含み、このデータブロックに渡される配列のキーを再生成します。
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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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タイプ！ RESERVED！ KDの長さ！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ ！ SPIサイズ！ SPI（変数）〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - ！ + - - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜キーパケットが〜+属性 - + - + - + - + - + - + - + - + - + - ！
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 RESERVED（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 Typeフィールドの値に固有のものです。以下のセクションでは、各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ペイロードに送信された各タイプに一致する一つの属性が存在しなければなりません。属性は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.
無TEKキーのパケットが登録KDペイロードに含まれている場合は、グループのメンバーが再キーSAの一部としてTEKを受け取ることを期待することができます。少なくとも一つの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.
アルゴリズムは、複数のキーを必要とする場合（例えば、3DES）は、全てのキーが一つの属性に含まれることになります。
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キーは、キーが暗号化に使用されるようにするため（例えば、DES_KEY1、DES_KEY2、DES_KEY3）に（パリティビットを含む）は、単一の192ビットの属性として指定されるであろう。
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ペイロードに送信された各タイプに一致する一つの属性が存在しなければなりません。属性は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ペイロードで唯一の存在でなければなりません。
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ペイロードに含まれている場合、唯一の存在がなければなりません。
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は、グループメンバー以上に送信される場合には、GROUPKEY-PUSHメッセージKDペイロードに含まれてはいけません。 LKH_DOWNLOAD_ARRAY属性はKDペイロードに含まれている場合、唯一の存在がなければなりません。
This attribute consists of a header block, followed by one or more LKH keys.
この属性は、一つ以上の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 ! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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バージョン！ LKH鍵の＃！ RESERVED！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ LKH鍵！ 〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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.
LKHバージョン（1つのオクテット）O - データでフォーマットされ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 RESERVED（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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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！キータイプ！ RESERVED！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜キー作成日！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜キーの有効期限日！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜キーハンドル！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ ！ 〜キーデータ〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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 RESERVED（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.
キー作成日（4つのオクテット）O - これは、このキーのデータが最初に生成されたときの時間値です。ゼロの時間値は、このキーが有効ではありませんその前の時間がないことを示しています。
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.
キーの有効期限（4つのオクテット）O - これは、このキーは、もはや使用するために有効であるときの時間価値はあります。ゼロの時間値は、このキーは有効期限がないことを示しています。
o Key Handle (4 octets) -- This is the randomly generated value to uniquely identify a key within an LKH ID.
キーハンドル（4つのオクテット）O - これは一意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
この属性は、グループ用の鍵を更新するために使用されます。グループ全体をリキーするGROUPKEY-PUSHメッセージKDのペイロードに含まれる可能性が最も高いです。この属性は、セクション5.5.3.1で定義されるように、一つ以上のLKHキー続いて、ヘッダブロックから成り
There may be any number of UPDATE_ARRAY attributes included in a KD payload.
UPDATE_ARRAY任意の数のKDのペイロードに含まれる属性があるかもしれません。
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 ! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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バージョン！ LKH鍵の＃！予約済み！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ LKH ID！ RESERVED2！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！キーハンドル！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！ LKH鍵！ 〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
o LKH version (1 octet) -- Contains the version of the LKH protocol which the data is formatted in. Must be one.
LKHバージョン（1つのオクテット）O - データでフォーマットされ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 RESERVED（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.
キーハンドル（4つのオクテット）O - これは一意第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.
セクション5.5.3.1で定義されているようLKHキーがあります。 LKHキー構造はLKH IDから順にキーツリーの経路に沿ってキーを含むグループKEKで最高潮に達する、LKH_UPDATE_ARRAYヘッダに見出されます。各LKH鍵の鍵データフィールドはLKH_UPDATE_ARRAY属性でそれを前のLKH鍵で暗号化されます。最初LKHキーLKH_UPDATE_ARRAYヘッダに見出さLKH IDとキーハンドルによって定義されたキーで暗号化されます。
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].
シーケンス番号ペイロード（配列）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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！次ペイロード！ RESERVED！ペイロード長！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +！シーケンス番号！ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
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 RESERVED（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.
シーケンス番号（4つのオクテット）O - このフィールドには、グループのための単調増加カウンタ値を含みます。これはGCKSによってゼロに初期化され、それぞれその後に送信されるメッセージにインクリメントされます。したがって、所与のリキーSAのために送られる最初のパケットはGDOI実装がリキーSAの属性として、シーケンスカウンタを保持し、GROUPKEY-PUSHメッセージを受信すると、カウンタをインクリメント1のシーケンス番号を有することになります。シーケンス番号の現在の値が登録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.
ハッシュは、（）署名で使用されるハッシュ関数であるPOP_HASH =ハッシュ（| |ニッケル-NR「ポップ」）：GCKS、GCKSデリゲートまたはメンバーは、以下の値のハッシュに署名します。
The "pop" prefix ensures that the signature of the POP payload cannot be used for any other purpose in the GDOI protocol.
「ポップ」プレフィックスは、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.
ノンス、ペイロードのデータ部（すなわち、Ni_bとNr_bはHASHsに含まれる）は、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）のエンティティ認証を実行し、そのメッセージの送信元の認証を提供します。このプロトコルはまた、無担保ネットワーク上のman-in-ミドル、接続ハイジャック、再生、反射、およびサービス拒否（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.
ISAKMPフェーズ1つのプロトコル、ISAKMPフェーズ1つのプロトコルによって保護されている新たな交換と呼ばれるGROUPKEYプル、および新しいメッセージGROUPKEY-PUSHと呼ばれるこの文書に記載されているようにGDOIの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はGROUPKEYプル交換を保護するために[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プルプロトコルで送信します。
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.
成功のman-in-the-middleまたは接続ハイジャック攻撃は、鍵の確立中に通信エンティティのうちの1つまたは複数のエンティティ認証を箔。 GDOIは、man-in-the-middle攻撃を倒すために、フェーズ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クッキーメカニズムを使用します。 GDOIエンティティが正常に洗練された攻撃者によって模倣することができる良いクッキー、かどうかを確認しなければならないという点で、これは、サービス保護の否定の「弱い」の形です。フェーズ1クッキーメカニズムはステートフルで、クッキーのためのメモリリソースをコミットしますが、ステートレスなクッキーは、サービス拒否攻撃に対する防御力の向上、。
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プル交換は、グループメンバーは、SASとGCKSからキーを要求することを可能にします。これは、フェーズ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.
メッセージ認証ハッシュが（フェーズ1交換で得られる）SKEYID_a上になるように定義された各メッセージ内のハッシュペイロード、ISAKMPメッセージID、およびメッセージ内のすべてのペイロードによって提供されます。為替の唯一の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にのみ知られている秘密を含みます。攻撃者が検出されないメッセージを変更することはできませんので、これは、man-in-the-ミドルと接続ハイジャック攻撃を防ぐことができます。
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.
ナンスはGROUPKEY-PULL交換の新鮮さを提供しています。グループメンバーとGCKS交換ナンスは、最初の2つのメッセージを値。これらのナンスは、後続のHASHペイロードの計算に含まれています。グループメンバーとGCKSは、独自のnonceが含まれてHASHを受ける前に、計算コストが高いタスクを実行してはなりません。それはそれ自身のノンスを含む有効HASHペイロードと引き換えに第3のメッセージを受信するまでGCKSは、グループ管理状態（例えば、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プルメッセージは、それに先行するフェーズ1交換からクッキーペアを使用してメッセージを識別する。上述したようにクッキーが無効のクッキーとGROUPKEYプルメッセージが廃棄されるという意味で、サービス保護の拒否の弱いフォームを提供します。
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プル交換におけるCERTペイロードは、認証を含む証明書を提出するグループメンバーまたはGCKSは、公開鍵/秘密鍵のペアを識別するピアに属性ならびに可能。 GROUPKEYプルPOPペイロードは、認証インフラストラクチャは、それが秘密鍵の所有であることを証明することによりGROUPKEYプル認証基盤と異なるところの認可を達成することができます。
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プッシュ交換はGCKSがグループメンバーにSASとキーを送信することができ、単一のメッセージです。これは、IPマルチキャストグループを使用して、すべてのメンバーに送信される可能性があります。これは、効率的なリキーとグループメンバーシップの調整機能を提供します。
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交換は、メッセージの認証に使用された公開鍵を特定します。 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交換により設立された暗号鍵でGROUPKEY-PUSHメッセージを暗号化します。
This combination of confidentiality and message authentication services protects the GROUPKEY-PUSH message from man-in-middle and connection-hijacking attacks.
機密性とメッセージ認証サービスのこの組み合わせは、インミドルマン-と接続ハイジャック攻撃から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.
クッキーペアがGROUPKEY-PUSHメッセージのセキュリティアソシエーションを識別する。クッキーは、このように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.
メッセージ認証のために使用されるデジタル署名は、メッセージ認証コードよりもはるかに大きな計算コストがあり、GROUPKEY-PUSHメッセージを処理GDOIメンバーにサービス拒否攻撃の効果を増幅することができます。デジタル署名の追加コストは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.
サービス拒否攻撃を増幅するデジタル署名の電位が最も安価な暗号演算を最初に実行されるグループメンバが取る動作の順序によって緩和されます。基部材は、第1対称暗号を使用してメッセージを復号化します。それが有効に形成されたメッセージの場合、シーケンス番号は、リプレイウィンドウに対してチェックされます。シーケンス番号が有効である場合にのみ、デジタル署名が検証されます。このように実装されるサービス拒否攻撃のための順で、攻撃者は、機密保持のために使用される対称暗号化キー、および有効なシーケンス番号の両方を知っている必要があります。一般的にはこれが唯一の現在のグループのメンバーが効果的にサービス拒否攻撃を展開できることを意味します話します。
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がグループに配信されているとして、いくつかのグループメンバーが同じGROUPKEY-PUSHメッセージのグループへのアクセスを拒否された場合に発生することがあります。 4.2.1項で説明したように、順方向アクセス制御は、グループメンバーシップの変更は、新しいポリシーとのTEKから分離GCKSから送信された複数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.
ISAKMP DOI番号はGDOI SAペイロードとしてSAペイロードを識別するために必要とされます。 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].
名前空間の一部は、「RESERVED」が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.
著者は蘭カネッティ、キャシーメドウズ、アンドレアColegrove、およびLakshminath Dondetiに感謝します。蘭交流やペイロード定義の変化につながっている安全なグループ暗号、上の著者をお勧めしています。キャシーは所持交換の証拠だけでなく、いくつかのman-in-the-middle攻撃に対してリプレイ攻撃を含め、このドキュメントの以前のバージョンでは、いくつかの問題を特定しました。アンドレアは、このドキュメントのグループポリシーセクションに貢献しました。 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]「の動作のブロック暗号モードのための勧告」、アメリカの米国、技術総合研究所、は、NIST Special Publication 800-38A 2001版、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モード」、アメリカの米国、技術総合研究所、連邦情報処理標準（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]ブラドナーの、S.、BCP 14、RFC 2119、1997年3月 "のRFCsにおける使用のためのキーワードは、要求レベルを示すために"。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、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]モーガン、D.、Shertler、M.、シュナイダー、M.とJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル"、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]オーマン、H.、 "OAKLEYキー決意プロトコル"、RFC 2412、1998年11月。
[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]カーン、P.とW.シンプソン、 "Photuris：セッション鍵管理プロトコル"、RFC 2522、1999年3月。
[RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, September 1998.
[RFC2627]ウォルナー、D.、ハーダー、E.およびR.アゲ、 "マルチキャストのためのキー管理：問題とアーキテクチャ"、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. Schneier著、 "IPsecの、CounterPaneの暗号評価"、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.カネッティ、L. Dondeti、F.リンドホルム、 "グループ鍵管理アーキテクチャ"、進行中の作業。
[IKEv2] D. Harkins, et. al., "Proposal for the IKEv2 protocol", Work In Progress.
【のIKEv2] D.ハーキンズ、ら。アル。「のIKEv2プロトコルの提案」、進行中の作業。
[KINK] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", Work in Progress.
[KINK] M.トーマス、J. Vilhuber、 "キーのケルベロスインターネットネゴシエーション（KINK）"、ProgressのWork。
[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は、 "失効およびステートレス受信機のトレーススキーム"、暗号理論、シュプリンガー・フェアラークLNCS 2139、2001、頁41から62クリプト'01の進歩します。紙のフルバージョンが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.マグリューとA.シャーマン、「大規模な動的グループ内鍵確立は、一方向関数ツリーを使用する」、原稿は、ソフトウェア工学上の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、WET-ICE会議 "のIPsec鍵交換標準の分析"、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]ハーニー、H.、およびC. Muckenhirn、 "グループ鍵管理プロトコル（GKMP）仕様、" RFC 2093、1997年7月。
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture," RFC 2094, July 1997.
[RFC2094]ハーニー、H.およびC. Muckenhirn、 "グループ鍵管理プロトコル（GKMP）アーキテクチャ、" RFC 2094、1997年7月。
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]マクドナルド、D.、メッツ、C.およびB. Phanさん、 "PF_KEY鍵管理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.、ヤコブソン、V.およびR.フレデリック、 "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は、：、ISOC安全なネットワークと分散システムシンポジウム、1996年サンディエゴ「SKEMEは、多彩なインターネットのための鍵交換メカニズムを固定します」。
[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]ディフィー、P.バンOorschot、M. J.ウィーナー、 "認証および認証鍵交換、デザイン、コード及び暗号化"、2、107から125（1992）、Kluwerの学術出版。
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で指定された要件を満たさなければなりません。
A.1. IKEv2 Phase 1 protocol
A.1。 IKEv2のフェーズ1つのプロトコル
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プロトコルのバージョン2（IKEv2の）のIKEv2]進行中の作業です。そのプロトコルは、IKEフェーズ1およびフェーズ2プロトコルを簡素化し、IKEプロトコルのセキュリティを改善することを目的とします。 IKEv2のフェーズ1は、IKEでは不可能であったフェーズ1の間IPSEC SAをネゴシエート。しかし、IKEv2のは、位相2のプロトコルを定義します。フェーズ2プロトコルは、IKEクイックモードは、[RFC2409]でIKEフェーズ1のプロトコルによって保護されている方法と概念的に同様のフェーズ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プルプロトコルは同様にIKEv2のフェーズ1のプロトコルに従うことになります。
A.2. KINK Protocol
A.2。 KINKプロトコル
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.
KINKのための新しいDOIは、Kerberos KRB_AP_REQとKRB_AP_REPペイロードでGROUPKEY-PULL交換をカプセル化することになるに定義することができます。そのため、GDOIはKINKの計算効率の恩恵を受けるだろう。
Authors' Addresses
著者のアドレス
Mark Baugher Cisco Systems 5510 SW Orchid Street Portland, OR 97219, USA
マークBaugherシスコシステムズ5510 SWオーキッド・ストリート、ポートランド、OR 97219、USA
Phone: (503) 245-4543 EMail: mbaugher@cisco.com
電話：（503）245-4543 Eメール：mbaugher@cisco.com
Thomas Hardjono VeriSign 401 Edgewater Place, Suite 280 Wakefield, MA 01880
トーマスHardjonoベリサイン401エッジウォータープレイス、スイート280ウェイクフィールド、MA 01880
Phone: 781-245-6996 EMail: thardjono@verisign.com
電話：781-245-6996 Eメール：thardjono@verisign.com
Hugh Harney Sparta 9861 Broken Land Parkway Columbia, MD 21046
ヒューハーニースパルタ9861ブロークン・ランドパークウェイ、コロンビア、MD 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、USA
Phone: (408) 526-4796 EMail: bew@cisco.com
電話：（408）526-4796 Eメール：bew@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。