要約

  • RFC 5281 は EAP-TTLSv0 を、TLS ハンドシェイクと、その後の保護されたデータ交換に分ける。クライアント証明書を使わない通常の分岐では、第1段階で認証されるのは TTLS サーバーであり、加入者の実名と認証材料は第2段階で初めて現れる。
  • 信頼できるアクセス記録には、外側の経路指定用 ID、証明書検証、内側の方式とユーザー ID、AAA の判断、認可、鍵の配送、アクセスポイントでの適用、実際の通信までが必要である。途中の成功表示を最終結果として扱ってはならない。

Finished は「次の問いを安全に送れる」という合図

EAP-TTLSv0 の第1段階は TLS ハンドシェイクである。TTLS サーバーは証明書を提示し、クライアントは信頼する認証局、期待するサーバー名、検証ポリシーに照らして確認する。クライアント側の証明書は任意であり、多くの配備では使われない。ChangeCipherSpec と Finished の交換が終わると、保護された TLS レコードを送れるようになる。

ここで確定したのは、クライアントが正しいと判断した TTLS 終端との暗号化経路である。加入者が誰かという問いは、まだ残っている。第2段階では、その経路の中に AVP を入れ、実際のユーザー名、パスワード証明、内側の EAP、完全性情報、設定情報などを運ぶ。

したがって「TLS 確立」は「加入者認証済み」への言い換えではない。ホーム AAA が受け入れたことも、認可がアクセスポイントに届いたことも、リンク鍵が正しいセッションに入ったことも、利用可能な通信が流れたことも示さない。プロトコルは、その順番を意図的に分けている。

RFC 5281 は Informational 文書であり、当時の実装を記述したものだ。そこに残る TLS 1.0 と 1.1 の扱いは現在の推奨ではない。RFC 8996 は両方を禁止し、RFC 9427 は TLS 1.3 における鍵導出と結果処理を更新した。暗号の世代が変わっても、誰が誰を認証し、誰がサービスを実行したかという境界は消えない。

最初の名前は本人名ではなく配送先である

TTLS が始まる前、アクセスポイントは EAP-Response/Identity を求めることがある。この応答は暗号化トンネルの外にある。RFC 5281 はプライバシーのため、ここに実際のユーザー名を置かず、空値や匿名のプレースホルダーを使い、要求を適切な事業者へ送るための realm だけを残せるとしている。

この外側の ID が答えるのは「どの信頼ドメインへ届けるか」であって、「誰が接続しようとしているか」ではない。内側の ID は保護された経路を通って届き、ホーム側の権威が認証方式とポリシーに基づいて判断する。

運用ログが identity という一つの欄しか持たないと、二つの意味は簡単に混ざる。後から内側の値で上書きすれば経路選択の履歴を失う。外側の匿名値だけ残せば、AAA の判断を匿名文字列に帰属させてしまう。値、役割、観測者、時刻を別々に保存する必要がある。

TLS の保護は TTLS 終端で終わる

クライアントが送った内側の AVP は、TTLS サーバーまで TLS で保護される。そのサーバーはレコードを復号し、必要な認証材料を RADIUS、Diameter、その他の AAA キャリアで AAA/H に渡す。TTLS 終端とホーム AAA は同じ装置かもしれないが、別のシステムや複数のプロキシであることもある。

つまり外側の TLS は、クライアントから最終的なホーム権威までを一つの暗号化包みで覆ってはいない。バックエンド区間には独自の相互認証、機密性、完全性、経路制御が必要である。トンネルが安全という表示だけでは、その区間を監査したことにならない。

TTLS サーバーは透明な中継器でもない。内側の資格情報を見て、異なる AVP 文脈を変換し、何を転送するかを決める。RFC 5281 は、同じ AVP コードでも TTLS とバックエンドで意味が同一とは限らず、両方の意味を理解せずにコピーしてはならないと警告する。形式が通ったことは、意味が保存された証拠ではない。

認証結果は一回の判定とは限らない

AAA/H は challenge、accept、reject を返す。challenge は TTLS サーバーを通り、暗号化された内側の交換としてクライアントへ戻る。必要な往復が終わって権威が結論を出すと、その結果が外側の EAP-Success または EAP-Failure に結び付けられる。

内側で複数の方式を順に使うこともできる。パスワードの後にトークンを確認する配備では、それぞれの成功だけで全体の成功が決まるとは限らない。全方式を要求するのか、いずれか一つでよいのかはポリシーである。方式名、順序、個別結果、ポリシー世代を記録しなければ、単一の success は再現できない。

