> From: Alan DeKok <al...@deployingradius.com> > On Dec 1, 2022, at 1:14 PM, Marc Huber <marc.hu...@web.de> wrote: > 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.
Speaking only for myself, I agree with Alan. But, I am curious what devices, that will adopt new TACACS specs, do not support TLS? > I'd suggest requiring TLS-PSK. It's likely easy to update implementations > / interfaces to add a PSK. In contrast, certificates are more complex. We did consider TLS-PSK in-depth. As I recall, without looking back at the notes, we thought that this support might be best addressed in a separate draft because we considered certificates to be the most secure solution and it was not clear (to me) that (non-resumption) PSK was fully baked in TLS1.3, eg: draft-ietf-tls-external-psk-guidance. > 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. > These are challanges for many. But, support for certificate authentication must improve as it becomes demanded for gnxi, netconf, telemetry, hiba, sztp, and so on. How certificates are rotated, how to load chains for a private CA or to avoid issues if isolated, etc did not seem (to me) particular to network devices and therefore did not need to be addressed in the draft. We have tried to be minimalists about what belongs. I was not aware that some CAs would only issue certificates for web. Thanks, I will look at those references (again). We did take clues from reading about TLS support for other protocols, including syslog and radius. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
