要約

  • RFC 6345 の中継装置は、端末ごとの状態を保持しなくても動作できる。一方、認証エージェントは返信に使う中継装置のアドレスとポートをセッションに保持する。
  • 認証内容の保護と、その内容を運ぶ経路の可用性は別の問題だ。中継側の負担が小さいことは、相手の設定、再送処理、残存リスクへの対処が不要なことを意味しない。
  • 調達で比較すべきなのは一台の記憶容量だけではない。どこに情報が残り、誰が変更でき、障害時に誰が正常な往復を取り戻すのかまで含めて判断する必要がある。

接続の前に届かなければならないもの

ネットワークに参加してよいかを確認するための通信が、参加後の経路を前提にしていたら困る。認証を済ませるまで通常の通信ができない端末にも、認証相手へ情報を届ける手段は要る。PANA の中継仕様は、この小さく見えて厄介な順序の問題を扱っている。

RFC 6345 が挙げる例では、参加しようとする IPv6 端末はリンクローカルアドレスを使い、親ノードが、離れた認証エージェントへの中継を担う。これは仕様上の構成例であって、実際の普及率や特定製品の採用実績を示すものではない。それでも設計上の選択は明瞭だ。認証を必要とする端末に、まだ利用できない通常の IP 経路を要求せず、別の装置に橋渡しをさせる。

登場する役割を分けておこう。端末側が PaC、認証のやり取りを受け持つ側が PAA、中継装置が PRE である。PRE は PaC から見ると PAA のように振る舞うが、認証そのものを肩代わりするわけではない。端末から受けた PANA メッセージを別の包みに入れ、設定された PAA へ渡す。

この PRE は、PaC ごとの状態を保持する必要がない。限られた資源しか持たない装置には魅力的な性質である。ただし「状態を持たなくてよい」の目的語は、あくまで端末ごとの状態だ。接続相手の設定も、受信したパケットの処理も、運用者の判断も一切不要になる、という意味ではない。調達資料で修飾語が落ちると、技術上の長所が、その設計では約束していない経費削減へとすり替わる。

記憶を省いた側と、記憶を増やした側

往復を成立させる仕組みを見ると、省かれた仕事の行き先が分かる。PRE は PRY という中継用メッセージを使う。その中の Relayed-Message には、元の IP ヘッダーと UDP ヘッダーを除いた PANA メッセージを入れる。端末の IP アドレスと UDP ポートは、別の PaC-Information に格納する。

PAA にとって、内側に入っている端末の座標だけが手掛かりではない。初期のやり取りを識別する際には、端末と中継装置の双方の座標を用いる。また、返信をどこへ返すかを知るため、PRE の IP アドレスと UDP ポートを追加のセッション属性として保持する。端末が中継を意識せず認証を続けられる裏側で、PAA が戻り先を覚えている。

これは単に「端末側の費用をすべて中央へ移した」という話でもない。中継装置では端末ごとの状態割り当てを省けるが、パケットの処理は続く。PAA には追加の記憶が必要になり得る。接続相手の設定や障害対応は、装置の記憶容量とは別の負担である。どこで何が減り、どこで何が増えるかを個別に確かめなければ、全体の増減は言えない。本稿の資料から、その金額や性能差を算出することはできない。

設計の価値を否定する必要はない。端末の増加に応じて各 PRE にセッションを持たせなくて済むこと自体は、明確な利点である。問題は、その利点を評価するときに、PAA のセッション管理と運用上の引き受け手まで視界から消してしまうことだ。部品の簡素化と、サービスの責任範囲の縮小は同じではない。

訂正された一つの参照先

戻り道の扱いは、仕様の訂正にも表れている。技術的な正誤情報 2996 は、PRE が端末へ返信するときの UDP 宛先ポートを、どこから取得するかを修正した。正しい参照先は PaC-Information であり、元の文にあった Relayed-Message ではない。

この訂正は 2011 年 10 月 13 日に報告され、2012 年 9 月 7 日に確認された。新しい認証方式を追加したものでも、暗号鍵の所有者を変えたものでもない。返信に必要な情報の置き場所を正したのである。内側の PANA メッセージには元の UDP ヘッダーを入れない、という構造と合わせて読むと、なぜ参照先が重要なのかが分かる。

ここから導ける実務上の教訓は、特定の実装に不具合があったという断定ではない。そのための検証資料はない。むしろ、装置の評価に「この RFC に対応する」という一行だけを用いると、訂正を含む挙動の確認が抜け落ちる、ということだ。仕様の名前を知っていることと、返信を組み立てる際の情報の出所を説明できることには距離がある。

RFC Editor の記録 では、RFC 6345 は 2011 年 8 月の Proposed Standard である。日付と位置付けを示すのは、古い仕様を現在の製品保証に見せないためでもある。文書の存在は設計の根拠になるが、ある機器で訂正が反映されたか、あるネットワークで適切に運用されているかまでは証明しない。

再送しない外側にも、再送を担う内側がある

PRY の外側の Session Identifier と Sequence Number はゼロになる。PRE と PAA は、この PRY 自体を再送しない。それだけを見ると、中継には再送の面倒がないように思える。

