RFC3547 日本語訳
3547 The Group Domain of Interpretation. M. Baugher, B. Weis, T.Hardjono, H. Harney. July 2003. (Format: TXT=108901 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Baugher
Request for Comments: 3547 B. Weis
Category: Standards Track Cisco
T. Hardjono
Verisign
H. Harney
Sparta
July 2003
Baugherがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3547年のB.ウィスカテゴリ: 標準化過程コクチマスT.Hardjono Verisign H.ハーニースパルタ2003年7月
The Group Domain of Interpretation
解釈のグループドメイン
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
グループ重要経営者側が安全なグループコミュニケーションを支持するように、このドキュメントはInterpretation(DOI)のISAMKP Domainを寄贈します。 GDOIはグループセキュリティ協会を経営します。(協会はIPSECとIPを動く潜在的に他のデータ機密保護プロトコルか応用層によって使用されます)。 これらのセキュリティ協会は1個以上のキーをコード化するキー、交通をコード化するキー、またはグループのメンバーによって共有されたデータを保護します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. GDOI Applications. . . . . . . . . . . . . . . . . . . . 5
1.2. Extending GDOI . . . . . . . . . . . . . . . . . . . . . 5
2. GDOI Phase 1 protocol. . . . . . . . . . . . . . . . . . . . . 6
2.1. ISAKMP Phase 1 protocol. . . . . . . . . . . . . . . . . 6
2.1.1. DOI value. . . . . . . . . . . . . . . . . . . . 6
2.1.2. UDP port . . . . . . . . . . . . . . . . . . . . 6
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 6
3.1. Authorization. . . . . . . . . . . . . . . . . . . . . . 7
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Perfect Forward Secrecy. . . . . . . . . . . . . 9
3.2.2. ISAKMP Header Initialization . . . . . . . . . . 9
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 GDOIアプリケーション。 . . . . . . . . . . . . . . . . . . . 5 1.2. GDOI. . . . . . . . . . . . . . . . . . . . . 5 2を広げています。 GDOI Phase1は議定書を作ります。 . . . . . . . . . . . . . . . . . . . . 6 2.1. ISAKMP Phase1は議定書を作ります。 . . . . . . . . . . . . . . . . 6 2.1.1. DOI値。 . . . . . . . . . . . . . . . . . . . 6 2.1.2. UDPは.6 3を移植します。 交換. . . . . . . . . . . . . . . . . . . . 6 3.1をGROUPKEY引いてください。 認可。 . . . . . . . . . . . . . . . . . . . . . 7 3.2. メッセージ. . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1。 前進の秘密主義を完成させてください。 . . . . . . . . . . . . 9 3.2.2. ISAKMPヘッダー初期設定. . . . . . . . . . 9
Baugher, et. al. Standards Track [Page 1] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[1ページ]。
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
3.3. 創始者操作. . . . . . . . . . . . . . . . . . 10 3.4。 受信機操作。 . . . . . . . . . . . . . . . . . . 11 4. メッセージをGROUPKEY押してください。 . . . . . . . . . . . . . . . . . . . . 11 4.1. 前進の秘密主義(PFS)を完成させてください。 . . . . . . . . . . . . . 12 4.2. 前進の、そして、後方のアクセスは制御されます。 . . . . . . . . . . 12 4.2.1. アクセス管理要件を転送してください。 . . . . . . 13 4.3. Key Management. . . . . . . . . . . . . . 14 4.4の代表団。 署名キーの使用。 . . . . . . . . . . . . . . . . . 14 4.5. ISAKMPヘッダー初期設定. . . . . . . . . . . . . . 14 4.6。 SAsの削除。 . . . . . . . . . . . . . . . . . . . . 14 4.7. GCKS操作。 . . . . . . . . . . . . . . . . . . . . 15 4.8. メンバー操作を分類してください。 . . . . . . . . . . . . . . . . 16 5. 有効搭載量と定義された値。 . . . . . . . . . . . . . . . . . 16 5.1. 識別有効搭載量. . . . . . . . . . . . . . . . . 17 5.1.1。 識別タイプは.185.2を評価します。 セキュリティ協会有効搭載量. . . . . . . . . . . . . . 18 5.2.1。 SAペイロードに続く有効搭載量。 . . . . . . . 19 5.3. SA KEKペイロード. . . . . . . . . . . . . . . . . . . . . 19 5.3.1。 KEK属性. . . . . . . . . . . . . . . . . 22 5.3.2。 KEK_管理_アルゴリズム. . . . . . . . . . . . 22 5.3.3。 KEK_アルゴリズム。 . . . . . . . . . . . . . . . . . 23 5.3.4. KEKの_の主要な_の長さ. . . . . . . . . . . . . . . . . 23 5.3の.5。 KEKの_の主要な_生涯. . . . . . . . . . . . . . . . 24 5.3.6。 SIG_は_アルゴリズム. . . . . . . . . . . . . . . 24 5.3.7を論じ尽くします。 SIG_アルゴリズム。 . . . . . . . . . . . . . . . . . 24 5.3.8. SIGの_の主要な_の長さ. . . . . . . . . . . . . . . . . 25 5.3の.9。 KE_オークリー_は分類します。 . . . . . . . . . . . . . . . . 25 5.4. SA TEK有効搭載量. . . . . . . . . . . . . . . . . . . . . 25 5.4.1。 プロト_IPSEC_、特に。 . . . . . . . . . . . . . . . . 26 5.4.2. 他のセキュリティプロトコル. . . . . . . . . . . . 28 5.5。 主要なダウンロード有効搭載量. . . . . . . . . . . . . . . . . . 28 5.5.1。 TEKはタイプをダウンロードします。 . . . . . . . . . . . . . . . 30 5.5.2. KEKはタイプをダウンロードします。 . . . . . . . . . . . . . . . 31 5.5.3. LKHはタイプをダウンロードします。 . . . . . . . . . . . . . . . 32 5.6. 一連番号有効搭載量。 . . . . . . . . . . . . . . . . 35 5.7. 所有物の証拠。 . . . . . . . . . . . . . . . . . . 36 5.8. 一回だけ。 . . . . . . . . . . . . . . . . . . . . . . . . . 36 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 36 6.1. ISAKMPフェーズ1. . . . . . . . . . . . . . . . . . . . . 37 6.1.1。 認証. . . . . . . . . . . . . . . . . 37 6.1.2。 秘密性。 . . . . . . . . . . . . . . . . 37 6.1.3. 介入者攻撃保護。 . . . . . . 38 6.1.4. 再生/反射攻撃保護。 . . . . . . 38 6.1.5. サービス妨害保護. . . . . . . . . . 38 6.2。 交換. . . . . . . . . . . . . . . . . 38 6.2.1をGROUPKEY引いてください。 認証. . . . . . . . . . . . . . . . . 38 6.2.2。 秘密性。 . . . . . . . . . . . . . . . . 39 6.2.3. 介入者攻撃保護。 . . . . . . 39
Baugher, et. al. Standards Track [Page 2] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[2ページ]。
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
6.2.4. 再生/反射攻撃保護。 . . . . . . 39 6.2.5. サービス妨害保護. . . . . . . . . . 39 6.2.6。 認可。 . . . . . . . . . . . . . . . . . 40 6.3. 交換. . . . . . . . . . . . . . . . . 40 6.3.1をGROUPKEY押してください。 認証. . . . . . . . . . . . . . . . . 40 6.3.2。 秘密性。 . . . . . . . . . . . . . . . . 40 6.3.3. 介入者攻撃保護。 . . . . . . 40 6.3.4. 再生/反射攻撃保護。 . . . . . . 40 6.3.5. サービス妨害保護. . . . . . . . . . 41 6.3.6。 アクセス管理. . . . . . . . . . . . . 41 7を進めてください。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 41 7.1. ISAKMP土井. . . . . . . . . . . . . . . . . . . . . . . 41 7.2。 有効搭載量タイプ。 . . . . . . . . . . . . . . . . . . . . . 42 7.3. 新しいName空間。 . . . . . . . . . . . . . . . . . . . . 42 7.4. UDPは.428を移植します。 知的所有権は声明. . . . . . . . . . . . 42 9を正します。 承認. . . . . . . . . . . . . . . . . . . . . . . 43 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.1。 引用規格. . . . . . . . . . . . . . . . . . 43 10.2。 有益な参照. . . . . . . . . . . . . . . . . 44付録A: GDOI Phase1プロトコル. . . . . . . . . . . 46A.1を交替してください。 IKEv2 Phase1は.46A.2について議定書の中で述べます。 プロトコルをねじれさせてください。 . . . . . . . . . . . . . . . . . . . . . 46人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 47の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 48
1. Introduction
1. 序論
This document presents an ISAMKP Domain of Interpretation (DOI) for group key management called the "Group Domain of Interpretation" (GDOI). In this group key management model, the GDOI protocol is run between a group member and a "group controller/key server" (GCKS), which establishes security associations [Section 4.6.2 RFC2401] among authorized group members. ISAKMP defines two "phases" of negotiation [p.16 RFC2408]. The GDOI MUST be protected by a Phase 1 security association. This document incorporates the Phase 1 security association (SA) definition from the Internet DOI [RFC2407, RFC2409]. Other possible Phase 1 security association types are noted in Appendix A. The Phase 2 exchange is defined in this document, and proposes new payloads and exchanges according to the ISAKMP standard [p. 14 RFC2408].
このドキュメントは「解釈のグループドメイン」(GDOI)と呼ばれるグループ重要管理のためにInterpretation(DOI)のISAMKP Domainを寄贈します。 このグループかぎ管理モデルでは、GDOIプロトコルはグループのメンバーと認可されたグループのメンバーの中にセキュリティ協会[セクション4.6.2RFC2401]を設立する「グループコントローラ/主要なサーバ」(GCKS)の間の走行です。 ISAKMPは交渉[p.16 RFC2408]の2「フェーズ」を定義します。 GDOI MUST、Phase1セキュリティ協会によって保護されてください。 このドキュメントはインターネットDOI[RFC2407、RFC2409]からPhase1セキュリティ協会(SA)定義を取り入れます。 ISAKMP規格[p.14RFC2408]に従って、セキュリティ協会がPhase2が交換するAppendix A.に述べられるのをタイプする他の可能なPhase1は本書では定義されて、新しいペイロードと交換を提案します。
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
1) GDOI SA2) SAペイロード3)に続くSA KEK(SAK) SAペイロードに続くSA TEK(土曜日)
Baugher, et. al. Standards Track [Page 3] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[3ページ]。
4) Key Download Array (KD)
5) Sequence number (SEQ)
6) Proof of Possession (POP)
4) 主要なダウンロードアレイ(KD) 5) 一連番号(SEQ) 6) 所有物の証拠(ポップス)です。
There are two new exchanges.
2回の新しい交換があります。
1) A Phase 2 exchange creates Re-key and Data-Security Protocol SAs.
1) Phase2交換はRe-キーとData-セキュリティプロトコルSAsを作成します。
The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for a group's "Re-key" SA and/or "Data-security" SA. The Re-key SA includes a key encrypting key, or KEK, common to the group; a Data-security SA includes a data encryption key, or TEK, used by a data-security protocol to encrypt or decrypt data traffic [Section 2.1 RFC2407]. The SA for the KEK or TEK includes authentication keys, encryption keys, cryptographic policy, and attributes. The GROUPKEY-PULL exchange uses "pull" behavior since the member initiates the retrieval of these SAs from a GCKS.
「GROUPKEY-牽引力」と呼ばれる新しいPhase2交換はグループの「再主要な」SA、そして/または、「データ機密保護」SAのためにキーをダウンロードします。 Re主要なSAはキーをコード化するキー、またはグループに共通のKEKを含んでいます。 Data-セキュリティSAはデータ機密保護プロトコルによって使用される、データ通信量が[セクション2.1 RFC2407]であるとコード化するか、または解読するデータ暗号化キー、またはTEKを含んでいます。 KEKかTEKのためのSAは認証キー、暗号化キー、暗号の方針、および属性を含んでいます。 メンバーがGCKSからこれらのSAsの検索を開始するので、交換が使用するGROUPKEY-PULLは振舞いを「引きます」。
2) A datagram subsequently establishes additional Rekey and/or Data-Security Protocol SAs.
2) データグラムは次に、追加Rekey、そして/または、Data-セキュリティプロトコルSAsを設立します。
The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the members to create or update a Re-key or Data-security SA. A Re-key SA protects GROUPKEY-PUSH messages. Thus, a GROUPKEY-PULL is necessary to establish at least one Re-key SA in order to protect subsequent GROUPKEY-PUSH messages. The GCKS encrypts the GROUPKEY-PUSH message using the KEK Re-key SA. GDOI accommodates the use of arrays of KEKs for group key management algorithms using the Logical Key Hierarchy (LKH) algorithm to efficiently add and remove group members [RFC2627]. Implementation of the LKH algorithm is OPTIONAL.
GROUPKEY-PUSHデータグラムは、Re-キーかData-セキュリティSAを作成するか、またはアップデートするためにGCKSからメンバーまで「押されます」。 Re主要なSAはGROUPKEY-PUSHメッセージを保護します。 したがって、GROUPKEY-PULLが、その後のGROUPKEY-PUSHメッセージを保護するために少なくとも1Re主要なSAを証明するのに必要です。 GCKSは、KEK Re主要なSAを使用することでGROUPKEY-PUSHメッセージをコード化します。 GDOIは、効率的に、グループのメンバー[RFC2627]を加えて、免職するのにLogical Key Hierarchy(LKH)アルゴリズムを使用することでKEKsのアレイのグループかぎ管理アルゴリズムの使用を収容します。 LKHアルゴリズムの実現はOPTIONALです。
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.
Re主要なSAをリフレッシュするのにこのドキュメントによって指定されたGROUPKEY-PUSHは使用できますが、GROUPKEY-PUSHの最も一般の使用はデータ機密保護プロトコルのためにData-セキュリティSAを設立することです。 GDOIは、さまざまなデータ機密保護プロトコルをサポートするために今後の拡大を収容できます。 このドキュメントは1つのセキュリティプロトコルにしかデータ機密保護SAsを指定しないで、IPsecは超能力です。 別々のRFCは将来の安全なレアル-時間Transportプロトコルなどの他のデータ機密保護プロトコルのサポートを指定するでしょう。 そして、セキュリティプロトコルがTEKを使用して、同じようにデータ機密保護SAがそのIPsec超能力用途を「所有している」、IKE Phase2キー、Phase2SAを所有しています。 GDOI、IPsec超能力用途、TEK。
Thus, GDOI is a group security association management protocol: All GDOI messages are used to create, maintain, or delete security associations for a group. As described above, these security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members for multicast and groups security applications.
したがって、GDOIはグループセキュリティ協会管理プロトコルです: すべてのGDOIメッセージが、グループのためにセキュリティ協会を創設するか、維持するか、または削除するのに使用されます。 これらのセキュリティ協会が上で説明されるように1つを保護するか、キーをよりコード化するキー、交通をコード化するキー、またはデータが、マルチキャストのためにグループのメンバーで共有して、セキュリティアプリケーションを分類します。
Baugher, et. al. Standards Track [Page 4] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[4ページ]。
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].
キーワードが解釈しなければならない、本書では現れるとき、BCP14RFC2119[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりません。
1.1. GDOI Applications
1.1. GDOIアプリケーション
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を使用するかもしれません。それらのデータ通信量を保証する超能力。 セクション5.4 .1 GDOIがどう超能力のための必要なSAパラメタを運ぶかを指定します。 このように、GDOIは超能力パケットのグループ認証が共有、グループを使用している超能力が合わせるマルチキャストを支持します(超能力パケットのユニークな源の認証は可能ではありません)。
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を設立するかもしれません。
1.2. Extending GDOI
1.2. GDOIを広げています。
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を使用できるというわけではありません。超能力。 多くのレアルTime Transportプロトコルアプリケーションが、例えば、IP層を超えてRTPヘッダーの圧縮効率と輸送独立[RFC3550]を保存するためにセキュリティを必要とします。 将来のRTPセキュリティプロトコルはグループSAsを証明するのに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 MUSTはそのセキュリティプロトコルのためにGDOIによって伝えられたデータ機密保護SAパラメタを指定します。 これらのパラメタはこの.2通のセクション5.4ドキュメントにリストアップされています。
Data security protocol SAs MUST protect group traffic. GDOI provides no restriction on whether that group traffic is transmitted as unicast or multicast packets. However, GDOI MUST NOT be used as a key management mechanism by a data security protocol when the packets protected by the data-security SA are intended to be private and never become part of group communications.
データ機密保護プロトコルSAsはグループ交通を保護しなければなりません。 GDOIはそのグループ交通がユニキャストかマルチキャストパケットとして伝えられるかどうかに関する制限を全く提供しません。 しかしながら、GDOI MUST NOT、かぎ管理メカニズムとして、データ機密保護プロトコルで、データ機密保護SAによって保護されたパケットが個人的であり、グループコミュニケーションの一部に決してならないことを意図したら、使用されてください。
Baugher, et. al. Standards Track [Page 5] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[5ページ]。
2. GDOI Phase 1 protocol
2. GDOI Phase1プロトコル
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がaである、「「フェーズの1インチのプロトコル」で保護しなければならない2インチのプロトコルの位相を合わせてください。 「フェーズの1インチのプロトコルは以下の保護に備えるどんなプロトコルであるかもしれませんも」
o Peer Authentication o Confidentiality o Message Integrity
o 同輩Authentication o Confidentiality o Message Integrity
The following sections describe one such "phase 1" protocol. Other protocols which may be potential "phase 1" protocols are described in Appendix A. However, the use of the protocols listed there are not considered part of this document.
以下のセクションはそのような」の1つについて「フェーズの1インチのプロトコル説明します。 潜在的「フェーズの1インチのプロトコルはAppendix A.Howeverで説明されて、そこに記載されたプロトコルの使用はこのドキュメントの一部であると考えられないかもしれない」他のプロトコル。
2.1. ISAKMP Phase 1 protocol
2.1. ISAKMP Phase1プロトコル
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.
このドキュメントはISAKMPが中古のaが「GDOIのためのフェーズの1インチのプロトコル」であることができたなら[RFC2409]で定義されるようにどう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 Phase1プロトコルがどうGDOI「フェーズの1インチのプロトコル」に関する必要条件を満たすかを説明します。
2.1.1. DOI value
2.1.1. DOI値
The Phase 1 SA payload has a DOI value. That value MUST be the GDOI DOI value as defined later in this document.
Phase1SAペイロードには、DOI値があります。 その値は後で本書では定義されるようにGDOI DOI値でなければなりません。
2.1.2. UDP port
2.1.2. UDPポート
GDOI MUST NOT run on port 500 (the port commonly used for IKE). IANA has assigned port 848 for the use of GDOI.
GDOI MUST NOTはポート500(IKEに一般的に使用されるポート)で走ります。 IANAはGDOIの使用のためにポート848を割り当てました。
3. GROUPKEY-PULL Exchange
3. GROUPKEY-牽引力の交換
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交換の目標は特定のグループのメンバーにRe-キー、そして/または、Data-セキュリティSAsを設立することです。 Phase1SAはGROUPKEY-PULLを保護します。 与えられたPhase1SAにおいて複数のGROUPKEY-PULL交換があるかもしれません。 GROUPKEY-PULL交換がキー(KEK)をコード化するデータ機密保護キー(TEKs)、そして/または、グループキーをダウンロードするか、またはKEKはPhaseの保護で1SAを整列させます。
Baugher, et. al. Standards Track [Page 6] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[6ページ]。
3.1. Authorization
3.1. 認可
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つの代替の手段があります。 まず最初に、(GROUPKEY-PULL)がグループキーのために要求するPhase2を認可するのにPhase1のアイデンティティを使用できます。 2番目に、GROUPKEY-PULL要求で新しいアイデンティティを通過できます。 新しいアイデンティティは、所有者が認可されたグループのメンバーであると認識するのにグループに特定であり、グループの所有者によってサインされる証明書を使用するかもしれません。 所有物のProofペイロードはそれを有効にします。所有者はPhase2のアイデンティティに関連している秘密鍵を所有しています。
3.2. Messages
3.2. メッセージ
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はPhase2交換です。 フェーズ1はGROUPKEY-PULL HASHペイロードで使用される合わせられた細切れ肉料理の中の「キー」であるSKEYIDを計算します。 本書では定義されたPhase1を使用するとき、[RFC2409]に従って、SKEYIDは引き出されます。 IKE HASHペイロード世代[RFC2409部5.5]のように、それぞれのGROUPKEY-PULLメッセージは唯一定義されたセットの値を論じ尽くします。 一回だけは、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メッセージの再生に対して一回だけを使用します。 反射攻撃は単に現在のPhase1の文脈で役に立ちます。 GROUPKEY-PULLメッセージが前のPhase1に基づいて再演されると、HASH計算は間違ったSKEYIDのため失敗するでしょう。 一回だけが今までに評価される前にメッセージは処理に失敗するでしょう。 どちらの同輩も反復操作による保護の恩恵を得るように、それは同輩が活動的であると立証するプロトコルのメッセージを受け取るまでできるだけ多くの処理を延期しなければなりません。 例えば、NrがHASHペイロードに適切に含まれている状態でメッセージを受け取るまで、Responderは共有されたディフィー-ヘルマン番号(KEペイロードが含まれていたなら)を計算してはいけませんし、また新しいSAsをインストールしてはいけません。
Nonces require an additional message in the protocol exchange to ensure that the GCKS does not add a group member until it proves liveliness. The GROUPKEY-PULL member-initiator expects to find its nonce, Ni, in the HASH of a returned message. And the GROUPKEY-PULL GKCS responder expects to see its nonce, Nr, in the HASH of a returned message before providing group-keying material as in the following exchange.
一回だけは活気を立証するまでGCKSがグループのメンバーを加えないのを保証するプロトコル交換における追加メッセージを必要とします。 GROUPKEY-PULLメンバー創始者は、返されたメッセージのHASHで一回だけ、Niを見つけると予想します。 そして、GROUPKEY-PULL GKCS応答者は、一回だけを見ると予想します、Nr、以下の交換のようにグループを合わせる材料を供給する前の返されたメッセージのHASHで。
Baugher, et. al. Standards Track [Page 7] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[7ページ]。
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]
創始者(メンバー)応答者(GCKS)------------------ ---------------- HDR*、細切れ肉料理(1)、Ni、ID--><--HDR*、細切れ肉料理(2)、Nr、SA HDR*細切れ肉料理(3)[KE_I]-->[本命][_Iを飛び出させる]<--(HDR*)は(4)、[KE_R][SEQ]KD[本命]を論じ尽くします。[_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、M ID|Ni|ID)HASH(2)=prf(SKEYID、M ID| Ni_b|Nr|SA)HASH(3)=prf(SKEYID、M ID| Ni_b| Nr_b[| KE_I][| CERT][| POP_I])HASH(4)はprfと等しいです。(SKEYID、M ID| Ni_b| Nr_b[| KE_R][| SEQ|]KD[| 本命][| 大衆的な_R])
POP payload is constructed as described in Section 5.7.
* Protected by the Phase 1 SA, encryption occurs after HDR
POPペイロードはセクション5.7で説明されるように構成されます。 * Phase1SAによって保護されて、暗号化は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]のようにPhase1クッキーを使用するISAKMPヘッダーペイロードとメッセージ識別子(M ID)です。 活気が立証される前にGCKSがSA方針ペイロードだけを返していて、一回だけが最初の2回の交換に含まれていることに注意してください。 HASHペイロード[RFC2409]は、同輩がメッセージイドでPhase1秘密(SKEYID)と交換のための一回だけを特定させると立証します、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
NonceとHASHペイロードに加えて、メンバー創始者はそれがISAKMP IDペイロードを通して加わりたがっているグループを特定します。 GCKS応答者はSEQペイロードの一連番号の現行価値についてメンバーに知らせます。 一連番号はGROUPKEY-PUSHデータグラム(セクション4)を注文します。 メンバーは、どんな新しいSAsもインストールする前に一連番号がメンバーがグループのために持っている前のSEQペイロード(いずれかも保持するなら)より大きいことを確認するためにチェックしなければなりません。 SAペイロードがSA KEK属性を含んでいるなら、SEQペイロードは存在していなければなりません。 ペイロードは材料を合わせるDOI、KEK、そして/または、TEKについて説明します。GCKS応答者はSAペイロードのグループの暗号の方針についてメンバーに知らせます、そして、認証は変形します。SPIsをまた、GCKSが決定されて、SAペイロードチェーンでダウンロードします(セクション5.2を見てください)。 SA KEK属性はRe主要なSAのためのISAKMPクッキー組を含んでいます。(交渉されませんが、SAはダウンロードされます)。 SA TEK属性はこのドキュメントのセクション5.4で定義されるようにSPIを含んでいます。 2番目のメッセージはこのSAペイロードをダウンロードします。 Re主要なSAがSAペイロードで定義されると、KDはKEKを含むでしょう。 1つ以上のData-セキュリティです。
Baugher, et. al. Standards Track [Page 8] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[8ページ]。
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).
SAsはSAペイロードで定義されて、KDはTEKsを含むでしょう。 これは、TEKsの1人の始発があれば特定のグループの役に立って、将来のTEK GROUPKEY-PUSHメッセージ(セクション4で、説明される)の必要性を取り除くことができます。
As described above, the member may establish an identity in the GROUPKEY-PULL exchange in an optional CERT payload that is separate from the Phase 1 identity. When the member passes a new CERT, a proof of possession (POP) payload accompanies it. The POP payload demonstrates that the member or GCKS has used the very secret that authenticates it. POP_I is an ISAKMP SIG payload containing a hash including the nonces Ni and Nr signed by the member, when the member passes a CERT, signed by the Group Owner to prove its authorization. POP_R contains the hash including the concatenated nonces Ni and Nr signed by the GCKS, when the GCKS passes a CERT, signed by the group owner, to prove its authority to provide keys for a particular group. The use of the nonce pair for the POP payload, transformed through a pseudo-random function (prf) and encrypted, is designed to withstand compromise of the Phase 1 key. Implementation of the CERT and POP payloads is OPTIONAL.
上で説明されるように、メンバーはPhase1のアイデンティティから別々の任意のCERTペイロードにGROUPKEY-PULL交換におけるアイデンティティをつくかもしれません。 メンバーが新しいCERTを渡すと、所有物(POP)ペイロードの証拠はそれに伴います。 POPペイロードは、メンバーかGCKSがそれを認証するまさしくその秘密を使用したのを示します。 POP_Iはメンバーによってサインされた一回だけのNiとNrを含む細切れ肉料理を含むISAKMP SIGペイロードです、メンバーが認可を立証するようにGroup OwnerによってサインされたCERTを渡すと。 POP_RはGCKSによってサインされた連結された一回だけのNiとNrを含む細切れ肉料理を含んでいます、GCKSが特定のグループにキーを提供する権威を立証するためにグループの所有者によってサインされたCERTを渡すと。 一回だけの組の擬似ランダム機能(prf)を通して変えられて、コード化されたPOPペイロードの使用は、Phase1キーの妥協に耐えるように設計されています。 CERTとPOPペイロードの実現はOPTIONALです。
3.2.1. Perfect Forward Secrecy
3.2.1. 完全な前進の秘密主義
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ペイロードが交換に使用されるなら、両側は、材料がKDに含んだ新しい合わせることを保護するのにDH秘密を計算して、それを使用します。 GCKS応答者は、オークリーIEXTKEY手順[RFC2412]のようにKDペイロードでDH秘密をxorして、メンバーInitiatorにそれを送るでしょう。(Initiatorは、この操作を繰り返すことによって、KDを回収します)。 KEペイロードの実現はOPTIONALです。
3.2.2. ISAKMP Header Initialization
3.2.2. ISAKMPヘッダー初期設定
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ヘッダーで使用されます。 ISAKMP[RFC2408]によると、GDOI GROUPKEY-PULL交換はクッキーを使用します。
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]によると、Minorバージョンは0です。
The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange.
Exchange Typeには、GDOI GROUPKEY-PULL交換のための値32があります。
Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section 3.1]
ISAKMPによると、旗、Message ID、およびLengthがあります。[RFC2408、セクション3.1]
Baugher, et. al. Standards Track [Page 9] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[9ページ]。
3.3. Initiator Operations
3.3. 創始者操作
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などのバンドで出ている方法でグループ識別子と許容できるPhase1方針を決定しなければなりません。 フェーズ1は、SAペイロードでGDOI DOIを使用することで開始されます。 Phase1がいったん完全になると、創始者州のマシンは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を選んで、一回だけのペイロードを作成して、グループ識別子を含むアイデンティティペイロードを造って、HASH(1)を発生させます。
Upon receipt of the second GDOI message, the initiator validates HASH(2), extracts the nonce Nr, and interprets the SA payload. If the policy in the SA payload is acceptable (e.g., the security protocol and cryptographic protocols can be supported by the initiator), the initiator continues the protocol.
2番目のGDOIメッセージを受け取り次第、創始者は、HASH(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ペイロードのコンテンツになります。 必要なら、POPペイロードに署名するのに使用される秘密鍵に対応しているのに公開鍵を保つCERTペイロードは構成されます。
The initiator constructs the third GDOI message by including the CERT and POP payloads (if needed) and creating HASH(3).
創始者は、CERTとPOPペイロード(必要であるなら)を含んで、HASH(3)を作成することによって、3番目のGDOIメッセージを構成します。
Upon receipt of the fourth GDOI message, the initiator validates HASH(4). If the responder sent CERT and POP_R payloads, the POP signature is validated.
4番目のGDOIメッセージを受け取り次第、創始者は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.
創始者はKDの主要なパケットを解釈します、主要なパケットで以前に特定の方針を特定するSAペイロードで送られたSPIsにSPIsを合わせて。 TEKsのために、創始者は、TEK方針に合っているパケットを、送る準備ができているか、またはキーと方針がいったん取り組むようになると、受ける準備ができています。 (以前にこのTEK方針のために方針とキーを受け取ったなら、創始者は、それが聞き古したであるといけないこのTEK方針を無視すると代わりに決めるかもしれません。) このグループにKEKがあるなら、KEK方針とキーは使用の準備ができるとしてマークされます。
Baugher, et. al. Standards Track [Page 10] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[10ページ]。
3.4. Receiver Operations
3.4. 受信機操作
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(応答者)はグループのメンバーからの入って来る要求の受け身に聞こうとします。 Phase1はグループのメンバーを認証して、それらとの安全なセッションをセットアップします。
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はSAペイロードのグループのために一回だけのNr、および方針を含む2番目のGDOIメッセージを構成します(グループコントローラがRe主要なメッセージをグループに送るなら)、続いて、トラフィックSAs、およびSA KEK方針のためにSA TEKペイロードを構成します。
Upon receipt of the third GDOI message the GCKS validates HASH(3). If the initiator sent CERT and POP_I payloads, the POP signature is validated.
3番目のGDOIメッセージを受け取り次第、GCKSはHASH(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は4番目のGDOIメッセージを構成します、SEQペイロード(GCKSがrekeyメッセージを送るなら)、以前にSA TEKで送られた方針に対応するキーを含むKDペイロード、SA KEKペイロード、CERT、およびPOPペイロードを含んでいて(必要であるなら)。
4. GROUPKEY-PUSH Message
4. GROUPKEY-プッシュメッセージ
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メッセージは、Re主要なSA KEKかKEK配列を取り替える、そして/または、新しいData-セキュリティSAを作成します。
Member GCKS or Delegate
------ ----------------
メンバーGCKSか代表------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
<。---- HDR*、SEQ、SA、KD、[本命]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はRe-キー、そして/または、Data-セキュリティSAsのために、方針(例えば、保護スイート)と属性(例えば、SPI)を定義します。 GCKSか代表が任意にCERTペイロードをSIGの検証に提供します。 KDは有効搭載量部で説明されるように主要なダウンロードペイロードです。
Baugher, et. al. Standards Track [Page 11] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[11ページ]。
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ペイロードはストリング"rekey"で前に置かれた暗号化(ヘッダーを含んで、SIGペイロード自体を除く)の前の全体のメッセージのハッシュの署名です。 前に置かれたストリングは、GDOIプロトコルのいかなる他の目的にもRekeyデータグラムの署名を使用できないのを確実にします。
If the SA defines an LKH KEK array or single KEK, KD contains a KEK or KEK array for a new Re-key SA, which has a new cookie pair. When the KD payload carries a new SA KEK attribute (section 5.3), a Re-key SA is replaced with a new SA having the same group identifier (ID specified in message 1 of section 3.2) and incrementing the same sequence counter, which is initialized in message 4 of section 3.2. If the SA defines an SA TEK payload, this informs the member that a new Data-security SA has been created, with keying material carried in KD (Section 5.5).
SAがLKH KEK配列か独身のKEKを定義するなら、KDは新しいRe主要なSAのためのKEKかKEK配列を含んでいます。(SAは新しいクッキー組います)。 KDペイロードが新しいSA KEK属性(セクション5.3)を運ぶとき、Re主要なSAを同じグループ識別子(セクション3.2に関するメッセージ1で指定されたID)を持って、セクション3.2に関するメッセージ4で初期化されるのと同じ系列カウンタを増加する新しいSAに取り替えます。 SAがSA TEKペイロードを定義するなら、これは、新しいData-セキュリティSAが作成されたことをメンバーに知らせます、材料を合わせるのがKD(セクション5.5)で運ばれている状態で。
If the SA defines a large LKH KEK array (e.g., during group initialization and batched rekeying), parts of the array MAY be sent in different unique GROUPKEY-PUSH datagrams. However, each of the GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH datagram. This results in each datagram containing a sequence number and the policy in the SA payload, which corresponds to the KEK array portion sent in the KD payload.
SAが大きいLKH KEK配列(例えば、グループ初期化とbatched rekeyingの間の)を定義するなら、異なったユニークなGROUPKEY-PUSHデータグラムで配列の部品を送るかもしれません。しかしながら、それぞれのGROUPKEY-PUSHデータグラムは完全に形成されたGROUPKEY-PUSHデータグラムであるに違いありません。 これはKDペイロードで送られたKEK配列部分に対応するSAペイロードの一連番号と方針を含む各データグラムをもたらします。
4.1. Perfect Forward Secrecy (PFS)
4.1. 完全な前進の秘密保持(Pfs)
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メッセージのための主要なダウンロードを保護しなければなりません。 さらなる研究にはこの問題があります。
4.2. Forward and Backward Access Control
4.2. 前進の、そして、後方のアクセスコントロール
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]とSubset Difference[NNL]を含んでいて。 これらのアルゴリズムは、GDOIと共に使用できましたが、このドキュメントの一部として指定されません。
Baugher, et. al. Standards Track [Page 12] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[12ページ]。
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かSubset Differenceなどのアルゴリズムは後のドキュメントの一部としてGDOIに加えられるかもしれません。 どんなそのような追加もStandards Actionの[RFC2434]で定義されるようにためであるに違いありません。
4.2.1. Forward Access Control Requirements
4.2.1. 前進のアクセス制御要件
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.
前進のアクセスコントロールがグループの必要な特性であるなら、グループ会員資格を変えるGROUPKEY-PUSHメッセージに新しいSA_TEKsとKDペイロードの関連主要なパケットを含んではいけません。 SA_TEK方針とKDペイロードの関連主要なパケットが新しいKEKと共に保護されないので、これが必要です。 2番目のGROUPKEY-PUSHメッセージは、新しいKEKと共に保護されて、その結果、アクセサリーが否定されたメンバーにとって目に見えるようにならないので、新しいSA_TEKSと彼らの関連キーを提供できます。
If forward access control policy for the group includes keeping group policy changes from members that are denied access to the group, then two sequential GROUPKEY-PUSH messages changing the group KEK MUST be sent by the GCKS. The first GROUPKEY-PUSH message creates a new KEK for the group. Group members, which are denied access, will not be able to access the new KEK, but will see the group policy since the GROUPKEY-PUSH message is protected under the current KEK. A subsequent GROUPKEY-PUSH message containing the changed group policy and again changing the KEK allows complete forward access control. A GROUPKEY-PUSH message MUST NOT change the policy without creating a new KEK.
グループにおいて、前進のアクセス制御方針が、グループへのアクセス、2つの当時の連続したGROUPKEY-PUSHメッセージが否定されるメンバーからグループ政策変更を妨げるのを含んでいるなら、グループKEK MUSTを変えて、GCKSによって送られてください。 最初のGROUPKEY-PUSHメッセージはグループのために新しいKEKを作成します。 グループのメンバー(アクセスは拒絶されます)は、新しいKEKにアクセスできませんが、GROUPKEY-PUSHメッセージが現在のKEKの下に保護されるので、グループ方針を見るでしょう。 変えられたグループ方針を含んでいて、再びKEKを変えるその後のGROUPKEY-PUSHメッセージは完全な前進のアクセスコントロールを許します。 新しいKEKを作成しないで、GROUPKEY-PUSHメッセージは方針を変えてはいけません。
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-PUSHメッセージを必要とする上の制限を取り除くかもしれません、それらのメソッドが、アクセス制御方針がただ一つのGROUPKEY-PUSHメッセージの中でどれくらい前方に維持されるかを指定するなら。
Baugher, et. al. Standards Track [Page 13] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[13ページ]。
4.3. Delegation of Key Management
4.3. Key Managementの委譲
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にこれを残します。
4.4. Use of signature keys
4.4. 署名キーの使用
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 SHOULD NOTは、GROUPKEY-PULL POPペイロードの承認に使用されたGROUPKEY-PUSHメッセージでSIGペイロードに署名するのに同じキーを使用します。 同じキーであるなら、aがPOPのためにSIGペイロードにベースとして使用されるよりペイロードを基礎づけて、中古の、そして、a異なったハッシュ関数がSHOULDであったに違いないなら使用されてください。
4.5. ISAKMP Header Initialization
4.5. ISAKMPヘッダー初期設定
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によって経営された安全なグループを差別化するためにReの主要な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]によると、Minorバージョンは0です。
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message.
Exchange Typeには、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]に従って、Encryptionビットを設定しなければなりません。 他のすべてのビットをゼロに設定しなければなりません。
Message ID MUST be set to zero.
メッセージIDをゼロに設定しなければなりません。
Length is according to ISAKMP [RFC2408, Section 3.1]
ISAKMPによると、長さがあります。[RFC2408、セクション3.1]
4.6. Deletion of SAs
4.6. SAsの削除
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がSAsを削除するために受信機に合図したがっているかもしれないという回があります、例えば、放送の終わりに。 キーの削除は、GDOI GROUPKEY-PUSHメッセージの一部としてISAKMP Deleteペイロード[RFC2408、セクション3.15]を送ることによって、実行されるかもしれません。
One or more Delete payloads MAY be placed following the SEQ payload in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to group members, the SA and KD payloads MUST be omitted from the message.
1個以上のDeleteペイロードがGROUPKEY-PUSHメッセージでSEQペイロードに続くのが置かれるかもしれません。 GCKSにメンバーを分類するために発信するSAsがこれ以上ないなら、メッセージからSAとKDペイロードを省略しなければなりません。
Baugher, et. al. Standards Track [Page 14] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[14ページ]。
The following fields of the Delete Payload are further defined as follows:
Delete有効搭載量の以下の分野は以下の通りさらに定義されます:
o The Domain of Interpretation field contains the GDOI DOI.
o Interpretation分野のDomainは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 プロトコルイド分野はこのドキュメントのセクション5.4で定義されたTEKプロトコルイド値を含んでいます。 KEK SAを削除するために、プロトコルイドとしてゼロの値を使用しなければなりません。 Deleteペイロードで1つのプロトコルイド価値しか定義できないことに注意してください。 TEK SAとKEK SAを削除しなければならないなら、異なったDeleteペイロードでそれらを送らなければなりません。
4.7. GCKS Operations
4.7. GCKS操作
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かその代表がいくつかの理由(例えば会員資格が変えたか、またはキーが吐き出すことになっているグループ)の1つによってRekeyメッセージを開始するかもしれません。
To begin the rekey datagram the GCKS builds an ISAKMP HDR with the correct cookie pair, and a SEQ payload that includes a sequence number which is one greater than the previous rekey datagram.
rekeyデータグラムを始めるために、GCKSは正しいクッキー組、および前のrekeyデータグラムよりすばらしい1つである一連番号を含んでいるSEQペイロードでISAKMP HDRを造ります。
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ペイロードは加えられます。 これは構造が同じです、そして、SAペイロードへの意味はGROUPKEY-PULL交換を送りました。 KEK(静的なKEKの場合における)かグループ会員資格(LKHの場合における)における変化があれば、SA_KEK属性はSAに加えられます。 1新しいTEKsがあれば、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ペイロードは加えられます。 これは構造が同じです、そして、KDペイロードへの意味はGROUPKEY-PULL交換を送りました。 SA_KEK属性がSAペイロードに含まれていたなら、対応するKEKキー(または、KEK配列)は含まれています。 SAペイロードにそれぞれのSA_TEK属性を含んでいて、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.
終わりから二番目のステップでは、創始者はストリング"rekey"を論じ尽くします、続いて、既に形成されたかぎ管理メッセージを論じ尽くします。 ハッシュは、署名されて、SIGペイロードに置かれて、データグラムに加えられます。
Lastly, the payloads following the HDR are encrypted using the current KEK encryption key. The datagram can now be sent.
最後に、HDRに続くペイロードは、現在のKEK暗号化キーを使用することで暗号化されています。 現在、データグラムを送ることができます。
Baugher, et. al. Standards Track [Page 15] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[15ページ]。
4.8. Group Member Operations
4.8. グループメンバー操作
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データグラムを受け取るグループのメンバーはISAKMP HDRでクッキー組を既存のSAに合わせます。 メッセージは解読されます、そして、データグラムのフォームは有効にされます。 これは明白な不適格なメッセージ(サービス妨害攻撃の一部としてグループで送られるかもしれない)を取り外します。
The signature of the decrypted message is then validated, possibly using the CERT payload if it is included.
そして、それが含まれているならことによるとCERTペイロードを使用して、解読されたメッセージの署名は有効にされます。
The sequence number in the SEQ payload is validated to ensure that it is greater than the previously received sequence number, and that it fits within a window of acceptable values.
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とKDペイロードは処理されます(システムに追加される新しいGDOI Rekey SA(SAペイロードがSA_KEK属性を含んでいたなら)、そして/または、新しいIPsec SAsをもたらします)。
5. Payloads and Defined Values
5. 有効搭載量と定義された値
This document specifies use of several ISAKMP payloads, which are defined in accordance with RFC2408. The following payloads are extended or further specified.
このドキュメントは数個のISAKMPペイロードの使用を指定します。(RFC2408に従って、ペイロードは定義されます)。 以下のペイロードは、広げられるか、またはさらに指定されます。
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10
次の有効搭載量タイプ価値----------------- ----- セキュリティ協会(SA)1識別(ID)5一回だけ(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
次の有効搭載量タイプ価値----------------- ----- 所有物(飛び出す)19のSA KEK有効搭載量(SAK)15SA TEK有効搭載量(土曜日)16の主要なダウンロード(KD)17一連番号(SEQ)9度
Baugher, et. al. Standards Track [Page 16] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[16ページ]。
5.1. Identification Payload
5.1. 識別有効搭載量
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.
Identification有効搭載量は、グループのために後でSecurity Associationsに関連しているグループのアイデンティティを特定するのに使用されます。 アイデンティティが特定のIPマルチキャストに写像するかもしれないグループは、より一般的な識別子を分類するか、または指定するかもしれません、1セットの関連するマルチキャストの流れを表すものなどのように。
The Identification Payload is defined as follows:
Identification有効搭載量は以下の通り定義されます:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! RESERVE2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Identification Payload fields are defined as follows:
Identification有効搭載量分野は以下の通り定義されます:
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.
o 有効搭載量Length(2つの八重奏)--ジェネリックヘッダーを含む識別情報の八重奏における長さ。
o Identification Type (1 octet) -- Value describing the identity
information found in the Identification Data field.
o 識別Type(1つの八重奏)--アイデンティティ情報がIdentification Data分野で見つけた説明を評価してください。
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 識別Data(可変長)--Identification Typeによって示されるように、評価します。
Baugher, et. al. Standards Track [Page 17] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[17ページ]。
5.1.1. Identification Type Values
5.1.1. 識別タイプ値
The following table lists the assigned values for the Identification Type field found in the Identification Payload.
以下のテーブルはIdentification有効搭載量で見つけられたIdentification Type分野に割り当てられた値を記載します。
ID Type Value
------- -----
RESERVED 0 - 10
ID_KEY_ID 11
RESERVED 12 - 127
Private Use 128 - 255
IDタイプ価値------- ----- 予約された0--10ID_主要な_12--ID11予約された127私用128--255
5.1.1.1. ID_KEY_ID
5.1.1.1. IDの_の主要な_ID
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)八重奏グループ識別子を指定します。
5.2. Security Association Payload
5.2. セキュリティ協会有効搭載量
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.
Security AssociationペイロードはRFC2408で定義されます。 GDOIに関しては、それは、両方のRe-キーとData-セキュリティSAsのためにセキュリティー属性について断言するのに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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! DOI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SA Attribute Next Payload ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The Security Association Payload fields are defined as follows:
Security Association有効搭載量分野は以下の通り定義されます:
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-PULLかGROUPKEY-PUSHメッセージのために、上で定義されるように、特定します。 有効搭載量タイプ、次のペイロードはSAK有効搭載量であるはずがありませんか土曜日に、次の非セキュリティAssociationだけがペイロードをタイプします。
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 有効搭載量Length(2つの八重奏)--ジェネリックヘッダー、すべてのTEK、およびKEKを含む現在のペイロードの八重奏の長さはペイロードですか?
Baugher, et. al. Standards Track [Page 18] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[18ページ]。
o DOI (4 octets) -- Is the GDOI, which is value 2.
o DOI(4つの八重奏)--GDOI(値である)は2歳ですか?
o Situation (4 octets) -- Must be zero.
o 状況(4つの八重奏)--ゼロでなければなりません。
o SA Attribute Next Payload (1 octet) -- Must be either a SAK
Payload or a SAT Payload. See section 5.2.1 for a description
of which circumstances are required for each payload type to be
present.
o SA Attribute Next有効搭載量(1つの八重奏)--SAK有効搭載量か土曜日の有効搭載量のどちらかでなければなりません。 どの事情が各ペイロードに必要であるかに関する記述のためのセクション5.2.1が存在しているようにタイプされるのを見てください。
o RESERVED (2 octets) -- Must be zero.
o RESERVED(2つの八重奏)--ゼロでなければなりません。
5.2.1. Payloads following the SA payload
5.2.1. SAペイロードに続く有効搭載量
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、そして/または、TEKsのために特定のセキュリティ協会属性を定義する有効搭載量はSAペイロードに続かなければなりません。 それぞれのペイロードのいくつがグループ方針に依存していますか? ゼロか1SAK有効搭載量と、ゼロか、より多くの土曜日の有効搭載量があるかもしれません、1SAKか土曜日のペイロードのどちらかが存在していなければならないところで。
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アップデートがRegistration SAを使用することで実行されるでしょう、したがって、例えば、グループ方針がRe主要なSAの使用を必要としないなら、GCKSはSA KEK属性をグループのメンバーに送る必要はないでしょう。 あるいはまた、グループ方針は、Re主要なSAを使用しますが、単にRegistration SAの一部としてグループのメンバーにKEKをダウンロードするのを選ぶかもしれません。 したがって、KEK方針(SA KEK属性における)はRe主要な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.
複数の土曜日の指定は、セッション(例えば、ビデオ、オーディオ、およびテキスト)にもかかわらず、それぞれ個別的安全保障協会方針に関連しているように複数のセッションが同じグループと複数のストリームの一部であることを許容します。
5.3. SA KEK payload
5.3. SA KEKペイロード
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)ペイロードはGROUPKEY-PULL操作に特定のグループとパラメタのためのKEKメソッドのためのセキュリティー属性を含んでいます。 ソースと目的地のアイデンティティはGROUPKEY-PULLデータグラムに使用されるアイデンティティについて説明します。
Baugher, et. al. Standards Track [Page 19] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[19ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Protocol ! SRC ID Type ! SRC ID Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !SRC ID Data Len! SRC識別情報~++++++++++++++++++++++++++++++++、-、DST IDタイプ!DST IDポート!DST ID Dataレン! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! ~ SPI ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! POP Algorithm ! POP Key Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ KEK Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAK Payload fields are defined as follows:
SAK有効搭載量分野は以下の通り定義されます:
o Next Payload (1 octet) -- Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid
next payload types for this message are a SAT Payload or zero
to indicate there is no SA TEK payload.
o 次の有効搭載量(1つの八重奏)--次のペイロードに、GROUPKEY-PULLかGROUPKEY-PUSHメッセージのために、特定します。 このメッセージのための次の唯一の有効なペイロードタイプが土曜日の有効搭載量であるかそこで示すゼロはSA TEKペイロードではありません。
o RESERVED (1 octet) -- Must be zero.
o RESERVED(1つの八重奏)--ゼロでなければなりません。
o Payload Length (2 octets) -- Length of this payload, including
the KEK attributes.
o 有効搭載量Length(2つの八重奏)--KEK属性を含むこのペイロードの長さ。
o Protocol (1 octet) -- Value describing an IP protocol ID (e.g.,
UDP/TCP) for the rekey datagram.
o (1つの八重奏)について議定書の中で述べてください--rekeyデータグラムのために、IPプロトコルID(例えば、UDP/TCP)について説明する値。
o SRC ID Type (1 octet) -- Value describing the identity
information found in the SRC Identification Data field.
Defined values are specified by the IPSEC Identification Type
section in the IANA isakmpd-registry [ISAKMP-REG].
o SRC ID Type(1つの八重奏)--アイデンティティ情報がSRC Identification Data分野で見つけた説明を評価してください。 定義された値はIANA isakmpd-登録[ISAKMP-REG]のIPSEC Identification Type部によって指定されます。
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 Port(2つの八重奏)--ソースアイダホ州に関連しているポートを指定する値 ゼロの値は、SRC ID Port分野が無視されるべきであることを意味します。
o SRC ID Data Len (1 octet) -- Value specifying the length of the
SRC Identification Data field.
o SRC ID Dataレン(1つの八重奏)--SRC Identification Data分野の長さを指定する値。
Baugher, et. al. Standards Track [Page 20] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[20ページ]。
o SRC Identification Data (variable length) -- Value, as
indicated by the SRC ID Type.
o SRC Identification Data(可変長)--SRC ID Typeによって示されるように、評価します。
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 Type(1つの八重奏)--アイデンティティ情報がDST Identification Data分野で見つけた説明を評価してください。 定義された値はIANA isakmpd-登録[ISAKMP-REG]のIPSEC Identification Type部によって指定されます。
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 Port(2つの八重奏)--ソースアイダホ州に関連しているポートを指定する値
o DST ID Data Len (1 octet) -- Value specifying the length of the
DST Identification Data field.
o DST ID Data Len (1 octet) -- Value specifying the length of the DST Identification Data field.
o DST Identification Data (variable length) -- Value, as
indicated by the DST ID Type.
o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type.
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 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 POP Algorithm (2 octets) -- The POP payload algorithm. Defined
values are specified in the following table. If no POP
algorithm is defined by the KEK policy this field must be zero.
o 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.
Algorithm Type Value
-------------- -----
RESERVED 0
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
Algorithm Type Value -------------- ----- RESERVED 0 POP_ALG_RSA 1 POP_ALG_DSS 2 POP_ALG_ECDSS 3 RESERVED 4-127 Private Use 128-255
o POP Key Length (2 octets) -- Length of the POP payload key. If
no POP algorithm is defined in the KEK policy, this field must
be zero.
o 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.
Baugher, et. al. Standards Track [Page 21] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 21] RFC 3547 GDOI Domain of Interpretation July 2003
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 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.
5.3.1. KEK Attributes
5.3.1. KEK Attributes
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).
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).
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
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.
The following attributes may only be included in a GROUPKEY-PULL message: KEK_MANAGEMENT_ALGORITHM, KE_OAKLEY_GROUP.
5.3.2. KEK_MANAGEMENT_ALGORITHM
5.3.2. KEK_MANAGEMENT_ALGORITHM
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.
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 Type Value
------------------- -----
RESERVED 0
LKH 1
RESERVED 2-127
Private Use 128-255
KEK Management Type Value ------------------- ----- RESERVED 0 LKH 1 RESERVED 2-127 Private Use 128-255
Baugher, et. al. Standards Track [Page 22] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 22] RFC 3547 GDOI Domain of Interpretation July 2003
5.3.3. KEK_ALGORITHM
5.3.3. KEK_ALGORITHM
The KEK_ALGORITHM class specifies the encryption algorithm using with the KEK. Defined values are specified in the following table.
The KEK_ALGORITHM class specifies the encryption algorithm using with the KEK. Defined values are specified in the following table.
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_AES 3
RESERVED 4-127
Private Use 128-255
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.
A GDOI implementation MUST support the KEK_ALG_3DES algorithm attribute.
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.
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.
5.3.3.1. KEK_ALG_DES
5.3.3.1. KEK_ALG_DES
This algorithm specifies DES using the Cipher Block Chaining (CBC) mode as described in [FIPS81].
This algorithm specifies DES using the Cipher Block Chaining (CBC) mode as described in [FIPS81].
5.3.3.2. KEK_ALG_3DES
5.3.3.2. KEK_ALG_3DES
This algorithm specifies 3DES using three independent keys as described in "Keying Option 1" in [FIPS46-3].
This algorithm specifies 3DES using three independent keys as described in "Keying Option 1" in [FIPS46-3].
5.3.3.3. KEK_ALG_AES
5.3.3.3. KEK_ALG_AES
This algorithm specifies AES as described in [FIPS197]. The mode of operation for AES is Cipher Block Chaining (CBC) as recommended in [AES-MODES].
This algorithm specifies AES as described in [FIPS197]. The mode of operation for AES is Cipher Block Chaining (CBC) as recommended in [AES-MODES].
5.3.4. KEK_KEY_LENGTH
5.3.4. KEK_KEY_LENGTH
The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in bits).
The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in bits).
Baugher, et. al. Standards Track [Page 23] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 23] RFC 3547 GDOI Domain of Interpretation July 2003
5.3.5. KEK_KEY_LIFETIME
5.3.5. KEK_KEY_LIFETIME
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.
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.
5.3.6. SIG_HASH_ALGORITHM
5.3.6. SIG_HASH_ALGORITHM
SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The following tables define the algorithms for SIG_HASH_ALGORITHM.
SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The following tables define the algorithms for SIG_HASH_ALGORITHM.
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
RESERVED 3-127
Private Use 128-255
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_HASH_ALGORITHM is not required if the SIG_ALGORITHM is SIG_ALG_DSS or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1.
5.3.7. SIG_ALGORITHM
5.3.7. SIG_ALGORITHM
The SIG_ALGORITHM class specifies the SIG payload signature algorithm. Defined values are specified in the following table.
The SIG_ALGORITHM class specifies the SIG payload signature algorithm. Defined values are specified in the following table.
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
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.
A GDOI implementation MUST support the following algorithm attribute: SIG_ALG_RSA.
5.3.7.1. SIG_ALG_RSA
5.3.7.1. SIG_ALG_RSA
This algorithm specifies the RSA digital signature algorithm as described in [RSA].
This algorithm specifies the RSA digital signature algorithm as described in [RSA].
Baugher, et. al. Standards Track [Page 24] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 24] RFC 3547 GDOI Domain of Interpretation July 2003
5.3.7.2. SIG_ALG_DSS
5.3.7.2. SIG_ALG_DSS
This algorithm specifies the DSS digital signature algorithm as described in [FIPS186-2].
This algorithm specifies the DSS digital signature algorithm as described in [FIPS186-2].
5.3.7.3. SIG_ALG_ECDSS
5.3.7.3. SIG_ALG_ECDSS
This algorithm specifies the Elliptic Curve digital signature algorithm as described in [FIPS186-2].
This algorithm specifies the Elliptic Curve digital signature algorithm as described in [FIPS186-2].
5.3.8. SIG_KEY_LENGTH
5.3.8. SIG_KEY_LENGTH
The SIG_KEY_LENGTH class specifies the length of the SIG payload key.
The SIG_KEY_LENGTH class specifies the length of the SIG payload key.
5.3.9. KE_OAKLEY_GROUP
5.3.9. KE_OAKLEY_GROUP
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].
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].
5.4. SA TEK Payload
5.4. SA TEK Payload
The SA TEK (SAT) payload contains security attributes for a single TEK associated with a group.
The SA TEK (SAT) payload contains security attributes for a single TEK associated with a group.
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 ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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:
The SAT Payload fields are defined as follows:
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 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 RESERVED (1 octet) -- Must be zero.
o RESERVED (1 octet) -- Must be zero.
o Payload Length (2 octets) -- Length of this payload, including
the TEK Protocol-Specific Payload.
o Payload Length (2 octets) -- Length of this payload, including the TEK Protocol-Specific Payload.
Baugher, et. al. Standards Track [Page 25] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 25] RFC 3547 GDOI Domain of Interpretation July 2003
o Protocol-ID (1 octet) -- Value specifying the Security
Protocol. The following table defines values for the Security
Protocol
o Protocol-ID (1 octet) -- Value specifying the Security Protocol. The following table defines values for the Security Protocol
Protocol ID Value
----------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP 1
RESERVED 2-127
Private Use 128-255
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 Protocol-Specific Payload (variable) -- Payload which describes the attributes specific for the Protocol-ID.
5.4.1. PROTO_IPSEC_ESP
5.4.1. PROTO_IPSEC_ESP
The TEK Protocol-Specific payload for ESP is as follows:
The TEK Protocol-Specific payload for ESP is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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:
The SAT Payload fields are defined as follows:
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 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 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 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 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 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.
Baugher, et. al. Standards Track [Page 26] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 26] RFC 3547 GDOI Domain of Interpretation July 2003
o SRC ID Data Len (1 octet) -- Value specifying the length of the
SRC Identification Data field.
o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC Identification Data field.
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 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 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 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 Prot (1 octet) -- Value describing an IP protocol ID
(e.g., UDP/TCP). A value of zero means that the DST Id Prot
field should be ignored.
o DST ID Prot (1 octet) -- 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 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 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 Data Len (1 octet) -- Value specifying the length of the
DST Identification Data field.
o DST ID Data Len (1 octet) -- Value specifying the length of the DST Identification Data field.
o DST Identification Data (variable length) -- Value, as
indicated by the DST ID Type.
o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type.
o Transform ID (1 octet) -- Value specifying which ESP transform
is to be used. The list of valid values is defined in the
IPSEC ESP Transform Identifiers section of the IANA
isakmpd-registry [ISAKMP-REG].
o Transform ID (1 octet) -- Value specifying which ESP transform is to be used. The list of valid values is defined in the IPSEC ESP Transform Identifiers section of the IANA isakmpd-registry [ISAKMP-REG].
o SPI (4 octets) -- Security Parameter Index for ESP.
o SPI (4 octets) -- Security Parameter Index for 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 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.
Baugher, et. al. Standards Track [Page 27] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 27] RFC 3547 GDOI Domain of Interpretation July 2003
5.4.2. Other Security Protocols
5.4.2. Other Security Protocols
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.
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.
The following information needs to be provided for a Security Protocol to the GDOI.
The following information needs to be provided for a Security Protocol to the GDOI.
o The Protocol-ID for the particular Security Protocol
o The SPI Size
o The method of SPI generation
o The transforms, attributes and keys needed by the Security
Protocol
o 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
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.
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.
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.
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.
5.5. Key Download Payload
5.5. Key Download Payload
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.
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.
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.
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.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Number of Key Packets ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Key Packets ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Baugher, et. al. Standards Track [Page 28] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 28] RFC 3547 GDOI Domain of Interpretation July 2003
The Key Download Payload fields are defined as follows:
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 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 RESERVED (1 octet) -- Unused, set to zero.
o RESERVED (1 octet) -- Unused, set to zero.
o Payload Length (2 octets) -- Length in octets of the current
payload, including the generic payload header.
o Payload Length (2 octets) -- Length in octets of the current payload, including the generic payload header.
o Number of Key Packets (2 octets) -- Contains the total number
of both TEK and Rekey arrays being passed in this data block.
o Number of Key Packets (2 octets) -- Contains the total number of both TEK and Rekey arrays being passed in this data block.
o Key Packets
Several types of key packets are defined. Each Key Packet has
the following format.
o Key Packets Several types of key packets are defined. Each Key Packet has the following format.
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 Type ! RESERVED ! KD Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI Size ! SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Key Packet Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
o Key Download (KD) Type (1 octet) -- Identifier for the Key Data
field of this Key Packet.
o Key Download (KD) Type (1 octet) -- Identifier for the Key Data field of this Key Packet.
Key Download Type Value
----------------- -----
RESERVED 0
TEK 1
KEK 2
LKH 3
RESERVED 4-127
Private Use 128-255
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" is a single key whereas LKH is an array of key-encrypting keys.
o RESERVED (1 octet) -- Unused, set to zero.
o RESERVED (1 octet) -- Unused, set to zero.
o Key Download Length (2 octets) -- Length in octets of the Key
Packet data, including the Key Packet header.
o Key Download Length (2 octets) -- Length in octets of the Key Packet data, including the Key Packet header.
Baugher, et. al. Standards Track [Page 29] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 29] RFC 3547 GDOI Domain of Interpretation July 2003
o SPI Size (1 octet) -- Value specifying the length in octets of
the SPI as defined by the Protocol-Id.
o SPI Size (1 octet) -- Value specifying the length in octets of the SPI as defined by the Protocol-Id.
o SPI (variable length) -- Security Parameter Index which matches
a SPI previously sent in an SAK or SAT Payload.
o SPI (variable length) -- Security Parameter Index which matches a SPI previously sent in an SAK or SAT Payload.
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 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.
5.5.1. TEK Download Type
5.5.1. TEK Download Type
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).
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 Class Value Type
--------- ----- ----
RESERVED 0
TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 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.
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.
5.5.1.1. TEK_ALGORITHM_KEY
5.5.1.1. TEK_ALGORITHM_KEY
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.
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.
In the case that the algorithm requires multiple keys (e.g., 3DES), all keys will be included in one attribute.
In the case that the algorithm requires multiple keys (e.g., 3DES), all keys will be included in one attribute.
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 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).
Baugher, et. al. Standards Track [Page 30] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 30] RFC 3547 GDOI Domain of Interpretation July 2003
5.5.1.2. TEK_INTEGRITY_KEY
5.5.1.2. TEK_INTEGRITY_KEY
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.
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.
5.5.1.3. TEK_SOURCE_AUTH_KEY
5.5.1.3. TEK_SOURCE_AUTH_KEY
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.
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.
5.5.2. KEK Download Type
5.5.2. KEK Download Type
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).
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 Class Value Type
--------- ----- ----
RESERVED 0
KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 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.
If the KEK key packet is included, there MUST be only one present in the KD payload.
5.5.2.1. KEK_ALGORITHM_KEY
5.5.2.1. KEK_ALGORITHM_KEY
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.
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.
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.
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.
Baugher, et. al. Standards Track [Page 31] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 31] RFC 3547 GDOI Domain of Interpretation July 2003
5.5.2.2. SIG_ALGORITHM_KEY
5.5.2.2. SIG_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.
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.
5.5.3. LKH Download Type
5.5.3. LKH Download Type
The LKH key packet is comprised of attributes representing different leaves in the LKH key tree.
The LKH key packet is comprised of attributes representing different leaves in the LKH key tree.
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).
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).
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
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.
If an LKH key packet is included in the KD payload, there must be only one present.
5.5.3.1. LKH_DOWNLOAD_ARRAY
5.5.3.1. LKH_DOWNLOAD_ARRAY
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.
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.
This attribute consists of a header block, followed by one or more LKH keys.
This attribute consists of a header block, followed by one or more LKH keys.
Baugher, et. al. Standards Track [Page 32] RFC 3547 GDOI Domain of Interpretation July 2003
Baugher, et. al. Standards Track [Page 32] RFC 3547 GDOI Domain of Interpretation July 2003
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 Version ! # of LKH Keys ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! LKH Keys ! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The KEK_LKH attribute fields are defined as follows:
The KEK_LKH attribute fields are defined as follows:
o LKH version (1 octet) -- Contains the version of the LKH
protocol which the data is formatted in. Must be one.
o LKHバージョン(1つの八重奏)--データがフォーマットされるLKHプロトコルのバージョンを含んでいます。 1つはそうであるに違いありませんか?
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 Keyは以下の通り定義されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 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 1LKH ID!が合わせる+++++++++++++++++++++++++++++++++タイプ!は+++++++++++++++++++++++++++++++++~主要な作成日付を予約しました!;
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によって使用された2進の木構造のこのキーの位置です。
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 主要なType(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.
o 主要なCreation Date(4つの八重奏)--これはこの重要なデータが元々生成された時に関する時間的価値です。 ゼロの時間的価値は、このキーが有効でない時が全くないのを示します。
Baugher, et. al. Standards Track [Page 33] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[33ページ]。
o Key Expiration Date (4 octets) -- This is the time value of
when this key is no longer valid for use. A time value of zero
indicates that this key does not have an expiration time.
o 主要なExpiration Date(4つの八重奏)--これは使用には、このキーがもう有効でない時に関する時間的価値です。 ゼロの時間的価値は、このキーには満了時間がないのを示します。
o Key Handle (4 octets) -- This is the randomly generated value
to uniquely identify a key within an LKH ID.
o 主要なHandle(4つの八重奏)--これはLKH IDの中で唯一キーを特定する手当たりしだいに発生している値です。
o Key Data (variable length) -- This is the actual encryption key
data, which is dependent on the Key Type algorithm for its
format. If the mode of operation for the algorithm requires an
Initialization Vector (IV), an explicit IV MUST be included in
the Key Data field before the actual key.
o 主要なData(可変長)--これは実際の暗号化重要なデータです。(形式において、その重要なデータはKey Typeアルゴリズムに依存しています)。 アルゴリズムのための運転モードが初期設定Vector(IV)を必要とするなら、実際のキーの前のKey Data分野に明白な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.
Key Creation DateとKey満了Datesはゼロであるかもしれません。 これがグループの中の時間同期化が可能でない場合で必要です。
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 Key構造はグループのメンバーのためのLeaf識別子とキーを含んでいます。 LKH Key構造の残りは葉から整然としている主要な木の経路に沿ってキーを保管しています、グループKEKに終わって。
5.5.3.2. LKH_UPDATE_ARRAY
5.5.3.2. LKH_アップデート_配列
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ペイロードでおそらく全体のrekeyに含められるべき大部分が分類されるということです。 セクション5.5.3で.1を定義するとき、この属性は1個以上のLKHキーが支えたヘッダーブロックから成ります。
There may be any number of UPDATE_ARRAY attributes included in a KD payload.
_KDペイロードにARRAY属性を含んでいる場合、いろいろなUPDATEがあるかもしれません。
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 Version ! # of LKH Keys ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! LKH ID ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key Handle ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! LKH Keys ! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o LKH version (1 octet) -- Contains the version of the LKH
protocol which the data is formatted in. Must be one.
o LKHバージョン(1つの八重奏)--データがフォーマットされるLKHプロトコルのバージョンを含んでいます。 1つはそうであるに違いありませんか?
Baugher, et. al. Standards Track [Page 34] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[34ページ]。
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 Keyを暗号化するのに使用されるキーに関連しているノード識別子です。
o RESERVED2 (2 octets) -- Unused, set to zero.
o RESERVED2(2つの八重奏)--未使用であり、ゼロにセットしてください。
o Key Handle (4 octets) -- This is the value to uniquely identify
the key within the LKH ID which was used to encrypt the first
LKH key.
o 主要なHandle(4つの八重奏)--これは最初のLKHキーを暗号化するのに使用されたLKH IDの中で唯一キーを特定する値です。
The LKH Keys are as defined in Section 5.5.3.1. The LKH Key structures contain keys along the path of the key tree in order from the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the group KEK. The Key Data field of each LKH Key is encrypted with the LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first LKH Key is encrypted under the key defined by the LKH ID and Key Handle found in the LKH_UPDATE_ARRAY header.
LKHキーズはセクション5.5.3で.1に定義されるようにあります。 LKH Key構造はLKH_UPDATE_ARRAYヘッダーで見つけられたLKH IDから整然としている主要な木の経路に沿ってキーを保管しています、グループKEKに終わって。 LKHキーがLKH_UPDATE_ARRAY属性でそれに先行している状態で、それぞれのLKH KeyのKey Data分野は暗号化されます。 最初のLKH KeyはLKH_UPDATE_ARRAYヘッダーで見つけられたLKH IDとKey Handleによって定義されたキーの下で暗号化されます。
5.5.3.3. SIG_ALGORITHM_KEY
5.5.3.3. SIG_アルゴリズム_キー
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のための公開鍵がKey Packet Attributeに含まれていると宣言します。(どんな公開鍵認証基盤も利用可能でないときに、Key Packet Attributeは役に立つかもしれません)。 このキーを使用する署名アルゴリズムはSAKペイロードで指定されました。
5.6. Sequence Number Payload
5.6. 一連番号有効搭載量
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].
Sequence Number有効搭載量(SEQ)はGROUPKEY-PUSHメッセージのための反反復操作による保護を提供します。 使用はIPsec超能力プロトコル[RFC2406]で定義された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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
次..有効搭載量..予約..ペイロード長..一連番号
The Sequence Number Payload fields are defined as follows:
Sequence Number有効搭載量分野は以下の通り定義されます:
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つの八重奏)--メッセージの次のペイロードのペイロードタイプへの識別子。 現在のペイロードがメッセージの最終であるなら、この分野はゼロになるでしょう。
Baugher, et. al. Standards Track [Page 35] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[35ページ]。
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 有効搭載量Length(2つの八重奏)--ジェネリックペイロードヘッダーを含む現在のペイロードの八重奏における長さ。
o Sequence Number (4 octets) -- This field contains a
monotonically increasing counter value for the group. It is
initialized to zero by the GCKS, and incremented in each
subsequently-transmitted message. Thus the first packet sent
for a given Rekey SA will have a Sequence Number of 1. The
GDOI implementation keeps a sequence counter as an attribute
for the Rekey SA and increments the counter upon receipt of a
GROUPKEY-PUSH message. The current value of the sequence
number must be transmitted to group members as a part of the
Registration SA SA payload. A group member must keep a sliding
receive window. The window must be treated as in the ESP
protocol [RFC2406] Section 3.4.3.
o 系列Number(4つの八重奏)--この分野はグループのための単調に増加する対価を含んでいます。 それは、GCKSによってゼロに初期化されて、それぞれの次に伝えられたメッセージで増加されます。 したがって、与えられたRekey SAのために送られた最初のパケットは1のSequence Numberを持つでしょう。 GDOI実装は、Rekey SAのための属性として系列カウンタを保って、GROUPKEY-PUSHメッセージを受け取り次第カウンタを増加します。 Registration SA SAペイロードの一部としてメンバーを分類するために一連番号の現行価値を伝えなければなりません。 Aグループメンバー必須生活費aの滑りは窓を受けます。 超能力プロトコル[RFC2406]部3.4の.3のように窓を扱わなければなりません。
5.7. Proof of Possession
5.7. 所有物の証拠
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.
Possession有効搭載量のProofはGDOI交換の間、グループ会員資格承認の一部として使用されます。 Possession有効搭載量のProofはISAKMP SIGペイロードと同じです。 しかしながら、用法は完全に異なっています。
The GCKS, GCKS delegate or member signs a hash of the following
values:
POP_HASH = hash("pop" | Ni | Nr)
Where hash() is the hash function used with the signature.
以下のハッシュが評価するGCKS、GCKS代表またはメンバーサイン: POP_HASHはハッシュ()が署名と共に使用されるハッシュ関数であるハッシュ(「ポップス」|Ni|Nr)と等しいです。
The "pop" prefix ensures that the signature of the POP payload cannot be used for any other purpose in the GDOI protocol.
「ポップス」接頭語は、GDOIプロトコルのいかなる他の目的にもPOPペイロードの署名を使用できないのを確実にします。
5.8. Nonce
5.8. 一回だけ
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.
Nonceペイロード(すなわち、Ni_bとHASHsに含まれていたNr_b)のデータ部は8〜128バイト値であるに違いありません。
6. Security Considerations
6. セキュリティ問題
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
GDOIは送付者と受信機のグループのためのセキュリティ協会(SA)管理プロトコルです。 データ機密保護と異なって、議定書を作ってください、そして、SA経営者側は、コミュニケーション終点でしっかりとキーを証明するために主要な設立プロトコルを含んでいます。 このプロトコルはGDOIメンバーかGroup Controller/主要なServer(GCKS)の実体認証を実行します、そして、かぎ管理メッセージの秘密性を提供します、そして、それはそれらのメッセージのソース認証を提供します。 また、このプロトコルはディフェンスに最もよく知られている習慣を使用します。
Baugher, et. al. Standards Track [Page 36] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[36ページ]。
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.
非機密保護しているネットワーク[通り、RFC2522、SKEME]に対する中央の人、接続ハイジャック、再生、反射、およびサービスの否定(DOS)攻撃。 GDOIはネットワークが安全でないと仮定して、攻撃者の完全なコントロールの下にあるかもしれません。
GDOI assumes that the host computer is secure even though the network is insecure. GDOI ultimately establishes keys among members of a group, which MUST be trusted to use those keys in an authorized manner according to group policy. The security of GDOI, therefore, is as good as the degree to which group members can be trusted to protect authenticators, encryption keys, decryption keys, and message authentication keys.
GDOIは、ネットワークが不安定ですが、ホストコンピュータが安全であると仮定します。 GDOIは結局、グループのメンバーの中にキーを設立します。グループ方針によると、認可された方法でそれらのキーを使用するとそのメンバーを信じなければなりません。 したがって、GDOIのセキュリティは固有識別文字、暗号化キー、復号化キー、および通報認証キーを保護するとグループのメンバーを信じることができる度合いと同じくらい良いです。
There are three phases of GDOI as described in this document: an ISAKMP Phase 1 protocol, a new exchange called GROUPKEY-PULL which is protected by the ISAKMP Phase 1 protocol, and a new message called GROUPKEY-PUSH. Each phase is considered separately below.
GDOIの三相が本書では説明されるようにあります: ISAKMP Phase1プロトコル、新しい交換はISAKMP Phase1プロトコル、およびGROUPKEY-PUSHと呼ばれる新しいメッセージで保護されるGROUPKEY-PULLを呼びました。 各フェーズは別々に以下で考えられます。
6.1. ISAKMP Phase 1
6.1. ISAKMPフェーズ1
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-PULL交換を保護するために[RFC2409]で定義されたPhase1交換を使用します。 したがって、GDOIにおいて、それらの交換([RFC2409]に述べられるように)のすべてのセキュリティの特性と問題は関連しています。
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は先祖プロトコル[FS00]の問題を引き継ぐかもしれません、アイデンティティ暴露、単方向の認証の欠如、またはstatefulクッキー[PK01]などのように。 しかしながら、ちょうどそれらのプロトコルに表現された何年もの経験と仕事の利益を得るようにGDOIは先祖プロトコルへの改良から利益を得ることができました。 しかしながら、今後のIKE改良の恩恵を獲得するのに、GDOIは、将来の標準化過程RFCで改訂される必要があるでしょう。(RFCはこの仕様の範囲にあります)。
6.1.1. Authentication
6.1.1. 認証
Authentication is provided via the mechanisms defined in [RFC2409], namely Pre-Shared Keys or Public Key encryption.
[RFC2409]で定義されて、すなわち、メカニズムを通してPreによって共有されたキーズかPublic Key暗号化を認証に提供します。
6.1.2. Confidentiality
6.1.2. 秘密性
Confidentiality is achieved in Phase 1 through a Diffie-Hellman exchange that provides keying material, and through negotiation of encryption transforms.
秘密性はPhase1で材料を合わせながら供給されるディフィー-ヘルマンの交換を通して暗号化変換の交渉を通して達成されます。
Baugher, et. al. Standards Track [Page 37] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[37ページ]。
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.
Phase1プロトコルはGROUPKEY-PULLプロトコルで送られた暗号化と保全キーを保護するでしょう。 Phaseに使用される暗号化では1SHOULDがそれを超えています。強さ、キーでは、GROUPKEY-PULLプロトコルを送ってください。
6.1.3. Man-in-the-Middle Attack Protection
6.1.3. 介入者攻撃保護
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.
中央のうまくいっている人間か接続をハイジャックする攻撃が主要な設立の間、交信実体の1つ以上の実体認証をくじきます。 GDOIは、介入者攻撃を破るためにPhase1認証に依存します。
6.1.4. Replay/Reflection Attack Protection
6.1.4. 再生/反射攻撃保護
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は、ハッシュベースのメッセージ確認コードと組み合わせて前のかぎ管理メッセージの再生か反映から守るためにPhaseの1の一回だけのメカニズムを当てにします。
6.1.5. Denial of Service Protection
6.1.5. サービス妨害保護
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は、暗号のハッシュ処理の前に偽りのメッセージを特定するのにPhase1クッキーメカニズムを使用します。 GDOI実体が良いクッキー(首尾よく、洗練された攻撃者は模造できる)がないかどうかチェックしなければならないので、これは「弱い」形式のサービス保護の否定です。 Phaseの1個のクッキーのメカニズムは、statefulで、クッキーのためのメモリリソースを遂行しますが、状態がないクッキーはサービス不能攻撃に対するより良いディフェンスです。
6.2. GROUPKEY-PULL Exchange
6.2. GROUPKEY-牽引力の交換
The GROUPKEY-PULL exchange allows a group member to request SAs and keys from a GCKS. It runs as a "phase 2" protocol under protection of the Phase 1 security association.
GROUPKEY-PULL交換で、グループのメンバーはGCKSからSAsとキーを要求できます。 それは「Phase1セキュリティ協会の保護でのフェーズの2インチのプロトコル」として稼働しています。
6.2.1. Authentication
6.2.1. 認証
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プロトコルで必要ではありません。 それはPhase1プロトコルの文脈へ駆け込んでいます。(プロトコルは以前に、同輩のアイデンティティを認証しました)。
Baugher, et. al. Standards Track [Page 38] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[38ページ]。
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.
HASHペイロードは各メッセージに通報認証を提供します。そこでは、HASHが、メッセージにSKEYID(Phase1交換では、引き出される)、ISAKMP Message-IDとすべてのペイロードの上あるように定義されます。 交換の2つの終点だけがSKEYID値を知っているので、これは同輩がメッセージを送ったという信用を供給します。
6.2.2. Confidentiality
6.2.2. 秘密性
Confidentiality is provided by the Phase 1 security association, after the manner described in [RFC2409].
秘密性は[RFC2409]で説明された方法の後のPhase1セキュリティ協会によって提供されます。
6.2.3. Man-in-the-Middle Attack Protection
6.2.3. 介入者攻撃保護
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.
通報認証(上で、説明される)はHASHペイロードを構成するときグループのメンバーとGCKSだけにおいて知られている秘密を含んでいます。 攻撃者はメッセージが非検出した変化にできないでしょう、したがって、これが中央の人と接続をハイジャックする攻撃を防ぎます。
6.2.4. Replay/Reflection Attack Protection
6.2.4. 再生/反射攻撃保護
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ペイロード計算に含まれています。 それ自身の一回だけが含まれている状態でHASHを受ける前に、GroupメンバーとGCKS MUST NOTはどんな計算上高価なタスクも実行します。 有効なHASHペイロードがそれ自身の一回だけを含んでいる交換における3番目のメッセージを受け取るまで、GCKS MUST NOTは集団経営状態(例えば、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.
実装SHOULDは最近受信されたGROUPKEY-PULLメッセージに関する記録をつけて、既に処理されたメッセージを拒絶します。 これは再演されたメッセージの早めの破棄を可能にします。
6.2.5. Denial of Service Protection
6.2.5. サービス妨害保護
A GROUPKEY-PULL message identifies its messages using a cookie pair from the Phase 1 exchange that precedes it. The cookies provide a weak form of denial of service protection as described above, in the sense that a GROUPKEY-PULL message with invalid cookies will be discarded.
GROUPKEY-PULLメッセージは、それに先行するPhase1交換からのクッキー組を使用することでメッセージを特定します。 クッキーは上で説明されるようにサービス保護の否定の弱形を提供します、無効のクッキーがあるGROUPKEY-PULLメッセージが捨てられるという意味で。
The replay protection mechanisms described above provide the basis for denial of service protection.
上で説明された反復操作による保護メカニズムはサービス保護の否定の基礎を提供します。
Baugher, et. al. Standards Track [Page 39] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[39ページ]。
6.2.6. Authorization
6.2.6. 承認
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-PULL交換におけるCERTペイロードで、グループのメンバーかGCKSが承認属性を同輩に含んでいて、公衆/秘密鍵組を特定する証明書を提出できます。 GROUPKEY-PULL POPペイロードは、承認がそれが秘密鍵の所有物にあると立証することによって承認インフラストラクチャがGROUPKEY-PULL認証インフラストラクチャと異なっているところで達成されるのを可能にします。
6.3. GROUPKEY-PUSH Exchange
6.3. 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-PUSH交換はGCKSがメンバーを分類するためにSAsとキーを送ることができるただ一つのメッセージです。 これは、IPマルチキャストグループを使用することですべてのメンバーに送られそうです。 これは効率的なrekeyとグループ会員資格調整能力を提供します。
6.3.1. Authentication
6.3.1. 認証
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を保護します。
6.3.2. Confidentiality
6.3.2. 秘密性
The GCKS encrypts the GROUPKEY-PUSH message with an encryption key that was established by the GROUPKEY-PULL exchange.
GCKSはGROUPKEY-PULL交換で設立された暗号化キーでGROUPKEY-PUSHメッセージを暗号化します。
6.3.3. Man-in-the-Middle Attack Protection
6.3.3. 介入者攻撃保護
This combination of confidentiality and message authentication services protects the GROUPKEY-PUSH message from man-in-middle and connection-hijacking attacks.
秘密性とメッセージ認証サービスのこの組み合わせは中央の人と接続をハイジャックする攻撃からGROUPKEY-PUSHメッセージを保護します。
6.3.4. Replay/Reflection Attack Protection
6.3.4. 再生/反射攻撃保護
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メッセージは、再生と反射攻撃から守るために単調に増加する一連番号を含んでいます。 グループのメンバーは、一連番号を引窓と比較する超能力プロトコルと同じ方法で再演されたメッセージが一連番号を使用すると認めるでしょう。
Implementations SHOULD keep a record of recently received GROUPKEY-PUSH messages and reject duplicate messages. This enables an early discard of the replayed messages.
実装SHOULDは最近受信されたGROUPKEY-PUSHメッセージに関する記録をつけて、写しメッセージを拒絶します。 これは再演されたメッセージの早めの破棄を可能にします。
Baugher, et. al. Standards Track [Page 40] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[40ページ]。
6.3.5. Denial of Service Protection
6.3.5. サービス妨害保護
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.
サービス不能攻撃を増幅するデジタル署名の可能性はグループのメンバーが取る操作の注文で緩和されます。そこでは、最初に、実行されます中で暗号の操作最も高価でない。 グループのメンバーは、最初に、左右対称の暗号を使用することでメッセージを解読します。 それが確実に形成されたメッセージであるなら、一連番号は再生ウィンドウに対してチェックされます。 一連番号が有効であるのが、確かめられたデジタル署名であるということである場合にだけ。 したがって、サービス不能攻撃が仕掛けられるために、攻撃者は、秘密性に使用される左右対称の暗号化キーと有効な一連番号の両方を知る必要があるでしょう。 概してこれは、事実上、現在のグループのメンバーだけがサービス不能攻撃を配布することができることを意味します。
6.3.6. Forward Access Control
6.3.6. 前進のアクセスコントロール
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などの)が使用されているなら、いくつかの場合、前進のアクセスコントロールは確実にされないかもしれません。 同じGROUPKEY-PUSHメッセージの新しい政策としてのグループへのアクセスが何人かのグループのメンバーに拒絶されるなら、これは起こることができます、そして、TEKsはグループに提供されます。 セクション4.2.1で議論するように、複数のGROUPKEY-PUSHメッセージを送ることによって、前進のアクセスコントロールを維持できます。(そこでは、グループ会員資格変化が新しい政策から別々のGCKSとTEKsから送られます)。
7. IANA Considerations
7. IANA問題
7.1. ISAKMP DOI
7.1. ISAKMP土井
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番号が、SAペイロードがGDOI SAペイロードであると認識するのに必要です。 IANAは、GDOIを表すために値2を割り当てました。
Baugher, et. al. Standards Track [Page 41] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[41ページ]。
7.2. Payload Types
7.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 Next有効搭載量タイプを定義します。 ペイロードのためのセクション5.0が定義されるのを本書では見てください、これらのペイロードを特定するためにIANAによって定義されたNext有効搭載量値を含んでいて。
7.3. New Name spaces
7.3. 新しいName空間
The present document describes many new name spaces for use in the GDOI payloads. Those may be found in subsections under Section 5.0. A new GDOI registry has been created for these name spaces.
現在のドキュメントはGDOIペイロードにおける使用のために多くの新しい名前空間について説明します。 ものはセクション5.0の下で小区分で見つけられるかもしれません。 新しいGDOI登録をこれらの名前空間に作成してあります。
Portions of name spaces marked "RESERVED" are reserved for IANA allocation. New values MUST be added due to a Standards Action as defined in [RFC2434].
「予約されていること」が示される名前空間の部分はIANA配分のために予約されます。 [RFC2434]で定義されるStandards Actionのため新しい値を加えなければなりません。
Portions of name spaces marked "Private Use" may be allocated by implementations for their own purposes.
実装はそれら自身の目的のために「私用」であることが示される名前空間の部分を割り当てるかもしれません。
7.4. UDP Port
7.4. UDPポート
The IANA has assigned port 848 for use by GDOI.
IANAはGDOIによる使用のためにポート848を割り当てました。
8. Intellectual Property Rights Statement
8. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Baugher, et. al. Standards Track [Page 42] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[42ページ]。
9. Acknowledgements
9. 承認
The authors thank Ran Canetti, Cathy Meadows, Andrea Colegrove, and Lakshminath Dondeti. Ran has advised the authors on secure group cryptography, which has led to changes in the exchanges and payload definitions. Cathy identified several problems in previous versions of this document, including a replay attack against the proof of possession exchange, as well as several man-in-the-middle attacks. Andrea contributed to the group policy section of this document. Lakshminath identified several protocol issues that needed further specification and helped to resolve them.
作者はRanカネッティ、キャシー・メドース、アンドレア・コールグローブ、およびLakshminath Dondetiに感謝します。 走行、安全なグループ暗号に関して作者にアドバイスしました。(それは、交換とペイロード定義における変化に通じました)。 キャシーはこのドキュメントの旧バージョンのいくつかの問題を特定しました、所有物交換の証拠に対して反射攻撃を含めて、いくつかの介入者攻撃と同様に。 アンドレアはこのドキュメントのグループ方針部に貢献しました。 Lakshminathはそれらを決議するのを助けたさらなる仕様が必要があって、いくつかのプロトコル問題を特定しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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-モード]の「ブロック暗号運転モードのための推薦」と科学のアメリカの、そして、国家の研究所の合衆国と技術、NISTの特別な公表800-38は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]「エー・イー・エス(AES)」、科学技術のアメリカの、そして、国家の研究所の合衆国連邦情報処理基準(FIPS。)197(2001年11月)
[IPSEC-REG] http://www.iana.org/assignments/ipsec-registry
[IPSEC-レッジ] http://www.iana.org/assignments/ipsec-registry
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[ISAKMP-レッジ] 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.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Baugher, et. al. Standards Track [Page 43] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[43ページ]。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Domain of Interpretation for
ISAKMP", RFC 2407, November 1998.
[RFC2407] パイパー、D.、「ISAKMPのための解釈のインターネットIPドメイン」、RFC2407、1998年11月。
[RFC2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management
Protocol", RFC 2408, November 1998.
[RFC2408] Maughan、D.、Shertler、M.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは議定書を作ります」、RFC2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[RFC2412] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key
Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
[RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627,
September 1998.
[RFC2627] ウォルナー、D.、ハーダー、E.、およびR.エージー、「マルチキャストのための管理を合わせてください」 「問題とアーキテクチャ」、RFC2627、9月1998日
[RSA] RSA Laboratories, "PKCS #1 v2.0: RSA Encryption
Standard", October 1998.
[RSA]RSA研究所、「PKCS#1v2.0:」 1998年10月の「RSA暗号化規格。」
10.2. Informative References
10.2. 有益な参照
[FS00] N. Ferguson and B. Schneier, "A Cryptographic Evaluation
of IPsec, CounterPane",
http://www.counterpane.com/ipsec.html.
[FS00]N.ファーガソンとB.シュナイアー、「IPsec、ベッドカバーの暗号の評価」 http://www.counterpane.com/ipsec.html 。
[GKMARCH] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Group
Key Management Architecture", Work in Progress.
R.カネッティ、L.Dondeti、F.リンドホルム、「グループKey Managementアーキテクチャ」という[GKMARCH]M.Baugherは進行中で働いています。
[IKEv2] D. Harkins, et. al., "Proposal for the IKEv2 protocol",
Work In Progress.
et[IKEv2]D.ハーキン、アル、「IKEv2プロトコルのための提案」、Work In Progress。
[KINK] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation
of Keys (KINK)", Work in Progress.
[ねじれます] M.トーマス、「キー(もつれ)のKerberizedインターネット交渉」というJ.Vilhuberは進行中で働いています。
Baugher, et. al. Standards Track [Page 44] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[44ページ]。
[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、「状態がない受信機の取消しと追跡体系」、Cryptology、2001年のSpringer-Verlag LNCS2139年のCrypto'01、ページのAdvances、' 41-62. 紙の完全版は http://www.wisdom.weizmann.ac.il/~naor/ に現れます。
[OFT] D. Mcgrew and A. Sherman, "Key Establishment in Large
Dynamic Groups Using One-Way Function Trees", Manuscript
submitted to IEEE Transactions on Software Engineering.
A full version of the paper
appears in http://download.nai.com/products/media/nai/
misc/oft052098.ps, 1998
[OFT] D.McgrewとA.シャーマン、「大きいダイナミックなグループへの一方向関数木を使用する主要な設立」、ManuscriptはSoftware Engineeringの上のIEEE Transactionsに提出しました。 紙の完全版は http://download.nai.com/products/media/nai/ 雑ネタ/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.パールマン、C.コーフマン、「IPsecの主要な交換規格の分析」、WET-ICE会議、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、「グループKey Managementプロトコル(GKMP)仕様」、RFC2093、1997年7月。
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture," RFC 2094, July 1997.
[RFC2094] ハーニーとH.とC.Muckenhirn、「グループKey Managementプロトコル(GKMP)アーキテクチャ」、RFC2094、1997年7月。
[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 Management API、バージョン2インチ、RFC2367、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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年6月。
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", ISOC Secure Networks and
Distributed Systems Symposium, San Diego, 1996.
[SKEME]H.Krawczyk、「SKEME:」 「インターネットへの多能な安全な主要な交換メカニズム」、ISOCは、ネットワークと分散システムがシンポジウム、サンディエゴ、1996であると機密保護します。
[STS] Diffie, P. van Oorschot, M. J. Wiener, "Authentication
and Authenticated Key Exchanges, Designs, Codes and
Cryptography", 2, 107-125 (1992), Kluwer Academic
Publishers.
[STS]ディフィーと、P.バンOorschotと、M.J.Wienerと、「認証、認証された主要な交換、デザイン、コード、および暗号」、2、107-125(1992)、Kluwer Academic Publishers。
Baugher, et. al. Standards Track [Page 45] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[45ページ]。
Appendix A: Alternate GDOI Phase 1 protocols
付録A: 代替のGDOI Phase1プロトコル
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 Phase1に代わったGDOI Phase1プロトコルが議定書を作るとき他のプロトコルを使用できるだろう方法を説明します。 しかしながら、それらはこのドキュメントの一部として指定されません。 GDOI Phase1が議定書を作るので別のプロトコルが使用されるために別々のドキュメントを書かなければなりません。
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 Phase1プロトコル
Version 2 of the IKE protocol (IKEv2) is a work in progress [IKEv2]. That protocol seeks to simplify the IKE Phase 1 and Phase 2 protocols, and improve the security of the IKE protocol. An IKEv2 Phase 1 negotiates an IPSEC SA during phase 1, which was not possible in IKE. However, IKEv2 also defines a phase 2 protocol. The phase 2 protocol is protected by the Phase 1, similar in concept to how IKE Quick Mode is protected by the IKE Phase 1 protocols in [RFC2409].
IKEプロトコル(IKEv2)のバージョン2は処理中の作業[IKEv2]です。 そのプロトコルは、IKE Phase1とPhase2つのプロトコルを簡素化して、IKEプロトコルのセキュリティを向上させようとします。 IKEv2 Phase1は段階1の間、IPSEC SAを交渉します。(それは、IKEで可能ではありませんでした)。 しかしながら、また、IKEv2はフェーズ2プロトコルを定義します。 フェーズ2プロトコルはPhase1によって保護されます、概念では、IKEクィックModeが[RFC2409]のIKE Phase1プロトコルによってどう保護されるかと同様です。
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がユニークなポートを使用するので、SAペイロードのフェーズ2プロトコルがGDOI値を使用することの選択は必要ではありません。 IKEv2 Phase1プロトコル定義をGDOIポートに実行できたと予想されます。 プロトコルのSAペイロードが、全くGDOIに特定であるか、省略されるまたは必要でしょう。
The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in the same manner as described in this document.
本書では説明されるのと同じ方法でGROUPKEY-PULLプロトコルはIKEv2 Phase1プロトコルに従うでしょう。
A.2. KINK Protocol
A.2。 もつれプロトコル
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]はMode[RFC2409]がケルベロスKRB_でカプセル化したIKEクィックにAP_REQとKRB_AP_REPペイロードをカプセル化するメソッドを定義しました。 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を定義できました(ケルベロスKRBにおけるGROUPKEY-PULL交換に_AP_REQをカプセル化して、_AP_REPペイロードをKRBにカプセル化するでしょう)。 そういうものとして、GDOIはKINKの計算効率の利益を得るでしょう。
Baugher, et. al. Standards Track [Page 46] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[46ページ]。
Authors' Addresses
作者のアドレス
Mark Baugher Cisco Systems 5510 SW Orchid Street Portland, OR 97219, USA
5510年のマークBaugherシスコシステムズSW Orchid通りポートランド、または97219、米国
Phone: (503) 245-4543 EMail: mbaugher@cisco.com
以下に電話をしてください。 (503) 245-4543 メールしてください: mbaugher@cisco.com
Thomas Hardjono VeriSign 401 Edgewater Place, Suite 280 Wakefield, MA 01880
トーマスHardjonoベリサイン401Edgewater場所、ウェークフィールド、Suite280MA 01880
Phone: 781-245-6996 EMail: thardjono@verisign.com
以下に電話をしてください。 781-245-6996 メールしてください: thardjono@verisign.com
Hugh Harney Sparta 9861 Broken Land Parkway Columbia, MD 21046
Parkwayコロンビア、ヒューハーニースパルタ9861の起伏の多いLand MD 21046
Phone: (410) 381-9400 x203 EMail: hh@sparta.com
以下に電話をしてください。 (410) 381-9400x203 EMail: hh@sparta.com
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA
ブライアンウィスシスコシステムズ170w.タスマンDrive、サンノゼ、カリフォルニア95134-1706、米国
Phone: (408) 526-4796 EMail: bew@cisco.com
以下に電話をしてください。 (408) 526-4796 メールしてください: bew@cisco.com
Baugher, et. al. Standards Track [Page 47] RFC 3547 GDOI Domain of Interpretation July 2003
et Baugher、アル。 規格は2003年7月に解釈のRFC3547GDOIドメインを追跡します[47ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Baugher, et. al. Standards Track [Page 48]
et Baugher、アル。 標準化過程[48ページ]
一覧
スポンサーリンク
