2.8. Rekeying (再鍵化)
2.8. Rekeying (再鍵化)
IKE, ESP, AH の Security Association (SA) が用いる秘密鍵は, 限られた時間とデータ量にのみ使うべきである. これが SA 全体の生存期を制限する. 生存期が満了した SA は使用してはならない. 需要があれば新 SA を確立してもよい. 期限切れ SA に代わる SA の再確立を "rekeying" (再鍵化) と呼ぶ.
最小 IPsec 実装のため, 全体 IKE SA を再起動せず SA を再鍵化する能力は任意である. 実装は IKE SA 内の CREATE_CHILD_SA をすべて拒否してもよい. SA が期限切れまたは切れかけで, ここに述べる機構による再鍵化が失敗したら, 実装は IKE SA と関連 Child SA を閉じなければならず, その後新規に開始してもよい. 実装はその場再鍵化を望むかもしれない (性能が良く移行中の損失パケットが減る可能性がある).
既存 IKE SA 内で Child SA を再鍵化するには, 新しい同等 SA を作成し (下記 2.17 節), 新 SA が確立したら古いものを削除する. 再鍵化時, 新 Child SA は古いものと Traffic Selector やアルゴリズムを変えてはならない.
IKE SA を再鍵化するには, 既存 IKE SA 内の CREATE_CHILD_SA で旧 IKE SA を共有するピアと新しい同等 IKE SA を確立する (下記 2.18 節). こうして作られた IKE SA は元の IKE SA のすべての Child SA を継承し, 新 IKE SA がそれらの維持に必要な制御メッセージに用いられる. 新同等 IKE SA 作成後 initiator は旧 IKE SA を削除し, 自分自身を削除する Delete ペイロードは旧 IKE SA 上で送る最後のリクエストでなければならない.
SA は能動的に再鍵化すべきである. つまり旧 SA が期限切れで使えなくなる前に新 SA を確立する. 新 SA 確立から旧 SA が使えなくなるまで十分な時間を空け, トラフィックを新 SA に切り替えられるようにする.
IKEv1 と IKEv2 の違いの一つは, IKEv1 では SA 生存期を交渉したことである. IKEv2 では SA の各端が自らの生存期ポリシーを執行し必要なら再鍵化する. 両端のポリシーが異なれば, 短い方が常に再鍵化を要求する側になる. SA が長期非アクティブで, トラフィックがなければ端点はその SA を開始しなかったであろう場合, 生存期満了時に再鍵化ではなく閉じることを選んでもよい. 前回再鍵化以降トラフィックがなければ同様である.
IKEv2 は意図的に同一端点間で同一 Traffic Selector の SA を並行させうる. 目的の一つは SA 間の QoS 差のサポートである ([DIFFSERVFIELD], [DIFFSERVARCH], [DIFFTUNNEL] の 4.1 節). したがって IKEv1 と異なり端点と Traffic Selector の組が SA を一意に特定しないことがあり, 重複 Traffic Selector に基づく IKEv1 の再鍵化ヒューリスティックは使うべきではない.
特にパケット損失があると, 端点が SA の状態で一致しない時間窓がある. CREATE_CHILD_SA の responder は作成リクエストへのレスポンスを送る前に SA 上のメッセージを受け入れる用意がなければならず, initiator に曖昧さがない. initiator はレスポンスを処理し次第 SA 上で送信を始めてもよい. しかし initiator は CREATE_CHILD_SA レスポンスを受信・処理するまで新規 SA 上では受信できない. では responder はいつ新 SA 上で送ってよいか.
技術的正しさと相互運用性の観点から responder は CREATE_CHILD_SA レスポンスを送り次第 SA 上で送信を始めてもよい. しかし状況によってはパケットが無駄に落ちうるため, 実装は送信を遅らせてもよい.
responder は (1) SA ペアのもう半分で暗号的に有効なメッセージを受信したか, (2) 新 SA が既存を再鍵化し置換 SA を閉じる IKE リクエストを受信したかのいずれかで, initiator がその SA で受信準備できたと確信できる. SA 再鍵化時 responder は上記のいずれかまで旧 SA でトラフィックを送り続ける. 新 SA 確立時 responder は相手からの 1 パケットまたはタイムアウトまで新 SA 上の送信を遅らせてもよい. initiator が CREATE_CHILD_SA レスポンス前に SA 上でメッセージを受信したら, おそらく損失と解し CREATE_CHILD_SA を再送する. キューにメッセージがなければ initiator は新 ESP SA 上にダミー ESP を送り, 受信準備ができたことを responder に確信させてもよい.
2.8.1. Child SA の同時再鍵化
両端の生存期ポリシーが同じなら, 同時に再鍵化が始まり冗長 SA になりうる. 確率を下げるため, 再鍵化が必要と分かった後ランダム遅延でジッターを入れるべきである.
この再鍵化は同じノード対の間に一時的に複数の類似 SA を生む. 受信に使える SA が 2 つあれば, ノードはどちらの SA でも着信を受け入れなければならない. 衝突で冗長 SA ができた場合, 2 交換で使った 4 つの nonce のうち最小で作成された SA は作成側が閉じるべきである. "最小" はオクテット列比較である (大整数比較ではない). 最初のオクテットから比較し等しければ次へ. 一方の nonce が先に終わればそちらが小さい. 生存する再鍵化 SA を開始したノードは新 SA 確立後に置換された SA を削除すべきである.
実装への影響の説明. ホスト A と B が SPI (SPIa1,SPIb1) の Child SA 対を持ち同時に再鍵化を始めるとする:
Host A Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2
recv req2 <--
この時点で A は同時再鍵化を知るが, どちらの交換が最小 nonce かはまだ分からないので記録して通常応答する.
send resp2: SA(..,SPIa3,..),
Nr1,.. -->
--> recv req1
B も同時再鍵化を知り, 通常応答する.
<-- send resp1: SA(..,SPIb3,..),
Nr2,..
recv resp1 <--
--> recv resp2
この時点で A と B の間に 3 対の Child SA がある (旧 1 対と新 2 対). nonce を比較する. resp2 の Nr1 が最小なら, B (req2 送信者) が冗長な新 SA を削除し, A (生存再鍵化 SA を開始した側) が旧 SA を削除する.
send req3: D(SPIa1) -->
<-- send req4: D(SPIb2)
--> recv req3
<-- send resp3: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->
再鍵化完了.
ネットワーク損失で再送が起きると別シーケンスもありうる. 再鍵化は同様に始まるが A の最初のパケット (req1) が失われる.
Host A Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),
Ni1,.. --> (lost)
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2
recv req2 <--
send resp2: SA(..,SPIa3,..),
Nr1,.. -->
--> recv resp2
<-- send req3: D(SPIb1)
recv req3 <--
send resp3: D(SPIa1) -->
--> recv resp3
B から見ると再鍵化は完了し, A の req1 は未受信のため同時再鍵化を知らない. しかし A は再送を続け最終的に B に届く.
resend req1 -->
--> recv req1
B からは A が既に存在しない SA を再鍵化しようとしているように見える. したがって CHILD_SA_NOT_FOUND など非致命的に応答する.
<-- send resp1: N(CHILD_SA_NOT_FOUND)
recv resp1 <--
A はこのエラーで既に同時再鍵化を知っているなら無視できる.
2.8.2. IKE SA の同時再鍵化
両ピアが同時に IKE_SA を再鍵化しようとするのは最も複雑なケースの一つである. 基本的に 2.8 節の記述が当てはまるが, Child SA が正しい IKE_SA を継承することが重要である.
両端点が同時再鍵化に気づく場合は Child SA と同様である. CREATE_CHILD_SA の後, A と B の間に旧 IKE SA と新 IKE SA 2 つがある. 最小 nonce を含む新 IKE SA は作成者が削除すべきであり, 残る新 IKE SA はすべての Child SA を継承しなければならない.
通常の同時再鍵化に加え, 一方が他方の再鍵化に気づく前に自らの再鍵化を終える特別なケースがある. 一方だけが同時再鍵化を検出した場合冗長 SA はできない. 同時再鍵化に気づかなかったピアが, 既に成功裏に再鍵化した IKE SA の再鍵化リクエストを受け取ったら, (削除通知を送済みかどうかにかかわらず) 閉じようとしている IKE SA であるため TEMPORARY_FAILURE を返すべきである. 同時再鍵化に気づいたピアが相手から旧 IKE SA の削除リクエストを受け取れば, 相手は同時再鍵化を検出しなかったことが分かり, 先に気づいた側は自らの再鍵化試行を忘れてよい.
Host A Host B
-------------------------------------------------------------------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
--> recv req3
この時点でホスト B は IKE_SA 閉鎖リクエストを見る. 通常どおり応答する以外にほとんどない. ただし B はここで req2 の再送を止めるべきである. A が resp3 を受信すると旧 IKE_SA の状態をすべて削除し req2 に答えられなくなるからである.
<-- send resp3: ()
TEMPORARY_FAILURE は RFC 4306 になく, 交渉もされない. したがって本書を実装しない RFC 4306 のみのピアがこれを受け取りうる. その場合未知エラー通知と同様に扱い交換を止める. 相手は既に再鍵化済みなので害はない.
2.8.3. IKE SA 再鍵化と再認証
IKEv2 では IKE SA の再鍵化と再認証 (reauthentication) は別概念である. 再鍵化は IKE SA の新鍵を確立し Message ID カウンタをリセットするが, 当事者を再認証しない (AUTH や EAP ペイロードはない).
IKE SA 再鍵化が重要な環境もあるが, 長期資格情報へのアクセスを再検証する再認証の方がしばしば重要である.
IKEv2 は再認証を特別サポートしない. 再認証はゼロから新 IKE SA を作る (REKEY_SA Notify なしで IKE_SA_INIT/IKE_AUTH), 新 IKE SA 内に新 Child SA を作り (REKEY_SA なし), 最後に旧 IKE SA を削除する (旧 Child SA も削除).
再認証も IKE SA と Child SA の新鍵を確立する. したがって再鍵化は再認証より頻繁にできるが, "認証生存期" が "鍵生存期" より短い状況は意味をなさない.
新 IKE SA の作成は元 IKE SA の initiator または responder のどちらからでも始められるが, EAP や Configuration ペイロードの使用により実際には元と同じ側から再認証を始める必要がある. IKEv2 は現状この場合 responder が再認証を要求することを許さないが, [REAUTH] など拡張で追加されている.