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

Here is my review.

Section 3

"Certificates are hard to manage, but there is no guidance in [RFC6614
<https://www.rfc-editor.org/info/rfc6614>] and [RFC7360
<https://www.rfc-editor.org/info/rfc7360>] for using TLS-PSK."¶
<https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-3-1>

[BA] How about this?

"TLS deployments rely on certificates in most common uses. 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.

Unfortunately, "Transport Layer Security (TLS) Encryption for RADIUS"
[RFC6614] and " Datagram Transport Layer Security (DTLS) as a Transport
Layer for RADIUS" [RFC7360] do not provide guidance for using TLS-PSK."

"Implementations can ensure safety from cross-protocol related output by
not reusing PSKs between TLS 1.3 and TLS 1.2.

[BA] Not sure what "cross-protocol related output" means. How about this?

"Reuse of a PSK in multiple versions of TLS (e.g. TLS 1.2 and TLS 1.3) is
considered unsafe <insert reference>, due to <insert justification>.

¶
<https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-4-7>

"It would be unnecessarily complex for management interfaces and
administrators to manage multiple PSKs depending on the TLS version.
Therefore, we mandate that when TLS-PSK is used, TLS 1.3 or later MUST be
used in RADIUS/TLS and RADIUS/DTLS.¶
<https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-4-8>
"

[BA] I don't think it is helpful to prohibit use of TLS 1.2. Also, won't we
have the same issue if an implementation can reuse a PSK with TLS 1.3 and a
future version? How about this?

"In order to prevent reuse of a PSK with multiple TLS versions,
implementations configuring TLS -PSK MUST require negotiation of the
highest TLS version that they support.  For example, if a TLS
implementation supports both 1.2 and 1.3, the implementation MUST require
that TLS 1.3 be negotiated in RADIUS/TLS and RADIUS/DTLS."

"Implementations MUST use ECDH cipher suites:¶
<https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-4-9>

   - TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256¶
   <https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-4-10.1>
   - TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256¶
   <https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-4-10.2>
   - TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384¶
   <https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-4-10.3>
   - TBD: other TLS ECDH PSK suites¶
   <https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-4-10.4>

"

[BA] In general, ciphersuite mandates have not aged well, because new
ciphersuites are introduced with each TLS version, and others are
deprecated. So I'd try to couch the guidance in terms of a specific TLS
version.

Section 4.1

"A RADIUS client implementing TLS-PSK MUST update their management
interfaces and application programming interfaces (APIs) to label the PSK
field as "PSK" or "TLS-PKS, and MUST NOT label the PSK field as "shared
secret".¶
<https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-4.1-3>

[BA] UI mandates are out of scope for IETF specifications. How about this?

"RADIUS shared secrets cannot safely be used as TLS-PSKs. To prevent
confusion between shared secrets and TLS-PSKs, management interfaces and
APIs need to label PSK fields as "PSK" or "TLS-PSK", rather than "shared
secret".

Section 5.1

"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. A RADIUS server which accepts TLS-PSK MUST have a unique
PSK per RADIUS client.¶
<https://datatracker.ietf.org/doc/html/draft-dekok-radext-tls-psk#section-5.1-8>
"

[BA] I think this requirement could be stated more clearly and should be
placed at the front of the section.  How about this?

"Each RADIUS client MUST be configured with a unique TLS-PSK, which implies
a unique PSK identifier for each RADIUS client. To enforce the use of
unique TLS-PSKs, RADIUS servers accepting TLS-PSK MUST require a unique
TLS-PSK and PSK identifier for each RADIUS client."

Section 6

I'd retitle this as "PSKs and Shared Secrets" and move it closer to the
front of the document, given its importance.

On Fri, Mar 3, 2023 at 10:21 AM Alan DeKok <aland@deployingradius.com>
wrote:

>   A basic TLS-PSK document giving initial guidance on using TLS-PSK.
>
> Begin forwarded message:
>
> *From: *internet-drafts@ietf.org
> *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" <aland@freeradius.org>
>
>
> 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
>
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>