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]
