<?xml version='1.0'encoding='utf-8'?> <!-- -*- indent-with-tabs: 0 -*- --> <?xml-model href="rfc7991bis.rnc"?> <!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> --> <!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc docName="draft-ietf-opsawg-tacacs-tls13-24" number="9887" category="std" ipr="trust200902" submissionType='IETF' consensus="true" updates="8907" obsoletes="" xmlns:xi="http://www.w3.org/2001/XInclude" version="3" sortRefs="true"indexInclude="false" tocDepth="3">symRefs="true" tocInclude="true" tocDepth="3" xml:lang="en"> <front> <title abbrev="TACACS+ over TLS1.3"> Terminal1.3">Terminal Access Controller Access-Control System Plusover TLS 1.3 (TACACS+ over TLS) </title>(TACACS+) over TLS 1.3</title> <seriesInfo name="RFC" value="9887"/> <author fullname="Thorsten Dahm" initials="T." surname="Dahm"> <address><postal> <street></street> <code></code> <city></city> <country></country> </postal><email>thorsten.dahm@gmail.com</email> </address> </author> <author fullname="John Heasley" initials="J." surname="Heasley"> <organization abbrev="NTT">NTT</organization> <address><postal> <street></street> <code></code> <city></city> <country></country> </postal><email>heas@shrubbery.net</email> </address> </author> <author initials="D.C." surname="Medway Gash" fullname="Douglas C. Medway Gash"> <organization>Cisco Systems, Inc.</organization> <address> <postal> <street>170 West Tasman Dr.</street> <city>San Jose</city> <region>CA</region> <code>95134</code> <country>United States of America</country> </postal> <email>dcmgash@cisco.com</email><uri/></address> </author> <author initials="A." surname="Ota" fullname="Andrej Ota"> <organization>Google Inc.</organization> <address> <postal> <street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>United States of America</country> </postal><phone/><email>andrej@ota.si</email><uri/></address> </author><date/> <area>Operations and Management Area (ops)</area> <workgroup>Operations and Management Area Working Group</workgroup><date month="October" year="2025"/> <area>OPS</area> <workgroup>opsawg</workgroup> <keyword>TACACS+</keyword> <abstract> <t> 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,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 bestpractices. </t>practices.</t> <t>This document updates RFC 8907.</t> </abstract><note title="Requirements Language"> <t> 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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </note></front> <middle><section title="Introduction"><section> <name>Introduction</name> <t>The <xref target="RFC8907">Terminal"The Terminal Access Controller Access-Control System Plus (TACACS+)Protocol </xref>Protocol" <xref target="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,authorizationauthorization, and accounting services (AAA) for TACACS+ clients within the device administration use case. </t><t><!-- [rfced] May we update this text for readability? Original: While the content of the protocol is highly sensitive, TACACS+ lacks effective confidentiality, integrity, and authentication of the connection and network traffic between the TACACS+ server and client, requiring secure transport to safeguard a deployment. The security mechanisms as described in Section 10 of [RFC8907] are extremely weak. Suggested: 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 10 of [RFC8907] are extremely weak. --> <t> While the content of the protocol is highly sensitive, TACACS+ lacks effective confidentiality, integrity, and authentication of the connection and network traffic between the TACACS+ server and client, requiring secure transport to safeguard a deployment. The security mechanisms as described in <xreftarget="RFC8907"/>target="RFC8907" section="10"/> are extremely weak. </t> <t> To address these deficiencies, this document updates the TACACS+ protocol to use<xref target="RFC8446">TLS 1.3</xref>authentication andencryption,encryption <xref target="RFC8446" />, and obsoletes the use of TACACS+ obfuscation mechanisms(Section 10.5 of <xref target="RFC8907"/>).(<xref target="RFC8907" section="10.5"/>). The maturity of TLS in version 1.3 and above makes it a suitable choice for the TACACS+ protocol. </t> </section> <sectiontitle="Technical Definitions"anchor="TLSTacacsServerDefinition"> <name>Technical Definitions</name> <t> The terms defined inSection 3 of<xreftarget="RFC8907"/>target="RFC8907" section="3"/> are fully applicable here and will not be repeated. The following terms are also used in this document. </t><t> Obfuscation: TACACS+<dl> <dt>Obfuscation:</dt> <dd>TACACS+ was originally intended to incorporate a mechanism for securing the body of its packets. The algorithm is categorized as Obfuscation in <xref target="RFC8907" section="10.5.2"/>. The term is used to ensure that the algorithm is not mistaken for encryption. It should not be consideredsecure. </t> <t> Non-TLS connection: Thissecure.</dd> <!-- [rfced] Should "for test" be "for testing"? Original: It is a connection without TLS, using the unsecure TACACS+ authentication and obfuscation (or the unobfuscated option for test). --> <dt>Non-TLS connection:</dt> <dd>This term refers to the connection defined in <xref target="RFC8907"/>. It is a connection without TLS, using the unsecure TACACS+ authentication and obfuscation (or the unobfuscated option for test). The use of well-known TCP/IP host port number 49 is specified as the default forNon-TLS connections. </t> <t>non-TLS connections.</dd> <dt> TLSconnection: Aconnection:</dt> <dd>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.</t> <t></dd> <dt> TLS TACACS+server: Thisserver:</dt> <dd>This document describes a variant of the TACACS+ server, introduced inSection 3.2 of [RFC8907],<xref section="3.2" target="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 orNon-TLS)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,clients to ensure they direct their traffic to the correct TACACS+ servers.</t> <t> Peer: The</dd> <dt> Peer:</dt> <dd>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. </dd> </dl> <section> <name>Requirements Language</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section><section title="TACACS+</section> <section> <name>TACACS+ overTLS">TLS</name> <t> TACACS+ over TLS takes the protocol defined in <xref target="RFC8907"/>, removes the option for MD5 obfuscation, and specifies that TLS 1.3 be used for transport (<xref target="TLSPort"/> elaborates on TLS version support). A new well-known default host port number is used. The next sections provide further details and guidance. </t> <t>TLS is introduced into TACACS+ to fulfill the following requirements: </t> <ol> <li>Confidentiality and Integrity: The MD5 algorithm underlying the obfuscation mechanism specified in <xref target="RFC8907"/> has been shown to be insecure <xref target="RFC6151"/> when used for encryption. This prevents TACACS+ from being used in a<xref target="FIPS-140-3"/> -deployment compliantdeployment.with <xref target="FIPS-140-3"/>. Securing the TACACS+ protocol with TLS is intended to provide confidentiality and integrity without requiring the provision of a secured network. </li> <li>Peer authentication: The authentication capabilities of TLS replace the shared secrets of obfuscation for mutual authentication. </li> </ol> <t>This document adheres to the recommendations in <xref target="I-D.ietf-uta-require-tls13"/>.</t> <sectiontitle="Separating TLS Connections"anchor="TLSPort"> <name>Separating TLS Connections</name> <t> Peers implementing the TACACS+ protocol variant defined in this documentMUST<bcp14>MUST</bcp14> 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. Optionswhichthat upgrade an initialNon-TLS connection, MUST NOTnon-TLS connection <bcp14>MUST NOT</bcp14> beused,used; see <xref target="wellknown"/>. </t> <t> To ensure clear separation between TACACS+ traffic using TLS and that which does not (see <xref target="wellknown"/>), servers supporting TACACS+ over TLSMUST<bcp14>MUST</bcp14> listen on a TCP/IP port distinct from that used by non-TLS TACACS+ servers. It is furtherRECOMMENDED<bcp14>RECOMMENDED</bcp14> to deploy the TLS and non-TLS services on separate hosts, as discussed in <xref target="TLSUSE"/>. </t> <t> Given the prevalence of default port usage in existing TACACS+ client implementations, this specification assigns a well-known TCP port number for TACACS+ over TLS:<xref target="ICTBD">[TBD]</xref>,300, with the associated service name "tacacss" (see <xreftarget="ICTBD"/>.target="ICTBD"/>). This allows clients to unambiguously distinguish between TLS and non-TLS connections, even in the absence of an explicitly configured port number. </t> <t> While the use of the designated port number is strongly encouraged, deployments with specific requirementsMAY<bcp14>MAY</bcp14> use alternative TCP port numbers. In such cases, operators must carefully consider the operational implications described in <xref target="wellknown"/>. </t> </section> <sectiontitle="TLS Connection"anchor="TLSConn"> <name>TLS Connection</name> <t> 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 clientMUST<bcp14>MUST</bcp14> immediately begin the TLS negotiation before sending any TACACS+ protocol data. </t> <t>MinimumA minimum of TLS 1.3 <xreftarget="RFC8446">TLS 1.3</xref> MUSTtarget="RFC8446"/> <bcp14>MUST</bcp14> be used fortransport, ittransport. It is expected thatTACACS+TACACS+, as described in thisdocumentdocument, will work with future versions of TLS. Earlier versions of TLSMUST NOT<bcp14>MUST NOT</bcp14> be used. </t> <t> Once the TLS connection has been successfully established, the exchange of TACACS+ dataMUST<bcp14>MUST</bcp14> proceed in accordance with the procedures defined in <xreftarget="RFC8907"/>,target="RFC8907"/>. However, all TACACS+ messagesSHALL<bcp14>SHALL</bcp14> be transmitted as TLS application data. The TACACS+ obfuscation mechanism defined in <xref target="RFC8907"/>MUST NOT<bcp14>MUST NOT</bcp14> be applied when operating over TLS (<xref target="ObsolescenceOfTACACSObfuscation"/>).</t> <!-- [rfced] We recommend simplifying this sentence for clarity. Does the connection persist until either a) the TLS TACACS+ peer closes it or b) an inactivity timeout occurs? Please consider how the text may be updated. Original: The connection persists until the TLS TACACS+ peer closes it, either due to an error, or at the conclusion of the TACACS+ session, or, if Single Connection Mode (Section 4.3 of [RFC8907]) has been negotiated, when an inactivity timeout occurs. Perhaps: The connection persists until the TLS TACACS+ peer closes it or until an inactivity timeout occurs when Single Connection Mode (Section 4.3 of [RFC8907]) is used. The TLS TACACS+ peer may close the connection due to an error or because the TACACS+ session has concluded. --> <t> The connection persists until the TLS TACACS+ peer closes it, either due to an error, or at the conclusion of the TACACS+ session, or, if Single Connection Mode (<xref target="RFC8907" section="4.3"/>) has been negotiated, when an inactivity timeout occurs. Why it 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. </t> <t> TACACS+ connections are generally not long-lived. For connections not operating in Single Connection Mode (as defined in <xref target="RFC8907"section="4.3"/>)section="4.3"/>), the TCP sessionSHALL<bcp14>SHALL</bcp14> be closed upon completion of the associated TACACS+ session. Connections operating in Single Connection ModeMAY<bcp14>MAY</bcp14> 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. </t> <t> TACACS+ clients and servers widely support IPv6 configuration in addition to IPv4. This document makes no changes to recommendations in this area. </t> </section><section title="TLS<section> <name>TLS AuthenticationOptions">Options</name> <t> ImplementationsMUST<bcp14>MUST</bcp14> support certificate-based mutual authentication, to provide a core option for interoperability between deployments. This authentication option is specified in <xref target="CertAuth"/>. </t> <t> In addition to certificate-based TLS authentication, implementationsMAY<bcp14>MAY</bcp14> support the following alternative authentication mechanisms: </t> <ul> <li>Pre-Shared Keys (PSKs) (<xref target="PSKAuth"/>), also known as external PSKs in TLS 1.3. </li> <li>Raw Public Keys (RPKs). The details ofRPKRPKs are consideredout-of-scopeout of scope for this document. Refer to <xref target="RFC7250"/> and <xref target="RFC8446" section="4.4.2"/> for implementation, deployment, and security considerations. </li> </ul> </section> <sectiontitle="TLS Certificate-Based Authentication"anchor="CertAuth"> <name>TLS Certificate-Based Authentication</name> <t> TLS certificate authentication is the primary authentication option for TACACS+ over TLS. This section covers certificate-based authentication only.</t> <t>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 <xref target="BCP195"/>.</t> <t>Each peerMUST<bcp14>MUST</bcp14> validate the certificate path of its remote peer, including revocation checking, as described in <xref target="CertPV"/>. </t> <t> 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. </t> <t> Unless disabled by configuration, a peerMUST NOT<bcp14>MUST NOT</bcp14> permit connection of any peer that presents an invalid TLS certificate. </t> <sectiontitle="TLSanchor="CertPV"> <name>TLS Certificate PathVerification" anchor="CertPV"> <t>Verification</name> <!-- [rfced] "verification" does not appear in Section 6 of RFC 5280. Would it be helpful to the reader to use "validation" for consistency with the reference? Original: The implementation of certificate-based mutual authentication MUST support certificate path verification as described in Section 6 of [RFC5280]. --> <t> The implementation of certificate-based mutual authentication <bcp14>MUST</bcp14> support certificate path verification as described in <xref target="RFC5280" section="6"/>. </t> <t> In some deployments, a peer may be isolated from a remote peer's CA. Implementations for these deploymentsMUST<bcp14>MUST</bcp14> support certificate chains(a.k.a.(aka bundles or chains of trust), where the entire chain of theremote'sremote peer's certificate is stored on the local peer. </t> <t> TLS Cached Information Extension <xref target="RFC7924"/>SHOULD<bcp14>SHOULD</bcp14> be implemented. ThisMAY<bcp14>MAY</bcp14> be augmented with RPKs <xref target="RFC7250"/>, though revocation must be handled as it is not part ofthe standard.that specification. </t> <t> Other approaches may be used for loading the intermediate certificates onto the client, butMUSTthey <bcp14>MUST</bcp14> include support for revocation checking. For example, <xref target="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. </t> </section><section title="TLS<section> <name>TLS CertificateIdentification">Identification</name> <t>For the client-side validation of presented TLS TACACS+ server identities, implementationsMUST<bcp14>MUST</bcp14> follow<xref target="RFC9525"/>the validationtechniques.techniques defined in <xref target="RFC9525"/>. Identifier types DNS-ID, IP-ID, or SRV-ID are applicable for use with the TLS TACACS+protocol,protocol; they are selected by operators depending upon the deployment design. TLS TACACS+ does not use URI-IDs for TLS TACACS+ server identity verification.</t> <t>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 <xref target="RFC9525" section="6.3"/>MUST<bcp14>MUST</bcp14> be followed, and the wildcardSHOULD<bcp14>SHOULD</bcp14> be confined to a subdomain dedicated solely to TACACS+ servers.</t> <t> For the TLS TACACS+ server-side validation of client identities, implementationsMUST<bcp14>MUST</bcp14> support the ability to configure which fields of a certificate are used for clientidentification,identification to verify that the client is a valid source for the received certificate and that it is permitted access to TACACS+. ImplementationsMUST<bcp14>MUST</bcp14> supporteither: </t> <t>Network address basedeither:</t> <ul spacing="normal"> <li>Network-address-based validation methods as described in <xref target="RFC5425"section="5.2"/>. </t> <t>or</t> <t> Clientsection="5.2"/> or</li> <li>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 iPAddressMUST<bcp14>MUST</bcp14> be supported. Other options defined in <xref target="RFC5280" section="4.2.1.6"/>MAY<bcp14>MAY</bcp14> be supported. This approach allows a client's network location to be reconfigured without issuing a new clientcertificate. </t>certificate.</li></ul> <t> ImplementationsMUST<bcp14>MUST</bcp14> support the TLS Server Name Indicationextension(SNI) extension (<xref target="RFC6066" section="3"/>). TLS TACACS+ clientsMUST<bcp14>MUST</bcp14> 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 <xref target="TLSSNISec"/> for security related operator considerations. </t> <t>Certificate provisioning is out of scope of this document.</t> </section><section title="Cipher<section> <name>Cipher SuitesRequirements">Requirements</name> <t> ImplementationsMUST<bcp14>MUST</bcp14> support the TLS 1.3 mandatory cipher suites (<xref target="RFC8446" section="9.1"/>). Readers should refer to <xref target="BCP195"/>. The cipher suites offered or acceptedSHOULD<bcp14>SHOULD</bcp14> be configurable so that operators can adapt. </t> </section> </section> <sectiontitle="TLS PSK Authentication"anchor="PSKAuth"> <name>TLS PSK Authentication</name> <t> As an alternative to certificate-based authentication, implementationsMAY<bcp14>MAY</bcp14> support PSKs, also known asExternalexternal PSKs in TLS 1.3 <xref target="RFC8446"/>. These should not be confused with resumption PSKs. </t> <t> The use ofExternalexternal PSKs is less well established than certificate-based authentication. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that systems follow the directions of <xref target="RFC9257"/> and <xref target="RFC8446" section="4"/>. </t> <t> Where PSKAuthenticationauthentication is implemented, PSK lengths of at least 16 octetsMUST<bcp14>MUST</bcp14> be supported. </t> <t> PSKIdentity MUSTidentity <bcp14>MUST</bcp14> follow recommendations of <xref target="RFC9257" section="6.1"/>. ImplementationsMUST<bcp14>MUST</bcp14> support PSK identities of at least 16 octets. </t> <t> Although this document removes the option of MD5 obfuscation (<xref target="ObsolescenceOfTACACSObfuscation"/>), it is still possible that the TLS andNon-TLSnon-TLS versions of TACACS+mayexist in an organization, for example, during migration (<xref target="MIGRATION"/>). In such cases, the shared secrets configured for TACACS+ obfuscation clientsMUST NOT<bcp14>MUST NOT</bcp14> be the same as the PSKs configured for TLS clients. </t> <t> </t> </section> <sectiontitle="TLS Resumption"anchor="TLSResumption"> <name>TLS Resumption</name> <!-- [rfced] Is it correct to refer to the "TLS Resumption protocol"? Original: The TLS Resumption protocol, detailed in [RFC8446], can minimize the number of round trips required during the handshake process. Perhaps: TLS Resumption [RFC8446] can minimize the number of round trips required during the handshake process. --> <t> The TLS Resumption protocol, detailed in <xref target="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. </t> <t>The clientSHOULD<bcp14>SHOULD</bcp14> 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+ serverSHOULD<bcp14>SHOULD</bcp14> allow resumption if the ticket in question has not expired and has not been used before. </t> <t> When a TLS TACACS+ server is presented with a resumption request from the TLS client, itMAY<bcp14>MAY</bcp14> 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 <xref target="RFC8446" section="C.4"/>, reuse of a ticket allows passive observers to correlate different connections. TLS TACACS+ clients and serversSHOULD<bcp14>SHOULD</bcp14> follow the client tracking preventions in <xref target="RFC8446" section="C.4"/>. </t> <t> When processing TLS resumption, certificates must be verified to check for revocation during the period since the last NewSessionTicket Message. </t> <t>The resumption ticket_lifetimeSHOULD<bcp14>SHOULD</bcp14> be configurable, including a zero seconds lifetime. Refer to <xref target="RFC8446" section="4.6.1"/> for guidance on ticket lifetime. </t> </section> </section> <sectiontitle="Obsolescenceanchor="ObsolescenceOfTACACSObfuscation"> <name>Obsolescence of TACACS+Obfuscation" anchor="ObsolescenceOfTACACSObfuscation">Obfuscation</name> <!-- [rfced] Section 5.2 of [RFC5425] is titled "Subject Name Authorization" and doesn't appear to mention any kind of obfuscation mechanism. Also, is the obfuscation mechanism described in both RFC 8907 and 5425 (or other)? Please review and let us know how/if the text may be clarified. Original: [RFC8907] describes the obfuscation mechanism, documented in Section 5.2 of [RFC5425]. Such a method is weak. --> <t> <xref target="RFC8907"/> describes the obfuscation mechanism, documented in <xref target="RFC5425" section="5.2"/>. Such a method is weak. </t> <t> The introduction of TLS authentication and encryption to TACACS+ replaces this formermechanism andmechanism, so obfuscation is hereby obsoleted. This section describes how the TACACS+ client and serversMUST<bcp14>MUST</bcp14> operate regarding the obfuscation mechanism. </t> <t> PeersMUST NOT<bcp14>MUST NOT</bcp14> use obfuscation with TLS. </t> <t> A TACACS+ client initiating a TACACS+ TLS connectionMUST<bcp14>MUST</bcp14> set the TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that obfuscation is not used for the session. All subsequent packetsMUST<bcp14>MUST</bcp14> have the TAC_PLUS_UNENCRYPTED_FLAG bit set to 1. </t> <t> A TLS TACACS+ server that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1 over a TLSconnection, MUSTconnection <bcp14>MUST</bcp14> 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 inSection 4.5 of<xreftarget="RFC8907"/>target="RFC8907" section="4.5"/> regarding Data Obfuscation for TAC_PLUS_UNENCRYPTED_FLAG or key mismatches. </t> <t> A TACACS+ client that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG bit not set to 1MUST<bcp14>MUST</bcp14> terminate the session, andSHOULD<bcp14>SHOULD</bcp14> log this error. </t> </section> <sectiontitle="Security Considerations"anchor="Security"><section title="TLS"><name>Security Considerations</name> <section> <name>TLS</name> <t> This document improves the confidentiality, integrity, and authentication of the connection and network traffic between TACACS+ peers by adding TLS support. </t> <t> 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. </t> <t> <!-- [rfced] We are having trouble parsing "for implementing protocols that use TLS and their deployment." Original: [BCP195] offers substantial guidance for implementing protocols that use TLS and their deployment. Perhaps: [BCP195] offers substantial guidance for implementing and deploying protocols that use TLS. --> <xref target="BCP195"/> offers substantial guidance for implementing protocols that use TLS and their deployment. Those implementing and deploying Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3 outlined in <xref target="BCP195"/> or its subsequent versions. </t> <t> This document outlines additional restrictions permissible under <xreftarget="BCP195"/>target="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. </t> <t> This document concerns the use of TLS as transport forTACACS+,TACACS+ and does not make any changes to the core TACACS+ protocol, other than the direct implications of deprecating obfuscation. OperatorsMUST<bcp14>MUST</bcp14> be cognizant of the security implications of the TACACS+ protocol itself. Further documents are planned, for example, to address the security implications ofpassword basedpassword-based authentication and enhance the protocol to accommodate alternative schemes. </t> <sectiontitle="TLS Use"anchor="TLSUSE"> <name>TLS Use</name> <t> New TACACS+ production deploymentsSHOULD<bcp14>SHOULD</bcp14> use TLS authentication and encryption. Also see <xref target="RFC3365"/>. </t> <t> TLS TACACS+ servers (as defined in <xref target ="TLSTacacsServerDefinition"/>)MUST NOT<bcp14>MUST NOT</bcp14> allowNon-TLSnon-TLS connections, because of the threat of downgrade attacks or misconfiguration described in <xref target="wellknown"/>. Instead, separateNon-TLSnon-TLS TACACS+ serversSHOULD<bcp14>SHOULD</bcp14> be set up to cater for these clients. </t> <t> It isNOT RECOMMENDED<bcp14>NOT RECOMMENDED</bcp14> that TLS TACACS+ servers andNon-TLSnon-TLS TACACS+ servers be deployed on the same host, for reasons discussed in <xref target="wellknown"/>. Non-TLS connections would be better served by deploying the requiredNon-TLSnon-TLS TACACS+ servers on separate hosts. </t> <t> TACACS+Clients MUST NOTclients <bcp14>MUST NOT</bcp14> fail back to aNon-TLSnon-TLS connection if a TLS connection fails. This prohibition includes during the migration of a deployment (<xref target="MIGRATION"/>). </t> </section><section title="TLS 0-RTT"><section> <name>TLS 0-RTT</name> <t> TLS 1.3 resumption and PSK techniques make it possible to sendEarly Data, aka.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, clientsMUST NOT<bcp14>MUST NOT</bcp14> send data until the full TLS handshake completes; that is, clientsMUST NOT<bcp14>MUST NOT</bcp14> send 0-RTT data and TLS TACACS+ serversMUST<bcp14>MUST</bcp14> abruptly disconnect clients that do. </t> <t>TLS TACACS+ clients and serversMUST NOT<bcp14>MUST NOT</bcp14> include the "early_data" extension. Seesections 2.3Sections <xref target="RFC8446" sectionFormat="bare" section="2.3"/> and4.2.10<xref target="RFC8446" sectionFormat="bare" section="4.2.10"/> of <xref target="RFC8446"/> for security concerns.</t> </section><section title="TLS Options"><section> <name>TLS Options</name> <t>Recommendations in <xref target="BCP195"/>MUST<bcp14>MUST</bcp14> be followed to determine which TLS versions and algorithms should be supported, deprecated, obsoleted, or abandoned. </t> <t> Also, <xref target="RFC8446" section="9"/> prescribes mandatory supported options. </t> </section> <sectiontitle="Unreachableanchor="CAcache"> <name>Unreachable Certification Authority(CA)" anchor="CAcache">(CA)</name> <t> 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 <xref target="CertPV"/> can help address this and should be considered where implemented. </t> </section> <sectiontitle="TLSanchor="TLSSNISec"> <name>TLS Server Name Indicator(SNI)" anchor="TLSSNISec">(SNI)</name> <t> 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 <xref target="RFC6066" section="11.1"/>. </t> </section> <sectiontitle="Server Identity Wildcards"anchor="SIWildcards"> <name>Server Identity Wildcards</name> <!-- [rfced] The use of "MUST" twice in this sentence reads oddly. Please review. Original: Further, operators MUST ensure that the TLS TACACS+ servers covered by a wildcard certificate MUST be impervious to redirection of traffic to a different server (for example, due to on-path attacks or DNS cache poisoning). Perhaps A: 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). Perhaps B: Further, operators MUST ensure that the TLS TACACS+ servers are covered by a wildcard certificate and MUST be impervious to redirection of traffic to a different server (for example, due to on-path attacks or DNS cache poisoning). --> <t> 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 useMUST<bcp14>MUST</bcp14> follow the recommendations of <xref target="RFC9525" section="7.1"/>. OperatorsMUST<bcp14>MUST</bcp14> ensure that the wildcard is limited to a subdomain dedicated solely to TLS TACACS+ servers. Further, operatorsMUST<bcp14>MUST</bcp14> ensure that the TLS TACACS+ servers covered by a wildcard certificateMUST<bcp14>MUST</bcp14> be impervious to redirection of traffic to a different server (for example, due to on-path attacks or DNS cache poisoning). </t> </section> </section> <sectiontitle="TACACS+ Configuration"anchor="TACACSConfiguration"> <name>TACACS+ Configuration</name> <t> Implementors must ensure that the configuration scheme introduced for enabling TLS is straightforward and leaves no room for ambiguity regarding whether TLS orNon-TLSnon-TLS will be used between the TACACS+ client and the TACACS+ server. </t> <t> 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 implementationsMUST<bcp14>MUST</bcp14> use the correct port values: </t> <ul><li>for Non-TLS<li>49: for non-TLS connectionTACACS+: Port number 49.</li> <li>forTACACS+</li> <li>300: for TLS connectionTACACS+: (TBD).</li>TACACS+</li> </ul> <t> Implementors may offer a single option for TACACS+ clients and servers to disable allNon-TLSnon-TLS TACACS+ operations. When enabled on a TACACS+ server, it will not respond to any requests fromNon-TLSnon-TLS TACACS+ client connections. When enabled on a TACACS+ client, it will not establish anyNon-TLSnon-TLS TACACS+ server connections. </t> </section> <sectiontitle="Well-Knownanchor="wellknown"> <name>Well-Known TCP/IP PortNumber" anchor="wellknown">Number</name> <t> A new port number is considered appropriate (rather than a mechanism that negotiates an upgrade from an initialNon-TLSnon-TLS TACACS+Connection)connection) because it allows: </t> <ul> <li>ease of blocking the unobfuscated or obfuscated connections by the TCP/IP port number,</li> <li>passive Intrusion Detection Systems (IDSs) monitoring the unobfuscated to be unaffected by the introduction of TLS, </li> <li>avoidance of on-path attacks that can interfere with upgrade, and</li> <li>prevention of the accidental exposure of sensitive information due to misconfiguration.</li> </ul> <t> However,co-existencethe coexistence of inferior authentication andobfuscated,obfuscation, whether aNon-TLSnon-TLS connection or deprecated parts that compose TLS, also presents an opportunity fordown-gradedowngrade attacks. Causing failure of connections to the TLS-enabled service or the negotiation of shared algorithm support are two suchdown-gradedowngrade attacks. </t> <t> The simplest mitigation exposure fromNon-TLSnon-TLS connection methods is to refuseNon-TLSnon-TLS connections at the host entirely, perhaps using separate hosts forNon-TLSnon-TLS connections and TLS. </t> <t> Another approach is mutual configuration that requires TLS. TACACS+ clients and serversSHOULD<bcp14>SHOULD</bcp14> support configuration that requires peers, globally and individually, to use TLS. Furthermore, peersSHOULD<bcp14>SHOULD</bcp14> be configurable to limit offered or recognized TLS versions and algorithms to those recommended by standards bodies and implementers. </t> </section> </section> <sectiontitle="Operational Considerations"anchor="OPSCONS"> <name>Operational Considerations</name> <t> Operational and deployment considerations are spread throughout the document. While avoiding repetition, it is useful for the impatient to direct particular attention to Sections5.2<xref target="TACACSConfiguration" format="counter"/> and5.1.5.<xref target="TLSSNISec" format="counter"/>. However, it is important that the entireSection 5<xref target="Security"/> is observed. </t> <t>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 <xref target="BCP195"/> for guidance. Attention is drawn to the provisioning ofCertificatescertificates to all peers, including TACACS+ TLS clients, to permit the mandatory mutual authentication.</t> <sectiontitle="Migration"anchor="MIGRATION"> <name>Migration</name> <t>Section 5.2<xref target="TACACSConfiguration"/> mentions that for an optimal deployment of TLS TACACS+, TLS should be universally applied throughout the deployment. However, during the migration process from aNon-TLSnon-TLS TACACS+ deployment, operators may need to support both TLS andNon-TLSnon-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: </t> <ul> <li>The period where any client is configured with both TLS andNon-TLSnon-TLS TACACS+ servers should be minimized. </li><li>The<!-- [rfced] Does the operator need to consider the impact of supporting both TLS and non-TLS connections? Original: * The operator must consider the impact of mixed TLS and Non-TLS on security, as mentioned above. Perhaps: * The operator must consider the security impact of supporting both TLS and non-TLS connections, as mentioned above. --> <li>The operator must consider the impact of mixed TLS and non-TLS on security, as mentioned above.</li> </ul> </section> <sectiontitle="Maintaininganchor="NONTLS"> <name>Maintaining Non-TLS TACACS+Clients" anchor="NONTLS">Clients</name> <t> Some TACACS+ client devices in a deployment may not implement TLS. These devices will require access toNon-TLSnon-TLS TACACS+ servers. Operators must follow the recommendation of <xref target="TLSUSE"/> and deploy separateNon-TLSnon-TLS TACACS+ servers for theseNon-TLSnon-TLS clients from those used for the TLS clients. </t> </section><section title="YANG<section> <name>YANG Model for TACACS+Clients">Clients</name> <t> <xreftarget="ietf-opsawg-secure-tacacs-yang"/>target="I-D.ietf-opsawg-secure-tacacs-yang"/> specifies a YANG model for managing TACACS+ clients, including TLS support. </t> </section> </section> <sectiontitle="IANA Considerations"anchor="ICTBD"><t><name>IANA Considerations</name> <!-- [rfced] The description of the service name in the first paragraph differs from the what appears in the registration template below it and what appears on the IANA(has allocated)site. Is the intent to relay that the service name "tacacss" isrequestedcommonly referred toallocateas "TACACS+ over TLS" rather than the description in the template? Or, should the descriptions be the same? Original: IANA has allocated a new well-known system TCP/IP port number([TBD])(300) for the service name "tacacss", described as "TACACS+ over TLS". The service name "tacacss" follows the common practice of appending an "s" to the name given to the Non-TLSwell-knownwell- known port name. This allocation is justified in<xref target="wellknown"/>. </t> <t>IANA (has added) is requested to addSection 5.3. IANA has added tacacss as a new entry to the "Service name and Transport Protocol Port Number Registry" available athttps://www.iana.org/assignments/service-names-port-numbers/ </t> <t>Service Name: tacacss</t> <t>Port Number: [TBD]</t> <t>Transport Protocol: TCP</t> <t>Description:<https://www.iana.org/assignments/service-names-port-numbers>. Description in the template and the IANA registry: TLS Secure Login Host Protocol(TACACSS)</t> <t>Assignee: IESG</t> <t>Contact: IETF Chair</t> <t>Reference: [TBD] (This Document)</t> <t> RFC EDITOR:(TACACSS) See <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?=&skey=2&page=6>. If the text should be the same, perhaps the paragraphs could be combined as follows: 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. Related: Original in Section 3.1: Given the prevalence of default port usage in existing TACACS+ client implementations, this specification assigns a well-known TCP port numbershould replace "[TBD]" withinfor TACACS+ over TLS: [TBD] (Section 7), with the associated service name "tacacss" Section 7. Perhaps: Given the prevalence of default port usage in existing TACACS+ client implementations, thisdocument. </t>specification assigns well-known TCP port 300 for TACACS+ over TLS (see Section 7). Original in Section 3.1 - We believe this is intentional to align with the line prior: * for Non-TLS connection TACACS+: Port number 49. * for TLS connection TACACS+: (TBD). --> <t>ConsiderationsIANA has allocated a new well-known system TCP/IP port number (300) for the service name "tacacss", described as "TACACS+ over TLS". The service name "tacacss" follows the common practice of appending an "s" to the name given to the non-TLS well-known port name. This allocation is justified in <xref target="wellknown"/>.</t> <t> IANA has added the following entry to the "Service Name and Transport Protocol Port Number Registry" (see <eref brackets="angle" target="https://www.iana.org/assignments/service-names-port-numbers"/>). </t> <dl spacing="compact" newline="false"> <dt>Service Name:</dt><dd>tacacss</dd> <dt>Port Number:</dt><dd>300</dd> <dt>Transport Protocol:</dt><dd>TCP</dd> <dt>Description:</dt><dd>TLS Secure Login Host Protocol (TACACSS)</dd> <dt>Assignee:</dt><dd>IESG</dd> <dt>Contact:</dt><dd>IETF Chair</dd> <dt>Reference:</dt><dd>RFC 9887</dd> </dl> <t>Considerations about service discovery are out of scope of thisdocument. </t>document.</t> </section><section title="Acknowledgments"><section> <name>Acknowledgments</name> <t> The author(s) would like to thankRuss Housley, Steven M. Bellovin, Stephen Farrell, Alan DeKok, Warren Kumari, Tom Petch, Tirumal Reddy, Valery Smyslov,<contact fullname="Russ Housley"/>, <contact fullname="Steven M. Bellovin"/>, <contact fullname="Stephen Farrell"/>, <contact fullname="Alan DeKok"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Tom Petch"/>, <contact fullname="Tirumal Reddy"/>, <contact fullname="Valery Smyslov"/>, andMohamed Boucadair<contact fullname="Mohamed Boucadair"/> for their support, insightful review, and/or comments. <xref target="RFC5425"/> was also used as a basis for the general approach to TLS. <xref target="RFC9190"/> was used as a basis for TLSResumption Recommendations.resumption recommendations. Although still in draft form at the time of writing, <xreftarget="I-D.ietf-radext-tls-psk"/>target="RFC9813"/> was used as a model for PSKRecommendations.recommendations. </t> </section> </middle> <back><references title="Normative References"> <referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195"> <reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325"> <front> <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) </title> <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/> <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/> <author fullname="T. Fossati" initials="T." surname="Fossati"/> <date month="November" year="2022"/> <abstract> <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. </t> <t>RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. </t> </abstract> </front> <seriesInfo name="BCP" value="195"/> <seriesInfo name="RFC" value="9325"/> <seriesInfo name="DOI" value="10.17487/RFC9325"/> </reference> </referencegroup> <?rfc include="reference.RFC.2119.xml"?> <?rfc include="reference.RFC.5280.xml"?> <?rfc include="reference.RFC.5425.xml"?> <?rfc include="reference.RFC.6066.xml"?> <?rfc include="reference.RFC.7250.xml"?> <?rfc include="reference.RFC.7924.xml"?> <?rfc include="reference.RFC.8174.xml"?> <?rfc include="reference.RFC.8446.xml"?> <?rfc include="reference.RFC.8907.xml"?> <?rfc include="reference.RFC.9525.xml"?><displayreference target="I-D.ietf-opsawg-secure-tacacs-yang" to="TACACS-YANG"/> <displayreference target="I-D.ietf-uta-require-tls13" to="REQ-TLS13"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5425.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7924.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8907.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/> </references><references title="Informative References"><references> <name>Informative References</name> <reference anchor="FIPS-140-3"target="https://csrc.nist.gov/pubs/fips/140-3/final">target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf"> <front><title>NIST Federal Information Processing Standards (FIPS) Publication 140-3</title><title>Security Requirements for Cryptographic Modules</title> <author> <organizationshowOnFrontPage="true">Nationalabbrev="NIST">National Institute of Standards andTechnology, U.S. Department of Commerce </organization> </author> </front> </reference> <?rfc include="reference.RFC.3365.xml"?> <?rfc include="reference.RFC.6151.xml"?> <?rfc include="reference.RFC.9190.xml"?> <?rfc include="reference.RFC.9257.xml"?> <reference anchor="ietf-opsawg-secure-tacacs-yang" target="https://datatracker.ietf.org/doc/draft-ietf-opsawg-secure-tacacs-yang/"> <front> <title>A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) </title> <author fullname="Mohamed Boucadair" role="editor"> </author> <author fullname="Bo Wu"> </author> <author fullname="Guangying Zheng"> </author> <author fullname="Michael Wang"> </author> </front> </reference> <reference anchor="I-D.ietf-radext-tls-psk"> <front> <title>Operational Considerations for RADIUS and TLS-PSK</title> <author fullname="Alan DeKok" initials="A." surname="DeKok"> <organization>InkBridge Networks</organization>Technology</organization> </author> <dateday="21" month="January" year="2025"/> <abstract> <t> This document provides implementation and operational considerations for using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360). The purpose of the document is to help smooth the operational transition from the use of the RADIUS/UDP to RADIUS/TLS. </t> </abstract>month="March" year="2019"/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-radext-tls-psk-12"/>name="NIST FIPS" value="140-3"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.140-3"/> </reference><reference anchor="I-D.ietf-uta-require-tls13"> <front> <title>New Protocols Using TLS Must Require TLS 1.3</title> <author fullname="Rich Salz" initials="R." surname="Salz"> <organization>Akamai Technologies</organization> </author> <author fullname="Nimrod Aviram" initials="N." surname="Aviram"> </author> <date day="14" month="April" year="2025"/> <abstract> <t> TLS 1.3 use is widespread, it has had comprehensive security proofs, and it improves both security and privacy over TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3365.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9190.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9257.xml"/> <!-- [I-D.ietf-opsawg-secure-tacacs-yang] draft-ietf-opsawg-secure-tacacs-yang-13 - EDIT --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-opsawg-secure-tacacs-yang.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9813.xml"/> <!-- [I-D.ietf-uta-require-tls13] draft-ietf-uta-require-tls13-12 - EDIT --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-uta-require-tls13.xml"/> </references> </references> <!-- [rfced] This documentupdates RFC9325 and discusses post-quantum cryptography and the securityused both "non-TLS" andprivacy improvements over TLS 1.2 as a rationale"Non-TLS". We have lowercased instances of "Non-TLS" forthat update. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-uta-require-tls13-12"/> </reference> </references>consistency and because overcapitalization can detract from readability. --> </back> </rfc>