Early Review of draft-ietf-opsawg-tacacs-tls13-10
review-ietf-opsawg-tacacs-tls13-10-opsdir-early-qu-2024-08-03-00

Request Review of draft-ietf-opsawg-tacacs-tls13
Requested revision No specific revision (document currently at 20)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2024-05-03
Requested 2024-04-19
Requested by Joe Clarke
Authors Thorsten Dahm , John Heasley , dcmgash@cisco.com , Andrej Ota
I-D last updated 2025-04-29 (Latest revision 2025-04-13)
Completed reviews Secdir Early review of -07 by Russ Housley (diff)
Tsvart Early review of -07 by Colin Perkins (diff)
Secdir IETF Last Call review of -10 by Russ Housley (diff)
Opsdir Early review of -10 by Yingzhen Qu (diff)
Opsdir IETF Last Call review of -18 by Qin Wu (diff)
Secdir IETF Last Call review of -18 by Russ Housley (diff)
Secdir IETF Last Call review of -19 by Russ Housley (diff)
Genart IETF Last Call review of -20 by Russ Housley
Artart IETF Last Call review of -20 by Rich Salz
Comments 
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 Yingzhen Qu
State Completed
Request Early review on draft-ietf-opsawg-tacacs-tls13 by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/KtymSaAoyAmmF8HdVUQCnZ_LI80
Reviewed revision 10 (document currently at 20)
Result Has issues
Completed 2024-08-03
review-ietf-opsawg-tacacs-tls13-10-opsdir-early-qu-2024-08-03-00
I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

I have the following questions and nits for the authors to consider:

102      Protocol [RFC8907] provides Device Administration for routers,
nits: s/Device Administration/device administration

106      within the Device Administration use case.
same nits as above.

190      To ensure separation of TACACS+ traffic that uses TLS from that which
191      does not (Section 5.3), they will be deployed on different ports.
Q: This seems to contradict with section 5.1.1, which says "TACACS+ servers that
have TLS support MUST NOT allow Non-TLS connections". If a TACACS+ server uses TLS,
it should not have non-TLS connections.

205      A TACACS+ client initiates a TLS connection by making a TCP
206      connection to a configured server on the TACACS+ TLS port number
207      ([TBD]) (Section 3.1).
Q: should this reference Section 7?

271      support certificate Path verification as described in Section 6 of
nits: s/Path/path

270      The implementation of certificate based mutual authentication MUST
271      support certificate Path verification as described in Section 6 of
272      [RFC5280]
Q: Add RFC 9608 as a reference?

303      For the server-side validation of client identities, Implementations
nits: s/Implementations/implementations

303	   For the server-side validation of client identities, Implementations
304	   must support the ability to configure which fields of a certificate
Should this be MUST?

325	   Section 5.1.5 for securitly related operator considerations.
nits: s/securitly/security

535	   https://www.iana.org/assignments/service-name-port-numbers/
the correct link is: https://www.iana.org/assignments/service-names-port-numbers/