Hi all, FWIW, we had an offline discussion with Alan and the authors to clarify the concerns.
I'm reporting the main outcome of that discussion, fwiw: (1) Alan agreed that: * It is good practice to leverage existing standards * Repeating details isn't useful (2) Still, the key comment from Alan is: > My point was that the RFCs I referenced had substantial text over > and above 8446 / 9525. I asked that the authors double- check the > documents I mentioned, to see how these issues were addressed. The > result was a few minor changes. The shepherd agrees that this is a reasonable comment that should be adequately addressed. The authors engaged to have a look into the various RFCs cited by Alan and grab applicable items to tacacs+ context. It would be helpful to share the rationale for the items that they picked vs. those they considered as not relevant. (3) As a bonus, Alan provided the following comments and summary == Some grammar / clarity comments: Section 3.1: ... To ensure separation of TACACS+ traffic that uses TLS from that which does not (Section 5.3), they will be deployed on different ports. Due to the widespread use of default port number settings in numerous existing TACACS+ client configurations, a well-known system TCP/IP port number will be requested from IANA ... The text is ambiguous: "will" be requested? When? Does this document allocate the port? The usual text is to say "port TBD has been assigned for this protocol". In short: I'm not objecting to the publication of this document. My concern is that it doesn't give a lot of guidance to implementing TACACS+ over TLS. I can see basic implementations working, just by wrapping TACACS+ in TLS. But the operational considerations outlined above will have to be discovered piece-meal by implementors. == Cheers, Med > -----Message d'origine----- > De : Alan DeKok <al...@deployingradius.com> > Envoyé : lundi 24 juin 2024 15:17 > À : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org> > Cc : ops...@ietf.org; uta@ietf.org > Objet : [OPSAWG]Re: WG LC: draft-ietf-opsawg-tacacs-tls13 > > > On Jun 24, 2024, at 8:38 AM, Joe Clarke (jclarke) > <jclarke=40cisco....@dmarc.ietf.org> wrote: > > > > Grrr, forgot the link for convenience. Please provide WG LC > reviews for the following draft: > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-tacacs- > tls13%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3588a630 > 7a0d4559d37a08dc94501403%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C638548318850718922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sd > ata=nDNztJbIjA5qljJNMmux6WCbEmrdMsEJQzXNdIzRasE%3D&reserved=0 > > I have general concerns about the document, which I've raised > before. The document is extremely small, and offers little > guidance around most implementation and operational issues > related to OpenSSL. I've made these comments before, and there > appears to be few changes which address my concerns. > > For similar issues with there protocols, I would refer the > reader to RFC 9190 for discussions of EAP over TLS, and RFC 6614 > / RFC 7360 for discussions of RADIUS over TLS. Both of those > documentations contain significantly more content which can guide > the reader. > > In contrast, this document comes across as "send TACACS over > TLS". Almost every operational or implementation consideration > is left as an exercise for the reader. Experience shows that > this is a way to get non-interoperable implementations. > > The document is also Standards Track. Has anyone implemented > it? > > Given the lack of guidance in the draft, and the lack of > experience with implementations, I'd suggest that "Experimental" > is more appropriate. > > Alan DeKok. > > _______________________________________________ > OPSAWG mailing list -- ops...@ietf.org > To unsubscribe send an email to opsawg-le...@ietf.org ____________________________________________________________________________________________________________ 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. _______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