第2段階がないこと自体も、必ずしも異常ではない。第1段階のクライアント証明書で十分に認証できた場合や、以前の成功セッションを正しく再開した場合には省略できる。必要なのは「内側が見えない」という警報ではなく、どの分岐が選ばれ、どの過去の判断を継承したかという記録である。

一方、TLS だけ成功し、内側のユーザー認証に失敗したセッションを再開可能として保存するのは致命的である。RFC 5281 はその帰結を catastrophic と表現する。再開資格は、加入者認証の成功から生まれなければならず、ハンドシェイク完了から捏造されてはならない。

鍵を計算できることと、使う権限は別である

TLS の共有秘密と乱数からは MSK と EMSK を導出できる。加入者認証が成功した後、データ接続用の鍵素材と認可情報が AAA キャリアを経由してアクセスポイントへ送られる。

ここには二つの事実がある。暗号処理が候補のバイト列を作れることと、ポリシーがその鍵を特定のアクセスセッションで使うことを許可したことだ。拒否されたユーザーについて鍵素材が計算可能でもよい。誤ったセッションに関連付けられたり、古い認可と一緒に届いたり、アクセスポイントが実際にはインストールしなかったりすることもある。

監査で問うべきなのは「鍵が生成されたか」だけではない。どの TLS transcript と加入者判断から生まれ、どの成功判定が配送を許し、どのアクセスポイント・セッションが取り込み、どのポリシーとともに実行したかである。その後に通信が成立したかも別に観測する。

成功はクライアント側と実行側へ別々に届く

AAA/H が加入者を受け入れると、クライアントには通常 EAP-Success が届く。アクセスポイントには別の AAA 経路で Accept、鍵、フィルタ、論理ネットワーク、時間制限、帯域制限などの認可が届く。同じ判断を起点にしていても、受信者も経路も違う。

クライアントが EAP-Success を見たことは、アクセスポイントが意図した認可を実装した証拠ではない。アクセスポイントが Accept を受け取ったことも、正しい VLAN やフィルタを適用した証拠ではない。リンク暗号が有効でも、アドレス取得、ルーティング、DNS、アプリケーション到達性は失敗し得る。

「アクセスが回復した」という主張を閉じるには、実行点での状態読戻しと、必要ならアプリケーション境界での双方向観測が要る。認証を決定した当事者は、自ら観測できない下流の結果まで success という一語で所有できない。

外側と内側の二つの成功には結合の穴がある

RFC 5281 は EAP-TTLSv0 の既知の制約として、外側 TLS と内側認証の暗号学的な binding がないことを挙げる。トンネル内外で再利用できる資格情報は、攻撃者によって別の文脈へ中継される危険がある。文書はそのような再利用を避け、層を結合する拡張を検討するよう求めている。

これは全ての EAP-TTLS セッションが不正だという意味ではない。しかし「外側も内側も成功した」と「同一の認証文脈に結合された」は同じ主張ではない。後発の tunneled method や拡張の保証を、基礎版 EAP-TTLSv0 に遡って読み込んではならない。

アクセス記録を境界順に組み立てる

重要なアクセス判断では、少なくとも次を残すべきである。

  • クライアント、アクセスポイント、TTLS サーバー、ホーム AAA の識別子
  • 外側の明文 ID、ルーティング realm、プロキシ経路
  • サーバー証明書チェーン、期待名ポリシー、検証結果
  • TLS バージョン、暗号スイート、transcript、第1段階の完了
  • クライアント証明書の有無と、それが加入者認証に使われたか
  • 新規か再開か、再開なら継承した成功認証と認可
  • 内側の ID、方式の順序、challenge、各結果
  • TTLS から AAA への取引 ID とキャリア保護
  • AAA の accept/reject、ポリシー世代、返された認可
  • クライアントが観測した EAP-Success/EAP-Failure
  • MSK の配送先とアクセスポイント・セッションへの結合
  • フィルタ、ネットワーク割当、時間・帯域制限の実装状態
  • リンク保護と双方向データの観測
  • 障害報告が約束したアプリケーション結果

記録は途中のどの境界でも停止できなければならない。安全なトンネルと拒否された加入者は両立する。受け入れられた加入者と実行失敗も両立する。リンクが確立していてもサービスは使えないことがある。境界を分けるのは悲観ではなく、最初の緑色を最後の成果に偽装させないための運用規律である。

Sources