TACACS+ TLS 1.3
draft-ietf-opsawg-tacacs-tls13-07
| Document | Type | Active Internet-Draft (opsawg WG) | |
|---|---|---|---|
| Authors | Thorsten Dahm , John Heasley , dcmgash@cisco.com , Andrej Ota | ||
| Last updated | 2024-04-23 | ||
| Replaces | draft-dahm-tacacs-tls13 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
SECDIR Early review
by Russ Housley
Not ready
TSVART Early Review due 2024-05-03
Incomplete
OPSDIR Early Review due 2024-05-03
Incomplete
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Mohamed Boucadair | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | mohamed.boucadair@orange.com |
draft-ietf-opsawg-tacacs-tls13-07
Operations and Management Area Working Group T. Dahm
Internet-Draft
Updates: RFC8907 (if approved) J. Heasley
Intended status: Standards Track NTT
Expires: 25 October 2024 D.C. Medway Gash
Cisco Systems, Inc.
A. Ota
Google Inc.
23 April 2024
TACACS+ TLS 1.3
draft-ietf-opsawg-tacacs-tls13-07
Abstract
The Terminal Access Controller Access-Control System Plus (TACACS+)
Protocol provides device administration for routers, network access
servers and other networked computing devices via one or more
centralized servers. This document adds Transport Layer Security
(TLS 1.3) support to TACACS+ and obsoletes former inferior security
mechanisms.
This document updates RFC RFC8907.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[BCP14] when, and only when, they appear in all capitals, as shown
here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Dahm, et al. Expires 25 October 2024 [Page 1]
Internet-Draft The Terminal Access Controller Access-Co April 2024
This Internet-Draft will expire on 25 October 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 3
2.1. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Non-TLS Connection . . . . . . . . . . . . . . . . . . . 3
2.3. TLS Connection . . . . . . . . . . . . . . . . . . . . . 4
2.4. TACACS+ Server . . . . . . . . . . . . . . . . . . . . . 4
2.5. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. TACACS+ over TLS . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Separating TLS Connections . . . . . . . . . . . . . . . 4
3.2. TLS Connection . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Cipher Requirements . . . . . . . . . . . . . . . . . 5
3.2.2. TLS Authentication . . . . . . . . . . . . . . . . . 6
3.3. TLS Identification . . . . . . . . . . . . . . . . . . . 6
4. Obsolescence of TACACS+ Obfuscation . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. TLS Use . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.2. TLS 0-RTT . . . . . . . . . . . . . . . . . . . . . . 9
5.1.3. TLS Options . . . . . . . . . . . . . . . . . . . . . 9
5.1.4. Unreachable Certificate Authority (CA) . . . . . . . 9
5.1.5. TLS Server Name Indicator (SNI) . . . . . . . . . . . 9
5.2. TACACS+ Configuration . . . . . . . . . . . . . . . . . . 10
5.3. Well-Known TCP/IP Port . . . . . . . . . . . . . . . . . 10
6. Operator Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Migration . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Maintaining Non-TLS TACACS+ Clients . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 12
10. Informative References . . . . . . . . . . . . . . . . . . . 14
Dahm, et al. Expires 25 October 2024 [Page 2]
Internet-Draft The Terminal Access Controller Access-Co April 2024
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The Terminal Access Controller Access-Control System Plus (TACACS+)
Protocol [RFC8907] provides Device Administration for routers,
network access servers and other networked computing devices via one
or more centralized servers. The protocol provides authentication,
authorization and accounting services (AAA) for TACACS+ clients
within the Device Administration use case.
While the content of the protocol is highly sensitive, TACACS+ lacks
effective confidentiality, integrity, and authentication of the
connection and network traffic between the server and client,
requiring secure transport to safeguard a deployment. The existing
TACACS+ mechanisms are extremely weak as described in Section 10 of
[RFC8907].
To address these deficiencies, this document updates the TACACS+
protocol to use TLS 1.3 [RFC8446] authentication and encryption, and
obsoletes the use of its former mechanisms (Section 10.5 of
[RFC8907]).
2. Technical Definitions
The terms defined in Section 3 of [RFC8907] are fully applicable here
and will not be repeated. The following terms are also used in this
document.
2.1. Obfuscation
TACACS+ was originally intended to incorporate a mechanism for
securing the body of its packets. The algorithm is categorized as
Obfuscation in Section 10.5.2 of [RFC8907]. The term should be
interpreted to mean "plaintext", it is used to ensure that the
algorithm is not mistaken for encryption.
2.2. Non-TLS Connection
This term refers to the connection defined in [RFC8907]. It is a
connection without TLS and therefore being plaintext or possibly
using unsecure TACACS+ authentication and obfuscation. The use of
well-known TCP/IP server port number 49 is specified as the default
for Non-TLS connections.
Dahm, et al. Expires 25 October 2024 [Page 3]
Internet-Draft The Terminal Access Controller Access-Co April 2024
2.3. TLS Connection
A TLS connection is a TCP/IP connection with TLS authentication and
encryption used by TACACS+ for transport. A TLS connection for
TACACS+ is always between one TACACS+ client and one TACACS+ Server.
2.4. TACACS+ Server
A TACACS+ server is an instance of the server as defined in
Section 3.2 of [RFC8907] that responds to TACACS+ traffic bound to a
specific port number on a host. This document distinguishes the
TACACS+ server instance from the host itself. A host may have
multiple TACACS+ servers running, each listening on different port
numbers.
2.5. Peer
The peer of a TACACS+ client (or server) in the context of a TACACS+
connection, is a server (or client). Together, the ends of a TACACS+
connection are referred to as peers.
3. TACACS+ over TLS
TACACS+ over TLS takes the protocol defined in [RFC8907], removes the
option for MD5 obfuscation, and specifies the use of TLS (version 1.3
or later) for transport using a new well-known default server port
number. The next sections provide further details and guidance.
TLS is introduced into TACACS+ to fulfill the following requirements:
1. Confidentiality and Integrity: The MD5 obfuscation specified in
[RFC8907] has been shown to be insecure [RFC6151]. This prevents
TACACS+ being used in a FIPS-140 compliant deployment. Securing
TACACS+ protocol with TLS is intended to provide confidentiality
and integrity without requiring the provision of a secured
network.
2. Peer authentication: The authentication capabilities of TLS
replace the pre-shared keys of obfuscation for mutual
authentication.
3.1. Separating TLS Connections
All data exchanged by TACACS+ peers MUST be encrypted, including the
mutual authentication of the peers. Therefore, when a TCP connection
is established for the service, a TLS handshake begins immediately.
Dahm, et al. Expires 25 October 2024 [Page 4]
Internet-Draft The Terminal Access Controller Access-Co April 2024
To ensure separation of TACACS+ traffic that uses TLS from that which
does not (Section 5.3), they will be deployed on different ports.
Due to the widespread use of default port number settings in numerous
existing TACACS+ client configurations, a well-known system TCP/IP
port number will be requested from IANA. Client implementations can
ensure traffic is kept separate. The designated port number is [TBD]
(Section 7) with the service name [TBDN] (Section 7).
Under exceptional circumstances, this document permits any other TCP
port number to be configured when required by deployment specifics,
but the implications in Section 5.3 have to be considered by
operators.
3.2. TLS Connection
A TACACS+ client initiates a TLS connection by making a TCP
connection to a configured server on the TACACS+ TLS port number
([TBD]) (Section 3.1). Once the TCP connection is established, the
client MUST immediately begin the TLS negotiation before sending any
TACACS+ protocol data.
Implementations MUST support TLS 1.3 [RFC8446] and MAY permit TLS 1.3
session resumption. If resumption is supported, the resumption
ticket_lifetime SHOULD be configurable, including a zero seconds
lifetime.
Once the TLS connection is established, the exchange of TACACS+ data
proceeds as normal, except that it is transmitted over TLS as TLS
application data and without TACACS+ obfuscation (Section 4)
The connection persists until the server or client closes it. It
might be closed due to an error or at the conclusion of the TACACS+
session. If Single Connection Mode has been negotiated, it might
remain open after a successful session, until an error or an
inactivity timeout occurs. Why it closed has no bearing on TLS
resumption, unless closed by a TLS error, in which case the ticket
might be invalidated.
3.2.1. Cipher Requirements
Implementations MUST support the TLS 1.3 mandatory cipher suites (TLS
1.3 [RFC8446] Section 9.1). The cipher suites offered or accepted
SHOULD be configurable so that operators can adapt.
This document makes no cipher suite recommendations, but
recommendations can be found in the TLS Cipher Suites section of the
Section 4.3 of [RFC9325].
Dahm, et al. Expires 25 October 2024 [Page 5]
Internet-Draft The Terminal Access Controller Access-Co April 2024
3.2.2. TLS Authentication
Implementations MUST support certificate-based TLS authentication and
certificate revocation bi-directionally for authentication, identity
verification and policy purposes. Certificate path verification as
described in Section 3.2.2.1 MUST be supported.
If the verification succeeds, the authentication is successful and
the connection is permitted. Policy may impose further constraints
upon the peer, allowing or denying the connection based on
certificate fields or any other parameters exposed by the
implementation.
Unless disabled by configuration, a peer MUST disconnect any peer
that presents an invalid TLS Certificate.
In addition to full certificate-based TLS authentication,
implementations MAY support:
* Raw Public Keys [RFC7250]
* Pre-Shared Keys (PSKs) [RFC4279] and [RFC8773], also known as
external PSKs in TLS 1.3, which are not resumption PSKs.
The details of these mechanisms are considered out-of-scope for this
document. Please refer to the RFCs above for implementation,
deployment, and security considerations.
3.2.2.1. TLS Certificate Path Verification
Implementations MUST support certificate Path verification as
described in [RFC5280].
Because a peer could be isolated from a remote peer's Certificate
Authority (CA), implementations MUST support certificate chains
(a.k.a. bundles or chains of trust), where the entire chain of the
remote's certificate is stored on the local peer. TLS Cached
Information Extension [RFC7924] SHOULD be implemented. This MAY be
augmented with Raw Public Keys [RFC7250].
3.3. TLS Identification
RFC EDITOR: [authors to add reference to RFC 9525 here]
Dahm, et al. Expires 25 October 2024 [Page 6]
Internet-Draft The Terminal Access Controller Access-Co April 2024
In addition to authentication of TLS certificates, implementations
MUST allow operators to specify which certificate fields are to be
used for peer-identification, to verify that the peer is a valid
source for the received certificate and that it is permitted access
to TACACS+. Implementations MUST support either:
Network location based validation methods as described in Section 5.2
of [RFC5425].
or
Device Identity based validation methods where the peer's identity is
used in the certificate subjectName. This is applicable in
deployments where the device securely supports an identity which is
shared with its peer. This approach allows a peer's network location
to be reconfigured without issuing a new client certificate. Only
the local server mapping needs to be updated.
Implementations SHOULD support the TLS Server Name Indication
extension (Section 3 of [RFC6066]), and SHOULD include the server
domain name in the SNI "server_name" extension of the client hello.
Certificate Provisioning is out of scope of this document.
4. Obsolescence of TACACS+ Obfuscation
[RFC8907] describes the obfuscation mechanism, documented in
Section 5.2 of [RFC5425]. Such a method is weak.
The introduction of TLS PSK, certificate peer authentication, and TLS
encryption to TACACS+ replaces these former mechanisms and so
obfuscation is hereby obsoleted. This section describes how the
TACACS+ client and servers MUST operate with regards to the
obfuscation mechanism.
Peers MUST NOT use obfuscation with TLS.
A TACACS+ client initiating a TACACS+ TLS connection MUST set the
TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that obfuscation is
not used for the session. All subsequent packets MUST have the
TAC_PLUS_UNENCRYPTED_FLAG set.
Dahm, et al. Expires 25 October 2024 [Page 7]
Internet-Draft The Terminal Access Controller Access-Co April 2024
A TACACS+ server that receives a packet with the
TAC_PLUS_UNENCRYPTED_FLAG not set (cleared) over a TLS connection,
MUST return an error of TAC_PLUS_AUTHEN_STATUS_ERROR,
TAC_PLUS_AUTHOR_STATUS_ERROR, or TAC_PLUS_ACCT_STATUS_ERROR as
appropriate for the TACACS+ message type, with the
TAC_PLUS_UNENCRYPTED_FLAG set, and terminate the session. This
behavior corresponds to that defined in Section 4.5 of [RFC8907] Data
Obfuscation for TAC_PLUS_UNENCRYPTED_FLAG or key mismatches.
A TACACS+ client that receives a packet with the
TAC_PLUS_UNENCRYPTED_FLAG not set (i.e., cleared), MUST terminate the
session, and SHOULD log this error.
5. Security Considerations
5.1. TLS
This document improves the confidentiality, integrity, and
authentication of the connection and network traffic between TACACS+
peers by adding TLS support.
Simply adding TLS support to the protocol does not guarantee the
protection of the server and clients. It is essential for the
operators and equipment vendors to adhere to the latest best
practices for ensuring the integrity of network devices and selecting
secure TLS key and encryption algorithms.
[RFC9325] offers substantial guidance for implementing protocols that
use TLS and their deployment. Those implementing and deploying
Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3
outlined in [RFC9325], or its subsequent versions.
This document outlines additional restrictions permissible under
[RFC9325]. For example, any recommendations referring to TLS 1.2,
including the mandatory support, are not relevant for Secure TACACS+
as TLS 1.3 or above is mandated.
5.1.1. TLS Use
Non-TLS connections should not be used for new TACACS+ deployments.
TACACS+ servers that have TLS support MUST NOT allow Non-TLS
connections, because of the threat of downgrade attacks, as described
in Section 5.2. Instead, separate Non-TLS TACACS+ servers can be set
up to cater for these clients.
Dahm, et al. Expires 25 October 2024 [Page 8]
Internet-Draft The Terminal Access Controller Access-Co April 2024
Further, TLS TACACS+ servers and Non-TLS TACACS+ servers SHOULD NOT
be deployed on the same host. Non-TLS connections would be better
served by deploying the required Non-TLS TACACS+ servers on separate
hosts.
It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication
and encryption, including TLS using the NULL algorithm, except for
within test and debug environments. Also see [RFC3365].
5.1.2. TLS 0-RTT
TLS 1.3 resumption and PSK techniques make it possible to send Early
Data, aka. 0-RTT data, data that is sent before the TLS handshake
completes. Replay of this data is a risk. Given the sensitivity of
TACACS+ data, clients MUST NOT send data until the full TLS handshake
completes; that is, clients MUST NOT send 0-RTT data and servers MAY
abruptly disconnect clients that do.
5.1.3. TLS Options
Recommendations in Section 4 of [RFC9325] or any RFCs which obsolete
it, MUST be followed, in order to determine which TLS versions and
algorithms should be supported, deprecated, obsoleted, or abandoned
Other useful examples are the TLS specifications themselves (TLS 1.3
[RFC8446]), which prescribes mandatory support in Section 9, and TLS
Recommendations [RFC7525].
5.1.4. Unreachable Certificate Authority (CA)
Operators SHOULD be cognizant of the potential of server and/or
client isolation from their peer's CA by network failures. Isolation
from a public key certificate's CA will cause the verification of the
certificate to fail and thus TLS authentication of the peer to fail.
Operators SHOULD consider loading certificate chains on devices and
servers to avoid this failure.
The approaches mentioned in Section 3.2.2.1 can help address this,
and should be considered where implemented. Both are out of scope
for this document. Certificate fingerprints are another option.
5.1.5. TLS Server Name Indicator (SNI)
Operators SHOULD be aware that the TLS SNI extension is part of the
TLS client hello, and is therefore subject to eavesdropping. Also
see Section 11.1 of [RFC6066].
Dahm, et al. Expires 25 October 2024 [Page 9]
Internet-Draft The Terminal Access Controller Access-Co April 2024
If TLS Encrypted Client Hello becomes standardized and applicable to
TLS 1.3, then it SHOULD be included in Secure TACACS+ implementation.
5.2. TACACS+ Configuration
Implementors MUST ensure that the configuration scheme introduced for
enabling TLS is straightforward and leaves no room for ambiguity
regarding whether TLS or Non-TLS will be used between the TACACS+
client and the TACACS+ server.
This document recommends the use of a separate port number that TLS
enabled TACACS+ servers will listen to. Where deployments have not
overridden the defaults explicitly, TACACS+ client implementations
MUST use the correct values:
* for Non-TLS connection TACACS+: Port 49.
* for TLS connection TACACS+: (TBD).
Implementors MAY offer a single option for TACACS+ clients and
servers to disable all Non-TLS TACACS+ operations. When enabled on a
TACACS+ server, it will not respond to any requests from Non-TLS
TACACS+ client connections. When enabled on a TACACS+ client, it
will not establish any Non-TLS TACACS+ server connections.
5.3. Well-Known TCP/IP Port
A new port is considered appropriate and superior to a "STARTTLS"
command or other negotiation method because it allows:
* ease of blocking the unobfuscated or obfuscated connections by the
TCP/IP port number,
* passive Intrusion Detection Systems (IDSs) monitoring the
unobfuscated to be unaffected by the introduction of TLS,
* avoidance of Man in the Middle (MitM) attacks that can interfere
with STARTTLS,
* and helps prevent the accidental exposure of sensitive information
due to misconfiguration.
However, co-existence of inferior authentication and obfuscated,
whether an Non-TLS connection or deprecated parts that compose TLS,
also presents opportunity for down-grade attacks. Causing failure of
connections to the TLS-enabled service or the negotiation of shared
algorithm support are two such down-grade attacks.
Dahm, et al. Expires 25 October 2024 [Page 10]
Internet-Draft The Terminal Access Controller Access-Co April 2024
The simplest way to address exposure from Non-TLS connection methods
is to refuse Non-TLS connections at the server entirely, perhaps
using separate servers for Non-TLS connections and TLS.
Another approach is mutual configuration that requires TLS. Clients
and servers SHOULD support configuration that requires peers,
globally and individually, use TLS. Furthermore, peers SHOULD be
configurable to limit offered or recognized TLS versions and
algorithms to those recommended by standards bodies and implementers.
6. Operator Considerations
Operational and deployment considerations are spread throughout the
document. While avoiding repetition, it is useful for the impatient
to direct particular attention to Sections 5.2 and 5.1.5. However,
it is important that the entire Section 5 is observed.
6.1. Migration
In Section 5.2, it is mentioned that for an optimal deployment of TLS
TACACS+, TLS should be universally applied throughout the deployment.
However, during the migration process from a Non-TLS TACACS+
deployment, operators may need to support both TLS and Non-TLS
TACACS+ servers. This migration phase allows operators to gradually
transition their deployments from an insecure state to a more secure
one, but it is important to note that it is vulnerable to downgrade
attacks. Therefore, the migration phase should be considered
insecure until it is fully completed. To mitigate this hazard:
* the period where any client is configured with both TLS and Non-
TLS servers should be minimized.
* the operator must consider the impact of mixed TLS and Non-TLS on
security.
6.2. Maintaining Non-TLS TACACS+ Clients
Some TACACS+ client devices in a deployment may not implement TLS.
These devices will require access to Non-TLS TACACS+ servers.
Operators MUST follow the recommendation of Section 5.1.1 and deploy
separate TACACS+ servers for these Non-TLS clients from those used
for the TLS clients.
Dahm, et al. Expires 25 October 2024 [Page 11]
Internet-Draft The Terminal Access Controller Access-Co April 2024
7. IANA Considerations
The authors request that, when this draft is accepted by the working
group, the OPSAWG Chairs submit a request to IANA for an early
allocation, per [RFC4020] and [RFC6335], of a new well-known system
TCP/IP port number for the service name "tacacss" (referenced in this
document also as "TACACS+ TLS well-known port ([TBD])"), described as
"TACACS+ over TLS". The service name "tacacss" follows the common
practice of appending an "s" to the name given to the Non-TLS well-
known port name. This allocation is justified in Section 5.3.
This document requests IANA to add a new entity from the "Service
name and Transport Protocol Port Number Registry" available at
https://www.iana.org/assignments/service-name-port-numbers/
Service Name: tacacss
Port Number: [TBD]
Transport Protocol: TCP
Description: Login Host Protocol (TACACSS)
Assignee: IESG
Contact: IETF Chair
Reference: [TBDN] (This Document)
RFC EDITOR: this port number should replace "[TBD]" and the service
name should replace "[TBDN]" within this document.
Considerations about service discovery are out of scope of this
document.
8. Acknowledgments
The author(s) would like to thank Russ Housley, Steven M. Bellovin,
Stephen Farrell, Alan DeKok, Warren Kumari, Tom Petch and Mohamed
Boucadair for their support, insightful review, and/or comments.
[RFC5425] was also used as a basis for the approach to TLS.
9. Normative References
[BCP14] Best Current Practice 14,
<https://www.rfc-editor.org/bcp/bcp14.txt>.
At the time of writing, this BCP comprises the following:
Dahm, et al. Expires 25 October 2024 [Page 12]
Internet-Draft The Terminal Access Controller Access-Co April 2024
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5425] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed.,
"Transport Layer Security (TLS) Transport Mapping for
Syslog", RFC 5425, DOI 10.17487/RFC5425, March 2009,
<https://www.rfc-editor.org/info/rfc5425>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015,
<https://www.rfc-editor.org/info/rfc7525>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.
Dahm, et al. Expires 25 October 2024 [Page 13]
Internet-Draft The Terminal Access Controller Access-Co April 2024
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/info/rfc8773>.
[RFC8907] Dahm, T., Ota, A., Medway Gash, D.C., Carrel, D., and L.
Grant, "The Terminal Access Controller Access-Control
System Plus (TACACS+) Protocol", RFC 8907,
DOI 10.17487/RFC8907, September 2020,
<https://www.rfc-editor.org/info/rfc8907>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
10. Informative References
[RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61,
RFC 3365, DOI 10.17487/RFC3365, August 2002,
<https://www.rfc-editor.org/info/rfc3365>.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", RFC 4020,
DOI 10.17487/RFC4020, February 2005,
<https://www.rfc-editor.org/info/rfc4020>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
August 2015, <https://www.rfc-editor.org/info/rfc7605>.
Dahm, et al. Expires 25 October 2024 [Page 14]
Internet-Draft The Terminal Access Controller Access-Co April 2024
[TLSCSREC] IANA, "Transport Layer Security (TLS) Parameters",
<https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml#tls-parameters-4>.
Authors' Addresses
Thorsten Dahm
Email: thorsten.dahm@gmail.com
John Heasley
NTT
Email: heas@shrubbery.net
Douglas C. Medway Gash
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: dcmgash@cisco.com
Andrej Ota
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: andrej@ota.si
Dahm, et al. Expires 25 October 2024 [Page 15]