[radext] Shepherd review of draft-ietf-radext-tls-psk-03

[Valery Smyslov <[e-mail]>]

Hi,

this is a shepherd review of draft-ietf-radext-tls-psk-03. 
First, as a shepherd, I have to ask the following questions:

1. According to BCP79 all authors and contributors should either disclose
    any known to them IPRs related to the draft or confirm that they are not aware of such IPRs.

2. Are there existing implementations that follow this draft?

Review follows.

Formal issues.
1. Since the draft clarifies RFC6614 and RFC7360 for using with PSK,
     I think that references to these RFCs should be made normative (currently informative).

2. Please make references to RFC7585, RFC9258 and RFC8446 informative. The way they are cited
    doesn't imply that implementers of this draft have to read them.

3. Please make references to RFC9257 and RFC9325 normative. The way they are cited
    implies that implementers of this draft have to read and follow them.

4. Please remove [BCP14] from the references. It is not used in the draft, instead
    RFC2119 and RFC8174 are referenced separately.

5. Section 4.1
    I don't think that referencing RFC8937 is appropriate in the context of this document.
    The idea of improving randomness in RFC8937 is that a long term signature private
     key is used to add an entropy to a random value. And this document assumes that 
     peers don't have certificates (thus don't have long term signature private keys).
     So, it's a bit weird to advice using them. Perhaps we could just reference RFC4086 instead?

6.I think that a sentence should be added somewhere, that unless specifically clarified, 
    by "TLS" both TLS and DTLS are meant in the document. 
    For example, RFC 9325 has the following text:

   Unless it is explicitly called out that a recommendation applies to
   TLS alone or to DTLS alone, each recommendation applies to both TLS
   and DTLS.

7. Section 4.1
    I think that mentioning PAKE TLS needs reference (perhaps RFC5054 and RFC8492, something else?).

Text improvements.
1. Section 4.1.1
    Just to avoid any confusion, can we clarify that by "Shared Secrets" here "RADIUS Shared Secrets" are meant?
    Because PSKs are also "shared secrets", so there is some overlap in terminology and a room for confusion.

2. Section 5.1
     In the text "Due to the security issues described above" it is not immediately clear 
     what issues are meant. Can we replace "above" with a reference to a Section
     where these issues described?

3. Section 5.1
     I think that the text:

   RADIUS/TLS clients MUST still permit the configuration of a RADIUS
   server IP address or host name.  Where [RFC7585] dynamic server
   lookups are used, that specification only makes provisions for
   servers to use certificates.  

   can be rephrased for better clarity. Perhaps:

   With TLS-PSK RADIUS/TLS clients MUST permit the configuration of a RADIUS
   server IP address or host name, because dynamic server lookups [RFC7585] 
   can only be used if servers use certificates.

Nits and grammar:
1. Section 4.1.1:
   s/It is RECOMMENDED that RADIUS clients and server/It is RECOMMENDED that RADIUS clients and servers

2. Section 5:
   s/MUST "psk_dhe_ke"/MUST use "psk_dhe_ke"

[shepherd hat off]

The following issues are not formal and probably require some discussion.
So I want to identify them here mostly from SECRIR reviewer point of view.

1. Section 4.1
    There are requirements on PSKs length, but it is not mentioned that 
    they must be uniformly random, which is important for the security of TLS-PSK.
    Perhaps this is implied, but it's better to spell this out.

    And then I'm a bit concerned that a script generated PSK is provided.
    First, the script "as is" is inconsistent with the requirement above
    (I assume that PSKs are random), because it generates only 12 bytes
    of random data, while the requirement is that PSKs MUST be at least 16 bytes.
    Yes, there is a text that if you want more, just modify the script,
    but most implementers will just copy-paste it. Please, don't provoke them
    to make wrong things.

    In addition, I'm not sure that converting PSKs to a human-readable form is a good idea.
    This conversion makes PSKs weaker (the length is increased, while the initial entropy
    persists, the distribution becomes non-uniform). In my understanding PSKs often 
    are entered to the systems just referencing a file containing them, not by entering them letter by letter.

2. Section 6.2.
    In the text:

   The alternative would be to suggest that RADIUS servers allow any
   source IP address to connect and try TLS-PSK, which could be a
   security risk.

   I think that we should explain what security risk is meant.
   Otherwise it looks like handwaving.

3. Section 6.2.
    The following assertion:

   It is significantly easier for an attacker to crack a PSK than
   to forge a client certificate.

   is not true in general (with sufficiently strong PSKs) and
   is plain wrong if we talk about quantum computers, which
   will break any certificate but cannot break PSKs. So, either
   more context should be given (e.g. we assume that 
   certificate private keys are stored in HSMs, while
   PSKs are not etc.) or this assertion should be removed.

   In my understanding this assertion justifies the requirement
   for servers to filter clients' IP addresses when PSKs are used.
   Perhaps it is better to justify this requirement by mentioning,
   that PSKs are provided to a known clients which location
   is usually well-known, thus we can add a safeguard on IP level.
   On contrast, certificates can be obtained by clients from CAs
   without servers prior knowledge, so it is generally impossible
   to filter out IP addresses of (not-yet-known) clients' in this case.

4. Section 6.2.1
   The text:

   A server supporting this specification MUST be configurable with a
   set of "allowed" network ranges from which clients are permitted to
   connect.

   needs a clarification that only clients wishing to use PSK are considered here.
   Perhaps:

   A server supporting this specification MUST be configurable with a
   set of "allowed" network ranges from which clients wishing to use PSK in TLS
   are permitted to connect.

   Then, an interesting question is what to do with clients that wish to use
   both certificates and PSK (see RFC 8773)? Should servers filter out
   IP addresses of these clients or not? I think some clarification is needed in the draft.

Regards,
Valery.