Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt

[Alan DeKok <[e-mail]>]

On Dec 1, 2022, at 1:14 PM, Marc Huber <[e-mail]> wrote:
> I've the gut feeling that
> 
>    Peers MUST NOT use Obfuscation with TLS.
> ...
> isn't the best approach. This would break the transition process compatibility for devices that don't encrypt on their own which move TLS to an intermediate system (a reverse proxy, essentially).

  We're just going through this with RADIUS.  We defined RADIUS over TLS 10 years ago, and left the MD5 obfuscation in.

  We're now updating it to remove MD5.  In hindsight, it was a mistake.  Among other things, leaving MD5 in means that it's difficult to run implementations in a FIPS environment.

  Plus, what key do you use for the MD5 obfuscation?  Do you leave the old one in the admin interfaces?  And add TLS?

  I think that the current approach is best.  Drop the 20+ year-old obfuscation.  Just use modern crypto.

  I'd suggest requiring TLS-PSK.  It's likely easy to update implementations / interfaces to add a PSK.  In contrast, certificates are more complex.

  Plus, operational experience with RADIUS shows that certificate management is a big problem.  There are many issues with certificates:

* do the client / server use Web CAs for certificate valdation?  Are these web CAs shipped with the product?  How are they updated?

* If a private CA is used, then the implementations have to be updated to allow for configuration of CAs in addition to client certs

* certificate expiry is rare enough that people forget how to renew them, but often enough that they have to be renewed regularly

* web CAs won't issue certs for non-web use.  So to get a cert, you have to claim you're putting it on a web server, and add id-kp-serverAuth in order to pass web CA validation

* How are the certificates validated?  There is a long list of things which can be done to validate the certificate.  Some RFCs have guidance, but implementation experience shows that those aren't enough.


  I'd suggest checking the certificate validation rules in RFC 5216 and RFC 9190  (EAP-TLS), and RFC 6614 (RADIUS/TLS).  The operational issues are similar.  It may also be useful to look at RFC 7585 (dynamic server discovery via DNS).

  I'd suggest also looking at the TLS configuration in FreeRADIUS here:  https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-available/eap#L177

  It's for EAP-TLS, but the requirements for TACACS+ with TLS would be similar.  There are a large number of options for configuring certificates, validation methods, CAs, PSKs, etc.  Nearly all of these would be required when TACACS+ is used with TLS.

  Alan DeKok.