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

4. GROUPKEY-PUSHメッセージ (GROUPKEY-PUSH Message)

GDOIは、グループ通信を使用して制御情報を安全に送信します。通常、これはGROUPKEY-PUSHメッセージのIPマルチキャスト配信を使用しますが、IPマルチキャストが不可能な場合は、ユニキャスト配信を使用して「プッシュ」することもできます (CAN)。GROUPKEY-PUSHメッセージは、再鍵化SA KEKまたはKEK配列を置き換え、および/または新しいデータセキュリティSAを作成します。

メンバー                             GCKSまたは委任者
------                               ----------------

                    <---- HDR*, SEQ, SA, KD, [CERT,] SIG

注: 再鍵化SA KEKによって保護されており、暗号化はHDRの後に発生します

HDRは以下で定義されています。SEQペイロードはペイロードセクションで定義されています。SAは、再鍵化および/またはデータセキュリティSAのポリシー (例: 保護スイート) および属性 (例: SPI) を定義します。GCKSまたは委任者は、SIGの検証のためにオプションでCERTペイロードを提供します。KDは、ペイロードセクションで説明されている鍵ダウンロードペイロードです。

SIGペイロードは、暗号化前のメッセージ全体のハッシュの署名です (ヘッダーを含み、SIGペイロード自体を除く)。文字列「rekey」が接頭辞として付けられています。接頭辞文字列は、再鍵化データグラムの署名がGDOIプロトコルの他の目的に使用されないことを保証します。

SAがLKH KEK配列または単一のKEKを定義する場合、KDには新しい再鍵化SAのKEKまたはKEK配列が含まれており、新しいクッキーペアを持っています。KDペイロードが新しいSA KEK属性 (セクション5.3) を運ぶ場合、再鍵化SAは、同じグループ識別子 (セクション3.2のメッセージ1で指定されたID) を持ち、同じシーケンスカウンタをインクリメントする新しいSAに置き換えられます。シーケンスカウンタはセクション3.2のメッセージ4で初期化されます。SAがSA TEKペイロードを定義する場合、これは新しいデータセキュリティSAが作成されたことをメンバーに通知し、鍵化マテリアルはKD (セクション5.5) で運ばれます。

SAが大きなLKH KEK配列を定義する場合 (例: グループ初期化およびバッチ再鍵化中)、配列の一部を異なる一意のGROUPKEY-PUSHデータグラムで送信してもよい (MAY)。ただし、各GROUPKEY-PUSHデータグラムは、完全に形成されたGROUPKEY-PUSHデータグラムでなければなりません (MUST)。これにより、各データグラムにシーケンス番号とSAペイロードのポリシーが含まれ、KDペイロードで送信されたKEK配列部分に対応します。

4.1. 完全前方秘匿性 (Perfect Forward Secrecy, PFS)​

GROUPKEY-PUSHメッセージはグループKEKによって保護されていますが、すべての場合において、GROUPKEY-PUSHメッセージは新しい鍵ダウンロードなどの情報を運びます。GROUPKEY-PUSHメッセージがPFSを持つためには、新たに生成された秘密が鍵ダウンロードを保護しなければなりません (MUST)。この問題は今後の研究課題です。

4.2. 前方および後方アクセス制御 (Forward and Backward Access Control)​

GROUPKEY-PUSHを通じて、GDOIは、グループから削除されたメンバーによる新しいグループ鍵へのアクセスを拒否する (前方アクセス制御) および、グループに追加されたメンバーによる古いグループ鍵へのアクセスを拒否する (後方アクセス制御) という特性を持つLKHなどのアルゴリズムをサポートします。PFSとは無関係な概念として、「前方アクセス制御」および「後方アクセス制御」は、文献 [RFC2627] では「完全前方セキュリティ」および「完全後方セキュリティ」と呼ばれています。

LKH以外の前方および後方アクセス制御を提供するグループ管理アルゴリズムが文献で提案されており、OFT [OFT] およびサブセット差分 (Subset Difference) [NNL] が含まれます。これらのアルゴリズムはGDOIで使用できますが (COULD)、本文書の一部として規定されていません。

グループ管理アルゴリズムのサポートは、SA_KEKペイロードで送信されるKEY_MANAGEMENT_ALGORITHM属性を介してサポートされます。GDOIは、LKHを前方および後方アクセス制御に使用できる1つの方法を規定しています。LKHの他の使用方法、およびOFTやサブセット差分などの他のグループ管理アルゴリズムは、後の文書の一部としてGDOIに追加される可能性があります (MAY)。そのような追加は、[RFC2434] で定義されているStandards Actionによるものでなければなりません (MUST)。

4.2.1. 前方アクセス制御要件 (Forward Access Control Requirements)​

グループ管理アルゴリズムを使用してグループメンバーシップが変更される場合、通常、新しいSA_TEK (およびそれらに関連する鍵) も必要です。新しいSAと鍵は、アクセスを拒否されたメンバーがグループに参加できなくなることを保証します。

前方アクセス制御がグループの望ましい特性である場合、グループメンバーシップを変更するGROUPKEY-PUSHメッセージに、新しいSA_TEKおよびKDペイロード内の関連鍵パケットを含めてはなりません (MUST NOT)。これは、SA_TEKポリシーおよびKDペイロード内の関連鍵パケットが新しいKEKで保護されていないためです。2番目のGROUPKEY-PUSHメッセージは、新しいSA_TEKSおよびそれらに関連する鍵を配信できます。これは新しいKEKで保護されるため、アクセスを拒否されたメンバーには見えません。

グループの前方アクセス制御ポリシーに、アクセスを拒否されたメンバーからグループポリシーの変更を秘匿することが含まれる場合、GCKSはグループKEKを変更する2つの連続したGROUPKEY-PUSHメッセージを送信しなければなりません (MUST)。最初のGROUPKEY-PUSHメッセージは、グループの新しいKEKを作成します。アクセスを拒否されたグループメンバーは新しいKEKにアクセスできませんが、GROUPKEY-PUSHメッセージが現在のKEKで保護されているため、グループポリシーを見ることができます。変更されたグループポリシーを含み、再度KEKを変更する後続のGROUPKEY-PUSHメッセージにより、完全な前方アクセス制御が可能になります。GROUPKEY-PUSHメッセージは、新しいKEKを作成せずにポリシーを変更してはなりません (MUST NOT)。

LKHの他の使用方法または他のグループ管理アルゴリズムがGDOIに追加される場合、それらの方法は、単一のGROUPKEY-PUSHメッセージ内で前方アクセス制御ポリシーがどのように維持されるかを指定する限り、複数のGROUPKEY-PUSHメッセージを必要とする上記の制限を削除してもよい (MAY)。

4.3. 鍵管理の委任 (Delegation of Key Management)​

GDOIは、PKIの委任機能を通じてGROUPKEY-PUSHデータグラムの委任をサポートします。ただし、GDOIは、GCKSが委任者をどのように識別するかを明示的に規定していませんが、これを特定のGDOI実装で使用されるPKIに任せています。

4.4. 署名鍵の使用 (Use of Signature Keys)​

GCKSは、GROUPKEY-PUSHメッセージのSIGペイロードに署名するために使用する鍵と、GROUPKEY-PULL POPペイロードでの認可に使用された鍵を同じにすべきではありません (SHOULD NOT)。同じ鍵を使用しなければならない場合、POPペイロードのベースとして使用されるハッシュ関数とSIGペイロードのベースとして使用されるハッシュ関数は異なるものにすべきです (SHOULD)。

に最終更新