要約

  • RFC 3012は、Mobile IPv4のForeign Agentが自分で新しいチャレンジを発行し、AAAの完了前に欠落、再利用、未知の値を見分けられるようにした。
  • 正しい値を返すことは、直近のローカル状態との対応しか示さない。認証、認可、登録受理、転送状態、実際の通信には別々の証拠が必要だった。

ローミングでは、端末の居場所と資格情報の保管場所が一致しない。端末は訪問先ネットワークに現れるが、その正当性を判断できる秘密や契約はホームドメインにある。Foreign Agentは、見知らぬ端末とあらかじめsecurity associationを持たないままRegistration Requestを扱わなければならなかった。

すべてを遠隔のAuthentication, Authorization and Accountingへ送るだけでは、最初の時間差が残る。AAAの回答を待つあいだにも古い要求は再生できる。訪問先の境界には、自分の手元で発行し、自分の履歴と照合できる材料が必要だった。

2000年11月のRFC 3012は、Agent AdvertisementにChallenge extensionを入れる仕組みを定めた。値はランダムで、少なくとも32ビットが望ましい。Mobile Nodeはその値をRegistration RequestのMN-FA Challenge extensionへコピーして返す。

重要なのは値の見た目ではなく発行主体である。Foreign Agentは、自分が最近どの値を広告したかを知っている。したがって、端末のアイデンティティに結論が出る前でも、要求が自分の最近の呼びかけに対応しているかを判断できる。これはローカルな鮮度であって、身元証明ではない。

RFC 3012はその限界を拡張順序に刻んだ。MN-FA Challengeの後ろには、Mobile-Foreign AuthenticationかMN-AAA Authenticationのいずれかが必要だった。チャレンジだけを持ち、どちらの認証拡張もない登録要求は黙って破棄しなければならない。

直接のsecurity associationがあれば、Mobile-Foreign Authenticationが要求を結び付ける。なければMN-AAAを使い、RFC 2794のNetwork Access Identifierも入れることが推奨された。NAIのrealmは適切な管理ドメインへの振り分けに役立つが、その文字列だけで本人性は証明されない。

各要素は別の問いに答える。チャレンジは「どの最近値に応答しているか」、authenticatorは「どの秘密とアルゴリズムでデータが結ばれたか」、AAAは「資格情報をどう評価したか」、ポリシーは「この登録を許すか」を扱う。一つの一致が次の判断を代行することはない。

三つのエラーは履歴の違いを保存した。MISSING_CHALLENGEは必須値がない。STALE_CHALLENGEは同じMobile Nodeがすでに使った。UNKNOWN_CHALLENGEは、最後の成功応答で渡した値でも、最近のCHALLENGE_WINDOW広告に含まれる値でもない。IANAのMobile IPv4レジストリにはこれらの番号が残る。

すべてを「認証失敗」とまとめれば、構造欠落、履歴上の再利用、発行記録の不一致が区別できなくなる。RFCが与えたのは拒否のラベルだけではなく、どの状態境界で失敗したかという手掛かりだった。

ただし、ネットワークには再送がある。同じ64ビットIdentificationと同じChallengeを持つ要求が再び届き、対応するpending recordがまだ残っているなら、Foreign Agentはもう一度Home Agentへ転送できる。それ以外の再利用は通常staleとなる。

この例外は、リプレイ対策の本体が記憶であることを示す。同じバイト列でも、進行中の一取引を救う再送と、過去の権限を取り戻そうとする再生は違う。発行者、端末、値、Identification、pending期限を一緒に保持しなければ区別できない。

下流の応答にも対応関係が必要だった。チャレンジをHome Agentまで転送する場合、Foreign Agentはその値をpending状態に保存し、同じ値を含まないRegistration Replyを拒否する。これは応答が当該取引に属するというレシートであり、経路設定やアプリケーション到達の証明ではない。

MN-FAの直接関係でローカル認証を済ませ、チャレンジを除去してから転送する場合は、Identificationを記録することが求められた。次の区間で表現が変わっても、リプレイ境界を残す責任は消えない。

完全な検証はMobile IPv4の外に置かれた。付録はそれをverification infrastructureと呼ぶ。Foreign Agentは認証材料を渡し、安全な結果を待てるが、内部プロトコルや製品、運用主体までは規定しない。共通化されたのは接続面であり、管理制度ではない。

既存環境との接続のため、CHAP_SPI 2はRADIUSに近いCHAP風MD5計算を用意した。しかしセキュリティ節は、それがHMAC-MD5より弱く、可能なら避けるべきだと記した。導入を可能にする互換性は、永続的な安全性の宣言ではなかった。

DoSの余地も残った。悪意ある再送が拒否に見えるReplyを生み、その間に正当な受理応答がまだ移動中かもしれない。端末は先に届いた信号で失敗と判断し得る。ローカルな鮮度検査は、分散システム全体の時系列を整列しない。

4バイト未満の短いチャレンジでは、Identificationも保存して一意性を補うことが推奨された。「ランダム」と呼んでも不足したエントロピーは増えない。長さ、取引ID、履歴が明示条件のもとで支え合う。

2007年のRFC 4721はRFC 3012を廃止して改訂した。Foreign Agentは端末ごとに適用可能な値を記録し、すでに使った値より前に広告されたチャレンジを再利用させない。偽のReplyやAdvertisementへの対策、処理の明確化、HMAC-MD5も加わった。

この改訂から特定の侵害を推測することはできない。ただし、鮮度が順序付き履歴に依存することは明確である。誰が発行し、どの端末が使い、直前に何が受理され、どの要求がpendingで、どのauthenticatorが覆ったか。それを失ったランダム値に独立した権威はない。

RFC 2002との境界も重要だ。基本Mobile IPv4はhome addressとcare-of addressの期限付きbindingを扱った。RFC 3012はその前段、訪問先境界でのローカルな鮮度を扱う。登録受理や物理的位置、トンネル配送を証明する記事ではない。

RFC 1994のPPP CHAPとも同じではない。PPPではリンク認証のauthenticatorとpeerが交換する。RFC 3012ではForeign Agentの値をMobile IPv4登録へ入れ、別のAAA基盤が資格情報を評価し得る。計算方式の近さは統制面の同一性を意味しない。

Lu HengのMinimum Initial Specificationという視点なら、共通層をフォーマット、順序、窓、エラー、相関に限定した点が見える。検証基盤や許可方針はローカルに選べる。Running-Code Primacyは、公開RFCから特定ネットワークの実装や有効化を推測しないよう要求する。

パケットは値が戻ったことを示す。暗号ログは検証結果を示す。ポリシーログは認可を示す。Home Agent状態はbinding受理を示す。トラフィックは利用を示す。「challenge-response」という一語でこれらを圧縮してはならない。

ゲートウェイは、自分で確立できる事実のためにチャレンジを出した。信頼はまだ別のシステムから届く必要があった。その未完成さを隠さなかったことこそ、RFC 3012の歴史的な精度である。

Sources