Hi Alan, Please see one comment inline.
Cheers, Med > -----Message d'origine----- > De : OPSAWG <opsawg-boun...@ietf.org> De la part de Alan DeKok > Envoyé : mardi 23 avril 2024 17:20 > À : opsawg <opsawg@ietf.org> > Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13- > 07.txt > > > Some comments on the latest draft: > > 2.1. Obfuscation > > ... The algorithm is categorized as Obfuscation in Section > 10.5.2 of [RFC8907]. The term should be interpreted to mean > "plaintext" > > I wouldn't call it "plaintext", as it's not. Perhaps instead > just drop the "interpreted to mean plaintext" portion. > > 2.2 > > ... using unsecure TACACS+ authentication and obfuscation > > "insecure" instead of "unsecure". > > > 3.1 > > ... All data exchanged by TACACS+ peers MUST be encrypted, > > Perhaps explicitly say that TLS cipher suites with NULL > encryption are banned. This is a little more quantitative. > > ... 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. > > Perhaps just say "uses port TBD", and leave the IANA > instructions in a separate IANA section. > > i.e. the final RFC doesn't need to contain text on "port will > be requested from IANA" > > 3.2 > > ... Why it closed has no bearing on TLS resumption, unless > closed by a TLS error, in which case the ticket might be > invalidated. > > "might" seems wrong here. If there is a TLS error, the server > generally should discard any session tickets. While RFC 8446 > doesn't say this, I'm not clear if there are any use-cases for > resuming sessions which (for example) had previously failed with > fatal TLS errors. > > 3.2.2. > > Are there any considerations for which CA to use, or what kind > of CA to use? > > 4 > > [RFC8907] describes the obfuscation mechanism, documented in > Section 5.2 of [RFC5425]. > > The reference to 5425 seems wrong. > > 5.1.1.1 > > ... Non-TLS connections should not be used for new TACACS+ > deployments. > > Maybe SHOULD NOT? > > ... It is NOT RECOMMENDED to deploy TACACS+ wi > > I think this should be a MUST NOT > [Med] I don't think the normative language is justified here as it will be redundant with this part: It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication and encryption, including TLS using the NULL algorithm, except for within test and debug environments. NOT RECOMMENDED is right as there is a clear exception called out. ____________________________________________________________________________________________________________ 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
