Greetings, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
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 --> 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 --> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 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.) Original: While the use of MD5 in RADIUS/TLS is not known to be insecure, it can be difficult for individual organizations to perform cryprographic analyses of the protocols that they use. It is much simpler and more practical to simply verify that there insecure digests such as MD5 are not used anywhere in the system. Then by definition, the systems are at least not known to be insecure. Perhaps: While the use of MD5 in RADIUS/TLS is known to be secure, it can be difficult for individual organizations to perform cryptographic analyses of the protocols that they use. It is much simpler and more practical to simply verify that their insecure digests such as MD5 are not used anywhere in the system. Then by definition, the systems are at least known to be secure. --> 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. Original: A preliminary implementation has shown that only minor code changes are required to support RADIUS/1.1 on top of an existing RADIUS/TLS server implementation, which are: * A method to set the list of supported ALPN protocols before the TLS handshake starts * After the TLS handshake has completed, a method to query if ALPN has chosen a protocol, and if yes, which protocol was chosen. * Changes to the packet encoder and decoder, so that the individual packets are not authenticated, and no attribute is encoded with the historic obfuscation methods. Current: A preliminary implementation has shown that only minor code changes are required to support RADIUS/1.1 on top of an existing RADIUS/TLS server implementation. These include: ... * A method to query if ALPN has chosen a protocol (and if yes, which protocol was chosen) after the TLS handshake has completed. ... --> 6) <!--[rfced] Please clarify "default 4K packet size". Does this refer to the 4096-byte maximum size or something else? Original: * The default 4K packet size 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. --> 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. Original: A more detailed definition of the variable and the meaning of the values is given below. Configuration Variable Name Version b) May the "Values" text be reformatted for clarity? Perhaps it could be more clearly separated into 2 portions as follows. Original: Values When the variable is unset, ALPN is not used. [...] Client Behavior [...] Server Behavior [...] Other values ("1.0", "1.0, 1.1", "1.1", etc.) Client Behavior [...] Server Behavior [...] Perhaps: For "Value": (A) If unset, ALPN is not used. [...] Client Behavior [...] Server Behavior [...] (B) If set to "1.0", "1.0, 1.1", "1.1", or future values: Client Behavior [...] Server Behavior [...] 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".) Original: The client will receive either no ALPN response from the server, or an ALPN response of one version string with MUST match one of the strings it sent, or else a TLS alert of "no_application_protocol" (120). Option A ("either X, Y, or Z"): The client will receive either no ALPN response from the server. an ALPN response of one version string that MUST match one of the strings it sent, or a TLS alert of "no_application_protocol" (120). Option B ("X, Y, or Z"): The client will receive no ALPN response from the server, an ALPN response of one version string that MUST match one of the strings it sent, or 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"? Original: If there are connection issues, then the configuration should be reverted to using allow both "radius/1.0" and "radius/1.1" ALPN strings, until such time as the connection problems have been resolved. 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 time that the connection problems have been resolved. --> 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. --> 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? Original: There are others ways to mitigate these risks. The simplest is to follow the requirements of [RFC6614], Section 2.4 item (3) and [RFC7360], Section 10.4, which mandates that RADIUS over TLS implementations validate the peer before sending any RADIUS traffic. --> 12) <!-- [rfced] As Section 3.4 of RFC 8044 refers to the "text" data, should the section number be updated to 3.5? Original: Specifically, the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes ([RFC2548], Section 2.4) MUST be encoded as any other attribute of data type 'string' ([RFC8044], Section 3.4). Perhaps: Specifically, the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes ([RFC2548], Section 2.4) MUST be encoded as any other attribute of data type 'string' ([RFC8044], Section 3.5). --> 13) <!--[rfced] As the keyword is RECOMMENDED rather than RECOMMENDS, how may this be rephrased? The preceding sentence is included for context. Original: When the Message-Authenticator attribute is missing from Access- Request packets, it is often possible to trivially forge or replay those packets. As such, this document RECOMMENDS that RADIUS clients always include Message-Authenticator in Access-Request packets when using UDP or TCP transport. Perhaps: When the Message-Authenticator attribute is missing from Access- Request packets, it is often possible to trivially forge or replay those packets. As such, it is RECOMMENDED that RADIUS clients always include Message-Authenticator in Access-Request packets when using UDP or TCP transport. --> 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. b) Similarly, should the first sentence of this section contain more list items before the "etc."? Original: While some attributes such as CHAP-Password, etc. depend on insecure cryptographic primitives such as MD5, these attributes are treated as opaque blobs when sent between a RADIUS client and server. 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. Original: So long as any future specification uses the existing encoding, etc. schemes defined for RADIUS, no additional text in future documents is necessary in order to be compatible with RADIUS/1.1. Perhaps: So long as any future specification uses the existing schemes for encoding, decoding, etc., that are defined for RADIUS, no additional text in future documents is necessary in order to be compatible with RADIUS/1.1. --> 15) <!-- [rfced] For conciseness, may we condense these two sentences into one? Original: A server implementing this specification can proxy CHAP, MS-CHAP, etc. without any issue. A server implementing this specification can authenticate CHAP, MS-CHAP, etc. without any issue. Perhaps: A server implementing this specification can proxy and authenticate CHAP, MS-CHAP, etc. without any issue. --> 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. Original: Clients MUST NOT forward the packet over the same connection, and SHOULD NOT forward it to over a different connection to the same server. Current: Clients MUST NOT forward the packet over the same connection and SHOULD NOT forward it over a different connection to the same server. --> 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? --> 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? Examples from this document: data type 'string' ([RFC8044], Section 3.5) data type 'text' 'text' data type in [RFC8044], Section 3.4 "text" ([RFC8044], Section 3.4) or "string" ([RFC8044], Section 3.5). b) Because "ALPN" is "Application-Layer Protocol Negotiation", "ALPN negotiation" seems redundant. May we remove the word 'negotiation' in the following examples? performing ALPN negotiation ALPN negotiation issues. Figure 1: Possible outcomes for ALPN Negotiation 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. Original: ... with value Unsupported Extension (406). ... with value 502 for "Request Not Routable (Proxy)" ... with value 202 for "Invalid EAP Packet (Ignored)". Current: ... with value 406 (Unsupported Extension). ... with value 502 (Request Not Routable (Proxy)). ... with value 202 (Invalid EAP Packet (Ignored)). --> 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? 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? Original: Another way to mitigate these risks is for the system being authenticated to use an authentication protocol which never sends passwords (e.g. EAP-pwd [RFC5931]), or which sends passwords protected by a TLS tunnel (e.g. EAP-TTLS [RFC5281]). Perhaps: Another way to mitigate these risks is for the system being authenticated to use an authentication protocol that never sends passwords (e.g., an Extensible Authentication Protocol (EAP) method like EAP-pwd [RFC5931]), or one that sends passwords protected by a TLS tunnel (e.g., EAP Tunneled Transport Layer Security (EAP-TTLS) [RFC5281]). c) FYI, we have added expansions for the following abbreviations upon first use. Please review to ensure correctness. Challenge Handshake Authentication Protocol (CHAP) Microsoft CHAP (MS-CHAP) Protected Extensible Authentication Protocol (PEAP) --> 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.) While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. 205: The following items are left unchanged from traditional TLS-based 771: from traditional RADIUS. This protocol is only used when --> Thank you. RFC Editor/kf/ar On Apr 3, 2025, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/04/03 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9765.xml https://www.rfc-editor.org/authors/rfc9765.html https://www.rfc-editor.org/authors/rfc9765.pdf https://www.rfc-editor.org/authors/rfc9765.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9765-diff.html https://www.rfc-editor.org/authors/rfc9765-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9765-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9765 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9765 (draft-ietf-radext-radiusv11-11) Title : RADIUS/1.1: Leveraging Application-Layer Protocol Negotiation (ALPN) to Remove MD5 Author(s) : A. DeKok WG Chair(s) : Margaret Cullen, Valery Smyslov Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
