Internet Engineering Task Force (IETF) T. Dahm
Request for Comments: 9887
Updates: 8907 J. Heasley
Category: Standards Track NTT
ISSN: 2070-1721 D.C. Medway Gash
Cisco Systems, Inc.
A. Ota
Google Inc.
December 2025
This document specifies the use of Transport Layer Security (TLS) version 1.3 to secure the communication channel between a Terminal Access Controller Access-Control System Plus (TACACS+) client and server. TACACS+ is a protocol used for Authentication, Authorization, and Accounting (AAA) in networked environments. The original TACACS+ protocol does not mandate the use of encryption or secure transport. This specification defines a profile for using TLS 1.3 with TACACS+, including guidance on authentication, connection establishment, and operational considerations. The goal is to enhance the confidentiality, integrity, and authenticity of TACACS+ traffic, aligning the protocol with modern security best practices.
この文書では、ターミナル アクセス コントローラー アクセス コントロール システム プラス (TACACS+) クライアントとサーバー間の通信チャネルを保護するためのトランスポート層セキュリティ (TLS) バージョン 1.3 の使用を指定します。TACACS+ は、ネットワーク環境での認証、認可、およびアカウンティング (AAA) に使用されるプロトコルです。元の TACACS+ プロトコルでは、暗号化や安全な転送の使用は義務付けられていません。この仕様は、認証、接続の確立、および運用上の考慮事項に関するガイダンスを含む、TACACS+ で TLS 1.3 を使用するためのプロファイルを定義します。目標は、プロトコルを最新のセキュリティのベスト プラクティスに合わせて、TACACS+ トラフィックの機密性、完全性、信頼性を強化することです。
This document updates RFC 8907.
この文書は RFC 8907 を更新します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9887.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9887 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Technical Definitions
2.1. Requirements Language
3. TACACS+ over TLS
3.1. Separating TLS Connections
3.2. TLS Connection
3.3. TLS Authentication Options
3.4. TLS Certificate-Based Authentication
3.4.1. TLS Certificate Path Verification
3.4.2. TLS Certificate Identification
3.4.3. Cipher Suites Requirements
3.5. TLS PSK Authentication
3.6. TLS Resumption
4. Obsolescence of TACACS+ Obfuscation
5. Security Considerations
5.1. TLS
5.1.1. TLS Use
5.1.2. TLS 0-RTT
5.1.3. TLS Options
5.1.4. Unreachable Certificate Authority (CA)
5.1.5. TLS Server Name Indicator (SNI)
5.1.6. Server Identity Wildcards
5.2. TACACS+ Configuration
5.3. Well-Known TCP/IP Port Number
6. Operational Considerations
6.1. Migration
6.2. Maintaining Non-TLS TACACS+ Clients
6.3. YANG Model for TACACS+ Clients
7. IANA Considerations
8. Acknowledgments
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses
"The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol" [RFC8907] provides device administration for routers, network access servers, and other networked computing devices via one or more centralized TACACS+ servers. The protocol provides authentication, authorization, and accounting services (AAA) for TACACS+ clients within the device administration use case.
「ターミナル アクセス コントローラ アクセス制御システム プラス (TACACS+) プロトコル」[RFC8907] は、1 つ以上の集中型 TACACS+ サーバを介して、ルータ、ネットワーク アクセス サーバ、およびその他のネットワーク化されたコンピューティング デバイスのデバイス管理を提供します。このプロトコルは、デバイス管理のユースケース内で TACACS+ クライアントに認証、認可、およびアカウンティング サービス（AAA）を提供します。
The content of the protocol is highly sensitive and requires secure transport to safeguard a deployment. However, TACACS+ lacks effective confidentiality, integrity, and authentication of the connection and network traffic between the TACACS+ server and client. The security mechanisms as described in Section 4.5 of [RFC8907] are extremely weak.
プロトコルの内容は非常に機密性が高く、展開を保護するために安全な転送が必要です。ただし、TACACS+ には、TACACS+ サーバとクライアント間の接続およびネットワーク トラフィックの効果的な機密性、完全性、および認証が欠けています。[RFC8907] のセクション 4.5 で説明されているセキュリティメカニズムは非常に弱いです。
To address these deficiencies, this document updates the TACACS+ protocol to use TLS 1.3 authentication and encryption [RFC8446], and obsoletes the use of TACACS+ obfuscation mechanisms. The maturity of TLS in version 1.3 and above makes it a suitable choice for the TACACS+ protocol.
これらの欠陥に対処するために、この文書では TLS 1.3 認証と暗号化 [RFC8446] を使用するように TACACS+ プロトコルを更新し、TACACS+ 難読化メカニズムの使用を廃止します。バージョン 1.3 以降の TLS は成熟しているため、TACACS+ プロトコルには適切な選択肢となっています。
The terms defined in Section 3 of [RFC8907] are fully applicable here and will not be repeated. The following terms are also used in this document.
[RFC8907] のセクション 3 で定義されている用語はここで完全に適用されるため、繰り返しません。この文書では次の用語も使用されます。
Obfuscation:
難読化:
TACACS+ was originally intended to incorporate a mechanism for securing the body of its packets. The algorithm is categorized as obfuscation in Section 10.5.2 of [RFC8907]. The term is used to ensure that the algorithm is not mistaken for encryption. It should not be considered secure.
TACACS+ は当初、パケットの本体を保護するためのメカニズムを組み込むことを目的としていました。このアルゴリズムは、[RFC8907] のセクション 10.5.2 で難読化として分類されています。この用語は、アルゴリズムが暗号化と間違われないようにするために使用されます。安全であると考えるべきではありません。
Non-TLS connection:
非TLS接続:
This term refers to the connection defined in [RFC8907]. It is a connection without TLS, using the unsecure TACACS+ authentication and obfuscation (or the unobfuscated option for testing). The use of well-known TCP/IP host port number 49 is specified as the default for non-TLS connections.
この用語は、[RFC8907] で定義されている接続を指します。これは、安全でない TACACS+ 認証と難読化 (またはテスト用の難読化されていないオプション) を使用した、TLS を使用しない接続です。非 TLS 接続のデフォルトとして、既知の TCP/IP ホスト ポート番号 49 の使用が指定されています。
TLS connection:
TLS接続:
A TLS connection is a TCP/IP connection with TLS authentication and encryption used by TACACS+ for transport. A TLS connection for TACACS+ is always between one TACACS+ client and one TACACS+ server.
TLS 接続は、TACACS+ がトランスポートに使用する TLS 認証と暗号化を備えた TCP/IP 接続です。TACACS+ の TLS 接続は、常に 1 つの TACACS+ クライアントと 1 つの TACACS+ サーバーの間で行われます。
TLS TACACS+ server:
TLS TACACS+ サーバー:
This document describes a variant of the TACACS+ server, introduced in Section 3.2 of [RFC8907], which utilizes TLS for transport, and makes some associated protocol optimizations. Both server variants respond to TACACS+ traffic, but this document specifically defines a TACACS+ server (whether TLS or non-TLS) as being bound to a specific port number on a particular IP address or hostname. This definition is important in the context of the configuration of TACACS+ clients to ensure they direct their traffic to the correct TACACS+ servers.
この文書は、[RFC8907] のセクション 3.2 で導入された TACACS+ サーバーのバリアントについて説明します。これは、トランスポートに TLS を利用し、関連するプロトコルの最適化を行います。どちらのサーバー バリアントも TACACS+ トラフィックに応答しますが、このドキュメントでは、TACACS+ サーバー (TLS か非 TLS かに関係なく) が特定の IP アドレスまたはホスト名の特定のポート番号にバインドされるものとして具体的に定義されています。この定義は、TACACS+ クライアントの設定のコンテキストにおいて、トラフィックが正しい TACACS+ サーバに確実に送信されるようにするために重要です。
Peer:
ピア:
The peer of a TACACS+ client (or server) in the context of a TACACS+ connection, is a TACACS+ server (or client). Together, the ends of a TACACS+ connection are referred to as peers.
TACACS+ 接続のコンテキストにおける TACACS+ クライアント (またはサーバー) のピアは、TACACS+ サーバー (またはクライアント) です。TACACS+ 接続の両端をまとめてピアと呼びます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
TACACS+ over TLS takes the protocol defined in [RFC8907], removes the option for obfuscation, and specifies that TLS 1.3 be used for transport (Section 3.1 elaborates on TLS version support). A new well-known default host port number is used. The next sections provide further details and guidance.
TACACS+ over TLS は、[RFC8907] で定義されたプロトコルを採用し、難読化のオプションを削除し、トランスポートに TLS 1.3 を使用することを指定します (TLS バージョンのサポートについてはセクション 3.1 で詳しく説明します)。新しい既知のデフォルトのホスト ポート番号が使用されます。次のセクションでは、さらなる詳細とガイダンスを提供します。
TLS is introduced into TACACS+ to fulfill the following requirements:
TLS は、次の要件を満たすために TACACS+ に導入されています。
1. Confidentiality and Integrity: The MD5 algorithm underlying the obfuscation mechanism specified in [RFC8907] has been shown to be insecure [RFC6151] when used for encryption. This prevents TACACS+ from being used in a deployment compliant with [FIPS-140-3]. Securing the TACACS+ protocol with TLS is intended to provide confidentiality and integrity without requiring the provision of a secured network.
1. 機密性と完全性: [RFC8907] で指定されている難読化メカニズムの基礎となる MD5 アルゴリズムは、暗号化に使用すると安全ではないことが [RFC6151] で示されています。これにより、TACACS+ が [FIPS-140-3] に準拠した展開で使用されなくなります。TLS を使用して TACACS+ プロトコルを保護することは、安全なネットワークを提供することなく機密性と完全性を提供することを目的としています。
2. Peer authentication: The authentication capabilities of TLS replace the shared secrets of obfuscation for mutual authentication.
2. ピア認証: TLS の認証機能は、相互認証のための難読化の共有秘密を置き換えます。
This document adheres to the recommendations in [REQ-TLS13].
この文書は、[REQ-TLS13] の推奨事項に準拠しています。
Peers implementing the TACACS+ protocol variant defined in this document MUST apply mutual authentication and encrypt all data exchanged between them. Therefore, when a TCP connection is established for the service, a TLS handshake begins immediately. Options that upgrade an initial non-TLS connection MUST NOT be used; see Section 5.3.
この文書で定義されている TACACS+ プロトコル バリアントを実装するピアは、相互認証を適用し、ピア間で交換されるすべてのデータを暗号化する必要があります。したがって、サービスに対して TCP 接続が確立されると、TLS ハンドシェイクがすぐに開始されます。初期の非 TLS 接続をアップグレードするオプションは使用してはなりません。セクション 5.3 を参照してください。
To ensure clear separation between TACACS+ traffic using TLS and that which does not (see Section 5.3), servers supporting TACACS+ over TLS MUST listen on a TCP/IP port distinct from that used by non-TLS TACACS+ servers. It is further RECOMMENDED to deploy the TLS and non-TLS services on separate hosts, as discussed in Section 5.1.1.
TLS を使用する TACACS+ トラフィックとそれを使用しない TACACS+ トラフィックを明確に分離するために (セクション 5.3 を参照)、TLS 経由で TACACS+ をサポートするサーバーは、非 TLS TACACS+ サーバーが使用するものとは異なる TCP/IP ポートでリッスンしなければなりません (MUST)。セクション 5.1.1 で説明したように、TLS サービスと非 TLS サービスを別々のホストにデプロイすることがさらに推奨されます。
Given the prevalence of default port usage in existing TACACS+ client implementations, this specification assigns the well-known TCP port number 300 for TACACS+ over TLS (see Section 7).
既存の TACACS+ クライアント実装におけるデフォルト ポートの使用の普及を考慮して、この仕様では、TLS 上の TACACS+ に既知の TCP ポート番号 300 を割り当てます (セクション 7 を参照)。
While the use of the designated port number is strongly encouraged, deployments with specific requirements MAY use alternative TCP port numbers. In such cases, operators must carefully consider the operational implications described in Section 5.3.
指定されたポート番号の使用が強く推奨されますが、特定の要件がある展開では、代替の TCP ポート番号を使用してもよい(MAY)。このような場合、オペレーターはセクション 5.3 で説明されている運用上の影響を慎重に考慮する必要があります。
A TACACS+ client initiates a TLS connection by making a TCP connection to a configured TLS TACACS+ server on the TACACS+ TLS port number. Once the TCP connection is established, the client MUST immediately begin the TLS negotiation before sending any TACACS+ protocol data.
TACACS+ クライアントは、TACACS+ TLS ポート番号で設定された TLS TACACS+ サーバーへの TCP 接続を確立することにより、TLS 接続を開始します。TCP 接続が確立されたら、クライアントは TACACS+ プロトコル データを送信する前に、すぐに TLS ネゴシエーションを開始しなければなりません (MUST)。
A minimum of TLS 1.3 [RFC8446] MUST be used for transport. It is expected that TACACS+, as described in this document, will work with future versions of TLS. Earlier versions of TLS MUST NOT be used.
トランスポートには少なくとも TLS 1.3 [RFC8446] を使用しなければなりません (MUST)。このドキュメントで説明されているように、TACACS+ は TLS の将来のバージョンでも動作することが期待されています。以前のバージョンの TLS は使用してはなりません。
Once the TLS connection has been successfully established, the exchange of TACACS+ data MUST proceed in accordance with the procedures defined in [RFC8907]. However, all TACACS+ messages SHALL be transmitted as TLS application data. The TACACS+ obfuscation mechanism defined in [RFC8907] MUST NOT be applied when operating over TLS (Section 4).
TLS 接続が正常に確立されたら、[RFC8907] で定義された手順に従って TACACS+ データの交換を続行しなければなりません (MUST)。ただし、すべての TACACS+ メッセージは TLS アプリケーション データとして送信されるものとします (SHALL)。[RFC8907] で定義されている TACACS+ 難読化メカニズムは、TLS 上で動作する場合には適用してはなりません (セクション 4)。
TLS TACACS+ connections are generally not long-lived. The connection will be closed by either a peer if it encounters an error or an inactivity timeout.
TLS TACACS+ 接続は通常、存続期間が長くありません。エラーまたは非アクティブ タイムアウトが発生した場合、接続はピアによって閉じられます。
For connections not operating in Single Connection Mode (as defined in Section 4.3 of [RFC8907]), the TCP session SHALL be closed upon completion of the associated TACACS+ session. Connections operating in Single Connection Mode MAY persist for a longer duration but are typically subject to timeout and closure after a brief period of inactivity. Consequently, support for transport-layer keepalive mechanisms is not required.
シングル接続モード ([RFC8907] のセクション 4.3 で定義) で動作していない接続の場合、TCP セッションは、関連する TACACS+ セッションの完了時に閉じられるものとします (SHALL)。単一接続モードで動作する接続は、より長期間持続する場合がありますが、通常は短期間の非アクティブ状態の後にタイムアウトして終了する可能性があります。したがって、トランスポート層のキープアライブ メカニズムのサポートは必要ありません。
Why a connection is closed has no bearing on TLS resumption, unless closed by a TLS error, in which case it is possible that the ticket has been invalidated.
接続が閉じられた理由は、TLS エラーによって閉じられない限り、TLS の再開には関係ありません。TLS エラーによって閉じられた場合、チケットが無効になっている可能性があります。
TACACS+ clients and servers widely support IPv6 configuration in addition to IPv4. This document makes no changes to recommendations in this area.
TACACS+ クライアントおよびサーバは、IPv4 に加えて IPv6 設定を幅広くサポートしています。この文書では、この分野の推奨事項に変更は加えません。
Implementations MUST support certificate-based mutual authentication, to provide a core option for interoperability between deployments. This authentication option is specified in Section 3.4.
実装は、展開間の相互運用性のための中核となるオプションを提供するために、証明書ベースの相互認証をサポートしなければなりません (MUST)。この認証オプションはセクション 3.4 で指定されています。
In addition to certificate-based TLS authentication, implementations MAY support the following alternative authentication mechanisms:
証明書ベースの TLS 認証に加えて、実装は次の代替認証メカニズムをサポートしてもよい(MAY)。
* Pre-Shared Keys (PSKs) (Section 3.5), also known as external PSKs in TLS 1.3.
* 事前共有キー (PSK) (セクション 3.5)。TLS 1.3 では外部 PSK とも呼ばれます。
* Raw Public Keys (RPKs). The details of RPKs are considered out of scope for this document. Refer to [RFC7250] and Section 4.4.2 of [RFC8446] for implementation, deployment, and security considerations.
* 未加工の公開キー (RPK)。RPK の詳細は、このドキュメントの範囲外とみなされます。実装、展開、およびセキュリティに関する考慮事項については、[RFC7250] および [RFC8446] のセクション 4.4.2 を参照してください。
TLS certificate authentication is the primary authentication option for TACACS+ over TLS. This section covers certificate-based authentication only.
TLS 証明書認証は、TACACS+ over TLS の主要な認証オプションです。このセクションでは、証明書ベースの認証についてのみ説明します。
Deploying TLS certificate-based authentication correctly will considerably improve the security of TACACS+ deployments. It is essential for implementers and operators to understand the implications of a TLS certificate-based authentication solution, including the correct handling of certificates, Certificate Authorities (CAs), and all elements of TLS configuration. For guidance, start with [BCP195].
TLS 証明書ベースの認証を正しく展開すると、TACACS+ 展開のセキュリティが大幅に向上します。実装者と運用者は、証明書、認証局 (CA)、および TLS 構成のすべての要素の正しい処理を含む、TLS 証明書ベースの認証ソリューションの影響を理解することが重要です。ガイダンスとして、[BCP195] から始めてください。
Each peer MUST validate the certificate path of its remote peer, including revocation checking, as described in Section 3.4.1.
各ピアは、セクション 3.4.1 で説明されているように、失効チェックを含めて、リモート ピアの証明書パスを検証しなければなりません (MUST)。
If the verification succeeds, the authentication is successful and the connection is permitted. Policy may impose further constraints upon the peer, allowing or denying the connection based on certificate fields or any other parameters exposed by the implementation.
検証が成功すると、認証が成功し、接続が許可されます。ポリシーはピアにさらなる制約を課し、証明書フィールドや実装によって公開されるその他のパラメータに基づいて接続を許可または拒否する場合があります。
Unless disabled by configuration, a peer MUST NOT permit connection of any peer that presents an invalid TLS certificate.
設定で無効にしない限り、ピアは無効な TLS 証明書を提示するピアの接続を許可してはなりません (MUST NOT)。
The implementation of certificate-based mutual authentication MUST support certificate path validation as described in Section 6 of [RFC5280].
証明書ベースの相互認証の実装は、[RFC5280] のセクション 6 で説明されているように、証明書パスの検証をサポートしなければなりません (MUST)。
In some deployments, a peer may be isolated from a remote peer's CA. Implementations for these deployments MUST support certificate chains (aka bundles or chains of trust), where the entire chain of the remote peer's certificate is stored on the local peer.
一部の展開では、ピアがリモート ピアの CA から分離される場合があります。これらの展開の実装では、リモート ピアの証明書のチェーン全体がローカル ピアに保存される証明書チェーン (別名バンドルまたは信頼チェーン) をサポートしなければなりません。
TLS Cached Information Extension [RFC7924] SHOULD be implemented. This MAY be augmented with RPKs [RFC7250], though revocation must be handled as it is not part of that specification.
TLS キャッシュ情報拡張 [RFC7924] を実装すべきです (SHOULD)。これは RPK [RFC7250] で拡張してもよい (MAY) が、失効はその仕様の一部ではないため処理する必要がある。
Other approaches may be used for loading the intermediate certificates onto the client, but they MUST include support for revocation checking. For example, [RFC5280] details the Authority Information Access (AIA) extension to provide information about the issuer of the certificate in which the extension appears. It can be used to provide the address of the Online Certificate Status Protocol (OCSP) responder from where the revocation status of the certificate (which includes the extension) can be checked.
中間証明書をクライアントにロードするために他のアプローチを使用することもできますが、失効チェックのサポートを含める必要があります。たとえば、[RFC5280] では、Authority Information Access (AIA) 拡張機能について詳しく説明し、拡張機能が含まれる証明書の発行者に関する情報を提供します。これを使用して、証明書 (拡張子を含む) の失効ステータスを確認できるオンライン証明書ステータス プロトコル (OCSP) レスポンダーのアドレスを提供できます。
For the client-side validation of presented TLS TACACS+ server identities, implementations MUST follow the validation techniques defined in [RFC9525]. Identifier types DNS-ID, IP-ID, or SRV-ID are applicable for use with the TLS TACACS+ protocol; they are selected by operators depending upon the deployment design. TLS TACACS+ does not use URI-IDs for TLS TACACS+ server identity verification.
提示された TLS TACACS+ サーバー ID のクライアント側検証については、実装は [RFC9525] で定義されている検証手法に従わなければなりません (MUST)。識別子のタイプ DNS-ID、IP-ID、または SRV-ID は、TLS TACACS+ プロトコルでの使用に適用できます。これらは、展開設計に応じてオペレーターによって選択されます。TLS TACACS+ は、TLS TACACS+ サーバーの ID 検証に URI-ID を使用しません。
Wildcards in TLS TACACS+ server identities simplify certificate management by allowing a single certificate to secure multiple servers in a deployment. However, this introduces security risks, as compromising the private key of a wildcard certificate impacts all servers using it. To address these risks, the guidelines in Section 6.3 of [RFC9525] MUST be followed, and the wildcard SHOULD be confined to a subdomain dedicated solely to TACACS+ servers.
TLS TACACS+ サーバー ID のワイルドカードを使用すると、単一の証明書で展開内の複数のサーバーを保護できるため、証明書の管理が簡素化されます。ただし、ワイルドカード証明書の秘密キーが侵害されると、それを使用するすべてのサーバーに影響が及ぶため、セキュリティ リスクが生じます。これらのリスクに対処するには、[RFC9525] のセクション 6.3 のガイドラインに従わなければならず (MUST)、ワイルドカードは TACACS+ サーバー専用のサブドメインに限定すべきである (SHOULD)。
For the TLS TACACS+ server-side validation of client identities, implementations MUST support the ability to configure which fields of a certificate are used for client identification to verify that the client is a valid source for the received certificate and that it is permitted access to TACACS+. Implementations MUST support either:
クライアント ID の TLS TACACS+ サーバー側検証の場合、実装は、クライアントが受信した証明書の有効なソースであること、および TACACS+ へのアクセスが許可されていることを検証するために、クライアントの識別に使用される証明書のフィールドを設定する機能をサポートしなければなりません (MUST)。実装では次のいずれかをサポートする必要があります。
* Network-address-based validation methods as described in Section 5.2 of [RFC5425] or
* [RFC5425] のセクション 5.2 に記載されているネットワークアドレスベースの検証方法、または
* Client Identity validation of a shared identity in the certificate subjectAltName. This is applicable in deployments where the client securely supports an identity which is shared with the TLS TACACS+ server. Matching of dNSName and iPAddress MUST be supported. Other options defined in Section 4.2.1.6 of [RFC5280] MAY be supported. This approach allows a client's network location to be reconfigured without issuing a new client certificate.
* 証明書 subjectAltName 内の共有 ID のクライアント ID 検証。これは、クライアントが TLS TACACS+ サーバーと共有される ID を安全にサポートする展開に適用されます。dNSName と iPAddress の一致がサポートされなければなりません。[RFC5280] のセクション 4.2.1.6 で定義されている他のオプションがサポートされてもよい(MAY)。このアプローチにより、新しいクライアント証明書を発行せずにクライアントのネットワークの場所を再構成できます。
Implementations MUST support the TLS Server Name Indication (SNI) extension (Section 3 of [RFC6066]). TLS TACACS+ clients MUST support the ability to configure the TLS TACACS+ server's domain name, so that it may be included in the SNI "server_name" extension of the client hello (This is distinct from the IP Address or hostname configuration used for the TCP connection). Refer to Section 5.1.5 for security related operator considerations.
実装は、TLS Server Name Indication (SNI) 拡張機能 ([RFC6066] のセクション 3) をサポートしなければなりません (MUST)。TLS TACACS+ クライアントは、クライアント hello の SNI "server_name" 拡張子にドメイン名が含まれるように、TLS TACACS+ サーバーのドメイン名を設定する機能をサポートしなければなりません (これは、TCP 接続に使用される IP アドレスまたはホスト名の設定とは異なります)。セキュリティ関連のオペレータの考慮事項については、セクション 5.1.5 を参照してください。
Certificate provisioning is out of scope of this document.
証明書のプロビジョニングはこのドキュメントの範囲外です。
Implementations MUST support the TLS 1.3 mandatory cipher suites (Section 9.1 of [RFC8446]). Readers should refer to [BCP195]. The cipher suites offered or accepted SHOULD be configurable so that operators can adapt.
実装は、TLS 1.3 必須暗号スイート ([RFC8446] のセクション 9.1) をサポートしなければなりません (MUST)。読者は [BCP195] を参照してください。提供または受け入れられる暗号スイートは、オペレータが適応できるように構成可能であるべきです(SHOULD)。
As an alternative to certificate-based authentication, implementations MAY support PSKs, also known as external PSKs in TLS 1.3 [RFC8446]. These should not be confused with resumption PSKs.
証明書ベースの認証の代替として、実装は TLS 1.3 [RFC8446] では外部 PSK とも呼ばれる PSK をサポートしてもよい(MAY)。これらを再開 PSK と混同しないでください。
The use of external PSKs is less well established than certificate-based authentication. It is RECOMMENDED that systems follow the directions of [RFC9257] and Section 4 of [RFC8446].
外部 PSK の使用は、証明書ベースの認証ほど確立されていません。システムが [RFC9257] および [RFC8446] のセクション 4 の指示に従うことが推奨されます。
Where PSK authentication is implemented, PSK lengths of at least 16 octets MUST be supported.
PSK 認証が実装されている場合、少なくとも 16 オクテットの PSK 長がサポートされなければなりません (MUST)。
PSK identity MUST follow recommendations of Section 6.1 of [RFC9257]. Implementations MUST support PSK identities of at least 16 octets.
PSK ID は、[RFC9257] のセクション 6.1 の推奨事項に従わなければなりません (MUST)。実装は少なくとも 16 オクテットの PSK ID をサポートしなければなりません (MUST)。
Although this document removes the option of obfuscation (Section 4), it is still possible that the TLS and non-TLS versions of TACACS+ exist in an organization, for example, during migration (Section 6.1). In such cases, the shared secrets configured for TACACS+ obfuscation clients MUST NOT be the same as the PSKs configured for TLS clients.
この文書では難読化のオプション (セクション 4) が削除されていますが、移行中などに TACACS+ の TLS バージョンと非 TLS バージョンが組織内に存在する可能性があります (セクション 6.1)。このような場合、TACACS+ 難読化クライアント用に設定された共有秘密は、TLS クライアント用に設定された PSK と同じであってはなりません。
TLS Resumption [RFC8446] can minimize the number of round trips required during the handshake process. If a TLS client holds a ticket previously extracted from a NewSessionTicket message from the TLS TACACS+ server, it can use the PSK identity tied to that ticket. If the TLS TACACS+ server consents, the resumed session is acknowledged as authenticated and securely linked to the initial session.
TLS Resumption [RFC8446] は、ハンドシェイクプロセス中に必要なラウンドトリップ数を最小限に抑えることができます。TLS クライアントが、TLS TACACS+ サーバーからの NewSessionTicket メッセージから以前に抽出されたチケットを保持している場合、そのチケットに関連付けられた PSK ID を使用できます。TLS TACACS+ サーバーが同意すると、再開されたセッションは認証されたものとして認識され、最初のセッションに安全にリンクされます。
The client SHOULD use resumption when it holds a valid unused ticket from the TLS TACACS+ server, as each ticket is intended for a single use only and will be refreshed during resumption. The TLS TACACS+ server can reject a resumption request, but the TLS TACACS+ server SHOULD allow resumption if the ticket in question has not expired and has not been used before.
クライアントは、TLS TACACS+ サーバーからの有効な未使用のチケットを保持している場合、再開を使用する必要があります。各チケットは 1 回のみの使用を目的としており、再開中に更新されるためです。TLS TACACS+ サーバーは再開リクエストを拒否できますが、問題のチケットの有効期限が切れておらず、以前に使用されていない場合、TLS TACACS+ サーバーは再開を許可すべきです(SHOULD)。
When a TLS TACACS+ server is presented with a resumption request from the TLS client, it MAY still choose to require a full handshake. In this case, the negotiation proceeds as if the session was a new authentication, and the resumption attempt is ignored. As described in Appendix C.4 of [RFC8446], reuse of a ticket allows passive observers to correlate different connections. TLS TACACS+ clients and servers SHOULD follow the client tracking preventions in Appendix C.4 of [RFC8446].
TLS TACACS+ サーバーが TLS クライアントから再開リクエストを受け取った場合でも、完全なハンドシェイクを要求することを選択してもよい(MAY)。この場合、ネゴシエーションはセッションが新しい認証であるかのように進行し、再開の試行は無視されます。[RFC8446] の付録 C.4 で説明されているように、チケットの再利用により、受動的なオブザーバーがさまざまな接続を関連付けることができます。TLS TACACS+ クライアントとサーバーは、[RFC8446] の付録 C.4 にあるクライアント追跡防止に従う必要があります (SHOULD)。
When processing TLS resumption, certificates must be verified to check for revocation during the period since the last NewSessionTicket Message.
TLS 再開を処理する場合、最後の NewSessionTicket メッセージ以降の期間中に証明書が失効していないかどうかを確認するために証明書を検証する必要があります。
The resumption ticket_lifetime SHOULD be configurable, including a zero seconds lifetime. Refer to Section 4.6.1 of [RFC8446] for guidance on ticket lifetime.
再開の ticket_lifetime は、0 秒の有効期間を含めて設定可能である必要があります (SHOULD)。チケットの有効期間に関するガイダンスについては、[RFC8446] のセクション 4.6.1 を参照してください。
The obfuscation mechanism documented in Section 4.5 of [RFC8907] is weak.
[RFC8907] のセクション 4.5 に文書化されている難読化メカニズムは弱いです。
The introduction of TLS authentication and encryption to TACACS+ replaces this former mechanism, so obfuscation is hereby obsoleted. This section describes how the TACACS+ client and servers MUST operate regarding the obfuscation mechanism.
TACACS+ への TLS 認証と暗号化の導入により、この以前のメカニズムが置き換えられるため、難読化は廃止されます。このセクションでは、TACACS+ クライアントとサーバーが難読化メカニズムに関してどのように動作しなければならないかについて説明します。
Peers MUST NOT use obfuscation with TLS.
ピアは TLS による難読化を使用してはなりません。
A TACACS+ client initiating a TACACS+ TLS connection MUST set the TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that obfuscation is not used for the session. All subsequent packets MUST have the TAC_PLUS_UNENCRYPTED_FLAG bit set to 1.
TACACS+ TLS 接続を開始する TACACS+ クライアントは、TAC_PLUS_UNENCRYPTED_FLAG ビットを設定し、セッションで難読化が使用されていないことをアサートする必要があります。後続のすべてのパケットでは、TAC_PLUS_UNENCRYPTED_FLAG ビットが 1 に設定されていなければなりません。
A TLS TACACS+ server that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 over a TLS connection MUST return an error of TAC_PLUS_AUTHEN_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR, or TAC_PLUS_ACCT_STATUS_ERROR as appropriate for the TACACS+ message type, with the TAC_PLUS_UNENCRYPTED_FLAG bit set to 1, and terminate the session. This behavior corresponds to that defined in Section 4.5 of [RFC8907] regarding data obfuscation for TAC_PLUS_UNENCRYPTED_FLAG or key mismatches.
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 に設定し、セッションを終了します。この動作は、TAC_PLUS_UNENCRYPTED_FLAG のデータ難読化またはキーの不一致に関して [RFC8907] のセクション 4.5 で定義されている動作に対応します。
A TACACS+ client that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 MUST terminate the session, and SHOULD log this error.
TAC_PLUS_UNENCRYPTED_FLAG ビットが 1 に設定されていないパケットを受信した TACACS+ クライアントは、セッションを終了しなければならず (MUST)、このエラーをログに記録すべきです (SHOULD)。
This document improves the confidentiality, integrity, and authentication of the connection and network traffic between TACACS+ peers by adding TLS support.
このドキュメントでは、TLS サポートを追加することで、TACACS+ ピア間の接続とネットワーク トラフィックの機密性、整合性、認証を向上させます。
Simply adding TLS support to the protocol does not guarantee the protection of the TLS TACACS+ server and clients. It is essential for the operators and equipment vendors to adhere to the latest best practices for ensuring the integrity of network devices and selecting secure TLS key and encryption algorithms.
プロトコルに TLS サポートを追加するだけでは、TLS TACACS+ サーバーとクライアントの保護は保証されません。通信事業者と機器ベンダーは、ネットワーク デバイスの整合性を確保し、安全な TLS キーと暗号化アルゴリズムを選択するための最新のベスト プラクティスに従うことが重要です。
[BCP195] offers substantial guidance for implementing and deploying protocols that use TLS. Those implementing and deploying Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3 outlined in [BCP195] or its subsequent versions.
[BCP195] は、TLS を使用するプロトコルの実装と展開に関する重要なガイダンスを提供します。Secure TACACS+ を実装および展開する場合は、[BCP195] またはその後続バージョンで概説されている TLS 1.3 に関連する推奨事項に従う必要があります。
This document outlines additional restrictions permissible under [BCP195]. For example, any recommendations referring to TLS 1.2, including the mandatory support, are not relevant for Secure TACACS+, as TLS 1.3 or above is mandated.
この文書は、[BCP195] で許容される追加の制限について概説します。たとえば、必須サポートを含む TLS 1.2 に関する推奨事項は、TLS 1.3 以降が必須であるため、Secure TACACS+ には関係ありません。
This document concerns the use of TLS as transport for TACACS+ and does not make any changes to the core TACACS+ protocol, other than the direct implications of deprecating obfuscation. Operators MUST be cognizant of the security implications of the TACACS+ protocol itself. Further documents are planned, for example, to address the security implications of password-based authentication and enhance the protocol to accommodate alternative schemes.
この文書は、TACACS+ のトランスポートとしての TLS の使用に関するものであり、難読化の廃止による直接的な影響を除き、コア TACACS+ プロトコルに変更を加えるものではありません。オペレータは、TACACS+ プロトコル自体のセキュリティへの影響を認識しなければなりません。たとえば、パスワードベースの認証のセキュリティへの影響に対処し、代替スキームに対応するためにプロトコルを強化するために、さらなる文書が計画されています。
New TACACS+ production deployments SHOULD use TLS authentication and encryption. Also see [RFC3365].
新しい TACACS+ 実稼働展開では、TLS 認証と暗号化を使用する必要があります (SHOULD)。[RFC3365]も参照してください。
TLS TACACS+ servers (as defined in Section 2) MUST NOT allow non-TLS connections, because of the threat of downgrade attacks or misconfiguration described in Section 5.3. Instead, separate non-TLS TACACS+ servers SHOULD be set up to cater for these clients.
TLS TACACS+ サーバー (セクション 2 で定義) は、セクション 5.3 で説明されているダウングレード攻撃または構成ミスの脅威のため、非 TLS 接続を許可してはなりません (MUST NOT)。代わりに、これらのクライアントに対応するために、別個の非 TLS TACACS+ サーバーをセットアップする必要があります (SHOULD)。
It is NOT RECOMMENDED that TLS TACACS+ servers and non-TLS TACACS+ servers be deployed on the same host, for reasons discussed in Section 5.3. Non-TLS connections would be better served by deploying the required non-TLS TACACS+ servers on separate hosts.
セクション 5.3 で説明した理由により、TLS TACACS+ サーバーと非 TLS TACACS+ サーバーを同じホストに展開することは推奨されません。非 TLS 接続は、必要な非 TLS TACACS+ サーバーを別のホストに展開することによって、より適切に提供されます。
TACACS+ clients MUST NOT fail back to a non-TLS connection if a TLS connection fails. This prohibition includes during the migration of a deployment (Section 6.1).
TACACS+ クライアントは、TLS 接続が失敗した場合に非 TLS 接続にフェールバックしてはなりません (MUST NOT)。この禁止事項には、デプロイメントの移行中も含まれます (セクション 6.1)。
TLS 1.3 resumption and PSK techniques make it possible to send early data, aka 0-RTT data, data that is sent before the TLS handshake completes. Replay of this data is a risk. Given the sensitivity of TACACS+ data, clients MUST NOT send data until the full TLS handshake completes; that is, clients MUST NOT send 0-RTT data and TLS TACACS+ servers MUST abruptly disconnect clients that do.
TLS 1.3 再開と PSK 技術により、TLS ハンドシェイクが完了する前に送信される初期データ (別名 0-RTT データ) を送信できるようになります。このデータの再生には危険が伴います。TACACS+ データの機密性を考慮すると、クライアントは完全な TLS ハンドシェイクが完了するまでデータを送信してはなりません。つまり、クライアントは 0-RTT データを送信してはならず、TLS TACACS+ サーバーは、送信したクライアントを突然切断しなければなりません (MUST)。
TLS TACACS+ clients and servers MUST NOT include the "early_data" extension. See Sections 2.3 and 4.2.10 of [RFC8446] for security concerns.
TLS TACACS+ クライアントおよびサーバーには、「early_data」拡張子を含めてはなりません。セキュリティ上の懸念については、[RFC8446] のセクション 2.3 および 4.2.10 を参照してください。
Recommendations in [BCP195] MUST be followed to determine which TLS versions and algorithms should be supported, deprecated, obsoleted, or abandoned.
どの TLS バージョンとアルゴリズムをサポートするか、非推奨にするか、廃止するか、放棄するかを決定するには、[BCP195] の推奨事項に従わなければなりません (MUST)。
Also, Section 9 of [RFC8446] prescribes mandatory supported options.
また、[RFC8446] のセクション 9 では、必須のサポートされるオプションが規定されています。
Operators should be cognizant of the potential of TLS TACACS+ server and/or client isolation from their peer's CA by network failures. Isolation from a public key certificate's CA will cause the verification of the certificate to fail and thus TLS authentication of the peer to fail. The approach mentioned in Section 3.4.1 can help address this and should be considered.
オペレータは、ネットワーク障害によって TLS TACACS+ サーバーやクライアントがピアの CA から分離される可能性があることを認識しておく必要があります。公開キー証明書の CA から分離すると、証明書の検証が失敗し、ピアの TLS 認証が失敗します。セクション 3.4.1 で説明したアプローチは、これに対処するのに役立つため、検討する必要があります。
Operators should be aware that the TLS SNI extension is part of the TLS client hello, which is sent in cleartext. It is, therefore, subject to eavesdropping. Also see Section 11.1 of [RFC6066].
オペレータは、TLS SNI 拡張が TLS クライアント hello の一部であり、クリアテキストで送信されることに注意する必要があります。したがって、盗聴される可能性があります。[RFC6066] のセクション 11.1 も参照してください。
The use of wildcards in TLS server identities creates a single point of failure: a compromised private key of a wildcard certificate impacts all servers using it. Their use MUST follow the recommendations of Section 7.1 of [RFC9525]. Operators MUST ensure that the wildcard is limited to a subdomain dedicated solely to TLS TACACS+ servers. Further, operators MUST ensure that the TLS TACACS+ servers covered by a wildcard certificate are impervious to redirection of traffic to a different server (for example, due to on-path attacks or DNS cache poisoning).
TLS サーバー ID でワイルドカードを使用すると、単一障害点が作成されます。つまり、ワイルドカード証明書の秘密キーが侵害されると、それを使用するすべてのサーバーが影響を受けます。それらの使用は、[RFC9525] のセクション 7.1 の推奨事項に従わなければなりません (MUST)。オペレーターは、ワイルドカードが TLS TACACS+ サーバー専用のサブドメインに限定されていることを確認する必要があります。さらに、運用者は、ワイルドカード証明書の対象となる TLS TACACS+ サーバーが、別のサーバーへのトラフィックのリダイレクト (たとえば、オンパス攻撃や DNS キャッシュ ポイズニングによる) の影響を受けないことを確認しなければなりません。
Implementors must ensure that the configuration scheme introduced for enabling TLS is straightforward and leaves no room for ambiguity regarding whether TLS or non-TLS will be used between the TACACS+ client and the TACACS+ server.
実装者は、TLS を有効にするために導入された設定スキームが単純であり、TACACS+ クライアントと TACACS+ サーバ間で TLS と非 TLS のどちらが使用されるかについてあいまいさが生じる余地がないことを確認する必要があります。
This document recommends the use of a separate port number that TLS TACACS+ servers will listen to. Where deployments have not overridden the defaults explicitly, TACACS+ client implementations MUST use the correct port values:
この文書では、TLS TACACS+ サーバーがリッスンする別のポート番号の使用を推奨します。導入でデフォルトが明示的にオーバーライドされていない場合、TACACS+ クライアント実装では正しいポート値を使用する必要があります。
* 49: for non-TLS connection TACACS+
* 49: 非 TLS 接続用 TACACS+
* 300: for TLS connection TACACS+
* 300: TLS 接続用 TACACS+
Implementors may offer a single option for TACACS+ clients and servers to disable all non-TLS TACACS+ operations. When enabled on a TACACS+ server, it will not respond to any requests from non-TLS TACACS+ client connections. When enabled on a TACACS+ client, it will not establish any non-TLS TACACS+ server connections.
実装者は、TACACS+ クライアントとサーバーに対して、TLS 以外の TACACS+ 操作をすべて無効にする単一のオプションを提供できます。TACACS+ サーバーで有効にすると、非 TLS TACACS+ クライアント接続からの要求に応答しなくなります。TACACS+ クライアントで有効にすると、非 TLS TACACS+ サーバー接続は確立されません。
A new port number is considered appropriate (rather than a mechanism that negotiates an upgrade from an initial non-TLS TACACS+ connection) because it allows:
新しいポート番号は、次のことが可能になるため、(最初の非 TLS TACACS+ 接続からのアップグレードをネゴシエートするメカニズムではなく) 適切であると考えられます。
* ease of blocking the unobfuscated or obfuscated connections by the TCP/IP port number,
* TCP/IP ポート番号による難読化されていない接続または難読化された接続のブロックの容易さ、
* passive Intrusion Detection Systems (IDSs) monitoring the unobfuscated to be unaffected by the introduction of TLS,
* TLS 導入による影響を受けないよう難読化されていないものを監視するパッシブ侵入検知システム (IDS)、
* avoidance of on-path attacks that can interfere with upgrade, and
* アップグレードを妨げる可能性のあるパス上の攻撃を回避します。
* prevention of the accidental exposure of sensitive information due to misconfiguration.
* 設定ミスによる機密情報の誤った公開を防止します。
However, the coexistence of inferior authentication and obfuscation, whether a non-TLS connection or deprecated parts that compose TLS, also presents an opportunity for downgrade attacks. Causing failure of connections to the TLS-enabled service or the negotiation of shared algorithm support are two such downgrade attacks.
ただし、非 TLS 接続であろうと、TLS を構成する非推奨の部分であろうと、劣った認証と難読化が共存すると、ダウングレード攻撃の機会も生じます。TLS 対応サービスへの接続の失敗を引き起こすこと、または共有アルゴリズム サポートのネゴシエーションは、このようなダウングレード攻撃の 2 つです。
The simplest mitigation exposure from non-TLS connection methods is to refuse non-TLS connections at the host entirely, perhaps using separate hosts for non-TLS connections and TLS.
非 TLS 接続方法による危険を軽減する最も簡単な方法は、非 TLS 接続と TLS に別のホストを使用するなどして、ホストで非 TLS 接続を完全に拒否することです。
Another approach is mutual configuration that requires TLS. TACACS+ clients and servers SHOULD support configuration that requires peers, globally and individually, to use TLS. Furthermore, peers SHOULD be configurable to limit offered or recognized TLS versions and algorithms to those recommended by standards bodies and implementers.
もう 1 つのアプローチは、TLS を必要とする相互構成です。TACACS+ クライアントとサーバーは、ピアがグローバルおよび個別に TLS を使用することを必要とする設定をサポートすべきです (SHOULD)。さらに、ピアは、提供または認識されている TLS バージョンおよびアルゴリズムを、標準化団体および実装者が推奨するものに制限するように構成可能であるべきです(SHOULD)。
Operational and deployment considerations are spread throughout the document. While avoiding repetition, it is useful for the impatient to direct particular attention to Sections 5.2 and 5.1.5. However, it is important that the entire Section 5 is observed.
運用および導入に関する考慮事項がドキュメント全体に渡って記載されています。繰り返しを避けながら、せっかちな方はセクション 5.2 と 5.1.5 に特に注意を向けると役立ちます。ただし、セクション 5 全体を遵守することが重要です。
It is essential for operators to understand the implications of a TLS certificate-based authentication solution, including the correct handling of certificates, CAs, and all elements of TLS configuration. Refer to [BCP195] for guidance. Attention is drawn to the provisioning of certificates to all peers, including TACACS+ TLS clients, to permit the mandatory mutual authentication.
通信事業者は、証明書、CA、および TLS 構成のすべての要素の正しい処理を含む、TLS 証明書ベースの認証ソリューションの影響を理解することが重要です。ガイダンスについては、[BCP195] を参照してください。必須の相互認証を許可するために、TACACS+ TLS クライアントを含むすべてのピアに証明書をプロビジョニングすることに注意してください。
Section 5.2 mentions that for an optimal deployment of TLS TACACS+, TLS should be universally applied throughout the deployment. However, during the migration process from a non-TLS TACACS+ deployment, operators may need to support both TLS and non-TLS TACACS+ servers. This migration phase allows operators to gradually transition their deployments from an insecure state to a more secure one, but it is important to note that it is vulnerable to downgrade attacks. Therefore, the migration phase should be considered insecure until it is fully completed. To mitigate this hazard:
セクション 5.2 では、TLS TACACS+ を最適に展開するには、展開全体にわたって TLS を普遍的に適用する必要があると述べています。ただし、非 TLS TACACS+ 導入環境からの移行プロセス中に、オペレーターは TLS サーバーと非 TLS TACACS+ サーバーの両方をサポートする必要がある場合があります。この移行フェーズにより、事業者は展開を安全でない状態からより安全な状態に徐々に移行できますが、ダウングレード攻撃に対して脆弱であることに注意することが重要です。したがって、移行フェーズは完全に完了するまでは安全ではないと考えるべきです。この危険を軽減するには:
* The period where any client is configured with both TLS and non-TLS TACACS+ servers should be minimized.
* クライアントが TLS と非 TLS TACACS+ サーバーの両方で構成されている期間は、最小限に抑える必要があります。
* The operator must consider the security impact of supporting both TLS and non-TLS connections, as mentioned above.
* 前述したように、通信事業者は、TLS 接続と非 TLS 接続の両方をサポートすることによるセキュリティへの影響を考慮する必要があります。
Some TACACS+ client devices in a deployment may not implement TLS. These devices will require access to non-TLS TACACS+ servers. Operators must follow the recommendation of Section 5.1.1 and deploy separate non-TLS TACACS+ servers for these non-TLS clients from those used for the TLS clients.
導入環境内の一部の TACACS+ クライアント デバイスは TLS を実装していない場合があります。これらのデバイスは、非 TLS TACACS+ サーバーにアクセスする必要があります。オペレータは、セクション 5.1.1 の推奨事項に従い、これらの非 TLS クライアントに対して、TLS クライアントに使用されるものとは別の非 TLS TACACS+ サーバーを展開する必要があります。
[TACACS-YANG] specifies a YANG model for managing TACACS+ clients, including TLS support.
[TACACS-YANG] は、TLS サポートを含む、TACACS+ クライアントを管理するための YANG モデルを指定します。
IANA has allocated the following new well-known system in the "Service Name and Transport Protocol Port Number Registry" (see <https://www.iana.org/assignments/service-names-port-numbers>). The service name "tacacss" follows the common practice of appending an "s" to the name given to the non-TLS well-known port name. See the justification for the allocation in Section 5.3.
IANA は、次の新しい既知のシステムを「サービス名およびトランスポート プロトコル ポート番号レジストリ」に割り当てました (<https://www.iana.org/assignments/service-names-port-numbers> を参照)。サービス名「tacacss」は、非 TLS の既知のポート名に与えられた名前に「s」を追加するという一般的な慣行に従っています。セクション 5.3 の割り当ての正当性を参照してください。
Service Name:
サービス名：
tacacss
タカックス
Port Number:
ポート番号:
300
300
Transport Protocol:
トランスポートプロトコル:
TCP
TCP
Description:
説明：
TLS Secure Login Host Protocol (TACACSS)
TLS セキュア ログイン ホスト プロトコル (TACACSS)
Assignee:
譲受人:
IESG
IESG
Contact:
接触：
IETF Chair
IETF議長
Reference:
参照：
RFC 9887
RFC 9887
Considerations about service discovery are out of scope of this document.
サービス検出に関する考慮事項は、このドキュメントの範囲外です。
The author(s) would like to thank Russ Housley, Steven M. Bellovin, Stephen Farrell, Alan DeKok, Warren Kumari, Tom Petch, Tirumal Reddy, Valery Smyslov, and Mohamed Boucadair for their support, insightful review, and/or comments. [RFC5425] was also used as a basis for the general approach to TLS. [RFC9190] was used as a basis for TLS resumption recommendations. Although still in draft form at the time of writing, [RFC9813] was used as a model for PSK recommendations.
著者は、Russ Housley、Steven M. Bellovin、Stephen Farrell、Alan DeKok、Warren Kumari、Tom Petch、Tirumal Reddy、Valery Smyslov、および Mohamed Boucadair のサポート、洞察力に富んだレビュー、および/またはコメントに感謝します。[RFC5425] は、TLS への一般的なアプローチの基礎としても使用されました。[RFC9190] は TLS 再開勧告の基礎として使用されました。執筆時点ではまだ草稿の段階ですが、[RFC9813] は PSK 勧告のモデルとして使用されました。
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[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>.
[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>.
[RFC5425] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed.,
"Transport Layer Security (TLS) Transport Mapping for
Syslog", RFC 5425, DOI 10.17487/RFC5425, March 2009,
<https://www.rfc-editor.org/info/rfc5425>.
[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>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., 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>.
[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.C., Carrel, 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>.
[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>.
[FIPS-140-3]
NIST, "Security Requirements for Cryptographic Modules",
NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.140-3.pdf>.
[REQ-TLS13]
Salz, R. and N. Aviram, "New Protocols Using TLS Must
Require TLS 1.3", Work in Progress, Internet-Draft, draft-
ietf-uta-require-tls13-12, 14 April 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-uta-
require-tls13-12>.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61,
RFC 3365, DOI 10.17487/RFC3365, August 2002,
<https://www.rfc-editor.org/info/rfc3365>.
[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>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>.
[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood,
"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>.
[RFC9813] DeKok, A., "Operational Considerations for Using TLS Pre-
Shared Keys (TLS-PSKs) with RADIUS", BCP 243, RFC 9813,
DOI 10.17487/RFC9813, July 2025,
<https://www.rfc-editor.org/info/rfc9813>.
[TACACS-YANG]
Boucadair, M. and B. Wu, "A YANG Data Model for Terminal
Access Controller Access-Control System Plus (TACACS+)",
Work in Progress, Internet-Draft, draft-ietf-opsawg-
secure-tacacs-yang-13, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
secure-tacacs-yang-13>.
Thorsten Dahm
Email: thorsten.dahm@gmail.com
John Heasley
NTT
Email: heas@shrubbery.net
Douglas C. Medway Gash
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: dcmgash@cisco.com
Andrej Ota
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: andrej@ota.si