Fair point. I was agreeing to the dedicated port for tacacss. That said, I do believe tacacss meets the secure requirement set forth in 7605 with respect to creating a new, secure service that replicates and insecure service in a non-backwards compatible way.
That part of Section 7.1 should be cited as a justification for the assignment. Joe From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Date: Wednesday, July 5, 2023 at 11:04 To: Joe Clarke (jclarke) <jcla...@cisco.com>, opsawg@ietf.org <opsawg@ietf.org> Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt Hi Joe, all, On the port number point, I’m afraid that the arguments in Section 8 are more for justifying why distinct port numbers might be useful, not why a well-known port number has to be assigned. I would suggest to strengthen that part before making the request (see more in rfc6335#section-7.2 and also rfc7605#section-7). Cheers, Med De : OPSAWG <opsawg-boun...@ietf.org> De la part de Joe Clarke (jclarke) Envoyé : mercredi 5 juillet 2023 16:42 À : opsawg@ietf.org Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt Thanks for the update on this document. I’ve reviewed this new version in its entirety. To summarize: · TACACS+ TLS will use a dedicated “tacacss” TCP port number · Obfuscation is prohibited by TACACS+ TLS compliant clients/servers (within the tunnel) These were two issues I believe were discussion points in the WG. As a contributor, I am convinced that both make sense for the reasons put forth in the draft. Hopefully during the migration process, implementors won’t forget the obfuscation on non-TLS sessions. I like the migration section, but I am curious why, after migration, one would need any legacy servers at all (regardless of server lists). I can see having my “DEVICE_ADMIN” T+ list having both TLS servers first followed by legacy servers while I sus out the stability of the new implementation. But when I’m satisfied, I likely would remove the legacy servers altogether. Moreover, at least with Cisco config, I assume I’d have each server defined with various TLS attributes and it wouldn’t matter what list they are in. I guess what I’m suggesting is dropping the second paragraph in Section 6.2 and saying something to the effect of, when migration from legacy, obfuscated T+ to T+ TLS, insecure and secure servers MAY be mixed in redundant service lists. However, secure servers SHOULD be tried first before falling back to insecure servers. As a nit, Indication is misspelled in Section 3.3. As co-chair: · WG, please review this draft! · Authors, any thoughts to what port number to use for tacacss or whatever IANA can assign? I’d like to see a few more reviews before pinging the ADs on early allocation. · Are there any implementations of this thus far? If so having an Appendix for them would help. Joe From: OPSAWG <opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>> on behalf of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Date: Thursday, June 29, 2023 at 10:55 To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> <i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>> Cc: opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title : TACACS+ TLS 1.3 Authors : Thorsten Dahm Douglas Gash Andrej Ota John Heasley Filename : draft-ietf-opsawg-tacacs-tls13-03.txt Pages : 12 Date : 2023-06-29 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 Internet-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-03.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg ____________________________________________________________________________________________________________ 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 https://www.ietf.org/mailman/listinfo/opsawg
