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

Reply via email to