Greetings, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] The title of the document has been updated as follows. "TLS-PSK" has been expanded as "TLS Pre-Shared Key"; however, please let us know if it should be expanded otherwise both here and in the rest of the document. Original: Operational Considerations for RADIUS and TLS-PSK Option A (current title): Operational Considerations for RADIUS and TLS Pre-Shared Key (TLS-PSK) Option B (using the phrase from the abstract): Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS Option C (more similar to the title of RFC 4279): Operational Considerations for RADIUS and TLS Pre-Shared Key (TLS-PSK) Cipher Suites [Note: RFC 4279 has been cited for "TLS-PSK" in RFCs 6614, 6940, and 7593.] --> 2) <!--[rfced] This document has been assigned a new BCP number. Please let us know if this is not correct (i.e., it should be part of an existing BCP). See the complete list of BCPs here: https://www.rfc-editor.org/bcps --> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 4) <!-- [rfced] What specific text does "base32 in the example below" refer to? May we update to provide a more clear pointer for the reader? Original: That is, a PSK with high entropy may be expanded via some construct (e.g., base32 as in the example below) in order to make it easier for people to interact with. --> 5) <!-- [rfced] Section 4.2: We have made some updates to the numbered list at the end of this section, in order to make the list items more parallel. Please review and let us know any further updates. --> 6) <!-- [rfced] For readability, may we format this sentence as a list? Original: For example, the identity may have incorrect UTF-8 format; or it may contain data which forms an injection attack for SQL, LDAP, REST or shell meta characters; or it may contain embedded NUL octets which are incompatible with APIs which expect NUL terminated strings. Perhaps: For example, the identity may: * have an incorrect UTF-8 format, * contain data that forms an injection attack for SQL, the Lightweight Directory Access Protocol (LDAP), Representational State Transfer (REST), or shell meta characters, or * contain embedded NUL octets that are incompatible with APIs that expect NUL terminated strings. --> 7) <!-- [rfced] For clarity, may we update the second part of this sentence to repeat "expose"? This helps to avoid misreading "fields" as a verb. Original: The client implementation can then expose a user interface flag which is "TLS yes / no", and then also fields which ask for the PSK Identity and PSK itself. Perhaps: The client implementation can then expose a user interface flag that is "TLS yes / no", and also expose fields that ask for the PSK Identity and PSK itself. --> 8) <!-- [rfced] Regarding this text in Section 5: a) May we update the first sentence to avoid repetition of "TLS 1.3"? b) This exact text appears again in Section 6 (i.e., for clients and servers). Please review and confirm it is correct for this text to appear twice in this document. Original: For TLS 1.3, Implementations MUST support "psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3 as discussed in [RFC8446], Section 4.2.9 and in [RFC9257], Section 6. Implementations MUST implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2, and in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof these recommendations, we give the following recommendations: * Implementations SHOULD use the "Recommended" cipher suites listed in the IANA "TLS Cipher Suites" registry, - for TLS 1.3, the use "psk_dhe_ke" PSK key exchange mode, - for TLS 1.2 and earlier, use cipher suites which require ephemeral keying. Perhaps: For TLS 1.3, implementations MUST support the "psk_dhe_ke" Pre-Shared Key Exchange Mode as discussed in [RFC8446], Section 4.2.9 and in [RFC9257], Section 6. Implementations MUST implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof these recommendations, we give the following recommendations. * Implementations SHOULD use the "Recommended" cipher suites listed in the IANA "TLS Cipher Suites" registry: - For TLS 1.3, use the "psk_dhe_ke" PSK key exchange mode. - For TLS 1.2 and earlier, use cipher suites that require ephemeral keying. --> 9) <!-- [rfced] Is "clients" meant to be singular possessive or plural possessive in the text below? Original: That is, the IP address is treated as the clients identity, and the shared secret is used to prove the clients authenticity and shared trust. The set of clients forms a logical database "client table", with the IP address as the key. Perhaps (singular possessive): That is, the IP address is treated as the client's identity, and the shared secret is used to prove the client's authenticity and shared trust. The set of clients forms a logical database "client table" with the IP address as the key. --> 10) <!-- [rfced] Informative reference RFC 5077 has been obsoleted by RFC 8446. We recommend replacing RFC 5077 with RFC 8446. However, if RFC 5077 must be referenced, we suggest mentioning RFC 8446 (e.g., "RFC 5077 has been obsoleted by RFC 8446.") See Section 4.8.6 in the RFC Style Guide (RFC 7322). --> 11) <!-- [rfced] Abbreviations and Terminology: a) We note "pre-shared key" appears frequently after the abbreviation "PSK" is introduced. May we update instances of "pre-shared key" to its abbreviation after it is first expanded? b) FYI, we changed "PKSs" to "PSKs" in the text below. Please review whether this is correct. Original: Implementations SHOULD use a humanly readable form of PKSs... c) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be expanded upon first use. How should "PSK-DH" and "ECDHE_PSK" be expanded below? Original: TLS-PSK MUST use modes such as PSK-DH or ECDHE_PSK [RFC5489] which provide forward secrecy. Perhaps: TLS-PSK MUST use modes such as PSK Diffie-Hellman (PSK-DH) or Elliptic Curve Diffie-Hellman Exchange with PSK (ECDHE_PSK) [RFC5489] that provide forward secrecy. d) FYI, we added expansions upon first use for the abbreviations below. Please review each expansion in the document carefully to ensure correctness. Lightweight Directory Access Protocol (LDAP) Representational State Transfer (REST) Network Access Server (NAS) --> 12) <!-- [rfced] FYI, we fixed the links to the sections as follows. Please review to ensure these updates are correct. Original: Further discussion of this topic is contained in []{#sharing}. See {}(#resumption) below for more discussion of issues around resumption. Current: Further discussion of this topic is contained in Section 4.3. See Section 6.2.3 below for more discussion of issues around resumption. --> 13) <!-- [rfced] We updated artwork to sourcecode in Section 4.1.2. Please confirm that this is correct. In addition, please consider whether the "type" attribute of any sourcecode element should be set and/or has been set correctly. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> 14) <!-- [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. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. RFC Editor/kf/ar On Jun 17, 2025, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/06/17 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/rfc9813.xml https://www.rfc-editor.org/authors/rfc9813.html https://www.rfc-editor.org/authors/rfc9813.pdf https://www.rfc-editor.org/authors/rfc9813.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9813-diff.html https://www.rfc-editor.org/authors/rfc9813-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9813-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9813 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9813 (draft-ietf-radext-tls-psk-12) Title : Operational Considerations for RADIUS and TLS-PSK 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