Hi, just wanted to close on this section. The original was:
5.1.1. TLS Use Non-TLS connections should not be used for new TACACS+ deployments. TLS TACACS+ servers MUST NOT allow Non-TLS connections, because of the threat of downgrade attacks, as described in Section 5.2, or misconfiguration. Instead, separate Non-TLS TACACS+ servers SHOULD be set up to cater for these clients. Further, TLS TACACS+ servers and Non-TLS TACACS+ servers SHOULD NOT be deployed on the same host. Non-TLS connections would be better served by deploying the required Non-TLS TACACS+ servers on separate hosts. It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication and encryption, unless within test and debug environments. Also see [RFC3365]. The Proposed new version, attempting to take the comments into account is: 5.1.1. TLS Use New TACACS+ production deployments SHOULD use TLS authentication and encryption. Also see [RFC3365]. TLS TACACS+ servers (see definition in Section 2.4) MUST NOT allow Non-TLS connections, because of the threat of downgrade attacks or misconfiguration described in Section 5.3. Instead, separate Non-TLS TACACS+ servers MUST be set up to cater for these clients. It is NOT RECOMMENDED that TLS TACACS+ servers and Non-TLS TACACS+ servers be deployed on the same host, for reasons discussed in Section 5.3. Non-TLS connections would be better served by deploying the required Non-TLS TACACS+ servers on separate hosts. Hopefully this clarifies the hierarchy of TLS configuration from the connection, through the server and the host. Any concerns, please let us know. Thanks! From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Date: Wednesday, 30 October 2024 at 07:02 To: Alan DeKok <al...@deployingradius.com>, Douglas Gash (dcmgash) <dcmg...@cisco.com> Cc: 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. Hi Alan, Doug, all One comment about this part: > 5.1.1 > > ... Non-TLS connections should not be used for new TACACS+ > deployments. > > Perhaps make this normative: SHOULD NOT be used [Med] Wouldn't that be then redundant with this generic statement at the end of that section? It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication and encryption, unless within test and debug environments. Unless there are subtleties, a straightforward fix here would be to delete the sentence you quoted. Cheers, Med (doc Shepherd) > -----Message d'origine----- > De : Alan DeKok <al...@deployingradius.com> > Envoyé : mardi 29 octobre 2024 22:35 > À : Douglas Gash (dcmgash) <dcmg...@cisco.com> > Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > Joe Clarke (jclarke) <jcla...@cisco.com>; opsawg@ietf.org; > Thorsten Dahm <thorsten.d...@gmail.com>; John Heasly > <h...@shrubbery.net>; Andrej Ota <and...@ota.si> > Objet : 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." > > 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. > > 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. > > 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 > > ... 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. > > 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. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
