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

3. GROUPKEY-PULL交換 (GROUPKEY-PULL Exchange)

GROUPKEY-PULL交換の目的は、特定のグループのメンバーにおいて再鍵化 (Re-key) および/またはデータセキュリティSAを確立することです。フェーズ1 SAがGROUPKEY-PULLを保護します。特定のフェーズ1 SAに対して複数のGROUPKEY-PULL交換が存在する可能性があります (MAY)。GROUPKEY-PULL交換は、フェーズ1 SAの保護の下で、データセキュリティ鍵 (TEK) および/またはグループ鍵暗号化鍵 (KEK) またはKEK配列をダウンロードします。

3.1. 認可 (Authorization)​

GROUPKEY-PULLメッセージを認可する2つの代替手段があります。第1に、フェーズ1アイデンティティを使用して、グループ鍵のフェーズ2 (GROUPKEY-PULL) リクエストを認可できます。第2に、GROUPKEY-PULLリクエストで新しいアイデンティティを渡すことができます。新しいアイデンティティは、グループに固有のものであり、グループ所有者によって署名された証明書を使用して、保持者を認可されたグループメンバーとして識別できます。所有証明ペイロード (Proof-of-Possession Payload) は、保持者がフェーズ2アイデンティティに関連付けられた秘密鍵を所有していることを検証します。

3.2. メッセージ (Messages)​

GROUPKEY-PULLはフェーズ2交換です。フェーズ1は、GROUPKEY-PULL HASHペイロードで使用されるキー付きハッシュの「鍵 (Key)」であるSKEYID_aを計算します。本文書で定義されているフェーズ1を使用する場合、SKEYID_aは[RFC2409]に従って導出されます。IKE HASHペイロード生成 [RFC 2409 セクション5.5] と同様に、各GROUPKEY-PULLメッセージは一意に定義された値のセットをハッシュします。ノンス (Nonces) はHASHを順列し、リプレイ攻撃 (Replay Attacks) に対するある程度の保護を提供します。リプレイ保護は、鍵管理サーバーが引き付ける攻撃からGCKSを保護するために重要です。

GROUPKEY-PULLはノンスを使用して「活性 (Liveliness)」を保証します、つまり最近のGROUPKEY-PULLメッセージのリプレイに対する保護です。リプレイ攻撃は、現在のフェーズ1のコンテキストでのみ有用です。以前のフェーズ1に基づいてGROUPKEY-PULLメッセージがリプレイされた場合、HASH計算は間違ったSKEYID_aのために失敗します。メッセージは、ノンスが評価される前に処理に失敗します。どちらのピアもリプレイ保護の恩恵を受けるためには、ピアが活性していることを証明するプロトコルでメッセージを受信するまで、できるだけ多くの処理を延期する必要があります。たとえば、レスポンダは、HASHペイロードに適切にNrが含まれているメッセージを受信するまで、共有Diffie-Hellman番号 (KEペイロードが含まれている場合) を計算したり、新しいSAをインストールしたりしてはなりません (MUST NOT)。

ノンスは、GCKSがグループメンバーを活性を証明するまで追加しないようにするために、プロトコル交換で追加のメッセージを必要とします。GROUPKEY-PULLメンバーイニシエータは、返されたメッセージのHASHに自身のノンスNiが含まれていることを期待します。そして、GROUPKEY-PULL GCKSレスポンダは、以下の交換のようにグループ鍵化マテリアルを提供する前に、返されたメッセージのHASHに自身のノンスNrが含まれていることを確認することを期待します。

イニシエータ (メンバー)              レスポンダ (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]

ハッシュは次のように計算されます:

HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | CERT ] [ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ] KD [ | CERT ] [ | POP_R])

POPペイロードは、セクション5.7で説明されているように構築されます。

注: フェーズ1 SAによって保護されており、暗号化はHDRの後に発生します

HDRは、IKE [RFC2409] のようにフェーズ1クッキーとメッセージ識別子 (M-ID) を使用するISAKMPヘッダーペイロードです。ノンスは最初の2つの交換に含まれ、GCKSは活性が証明される前にSAポリシーペイロードのみを返すことに注意してください。HASHペイロード [RFC2409] は、ピアがフェーズ1シークレット (SKEYID_a) とメッセージID (M-ID) によって識別される交換のノンスを持っていることを証明します。活性が確立されると、最後のメッセージはKDペイロードのダウンロードの実際の処理を完了します。

ノンスとHASHペイロードに加えて、メンバーイニシエータはISAKMP IDペイロードを通じて参加したいグループを識別します。GCKSレスポンダは、SEQペイロードでシーケンス番号の現在の値をメンバーに通知します。シーケンス番号はGROUPKEY-PUSHデータグラム (セクション4) を順序付けます。メンバーは、新しいSAをインストールする前に、シーケンス番号がグループに対して保持している以前のSEQペイロード (保持している場合) よりも大きいことを確認しなければなりません (MUST)。SAペイロードにSA KEK属性が含まれている場合、SEQペイロードが存在しなければなりません (MUST)。

3.2.1. 完全前方秘匿性 (Perfect Forward Secrecy)​

GROUPKEY-PULLの完全前方秘匿性 (Perfect Forward Secrecy, PFS) は、RFC 2409で説明されている鍵交換 (Key Exchange, KE) ペイロードのオプションの含有によって達成されます。KEが使用される場合、GROUPKEY-PULLの一部としてDiffie-Hellman交換があります。これにより、Diffie-Hellman鍵合意へのアクセスなしにTEKまたはKEKを回復できないことが保証されます。

3.2.2. ISAKMPヘッダーの初期化 (ISAKMP Header Initialization)​

GROUPKEY-PULLのHDRフィールドは次のように初期化されます。

  • クッキーはフェーズ1からのものです。各GROUPKEY-PULLはフェーズ1クッキーを共有します。
  • メッセージIDはイニシエータによってランダムに生成され、REQUESTとREPLYをマッチングするために使用されます。
  • 次のペイロードはHASHです。
  • 交換タイプはGDOI_GROUPKEY_PULL (値32) です。

3.3. イニシエータの動作 (Initiator Operations)​

GROUPKEY-PULLイニシエータは、ノンスNiを生成し、フェーズ1 SAですべてのメッセージを保護しなければなりません (MUST)。フェーズ1 SAは、すべてのGROUPKEY-PULLペイロードに対して暗号化とデータ発信元認証を提供します。

3.4. レシーバーの動作 (Receiver Operations)​

GROUPKEY-PULLレスポンダ (GCKS) は、すべてのHASHペイロードを検証し、その後、後続のペイロードを復号化しなければなりません (MUST)。GCKSは、HASH計算のノンスNiとNrが、平文ペイロードで送信されたノンスと一致することを確認しなければなりません (MUST)。HASHペイロード検証が失敗した場合、GCKSはメッセージを拒否しなければならず (MUST)、イベントを監査してもよい (MAY)。

GCKSは、本文書の範囲外のポリシーを通じてグループメンバーの認可を検証しなければなりません (MUST)。

に最終更新