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

2.8. キーの再生成 (Rekeying)

2.8. キーの再生成 (Rekeying)​

キーの再生成 (rekeying) とは, 通信状態を途切れさせることなく, 既存の SA を新しい SA で置き換えることです。これは通常, 古い SA の有効期限が近づいたときに行われます。キーの再生成中, 双方は新しい鍵素材について合意しなければなりません (MUST)。双方は古い SA と新しい SA の両方からのパケットを同時に処理できなければなりません (MUST)。セクション 2.8 は子 SA のキーの再生成を説明し, セクション 2.18 は親 SA (IKE SA) のキーの再生成を説明します。

キーの再生成は頻繁に使用されますが, 関連する交換の実装は必須ではありません (REQUIRED)。キーの再生成機能を持つ実装は, この文書で説明する CREATE_CHILD_SA 交換をサポートしなければなりません (MUST)。キーの再生成機能を持たない実装は, IKE_SA_INIT 交換の SA ペイロードで, キーの再生成に特有の属性を含まない単純な提案を送信しなければなりません (MUST)。これにより, ピアはキーの再生成を試みなくなります。キーの再生成をサポートしない実装は, REKEY_SA 属性を含む CREATE_CHILD_SA 交換を拒否し, NO_ADDITIONAL_SAS 通知を含む応答を送信しなければなります (MUST)。

イニシエータがキーの再生成を行いたい場合, それは新しい SA の提案を含み, キーの再生成対象となる SA を指定する REKEY_SA 属性を含む CREATE_CHILD_SA 交換を開始します。REKEY_SA 属性の SPI 値は, キーの再生成対象となる SA が送信方向で使用する SPI です。削除された SA のキーの再生成にも REKEY_SA 属性を持つ SA ペイロードを使用できます。この場合, SPI 値は削除された SA の送信方向 SPI です。CREATE_CHILD_SA 交換中, 古い [フェードアウト] SA は引き続き使用され (つまり, キーの再生成交換が完了するまで古い SA は SA データベース (SAD) から削除されません), 新しい [フェードイン] SA が確立されます。イニシエータは, 確立されたばかりの SA を新しい SA として使用し, 古い SA を「死んだ」とマークします (つまり, できるだけ早く削除します)。レスポンダは古い SA を「生きている」とマークしますが, 新しい SA を新しい SA として使用します。言い換えれば, 双方とも古い SA の使用から新しい SA の使用に切り替えますが, レスポンダは確認を受け取るまでそうしてはなりません (MUST)。

現在の SA の所有者 (つまり, IKE_SA_INIT 交換で SA 提案を送信した側) は, キーの再生成交換でイニシエータでなければなりません (MUST)。なぜなら, 新しい SA は所有者によって提案されなければならないからです (MUST)。これは, 同時のキー再生成交換のデッドロックを防ぎます。SA のキーの再生成を行うには, SA の所有者によって CREATE_CHILD_SA 交換が開始されなければなりません (MUST)。

実装が, まもなく使用される SA を受け入れる前に, 古い SA がピアの SAD から削除されたという確認を待つ場合があります。この場合, 実装は INFORMATIONAL 交換の削除通知を待たなければなりません (MUST) (セクション 2.4 および 3.11 参照)。そのような削除通知を受信する前に, 実装は古い SA を保持しなければなりません (MUST)。なぜなら, ピアはまだそれを使用している可能性があるからです。この待機はイニシエータとレスポンダの両方の責任です。実装は古い SA を無期限に保持すべきではありません (SHOULD NOT) が, 削除通知が到着するか, その SA のネゴシエートされた生存時間 (その SA のネゴシエートされた生存時間によって決定される) が満了するまで, 古い SA を保持しなければなりません (MUST)。

キーの再生成機能を持つ実装が IKE_SA_INIT 交換中に REKEY_SA 属性を含む提案を受信した場合, それは NO_ADDITIONAL_SAS 通知を含む応答でその提案を拒否しなければなります (MUST)。実装がキーの再生成をサポートしていない場合, それは REKEY_SA 属性を含む CREATE_CHILD_SA 交換を拒否しなければなりません (MUST)。IKE_SA_INIT 交換で受信した REKEY_SA 属性を含む提案はエラーです。しかし, CREATE_CHILD_SA 交換で受信した REKEY_SA 属性を含む提案は有効です。

キーの再生成交換が失敗した場合 (たとえば, NO_ADDITIONAL_SAS のため, あるいは無効な提案のため), 古い SA は引き続き利用可能であり, 後でキーの再生成を試行してもかまいません (MAY)。古い SA が満了した場合, 通信は中断され, 双方のポリシーが許せば, 新しい SA (おそらく全く新しい IKE SA) を確立してもかまいません (MAY)。

リソース枯渇は, 攻撃者が過剰な SA を要求して被害者のリソースを消費するサービス拒否攻撃です。この攻撃を回避するため, 実装は, キーの再生成の対象となる SA の数, および単一の IKE SA によって確立される子 SA の数を, 任意の時点で制限すべきです (SHOULD)。

2.8.1. 同時キー再生成​

同時キー再生成とは, 両方のピアがキー再生成交換を開始した状況です。2 つの独立した CREATE_CHILD_SA 交換が同時に発生する場合のデッドロックを回避し, また, 2 つの新しい SA が整合性のない ID をネゴシエートするという可能性のある問題を回避するため, 実装は以下の規則に従わなければなりません (MUST):

  1. 元の SA の所有者は, 新しい CREATE_CHILD_SA 交換のイニシエータであり続けなければなりません (MUST)。

  2. レスポンダが, すでにそれ自身がキー再生成要求を送信した SA のキー再生成を試みる CREATE_CHILD_SA 交換を受信した場合, レスポンダはピアのキー再生成要求をそれ自身の要求より優先させなければなりません (MUST)。この場合, レスポンダはそれ自身が開始した SA を削除し, ピアによって作成された SA を使用すべきです (SHOULD)。レスポンダは新しい SPI をイニシエータに送信しなければなりません (MUST)。これにより, イニシエータはどの SPI を使用するかを知ります。

  3. 任意の時点で, 同一の元の SA に関連しアクティブな SA は 2 つより多くすべきではありません (SHOULD NOT)。

同時キー再生成を回避するため, 実装はキー再生成交換を開始する前にランダムな時間待機してもかまいません (MAY)。それ自身がまだキー再生成を開始していないときに, ピアによって開始されたキー再生成要求を受信した場合, それはピアの要求をそれ自身の要求より優先させるべきです (SHOULD)。