Dear OPSAWG et al, Version 15 includes updates related to Nits identified by Med, and the items Alan identified, that are covered below, EXCEPT the CA issues (in sections, 5, 5.14), which are still being explored, and these will be addressed in new version to be uploaded soon.
Thank you. From: Douglas Gash (dcmgash) <dcmg...@cisco.com> Date: Sunday, 10 November 2024 at 12:41 To: Alan DeKok <al...@deployingradius.com> Cc: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, Joe Clarke (jclarke) <jcla...@cisco.com>, opsawg@ietf.org <opsawg@ietf.org>, Thorsten Dahm <thorsten.d...@gmail.com>, John Heasly <h...@shrubbery.net>, Andrej Ota <and...@ota.si> Subject: Re: TACACS+ TLS Resumption and PSK. Dear Alan, Thank you for your time to review, and your comments. I think John H. is responding to your comments on section for section 5 and 5.1.4 (in attached email). Please find responses for the balance (comments on 2.1, 3, 5.1.1) We have started with rev15, and will look to incorporate the responses to these issues ASAP. Thanks! From: Alan DeKok <al...@deployingradius.com> Date: Tuesday, 29 October 2024 at 21:35 To: Douglas Gash (dcmgash) <dcmg...@cisco.com> Cc: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, Joe Clarke (jclarke) <jcla...@cisco.com>, opsawg@ietf.org <opsawg@ietf.org>, Thorsten Dahm <thorsten.d...@gmail.com>, John Heasly <h...@shrubbery.net>, Andrej Ota <and...@ota.si> Subject: Re: TACACS+ TLS Resumption and PSK. On Oct 28, 2024, at 7:51 AM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > Rev 11 of the T+ TLS doc had new sections for PSK and resumption, with a > slight restructure to accommodate PKI and PSK in regular hierarchy in the > contents. > > We are currently preparing another rev of the doc, so would be very grateful > for any feedback to ensure the previous paucity of coverage of these subjects > was sufficiently remedied. If not, now would be ideal time for us to address > any remaining concerns in this (or any other) area. From the -14 version: 2.1 nits: ... The algorithm is categorized as Obfuscation in Section 10.5.2 of [RFC8907]. The term should be interpreted to mean "plaintext", it is used to ensure that the algorithm is not mistaken for encryption. The obfuscation method is not "plaintext". Perhaps "while there are no known attacks on this method, it is not known to be secure." <Doug>The algorithm on top of MD5 may not have any published vulnerabilities, but the MD5 itself is not a secure foundation. But Plaintext does have an accepted meaning that is abused here, we will rectify that</Doug> Similarly in Section 3: ... Confidentiality and Integrity: The MD5 obfuscation specified in [RFC8907] has been shown to be insecure [RFC6151]. MD5 has been cracked. But there are no known attacks on the obfuscation method used. <Doug>We’ll clarify</Doug> 3 item (2): ... • Peer authentication: The authentication capabilities of TLS replace the pre-shared keys of obfuscation for mutual authentication. Perhaps use "shared secret' for consistency with RFC 8907. "Pre-shared keys" sounds like PSKs used for TLS. <Doug>agreed</Doug> 5 Perhaps add a note that TACACS+ TLS servers and clients SHOUD NOT use well-known CAs. i.e. CAs from the web PKI. Doing so would allow clients to connect to any server, and would allow anyone to issue client certs. 5.1.1 ... Non-TLS connections should not be used for new TACACS+ deployments. Perhaps make this normative: SHOULD NOT be used <Doug>The thread was also covered by Med, his approach looks to be a good way to resolve the issue you raised.</Doig> ... Further, TLS TACACS+ servers and Non-TLS TACACS+ servers SHOULD NOT be deployed on the same host. Why? There's no justification here. I'm not sure why this would be an issue. <Doug>Section 5.3 proved the reasoning. But after some internal discussion, we have re-considered and would propose to change from SHOULD NOT to NOT RECOMMENDED (and to make sure section 5.3 is referenced). We hope this should correctly address the issue. FYI: Here is the part of 5.3: However, co-existence of inferior authentication and obfuscated, whether an Non-TLS connection or deprecated parts that compose TLS, also presents opportunity for down-grade attacks. Causing failure of connections to the TLS-enabled service or the negotiation of shared algorithm support are two such down-grade attacks. The simplest way to address exposure from Non-TLS connection methods is to refuse Non-TLS connections at the host entirely, perhaps using separate hosts for Non-TLS connections and TLS. </Doug> 5.1.4 ... Operators should be cognizant of the potential of TLS TACACS+ server and/or client isolation from their peer's CA by network failures. Isolation from a public key certificate's CA will cause the verification of the certificate to fail and thus TLS authentication of the peer to fail. I'm not sure why it's an issue if the CA is unreachable. The TACACS+ TLS server has to be configured with the CA cert, and all intermediate certs. The client should ideally also be configured with the CA cert. There's no need to contact the CA, the CA cert is just a file on disk. Why does the CA have to be online? Overall the changes look reasonable, thanks. Alan DeKok.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
