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://mailarchive.ietf.org/arch/msg/secdir/HpnUABp1q4YbRWq5Q16VD3XRo64/ 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://mailarchive.ietf.org/arch/msg/secdir/01c9y_BUuuxEcj4I6vW9tgowjtw/? == 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
