Re: [radext] Fwd: New Version Notification for draft-dekok-radext-tls-psk-00.txt

[[e-mail]]

Hi Alan,

 

I am sorry for the late review; a few comments:

 

1. "However, we recognize that it may be difficult to fully upgrade client
implementations to allow for certificates to be used with RADIUS/TLS and
RADIUS/DTLS"

 

I think the motivation for TLS-PSK is broader than client implementations
(e.g., certs are costly to manage). I suggest replacing this with "However,
we recognize that certificates may not always be the most appropriate choice
for RADIUS/TLS and RADIUS/DTLS".

 

2. "The client implementation can then expose a flag "TLS yes / no", and
then a shared secret (now PSK) entry field."

 

I think the presentation of the configuration is an implementation choice.
There are other ways that a PSK could be provisioned into a client. I
suggest either removing this text, or softening it so that it is understood
as a possible approach.

 

3. "Any shared secret used for RADIUS/UDP or RADIUS/TLS [RFC6613] MUST NOT
be used for TLS-PSK".

 

I assume this is meant as simultaneous use? It would be convenient for
operators to switch from RFC2865 to TLS-PSK transport, with the PSK taking
the same value as the shared secret (subject to the other requirements).

 

4. "That is, short PSKs MUST NOT be permitted to be used".

 

I think the language here could be improved: "Shorter PSKs of 15 bytes or
less MUST NOT be used".

 

5. "We also incorporate by reference the requirements of Section 10.2 of
[RFC7360] when using PSKs"

 

Is this meant normatively? If so, the language could be more explicit and
the reference to RFC7360 moved from "Informative" to "Normative".

 

6. label the PSK field as "PSK" or "TLS-PKS

 

There is a missing quotation mark at the end of the sentence.

 

7. "Where dynamic server lookups [RFC7585] are not used, RADIUS clients MUST
still permit the configuration of a RADIUS server IP address."

 

RFC7585 discusses certificates, which is outside of the scope of this
document, and so this sentence could be simplified: "RADIUS clients MUST
still permit the configuration of a RADIUS server IP address".

 

8. "RADIUS servers MUST be able to look up PSK identity in a subsystem which
then returns the actual PSK."

 

Implementation detail - suggest removing.

 

9. "RADIUS servers MUST support IP address and network filtering of the
source IP address for all TLS connections. There is rarely a reason for a
RADIUS server to allow connections from the entire Internet, and there are
many reasons to limit permitted connections to a small list of networks."

 

I think this text needs qualifying to make it explicit that it refers to
connections using TLS-PSK. The point of RFC7585 is to permit connections
from the entire Internet.

 

As a general point, is the text around filtering needed? Operators are
familiar with the need to restrict inbound connections to applications using
network policy enforced by host or perimeter firewalls. This text is pushing
the management of network policy into the server, and so implies that the IP
address actually is an identifier in terms of connection policy. I think it
would be helpful to have greater clarity here around the roles of PSK
identifiers and IP addresses as factors of connection policy.

 

10. "RADIUS servers SHOULD tie PSK identities to a particular permitted IP
address or permitted network, as doing so will lower the risk if a PSK is
leaked"

 

See my para above.

 

11. "A RADIUS server which accepts TLS-PSK MUST support a unique PSK
identifier per RADIUS client. There is no reason to use the same identifier
for multiple clients"

 

There is a reason to use the same identifier for multiple clients: deployers
would find it very convenient. It is common practice to use the same RADIUS
shared secret(s) for clients within larger deployments. Indeed, RFC2865
states that "[.] it is expected that the same secret MAY be used to
authenticate with servers [.]".

 

This requirement forces deployers to manage unique identifiers and PSKs per
client. Why?

 

In general, this doc looks good; but I think the language around the roles
and use of IP addresses and PSK identifiers for connection policy needs
clarifying (happy to propose some text); and we should relax the per-client
identifier/PSK requirement to bring this inline with existing, accepted
practices.

 

Josh 

 

From: radext <[e-mail]> On Behalf Of Alan DeKok
Sent: Friday, March 3, 2023 3:21 PM
To: [e-mail]
Subject: [radext] Fwd: New Version Notification for
draft-dekok-radext-tls-psk-00.txt

 

  A basic TLS-PSK document giving initial guidance on using TLS-PSK.





Begin forwarded message:

 

From: [e-mail] <mailto:[e-mail]> 

Subject: New Version Notification for draft-dekok-radext-tls-psk-00.txt

Date: March 3, 2023 at 10:11:20 AM EST

To: "Alan DeKok" <[e-mail] <mailto:[e-mail]> >

 


A new version of I-D, draft-dekok-radext-tls-psk-00.txt
has been successfully submitted by Alan DeKok and posted to the
IETF repository.

Name:                draft-dekok-radext-tls-psk
Revision:           00
Title:                    RADIUS and TLS-PSK
Document date:             2023-03-03
Group:                               Individual Submission
Pages:                7
URL:
https://www.ietf.org/archive/id/draft-dekok-radext-tls-psk-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dekok-radext-tls-psk/
Html:
https://www.ietf.org/archive/id/draft-dekok-radext-tls-psk-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk


Abstract:
  This document gives implementation and operational considerations for
  using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360).




The IETF Secretariat