RFC 9887：安全な TACACS+ の失敗はフォールバックを許可しない

要約

RFC 9887 は TLS 版 TACACS+ に別のサービス境界を与え、TLS 1.3 と相互認証を必須にし、0-RTT のアプリケーションデータと非 TLS へのフォールバックを禁止する。
新旧サーバーは移行中に併存し得るが、その期間は完了するまで安全ではない。旧サービスへ届くことは、保護サービスの継続性を示さない。

セキュリティ移行で重い意味を持つのは、新経路を有効にする文ではなく、新経路が使えない時の動作を定める文である。RFC 9887 は TACACS+ クライアントに、TLS 接続が失敗しても非 TLS 接続へ戻ってはならないと命じる。移行期間も例外ではない。

TACACS+ が運ぶのは機器管理の通信である。RFC 8907 は認証、認可、アカウンティングを分けているが、従来のパケット本文の仕組みは難読化であって現代的な暗号化ではない。RFC 9887 は保護版でそれを TLS 認証と暗号化に置き換える。同じ曖昧な待受口に任意の機能を足す設計ではない。

TCP 接続後は直ちに TLS ハンドシェイクを開始する。平文や難読化された接続から途中で昇格する方式は禁止される。既定では旧 TACACS+ が TCP 49、新しい tacacss が TCP 300 を使い、IANA のサービス登録にもその割当がある。

物理的な分離は検証可能な制御になる。フィルタは強弱のサービスを区別でき、経路上の攻撃者がアップグレード交渉を壊す余地を減らし、設定の曖昧さによる誤送信も抑えられる。RFC は別ホストも推奨する。TLS 非対応機器に旧サーバーが必要でも、それは TLS 必須クライアントの自動予備経路ではない。

ポートが開いているという観測は入口の存在しか証明しない。期待した相手、交渉した版、証明書検証、ハンドシェイク完了、TACACS+ メッセージ受理、認可、機器上の実行は別々の証拠である。

このプロファイルは TLS 1.3 以上を要求し、旧版を認めない。現行仕様は RFC 9846、運用上の指針は RFC 9325 にある。実装は共通の相互運用手段として証明書による相互認証を備える。

双方は X.509 プロファイルに従って証明書パスと失効状態を検証し、サービス識別には RFC 9525 の規則を使う。成功が示すのは TLS の相手である。ローカル方針は接続をさらに制限でき、その後も TACACS+ は利用者やコマンドの認可を別に判断する。

有効な証明書はコマンドの許可ではない。完了したハンドシェイクはアカウンティング記録ではない。肯定的な認可応答も、操作が実行され、意図した状態になった証明ではない。転送境界の成功は後続の権限を継承しない。

0-RTT も使えない。クライアントとサーバーは early_data 拡張を含めず、サーバーは早期データを送るクライアントを切断する。再開チケットは新しい認証済み接続を助けるが、ハンドシェイク前の AAA 入力を許可するものではない。

フォールバック禁止は、可用性事故が気づかれない方針変更へ変わるのを防ぐ。期限切れ証明書、失効、不完全なチェーン、CA や失効確認先への到達不能、安全サーバーの故障はいずれも運用圧力を生む。しかし、到達可能な旧サーバーを適格な保護相手へ変えるものではない。

必要なのは証拠水準を下げない継続性である。複数の安全サーバー、ローカルに用意したチェーン、失効確認の継続、ローテーション訓練、独立監視、帯域外復旧を整える。人が承認する例外を設けるなら、対象、期限、責任者、監査記録が必要であり、クライアントの隠れた再試行にはできない。

RFC 9887 は新旧サービスの一時的併存を認める一方、移行完了までは安全でないと明記する。クライアントが両方のサーバーを持つ期間は短くすべきである。

移行率 90% は安全性 90% の証明ではない。残った弱経路は機密通信を受け得るし、攻撃者はその利用を狙って TLS 経路を失敗させるかもしれない。完了の証拠は、移行済みクライアントが 49 番へ戻れず、旧サーバーが明示的に隔離された対象だけを扱うことである。

SNI はクライアント hello で平文のまま見える。ワイルドカード証明書は共通秘密鍵の障害範囲を広げるため、専用サブドメインに絞る。サービス発見は仕様外である。いずれも機関としての正当な運用者を自動的に決める情報ではない。