要約

  • RFC 5418 は、無線端末、AAA サーバー、アクセスコントローラー、Wireless Termination Point（WTP）の間にある複数の二者間関係として CAPWAP の安全性を説明する。隣り合う接続ごとに認証しても、全経路の認可が自動的に成立するわけではない。
  • 事前共有鍵を使うと、装置クラス単位の広い認可になり得る。鍵を持っているだけでは、アクセスコントローラー（AC）と WTP を常に区別できない。
  • 正規の証明書、保護された制御チャネル、特定の導入先から認可された装置であることは、別々に検証する必要がある。

移行時に確かめるべきなのは、証明書の有効性だけではない

支店のコントローラーを入れ替えるとき、新しい証明書の検証に成功しても、どの WTP にその AC への接続を許可したかは別の登録判断として残る。接続を確立できることと、その装置が特定の導入先で役割を担ってよいことは同じではない。RFC 5418 はこの二つを混同しないための脅威分析である。

RFC 5418 は、その分岐を具体的に捉えた 2009 年の Informational 文書である。独立したアクセスポイントの機能を、無線側の Wireless Termination Point（WTP）と、別の場所に置く Access Controller（AC）へ分割した場合の露出を分析する。従来は一台の装置の内部にあったやり取りが、Layer 3 のネットワークを横断する。安全性は、そのネットワークと機能分担の仕方に左右される。

対象範囲は CAPWAP と IEEE 802.11 の脅威分析だ。製品導入の調査でも、攻撃の事例報告でも、Internet Standard でもない。価値は、構成図が隠しやすい問いを分解する点にある。対向装置は誰か。どの役割を与えるのか。どの鍵を渡すのか。利用者のデータは実際にはどこを通るのか。

本稿の編集上の視点は、Heng Lu の Note 65「Running-Code Primacy」から採る。主張を、システムが実際に動かす仕組みや運用者が確かめられる証拠と照合する、という方法である。同ノートはインターネット調整システムの設計論であり、無線セキュリティの規範ではない。ここでは、図や方針を、装置のID、役割確認、制御器の関係、転送経路の実証に置き換えないという意味で用いる。

CAPWAP が増やす二者間の信頼

従来型のアクセスポイントは、一台で無線端末と有線ネットワークをつなぐ。CAPWAP は機能を分け、WTP が無線通信を担い、AC が管理と有線側の機能を担う。集中管理や拠点構成の選択肢が増える一方、信頼関係も増える。

RFC 5418 の簡略例には、少なくとも七つの関係または鍵の受け渡しがある。

手順 関係または受け渡し 例で確立されること
1 WTP–AC CAPWAP の対向関係
2 AC–AAA コントローラーから認証サービスへの認証済み接続
3 端末–AAA EAP 認証と鍵素材の生成
4 AAA → AC Pairwise Master Key のコントローラーへの配布
5 AC–端末 一時鍵を作る四者間ハンドシェイク
6 AC → WTP 暗号化を分散する場合の一時鍵の受け渡し
7 WTP–端末 クライアントの無線リンク保護

これは一本のエンドツーエンド認証ではない。RFC 5418 は各関係が二者間の信頼であると明記する。端末が AAA を信頼し、AAA が AC を信頼し、AC が WTP を信頼しても、端末がその WTP を信頼すべきだとは限らない。侵害された WTP は AC との関係を保ったまま、端末へ誤ったネットワーク情報を示す可能性がある。階層の一台が侵害されれば、その下位の装置にも影響し得る。

これは構造上のリスクを述べたもので、すべての無線ネットワークが侵害されているという意味ではない。各IDと鍵を、最終的に与える権限までたどり、装置が侵害された場合に何が実行できるのかを確かめる。

共有鍵で分かること、残る問い

RFC 5418 は認証と認可を区別する。認証は相手がIDまたは資格情報を提示できるかを問う。認可は、どのリソースや操作を許すかを決める。

事前共有鍵について、文書は認可が広く粗くなり得ると説明する。鍵を知る装置は、その鍵に結び付いたクラスの信頼を得る。クラスごとに鍵を分ければ区分けはできるが、その鍵だけでは保持者が AC か WTP かを証明できない場合がある。同じ秘密を両方の役割が利用できるなら、別の検査がない限り、鍵を得た装置はどちらの役割も申告し得る。

秘密が台帳の想定より多くの場所に流出していると、影響は広がる。工場での初期設定、作業メモ、コントローラー設定、交換機器の手順に同じ鍵が複製されれば、それは一台の装置の属性ではなく、複数の装置を動かす共通の権限になる。誰が取得できるか、装置クラスが実際に分かれているか、どのように更新するか、受け手が申告ロールを検査するかが評価点だ。RFC 5418 は特定の運用者がそのように鍵を扱うとは述べていない。各組織が確認すべき統制項目である。

証明書なら、より細かな確認ができる。ただし「証明書がある」ことは完全な登録方針ではない。RFC 5418 は、装置の MAC アドレスを含む主体名と、AC/WTP の役割を分ける Extended Key Usage を挙げる。相手がその主体名を自社の導入対象と照合し、鍵用途を厳密に検査して初めて役に立つ。汎用の任意拡張用途を許すと、追加の名前検査がなければ役割の区別が崩れる可能性がある。

