メインコンテンツまでスキップ

4. TACACS+ 難読化の廃止 (Obsolescence of TACACS+ Obfuscation)

[RFC8907] のセクション 4.5 に文書化された難読化メカニズムは脆弱です。

TACACS+ に TLS 認証と暗号化を導入することで、この以前のメカニズムが置き換えられるため、難読化はここに正式に廃止されます。このセクションでは、難読化メカニズムに関して TACACS+ クライアントとサーバーがどのように動作しなければならないかを説明します。

ピアは TLS で難読化を使用してはなりません (MUST NOT)。

TACACS+ TLS 接続を開始する TACACS+ クライアントは、TAC_PLUS_UNENCRYPTED_FLAG ビットを設定しなければならず (MUST)、それによってセッションに難読化が使用されないことを表明します。すべての後続パケットは TAC_PLUS_UNENCRYPTED_FLAG ビットを 1 に設定しなければなりません (MUST)。

TLS 接続を介して TAC_PLUS_UNENCRYPTED_FLAG ビットが 1 に設定されていないパケットを受信した TLS TACACS+ サーバーは、TACACS+ メッセージタイプに応じて適切なエラー (TAC_PLUS_AUTHEN_STATUS_ERROR、TAC_PLUS_AUTHOR_STATUS_ERROR、または TAC_PLUS_ACCT_STATUS_ERROR) を返し、TAC_PLUS_UNENCRYPTED_FLAG ビットを 1 に設定し、セッションを終了しなければなりません (MUST)。

TAC_PLUS_UNENCRYPTED_FLAG ビットが 1 に設定されていないパケットを受信した TACACS+ クライアントは、セッションを終了しなければならず (MUST)、このエラーをログに記録すべきです (SHOULD)。

5. セキュリティに関する考慮事項 (Security Considerations)

5.1. TLS​

この文書は、TLS サポートを追加することにより、TACACS+ ピア間の接続とネットワークトラフィックの機密性、完全性、および認証を向上させます。

単にプロトコルに TLS サポートを追加するだけでは、TLS TACACS+ サーバーとクライアントの保護は保証されません。ネットワークデバイスの完全性を確保し、安全な TLS 鍵と暗号化アルゴリズムを選択するための最新のベストプラクティスを、オペレーターと機器ベンダーが遵守することが不可欠です。

[BCP195] は、TLS を使用するプロトコルの実装と展開に関する実質的なガイダンスを提供しています。セキュア TACACS+ を実装および展開する者は、[BCP195] またはその後続バージョンで概説されている TLS 1.3 に関連する推奨事項を遵守しなければなりません。

5.1.1. TLS の使用 (TLS Use)​

新しい TACACS+ 本番環境の展開は、TLS 認証と暗号化を使用すべきです (SHOULD)。

TLS TACACS+ サーバー (セクション 2 で定義) は、セクション 5.3 で説明されているダウングレード攻撃または設定ミスの脅威のため、非 TLS 接続を許可してはなりません (MUST NOT)。代わりに、これらのクライアントに対応するために、別個の非 TLS TACACS+ サーバーを設定すべきです (SHOULD)。

セクション 5.3 で説明されている理由により、同じホスト上に TLS TACACS+ サーバーと非 TLS TACACS+ サーバーを展開することは推奨されません (NOT RECOMMENDED)。非 TLS 接続は、別個のホスト上に必要な非 TLS TACACS+ サーバーを展開することによってよりよく提供されます。

TLS 接続が失敗した場合、TACACS+ クライアントは非 TLS 接続にフォールバックしてはなりません (MUST NOT)。この禁止事項には、展開の移行中 (セクション 6.1) も含まれます。

5.1.2. TLS 0-RTT​

TLS 1.3 の再開と PSK 技術により、TLS ハンドシェイクが完了する前に送信されるデータ、つまり 0-RTT データである早期データを送信することが可能になります。このデータのリプレイはリスクです。TACACS+ データの機密性を考慮すると、クライアントは完全な TLS ハンドシェイクが完了するまでデータを送信してはなりません (MUST NOT)。つまり、クライアントは 0-RTT データを送信してはならず (MUST NOT)、TLS TACACS+ サーバーは 0-RTT データを送信するクライアントを即座に切断しなければなりません (MUST)。

TLS TACACS+ クライアントとサーバーは early_data 拡張を含めてはなりません (MUST NOT)。セキュリティ上の懸念については、[RFC8446] のセクション 2.3 および 4.2.10 を参照してください。

5.1.3. TLS オプション (TLS Options)​

どの TLS バージョンとアルゴリズムをサポート、非推奨、廃止、または放棄すべきかを決定するために、[BCP195] の推奨事項に従わなければなりません (MUST)。

また、[RFC8446] のセクション 9 では、必須でサポートされるオプションが規定されています。

5.1.4. 到達不能な証明機関 (CA) (Unreachable Certificate Authority)​

