要約

  • RFC 5422はサーバー認証なしの設定後にはアクセスを与えないよう勧める一方、認証ありではサーバーの方針に応じて許可できる。
  • Tunnel PACの確認はピアが処理・保存したという報告であり、後続認証の成功やアクセス許可を示すものではない。

初期設定はアクセス許可まで届かない

機器がネットワークに参加する時点で、共有秘密、サーバーの信頼ルート、Protected Access Credentialをまだ持っていないことがある。RFC 5422は、EAP-FASTで必要な情報を動的に設定する方法を扱う。確認すべきなのは、初期交換が成功したことと、その機器がネットワーク資源を使えることを同じ結果にしてよいかどうかだ。

EAP-FASTにはTLSのフェーズ1と、トンネル内で行うEAPのフェーズ2がある。RFC 5422はサーバー認証ありとサーバー認証なしのプロビジョニングを区別する。前者ではTLSハンドシェイク中にピアがサーバーを検証するため、事前に信頼情報が必要になる。後者は匿名Diffie–Hellman TLSで始められ、事前設定の負担を減らす一方、最初の段階ではサーバーの身元が確認されない。

匿名で始めても、認証を省いてよいわけではない。両者はトンネル内で相互認証と鍵導出を行うEAP方式を完了し、ピアはCrypto-Binding TLVで内側の交換がTLSトンネルの完全性に結び付いていることを確認する。2009年版では、このモードの実装に内側の認証方式としてEAP-FAST-MSCHAPv2のサポートが必須だった。内側の成功だけを見ると、外側のチャネルとの結び付きを取り落とす。 (RFC 5422 §§2, 3.2–3.2.3, 6.1.2; RFC 4851)

その後、サーバーはTunnel PAC（PAC-KeyとPAC-Opaqueを含む）やサーバーの信頼ルートを配布できる。Tunnel PACは将来のEAP-FASTトンネルに使う資格情報であり、それ自体がネットワーク利用を認めるわけではない。

Tunnel PACについてピアが返すPAC-Acknowledgementは、処理と保存の結果を伝えるものだ。このTLVはTunnel PAC以外には使わない。サーバーが受け取るのはピアの報告であり、次回の認証成功、アクセス方針の許可、アプリケーション到達性までを示すレシートではない。 (RFC 5422 §§3.2, 4.1.4, 4.2.5)

RFC 5422は明確に、サーバー認証なしのプロビジョニング終了時にネットワークアクセスを与えるべきではないとする。交換は資格情報の設定だけを目的とする。ピア側の方針により切断し、取得した情報で別のEAP-FAST交換を始められる。一方、サーバー認証ありのモードでは、プロビジョニング成功後にアクセスを認めることができる。モードごとの意味を「成功」という一語に畳み込めない。 (RFC 5422 §3.5)

選択にはトレードオフがある。サーバー認証ありは中間者への保護が強いが、機器に事前の信頼情報が必要だ。匿名モードはゼロタッチ導入をしやすくする半面、パスワード方式に対するオフライン辞書攻撃の危険を大きくする。RFC 5422はオンライン試行の抑制や、匿名モードを使う場所・条件の制限も挙げる。これは2009年のInformational文書の設計上の注意であり、現在の製品や導入率を示すデータではない。 (RFC 5422 §§6.1–6.3)

運用記録は、初期設定モード、内側の相互認証とCrypto-Binding、配布資格情報の種類と期限、Tunnel PAC確認、資格情報を使う次の認証、最終的なアクセス判断を別々に持つべきだ。プロビジョニング担当とネットワーク許可担当が異なるなら、共通の相関IDと、次の交換が現れない場合の責任者が欠かせない。初期交換の成功だけでは、その空白は埋まらない。

内側の認証成功後もアクセス拒否はあり得る

RFC 5422の3.5節では、プロビジョニング完了後の許可をサーバーポリシーが決める。サーバー認証ありのモードでは、ピアを認証してTunnel PACを渡した後にネットワーク利用を認めることができる。サーバー認証なしのモードは異なり、交換は設定だけを目的とするため、終了時にアクセスを与えるべきではない。同じように資格情報が配布されても、許可結果は同じではない。

内側のEAP方式が成功しても、それだけでアクセス許可にはならない。Result TLVが内側の成功を示した後でも、サーバーは方針が満たされていないとしてEAP Failureで終えられる。アクセスを開く目的の交換でなければ、RFC 5422はネットワーク接続を許可せず、Network Access Serverへセッション鍵を渡さないよう求める。内側の成功数だけを見る画面は、意図した拒否を緑色の完了として誤表示しかねない。最初の成功表示ではなく、最終EAP結果と鍵の引き渡しまで追う必要がある。（RFC 5422 §3.5、RFC 4851 §4.2.2）

確認応答が示すのは資格情報の一時点

Tunnel PACは単一の汎用トークンではない。PAC-Keyはフェーズ1トンネルを確立する32オクテットの秘密鍵で、PAC-Opaqueは発行サーバー固有の情報として後でサーバーに返される。PAC-Infoには発行者や有効期間を含められる。RFC 4851はPAC-Keyの安全な扱いを求め、RFC 5422はピアとサーバー双方に保存の責任があるとする。配布後にも保管、期限、更新を管理しなければならない。

PAC-Acknowledgementが扱うのは、新たに配布されたTunnel PACの処理・保存結果だけであり、値は成功か失敗である。成功はその時点でピアがそう報告したという意味だ。後日もトンネルを確立できること、秘密が安全に保たれ続けること、ネットワーク許可が出ることまでは示さない。次のEAP-FAST交換で初めて、新しい認証文脈で資格情報が使えるかを試せる。その成功も、アプリケーションまで通信できた証拠とは別である。（RFC 5422 §§4.2.2–4.2.5, 6.8、RFC 4851 §3.2.2）

拒否は可用性にも影響する

この分離には可用性上の代償がある。プロビジョニング後にEAP Failureで拒否すると、802.11機器では完全な切断につながる場合がある。ピアまたはサーバーがTLS再ネゴシエーションを試せば、新しい資格情報を使う後続認証へ滑らかに移れる可能性があるが、どちらも要求を拒める。通常のアクセス方針は、その後続認証が成功してから適用される。配布件数だけでなく、再接続、拒否、完全再起動、TLS再ネゴシエーションの結果を追う必要がある。そうしなければ、正しい拒否を初期設定障害と誤認し、未入場の機器を成功数の中に隠してしまう。（RFC 5422 §3.5）

参考資料