Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt
> From: Alan DeKok > On Dec 1, 2022, at 1:14 PM, Marc Huber 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
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt
Thu, Dec 01, 2022 at 06:00:53PM +, Joe Clarke (jclarke): > I’ve read the -01 revision, and the new text in Section 4 seems logical to > me. Being a bit pedantic, it might be good to reference that section when > deciding on the correct ERROR to send. No problem; that will be in the next version. Thanks ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt
On Dec 1, 2022, at 1:14 PM, Marc Huber 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt
Hi, I've the gut feeling that Peers MUST NOT use Obfuscation with TLS. A TACACS+ client initiating a TACACS+ TLS connection MUST set the TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that Obfuscation is not used for the Session. All subsequent packets MUST have the TAC_PLUS_UNENCRYPTED_FLAG set. A TACACS+ server that receives a packet with the TAC_PLUS_UNENCRYPTED_FLAG not set (cleared) over a TLS connection, MUST return an error of TAC_PLUS_AUTHEN_STATUS_ERROR, TAC_PLUS_AUTHOR_STATUS_ERROR, or TAC_PLUS_ACCT_STATUS_ERROR as appropriate for the TACACS+ message type, with the TAC_PLUS_UNENCRYPTED_FLAG set, and terminate the Session. 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). This might be a corner case, but I'd prefer a standard for TACACS+-over-TLS that just leaves the TACACS+ protocol as-is and simply encrypts/decrypts. TACACS+ over TLS shouldn't behave differently to plain TACACS+. Thanks, Marc ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt
I’ve read the -01 revision, and the new text in Section 4 seems logical to me. Being a bit pedantic, it might be good to reference that section when deciding on the correct ERROR to send. Joe From: OPSAWG on behalf of heasley Date: Thursday, December 1, 2022 at 00:32 To: opsawg@ietf.org Cc: and...@ota.si , Douglas Gash (dcmgash) , h...@shrubbery.net , thorsten.d...@gmail.com Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt Wed, Nov 30, 2022 at 09:04:04PM -0800, internet-dra...@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working Group > WG of the IETF. > > Title : TACACS+ TLS 1.3 > Authors : Thorsten Dahm > Douglas Gash > Andrej Ota > John Heasley > Filename: draft-ietf-opsawg-tacacs-tls13-01.txt > Pages : 11 > Date: 2022-11-30 > > 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 Transport Layer Security >(currently defined by TLS 1.3 [RFC8446]) support and obsoletes former >inferior security mechanisms. > This addresses two of the comments made by Joe Clarke. Among which, Joe asked that mishandling of the TAC_PLUS_UNENCRYPTED_FLAG in a TLS connection be treated as FAIL, which means that the authen or author failed and the client would stop and not proceed to other servers or methods. Upon reviewing to make this change, we concluded that this was not quite the correct behavior, based on the current behavior of similar errors in RFC8907 (S4.5 specifically), it should proceed to other servers or methods. So, the draft, in S4, now specifies returning ERROR rather than FAIL or ignoring the deprecated flag. Hopefully, this change agrees with everyone. We still have some operators/security considerations to address and the issues raised by Alan. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt
Wed, Nov 30, 2022 at 09:04:04PM -0800, internet-dra...@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working Group > WG of the IETF. > > Title : TACACS+ TLS 1.3 > Authors : Thorsten Dahm > Douglas Gash > Andrej Ota > John Heasley > Filename: draft-ietf-opsawg-tacacs-tls13-01.txt > Pages : 11 > Date: 2022-11-30 > > 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 Transport Layer Security >(currently defined by TLS 1.3 [RFC8446]) support and obsoletes former >inferior security mechanisms. > This addresses two of the comments made by Joe Clarke. Among which, Joe asked that mishandling of the TAC_PLUS_UNENCRYPTED_FLAG in a TLS connection be treated as FAIL, which means that the authen or author failed and the client would stop and not proceed to other servers or methods. Upon reviewing to make this change, we concluded that this was not quite the correct behavior, based on the current behavior of similar errors in RFC8907 (S4.5 specifically), it should proceed to other servers or methods. So, the draft, in S4, now specifies returning ERROR rather than FAIL or ignoring the deprecated flag. Hopefully, this change agrees with everyone. We still have some operators/security considerations to address and the issues raised by Alan. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : TACACS+ TLS 1.3 Authors : Thorsten Dahm Douglas Gash Andrej Ota John Heasley Filename: draft-ietf-opsawg-tacacs-tls13-01.txt Pages : 11 Date: 2022-11-30 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 Transport Layer Security (currently defined by TLS 1.3 [RFC8446]) support and obsoletes former inferior security mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-tls13-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
