rfc9887v1.txt		rfc9887.txt
	Internet Engineering Task Force (IETF) T. Dahm		Internet Engineering Task Force (IETF) T. Dahm
	Request for Comments: 9887		Request for Comments: 9887
	Updates: 8907 J. Heasley		Updates: 8907 J. Heasley
	Category: Standards Track NTT		Category: Standards Track NTT
	ISSN: 2070-1721 D.C. Medway Gash		ISSN: 2070-1721 D.C. Medway Gash
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A. Ota		A. Ota
	Google Inc.		Google Inc.
	October 2025		November 2025
	Terminal Access Controller Access-Control System Plus (TACACS+)		Terminal Access Controller Access-Control System Plus (TACACS+)
	over TLS 1.3		over TLS 1.3
	Abstract		Abstract
	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 channel between a Terminal
	Access Controller Access-Control System Plus (TACACS+) client and		Access Controller Access-Control System Plus (TACACS+) client and
	server. TACACS+ is a protocol used for Authentication,		server. TACACS+ is a protocol used for Authentication,
	skipping to change at line 81 ¶		skipping to change at line 81 ¶
	3.4.2. TLS Certificate Identification		3.4.2. TLS Certificate Identification
	3.4.3. Cipher Suites Requirements		3.4.3. Cipher Suites Requirements
	3.5. TLS PSK Authentication		3.5. TLS PSK Authentication
	3.6. TLS Resumption		3.6. TLS Resumption
	4. Obsolescence of TACACS+ Obfuscation		4. Obsolescence of TACACS+ Obfuscation
	5. Security Considerations		5. Security Considerations
	5.1. TLS		5.1. TLS
	5.1.1. TLS Use		5.1.1. TLS Use
	5.1.2. TLS 0-RTT		5.1.2. TLS 0-RTT
	5.1.3. TLS Options		5.1.3. TLS Options
	5.1.4. Unreachable Certification Authority (CA)		5.1.4. Unreachable Certificate Authority (CA)
	5.1.5. TLS Server Name Indicator (SNI)		5.1.5. TLS Server Name Indicator (SNI)
	5.1.6. Server Identity Wildcards		5.1.6. Server Identity Wildcards
	5.2. TACACS+ Configuration		5.2. TACACS+ Configuration
	5.3. Well-Known TCP/IP Port Number		5.3. Well-Known TCP/IP Port Number
	6. Operational Considerations		6. Operational Considerations
	6.1. Migration		6.1. Migration
	6.2. Maintaining Non-TLS TACACS+ Clients		6.2. Maintaining Non-TLS TACACS+ Clients
	6.3. YANG Model for TACACS+ Clients		6.3. YANG Model for TACACS+ Clients
	7. IANA Considerations		7. IANA Considerations
	8. Acknowledgments		8. Acknowledgments
	skipping to change at line 106 ¶		skipping to change at line 106 ¶
	1. Introduction		1. Introduction
	"The Terminal Access Controller Access-Control System Plus (TACACS+)		"The Terminal Access Controller Access-Control System Plus (TACACS+)
	Protocol" [RFC8907] provides device administration for routers,		Protocol" [RFC8907] provides device administration for routers,
	network access servers, and other networked computing devices via one		network access servers, and other networked computing devices via one
	or more centralized TACACS+ servers. The protocol provides		or more centralized TACACS+ servers. The protocol provides
	authentication, authorization, and accounting services (AAA) for		authentication, authorization, and accounting services (AAA) for
	TACACS+ clients within the device administration use case.		TACACS+ clients within the device administration use case.
	While the content of the protocol is highly sensitive, TACACS+ lacks		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		effective confidentiality, integrity, and authentication of the
	connection and network traffic between the TACACS+ server and client,		connection and network traffic between the TACACS+ server and client.
	requiring secure transport to safeguard a deployment. The security		The security mechanisms as described in Section 10 of [RFC8907] are
	mechanisms as described in Section 10 of [RFC8907] are extremely		extremely weak.
	weak.
	To address these deficiencies, this document updates the TACACS+		To address these deficiencies, this document updates the TACACS+
	protocol to use TLS 1.3 authentication and encryption [RFC8446], and		protocol to use TLS 1.3 authentication and encryption [RFC8446], and
	obsoletes the use of TACACS+ obfuscation mechanisms (Section 10.5 of		obsoletes the use of TACACS+ obfuscation mechanisms (Section 10.5 of
	[RFC8907]). The maturity of TLS in version 1.3 and above makes it a		[RFC8907]). The maturity of TLS in version 1.3 and above makes it a
	suitable choice for the TACACS+ protocol.		suitable choice for the TACACS+ protocol.
	2. Technical Definitions		2. Technical Definitions
	The terms defined in Section 3 of [RFC8907] are fully applicable here		The terms defined in Section 3 of [RFC8907] are fully applicable here
	skipping to change at line 134 ¶		skipping to change at line 134 ¶
	Obfuscation: TACACS+ was originally intended to incorporate a		Obfuscation: TACACS+ was originally intended to incorporate a
	mechanism for securing the body of its packets. The algorithm is		mechanism for securing the body of its packets. The algorithm is
	categorized as Obfuscation in Section 10.5.2 of [RFC8907]. The		categorized as Obfuscation in Section 10.5.2 of [RFC8907]. The
	term is used to ensure that the algorithm is not mistaken for		term is used to ensure that the algorithm is not mistaken for
	encryption. It should not be considered secure.		encryption. It should not be considered secure.
	Non-TLS connection: This term refers to the connection defined in		Non-TLS connection: This term refers to the connection defined in
	[RFC8907]. It is a connection without TLS, using the unsecure		[RFC8907]. It is a connection without TLS, using the unsecure
	TACACS+ authentication and obfuscation (or the unobfuscated option		TACACS+ authentication and obfuscation (or the unobfuscated option
	for test). The use of well-known TCP/IP host port number 49 is		for testing). The use of well-known TCP/IP host port number 49 is
	specified as the default for non-TLS connections.		specified as the default for non-TLS connections.
	TLS connection: A TLS connection is a TCP/IP connection with TLS		TLS connection: A TLS connection is a TCP/IP connection with TLS
	authentication and encryption used by TACACS+ for transport. A		authentication and encryption used by TACACS+ for transport. A
	TLS connection for TACACS+ is always between one TACACS+ client		TLS connection for TACACS+ is always between one TACACS+ client
	and one TACACS+ server.		and one TACACS+ server.
	TLS TACACS+ server: This document describes a variant of the TACACS+		TLS TACACS+ server: This document describes a variant of the TACACS+
	server, introduced in Section 3.2 of [RFC8907], which utilizes TLS		server, introduced in Section 3.2 of [RFC8907], which utilizes TLS
	for transport, and makes some associated protocol optimizations.		for transport, and makes some associated protocol optimizations.
	skipping to change at line 204 ¶		skipping to change at line 204 ¶
	Options that upgrade an initial non-TLS connection MUST NOT be used;		Options that upgrade an initial non-TLS connection MUST NOT be used;
	see Section 5.3.		see Section 5.3.
	To ensure clear separation between TACACS+ traffic using TLS and that		To ensure clear separation between TACACS+ traffic using TLS and that
	which does not (see Section 5.3), servers supporting TACACS+ over TLS		which does not (see Section 5.3), servers supporting TACACS+ over TLS
	MUST listen on a TCP/IP port distinct from that used by non-TLS		MUST listen on a TCP/IP port distinct from that used by non-TLS
	TACACS+ servers. It is further RECOMMENDED to deploy the TLS and		TACACS+ servers. It is further RECOMMENDED to deploy the TLS and
	non-TLS services on separate hosts, as discussed in Section 5.1.1.		non-TLS services on separate hosts, as discussed in Section 5.1.1.
	Given the prevalence of default port usage in existing TACACS+ client		Given the prevalence of default port usage in existing TACACS+ client
	implementations, this specification assigns a well-known TCP port		implementations, this specification assigns well-known TCP port 300
	number for TACACS+ over TLS: 300, with the associated service name		for TACACS+ over TLS (see Section 7).
	"tacacss" (see Section 7). This allows clients to unambiguously
	distinguish between TLS and non-TLS connections, even in the absence
	of an explicitly configured port number.
	While the use of the designated port number is strongly encouraged,		While the use of the designated port number is strongly encouraged,
	deployments with specific requirements MAY use alternative TCP port		deployments with specific requirements MAY use alternative TCP port
	numbers. In such cases, operators must carefully consider the		numbers. In such cases, operators must carefully consider the
	operational implications described in Section 5.3.		operational implications described in Section 5.3.
	3.2. TLS Connection		3.2. TLS Connection
	A TACACS+ client initiates a TLS connection by making a TCP		A TACACS+ client initiates a TLS connection by making a TCP
	connection to a configured TLS TACACS+ server on the TACACS+ TLS port		connection to a configured TLS TACACS+ server on the TACACS+ TLS port
	skipping to change at line 234 ¶		skipping to change at line 231 ¶
	expected that TACACS+, as described in this document, will work with		expected that TACACS+, as described in this document, will work with
	future versions of TLS. Earlier versions of TLS MUST NOT be used.		future versions of TLS. Earlier versions of TLS MUST NOT be used.
	Once the TLS connection has been successfully established, the		Once the TLS connection has been successfully established, the
	exchange of TACACS+ data MUST proceed in accordance with the		exchange of TACACS+ data MUST proceed in accordance with the
	procedures defined in [RFC8907]. However, all TACACS+ messages SHALL		procedures defined in [RFC8907]. However, all TACACS+ messages SHALL
	be transmitted as TLS application data. The TACACS+ obfuscation		be transmitted as TLS application data. The TACACS+ obfuscation
	mechanism defined in [RFC8907] MUST NOT be applied when operating		mechanism defined in [RFC8907] MUST NOT be applied when operating
	over TLS (Section 4).		over TLS (Section 4).
	The connection persists until the TLS TACACS+ peer closes it, either		TLS TACACS+ connections are generally not long-lived. The connection
	due to an error, or at the conclusion of the TACACS+ session, or, if		will be closed by either a TLS+ TACACS Peer if it encounters an error
	Single Connection Mode (Section 4.3 of [RFC8907]) has been		or an inactivity timeout.
	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.
	TACACS+ connections are generally not long-lived. For connections		For connections not operating in Single Connection Mode (as defined
	not operating in Single Connection Mode (as defined in Section 4.3 of		in Section 4.3 of [RFC8907]), the TCP session SHALL be closed upon
	[RFC8907]), the TCP session SHALL be closed upon completion of the		completion of the associated TACACS+ session. Connections operating
	associated TACACS+ session. Connections operating in Single		in Single Connection Mode MAY persist for a longer duration but are
	Connection Mode MAY persist for a longer duration but are typically		typically subject to timeout and closure after a brief period of
	subject to timeout and closure after a brief period of inactivity.		inactivity. Consequently, support for transport-layer keepalive
	Consequently, support for transport-layer keepalive mechanisms is not		mechanisms is not required.
	required.
			Why a connection is closed has no bearing on TLS resumption, unless
			closed by a TLS error, in which case it is possible that the ticket
			has been invalidated.
	TACACS+ clients and servers widely support IPv6 configuration in		TACACS+ clients and servers widely support IPv6 configuration in
	addition to IPv4. This document makes no changes to recommendations		addition to IPv4. This document makes no changes to recommendations
	in this area.		in this area.
	3.3. TLS Authentication Options		3.3. TLS Authentication Options
	Implementations MUST support certificate-based mutual authentication,		Implementations MUST support certificate-based mutual authentication,
	to provide a core option for interoperability between deployments.		to provide a core option for interoperability between deployments.
	This authentication option is specified in Section 3.4.		This authentication option is specified in Section 3.4.
	skipping to change at line 300 ¶		skipping to change at line 297 ¶
	upon the peer, allowing or denying the connection based on		upon the peer, allowing or denying the connection based on
	certificate fields or any other parameters exposed by the		certificate fields or any other parameters exposed by the
	implementation.		implementation.
	Unless disabled by configuration, a peer MUST NOT permit connection		Unless disabled by configuration, a peer MUST NOT permit connection
	of any peer that presents an invalid TLS certificate.		of any peer that presents an invalid TLS certificate.
	3.4.1. TLS Certificate Path Verification		3.4.1. TLS Certificate Path Verification
	The implementation of certificate-based mutual authentication MUST		The implementation of certificate-based mutual authentication MUST
	support certificate path verification as described in Section 6 of		support certificate path validation as described in Section 6 of
	[RFC5280].		[RFC5280].
	In some deployments, a peer may be isolated from a remote peer's CA.		In some deployments, a peer may be isolated from a remote peer's CA.
	Implementations for these deployments MUST support certificate chains		Implementations for these deployments MUST support certificate chains
	(aka bundles or chains of trust), where the entire chain of the		(aka bundles or chains of trust), where the entire chain of the
	remote peer's certificate is stored on the local peer.		remote peer's certificate is stored on the local peer.
	TLS Cached Information Extension [RFC7924] SHOULD be implemented.		TLS Cached Information Extension [RFC7924] SHOULD be implemented.
	This MAY be augmented with RPKs [RFC7250], though revocation must be		This MAY be augmented with RPKs [RFC7250], though revocation must be
	handled as it is not part of that specification.		handled as it is not part of that specification.
	skipping to change at line 398 ¶		skipping to change at line 395 ¶
	Although this document removes the option of MD5 obfuscation		Although this document removes the option of MD5 obfuscation
	(Section 4), it is still possible that the TLS and non-TLS versions		(Section 4), it is still possible that the TLS and non-TLS versions
	of TACACS+ exist in an organization, for example, during migration		of TACACS+ exist in an organization, for example, during migration
	(Section 6.1). In such cases, the shared secrets configured for		(Section 6.1). In such cases, the shared secrets configured for
	TACACS+ obfuscation clients MUST NOT be the same as the PSKs		TACACS+ obfuscation clients MUST NOT be the same as the PSKs
	configured for TLS clients.		configured for TLS clients.
	3.6. TLS Resumption		3.6. TLS Resumption
	The TLS Resumption protocol, detailed in [RFC8446], can minimize the		TLS Resumption [RFC8446] can minimize the number of round trips
	number of round trips required during the handshake process. If a		required during the handshake process. If a TLS client holds a
	TLS client holds a ticket previously extracted from a		ticket previously extracted from a NewSessionTicket message from the
	NewSessionTicket message from the TLS TACACS+ server, it can use the		TLS TACACS+ server, it can use the PSK identity tied to that ticket.
	PSK identity tied to that ticket. If the TLS TACACS+ server		If the TLS TACACS+ server consents, the resumed session is
	consents, the resumed session is acknowledged as authenticated and		acknowledged as authenticated and securely linked to the initial
	securely linked to the initial session.		session.
	The client SHOULD use resumption when it holds a valid unused ticket		The client SHOULD use resumption when it holds a valid unused ticket
	from the TLS TACACS+ server, as each ticket is intended for a single		from the TLS TACACS+ server, as each ticket is intended for a single
	use only and will be refreshed during resumption. The TLS TACACS+		use only and will be refreshed during resumption. The TLS TACACS+
	server can reject a resumption request, but the TLS TACACS+ server		server can reject a resumption request, but the TLS TACACS+ server
	SHOULD allow resumption if the ticket in question has not expired and		SHOULD allow resumption if the ticket in question has not expired and
	has not been used before.		has not been used before.
	When a TLS TACACS+ server is presented with a resumption request from		When a TLS TACACS+ server is presented with a resumption request from
	the TLS client, it MAY still choose to require a full handshake. In		the TLS client, it MAY still choose to require a full handshake. In
	skipping to change at line 432 ¶		skipping to change at line 429 ¶
	When processing TLS resumption, certificates must be verified to		When processing TLS resumption, certificates must be verified to
	check for revocation during the period since the last		check for revocation during the period since the last
	NewSessionTicket Message.		NewSessionTicket Message.
	The resumption ticket_lifetime SHOULD be configurable, including a		The resumption ticket_lifetime SHOULD be configurable, including a
	zero seconds lifetime. Refer to Section 4.6.1 of [RFC8446] for		zero seconds lifetime. Refer to Section 4.6.1 of [RFC8446] for
	guidance on ticket lifetime.		guidance on ticket lifetime.
	4. Obsolescence of TACACS+ Obfuscation		4. Obsolescence of TACACS+ Obfuscation
	[RFC8907] describes the obfuscation mechanism, documented in		The obfuscation mechanism documented in Section 4.5 of [RFC8907].
	Section 5.2 of [RFC5425]. Such a method is weak.		Data Obfuscation is weak
	The introduction of TLS authentication and encryption to TACACS+		The introduction of TLS authentication and encryption to TACACS+
	replaces this former mechanism, so obfuscation is hereby obsoleted.		replaces this former mechanism, so obfuscation is hereby obsoleted.
	This section describes how the TACACS+ client and servers MUST		This section describes how the TACACS+ client and servers MUST
	operate regarding the obfuscation mechanism.		operate regarding the obfuscation mechanism.
	Peers MUST NOT use obfuscation with TLS.		Peers MUST NOT use obfuscation with TLS.
	A TACACS+ client initiating a TACACS+ TLS connection MUST set the		A TACACS+ client initiating a TACACS+ TLS connection MUST set the
	TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that obfuscation is		TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that obfuscation is
	skipping to change at line 475 ¶		skipping to change at line 472 ¶
	This document improves the confidentiality, integrity, and		This document improves the confidentiality, integrity, and
	authentication of the connection and network traffic between TACACS+		authentication of the connection and network traffic between TACACS+
	peers by adding TLS support.		peers by adding TLS support.
	Simply adding TLS support to the protocol does not guarantee the		Simply adding TLS support to the protocol does not guarantee the
	protection of the TLS TACACS+ server and clients. It is essential		protection of the TLS TACACS+ server and clients. It is essential
	for the operators and equipment vendors to adhere to the latest best		for the operators and equipment vendors to adhere to the latest best
	practices for ensuring the integrity of network devices and selecting		practices for ensuring the integrity of network devices and selecting
	secure TLS key and encryption algorithms.		secure TLS key and encryption algorithms.
	[BCP195] offers substantial guidance for implementing protocols that		[BCP195] offers substantial guidance for implementing and deploying
	use TLS and their deployment. Those implementing and deploying		protocols that use TLS. Those implementing and deploying Secure
	Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3		TACACS+ must adhere to the recommendations relevant to TLS 1.3
	outlined in [BCP195] or its subsequent versions.		outlined in [BCP195] or its subsequent versions.
	This document outlines additional restrictions permissible under		This document outlines additional restrictions permissible under
	[BCP195]. For example, any recommendations referring to TLS 1.2,		[BCP195]. For example, any recommendations referring to TLS 1.2,
	including the mandatory support, are not relevant for Secure TACACS+		including the mandatory support, are not relevant for Secure TACACS+
	as TLS 1.3 or above is mandated.		as TLS 1.3 or above is mandated.
	This document concerns the use of TLS as transport for TACACS+ and		This document concerns the use of TLS as transport for TACACS+ and
	does not make any changes to the core TACACS+ protocol, other than		does not make any changes to the core TACACS+ protocol, other than
	the direct implications of deprecating obfuscation. Operators MUST		the direct implications of deprecating obfuscation. Operators MUST
	skipping to change at line 533 ¶		skipping to change at line 530 ¶
	concerns.		concerns.
	5.1.3. TLS Options		5.1.3. TLS Options
	Recommendations in [BCP195] MUST be followed to determine which TLS		Recommendations in [BCP195] MUST be followed to determine which TLS
	versions and algorithms should be supported, deprecated, obsoleted,		versions and algorithms should be supported, deprecated, obsoleted,
	or abandoned.		or abandoned.
	Also, Section 9 of [RFC8446] prescribes mandatory supported options.		Also, Section 9 of [RFC8446] prescribes mandatory supported options.
	5.1.4. Unreachable Certification Authority (CA)		5.1.4. Unreachable Certificate Authority (CA)
	Operators should be cognizant of the potential of TLS TACACS+ server		Operators should be cognizant of the potential of TLS TACACS+ server
	and/or client isolation from their peer's CA by network failures.		and/or client isolation from their peer's CA by network failures.
	Isolation from a public key certificate's CA will cause the		Isolation from a public key certificate's CA will cause the
	verification of the certificate to fail and thus TLS authentication		verification of the certificate to fail and thus TLS authentication
	of the peer to fail. The approach mentioned in Section 3.4.1 can		of the peer to fail. The approach mentioned in Section 3.4.1 can
	help address this and should be considered where implemented.		help address this and should be considered where implemented.
	5.1.5. TLS Server Name Indicator (SNI)		5.1.5. TLS Server Name Indicator (SNI)
	skipping to change at line 556 ¶		skipping to change at line 553 ¶
	subject to eavesdropping. Also see Section 11.1 of [RFC6066].		subject to eavesdropping. Also see Section 11.1 of [RFC6066].
	5.1.6. Server Identity Wildcards		5.1.6. Server Identity Wildcards
	The use of wildcards in TLS server identities creates a single point		The use of wildcards in TLS server identities creates a single point
	of failure: a compromised private key of a wildcard certificate		of failure: a compromised private key of a wildcard certificate
	impacts all servers using it. Their use MUST follow the		impacts all servers using it. Their use MUST follow the
	recommendations of Section 7.1 of [RFC9525]. Operators MUST ensure		recommendations of Section 7.1 of [RFC9525]. Operators MUST ensure
	that the wildcard is limited to a subdomain dedicated solely to TLS		that the wildcard is limited to a subdomain dedicated solely to TLS
	TACACS+ servers. Further, operators MUST ensure that the TLS TACACS+		TACACS+ servers. Further, operators MUST ensure that the TLS TACACS+
	servers covered by a wildcard certificate MUST be impervious to		servers covered by a wildcard certificate are impervious to
	redirection of traffic to a different server (for example, due to on-		redirection of traffic to a different server (for example, due to on-
	path attacks or DNS cache poisoning).		path attacks or DNS cache poisoning).
	5.2. TACACS+ Configuration		5.2. TACACS+ Configuration
	Implementors must ensure that the configuration scheme introduced for		Implementors must ensure that the configuration scheme introduced for
	enabling TLS is straightforward and leaves no room for ambiguity		enabling TLS is straightforward and leaves no room for ambiguity
	regarding whether TLS or non-TLS will be used between the TACACS+		regarding whether TLS or non-TLS will be used between the TACACS+
	client and the TACACS+ server.		client and the TACACS+ server.
	skipping to change at line 644 ¶		skipping to change at line 641 ¶
	deployment, operators may need to support both TLS and non-TLS		deployment, operators may need to support both TLS and non-TLS
	TACACS+ servers. This migration phase allows operators to gradually		TACACS+ servers. This migration phase allows operators to gradually
	transition their deployments from an insecure state to a more secure		transition their deployments from an insecure state to a more secure
	one, but it is important to note that it is vulnerable to downgrade		one, but it is important to note that it is vulnerable to downgrade
	attacks. Therefore, the migration phase should be considered		attacks. Therefore, the migration phase should be considered
	insecure until it is fully completed. To mitigate this hazard:		insecure until it is fully completed. To mitigate this hazard:
	* The period where any client is configured with both TLS and non-		* The period where any client is configured with both TLS and non-
	TLS TACACS+ servers should be minimized.		TLS TACACS+ servers should be minimized.
	* The operator must consider the impact of mixed TLS and non-TLS on		* The operator must consider the security impact of supporting both
	security, as mentioned above.		TLS and non-TLS connections, as mentioned above.
	6.2. Maintaining Non-TLS TACACS+ Clients		6.2. Maintaining Non-TLS TACACS+ Clients
	Some TACACS+ client devices in a deployment may not implement TLS.		Some TACACS+ client devices in a deployment may not implement 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 Section 5.1.1 and deploy		Operators must follow the recommendation of Section 5.1.1 and deploy
	separate non-TLS TACACS+ servers for these non-TLS clients from those		separate non-TLS TACACS+ servers for these non-TLS clients from those
	used for the TLS clients.		used for the TLS clients.
	6.3. YANG Model for TACACS+ Clients		6.3. YANG Model for TACACS+ Clients
	[TACACS-YANG] specifies a YANG model for managing TACACS+ clients,		[TACACS-YANG] specifies a YANG model for managing TACACS+ clients,
	including TLS support.		including TLS support.
	7. IANA Considerations		7. IANA Considerations
	IANA has allocated a new well-known system TCP/IP port number (300)		IANA has allocated the following new well-known system in the
	for the service name "tacacss", described as "TACACS+ over TLS". 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		service name "tacacss" follows the common practice of appending an
	"s" to the name given to the non-TLS well-known port name. This		"s" to the name given to the non-TLS well-known port name. See the
	allocation is justified in Section 5.3.		justification for the allocation in Section 5.3.
	IANA has added the following entry to the "Service Name and Transport
	Protocol Port Number Registry" (see
	<https://www.iana.org/assignments/service-names-port-numbers>).
	Service Name: tacacss		Service Name: tacacss
	Port Number: 300		Port Number: 300
	Transport Protocol: TCP		Transport Protocol: TCP
	Description: TLS Secure Login Host Protocol (TACACSS)		Description: TLS Secure Login Host Protocol (TACACSS)
	Assignee: IESG		Assignee: IESG
	Contact: IETF Chair		Contact: IETF Chair
	Reference: RFC 9887		Reference: RFC 9887
	Considerations about service discovery are out of scope of this		Considerations about service discovery are out of scope of this
End of changes. 17 change blocks.
	52 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.48.