オペレーターは、ネットワーク障害によって TLS TACACS+ サーバーおよび/またはクライアントがピアの CA から分離される可能性を認識すべきです。公開鍵証明書の CA からの分離は、証明書の検証が失敗する原因となり、したがってピアの TLS 認証が失敗します。セクション 3.4.1 で言及されているアプローチは、これに対処するのに役立ち、検討すべきです。

5.1.5. TLS サーバー名指示 (SNI) (TLS Server Name Indicator)​

オペレーターは、TLS SNI 拡張が平文で送信される TLS クライアント hello の一部であることを認識すべきです。したがって、盗聴の対象となります。[RFC6066] のセクション 11.1 も参照してください。

5.1.6. サーバー ID のワイルドカード (Server Identity Wildcards)​

TLS サーバー ID でワイルドカードを使用すると、単一障害点が作成されます。ワイルドカード証明書の秘密鍵が侵害されると、それを使用するすべてのサーバーに影響します。その使用は、[RFC9525] のセクション 7.1 の推奨事項に従わなければなりません (MUST)。オペレーターは、ワイルドカードが TLS TACACS+ サーバー専用のサブドメインに限定されることを保証しなければなりません (MUST)。

5.2. TACACS+ 設定 (TACACS+ Configuration)​

実装者は、TLS を有効にするために導入された設定スキームが簡単で、TACACS+ クライアントと TACACS+ サーバー間で TLS または非 TLS が使用されるかどうかについて曖昧さがないことを保証しなければなりません。

この文書では、TLS TACACS+ サーバーがリッスンする別個のポート番号の使用を推奨しています。展開がデフォルトを明示的にオーバーライドしていない場合、TACACS+ クライアント実装は正しいポート値を使用しなければなりません (MUST)。

  • ポート 49: 非 TLS 接続 TACACS+ 用
  • ポート 300: TLS 接続 TACACS+ 用

実装者は、TACACS+ クライアントとサーバーがすべての非 TLS TACACS+ 操作を無効にするための単一のオプションを提供できます。TACACS+ サーバーで有効にすると、非 TLS TACACS+ クライアント接続からのいかなるリクエストにも応答しません。TACACS+ クライアントで有効にすると、非 TLS TACACS+ サーバー接続を確立しません。

一般的な設定ミスは、サーバーで TLS を有効にしながらクライアントを非 TLS ポートを使用するように誤設定すること、またはその逆です。これを防ぐために、明確な設定プラクティスには次のものが含まれるべきです (SHOULD)。

  • 設定ファイル内の明示的な TLS/非 TLS モード指示子
  • ポート番号が設定されたモードと一致しない場合の検証警告
  • TLS および非 TLS サーバーの別個の設定セクション

5.3. 既知の TCP/IP ポート番号 (Well-Known TCP/IP Port Number)​

新しいポート番号が適切と見なされる (最初の非 TLS TACACS+ 接続からアップグレードをネゴシエートするメカニズムではなく) のは、次のことが可能になるためです。

  • TCP/IP ポート番号による難読化されていないまたは難読化された接続のブロックの容易さ、
  • 難読化されていないものを監視する受動的侵入検知システム (IDS) が TLS の導入によって影響を受けない、
  • アップグレードを妨害する可能性のある経路上の攻撃の回避、および
  • 設定ミスによる機密情報の偶発的な漏洩の防止。

6. 運用上の考慮事項 (Operational Considerations)

6.1. 移行 (Migration)​

レガシー TACACS+ 展開から TLS セキュアな TACACS+ へのスムーズな移行を促進するために、組織は移行を慎重に計画する必要があります。最も一般的な移行戦略は次のとおりです。

並行運用 (Parallel Operation): オペレーターは、既存の非 TLS サーバーと並行して新しい TLS TACACS+ サーバーを展開できます。これにより、サービスの中断なしに段階的なクライアント移行が可能になります。ただし、セクション 5.1.1 で述べたように、同じホストで TLS と非 TLS の両方のサービスを実行することは推奨されません (NOT RECOMMENDED)。

段階的移行 (Phased Migration): 推奨されるアプローチには次のものが含まれます。

  1. 評価フェーズ (Assessment Phase): 環境内のすべての TACACS+ クライアントとサーバーを特定する
  2. パイロットフェーズ (Pilot Phase): テスト環境でポート 300 に TLS TACACS+ サーバーを展開する
  3. 初期展開 (Initial Deployment): クライアントのサブセットを新しい TLS サーバーを使用するように設定する
  4. 段階的ロールアウト (Gradual Rollout): 追加のクライアントを段階的に移行する
  5. 監視期間 (Monitoring Period): 継続する前に安定した動作を確保する
  6. 完了 (Completion): すべてのクライアントが移行されたら、非 TLS インフラストラクチャを廃止する

移行中、TLS 接続が失敗した場合、TACACS+ クライアントは非 TLS 接続にフォールバックするように設定してはなりません (MUST NOT) (セクション 5.1.1)。この禁止事項は、ダウングレード攻撃を防ぐために不可欠です。

