要約

  • RFC 5419は、ホームAAAを通じてMobile IPv6のBinding Updateを認証したいという当時の理由を残す一方、AAAからHAへ鍵を渡す手順をIETF共通の契約として定めてはいない。
  • 文書は、RADIUSを使う具体例と、MN–AAAアソシエーションからMN–HAの鍵・セキュリティアソシエーションを作る標準手順を明確に分けている。
  • 後発のRFC 4877はIKEv2/IPsecの経路を示し、初期の主張の一部を弱めた。2009年の説明だけから、現在の導入状況は判断できない。

Binding Updateだけでは信頼関係は完結しない

Mobile IPv6では、端末は別のネットワークへ移動してもホームアドレスを保てる。モバイルノード（MN）はHome Agent（HA）へBinding Update（BU）を送り、現在の到達先となるCare-of Addressを知らせる。HAはこのバインディングを保持し、パケットをトンネルで転送できる。基本設計では、MNとHA間のシグナリングをIPsecのセキュリティアソシエーションで保護する。両端は決まっている。運用上の問いは、加入者を管理する権限が別の仕組みにあるとき、両端がどうすれば一致する鍵を得られるかだ。

2009年1月発行のRFC 5419は、RFC 4285の認証オプションを必要とした理由を保存するInformational文書である。代替方式はIPsecを廃止するものではない、と明記している。例に登場するCDMA2000とWiMAXは、執筆者が当時説明したネットワーク構成だ。既存のホームAAAで加入者を認証し、加入者プロファイルを再利用し、ホームアドレスやHAを動的に割り当てたいという要件があった。これは文書に記録された当時の設計要件であり、現在のネットワークを測った結果ではない。(RFC 5419, §§1, 5)

RFC 4285は二つの関連オプションを定義する。MN–AAAオプションは、MNとホームAAAサーバーが共有するモビリティ用セキュリティアソシエーションに基づき、BUを認証する。一方、HAから返すBinding AcknowledgementにはMN–HAオプションを使わなければならない。RFC 4285によると、HAは認証済みチャネルを介して外部のホームAAAエンティティに認証を委ねるが、HAとAAAの具体的な連携方法は文書の対象外だ。要求を認証する状態と、応答を検証するためHAが持つ鍵の状態は、関連していても別のものになる。(RFC 4285, §5.2)

RADIUSの例が示す、仕様の境目

RFC 5419のCDMA2000の例では、HAが認証情報をRADIUSサーバーへ渡す。AAAはBUを検証し、MN–AAA共有秘密とタイムスタンプからセッション鍵を算出する。それをAccess-Acceptの3GPP2定義ベンダー固有属性でHAに返す。HAはこの鍵をMN–HAセキュリティアソシエーションに結び付ける。例で使われるSPIは5だ。HAはそのアソシエーションでBinding Acknowledgementを認証し、MNも同じ鍵を計算して応答を確かめ、後続のBUに利用する。(RFC 5419, §6.2)

この流れから、制御点が分かれていることが分かる。加入者認証の起点はMNとAAAが共有する資格情報だが、その後のHAシグナリングにはMNとHAが使える鍵が要る。例は、特定のネットワークプロファイルでセッション鍵を役割間に渡す方法を示す。そこで使われるRADIUS属性は3GPP2の定義であり、RFC 4285が定める普遍的な属性ではない。

続く制約の記述は明快だ。RFC 4285は、MN–AAAアソシエーションからMN–HA共有鍵とSAを作る仕組みを規定しておらず、IETF標準外の運用固有の手段に依存する。RFC 5419は、Mobile IPv4向けに鍵生成nonceと導出手順を規定したRFC 3957と対比する。これはRFC 4285が動作しないという意味ではない。相互運用性の契約がどこで終わるか、という説明だ。図に鍵の受け渡しが描かれていても、導出方法、本人との結び付け、鍵の適用範囲、配送手順までが他の実装へ持ち運べるとは限らない。(RFC 5419, §7; RFC 3957, §5)

ここでの批判は限定的である。RFC 4285の認証オプションが自動的に欠陥になるわけではなく、運用プロファイルで詳細を決められる。ただし詳細が各環境に委ねられるなら、MN、AAAサービス、RADIUS属性、HA、そして加入者と動的に選ばれたHAを結び付ける仕組みのどれがそのプロファイルに従うのかを、運用者は把握しなければならない。メッセージ形式だけでは、連鎖全体の整合性は確認できない。

理由を記録する間にも、前提は変わった

RFC 5419は発行時期の変化を隠していない。RFC 4877は2007年に公開され、IKEv2と改訂IPsecアーキテクチャを使うMobile IPv6の動作を規定した。RFC 5419自身が、IKEv2はAAAバックエンドとの連携を改善し、RFC 4285を正当化した初期の理由の一部を不要にしたと述べている。また、RFC 5026などの作業によって、動的なホームアドレスやHAのブートストラップも扱われた。したがって2009年の説明は、唯一の選択肢についての時代を超えた判断ではない。(RFC 4877; RFC 5026; RFC 5419, §§1, 5, 9)

残った論点はより限定される。執筆者は、対象にした環境の一部の端末がIKEv2に対応しない可能性、無線区間では追加の往復が意味を持つこと、運用者が加入者識別とサービス選択を既存のAAAモデルに置きたいことを挙げた。これは2009年の対象環境についての記述だ。現在の端末がどの程度IKEv2を実装するか、当該ネットワークが稼働しているか、どの方式を選ぶべきかは示していない。

認証オプション側にも条件がある。RFC 5419は、ルート最適化には別の保護が必要になること、オプションに暗号アルゴリズムのネゴシエーションがないこと、リプレイ対策のタイムスタンプには十分な時計同期が要ること、長期のNetwork Access Identifierが見える場合のプライバシー問題を挙げている。MN–AAAアソシエーション自体も帯域外で確立する。これらはプロファイルが扱うべき条件であって、方式全体を無効とする証拠ではない。(RFC 5419, §7)

規格、設計例、稼働実態を混同しない

ここには三つの異なる証拠がある。RFC 4285はオプション形式と処理を定める。RFC 5419は歴史的な理由とRADIUSの例を残す。RFC 3957はMobile IPv4の鍵導出手順を比較対象として示し、RFC 4877はIKEv2/IPsecの代替経路を記述する。これらから、特定のネットワークがどの実装を採用したか、また現在どのプロファイルが動作しているかは分からない。

運用者が設計を見直すなら、共有秘密の発生源、セッション鍵を加入者と選択済みHAに結び付ける方法、鍵を運ぶRADIUS属性、両端での有効期限とリプレイ状態の合わせ方、そしてAAAが受理してもHAが期待するSAを作れなかった場合の挙動を確かめたい。答えがベンダー固有のプロファイルにあるなら、それはセキュリティ設計の一部として版管理・試験・移行の対象になる。IKEv2を使う場合も、規格が公開されているというだけでなく、実際の端末とHAのバージョンでAAA連携が機能することを確かめる必要がある。

RFC 5419の教訓は、どちらかの認証オプションが勝ったという話ではない。加入者に対する中央の判断と、MN–HA間の暗号関係は別々のインフラ要素だ。標準化された交換、明示的な運用プロファイル、または別の鍵管理プロトコルで結べる。ただし「認証済み」という表示だけでは、鍵が正しい相手に届いた証拠にはならない。

出典