Alan, Paul (as AD), Paul, please review and let us know if you approve the new text (as shown in the diff files) in - Section 1 (per the reply to #4 below) and - Section 3.3.2 (per the reply to #10 below).
Alan, thank you for your reply. Please see the follow-up below. The revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9765.html https://www.rfc-editor.org/authors/rfc9765.txt https://www.rfc-editor.org/authors/rfc9765.pdf https://www.rfc-editor.org/authors/rfc9765.xml This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9765-diff.html https://www.rfc-editor.org/authors/rfc9765-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9765-auth48diff.html https://www.rfc-editor.org/authors/rfc9765-auth48rfcdiff.html (side by side) Re: #13, re: > Perhaps also add a note: > Further issues related to Message-Authenticator are discussed in > [draft-ietf-radext-deprecating-radius]. Is it correct that we should add this sentence to the end of Section 5.2 as its own paragraph, and add draft-ietf-radext-deprecating-radius as an informative reference, with anchor "DEPRECATE-RADIUS"? We will wait to hear from you again before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9765 Thank you. RFC Editor/ar > On Apr 4, 2025, at 3:39 AM, Alan DeKok > <aland=40freeradius....@dmarc.ietf.org> wrote: > > On Apr 3, 2025, at 6:33 PM, rfc-edi...@rfc-editor.org wrote: >> 1) <!-- [rfced] FYI, the title of the document has been updated as follows. >> Please review. >> >> Original: >> RADIUS/1.1, Leveraging ALPN to remove MD5 >> >> Current: >> RADIUS/1.1: Leveraging Application-Layer Protocol Negotiation (ALPN) to >> Remove MD5 >> --> > > This is fine. > >> 2) <!-- [rfced] We have updated the abbreviated title of this document (which >> appears in the header of the PDF output) to match this document's full >> title. Please review to ensure this change is accurate. >> >> Original: RADIUSv11 >> >> Current: RADIUS/1.1 >> --> > > This is fine. > >> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> > > I will do that shortly. > >> 4) <!-- [rfced] To avoid the double negative, may the phrase "not known to be >> insecure" be updated to "known to be secure" in the two instances below? >> (FYI, we changed "there" to "their" based on the context.) > > Unfortunately the change also changes the meaning. Perhaps instead: > > While the use of MD5 in RADIUS/TLS has not been proven to be insecure, it has > not been proven to be secure.. This gap means that > it is difficult to use RADIUS in organizations which require the use of > systems which have proven security. > Those organizations tend to simply ban the use of insecure > digests such as MD5 entirely, even if the use of MD5 has no known security > impact. While the resulting system might still not be secure, > it at least does not contain any known insecurities. > >> 5) <!-- [rfced] FYI - We have updated the second item in the list below for >> parallel structure with the other list items. Please review and let us >> know any objections. > > The change is fine. > >> 6) <!--[rfced] Please clarify "default 4K packet size". >> Does this refer to the 4096-byte maximum size or something else? > > Yes Perhaps instead: > > * The default 4096 octets packet size of [RFC2865], Section 3 is unchanged, > although [RFC7930] can > still be leveraged to use larger packets, > >> 7) <!-- [rfced] Section 2: For readability, we have adjusted some of the >> definitions in this section to have a closer 1:1 relationship >> between abbreviation and expansion. Please review. >> --> > > The changes are fine. > >> >> 8) <!-- [rfced] Section 3.3: Please review the following questions regarding >> the >> list that appears in this section. >> >> a) Is this list intended to directly correspond to the preceding table >> (now Table 1)? If so, please let us know if it should be updated, as >> "Configuration Variable Name" does not appear in the table. > > The intent is to suggest that implementations should define a configuration > variable which is named "Version". The content of that variable is the > values defined in the table. > >> b) May the "Values" text be reformatted for clarity? Perhaps it could >> be more clearly separated into 2 portions as follows. > > The suggested change is fine. > >> c) Please clarify this usage of either / or / or else. Are there three >> alternatives? (Also, seemingly "with" was meant to be "which"; we changed it >> to "that".) > > Perhaps: > > The client will receive either no ALPN response from the > server; or it will receive an ALPN response of one version string that > MUST > match one of the strings it sent; or else their will receive a TLS > alert of > "no_application_protocol" (120). > >> 9) <!-- [rfced] In the text below, how may we adjust the wording of "should >> be >> reverted to using allow both" and "until such time as"? > > Perhaps: > > If there are connection issues, then the configuration should be reverted > to allowing both "radius/1.0" and "radius/1.1" ALPN strings, until the > administrator has resolved the connection problems. > >> 10) <!-- [rfced] In the list that follows Table 2, would you like to >> add entries for "no ALPN" and "1.0"? We note they are the only >> table entries that are not listed. >> --> > > The "no ALPN" and "1.0" are used only in the row / column headings, not in > the table entries. The intent is to use the ALPN strings as the row / column > headings, and the outcomes in the table entries. > > Perhaps the text above the table could say: > > The preceding text gives a large number of recommendations. In order to give > a simpler description of the outcomes, a table of possible behaviors for > client/server values of the Version variable is given below. The row / > column headings are the RADIUS version numbers sent in ALPN (or no ALPN). > The contents of the table are the resulting RADIUS version which is > negotiated. For clarity, only the RADIUS version numbers have been given, > and not the full ALPN strings of (e.g.) "radius/1.0". > > This table and the names given below are for informational and descriptive > purposes only. > >> 11) <!-- [rfced] What does "[RFC6614], Section 2.4 item (3)" refer to? >> Is this intended to refer to a list item, a specific paragraph, or >> otherwise? > > The reference should be to RFC 6614, Section 3.4, item (3). > >> 12) <!-- [rfced] As Section 3.4 of RFC 8044 refers to the "text" data, >> should the section number be updated to 3.5? > > Yes. > >> 13) <!--[rfced] As the keyword is RECOMMENDED rather than RECOMMENDS, >> how may this be rephrased? The preceding sentence is included for >> context. > > The change is fine, thanks. > > Perhaps also add a note: > > Further issues related to Message-Authenticator are discussed in > [draft-ietf-radext-deprecating-radius]. > > The intent of the text here is to raise awareness of issues related to > Message-Authenticator. As this document is informational, it cannot change > any standards. We also don't want this document to depend on a "soon to be > published" draft. > > But it is good to have a note in this document which points out that the > recommendations given here are only temporary. > >> 14) <!-- [rfced] Please review the following questions regarding the usage of >> "etc." in the instances below. >> >> a) Could this section title be updated to be more specific than >> relying on "etc."? >> >> Original: >> 5.4. CHAP, MS-CHAP, etc. > > Perhaps: > > CHAP, MS-CHAP and similar attributes > >> >> b) Similarly, should the first sentence of this section contain more >> list items before the "etc."? > > Perhaps just drop the ", etc.". The preceding "such as" should be good > enough for the reader to note that the text is referring to multiple > attributes, and not just CHAP-Password. > >> c) May we update this text as follows so that "etc." does not interrupt >> the noun/adjective pair "encoding schemes"? If not, please provide >> other text. > > The change is fine. > >> 15) <!-- [rfced] For conciseness, may we condense these two sentences into >> one? > > Yes. > >> 16) <!-- [rfced] FYI, "to" has been removed from "forward it to over a >> different connection" in this sentence. Please let us know if it >> does not convey the intended meaning. > > The change is fine. > >> 17) <!-- [rfced] References: >> >> a) FYI, RFC 5077 (which was obsoleted by RFC 8446) is cited once in >> this document in a block quote. We added a sentence after the >> quoted text to note that fact. >> >> b) FIPS 140 is mentioned throughout this document but is not listed as >> a reference. May we add it as a reference? In addition, may we >> update "FIPS-140" to "FIPS 140" for consistency with this reference? >> --> > > The changes are fine. > >> 18) <!-- [rfced] Please review the following questions and/or changes >> regarding >> the terminology used in this document: >> >> a) We note the use of both single (') and double (") quotes around data types >> in this document. For consistency with RFC 8044, would you like to update to >> double quotes? > > Yes. > >> b) Because "ALPN" is "Application-Layer Protocol Negotiation", >> "ALPN negotiation" seems redundant. May we remove the word 'negotiation' >> in the following examples? > > Yes. > >> c) FYI, we have updated the formatting of the values below for consistency >> with other instances in the document. Please review to ensure these changes >> are correct. > > The changes are fine. > >> 19) <!-- [rfced] Abbreviations: >> Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations must be >> expanded upon first use. >> >> a) Should "CoA-NAK" be expanded as "Change-of-Authorization Negative >> Acknowledgment", or otherwise? > > No. the CoA-NAK name is defined in > https://datatracker.ietf.org/doc/html/rfc3576#section-2.3, and should be used > as-is. > >> Original: >> The Error-Cause attribute is defined in [RFC5176]. The "Table of >> Attributes" section given in [RFC5176], Section 3.6 permits that >> attribute to appear in CoA-NAK and Disconnect-NAK packets. >> >> b) Is this handling of "EAP-pwd" and "EAP-TTLS" accurate? > > Yes. > >> c) FYI, we have added expansions for the following abbreviations >> upon first use. Please review to ensure correctness. > > That's fine. > >> 20) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> For example, please consider whether "traditional" should be updated for >> clarity in the instances below. Would "historic" be an acceptable >> replacement? (We note this document already uses "historic" many times.) > > "historic" is fine. > > Alan DeKok. > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
