メインコンテンツまでスキップ

1. はじめに (Introduction)

本文書は、「グループ解釈ドメイン (Group Domain of Interpretation, GDOI)」と呼ばれるグループ鍵管理のためのISAKMP解釈ドメイン (ISAKMP Domain of Interpretation, DOI) を提示します。このグループ鍵管理モデルでは、GDOIプロトコルはグループメンバーと「グループコントローラー/鍵サーバー (Group Controller/Key Server, GCKS)」の間で実行され、認可されたグループメンバー間でセキュリティアソシエーション (Security Associations) [RFC2401 セクション4.6.2] を確立します。ISAKMPは2つの交渉「フェーズ (Phases)」を定義しています [RFC2408 p.16]。GDOIはフェーズ1セキュリティアソシエーションによって保護されなければなりません (MUST)。本文書は、インターネットDOI [RFC2407, RFC2409] からフェーズ1セキュリティアソシエーション (SA) の定義を取り入れています。その他の可能なフェーズ1セキュリティアソシエーションタイプは付録Aに記載されています。フェーズ2交換は本文書で定義されており、ISAKMP標準 [RFC2408 p.14] に従って新しいペイロード (Payloads) と交換 (Exchanges) を提案しています。

6つの新しいペイロードがあります:

  1. GDOI SA
  2. SA KEK (SAK)、SAペイロードに続くもの
  3. SA TEK (SAT)、SAペイロードに続くもの
  4. 鍵ダウンロード配列 (Key Download Array, KD)
  5. シーケンス番号 (Sequence Number, SEQ)
  6. 所有証明 (Proof of Possession, POP)

2つの新しい交換があります。

1) フェーズ2交換は、再鍵化 (Re-key) およびデータセキュリティプロトコルSAを作成します。

「GROUPKEY-PULL」と呼ばれる新しいフェーズ2交換は、グループの「再鍵化 (Re-key)」SAおよび/または「データセキュリティ (Data-security)」SAの鍵をダウンロードします。再鍵化SAには、グループに共通の鍵暗号化鍵 (Key Encrypting Key, KEK) が含まれます。データセキュリティSAには、データセキュリティプロトコルがデータトラフィックを暗号化または復号化するために使用するデータ暗号化鍵 (Data Encryption Key, TEK) が含まれます [RFC2407 セクション2.1]。KEKまたはTEKのSAには、認証鍵 (Authentication Keys)、暗号化鍵 (Encryption Keys)、暗号ポリシー (Cryptographic Policy)、および属性 (Attributes) が含まれます。GROUPKEY-PULL交換は、メンバーがGCKSからこれらのSAの取得を開始するため、「プル (Pull)」動作を使用します。

2) データグラムは、その後、追加の再鍵化および/またはデータセキュリティプロトコルSAを確立します。

GROUPKEY-PUSHデータグラムは、再鍵化またはデータセキュリティSAを作成または更新するために、GCKSからメンバーに「プッシュ (Pushed)」されます。再鍵化SAはGROUPKEY-PUSHメッセージを保護します。したがって、後続のGROUPKEY-PUSHメッセージを保護するために、少なくとも1つの再鍵化SAを確立するためにGROUPKEY-PULLが必要です (MUST)。GCKSは、KEK再鍵化SAを使用してGROUPKEY-PUSHメッセージを暗号化します。GDOIは、論理鍵階層 (Logical Key Hierarchy, LKH) アルゴリズムを使用するグループ鍵管理アルゴリズムのためのKEK配列の使用に対応しており、グループメンバーの追加と削除を効率的に行います [RFC2627]。LKHアルゴリズムの実装は任意です (OPTIONAL)。

本文書で規定されているGROUPKEY-PUSHは再鍵化SAをリフレッシュするために使用できますが (CAN)、GROUPKEY-PUSHの最も一般的な使用法は、データセキュリティプロトコルのためのデータセキュリティSAを確立することです。GDOIは、さまざまなデータセキュリティプロトコルをサポートするための将来の拡張に対応できます (CAN)。本文書は、1つのセキュリティプロトコル (IPsec ESP) に対してのみデータセキュリティSAを規定しています。別のRFCが、将来のセキュアリアルタイム転送プロトコル (Secure Real-time Transport Protocol) などの他のデータセキュリティプロトコルのサポートを規定する予定です。セキュリティプロトコルはTEKを使用し、IPsec ESPがIKEフェーズ2鍵を使用してフェーズ2SAを「所有」するのと同じ方法でデータセキュリティSAを「所有」します。GDOIの場合、IPsec ESPはTEKを使用します。

したがって、GDOIはグループセキュリティアソシエーション管理プロトコルです。すべてのGDOIメッセージは、グループのセキュリティアソシエーションを作成、維持、または削除するために使用されます。上記のように、これらのセキュリティアソシエーションは、マルチキャストおよびグループセキュリティアプリケーションのためにグループメンバーによって共有される1つ以上の鍵暗号化鍵、トラフィック暗号化鍵、またはデータを保護します。

本文書に出現するキーワードMUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALは、BCP 14、RFC 2119 [RFC2119] で説明されているように解釈されます。

1.1. GDOIアプリケーション (GDOI Applications)​

セキュアマルチキャストアプリケーションには、ビデオブロードキャスト (Video Broadcast) やマルチキャストファイル転送 (Multicast File Transfer) が含まれます。ビジネス環境では、これらのアプリケーションの多くがネットワークセキュリティを必要とし、データトラフィックを保護するためにIPsec ESPを使用する可能性があります (MAY)。セクション5.4.1では、GDOIがESPに必要なSAパラメータをどのように伝送するかを規定しています。このように、GDOIは、共有グループ鍵 (Shared Group Key) を使用したESPパケットのグループ認証によるマルチキャストESPをサポートします (ESPパケットの一意のソースの認証は不可能です)。

GDOIは、ビデオオンデマンド (Video-on-Demand) などのマルチキャスト転送を使用しないグループアプリケーションも保護できます (CAN)。たとえば、GROUPKEY-PUSHメッセージは、鍵管理交換や高コストの非対称暗号 (Asymmetric Cryptography) を必要とせずに、サブスクリプショングループのメンバーのためのペアワイズ (Pair-wise) IPsec ESP SAを確立できます (MAY)。

1.2. GDOIの拡張 (Extending GDOI)​

すべてのセキュアマルチキャストまたはマルチメディアアプリケーションがIPsec ESPを使用できるわけではありません。たとえば、多くのリアルタイム転送プロトコル (Real Time Transport Protocol) アプリケーションは、RTPヘッダー圧縮効率と転送独立性を維持するために、IPレイヤーの上でセキュリティを必要とします [RFC3550]。将来のRTPセキュリティプロトコルは、グループSAを確立するためにGDOIを使用することから利益を得る可能性があります (MAY)。

新しいデータセキュリティプロトコルを追加するには、新しいRFCが、GDOIがそのセキュリティプロトコルのために伝送するデータセキュリティSAパラメータを規定しなければなりません (MUST)。これらのパラメータは、本文書のセクション5.4.2に列挙されています。

データセキュリティプロトコルSAは、グループトラフィックを保護しなければなりません (MUST)。GDOIは、そのグループトラフィックがユニキャスト (Unicast) またはマルチキャスト (Multicast) パケットとして配信されるかについて制限を設けていません。ただし、データセキュリティSAによって保護されるパケットがプライベートのままであることを意図しており、グループ通信の一部にならない場合、GDOIはデータセキュリティプロトコルによって鍵管理メカニズムとして使用されてはなりません (MUST NOT)。

に最終更新