web-dev-qa-db-ja.com

IKEv2のIKE_AUTHフェーズ中の鍵交換

カジュアルな_IKEv2_ハンドシェイクは次のようになります。

_  Initiator                                                       Responder
  |                                                                      |
 1|-----------------------> HDR, SAi1, KEi, Ni ------------------------->|
 2|<----------------- HDR, SAr1, KEr, Nr, [CERTREQ] <--------------------|
 3|----> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}-->| 
 4|<------------ HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} <-----------|
  |                                                                      |
_

メッセージ（1）および（2）は_IKE_SA_INIT_交換に属し、メッセージ（3）および（4）は_IKE_AUTH_交換に属します。私はこの交換のWiresharkトレースを分析しましたが、IKE_AUTH (SAi2, SAr2)の間に、イニシエーター/レスポンダーがサポート/選択した一連のセキュリティアルゴリズム（暗号化、認証、整合性保護、diffie）をアドバタイズしているようです-hellmanグループ）。ただし、どちらもDH値をアドバタイズしません。したがって、ここでは実際の鍵交換はありません。私の質問は、_(SAi2, SAr2)_のセキュリティアソシエーションネゴシエーションの目的は何ですか？そして、プロトコルは_IKE_SA_INIT_中に既に1つを達成しているため、2番目のキー交換が必要なのはなぜですか（つまり、なぜ新しいキーをネゴシエートする必要があるのですか）。

diffie-hellmanipsecike
1
sasuke_X220

SAi2/SAr2ペイロードは、TSi/TSrペイロードとともに、最初の子SAをネゴシエートするために使用されます。 RFC 7296、セクション1.2 に従って：

イニシエーターは、子のネゴシエーションを開始しますSA SAi2ペイロードを使用します。最後のフィールド（SAi2で始まる）は、CREATE_CHILD_SA交換の説明で説明されています。

ただし、この子のキーマテリアルSAはIKEキーマテリアル（IKE_SA_INITの実行中にKEペイロードで確立）から派生しているため、個別のキーはありません。交換。DHグループは、IKE_AUTHの間、SAペイロードに明示的に含まれません。上記と同じセクションから：

IKE_AUTHメッセージには、KEi/KErまたはNi/Nrペイロードが含まれていないことに注意してください。したがって、SAペイロードには、NONE以外の値を持つ変換タイプ4（Diffie-Hellmanグループ）を含めることはできません。実装は、値NONEを送信する代わりに変換サブ構造全体を省略する必要があります。

RFC 6023 （Childless IKEv2 Initiation）をサポートするIKEv2実装は、これらのSA/TSペイロードを省略して、IKE SA最初の子SAなし。

後でCREATE_CHILD_SA交換を使用して子SAを作成または再キーイングするときに、ピアはオプションでDHグループをネゴシエートし、KEペイロードを使用してパブリックDH要素を交換できます（新しい子のキーが完了していない場合SAは、IKE SAキーマテリアルから派生したものです。）これは、IKEを子から分離する目的に役立ちますSAキーと子SA相互の鍵（これは通常、Perfect Forward SecrecyまたはPFSと呼ばれます）。

1
ecdsa