Hi Douglas, Many thanks for the consideration of my observations. Please see inline: GV2>
From: Douglas Gash (dcmgash) <dcmg...@cisco.com> Sent: Friday, July 4, 2025 11:36 AM To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; The IESG <i...@ietf.org> Cc: draft-ietf-opsawg-tacacs-tl...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com; Joe Clarke (jclarke) <jcla...@cisco.com> Subject: Re: Gunter Van de Velde's No Objection on draft-ietf-opsawg-tacacs-tls13-23: (with COMMENT) You don't often get email from mailto:dcmg...@cisco.com. https://aka.ms/LearnAboutSenderIdentification CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hello Gunter, Many, many thanks for taking the time to digest the doc and to provide some very significant improvements to the doc. Please see inline… From: Gunter Van de Velde via Datatracker <mailto:nore...@ietf.org> Date: Tuesday, 24 June 2025 at 15:17 To: The IESG <mailto:i...@ietf.org> Cc: mailto:draft-ietf-opsawg-tacacs-tl...@ietf.org <mailto:draft-ietf-opsawg-tacacs-tl...@ietf.org>, mailto:opsawg-cha...@ietf.org <mailto:opsawg-cha...@ietf.org>, mailto:opsawg@ietf.org <mailto:opsawg@ietf.org>, mailto:mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>, Joe Clarke (jclarke) <mailto:jcla...@cisco.com>, Joe Clarke (jclarke) <mailto:jcla...@cisco.com> Subject: Gunter Van de Velde's No Objection on draft-ietf-opsawg-tacacs-tls13-23: (with COMMENT) Gunter Van de Velde has entered the following ballot position for draft-ietf-opsawg-tacacs-tls13-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-opsawg-tacacs-tls13-23 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-23.txt # This is a great write-up and needed extension to TACACS+ # I noted some non-blocking observations in the text that follows. Mostly idnits and clarifications. # A support the DISCUSS from Ketan # Detailed Review # =============== 16 Abstract 17 18 The Terminal Access Controller Access-Control System Plus (TACACS+) 19 protocol provides device administration for routers, network access 20 servers, and other networked computing devices via one or more 21 centralized TACACS+ servers. This document adds Transport Layer 22 Security (TLS 1.3) support to TACACS+ and obsoletes former inferior 23 security mechanisms. 24 25 This document updates RFC 8907. GV> What about the following textblob alternative: " This document specifies the use of Transport Layer Security (TLS) version 1.3 to secure the communication channel between a TACACS+ client and server. TACACS+ is a protocol used for Authentication, Authorization, and Accounting (AAA) in networked environments. The original TACACS+ protocol, defined in RFC 8907, does not mandate the use of encryption or secure transport. This specification defines a profile for using TLS 1.3 with TACACS+, including guidance on authentication, connection establishment, and operational considerations. The goal is to enhance the confidentiality, integrity, and authenticity of TACACS+ traffic, aligning the protocol with modern security best practices. This document updates RFC 8907. Agreed, we will use this, however, one caveat, I understand that we should not make references in the abstract, so I think we need to just remove the clause “defined in RFC 8907”: The original TACACS+ protocol, defined in RFC 8907, does not mandate To The original TACACS+ protocol does not mandate Please LMK if I have misapprehended a previous comment 😉 GV2> ack " 183 3.1. Separating TLS Connections 184 185 All data exchanged by TACACS+ peers MUST be encrypted, including the 186 mutual authentication of the peers. Therefore, when a TCP connection 187 is established for the service, a TLS handshake begins immediately. GV> This reads like a storm of energy of change and leaves no room for introduction. The text states "peers MUST be encrypted". While true when supporting this RFC-to-be, it was not the situation before this RFC-to-be. Maybe mention in the text that it MUST be supported when this RFC-to-be is supported. Agreed, will attempt to attenuate the storm energy (a little) by way of the context prefix, as suggested. New text: Peers implementing the TACACS+ protocol variant defined in this document MUST apply mutual authentication and encrypt all data exchanged between them. GV2> Thanks 189 To ensure separation of TACACS+ traffic that uses TLS from that which 190 does not (Section 5.3), TLS TACACS+ servers MUST be deployed on a 191 separate TCP/IP port number from Non-TLS TACACS+ servers (preferably 192 on a separate host, as recommended in Section 5.1.1). Because of the 193 widespread use of default port number settings in numerous existing 194 TACACS+ client configurations, a well-known system TCP/IP port number 195 is assigned: the designated port number is [TBD] (Section 7) with the 196 service name tacacss (Section 7). This ensures that the client can 197 separate TLS and Non-TLS traffic even where default port numbers are 198 omitted from its TACACS+ server connection configuration. 199 200 Under exceptional circumstances, this document permits any other TCP 201 port number to be configured when required by deployment specifics, 202 but the implications in Section 5.3 have to be considered by GV> What about the following alternative textblob: " To ensure clear separation between TACACS+ traffic using TLS and that which does not (see Section 5.3), servers supporting TACACS+ over TLS MUST listen on a TCP/IP port distinct from that used by non-TLS TACACS+ servers. Where feasible, it is further RECOMMENDED to deploy the TLS and non-TLS services on separate hosts, as discussed in Section 5.1.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], with the associated service name "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 is strongly encouraged, deployments with specific requirements MAY use alternative TCP port numbers. In such cases, operators must carefully consider the operational implications described in Section 5.3. " Agreed, have updated to this text. GV2> Thanks 213 TLS 1.3 [RFC8446] must be used for transport, though it is expected 214 that TACACS+ as described in this document will work with future 215 versions of TLS. Earlier versions of TLS MUST NOT be used. GV> Would it be beneficial to state that "minimum TLS 1.3 MUST be used for transport ..."? Agreed, added, GV2> Thanks 217 Once the TLS connection is established, the exchange of TACACS+ data 218 proceeds as defined in [RFC8907], except that it is transmitted over 219 TLS as TLS application data and without TACACS+ obfuscation 220 (Section 4). GV> What about: " Once the TLS connection has been successfully established, the exchange of TACACS+ data SHALL proceed in accordance with the procedures defined in [RFC8907]. However, all TACACS+ messages SHALL be transmitted as TLS application data. The TACACS+ obfuscation mechanism defined in [RFC8907] MUST NOT be applied when operating over TLS (see Section 4) " Agreed, added this text, though we changed the “SHALL” to “MUST” GV2> Makes sense. Thanks 225 negotiated, when an inactivity timeout occurs. Why it closed has no 226 bearing on TLS resumption, unless closed by a TLS error, in which 227 case the ticket might be invalidated. GV> What is meant with "ticket"? 229 TACACS+ connections are not long-lived. Non 'Single Connection Mode' 230 (Section 4.3 of [RFC8907]) connections are closed as soon as the 231 TACACS+ session completes. Single Connection Mode connections are 232 longer lived, but even these are timed out and closed after a short 233 period of inactivity. For this reason, keepalives are not required 234 to be supported. GV> What about: " TACACS+ connections are generally not long-lived. For connections not operating in Single Connection Mode (as defined in Section 4.3 of [RFC8907]), the TCP session SHALL be closed upon completion of the associated TACACS+ session. Connections operating in Single Connection Mode MAY persist for a longer duration but are typically subject to timeout and closure after a brief period of inactivity. Consequently, support for transport-layer keepalive mechanisms is NOT REQUIRED. " Agreed, updated. GV2> Thanks 421 The introduction of TLS PSK, certificate peer authentication, and TLS 422 encryption to TACACS+ replaces these former mechanisms and so 423 obfuscation is hereby obsoleted. GV> Is TLS PSK in this document not documented after the TLS Encryption? Maybe follow order in the above phrase to be conmsistent with the documentation in this RFC-to-be for readability? Agreed, simplified to: The introduction of TLS authentication and encryption to TACACS+ replaces this former mechanism and so obfuscation is hereby obsoleted. This section describes how the TACACS+ client and servers MUST operate regarding the obfuscation mechanism. GV2> Thanks 502 completes. Replay of this data is a risk. Given the sensitivity of 503 TACACS+ data, clients MUST NOT send data until the full TLS handshake 504 completes; that is, clients MUST NOT send 0-RTT data and TLS TACACS+ 505 servers MUST abruptly disconnect clients that do. GV> Beyond the abruptly disconnect, is an operational logging recommended? I haven’t yet picked up this change, because there felt like dissonance between this section defining protocol behaviour and deployment management considerations such as notifications to admins. As an implementor, there are a bunch of notifications I’d add, so to have just this one singled out in the RFC I thought may cause confusion? GV2> That is fine Douglas. Be well, G/ _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
