Many, many thanks Sandy and team! From: Sandy Ginoza <[email protected]> Date: Monday, 8 December 2025 at 15:47 To: Andrej Ota <[email protected]> Cc: heasley <[email protected]>, [email protected] <[email protected]>, Douglas Gash (dcmgash) <[email protected]>, Thorsten Dahm <[email protected]>, RFC Editor <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Joe Clarke (jclarke) <[email protected]>, [email protected] <[email protected]> Subject: Re: AUTH48: RFC-to-be 9887 <draft-ietf-opsawg-tacacs-tls13-24> for your review
Andrej and John, Thank you for your replies. We have noted your approvals on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9887>. We have received all of the needed approvals, so we will prepare this document for publication - we expect it to be announced in then next few days. Thank you! Sandy Ginoza RFC Production Center > On Dec 5, 2025, at 6:08 PM, Andrej Ota <[email protected]> wrote: > > 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]
