要約

  • RFC 9887ではTCP接続の成立直後にTLSネゴシエーションを開始し、最低TLS 1.3を使用する。TACACS+はTLSアプリケーションデータとしてだけ送信される。TLSサーバーは非TLS接続を受け付けず、クライアントもTLS失敗後に非TLSへ戻らない。
  • 証明書による相互認証が実装の基線である。双方が相手の証明書パスを検証し、失効確認も行う。PSKとRaw Public Key（RPK）は任意の代替方式であり、TLS PSKは従来のTACACS+難読化シークレットと分離しなければならない。
  • TLS運用では従来のTACACS+難読化を使用しない。TLSが機密性と完全性を提供するため、TLSで動作するピアは TAC_PLUS_UNENCRYPTED_FLAG を 1 に設定しなければならない。TACACS+データのTLS 0-RTTは禁止され、再開チケットは一回だけ使用し、再開時にも失効を再確認する。
  • IANAはTCP 300とサービス名 tacacssを割り当てた。代替ポートも可能だが、明示的な運用上の検討が必要である。RFC 9887はTLSと非TLSが混在する移行段階を完了まで安全ではないとし、その期間を短くすること、非TLSサーバーを分離することを示している。同一ホストへの配置は推奨されない。

「フォールバック禁止」はプロトコルの動作を示すもので、移行計画を自動的に完了させる仕組みではない。機器を同時に移せない場合、旧サーバーが残ることがあり、リスクは二つの経路、誤った宛先、残存する到達性から生じる。RFC 9887は、ベンダー実装の普及、TCP 300の本番採用率、実際の移行期間やダウングレード事例、認証局の可用性、失効確認の遅延、TLS再開の性能測定を示していない。

検証設計。 TLS対応クライアント、TLSだけを受けるサーバー、明確に識別した非TLS旧サーバーを用意し、TCP 300の接続ログを観測する。相互証明書で正常なハンドシェイクを確認し、一方の証明書を失効させて新規接続と再開が拒否されることを確かめる。TLSサーバーに非TLSの先頭バイトを送って受理されないこと、TLSハンドシェイクを失敗させてもクライアントが旧経路へ接続しないことを確認する。キャプチャで0-RTTアプリケーションデータがないこと、再開チケットが再利用できないこと、TLS PSKと旧シークレットが異なることも検査する。これは検証設計であり、特定製品や実配備への主張ではない。

出典

RFC 9887：TACACS+ over TLS 1.3