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-07
Reviewer: Russ Housley
Review Date: 2024-04-25
IETF LC End Date: Unknown
IESG Telechat date: Unknown

Summary: Has Issues


Major Concerns:

Section 3.2.2 says:

   Implementations MUST support certificate-based TLS authentication and
   certificate revocation bi-directionally for authentication, identity
   verification and policy purposes.  Certificate path verification as
   described in Section 3.2.2.1 MUST be supported.

I do not understand this paragraph.  I suggest that you handle four
topics in separate sentences:

   (1) certificate for the server (for server authentication),
   (2) revocation checking of the server certificate by the client,
   (3) certificate for the client (for client authentication),
   (4) revocation checking of the client certificate by the server.
   
Section 3.2.2 says: "Pre-Shared Keys (PSKs) [RFC4279] ...".  RFC 4279 is
not appropriate for use with TLS 1.3, so it should not be cited here.

Section 5.1.2 says: "... servers MAY abruptly disconnect clients that
do."  I think this ought to make a stronger recommendation about 0-RTT.
Other profiles for the use of TLS with specific protocols (like
draft-ietf-netconf-over-tls13) completely forbid 0-RTT.

Section 5.1.4 talks about loading certificate chains.  It might also
talk about loading the information needed to perform revocation checks
or the use of OCSP stapling.

Section 5.1.4 says: "Certificate fingerprints are another option."
More explanation or a reference is needed here,


Minor Concerns:

The draft uses RFC 2119 terms, but it lacks a reference to RFC 2119
and the usual RFC 2119 boilerplate.


Nits:

Section 3: Please add a reference for FIPS 140.

Section 3.2.2.1: s/Certificate Authority (CA)/Certification Authority (CA)/

Section 3.3: s/Certificate Provisioning/Certificate provisioning/

Section 5.1.3: s/abandoned/abandoned./

Section 5.1.4: s/Certificate Authority (CA)/Certification Authority (CA)/

IDnits complaints about:

 == The 'Updates: ' line in the draft header should list only the numbers
    of the RFCs which will be updated by this document (if approved); it
    should not include the word 'RFC' in the list.