Subject: [OPSAWG] [[email-masked]: I-D Action: draft-dahm-tacacs-security-00.txt]

From: heasley <[email-masked]>
Date: Tue, 5 Apr 2022 17:44:55 +0000

OPSAWG participants,
An initial draft for, among other things, adding TLS transport for TACACS+
has been submitted.  It needs your scrutiny and your comments are requested.

TiA

Note that this would update RFC8907, not 8097 indicated in the header.

----- Forwarded message from [email-masked] -----

From: [email-masked]
To: [email-masked]
Subject: I-D Action: draft-dahm-tacacs-security-00.txt
Date: Thu, 31 Mar 2022 11:20:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : TACACS+ Security, TLS, and SSH Public Keys
        Authors         : Thorsten Dahm
                          Douglas Gash
                          Andrej Ota
                          John Heasley
	Filename        : draft-dahm-tacacs-security-00.txt
	Pages           : 22
	Date            : 2022-03-31

Abstract:
   The TACACS+ Protocol [RFC8907] provides device administration for
   routers, network access servers and other networked computing devices
   via one or more centralized servers.  This document, a companion to
   the TACACS+ protocol [RFC8907], adds new packet formats to improve
   security and function, Transport Layer Security (currently defined by
   TLS 1.3 [RFC8446]) support, and support for SSH [RFC4716] public keys
   and deprecates former inferior security mechanisms.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dahm-tacacs-security/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-dahm-tacacs-security-00.html

----- End forwarded message -----

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Apr 2022 17:15:21 -0400

This is a quick review based on first impressions.

  It may be good to have a note that the existing TACACS+ port can be used for TLS, if both ends are configured to require TLS.  That means systems can use existing firewall rules, etc. for TACACS+TLS.

  Section 3.2 says:

the resumption ticket_lifetime SHOULD be configurable, including a zero seconds lifetime.

  I'm not sure what a "zero-seconds lifetime" would mean.  It may be better to just omit the ticket in that case.

  It would be good to mention that TLS Server Name Indication (SNI) SHOULD be supported (https://datatracker.ietf.org/doc/html/rfc6066#section-3).  That way one server can act as the TACACS+ host for multiple domains, and switch between them using SNI.

  Section 4 concerns me.  This is not just adding TLS to TACACS+, it's adding an entirely new flow: TACACS+ proxying.  This is a major change to TACACS+, and I would strongly suggest moving it to another document.

  I would also recommend not defining a new packet type which extends the horrific TACACS+ packet format.  We've come a long way in protocol design since the mid 1990s.  The packet format is awkward, at best.  It is difficult to create and/or parse correctly.

  Plus, what if the proxy wishes to forward information about the client certificate, or server certificate which was used?  The current format makes this impossible.

  My recommendation would be to take a page from DHCPv6, and just add an encapsulation layer.  e.g. a TACACS+ header with minor version 2, and a new type signifying "proxied packet".   That packet could simply be a container for encapsulating the original packet.

  i.e. instead of re-encoding the entire packet (with all of the issues and errors that entails), just take the original packet, add a proxy header, and send that essentially verbatim.  This is much simpler, and has much less room for errors.

  i.e. a proxied packet could look like:

	TACACS+ header (minor = 2, type = proxied)
	proxy header {
		length of proxy header
		flag for is next header a proxied packet.
		original src / dst ip / port
		... potentially other data ..	      
	}
	length of original packet
	verbatim copy of original packet

  That format is simpler to encode/decode, simpler to understand, and is easily extensible to add new fields.  It also allows for multiple layers of proxying, which the current draft doesn't.

  Alan DeKok.