メーカー発行の証明書が示すのは、資格情報の発行元だ。WTP がこの導入先でどの AC を受け入れるか、AC がどの WTP を自社ネットワークの構成員と見なすかまでは決めない。RFC 5418 は、証明書による認可とゼロタッチ構成は完全には両立しないと指摘する。正しい AC と WTP を互いに識別できることは分析の前提であり、その選択方法は対象外だ。調達やセキュリティ審査でも、この前提を見失ってはならない。

AAA にも別の責任者がいる

簡略例では AC が認証器となり、RADIUS または Diameter で AAA サーバーと通信する。RFC 5418 は、AC–AAA 間で長期間使う資格情報が非一意または低エントロピーであれば、CAPWAP 環境全体の安全性に影響し得ると警告する。機密性と完全性を備えた相互認証を勧め、AAA の鍵管理について RFC 4962 を参照する。

これは WTP–AC と異なる関係の保護である。正しい WTP–AC の DTLS セッションは、AC が接続する AAA サーバーを自動で確認しない。端末と AAA が強い EAP を使っても、期待した AC だけが後続の鍵素材を受け取る証明にはならない。無線のハンドシェイク成功も、正しい WTP に鍵が渡った証拠ではない。各資格情報と認可判断に責任者を置く必要がある。

この問題には組織面もある。無線チームは装置の登録を、セキュリティチームは証明書を、ID チームは AAA を担当するかもしれない。各チームが「自分の接続は保護されている」と報告しても、その保証の接点が確認されていない場合がある。各信頼関係について、発行者、検証者、付与する役割、導入先の構成員であると示す記録を結び付けるとよい。

制御トンネルはデータ経路ではない

ID と鍵の流れだけでネットワーク全体は分からない。RFC 5418 は制御とユーザーデータの転送を分け、Split MAC、Local MAC などの構成を説明する。Local MAC では WTP が MAC 処理の大部分を担い、データフレームは通常、現地でブリッジされる。CAPWAP の用語だけで、データトンネルの選択は決まらない。

RFC 5415 が示すプロトコル上の境界は明確だ。WTP が候補コントローラーを探す Discovery Request と Discovery Response は平文であり、それ以外の制御メッセージは DTLS を使用する。データパケットの保護は任意で、AC の方針に従う。したがって制御接続が保護されているだけでは、利用者データが AC を通るのか、別の保護されたデータチャネルを通るのか、現地で有線ネットワークへ渡るのか分からない。

経路の選択は、制御を適用する場所も動かす。集中転送ならコントローラーを制御点にできるが、経路と依存先が増える。現地ブリッジは遠隔コントローラーまで全通信を戻さずに済む一方、分離、検査、監視をエッジ装置と接続先の有線網に委ねる。どちらが常に優れるという話ではない。実際の経路が、方針と事故対応計画の前提に合うかを確認すべきだ。

暗号化にも限界はある。RFC 5418 はリソース枯渇、受動的な傍受、トラフィック分析、経路上でのパケット破棄を扱う。DNS/DHCP の偽装や ARP キャッシュ汚染など、CAPWAP の範囲外にある攻撃も挙げる。これは DTLS の有用性を否定するのではなく、DTLS が守る部分と別の責任者が守る部分を分ける。

チェック欄ではなく、信頼関係を追う

有効な CAPWAP 審査は実際のトポロジーから始め、次を確認する。

  1. 各 WTP が受け入れる AC はどれか。導入先の一部だとどう確認するか。
  2. 各 AC が受け入れる WTP はどれか。装置ロールをどう区別するか。
  3. 共有鍵は用途に対して十分に限定されているか。誰が参照、設定、更新、失効できるか。
  4. AC と WTP は証明書の名前と役割を実際にどう検査するか。有効な証明書でも許可台帳にない装置はどう扱うか。
  5. AC が AAA に使う資格情報は何か。鍵の受け渡しと認可判断はどこに記録されるか。
  6. クライアントデータは AC を経由するか、現地でブリッジされるか。暗号化、分割、検査、ログはどこにあるか。
  7. DTLS でも残る資源枯渇、トラフィック分析、パケット破棄、ディスカバリー操作、隣接 LAN への攻撃は何か。

こうした質問によって、「無線 LAN は証明書を使っている」という一文を検証可能な判断に分解できる。アクセスポイントの交換時にはメーカー署名だけでなく、台帳とロール認可も更新する。支店を現地ブリッジへ移すなら、政策適用と監視計画もパケットとともに移す。AC–AAA 鍵の更新によって WTP–AC の識別が壊れたり、予備経路が塞がれたりしないかも確認する。

文書の限界は保つ

RFC 5418 は、2009 年当時の CAPWAP と 802.11 の脅威分析である。暗号の例や用語を現在の設定手順として流用してはいけない。RFC 5415 は CAPWAP プロトコルを定義し、RFC 5418 はアクセスポイント機能の分割が生む露出を分析する。どちらも今日の製品仕様、特定ネットワークの設定、実際の事故を証明しない。

今も役立つ視点は限定的だ。保護された通信路は信頼グラフの一本の辺にすぎない。鍵のアイコンが何個あるかではなく、受け入れたIDが正しい導入先、役割、権限に結び付いているか、クライアントのデータが組織の想定どおりの経路を通るかが問われる。資格情報を持つことと、それで開くシステムを統制することは同じではない。

出典