しかし、内側の PANA メッセージは別である。端点側で再送が起きれば、中継装置はそのメッセージを新しい PRY に包んで運ぶ。外側に独自の再送機構を重ねないことと、認証のやり取りから再送や順序管理がなくなることは違う。

RFC 5191 は、PANA のセッションやメッセージの検証、再送を端点側の仕事として扱う。加えて、PaC と PAA、必要に応じたバックエンド AAA、アクセスを実際に制御する enforcement point を区別する。PAA と制御点が別なら、両者間の設定情報の受け渡しにも、認証、完全性、リプレイへの保護が必要になる。

したがって、PRE だけを見て「簡単な機械だから復旧も簡単」と判断するのは早い。中継を交換しても、PAA が保持するセッションや戻り先、端点のやり直し、実際のアクセス制御との関係が残る。これらは本稿が観測した障害ではなく、構成の責任分界を考えるときに確認すべき論点である。どの装置が状態を持つかを明示しておけば、障害時の調査が装置の販売単位だけで分断されるのを避けやすい。

認証できない攻撃者にも、通信を妨げる余地はある

認証が守られていれば、中継が安全でなくても構わないのか。RFC 6345 の安全性の議論は、そう単純ではない。仕様は、不正な PRE による転送の妨害と、正当な端末になりすまして認証を完了することを分けている。

所定の脅威モデルでは、資格情報を持たない攻撃者が、被害端末として初期認証を完了することはできない。また、鍵を生成する EAP 方式を使った認証後であれば、偽造された内側のメッセージは完全性検証に失敗する。一方で、中継の戻り先情報への干渉、遅延や破棄、処理負荷を生じさせる余地は論じられている。秘密を奪うことに失敗しても、正常な利用者の手続きを止められる可能性は残る。

この区別には条件がある。RFC 5191 における PANA SA は、MSK を得られる EAP の成功に依存する。MSK がなければ、この SA は作られない。「PANA なら内側は必ず同じように保護される」と一般化してはいけない。ここで述べているのは文書の条件付きの分析であって、個々の実装の耐性試験ではない。

運用者にとっては、認証の完全性が保たれたという説明だけでは、利用者が接続できなかった理由への回答が終わらない。本人確認の正しさと、本人が確認手続きを完了できることは、それぞれ確かめるべき品質だ。ただし、その違いを根拠に資格情報の漏えいを推定するのも誤りである。何が防がれ、何が残るかを分けるほうが、過小評価にも過剰な警告にも陥りにくい。

任意の保護を、任意の責任と取り違えない

PRE と PAA の間の暗号的な保護は、RFC 6345 のプロトコル上は任意である。しかし同じ文書は、残存するリスクへの対処として、物理的または暗号的な保護と、通信相手を制限する仕組みを扱っている。暗号保護を必須にしない設計は、何も対処しなくてよいという免除ではない。

鍵管理の記述にも注意が要る。文書は、手作業で設定する鍵管理ではそこで説明するリプレイ防御を得られない一方、事前共有秘密を使う IKE を推奨している。「事前共有鍵はすべてリプレイに弱い」と読み替えると、鍵を手で固定する方法と、事前共有秘密を使って IKE を動かす方法を混同する。なお、これは 2011 年の仕様を読むための説明であり、その暗号構成を現在の推奨設定として提示するものではない。

PRE が使う PAA は、設定されたアドレスの中から選ばれる。この中継仕様は、PRE が動的に PAA を発見する方法を定めていない。想定する中継は最大一段であり、中継メッセージを入れ子にする処理も範囲外だ。構成変更を自動で吸収する、何段でも増やせる、という期待を「状態なし」に付け加える根拠はない。

端末による相手の発見にも別の境界がある。RFC 5192 の DHCP オプションは PAA の候補アドレスを順序付きで伝え、端末はその順序で試す。一方、そのオプションを、PANA 認証が必要かどうかの交渉に使ってはならない。情報を受け取れなかったことを、認証を省略したり弱い方式に落としたりする許可に変えてはいけない。行き先を探す手続きと、通行条件を決める権限は分けられている。

見える住所が違うとき

さらに、channel binding で PAA の IP アドレスを扱う場合、端末に見える PRE のアドレスと、認証サーバー側に見える PAA のアドレスの違いを考慮しなければならない。中継が透過的に見えても、すべての観測者が同じ相手の住所を見ているわけではない。

RFC 6345 は、中継を使わないマルチホームの PAA でも似た食い違いがあり得ると指摘する。住所の違いだけで侵害と判定することも、正常な構成なら違いをすべて無視してよいと考えることも適切ではない。どの住所を何の意味で比較しているのか、説明できる必要がある。運用の負担は、ここでは記憶容量ではなく、観測結果を正しく解釈する能力として現れる。

後年の RFC 7733 は、2016 年 2 月の家庭・建物向け RPL の構成で PANA と EAP-TLS を取り上げ、親ノードが認証サーバー自身でない場合に PRE を担う形を記している。これは用途を絞った歴史的な仕様上の位置付けである。現在の家庭用機器が一般に採用しているとも、そのまま現代の暗号設定に使えるとも言えない。設計の連続性を知る材料にはなるが、市場の実測値にはならない。