rfc9887.original.xml		rfc9887.xml
	<?xml version='1.0' encoding='utf-8'?>		<?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 proc
	essors, including most browsers -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<rfc docName="draft-ietf-opsawg-tacacs-tls13-24"
	category="std"		<rfc docName="draft-ietf-opsawg-tacacs-tls13-24" number="9887" category="std" ip
	ipr="trust200902"		r="trust200902" submissionType='IETF' consensus="true" updates="8907" obsoletes=
	submissionType='IETF'		"" xmlns:xi="http://www.w3.org/2001/XInclude" version="3" sortRefs="true" symRef
	consensus="true"		s="true" tocInclude="true" tocDepth="3" xml:lang="en">
	updates="8907"
	xmlns:xi="http://www.w3.org/2001/XInclude" version="3"
	sortRefs="true"
	indexInclude="false"
	tocDepth="3">
	<front>		<front>
	<title abbrev="TACACS+ over TLS 1.3">		<title abbrev="TACACS+ over TLS 1.3">Terminal Access Controller
	Terminal Access Controller Access-Control System Plus over TLS 1.3 (		Access-Control System Plus (TACACS+) over&nbsp;TLS&nbsp;1.3</title>
	TACACS+ over TLS)		<seriesInfo name="RFC" value="9887"/>
	</title>		<author fullname="Thorsten Dahm" initials="T." surname="Dahm">
	<author fullname="Thorsten Dahm" initials="T." surname="Dahm">		<address>
	<address>		<email>thorsten.dahm@gmail.com</email>
	<postal>		</address>
	<street></street>		</author>
	<code></code>
	<city></city>
	<country></country>
	</postal>
	<email>thorsten.dahm@gmail.com</email>
	</address>
	</author>
	<author fullname="John Heasley" initials="J." surname="Heasley">		<author fullname="John Heasley" initials="J." surname="Heasley">
	<organization abbrev="NTT">NTT</organization>		<organization abbrev="NTT">NTT</organization>
	<address>		<address>
	<postal>		<email>heas@shrubbery.net</email>
	<street></street>		</address>
	<code></code>		</author>
	<city></city>
	<country></country>
	</postal>
	<email>heas@shrubbery.net</email>
	</address>
	</author>
	<author initials="D.C." surname="Medway Gash" fullname="Douglas C. Medwa		<author initials="D.C." surname="Medway Gash" fullname="Douglas C. Medway
	y Gash">		Gash">
	<organization>Cisco Systems, Inc.</organization>		<organization>Cisco Systems, Inc.</organization>
	<address>		<address>
	<postal>		<postal>
	<street>170 West Tasman Dr.</street>		<street>170 West Tasman Dr.</street>
	<city>San Jose</city>		<city>San Jose</city>
	<region>CA</region>		<region>CA</region>
	<code>95134</code>		<code>95134</code>
	<country>United States of America</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>dcmgash@cisco.com</email>		<email>dcmgash@cisco.com</email>
	<uri/>		</address>
	</address>		</author>
	</author>
	<author initials="A." surname="Ota" fullname="Andrej Ota">		<author initials="A." surname="Ota" fullname="Andrej Ota">
	<organization>Google Inc.</organization>		<organization>Google Inc.</organization>
	<address>		<address>
	<postal>		<postal>
	<street>1600 Amphitheatre Parkway</street>		<street>1600 Amphitheatre Parkway</street>
	<city>Mountain View</city>		<city>Mountain View</city>
	<region>CA</region>		<region>CA</region>
	<code>94043</code>		<code>94043</code>
	<country>United States of America</country>		<country>United States of America</country>
	</postal>		</postal>
	<phone/>		<email>andrej@ota.si</email>
	<email>andrej@ota.si</email>		</address>
	<uri/>		</author>
	</address>
	</author>
	<date/>		<date month="October" year="2025"/>
	<area>Operations and Management Area (ops)</area>		<area>OPS</area>
	<workgroup>Operations and Management Area Working Group</workgroup>		<workgroup>opsawg</workgroup>
	<keyword>TACACS+</keyword>		<keyword>TACACS+</keyword>
	<abstract>		<abstract>
	<t>		<t> This document specifies the use of Transport Layer Security (TLS)
	This document specifies the use of Transport Layer Security (TLS		version 1.3 to secure the communication channel between a Terminal
	) version 1.3 to secure the communication		Access Controller Access-Control System Plus (TACACS+) client and
	channel between a Terminal Access Controller Access-Control Syst		server. TACACS+ is a protocol used for Authentication, Authorization,
	em Plus (TACACS+) client and server. TACACS+		and Accounting (AAA) in networked environments. The original TACACS+
	is a protocol used for Authentication, Authorization,		protocol does not mandate the use of encryption or secure
	and Accounting (AAA) in networked environments. The original TAC		transport. This specification defines a profile for using TLS 1.3 with
	ACS+ protocol, does not mandate the use of		TACACS+, including guidance on authentication, connection
	encryption or secure transport. This specification defines a pro		establishment, and operational considerations. The goal is to enhance
	file for using TLS 1.3 with TACACS+, including		the confidentiality, integrity, and authenticity of TACACS+ traffic,
	guidance on authentication, connection establishment, and operat		aligning the protocol with modern security best practices.</t>
	ional considerations. The goal is to enhance		<t>This document updates RFC 8907.</t>
	the confidentiality, integrity, and authenticity of TACACS+ traf
	fic, aligning the protocol with modern
	security best practices.
	</t>
	<t>This document updates RFC 8907.</t>
	</abstract>		</abstract>
	<note title="Requirements Language">
	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO
	T", "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>		</front>
	<middle>		<middle>
	<section title="Introduction">		<section>
			<name>Introduction</name>
	<t>		<t>
	The <xref target="RFC8907">Terminal Access Controller Access-Con		"The Terminal Access Controller Access-Control System Plus (TACA
	trol System Plus (TACACS+) Protocol		CS+) Protocol"
	</xref> provides device administration for routers, network access s		<xref target="RFC8907"/> provides device administration for routers,
	ervers, and other networked computing		network access servers, and other networked computing
	devices via one or more centralized TACACS+ servers.		devices via one or more centralized TACACS+ servers.
	The protocol provides authentication, authorization and accounti ng services (AAA) for TACACS+ clients		The protocol provides authentication, authorization, and account ing services (AAA) for TACACS+ clients
	within the device administration use case.		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>		<t>
	While the content of the protocol is highly sensitive, TACACS+ l acks effective confidentiality,		While the content of the protocol is highly sensitive, TACACS+ l acks effective confidentiality,
	integrity, and authentication of the connection and network traf fic between the TACACS+ server and client,		integrity, and authentication of the connection and network traf fic between the TACACS+ server and client,
	requiring secure transport to safeguard a deployment.		requiring secure transport to safeguard a deployment.
	The security mechanisms as described in Section 10 of <xref targ et="RFC8907"/> are extremely weak.		The security mechanisms as described in <xref target="RFC8907" s ection="10"/> are extremely weak.
	</t>		</t>
	<t>		<t>
	To address these deficiencies, this document updates the TACACS+ protocol to use <xref target="RFC8446">		To address these deficiencies, this document updates the TACACS+ protocol to use
	TLS 1.3		TLS 1.3
	</xref> authentication and encryption, and obsoletes the use of TACA		authentication and encryption <xref target="RFC8446" />, and obsolet
	CS+ obfuscation mechanisms (Section 10.5 of <xref		es the use of TACACS+ obfuscation mechanisms (<xref
	target="RFC8907"/>). The maturity of TLS in version 1.3 and		target="RFC8907" section="10.5"/>). The maturity of TLS in v
	above makes it a suitable choice for the TACACS+ protocol.		ersion 1.3 and above makes it a suitable choice for the TACACS+ protocol.
	</t>		</t>
	</section>		</section>
	<section title="Technical Definitions" anchor="TLSTacacsServerDefinition		<section anchor="TLSTacacsServerDefinition">
	">		<name>Technical Definitions</name>
	<t>		<t>
	The terms defined in Section 3 of		The terms defined in
	<xref target="RFC8907"/>		<xref target="RFC8907" section="3"/>
	are fully applicable here and will not be repeated.		are fully applicable here and will not be repeated.
	The following terms are also used in this document.		The following terms are also used in this document.
	</t>		</t>
	<t>		<dl>
	Obfuscation: TACACS+ was originally intended to incorporate		<dt>Obfuscation:</dt> <dd>TACACS+ was originally intended to incorporate a mecha
	a mechanism for securing the body of its packets.		nism for securing the body of its packets.
	The algorithm is categorized as Obfuscation in <xref target= "RFC8907" section="10.5.2"/>. The term		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 enc		is used to ensure that the algorithm is not mistaken for enc
	ryption. It should not be considered secure.		ryption. It should not be considered secure.</dd>
	</t>		<!-- [rfced] Should "for test" be "for testing"?
	<t>
	Non-TLS connection: This term refers to the connection defin		Original:
	ed in <xref target="RFC8907"/>.		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 connect
			ion defined in <xref target="RFC8907"/>.
	It is a connection without TLS, using the unsecure TACACS+		It is a connection without TLS, using the unsecure TACACS+
	authentication and obfuscation (or the unobfuscated option f or test).		authentication and obfuscation (or the unobfuscated option f or test).
	The use of well-known TCP/IP host port number 49 is specifie		The use of well-known TCP/IP host port number 49 is specifie
	d as the default for Non-TLS		d as the default for non-TLS
	connections.		connections.</dd>
	</t>		<dt>
	<t>		TLS connection:</dt> <dd>A TLS connection is a TCP/IP connec
	TLS connection: A TLS connection is a TCP/IP connection with		tion with TLS authentication and encryption used by TACACS+ for
	TLS authentication and encryption used by TACACS+ for
	transport. A TLS connection for TACACS+ is always between on e TACACS+ client and one TACACS+ server.		transport. A TLS connection for TACACS+ is always between on e TACACS+ client and one TACACS+ server.
	</t>		</dd>
	<t>		<dt>
	TLS TACACS+ server: This document describes a variant of the		TLS TACACS+ server:</dt> <dd>This document describes a varia
	TACACS+ server, introduced in Section 3.2 of [RFC8907], which		nt of the TACACS+ server, introduced in <xref section="3.2" target="RFC8907"/>,
			which
	utilizes TLS for transport, and makes some associated protoc ol optimizations. Both server variants respond to		utilizes TLS for transport, and makes some associated protoc ol optimizations. Both server variants respond to
	TACACS+ traffic, but this document specifically defines a TA CACS+ server (whether TLS or Non-TLS) as being bound to specific port number		TACACS+ traffic, but this document specifically defines a TA CACS+ server (whether TLS or non-TLS) as being bound to a specific port number
	on a particular IP address or hostname. This definition is i mportant in the context of the configuration		on a particular IP address or hostname. This definition is i mportant in the context of the configuration
	of TACACS+ clients, to ensure they direct their traffic to t		of TACACS+ clients to ensure they direct their traffic to th
	he correct TACACS+ servers.		e correct TACACS+ servers.
	</t>		</dd>
	<t>		<dt>
	Peer: The peer of a TACACS+ client (or server) in the contex		Peer:</dt> <dd>The peer of a TACACS+ client (or server) in t
	t of a TACACS+ connection, is a TACACS+ server (or		he context of a TACACS+ connection, is a TACACS+ server (or
	client). Together, the ends of a TACACS+ connection are refe rred to as peers.		client). Together, the ends of a TACACS+ connection are refe rred to as peers.
	</t>		</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&nbsp;14 <xref target="RFC2119"/> <xref
			target="RFC8174"/> when, and only when, they appear in all capitals, as
			shown here.
			</t>
			</section>
	</section>		</section>
	<section title="TACACS+ over TLS">		<section>
			<name>TACACS+ over TLS</name>
	<t>		<t>
	TACACS+ over TLS takes the protocol defined in <xref target="RFC 8907"/>, removes the option for MD5		TACACS+ over TLS takes the protocol defined in <xref target="RFC 8907"/>, removes the option for MD5
	obfuscation, and specifies that TLS 1.3 be used for transport (< xref target="TLSPort"/> elaborates TLS version support). A new well-known defaul t host port number is used.		obfuscation, and specifies that TLS 1.3 be used for transport (< xref target="TLSPort"/> elaborates on TLS version support). A new well-known def ault host port number is used.
	The next sections provide further details and guidance.		The next sections provide further details and guidance.
	</t>		</t>
	<t>TLS is introduced into TACACS+ to fulfill the following requireme nts:		<t>TLS is introduced into TACACS+ to fulfill the following requireme nts:
	</t>		</t>
	<ol>		<ol>
	<li>Confidentiality and Integrity: The MD5 algorithm underlying the obfuscation mechanism specified in <xref target="RFC8907"/> has been shown		<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 encryp tion. This prevents TACACS+ being used in a <xref target="FIPS-140-3"/> - compli ant deployment. Securing TACACS+ protocol with TLS is intended to provide confid entiality and		to be insecure <xref target="RFC6151"/> when used for encryp tion. This prevents TACACS+ from being used in a deployment compliant with <xref target="FIPS-140-3"/>. Securing the TACACS+ protocol with TLS is intended to pr ovide confidentiality and
	integrity without requiring the provision of a secured netwo rk.		integrity without requiring the provision of a secured netwo rk.
	</li>		</li>
	<li>Peer authentication: The authentication capabilities of TLS replace the shared secrets of obfuscation for mutual authentication.		<li>Peer authentication: The authentication capabilities of TLS replace the shared secrets of obfuscation for mutual authentication.
	</li>		</li>
	</ol>		</ol>
	<t>This document adheres to the recommendations in <xref target="I-D .ietf-uta-require-tls13"/>.</t>		<t>This document adheres to the recommendations in <xref target="I-D .ietf-uta-require-tls13"/>.</t>
	<section title="Separating TLS Connections" anchor="TLSPort">		<section anchor="TLSPort">
			<name>Separating TLS Connections</name>
	<t>		<t>
	Peers implementing the TACACS+ protocol variant defined in t his document MUST apply mutual		Peers implementing the TACACS+ protocol variant defined in t his document <bcp14>MUST</bcp14> apply mutual
	authentication and encrypt all data exchanged between them. Therefore, when a TCP connection is		authentication and encrypt all data exchanged between them. Therefore, when a TCP connection is
	established for the service, a TLS handshake begins immediat ely. Options which upgrade an initial Non-TLS connection, MUST NOT be used, see <xref target="wellknown"/>.		established for the service, a TLS handshake begins immediat ely. Options that upgrade an initial non-TLS connection <bcp14>MUST NOT</bcp14> be used; see <xref target="wellknown"/>.
	</t>		</t>
	<t>		<t>
	To ensure clear separation between TACACS+ traffic using TLS and that which does not (see <xref target="wellknown"/>), servers supporting		To ensure clear separation between TACACS+ traffic using TLS and that which does not (see <xref target="wellknown"/>), 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		TACACS+ over TLS <bcp14>MUST</bcp14> listen on a TCP/IP port distinct from that used by non-TLS TACACS+ servers. It is further <bcp14>RECOMM ENDED</bcp14>
	to deploy the TLS and non-TLS services on separate hosts, as discussed in <xref target="TLSUSE"/>.		to deploy the TLS and non-TLS services on separate hosts, as discussed in <xref target="TLSUSE"/>.
	</t>		</t>
	<t>		<t>
	Given the prevalence of default port usage in existing TACAC S+ client implementations, this specification assigns a well-known TCP port		Given the prevalence of default port usage in existing TACAC S+ client implementations, this specification assigns a well-known TCP port
	number for TACACS+ over TLS: <xref target="ICTBD">[TBD]</xre f>, with the associated service name "tacacss" <xref target="ICTBD"/>. This allo ws clients to unambiguously		number for TACACS+ over TLS: 300, with the associated servic e name "tacacss" (see <xref target="ICTBD"/>). This allows clients to unambiguou sly
	distinguish between TLS and non-TLS connections, even in the absence of an explicitly configured port number.		distinguish between TLS and non-TLS connections, even in the absence of an explicitly configured port number.
	</t>		</t>
	<t>		<t>
	While the use of the designated port number is strongly enco uraged, deployments with specific requirements MAY use alternative TCP port numb ers.		While the use of the designated port number is strongly enco uraged, deployments with specific requirements <bcp14>MAY</bcp14> use alternativ e TCP port numbers.
	In such cases, operators must carefully consider the operati onal implications described in <xref target="wellknown"/>.		In such cases, operators must carefully consider the operati onal implications described in <xref target="wellknown"/>.
	</t>		</t>
	</section>		</section>
	<section title="TLS Connection" anchor="TLSConn">		<section anchor="TLSConn">
			<name>TLS Connection</name>
	<t>		<t>
	A TACACS+ client initiates a TLS connection by making a TCP connection to a configured TLS TACACS+ server on the		A TACACS+ client initiates a TLS connection by making a TCP connection to a configured TLS TACACS+ server on the
	TACACS+ TLS port number.		TACACS+ TLS port number.
	Once the TCP connection is established, the client MUST imme diately begin the TLS negotiation before		Once the TCP connection is established, the client <bcp14>MU ST</bcp14> immediately begin the TLS negotiation before
	sending any TACACS+ protocol data.		sending any TACACS+ protocol data.
	</t>		</t>
	<t>		<t>
	Minimum <xref target="RFC8446">TLS 1.3</xref>		A minimum of TLS 1.3 <xref target="RFC8446"/>
	MUST be used for transport, it is expected that TACACS+ as d		<bcp14>MUST</bcp14> be used for transport. It is expected t
	escribed in this document will		hat TACACS+, as described in this document, will
	work		work
	with future versions of TLS. Earlier versions of TLS MUST NO T be used.		with future versions of TLS. Earlier versions of TLS <bcp14> MUST NOT</bcp14> be used.
	</t>		</t>
	<t>		<t>
	Once the TLS connection has been successfully established, t		Once the TLS connection has been successfully established, t
	he exchange of TACACS+ data MUST proceed in		he exchange of TACACS+ data <bcp14>MUST</bcp14> proceed in
	accordance with the procedures defined in <xref target="RFC8		accordance with the procedures defined in <xref target="RFC8
	907"/>, However, all TACACS+ messages SHALL be transmitted		907"/>. However, all TACACS+ messages <bcp14>SHALL</bcp14> be transmitted
	as TLS application data. The TACACS+ obfuscation mechanism d		as TLS application data. The TACACS+ obfuscation mechanism d
	efined in <xref target="RFC8907"/> MUST NOT be applied		efined in <xref target="RFC8907"/> <bcp14>MUST NOT</bcp14> be applied
	when operating over TLS (<xref target="ObsolescenceOfTACACSO bfuscation"/>).</t>		when operating over TLS (<xref target="ObsolescenceOfTACACSO bfuscation"/>).</t>
			<!-- [rfced] We recommend simplifying this sentence for clarity. Does the conne
			ction 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>		<t>
	The connection persists until the TLS TACACS+ peer closes it , either due to an error, or at the		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"/>)		conclusion of the TACACS+ session, or, if Single Connection Mode (<xref target="RFC8907" section="4.3"/>)
	has been negotiated, when an inactivity timeout occurs.		has been negotiated, when an inactivity timeout occurs.
	Why it closed has no bearing on TLS resumption, unless close d by a TLS error, in which case it is possible that the ticket has been invalida ted.		Why it closed has no bearing on TLS resumption, unless close d by a TLS error, in which case it is possible that the ticket has been invalida ted.
	</t>		</t>
	<t>		<t>
	TACACS+ connections are generally not long-lived. For connec		TACACS+ connections are generally not long-lived. For connec
	tions not operating in Single Connection Mode (as defined in <xref target="RFC89		tions not operating in Single Connection Mode (as defined in <xref target="RFC89
	07" section="4.3"/>) the TCP session		07" section="4.3"/>), the TCP session
	SHALL be closed upon completion of the associated TACACS+ se		<bcp14>SHALL</bcp14> be closed upon completion of the associ
	ssion. Connections operating in Single Connection Mode MAY persist for a longer		ated TACACS+ session. Connections operating in Single Connection Mode <bcp14>MAY
	duration but are typically subject		</bcp14> persist for a longer duration but are typically subject
	to timeout and closure after a brief period of inactivity. C onsequently, support for transport-layer keepalive mechanisms is not required.		to timeout and closure after a brief period of inactivity. C onsequently, support for transport-layer keepalive mechanisms is not required.
	</t>		</t>
	<t>		<t>
	TACACS+ clients and servers widely support IPv6 configuratio n in addition to IPv4. This document makes no changes to recommendations in this area.		TACACS+ clients and servers widely support IPv6 configuratio n in addition to IPv4. This document makes no changes to recommendations in this area.
	</t>		</t>
	</section>		</section>
	<section title="TLS Authentication Options">		<section>
			<name>TLS Authentication Options</name>
	<t>		<t>
	Implementations MUST support certificate-based mutual authen tication, to provide a core option for interoperability between deployments.		Implementations <bcp14>MUST</bcp14> support certificate-base d mutual authentication, to provide a core option for interoperability between d eployments.
	This authentication option is specified in <xref target="Cer tAuth"/>.		This authentication option is specified in <xref target="Cer tAuth"/>.
	</t>		</t>
	<t>		<t>
	In addition to certificate-based TLS authentication, impleme ntations MAY support the following alternative authentication mechanisms:		In addition to certificate-based TLS authentication, impleme ntations <bcp14>MAY</bcp14> support the following alternative authentication mec hanisms:
	</t>		</t>
	<ul>		<ul>
	<li>Pre-Shared Keys (PSKs) (<xref target="PSKAuth"/>), also known as external PSKs in TLS 1.3.		<li>Pre-Shared Keys (PSKs) (<xref target="PSKAuth"/>), also known as external PSKs in TLS 1.3.
	</li>		</li>
	<li>Raw Public Keys (RPKs). The details		<li>Raw Public Keys (RPKs). The details
	of RPK are considered out-of-scope for this document. Re fer to <xref target="RFC7250"/> and <xref target="RFC8446" section="4.4.2"/> for		of RPKs are considered out of scope for this document. R efer to <xref target="RFC7250"/> and <xref target="RFC8446" section="4.4.2"/> fo r
	implementation, deployment, and security considerations.		implementation, deployment, and security considerations.
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section title="TLS Certificate-Based Authentication" anchor="CertAu		<section anchor="CertAuth">
	th">		<name>TLS Certificate-Based Authentication</name>
	<t>		<t>
	TLS certificate authentication is the primary authentication option for TACACS+ over TLS.		TLS certificate authentication is the primary authentication option for TACACS+ over TLS.
	This section covers certificate-based authentication only.</ t>		This section covers certificate-based authentication only.</ t>
	<t>Deploying TLS certificate-based authentication correctly will considerably improve the security of TACACS+		<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		deployments. It is essential for implementers and operators to understand the implications of a TLS
	certificate-based authentication solution, including the cor rect handling of certificates, Certificate Authorities (CAs), and all		certificate-based authentication solution, including the cor rect handling of certificates, Certificate Authorities (CAs), and all
	elements of TLS configuration. For guidance, start with <xre f target="BCP195"/>.</t>		elements of TLS configuration. For guidance, start with <xre f target="BCP195"/>.</t>
	<t>Each peer MUST validate the certificate path of its remote pe er, including revocation checking,		<t>Each peer <bcp14>MUST</bcp14> validate the certificate path o f its remote peer, including revocation checking,
	as		as
	described in <xref target="CertPV"/>.		described in <xref target="CertPV"/>.
	</t>		</t>
	<t>		<t>
	If the verification succeeds, the authentication is successf ul and the connection is permitted.		If the verification succeeds, the authentication is successf ul and the connection is permitted.
	Policy may impose further constraints upon the peer, allowin g or denying the connection based on		Policy may impose further constraints upon the peer, allowin g or denying the connection based on
	certificate fields or any other parameters exposed by the im plementation.		certificate fields or any other parameters exposed by the im plementation.
	</t>		</t>
	<t>		<t>
	Unless disabled by configuration, a peer MUST NOT permit con nection of any peer that presents an		Unless disabled by configuration, a peer <bcp14>MUST NOT</bc p14> permit connection of any peer that presents an
	invalid TLS certificate.		invalid TLS certificate.
	</t>		</t>
	<section title="TLS Certificate Path Verification" anchor="CertP		<section anchor="CertPV">
	V">		<name>TLS Certificate Path 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>		<t>
	The implementation of certificate-based mutual authentic ation MUST support certificate path		The implementation of certificate-based mutual authentic ation <bcp14>MUST</bcp14> support certificate path
	verification as described in <xref target="RFC5280" sect ion="6"/>.		verification as described in <xref target="RFC5280" sect ion="6"/>.
	</t>		</t>
	<t>		<t>
	In some deployments, a peer may be isolated from a remot e peer's CA.		In some deployments, a peer may be isolated from a remot e peer's CA.
	Implementations for these deployments MUST support certi		Implementations for these deployments <bcp14>MUST</bcp14
	ficate chains		> support certificate chains
	(a.k.a. bundles or chains of trust), where the entire ch		(aka bundles or chains of trust), where the entire chain
	ain of the remote's certificate is		of the remote peer's certificate is
	stored		stored
	on the local peer.		on the local peer.
	</t>		</t>
	<t>		<t>
	TLS Cached Information Extension		TLS Cached Information Extension
	<xref target="RFC7924"/>		<xref target="RFC7924"/>
	SHOULD be implemented. This MAY be augmented with RPKs < xref target="RFC7250"/>,		<bcp14>SHOULD</bcp14> be implemented. This <bcp14>MAY</b cp14> be augmented with RPKs <xref target="RFC7250"/>,
	though		though
	revocation must be handled as it is not part of the stan dard.		revocation must be handled as it is not part of that spe cification.
	</t>		</t>
	<t>		<t>
	Other approaches may be used for loading the intermediat e certificates onto the client, but		Other approaches may be used for loading the intermediat e certificates onto the client, but
	MUST		they <bcp14>MUST</bcp14>
	include support for revocation checking. For example,		include support for revocation checking. For example,
	<xref target="RFC5280"/>		<xref target="RFC5280"/>
	details the Authority Information Access (AIA) extension to provide information about the		details the Authority Information Access (AIA) extension to provide information about the
	issuer		issuer
	of the certificate in which the extension appears. It ca n be used to provide the address of		of the certificate in which the extension appears. It ca n be used to provide the address of
	the		the
	Online Certificate Status Protocol (OCSP) responder from where revocation status of the		Online Certificate Status Protocol (OCSP) responder from where the revocation status of the
	certificate (which includes the extension) can be checke d.		certificate (which includes the extension) can be checke d.
	</t>		</t>
	</section>		</section>
	<section title="TLS Certificate Identification">		<section>
	<t>For the client-side validation of presented TLS TACACS+ s		<name>TLS Certificate Identification</name>
	erver identities, implementations MUST follow		<t>For the client-side validation of presented TLS TACACS+ s
	<xref target="RFC9525"/>		erver identities, implementations <bcp14>MUST</bcp14> follow the validation tech
	validation techniques. Identifier types DNS-ID, IP-ID, o		niques defined in
	r SRV-ID		<xref target="RFC9525"/>.
	are applicable for use with the TLS TACACS+ protocol, se		Identifier types DNS-ID, IP-ID, or SRV-ID
	lected by operators depending upon		are applicable for use with the TLS TACACS+ protocol; th
			ey are selected by operators depending upon
	the		the
	deployment design. TLS TACACS+ does not use URI-IDs for TLS TACACS+ server identity verification.</t>		deployment design. TLS TACACS+ does not use URI-IDs for TLS TACACS+ server identity verification.</t>
	<t>Wildcards in TLS TACACS+ server identities simplify certi ficate management by allowing a single		<t>Wildcards in TLS TACACS+ server identities simplify certi ficate management by allowing a single
	certificate to secure multiple servers in a deployment. However, this introduces security risks,		certificate to secure multiple servers in a deployment. However, this introduces security risks,
	as compromising the private key of a wildcard certificat e impacts all servers using it.		as compromising the private key of a wildcard certificat e impacts all servers using it.
	To address these risks, the guidelines in <xref target="		To address these risks, the guidelines in <xref target="
	RFC9525" section="6.3"/> MUST be followed,		RFC9525" section="6.3"/> <bcp14>MUST</bcp14> be followed,
	and the wildcard SHOULD be confined to a subdomain dedic		and the wildcard <bcp14>SHOULD</bcp14> be confined to a
	ated solely to TACACS+ servers.</t>		subdomain dedicated solely to TACACS+ servers.</t>
	<t>		<t>
	For the TLS TACACS+ server-side validation of client ide ntities, implementations MUST support the		For the TLS TACACS+ server-side validation of client ide ntities, implementations <bcp14>MUST</bcp14> support the
	ability to		ability to
	configure which fields of a certificate are used for cli ent identification, to verify that		configure which fields of a certificate are used for cli ent identification to verify that
	the		the
	client		client
	is a valid		is a valid
	source for the received certificate and that it is permi tted access		source for the received certificate and that it is permi tted access
	to TACACS+. Implementations MUST support either:		to TACACS+. Implementations <bcp14>MUST</bcp14> support
	</t>		either:</t>
	<t>Network address based validation methods as described in		<ul spacing="normal">
	<xref target="RFC5425"		<li>Network-address-based validation methods as described in <xref
			target="RFC5425" section="5.2"/> or</li>
	section="5.2"/>.		<li>Client Identity validation of a shared identity in the certificate subject
	</t>		AltName. This is
	<t>or</t>
	<t>
	Client Identity validation of a shared identity in the c
	ertificate subjectAltName. This is
	applicable		applicable
	in deployments where the client securely supports an ide ntity which is shared with the		in deployments where the client securely supports an ide ntity which is shared with the
	TLS TACACS+ server. Matching of dNSName and iPAddress MU		TLS TACACS+ server. Matching of dNSName and iPAddress <b
	ST be supported. Other options defined		cp14>MUST</bcp14> be supported. Other options defined
	in <xref target="RFC5280" section="4.2.1.6"/> MAY be sup		in <xref target="RFC5280" section="4.2.1.6"/> <bcp14>MAY
	ported.		</bcp14> be supported.
	This approach allows a client's network location to be r econfigured without issuing a new		This approach allows a client's network location to be r econfigured without issuing a new
	client		client
	certificate.		certificate.</li></ul>
	</t>
	<t>		<t>
	Implementations MUST support the TLS Server Name Indicat ion extension (SNI) (<xref		Implementations <bcp14>MUST</bcp14> support the TLS Serv er Name Indication (SNI) extension (<xref
	target="RFC6066"		target="RFC6066"
	section="3"/>).		section="3"/>).
	TLS TACACS+ clients MUST support the ability to configur e the TLS TACACS+ server's domain name, so that it may be		TLS TACACS+ clients <bcp14>MUST</bcp14> support the abil ity to configure the TLS TACACS+ server's domain name, so that it may be
	included		included
	in		in
	the		the
	SNI "server_name" extension of the client hello (This is distinct from the IP Address or hostname configuration used for the TCP connect ion). Refer to		SNI "server_name" extension of the client hello (This is distinct from the IP Address or hostname configuration used for the TCP connect ion). Refer to
	<xref target="TLSSNISec"/>		<xref target="TLSSNISec"/>
	for security related operator considerations.		for security related operator considerations.
	</t>		</t>
	<t>Certificate provisioning is out of scope of this document .</t>		<t>Certificate provisioning is out of scope of this document .</t>
	</section>		</section>
	<section title="Cipher Suites Requirements">		<section>
			<name>Cipher Suites Requirements</name>
	<t>		<t>
	Implementations MUST support the TLS 1.3 mandatory ciphe		Implementations <bcp14>MUST</bcp14> support the TLS 1.3
	r suites (<xref target="RFC8446" section="9.1"/>).		mandatory cipher suites (<xref target="RFC8446" section="9.1"/>).
	Readers should refer to <xref target="BCP195"/>. The cip		Readers should refer to <xref target="BCP195"/>. The cip
	her suites offered or accepted SHOULD be configurable so that operators can adap		her suites offered or accepted <bcp14>SHOULD</bcp14> be configurable so that ope
	t.		rators can adapt.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="TLS PSK Authentication" anchor="PSKAuth">		<section anchor="PSKAuth">
			<name>TLS PSK Authentication</name>
	<t>		<t>
	As an alternative to certificate-based authentication, imple mentations MAY support PSKs, also known as External PSKs in TLS 1.3 <xref target ="RFC8446"/>. These should not be confused with resumption PSKs.		As an alternative to certificate-based authentication, imple mentations <bcp14>MAY</bcp14> support PSKs, also known as external PSKs in TLS 1 .3 <xref target="RFC8446"/>. These should not be confused with resumption PSKs.
	</t>		</t>
	<t>		<t>
	The use of External PSKs is less well established than certi		The use of external PSKs is less well established than certi
	ficate-based authentication. It is		ficate-based authentication. It is
	RECOMMENDED that systems follow the directions of <xref targ		<bcp14>RECOMMENDED</bcp14> that systems follow the direction
	et="RFC9257"/> and <xref target="RFC8446" section="4"/>.		s of <xref target="RFC9257"/> and <xref target="RFC8446" section="4"/>.
	</t>		</t>
	<t>		<t>
	Where PSK Authentication is implemented, PSK lengths of at l east 16 octets MUST be supported.		Where PSK authentication is implemented, PSK lengths of at l east 16 octets <bcp14>MUST</bcp14> be supported.
	</t>		</t>
	<t>		<t>
	PSK Identity MUST follow recommendations of <xref target="RF C9257" section="6.1"/>. Implementations MUST support PSK identities		PSK identity <bcp14>MUST</bcp14> follow recommendations of < xref target="RFC9257" section="6.1"/>. Implementations <bcp14>MUST</bcp14> suppo rt PSK identities
	of at least 16 octets.		of at least 16 octets.
	</t>		</t>
	<t>		<t>
	Although this document removes the option of MD5 obfuscation		Although this document removes the option of MD5 obfuscation
	(<xref target="ObsolescenceOfTACACSObfuscation"/>), it is still possible that t		(<xref target="ObsolescenceOfTACACSObfuscation"/>), it is still possible that t
	he TLS and Non-TLS		he TLS and non-TLS
	versions of TACACS+ may exist in an organization, for exampl		versions of TACACS+ exist in an organization, for example, d
	e, during migration (<xref target="MIGRATION"/>).		uring migration (<xref target="MIGRATION"/>).
	In such cases, the shared secrets configured for TACACS+ obf		In such cases, the shared secrets configured for TACACS+ obf
	uscation clients MUST NOT be the same as the PSKs configured for TLS clients.		uscation clients <bcp14>MUST NOT</bcp14> be the same as the PSKs configured for
			TLS clients.
	</t>		</t>
	<t>		<t>
	</t>		</t>
	</section>		</section>
	<section title="TLS Resumption" anchor="TLSResumption">		<section 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>		<t>
	The TLS Resumption protocol, detailed in <xref target="RFC84 46"/>, can minimize the number of round trips required during the handshake proc ess.		The TLS Resumption protocol, detailed in <xref target="RFC84 46"/>, can minimize the number of round trips required during the handshake proc ess.
	If a TLS client holds a ticket previously extracted from a N ewSessionTicket message from the TLS TACACS+ server, it can use the PSK identity tied to that ticket.		If a TLS client holds a ticket previously extracted from a N ewSessionTicket 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 a cknowledged as authenticated and securely linked to		If the TLS TACACS+ server consents, the resumed session is a cknowledged as authenticated and securely linked to
	the initial session.		the initial session.
	</t>		</t>
	<t>The client SHOULD use resumption when it holds a valid unused ticket from the TLS TACACS+ server,		<t>The client <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 req uest,		as each ticket is intended for a single use only and will be refreshed during resumption. The TLS TACACS+ server can reject a resumption req uest,
	but the TLS TACACS+ server SHOULD allow resumption if the ti cket in question has not expired and has not been used before.		but the TLS TACACS+ server <bcp14>SHOULD</bcp14> allow resum ption if the ticket in question has not expired and has not been used before.
	</t>		</t>
	<t>		<t>
	When a TLS TACACS+ server is presented with a resumption req uest from the TLS client, it MAY still choose to require a full handshake.		When a TLS TACACS+ server is presented with a resumption req uest from the TLS client, it <bcp14>MAY</bcp14> still choose to require a full h andshake.
	In this case, the negotiation proceeds as if the session was a new authentication,		In this case, the negotiation proceeds as if the session was a new authentication,
	and the resumption attempt is ignored. As described in <xre f target="RFC8446" section="C.4"/>, reuse of a ticket allows passive observers t o correlate		and the resumption attempt is ignored. As described in <xre f target="RFC8446" section="C.4"/>, reuse of a ticket allows passive observers t o correlate
	different connections. TLS TACACS+ clients and servers SHOUL D follow the client tracking preventions in <xref target="RFC8446" section="C.4" />.		different connections. TLS TACACS+ clients and servers <bcp1 4>SHOULD</bcp14> follow the client tracking preventions in <xref target="RFC8446 " section="C.4"/>.
	</t>		</t>
	<t>		<t>
	When processing TLS resumption, certificates must be verifie d to check for revocation during the period since the last NewSessionTicket Mes sage.		When processing TLS resumption, certificates must be verifie d to check for revocation during the period since the last NewSessionTicket Mes sage.
	</t>		</t>
	<t>The resumption ticket_lifetime SHOULD be configurable, includ ing a zero		<t>The resumption ticket_lifetime <bcp14>SHOULD</bcp14> be confi gurable, including a zero
	seconds lifetime. Refer to <xref target="RFC8446" section="4 .6.1"/> for guidance on ticket lifetime.		seconds lifetime. Refer to <xref target="RFC8446" section="4 .6.1"/> for guidance on ticket lifetime.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="Obsolescence of TACACS+ Obfuscation" anchor="Obsolescenc		<section anchor="ObsolescenceOfTACACSObfuscation">
	eOfTACACSObfuscation">		<name>Obsolescence of TACACS+ 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 obfus
			cation 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>		<t>
	<xref target="RFC8907"/> describes the obfuscation mechanism, do cumented in <xref target="RFC5425" section="5.2"/>.		<xref target="RFC8907"/> describes the obfuscation mechanism, do cumented in <xref target="RFC5425" section="5.2"/>.
	Such a method is weak.		Such a method is weak.
	</t>		</t>
	<t>		<t>
	The introduction of TLS authentication and encryption to TACACS+ replaces		The introduction of TLS authentication and encryption to TACACS+ replaces
	this former mechanism and so obfuscation is hereby obsoleted.		this former mechanism, so obfuscation is hereby obsoleted.
	This section describes how the TACACS+ client and servers MUST o		This section describes how the TACACS+ client and servers <bcp14
	perate regarding the obfuscation		>MUST</bcp14> operate regarding the obfuscation
	mechanism.		mechanism.
	</t>		</t>
	<t>		<t>
	Peers MUST NOT use obfuscation with TLS.		Peers <bcp14>MUST NOT</bcp14> use obfuscation with TLS.
	</t>		</t>
	<t>		<t>
	A TACACS+ client initiating a TACACS+ TLS connection MUST set th e TAC_PLUS_UNENCRYPTED_FLAG bit, thereby		A TACACS+ client initiating a TACACS+ TLS connection <bcp14>MUST </bcp14> set the TAC_PLUS_UNENCRYPTED_FLAG bit, thereby
	asserting that obfuscation is not used for the session.		asserting that obfuscation is not used for the session.
	All subsequent packets MUST have the TAC_PLUS_UNENCRYPTED_FLAG b it set to 1.		All subsequent packets <bcp14>MUST</bcp14> have the TAC_PLUS_UNE NCRYPTED_FLAG bit set to 1.
	</t>		</t>
	<t>		<t>
	A TLS TACACS+ server that receives a packet with the TAC_PLUS_UN ENCRYPTED_FLAG bit not set to 1 over a TLS		A TLS TACACS+ server that receives a packet with the TAC_PLUS_UN ENCRYPTED_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		connection <bcp14>MUST</bcp14> return an error of TAC_PLUS_AUTHE N_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR, or
	TAC_PLUS_ACCT_STATUS_ERROR as appropriate for the TACACS+ messag e type, with the		TAC_PLUS_ACCT_STATUS_ERROR as appropriate for the TACACS+ messag e type, with the
	TAC_PLUS_UNENCRYPTED_FLAG bit set to 1, and terminate the sessio n.		TAC_PLUS_UNENCRYPTED_FLAG bit set to 1, and terminate the sessio n.
	This behavior corresponds to that defined in Section 4.5 of		This behavior corresponds to that defined in
	<xref target="RFC8907"/> Data Obfuscation for TAC_PLUS_UNENCRYPT		<xref target="RFC8907" section="4.5"/> regarding Data Obfuscatio
	ED_FLAG or key mismatches.		n for TAC_PLUS_UNENCRYPTED_FLAG or key mismatches.
	</t>		</t>
	<t>		<t>
	A TACACS+ client that receives a packet with the TAC_PLUS_UNENCR		A TACACS+ client that receives a packet with the TAC_PLUS_UNENCR
	YPTED_FLAG bit not set to 1 MUST		YPTED_FLAG bit not set to 1 <bcp14>MUST</bcp14>
	terminate the session, and SHOULD log this error.		terminate the session, and <bcp14>SHOULD</bcp14> log this error.
	</t>		</t>
	</section>		</section>
	<section title="Security Considerations" anchor="Security">		<section anchor="Security">
	<section title="TLS">		<name>Security Considerations</name>
			<section>
			<name>TLS</name>
	<t>		<t>
	This document improves the confidentiality, integrity, and a uthentication of the connection and		This document improves the confidentiality, integrity, and a uthentication of the connection and
	network traffic between TACACS+ peers by adding TLS support.		network traffic between TACACS+ peers by adding TLS support.
	</t>		</t>
	<t>		<t>
	Simply adding TLS support to the protocol does not guarantee the protection		Simply adding TLS support to the protocol does not guarantee the protection
	of the TLS TACACS+ server and clients. It is essential for t he operators and equipment vendors		of the TLS TACACS+ server and clients. It is essential for t he operators and equipment vendors
	to adhere to the latest best practices for ensuring the inte grity of network devices		to adhere to the latest best practices for ensuring the inte grity of network devices
	and selecting secure TLS key and encryption algorithms.		and selecting secure TLS key and encryption algorithms.
	</t>		</t>
	<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"/>		<xref target="BCP195"/>
	offers substantial guidance for implementing protocols that use		offers substantial guidance for implementing protocols that use
	TLS and their deployment. Those implementing and deploying S ecure TACACS+		TLS and their deployment. Those implementing and deploying S ecure TACACS+
	must adhere to the recommendations relevant to TLS 1.3 outli ned in <xref target="BCP195"/>		must adhere to the recommendations relevant to TLS 1.3 outli ned in <xref target="BCP195"/>
	or its subsequent versions.		or its subsequent versions.
	</t>		</t>
	<t>		<t>
	This document outlines additional restrictions permissible u nder <xref target="BCP195"/>		This document outlines additional restrictions permissible u nder <xref target="BCP195"/>.
	For example, any recommendations referring to TLS 1.2, inclu ding the mandatory		For example, any recommendations referring to TLS 1.2, inclu ding the mandatory
	support, are not relevant for Secure TACACS+ as TLS 1.3 or a bove is mandated.		support, are not relevant for Secure TACACS+ as TLS 1.3 or a bove is mandated.
	</t>		</t>
	<t>		<t>
	This document concerns the use of TLS as transport for TACAC		This document concerns the use of TLS as transport for TACAC
	S+, and does not make any changes to the core TACACS+		S+ and does not make any changes to the core TACACS+
	protocol, other than the direct implications of deprecating		protocol, other than the direct implications of deprecating
	obfuscation. Operators MUST be cognizant of the security		obfuscation. Operators <bcp14>MUST</bcp14> be cognizant of the security
	implications of the TACACS+ protocol itself. Further documen		implications of the TACACS+ protocol itself. Further documen
	ts are planned, for example, to address the security implications of password		ts are planned, for example, to address the security implications of password-ba
	based authentication and enhance the protocol to accommodate		sed authentication and enhance the protocol to accommodate alternative schemes.
	alternative schemes.
	</t>		</t>
	<section title="TLS Use" anchor="TLSUSE">		<section anchor="TLSUSE">
			<name>TLS Use</name>
	<t>		<t>
	New TACACS+ production deployments SHOULD use TLS authen tication and encryption. Also see <xref target="RFC3365"/>.		New TACACS+ production deployments <bcp14>SHOULD</bcp14> use TLS authentication and encryption. Also see <xref target="RFC3365"/>.
	</t>		</t>
	<t>		<t>
	TLS TACACS+ servers (as defined in <xref target ="TLSTac		TLS TACACS+ servers (as defined in <xref target ="TLSTac
	acsServerDefinition"/>) MUST NOT allow Non-TLS connections, because of the threa		acsServerDefinition"/>) <bcp14>MUST NOT</bcp14> allow non-TLS connections, becau
	t		se of the threat
	of downgrade attacks or misconfiguration described in <x		of downgrade attacks or misconfiguration described in <x
	ref target="wellknown"/>. Instead, separate Non-TLS TACACS+ servers		ref target="wellknown"/>. Instead, separate non-TLS TACACS+ servers
	SHOULD be set up to cater for these clients.		<bcp14>SHOULD</bcp14> be set up to cater for these clien
			ts.
	</t>		</t>
	<t>		<t>
	It is NOT RECOMMENDED that TLS TACACS+ servers and Non-T LS TACACS+ servers be deployed		It is <bcp14>NOT RECOMMENDED</bcp14> that TLS TACACS+ se rvers and non-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		on the same host, for reasons discussed in <xref target= "wellknown"/>. Non-TLS connections would be better served by deploying the
	required Non-TLS TACACS+ servers on separate hosts.		required non-TLS TACACS+ servers on separate hosts.
	</t>		</t>
	<t>		<t>
	TACACS+ Clients MUST NOT fail back to a Non-TLS connecti on if a TLS connection fails. This prohibition includes during the migration of a deployment (<xref target="MIGRATION"/>).		TACACS+ clients <bcp14>MUST NOT</bcp14> fail back to a n on-TLS connection if a TLS connection fails. This prohibition includes during th e migration of a deployment (<xref target="MIGRATION"/>).
	</t>		</t>
	</section>		</section>
	<section title="TLS 0-RTT">		<section>
			<name>TLS 0-RTT</name>
	<t>		<t>
	TLS 1.3 resumption and PSK techniques make it possible t o send Early Data, aka. 0-RTT data, data		TLS 1.3 resumption and PSK techniques make it possible t o send early data, aka 0-RTT data, data
	that is sent before the TLS handshake completes.		that is sent before the TLS handshake completes.
	Replay of this data is a risk.		Replay of this data is a risk.
	Given the sensitivity of TACACS+ data, clients MUST NOT		Given the sensitivity of TACACS+ data, clients <bcp14>MU
	send data until the full TLS handshake		ST NOT</bcp14> send data until the full TLS handshake
	completes; that is, clients MUST NOT send 0-RTT data and		completes; that is, clients <bcp14>MUST NOT</bcp14> send
	TLS TACACS+ servers MUST abruptly disconnect		0-RTT data and TLS TACACS+ servers <bcp14>MUST</bcp14> abruptly disconnect
	clients that do.		clients that do.
	</t>		</t>
	<t>TLS TACACS+ clients and servers MUST NOT include the "ear ly_data" extension. See sections 2.3 and 4.2.10 of <xref target="RFC8446"/>		<t>TLS TACACS+ clients and servers <bcp14>MUST NOT</bcp14> i nclude the "early_data" extension. See Sections <xref target="RFC8446" sectionFo rmat="bare" section="2.3"/> and <xref target="RFC8446" sectionFormat="bare" sect ion="4.2.10"/> of <xref target="RFC8446"/>
	for security concerns.</t>		for security concerns.</t>
	</section>		</section>
	<section title="TLS Options">		<section>
			<name>TLS Options</name>
	<t>Recommendations in		<t>Recommendations in
	<xref target="BCP195"/>		<xref target="BCP195"/>
	MUST be followed to determine which TLS versions and alg orithms should be supported,		<bcp14>MUST</bcp14> be followed to determine which TLS v ersions and algorithms should be supported,
	deprecated, obsoleted, or abandoned.		deprecated, obsoleted, or abandoned.
	</t>		</t>
	<t>		<t>
	Also,		Also,
	<xref target="RFC8446" section="9"/>		<xref target="RFC8446" section="9"/>
	prescribes mandatory supported options.		prescribes mandatory supported options.
	</t>		</t>
	</section>		</section>
	<section title="Unreachable Certification Authority (CA)" anchor		<section anchor="CAcache">
	="CAcache">		<name>Unreachable Certification Authority (CA)</name>
	<t>		<t>
	Operators should be cognizant of the potential of TLS TA CACS+ server and/or client isolation from their		Operators should be cognizant of the potential of TLS TA CACS+ server and/or client isolation from their
	peer's CA by network failures.		peer's CA by network failures.
	Isolation from a public key certificate's CA will cause the verification of the certificate to		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.		fail and thus TLS authentication of the peer to fail.
	The approach mentioned in		The approach mentioned in
	<xref target="CertPV"/>		<xref target="CertPV"/>
	can help address this and should be considered where imp lemented.		can help address this and should be considered where imp lemented.
	</t>		</t>
	</section>		</section>
	<section title="TLS Server Name Indicator (SNI)" anchor="TLSSNIS		<section anchor="TLSSNISec">
	ec">		<name>TLS Server Name Indicator (SNI)</name>
	<t>		<t>
	Operators should be aware that the TLS SNI extension is part of the TLS client hello, which is sent in cleartext. It is,		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 targ et="RFC6066" section="11.1"/>.		therefore, subject to eavesdropping. Also see <xref targ et="RFC6066" section="11.1"/>.
	</t>		</t>
	</section>		</section>
	<section title="Server Identity Wildcards" anchor="SIWildcards">		<section anchor="SIWildcards">
			<name>Server Identity Wildcards</name>
			<!-- [rfced] The use of "MUST" twice in this sentence reads oddly. Please revie
			w.
			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>		<t>
	The use of wildcards in TLS server identities creates a single point of failure:		The use of wildcards in TLS server identities creates a single point of failure:
	a compromised private key of a wildcard certificate impa cts all servers using it.		a compromised private key of a wildcard certificate impa cts all servers using it.
	Their use MUST follow recommendations of <xref target="R		Their use <bcp14>MUST</bcp14> follow the recommendations
	FC9525" section="7.1"/>.		of <xref target="RFC9525" section="7.1"/>.
	Operators MUST ensure that the wildcard is limited to a		Operators <bcp14>MUST</bcp14> ensure that the wildcard i
	subdomain dedicated solely to TLS TACACS+ servers.		s limited to a subdomain dedicated solely to TLS TACACS+ servers.
	Further, operators MUST ensure that the TLS TACACS+ serv		Further, operators <bcp14>MUST</bcp14> ensure that the T
	ers covered by a wildcard certificate MUST be impervious		LS TACACS+ servers covered by a wildcard certificate <bcp14>MUST</bcp14> be impe
			rvious
	to redirection of traffic to a different server (for exa mple, due to on-path attacks or DNS cache poisoning).		to redirection of traffic to a different server (for exa mple, due to on-path attacks or DNS cache poisoning).
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="TACACS+ Configuration" anchor="TACACSConfiguration">		<section anchor="TACACSConfiguration">
			<name>TACACS+ Configuration</name>
	<t>		<t>
	Implementors must ensure that the configuration scheme intro duced		Implementors must ensure that the configuration scheme intro duced
	for enabling TLS is straightforward and leaves no room for a mbiguity regarding whether		for enabling TLS is straightforward and leaves no room for a mbiguity regarding whether
	TLS or Non-TLS will be used between the TACACS+ client and t he TACACS+ server.		TLS or non-TLS will be used between the TACACS+ client and t he TACACS+ server.
	</t>		</t>
	<t>		<t>
	This document recommends the use of a separate port number t hat TLS TACACS+ servers		This document recommends the use of a separate port number t hat TLS TACACS+ servers
	will listen to. Where deployments have not overridden the de faults explicitly,		will listen to. Where deployments have not overridden the de faults explicitly,
	TACACS+ client implementations MUST use the correct values:		TACACS+ client implementations <bcp14>MUST</bcp14> use the c orrect port values:
	</t>		</t>
	<ul>		<ul>
	<li>for Non-TLS connection TACACS+: Port number 49.</li>		<li>49: for non-TLS connection TACACS+</li>
	<li>for TLS connection TACACS+: (TBD).</li>		<li>300: for TLS connection TACACS+</li>
	</ul>		</ul>
	<t>		<t>
	Implementors may offer a single option for TACACS+ clients a nd servers to disable all		Implementors may offer a single option for TACACS+ clients a nd servers to disable all
	Non-TLS TACACS+ operations. When enabled on a TACACS+ server		non-TLS TACACS+ operations. When enabled on a TACACS+ server
	, it will		, it will
	not respond to any requests from Non-TLS TACACS+ client conn		not respond to any requests from non-TLS TACACS+ client conn
	ections. When enabled on		ections. When enabled on
	a TACACS+ client, it will not establish any Non-TLS TACACS+		a TACACS+ client, it will not establish any non-TLS TACACS+
	server connections.		server connections.
	</t>		</t>
	</section>		</section>
	<section title="Well-Known TCP/IP Port Number" anchor="wellknown">		<section anchor="wellknown">
			<name>Well-Known TCP/IP Port Number</name>
	<t>		<t>
	A new port number is considered appropriate (rather than a m echanism that negotiates an		A new port number is considered appropriate (rather than a m echanism that negotiates an
	upgrade from an initial Non-TLS TACACS+ Connection) because it allows:		upgrade from an initial non-TLS TACACS+ connection) because it allows:
	</t>		</t>
	<ul>		<ul>
	<li>ease of blocking the unobfuscated or obfuscated connecti ons by the TCP/IP port number,</li>		<li>ease of blocking the unobfuscated or obfuscated connecti ons by the TCP/IP port number,</li>
	<li>passive Intrusion Detection Systems (IDSs) monitoring th e unobfuscated to be unaffected by the		<li>passive Intrusion Detection Systems (IDSs) monitoring th e unobfuscated to be unaffected by the
	introduction of TLS,		introduction of TLS,
	</li>		</li>
	<li>avoidance of on-path attacks that can interfere with upg rade, and</li>		<li>avoidance of on-path attacks that can interfere with upg rade, and</li>
	<li>prevention of the accidental exposure of sensitive infor mation due to misconfiguration.</li>		<li>prevention of the accidental exposure of sensitive infor mation due to misconfiguration.</li>
	</ul>		</ul>
	<t>		<t>
	However, co-existence of inferior authentication and obfusca		However, the coexistence of inferior authentication and obfu
	ted, whether a Non-TLS connection or		scation, whether a non-TLS connection or
	deprecated parts that compose TLS, also presents opportunity		deprecated parts that compose TLS, also presents an opportun
	for down-grade attacks.		ity for downgrade attacks.
	Causing failure of connections to the TLS-enabled service or the negotiation of shared algorithm		Causing failure of connections to the TLS-enabled service or the negotiation of shared algorithm
	support are two such down-grade attacks.		support are two such downgrade attacks.
	</t>		</t>
	<t>		<t>
	The simplest mitigation exposure from Non-TLS connection met		The simplest mitigation exposure from non-TLS connection met
	hods is to refuse Non-TLS		hods is to refuse non-TLS
	connections at the host entirely, perhaps using separate hos		connections at the host entirely, perhaps using separate hos
	ts for Non-TLS connections and TLS.		ts for non-TLS connections and TLS.
	</t>		</t>
	<t>		<t>
	Another approach is mutual configuration that requires TLS.		Another approach is mutual configuration that requires TLS.
	TACACS+ clients and servers SHOULD support configuration tha t requires peers, globally and individually, use		TACACS+ clients and servers <bcp14>SHOULD</bcp14> support co nfiguration that requires peers, globally and individually, to use
	TLS.		TLS.
	Furthermore, peers SHOULD be configurable to limit offered o r recognized TLS versions and algorithms		Furthermore, peers <bcp14>SHOULD</bcp14> be configurable to limit offered or recognized TLS versions and algorithms
	to those recommended by standards bodies and implementers.		to those recommended by standards bodies and implementers.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="Operational Considerations" anchor="OPSCONS">		<section anchor="OPSCONS">
			<name>Operational Considerations</name>
	<t>		<t>
	Operational and deployment considerations are spread throughout the		Operational and deployment considerations are spread throughout the
	document. While avoiding repetition, it is useful for the impati ent		document. While avoiding repetition, it is useful for the impati ent
	to direct particular attention to Sections 5.2 and 5.1.5.		to direct particular attention to Sections <xref target="TACACSC
	However, it is important that the entire Section 5 is observed.		onfiguration" format="counter"/> and <xref target="TLSSNISec" format="counter"/>
			.
			However, it is important that the entire <xref target="Security"
			/> is observed.
	</t>		</t>
	<t>It is essential for operators to understand the implications of a TLS		<t>It is essential for operators to understand the implications of a TLS
	certificate-based authentication solution, including the cor rect handling of certificates, CAs, and all		certificate-based authentication solution, including the cor rect handling of certificates, CAs, and all
	elements of TLS configuration. Refer to <xref target="BCP195 "/> for guidance. Attention is drawn to the provisioning		elements of TLS configuration. Refer to <xref target="BCP195 "/> for guidance. Attention is drawn to the provisioning
	of Certificates to all peers, including TACACS+ TLS clients, to		of certificates to all peers, including TACACS+ TLS clients, to
	permit the mandatory mutual authentication.</t>		permit the mandatory mutual authentication.</t>
	<section title="Migration" anchor="MIGRATION">		<section anchor="MIGRATION">
			<name>Migration</name>
	<t>		<t>
	Section 5.2 mentions that for an optimal deployment of TLS T ACACS+,		<xref target="TACACSConfiguration"/> mentions that for an op timal deployment of TLS TACACS+,
	TLS should be universally applied throughout the deployment. However, during		TLS should be universally applied throughout the deployment. However, during
	the migration process from a Non-TLS TACACS+ deployment, ope		the migration process from a non-TLS TACACS+ deployment, ope
	rators may need		rators may need
	to support both TLS and Non-TLS TACACS+ servers. This migrat		to support both TLS and non-TLS TACACS+ servers. This migrat
	ion phase allows		ion phase allows
	operators to gradually transition their deployments from an insecure state to		operators to gradually transition their deployments from an insecure state to
	a more secure one, but it is important to note that it is vu lnerable to		a more secure one, but it is important to note that it is vu lnerable to
	downgrade attacks. Therefore, the migration phase should be considered		downgrade attacks. Therefore, the migration phase should be considered
	insecure until it is fully completed. To mitigate this hazar d:		insecure until it is fully completed. To mitigate this hazar d:
	</t>		</t>
	<ul>		<ul>
	<li>The period where any client is configured with both TLS and Non-TLS TACACS+ servers should be		<li>The period where any client is configured with both TLS and non-TLS TACACS+ servers should be
	minimized.		minimized.
	</li>		</li>
	<li>The operator must consider the impact of mixed TLS and N		<!-- [rfced] Does the operator need to consider the impact of supporting both TL
	on-TLS on security, as mentioned above.</li>		S 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 no
			n-TLS on security, as mentioned above.</li>
	</ul>		</ul>
	</section>		</section>
	<section title="Maintaining Non-TLS TACACS+ Clients" anchor="NONTLS"		<section anchor="NONTLS">
	>		<name>Maintaining Non-TLS TACACS+ Clients</name>
	<t>		<t>
	Some TACACS+ client devices in a deployment may not implemen t TLS.		Some TACACS+ client devices in a deployment may not implemen t TLS.
	These devices will require access to Non-TLS TACACS+ servers .		These devices will require access to non-TLS TACACS+ servers .
	Operators must follow the recommendation of		Operators must follow the recommendation of
	<xref target="TLSUSE"/>		<xref target="TLSUSE"/>
	and deploy		and deploy
	separate Non-TLS TACACS+ servers for these Non-TLS clients f rom those used		separate non-TLS TACACS+ servers for these non-TLS clients f rom those used
	for the TLS clients.		for the TLS clients.
	</t>		</t>
	</section>		</section>
	<section title="YANG Model for TACACS+ Clients">		<section>
			<name>YANG Model for TACACS+ Clients</name>
	<t>		<t>
	<xref target="ietf-opsawg-secure-tacacs-yang"/> specifies a YANG model for managing TACACS+ clients, including TLS support.		<xref target="I-D.ietf-opsawg-secure-tacacs-yang"/> specifie s a YANG model for managing TACACS+ clients, including TLS support.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="IANA Considerations" anchor="ICTBD">		<section anchor="ICTBD">
	<t>		<name>IANA Considerations</name>
	IANA (has allocated) is requested to allocate a new well-known s		<!-- [rfced] The description of the service name in the first paragraph differs
	ystem TCP/IP port number ([TBD]) for the service name "tacacss", described as		from the what appears in the registration template below it and what appears on
	"TACACS+ over TLS".		the IANA site. Is the intent to relay that the service name "tacacss" is common
	The service name "tacacss" follows the common practice of append		ly referred to as "TACACS+ over TLS" rather than the description in the template
	ing an "s" to the name given to the		? Or, should the descriptions be the same?
	Non-TLS well-known port name.
	This allocation is justified in <xref target="wellknown"/>.		Original:
	</t>		IANA has allocated a new well-known system TCP/IP port number (300)
	<t>IANA (has added) is requested to add tacacss as a new entry to th		for the service name "tacacss", described as "TACACS+ over TLS". The
	e "Service name and Transport Protocol Port Number		service name "tacacss" follows the common practice of appending an
	Registry" available at https://www.iana.org/assignments/service-		"s" to the name given to the Non-TLS well- known port name. This
	names-port-numbers/		allocation is justified in Section 5.3.
	</t>
	<t>Service Name: tacacss</t>		IANA has added tacacss as a new entry to the "Service name and
	<t>Port Number: [TBD]</t>		Transport Protocol Port Number Registry" available at
	<t>Transport Protocol: TCP</t>		<https://www.iana.org/assignments/service-names-port-numbers>.
	<t>Description: TLS Secure Login Host Protocol (TACACSS)</t>
	<t>Assignee: IESG</t>		Description in the template and the IANA registry:
	<t>Contact: IETF Chair</t>		TLS Secure Login Host Protocol (TACACSS)
	<t>Reference: [TBD] (This Document)</t>		See <https://www.iana.org/assignments/service-names-port-numbers/service-names-p
	<t>		ort-numbers.xhtml?=&skey=2&page=6>.
	RFC EDITOR: this port number should replace "[TBD]" within
	this document.		If the text should be the same, perhaps the paragraphs could be combined as foll
	</t>		ows:
			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
			number for 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, this 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>		<t>
	Considerations about service discovery are out of scope of this		IANA has allocated a new well-known system
	document.		TCP/IP port number (300) for the service name "tacacss", described
	</t>		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 bracket
			s="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
			this document.</t>
	</section>		</section>
	<section title="Acknowledgments">		<section>
			<name>Acknowledgments</name>
	<t>		<t>
	The author(s) would like to thank Russ Housley, Steven M. Bellov		The author(s) would like to thank <contact fullname="Russ
	in, Stephen Farrell, Alan DeKok, Warren		Housley"/>, <contact fullname="Steven M.&nbsp;Bellovin"/>, <cont
	Kumari, Tom Petch, Tirumal Reddy, Valery Smyslov, and Mohamed Bo		act
	ucadair for their support, insightful		fullname="Stephen Farrell"/>, <contact fullname="Alan
	review, and/or comments.		DeKok"/>, <contact fullname="Warren Kumari"/>, <contact
	<xref target="RFC5425"/> was also used as a basis for the genera		fullname="Tom Petch"/>, <contact fullname="Tirumal Reddy"/>,
	l approach to TLS.		<contact fullname="Valery Smyslov"/>, and <contact
	<xref target="RFC9190"/> was used as a basis for TLS Resumption		fullname="Mohamed Boucadair"/> for their support, insightful
	Recommendations.		review, and/or comments. <xref target="RFC5425"/> was also
	Although still in draft form at the time of writing, <xref targe		used as a basis for the general approach to TLS. <xref
	t="I-D.ietf-radext-tls-psk"/> was used as a model for PSK Recommendations.		target="RFC9190"/> was used as a basis for TLS resumption
			recommendations. Although still in draft form at the time of
			writing, <xref target="RFC9813"/> was used as
			a model for PSK recommendations.
	</t>		</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references title="Normative References">		<displayreference target="I-D.ietf-opsawg-secure-tacacs-yang" to="TACACS-YANG"/>
			<displayreference target="I-D.ietf-uta-require-tls13" to="REQ-TLS13"/>
	<referencegroup anchor="BCP195" target="https://www.rfc-editor.org/i		<references>
	nfo/bcp195">		<name>References</name>
	<reference anchor="RFC9325" target="https://www.rfc-editor.org/i		<references>
	nfo/rfc9325">		<name>Normative References</name>
	<front>
	<title>Recommendations for Secure Use of Transport Layer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.
	Security (TLS) and Datagram Transport		BCP.0195.xml"/>
	Layer Security (DTLS)
	</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="Y. Sheffer" initials="Y." surname="She		FC.2119.xml"/>
	ffer"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="P. Saint-Andre" initials="P." surname=		FC.5280.xml"/>
	"Saint-Andre"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="T. Fossati" initials="T." surname="Fos		FC.5425.xml"/>
	sati"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	<date month="November" year="2022"/>		FC.6066.xml"/>
	<abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	<t>Transport Layer Security (TLS) and Datagram Trans		FC.7250.xml"/>
	port Layer Security (DTLS) are used to		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	protect data exchanged over a wide range of appl		FC.7924.xml"/>
	ication protocols and can also form the		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	basis for secure transport protocols. Over the y		FC.8174.xml"/>
	ears, the industry has witnessed several		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	serious attacks on TLS and DTLS, including attac		FC.8446.xml"/>
	ks on the most commonly used cipher		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	suites and their modes of operation. This docume		FC.8907.xml"/>
	nt provides the latest recommendations		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	for ensuring the security of deployed services t		FC.9525.xml"/>
	hat use TLS and DTLS. These
	recommendations are applicable to the majority o
	f use cases.
	</t>
	<t>RFC 7525, an earlier version of the TLS recommend
	ations, 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 t
	he guidance given the new environment
	and obsoletes RFC 7525. In addition, this docume
	nt 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"?>
	</references>		</references>
	<references title="Informative References">		<references>
	<reference anchor="FIPS-140-3" target="https://csrc.nist.gov/pubs/fi		<name>Informative References</name>
	ps/140-3/final">		<reference anchor="FIPS-140-3" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NI
	<front>		ST.FIPS.140-3.pdf">
	<title>NIST Federal Information Processing Standards (FIPS)		<front>
	Publication 140-3</title>		<title>Security Requirements for Cryptographic Modules</title>
	<author>		<author>
	<organization showOnFrontPage="true">National Institute		<organization abbrev="NIST">National Institute of Standards and Technology
	of Standards and Technology, U.S.		</organization>
	Department of Commerce		</author>
	</organization>		<date month="March" year="2019"/>
	</author>		</front>
	</front>		<seriesInfo name="NIST FIPS" value="140-3"/>
	</reference>		<seriesInfo name="DOI" value="10.6028/NIST.FIPS.140-3"/>
	<?rfc include="reference.RFC.3365.xml"?>		</reference>
	<?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"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	target="https://datatracker.ietf.org/doc/draft-ietf-opsaw		FC.3365.xml"/>
	g-secure-tacacs-yang/">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	<front>		FC.6151.xml"/>
	<title>A YANG Data Model for Terminal Access Controller Acce		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	ss-Control System Plus (TACACS+) </title>		FC.9190.xml"/>
	<author fullname="Mohamed Boucadair" role="editor">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	</author>		FC.9257.xml"/>
	<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>
	</author>
	<date day="21" month="January" year="2025"/>
	<abstract>
	<t> This document provides implementation and operational co
	nsiderations
	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>		<!-- [I-D.ietf-opsawg-secure-tacacs-yang]
	</abstract>		draft-ietf-opsawg-secure-tacacs-yang-13 - EDIT
	</front>		-->
	<seriesInfo name="Internet-Draft" value="draft-ietf-radext-tls-psk-12"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I
	/>		-D.ietf-opsawg-secure-tacacs-yang.xml"/>
	</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.
	This document updates RFC9325 and discusses post-quantum cryptography		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
	and the security and privacy improvements over TLS 1.2 as a rationale		FC.9813.xml"/>
	for that update.
	</t>		<!-- [I-D.ietf-uta-require-tls13]
	</abstract>		draft-ietf-uta-require-tls13-12 - EDIT
	</front>		-->
	<seriesInfo name="Internet-Draft" value="draft-ietf-uta-require-tls13-		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I
	12"/>		-D.ietf-uta-require-tls13.xml"/>
	</reference>
	</references>
			</references>
			</references>
			<!-- [rfced] This document used both "non-TLS" and "Non-TLS". We have lowercase
			d instances of "Non-TLS" for consistency and because overcapitalization can detr
			act from readability.
			-->
	</back>		</back>
	</rfc>		</rfc>
End of changes. 145 change blocks.
	545 lines changed or deleted		641 lines changed or added
This html diff was produced by rfcdiff 1.48.