要約

  • EAP方式が相手を正しく認証しても、ポリシー、AAA属性、認証装置の動作、鍵配送、下位層のデータ経路はそれぞれ失敗しうる。
  • 監査可能な記録は、方式の交換、EAP結果、RADIUS応答、認可判断、鍵、安全な関連付け、制御ポート、最初の通信を別の証跡として残す。

利用者が「認証できない」と訴える場面で、実際には認証が成功していることがある。バックエンドは資格情報を受け入れたが、同時接続数の制限が認可を拒んだ。Access-Acceptは届いたが、アクセスポイントは指定されたVLANに対応しなかった。鍵は生成されたが、リンクを守る関連付けまで届かなかった。ひとつの成功表示では、この違いを扱えない。

RFC 3748は2004年、Extensible Authentication ProtocolをStandards Trackで定義した。Bernard AbobaはLarry Blunk、John Vollbrecht、James Carlson、編集者Henrik Levkowetzと並ぶ著者である。個人の単独発明として扱うべきではない。重要なのは分業であり、EAPは複数の認証方式を運ぶ枠組みであって、ネットワーク認可と接続性の全工程ではない。

peerはリンク上で応答する。authenticatorはEAPを開始し、ローカルな接続点を制御する。EAP serverが方式を終端する。pass-through構成では、serverは遠いAAAバックエンドに置かれ、authenticatorは内容を理解しないままメッセージを中継できる。資格情報を検証する主体とデータ経路を開く装置は同じとは限らない。

RFC 3748は、認証されたpeerでもセッション上限などの認可ポリシーで接続を拒まれることがあると明記する。AAA proxyも判断に影響する。方式内部の保護された結果が示すのは、その方式の両端が何を確認したかである。割り当てるサービス、VLAN、機器の能力、制御ポートの状態は別の判断だ。

EAP Successが持つ情報は少ない

方式が成功裏に完了すると、authenticatorはCode 3のEAP Successを送る。このパケットに追加データはなく、確認応答も再送もない。失われた場合、条件を満たす下位層の成功表示からpeerが成功を推定できることもある。最後の一パケットだけを見ても、セッション全体は復元できない。

方式がまだ終了を許していない状態で、接続直後に送られた既製のSuccessは破棄される。偽のauthenticatorが方式の会話を飛ばすことを防ぐためだ。結果コードは直前の方式状態と結び付けて解釈する必要がある。

EAP Successには認可属性、鍵の導入、制御ポートの開放、IP設定は記録されない。アプリケーションの最初の通信が通ったかどうかも分からない。これらは後続の証跡で確認する。

RADIUSは別の欄で接続を決める

AbobaとP. CalhounのRFC 3579は、RADIUSがEAPを運ぶpass-through構成を定める。NASはAccess-AcceptかAccess-Rejectを受け取るまで対話を中継する。接続制御はRADIUSのパケット種別だけに基づけ、内部のEAPパケットを根拠にしてはならない。

Access-Rejectの中にEAP Successが入る組合せは矛盾しており、送るべきではない。それでも届けば、NASは接続を拒み、peerは認証に成功したと考える可能性がある。Access-AcceptとEAP Failureなら逆の分裂が起きる。NASは不一致を隠すためのEAPパケットを作ってはならない。両方の結果を残して異常として扱うべきである。

Access-Acceptが終えるのは認証段階である。VLAN、フィルター、サービス、上限などの指示も含みうる。NASが既知のサービスを実装していなければ、失敗が正しい。バックエンドは機器の能力に合わせて異なる認可を返せるため、同じ資格情報が場所ごとに同じ接続を保証するわけではない。

鍵を出力しても通信路は完成しない

Aboba、Dan Simon、P. EronenによるRFC 5247は、EAP方式、鍵の転送、下位層のsecure associationを分ける。方式がMaster Session Keyを出力しても、それは中間成果にすぎない。AAAが正しいauthenticatorへ材料を届け、下位層が実際の通信鍵を導出、導入する必要がある。

「MSKあり」という記録では、受信者、鍵の範囲、セッション識別子、一時鍵、導入結果が欠ける。関連付けが完了したことも証明しない。トンネル方式の内側と外側でpeerやserverの識別子が異なる場合もあり、peerは開始前に接続先のバックエンドserverを知らないことがある。

RFC 3748は、EAP後のデータ保護を認証を終えた主体に結び付けるよう求める。パケットごとの完全性、認証、リプレイ防止が派生鍵と結合されなければ、正しい認証記録の後でもデータは改変、偽造、再送されうる。

正しい資格情報で違うネットワークへ

同じ資格情報を複数サービスで使えると、誤設定や悪意のあるNASが別の問題を作る。価値の高いネットワーク名を広告しながら、peerを別サービスへ導けるからだ。RFC 6677はlying NAS、lying provider問題を扱う。peerが見たサービス属性を方式の保護下でserverへ送り、serverがNASの申告や登録情報と比較する。

channel bindingは、端末がネットワークを無条件に知る仕組みではない。広告、NASの主張、バックエンドの期待、比較を守った方式という四つの入力を持つ。ひとつでも失えば、強い認証が意図しないサービス上で成立した可能性を見落とす。

RFC 5216もEAP-TLSについて同じ境界を置く。証明書パスの検証後に、その識別子が当該環境でEAP-TLSに適切で認可されているか判断する。暗号学的な妥当性はポリシーへの入力であり、ポリシーそのものではない。

接続の証跡を順番に並べる

台帳は発見したネットワーク、peerの意図、NAS識別子、ポートから始まる。方式、全対話、保護された結果、peer/server識別子、外側のEAP結果、RADIUS種別、属性、ローカル能力判断を続ける。その後に鍵の出力先、secure association、制御ポート、IP設定、最初の到達性、課金と切断記録を置く。

この順番なら、無効な資格情報とポリシー拒否、Access-Acceptと非対応サービス、方式完了とデータ経路未完成を切り分けられる。利用者の一語の「つながらない」を、責任を持つ構成要素へ戻せる。

情報源