Skip to main content

Last Call Review of draft-ietf-opsawg-tacacs-tls13-18
review-ietf-opsawg-tacacs-tls13-18-opsdir-lc-wu-2025-03-13-02

Request Review of draft-ietf-opsawg-tacacs-tls13
Requested revision No specific revision (document currently at 20)
Type IETF Last Call Review
Team Ops Directorate (opsdir)
Deadline 2025-03-27
Requested 2025-03-06
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
This document had an early review, and now we're looking to see if all issues have been addressed satisfactorily.
Assignment Reviewer Qin Wu
State Completed
Request IETF Last Call review on draft-ietf-opsawg-tacacs-tls13 by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/LRLWKH-WuI9QeWrzpndJJRyrOV0
Reviewed revision 18 (document currently at 20)
Result Has nits
Completed 2025-03-13
review-ietf-opsawg-tacacs-tls13-18-opsdir-lc-wu-2025-03-13-02
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document updates the TACACS+ protocol to use TLS 1.3 for confidentiality,
integrity and authentication and obsolete insecure mechanism defined in
RFC8907. This document is on the right track and I believe it is ready for
publication. However I have a few comments on the latest v-18.

Major issues:
No
Minor issues:
No
Nits:

1. Section 2 Technical Definition
Section 2 mostly focus on new terminology definition, it is not reasonable to
add section number for each term, suggest to remove section number such as
section 2.1, 2.2, 2.3, etc.

2. Section 3.1
OLD TEXT:
“
 This way the client can ensure that TLS and non TLS traffic are separated even
 where default port numbers are omitted from its TACACS+ server connection
 configuration.
”
NEW TEXT:
“
Through this way the client can ensure that TLS and non TLS traffic are
separated even where default port numbers are omitted from its TACACS+ server
connection configuration. “

3. Section 3.4 said:
“
TLS Cached Information Extension [RFC7924] SHOULD be implemented. This MAY be
augmented with Raw Public Keys [RFC7250], though revocation must be handled as
it is not part of the standard ” Why revocation must be handled as it is not
part of standard, has no clue.

4. Section 7

OLD TEXT:
“
The authors request that, when this draft is accepted by the working group, the
OPSAWG Chairs submit a request to IANA for an early allocation, per [RFC4020]
and [RFC6335], of a new well-known system TCP/IP port number for the service
name "tacacss" (referenced in this document also as "TACACS+ TLS well-known
 port ([TBD])"), described as "TACACS+ over TLS".
“
NEW TEXT:
“
IANA has allocated a new well-known system TCP/IP port number for the service
name "tacacss", per [RFC4020] and [RFC6335] (referenced in this document also
 as "TACACS+ TLS well-known port ([TBD])"), described as "TACACS+ over TLS".
”

5. Section 6.1 said
"
the operator must consider the impact of mixed TLS and Non-TLS on security
"
which security impact of mixed TLS and Non-TLS should be considered? Something
specified in section 5, if yes, please make it clear.