Hi Authors, all, Many thanks for your effort on this document.
I managed finally to read the new version. I'm afraid that some of the comments in https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-tacacs-tls13-03-rev%20Med.pdf were not addressed or at least I fail to see how they are. For example, I still don't think that we can separate the discussion of the port number from how the IP address of the server is configured. I still also think that cipher suite discuss can be offloaded to RFC9325 (which btw should be cited as normative; also, please note that RFC7525 is now obsoleted by RFC9325). Cheers, Med De : OPSAWG <opsawg-boun...@ietf.org> De la part de Douglas Gash (dcmgash) Envoyé : vendredi 22 décembre 2023 17:54 À : opsawg@ietf.org Cc : John Heasly <h...@shrubbery.net>; Andrej Ota <and...@ota.si> Objet : [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4) Dear OPSAWG, Many thank for all the comments on the Secure TACACS+ (TLS) draft v3. We have submitted a revised doc which intention to address the concerns and comments. It is rather later than originally planned, our apologies for the delay. We will look forward to addressing the corresponding issues form this revision in a timelier manner. Some brief notes regarding the broader topics raised in v3, all items of course, are open for re-aligning as the group sees fit. * Regarding the allocation of a specific port, a key motivation concerns the pervasive use of default ports in current configurations. Ensuring the client implementations work correctly with default ports now TLS is introduced, to minimise burden for operators whilst avoiding wrinkles with downgrade attacks does require said new default port to be allocated, and we will explicitly mention this in a new section in the new doc. We hope this should help account for our request for an allocated port. * RFC9325 does look a timely reference, and we have tried to delegate what we can from the new TACACS+ doc to it. * Tracking the discussion on the deprecation of obfuscation option inside TLS, our current reading is that: * All TLS traffic must NOT use obfuscation. * Setting the non-obfuscation option (TACACS has a flag for unencrypted) is mandatory for all TLS TACACS+ traffic. * The aim is to avoid any ambiguity and to remove MD5 operations from this level of the protocol. * We hope we have addressed the raised issues nits and ambiguities. Best regards, the Authors. ____________________________________________________________________________________________________________ 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
