Re: [radext] I-D Action: draft-ietf-radext-tls-psk-03.txt

[Heikki Vatiainen <[e-mail]>]

On Fri, 1 Sept 2023 at 15:04, Alan DeKok <[e-mail]> wrote:

>   Can reviewers please check that the updated document addresses their
> concerns.  If so, I believe the document can move forward.
>

The document looks good to me. There's one general question I have about
what must be supported. I've also collected five points where I'd like to
see clarifications. The points do not attempt to change the behaviour
described in the document, only sharpen and enhance what the document says.

In general: What must be supported? Section 5. 'Guidance for RADIUS
Clients' states this:

> Client implementations MUST allow the use of a pre-shared key (TLS-PSK)
> for RADIUS/TLS.
>

Section 6. 'Guidance for RADIUS Servers' does not have a respective
statement. Likely the same requirement applies for servers too?

The document also doesn't say which TLS versions must be supported. Is TLS
1.2 and earlier required too? Further, does the same server instance have
to support both PSK and certificate authenticated TLS connections?

I've worked on an implementation and noticed that simultaneous support for
both PSK and certificate authentication is a bit tricky. RADIUS/TLS
requires TLS client certificate authentication. When this requirement is
combined with the differences between TLS 1.3 and 1.2, how they do PSK, how
they are implemented by TLS stacks, and how a stack requires these all to
be handled, at this point the simplicity of PSK is diminished. Being able
to support, for example, just TLS-PSK with TLS 1.3 would be much simpler
than requiring support for all TLS versions + PSK and certificate
authentication + session resumption.

In short: what are the minimum and suggested implementation requirements?


Here are the five points mentioned above, first:
Section 4.1. says:

> It is RECOMMENDED that systems follow the directions of [RFC9257] Section
> 4 for the use of external PSKs in TLS.
>

Should the section be Section 6 'Recommendations for External PSK Usage'
instead of Section 4?

Second:
Section 6 in RFC 9257 starts with the following text:

> 1. Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be
> at least 128 bits long, ...
>

The draft says, section 4.1, that PSKs are required to be at least 16
octets (128 bits) in length. The draft does not say that anything about
bits of entropy, it only has requirements and recommendations for PSK
length. Further in section 4.1., the code sample pulls 12 octets (96 bits)
from a platform specific random source, and then encodes it to a 24 octet
representation.

Suggestion: be more specific and state, for example, that a minimum length
PSK is sufficient only when it is pulled from a random source that provides
'uniformly and randomly generated' [1] output and therefore provides the
required amount of entropy. In other words, the PSK length after UI
encoding does not satisfy PSK length requirements and the entropy of the
PSK must be considered first. I'm not a crypto expert, therefore I don't
feel confident to suggest a more exact text update.

Also the code snippet in draft section 4.1 should be updated to read 16
octets with a note that the random source is assumed to provide one bit of
entropy for each bit that's read.

[1] https://en.wikipedia.org/wiki/Entropy_(information_theory)


Third:
Section 6.2 'Practices for TLS-PSK', first paragraph ends with:

> The PSK replaces the shared secret as proof of client authenticity and
> shared trust.
>

The previous section 6.1 'Current Practices' discusses the use of source IP
and shared secret with RADIUS/UDP. It might be useful to remind that before
RADIUS/1.1 the shared secret must still be used as it's used currently.
TLS-PSK doesn't change anything in that sense.

I like the analogy Section 6.2 introduces, but it could also be argued that
PSK replaces certificate and its identity and public key. When thought like
that, it's easier to see that the transported RADIUS remains the same no
matter how the TLS connection is authenticated and how its key exchange is
done.


Fourth:
The third paragraph in section 6.2 states the following:

> In most situations a RADIUS server does not need to allow connections from
> the entire Internet. Where such connections are required, as with [RFC7585]
> or with a roaming consortium, TLS-PSK MUST NOT be used. It is significantly
> easier for an attacker to crack a PSK than to forge a client certificate.
>

I'd replace the last sentence with similar text that's used in the last
paragraph of Section 5.1. It simply says that TLS-PSK must not be used
because it's not known how to do this.

OpenSSL 3.0 supports PSKs up to 512 octets (not bits)  which gives the
possibility to have strong PSKs. The current text in the draft would at
least require some justification if it is to be kept.


Fifth:
The last paragraph in Section 6.2.1 'Requirements of TLS-PSK' is:

> Finally, if a RADIUS server does not recognize the PSK identity or if the
> identity is not permitted to use PSK, then the server MAY proceed with a
> certificate-based handshake. Since TLS 1.3 [RFC8446] uses PSK for
> resumption, another use-case is that the PSK identity used for resumption
> may be rejected, in which case a full handshake is performed.
>

The meaning of the second sentence is unclear to me.

--
Heikki Vatiainen
[e-mail]