Skip to main content

Early Review of draft-ietf-opsawg-tacacs-tls13-07

Request Review of draft-ietf-opsawg-tacacs-tls13
Requested revision No specific revision (document currently at 10)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2024-05-03
Requested 2024-04-19
Requested by Joe Clarke
Authors Thorsten Dahm , John Heasley , , Andrej Ota
I-D last updated 2024-04-25
Completed reviews Secdir Early review of -07 by Russ Housley (diff)
Tsvart Early review of -07 by Colin Perkins (diff)
Secdir Last Call review of -10 by Russ Housley
We'd like to get some more security eyes on this given some of the comments we've had from the WG.  Additionally, getting a focused OPS review to see if there are other operational considerations for this given the ubiquity of T+ would be beneficial.
Assignment Reviewer Russ Housley
State Completed
Request Early review on draft-ietf-opsawg-tacacs-tls13 by Security Area Directorate Assigned
Posted at
Reviewed revision 07 (document currently at 10)
Result Not ready
Completed 2024-04-25
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 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.


Section 3: Please add a reference for FIPS 140.

Section 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.