Hi Russ, The last part of your clarification reflects the intent here. I agree this should be clearly formulated in the doc. I trust the authors will follow up with proposed changes SOON. Cheers, Med (as doc Shepherd) > -----Message d'origine----- > De : Russ Housley <housley@xxxxxxxxxxxx> > Envoyé : dimanche 9 mars 2025 19:06 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx> > Cc : IETF SecDir <secdir@xxxxxxxx>; draft-ietf-opsawg-tacacs- > tls13.all@xxxxxxxx; last-call@xxxxxxxx; opsawg@xxxxxxxx > Objet : Re: [Last-Call] Secdir last call review of draft-ietf-opsawg- > tacacs-tls13-18 > > > Med: > > The document has a MUST statement about mutual certificate-based > authentication, and then it talks about two approaches that do not use > certificates. That is my complaint. The proposed chages do not > address the core concerns. > > I do not have clarity about what the authors intend. Perhaps they > mean that there are three options for authentication. One of them > MUST be used. For interoperability, all implementations MUST > implement mutual certificate-based authentication. If that is the > intent, I can support it, but that is not what I see in the document. > > Russ > > > On Mar 9, 2025, at 5:44 AM, mohamed.boucadair@xxxxxxxxxx wrote: > > > > Hi Russ, > > > > Please see inline. > > > > Cheers, > > Med (as doc Shepherd) > > > >> -----Message d'origine----- > >> De : Russ Housley via Datatracker <noreply@xxxxxxxx> Envoyé : > >> dimanche 9 mars 2025 02:17 À : secdir@xxxxxxxx Cc : > >> draft-ietf-opsawg-tacacs-tls13.all@xxxxxxxx; last-call@xxxxxxxx; > >> opsawg@xxxxxxxx Objet : Secdir last call review of > >> draft-ietf-opsawg-tacacs-tls13-18 > >> > >> > >> Reviewer: Russ Housley > >> Review result: Not Ready > >> > >> I reviewed this document as part of the Security Directorate's > >> ongoing effort to review all IETF documents being processed by the > IESG. > >> These comments were written primarily for the benefit of the > Security > >> Area Directors. Document authors, document editors, and WG chairs > >> should treat these comments just like any other IETF Last Call > >> comments. > >> > >> Document: draft-ietf-opsawg-tacacs-tls13-18 > >> Reviewer: Russ Housley > >> Review Date: 2025-03-08 > >> IETF LC End Date: 2025-03-27 > >> IESG Telechat date: Unknown > >> > >> Summary: Not Ready > >> > >> > >> Major Concerns: > >> > >> Section 3.3: The text requires support for "mutual authentication". > I > >> assume that this means that it MUST be supported, but it does not > >> have to be used. > > > > [Med] ACK per the clarification provided by the authors to your > > previous review: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > > > archive.ietf.org%2Farch%2Fmsg%2Fsecdir%2FHpnUABp1q4YbRWq5Q16VD3XRo64%2 > > > F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C226a56f5921d45de3eb1 > > > 08dd5f3521c9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638771404001 > > > 257248%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > > > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda > > ta=ImdWz0O3UjdzuZaXJo%2F3xjzZ4YiqYGfWGSNfwiDa9%2Fg%3D&reserved=0 > > > > However, the next section say: "Each peer MUST validate > >> the certificate path of the remote peer, ...". This seems to be in > >> conflict. It requires the use of both server certificates and > client > >> certificates. > >> > > > > [Med] There are specific sections for each authentication option > (3.4/3.5). I suggest: > > > > (1) > > > > OLD: > > Implementations MUST support Certificate based mutual > authentication. > > > > NEW: > > Implementations MUST support Certificate-based mutual > authentication. > > Refer to Section 3.4 for additional guidance. > > > > (2) > > > > OLD: > > 3.4. TLS Certificate Authentication > > > > NEW: > > 3.4. TLS Certificate Authentication > > > > This section is applicable when certificate-based authentication is > used. > > > > > >> Section 3.3: The text says: "... full certificate-based TLS > >> authentication ...". I do not know what that means. Please > clarify. > >> > >> Section 3.3: With the removal of the reference to [RFC8773], how is > >> the requirement for certificates accomplished while also using > >> external PSKs? I am unaware of any other way to do so. Further, > >> Section 3.5 describes PSK authentication as an alternative to > >> certificate-based authentication. These sections are in conflict. > >> > >> Section 3.3: The text allows the use of [RFC7250] must be used in > the > >> context of [RFC8446]. How is the requirement for certificates > >> accomplished with raw public keys? I am unaware of any way to do > so. > > > > [Med] For the two last points, I wonder whether you checked the > context I provided you at > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > archive.ietf.org%2Farch%2Fmsg%2Fsecdir%2F01c9y_BUuuxEcj4I6vW9tgowjtw%2 > F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C226a56f5921d45de3eb1 > 08dd5f3521c9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638771404001 > 273689%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda > ta=QmSKMjjqk1m%2F%2BPB7DO5xDT%2FcjnrDgOCrlyZBQ5m4oNA%3D&reserved=0? > > > > == Here is the extract of specific comments from Valery: > > 7. Section 3.2.2: referencing RFC 7250 is a bit problematic, since > it defines using RPKs for TLS 1.2 only (and thus contains TLS 1.2 > specific information). RPKs is also supported in TLS 1.3, but > referencing this support is not an easy task - there is no dedicated > section in RFC 8446... I don't have any good proposals here, perhaps > just add reference to 8446 in addition to 7250. > > 8. Section 3.2.2: referencing RFC 8773 for PSK is incorrect. Using > sole PSK is defined in RFC 8446, while RFC 8773 defines using > PSK+Certificate. > > == > > > >> > >> > >> Minor Concerns: None > >> > >> > >> Nits: > >> > >> Section 3.3: s/Certificate based mutual/certificate-based mutual/ > >> > >> > > > > > ______________________________________________________________________ > > ______________________________________ > > 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. > > -- > > last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an > > email to last-call-leave@xxxxxxxx ____________________________________________________________________________________________________________ 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
