要約

  • FRID は、サーバーが既存の EAP-IKEv2 コンテキストを検索するために発行する仮名 NAI である。値が一致しても、提示者がそのコンテキストの鍵を保持していることは証明されない。
  • 高速再接続では、以前のコンテキストで保護されたメッセージ 3 と 4、新しい proposal SPI、fresh な nonce、成功後の新しい MSK/EMSK が必要になる。EAP-Success の後にも認可、鍵導入、通信、サービスという別の受領証が残る。

運用データベースには三つの「ID」が並ぶ。利用者が送った FRID、完全交換で確立された Peer-ID、今回の Ni と Nr から作られた Session-ID である。三つが同じ相手に関係していても、同じ事実を表してはいない。

RFC 5106 は、IKEv2 の仕組みに基づく Experimental な EAP メソッドを定義した。完全交換では EAP サーバーが IKEv2 の initiator、EAP ピアが responder になる。アルゴリズム、Diffie-Hellman 値、nonce を交換し、暗号化された payload 内の ID と AUTH を双方が検証する。成功するまで MSK と EMSK を生成してはならない。

将来の高速再接続に備え、サーバーは成功した完全交換の中で Next Fast-ID payload を送ることができる。その中身が Fast-Reconnect-ID である。FRID は NAI 形式を使い、username 部分を仮名化し、AAA ルーティングに必要な realm を残す。

したがって FRID の役割はコンテキスト選択である。サーバーは仮名から恒久 ID とセキュリティコンテキストを引く。fresh で一意なランダム成分が推奨されるが、それは bearer credential に変えるためではない。文字列を知ることと古いコンテキスト鍵を使えることは別である。

RFC は、次回も同じ EAP サーバーに届くとは保証しない。ホームオペレーターのサーバー間で仮名解決を共有することが推奨される。共有機構がなければ、未知の仮名を受けたサーバーは恒久 ID を要求できる。この failure は主体不正の証拠ではなく、状態配置の不一致かもしれない。

ピアは、直前の成功した完全交換または高速再接続で NFID を受け取った場合だけ FRID を提示できる。高速経路でも EAP-Response/Identity は必須である。サーバーは FRID を解決した後、ローカル方針によって高速再接続か完全交換を選ぶ。ピアは FRID を出した後でも完全交換の message 3 を処理しなければならない。

このため frid_presented、context_mapped、fast_path_selected を一つの authenticated にまとめてはいけない。検索成功は候補状態の発見であり、方針決定でも鍵所持証明でもない。

高速再接続の暗号的根拠は message 3 と 4 にある。両メッセージの encrypted payload は、以前の成功したコンテキストの鍵で暗号化・完全性保護される。サーバーは proposal に新しい非ゼロ SPI を選び、fresh な Ni を生成する。KEi を含める場合も fresh でなければならない。

ピアは message 3 を復号し完全性を検証する。成功した場合、自身の新しい非ゼロ SPI と Nr を生成し、message 4 を保護する。サーバーがその応答を正しく復号・検証して初めて今回の run は成功し、EAP-Success を返せる。FRID の一致だけではこの一連の処理は一歩も完了しない。

再接続後には鍵世代が変わる。SKEYSEED は古い SK_d、Ni、Nr、必要なら新しい Diffie-Hellman 共有値から計算される。EAP-IKEv2 用の暗号・完全性鍵も再生成される。さらに KEYMAT の前半 64 octet が MSK、後半 64 octet が EMSK になる。

ここで Session-ID は method type 49 と今回の Ni、Nr を連結して作られる。一方、再接続時の Peer-ID と Server-ID は、コンテキストを最初に作った完全交換の ID を参照する。新しいセッションを作りながら主体の連続性を旧コンテキストに結び付ける設計である。

この差を失うと監査が壊れる。FRID はローテーション可能な検索キーであり、Peer-ID は認証された主体の記録、Session-ID は一回の鍵生成 run の記録である。一つの列を上書きするデータモデルでは、どの主体がどの run でどの鍵世代を作ったか復元できない。

FRID 更新にも commit point がある。サーバーが新しい NFID を送っても、ピアが保存する前に障害が起きることがある。そのためサーバーは、少なくとも直近に使用された FRID と直近に発行した FRID の両方を保持すべきである。認証が成功しなかった場合、最後に成功した交換の FRID を上書きしてはならない。

これは「送信」と「共有状態の確立」を区別する規則である。未確認の新値だけを残せば、正常なピアを次回の検索で拒否する。最新時刻ではなく、成功したプロトコル遷移が権威ある世代を決める。

replay 対策も世代に依存する。成功後に古い message 3 を再送しても、検証用鍵が変わっているため失敗するはずである。ログには FRID だけでなく、旧コンテキスト世代、SPI、Ni/Nr digest、message 3/4 の検証結果を残す必要がある。

EAP-Success は EAP メソッドの境界である。RFC 5247 が扱う key management には、authenticator や lower layer も関与する。AAA がサービスを認可したか、鍵が接続点に導入されたか、controlled port が開いたか、最初の保護通信が流れたかは別に確認する。

RFC 5106 は channel binding をサポートしないと明記する。したがって、メソッドが相互認証に成功しても、下位アクセス網の全属性や接続点の正当性まで証明したことにはならない。UI が EAP-Success を「正しいネットワークでサービス中」と表示すれば、仕様にない推論を加える。

仮名も完全匿名ではない。username は隠れても realm はルーティングのため見える。FRID の生値を長期ログ識別子にすべきではない。期間限定の digest と generation を使えば、必要な相関を保ちながら追跡面を狭められる。

2008 年の相互運用 profile と現在の暗号方針も分ける。文書には 1024-bit MODP、3DES、SHA-1 世代の transform が含まれる。歴史的 RFC への適合は、現代の導入でそれらを許可する根拠にならない。実際に選択した suite と当時の policy version を記録する必要がある。

証拠イベントには、FRID digest、realm、発行サーバー、受信サーバー、mapping 結果、context generation、fast/full 選択、新 SPI、Ni/Nr digest、DH group、message 3/4 検証、Session-ID、EAP 結果、export された key handle を含める。raw key を監視系へコピーする必要はない。

その後に AAA decision、authenticator installation、first protected packet、service probe を接続する。こうすれば context_mapped から message4_verified、EAP-Success、key_installed、traffic_observed のどの辺が欠けたかを特定できる。

高速再接続とは、識別子を信じることではない。以前の相互認証で作った状態を選び、その状態の鍵を fresh な交換で正しく使えたことを確認し、新しいセッションへ移る手続きである。

コンテキストを memory pressure で削除した場合も、FRID の文字列から状態を再生成してはならない。旧鍵と成功履歴がなければ、それは同名の空レコードにすぎない。安全な動作は full exchange へ戻り、現在の policy と credential で新しい根を作ることである。

出典