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
