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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
