2.18. CREATE_CHILD_SA 交換を使用した IKE SA の鍵再生成

2.18. CREATE_CHILD_SA 交換を使用した IKE SA の鍵再生成

CREATE_CHILD_SA 交換は, 既存の IKE SA の鍵を再生成するために使用できます (セクション 1.3.2 および 2.8 参照)。新しいイニシエータおよびレスポンダの SPI は, セキュリティ・アソシエーション (SA) ペイロード内の提案 (Proposal) 構造体の SPI フィールドに提供されます (IKE ヘッダ内の SPI フィールドではありません)。IKE SA の鍵を再生成するときは, TS ペイロードは省略されます。新しい IKE SA の SKEYSEED は, 既存の IKE SA の SK_d を使用して次のように計算されます:

SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)

ここで g^ir (new) はこの CREATE_CHILD_SA 交換の一時的な Diffie-Hellman 交換からの共有秘密 (ビッグエンディアン順のオクテット文字列として表現され, 必要に応じてゼロでパディングされて modulus の長さとする) であり, Ni および Nr は任意のヘッダを取り除いた 2 つのナンスです。

古い IKE SA と新しい IKE SA は異なる PRF を選択しているかもしれません。鍵再生成交換は古い IKE SA に属するため, SKEYSEED の生成に使用されるのは古い IKE SA の PRF です。

IKE SA の鍵を再生成する主な理由は, 古い鍵素材の漏洩が現在の鍵に関する情報を提供せず, その逆も同様であることを保証するためです。したがって, 実装は IKE SA の鍵を再生成するときに, 新しい Diffie-Hellman 交換を実行しなければなりません (MUST)。言い換えると, イニシエータは Diffie-Hellman 変換に対して "NONE" 値を提案してはならず (MUST NOT), レスポンダはそのような提案を受け入れてはなりません (MUST NOT)。これは, IKE SA の鍵を再生成する成功した交換には常に KEi/KEr ペイロードが含まれることを意味します。

新しい IKE SA は, そのメッセージ・カウンタを 0 にリセットしなければなりません (MUST)。

SK_d, SK_ai, SK_ar, SK_ei, および SK_er は, セクション 2.14 で指定されたとおりに SKEYSEED から計算され, 新しい交換の SPIi, SPIr, Ni, Nr を使用し, また新しい IKE SA の PRF を使用します。