Hi Sandy,
To paraphrase Doug: LGTM, ship it.
Kind regards,
Andrej.
On 04/12/2025 17:10, Sandy Ginoza wrote:
Greetings Authors,
Thank you for your review. We have updated the document as described below -
please see followup notes below.
Please note that we highly recommend reviewing the edited files available at the URLs
below, rather than the file at
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-tls13-24>; that
file does not reflect the edits made to date.
The current files are available here:
https://www.rfc-editor.org/authors/rfc9887.xml
https://www.rfc-editor.org/authors/rfc9887.txt
https://www.rfc-editor.org/authors/rfc9887.pdf
https://www.rfc-editor.org/authors/rfc9887.html
Diffs of the most recent updates (only):
https://www.rfc-editor.org/authors/rfc9887-lastdiff.html
https://www.rfc-editor.org/authors/rfc9887-lastrfcdiff.html (side by side)
Note: Some of the updates requested will not appear as diffs because they were
corrected earlier in the process.
AUTH48 diffs:
https://www.rfc-editor.org/authors/rfc9887-auth48diff.html
https://www.rfc-editor.org/authors/rfc9887-auth48rfcdiff.html (side by side)
Comprehensive diffs:
https://www.rfc-editor.org/authors/rfc9887-diff.html
https://www.rfc-editor.org/authors/rfc9887-rfcdiff.html (side by side)
Please review the notes below.
On Dec 1, 2025, at 1:46 PM, heasley <[email protected]> wrote:
Mon, Nov 17, 2025 at 10:38:10PM -0800, Sandy Ginoza:
On Nov 13, 2025, at 2:13 PM, [email protected] wrote:
Wed, Nov 12, 2025 at 03:28:45PM -0800, Sandy Ginoza:
Hi John,
I’m not sure if we’re saying capitalized “Peer” is correct or if there is a
preference for the other update Med suggested:
NEW2:
TLS TACACS+ connections are generally not long-lived. The connection
will be closed by either a peer if it encounters an error
or an inactivity timeout.
hi. Sorry, I mean that capital P is correct. Meaning that either the
server or the client may close the connection.
Regarding capitalization, seemingly, lowercase is consistent with use
throughout the document. The term is capitalized as the definition entry in
Section 2, but it is lowercased in running text.
As editor, please educate/correct me. My understanding is that "Peer" is
not the same as "peer"; the former having been defined in section 2. The
distinction disambiguates which definition is intended.
While we see that “Peer” is defined in section 2, the capitalized form only
appears in the instances noted below. Because “Peer” only seems to appear as a
term or at the beginning of a sentence, we did not realize capitalization was
important here. If changes are needed, please let us know. We are not
confident we can accurately differentiate between peer in general and Peer
defined in section 2.
Peer: The peer of a TACACS+ client (or server) in the context of a
TACACS+ connection, is a TACACS+ server (or client). Together, the
ends of a TACACS+ connection are referred to as peers.
2. Peer authentication: The authentication capabilities of TLS
replace the shared secrets of obfuscation for mutual
authentication.
Peers implementing the TACACS+ protocol variant defined in this
document MUST apply mutual authentication and encrypt all data
exchanged between them. …
Peers MUST NOT use obfuscation with TLS.
Hi Sandy et al,
We have reviewed the entire document and came to the conclusion
that since "peer" is never used in any other context than the one
defined in Section 2, there is no need for it to be capitalized.
So, I retract my comment.
We also discussed changing the term. I am not sure that we really
came to a conlusion on that other than wondering whether it is
necessary given the above.
However, having read through the entire document again, we flagged
a few things that should be corrected in our opinion. As follows,
based on
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-tls13-24 :
Handling of the term "Obfuscation" is inconsistent. For one, the
capitalization of "Obfuscation" is inconsistent. Like "Peer", this
can be made lower-case (in S2).
We have ensured the lowercase form appears throughout, including where it appears as
"data obfuscation” in Section 4. Please let us know if you prefer otherwise.
We do not see occurrences of “Data Obfuscation” in the RFC Series aside from the
section title in RFC 8907.
Second, which I just noticed while writing this email, at some point
the term "MD5 obfuscation" appears to have been coined. That has not
been defined. Obfuscation uses MD5, but is otherwise referred to as
"data obfuscation" (rfc 8907) or "TACACS+ obfuscation" and defined
simply as "obfuscation" in S2.
I have not mentioned this to the other authors, but it seems like
"MD5" should be removed in all occurances. We would value your
opinion as well.
Because the text referring to "MD5 obfuscation” refers to RFC 8907 which does not
use “MD5 obfuscation", we agree with your suggestion to drop “MD5”. We updated the
text - please review and let us know if any changes are needed.
[snipped the resolved issues]
S4
< Section 5.2 of [RFC5425]. Such a method is weak.
Section 4.5 of [RFC8907]. Such a method is weak.
or
Section 4.5. Such a method is weak.
Completely wrong reference.
Original:
[RFC8907] describes the obfuscation mechanism, documented in
Section 5.2 of [RFC5425]. Such a method is weak.
Based on earlier discussion, this was updates as follows:
The obfuscation mechanism documented in Section 4.5 (Data
Obfuscation) of [RFC8907] is weak.
Now appears as follows:
The obfuscation mechanism documented in Section 4.5 of [RFC8907] is
weak.
Please review and let us know if any additional updates are needed or if you
approve the RFC for publication.
Thank you,
RFC Editor/sg
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