オペレーターは、移行中に詳細なログを維持して、まだ非 TLS 接続を試みているクライアントを特定すべきです。

6.2. 非 TLS TACACS+ クライアントの維持 (Maintaining Non-TLS TACACS+ Clients)​

一部のレガシーデバイスは TLS をサポートしておらず、アップグレードできない場合があります。これらのデバイスについて、オペレーターにはいくつかの選択肢があります。

  1. 別個の非 TLS インフラストラクチャ (Separate Non-TLS Infrastructure): 別個のホストに専用の非 TLS TACACS+ サーバーを展開する (推奨)。可能であれば、これらのサーバーはより制限されたネットワークセグメントに分離すべきです。

  2. 段階的なハードウェアリフレッシュ (Gradual Hardware Refresh): 通常のリフレッシュサイクルの一部として、レガシーデバイスの交換またはアップグレードを計画する。

  3. 補償制御 (Compensating Controls): レガシーデバイスを残さなければならない場合は、専用 VLAN、強化された監視、またはネットワーク層での暗号化トンネルなどの追加のネットワークレベルのセキュリティ制御を実装する。

非 TLS TACACS+ サーバーは明確に文書化され、監視されるべきです (SHOULD)。組織は完全な TLS 移行の目標日を設定すべきです。

6.3. TACACS+ クライアント用の YANG モデル (YANG Model for TACACS+ Clients)​

TLS 固有のパラメーターを含む TACACS+ クライアントを設定するための YANG データモデルは、ネットワーク自動化と異種ネットワークデバイス全体での一貫した設定管理に有益です。

このようなモデルには次のものが含まれる可能性があります。

  • サーバーアドレスとポート番号
  • TLS 設定パラメーター (証明書パス、暗号スイートなど)
  • フォールバック動作とタイムアウト設定
  • 認証優先順位

標準化された YANG モデルの開発は、この文書の範囲外ですが、将来の作業として奨励されます。YANG ベースの管理システムで TACACS+ over TLS を実装する組織は、ベンダーニュートラルなモデルの開発を検討すべきです。

7. IANA に関する考慮事項 (IANA Considerations)

IANA は、TACACS+ over TLS 用に TCP ポート番号 300 をサービス名 "tacacss" で割り当てました。

Service Name: tacacss
Transport Protocol: TCP
Port Number: 300
Description: TACACS+ over TLS
Reference: RFC 9887

8. 謝辞 (Acknowledgments)

著者は、IETF 運用および管理エリアワーキンググループ (OPSAWG) 参加者からの貢献とフィードバックに感謝します。この仕様の開発中に貴重な意見を提供してくださった方々、レビュー、提案、実装経験を含む、この文書の形成に役立ったすべての方々に特別な感謝を申し上げます。

TLS を通じて TACACS+ のセキュリティを強化する作業は、デバイス管理トラフィックのより良い保護に対する運用コミュニティのニーズによって推進されました。著者は、この仕様を可能にした協力的な取り組みに感謝します。

9. 参考文献 (References)

9.1. 規範的参考文献 (Normative References)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

    • https://www.rfc-editor.org/info/rfc2119

  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

    • https://www.rfc-editor.org/info/rfc8174

  • [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.

    • https://www.rfc-editor.org/info/rfc8446

  • [RFC8907] Dahm, T., Ota, A., Medway Gash, D., and L. Grant, "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", RFC 8907, DOI 10.17487/RFC8907, September 2020.

    • https://www.rfc-editor.org/info/rfc8907

  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008.

    • https://www.rfc-editor.org/info/rfc5280

  • [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023.

    • https://www.rfc-editor.org/info/rfc9525

  • [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011.

    • https://www.rfc-editor.org/info/rfc6066

9.2. 参考情報 (Informative References)​

  • [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011.

    • https://www.rfc-editor.org/info/rfc6151

  • [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014.

    • https://www.rfc-editor.org/info/rfc7250

  • [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016.

    • https://www.rfc-editor.org/info/rfc7924

  • [RFC9257] Housley, R., "Guidance for External Pre-Shared Key (PSK) Usage in TLS", RFC 9257, DOI 10.17487/RFC9257, July 2022.

    • https://www.rfc-editor.org/info/rfc9257

  • [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015.

    • https://www.rfc-editor.org/info/rfc7525

  • [FIPS-140-3] National Institute of Standards and Technology, "Security Requirements for Cryptographic Modules", FIPS PUB 140-3, March 2019.

    • https://csrc.nist.gov/publications/detail/fips/140/3/final

  • [REQ-TLS13] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", RFC 8996, DOI 10.17487/RFC8996, March 2021.

    • https://www.rfc-editor.org/info/rfc8996

著者のアドレス (Authors' Addresses)​

Thorsten Dahm
Email: [email protected]

John Heasley
NTT
Email: [email protected]

Douglas C. Medway Gash
Cisco Systems, Inc.
Email: [email protected]

Andrej Ota
Google Inc.
Email: [email protected]

に最終更新