[radext] Re: Selfie Attack on TLS-PSK

[Bernard Aboba <[e-mail]>]

In this message about Selfie as well as the previous post about channel
bindings, I think you have raised several important points:

*1. If a NAS is supporting both RADIUS over (D)TLS as well as RADIUS CoA
over (D)TLS, what does it need to do in order to avoid the Selfie attack?  *

For example, MUST the same (D)TLS session be used in both directions?

*2. How does RADIUS over (D)TLS perform not just authentication (e.g.
verification of certificates or PSKs), but also authorization? *

It is not sufficient for RADIUS clients and servers to use mutual
authentication with certificates or PSKs. It is also necessary to verify
that the endpoints are who they are expected to be.  This may not be so
simple in some deployment scenarios, such as where legacy NAS devices use
RADIUS over (D)TLS proxies, so that a server can receive packets from many
NASes over a (D)TLS session. How does the server validate that these
packets are arriving on the right (D)TLS sessions?  It may seem convenient
to say "we don't care" but surely there are some packet/path combinations
which would be unexpected, indicating mis-routing (and exposure of secrets
as well as location info to unauthorized proxies/servers). For example, it
would be "unusual" for a corpnet RADIUS server to receive RADIUS packets
originating from a corpnet NAS over a (D)TLS session with a roaming
partner.

It's also important to realize that despite what the drafts might say,
there will be deployments that throw common sense to the wind, such as by
utilizing the same PSKs between multiple client/server pairs. The IETF is
not the protocol police, but it is possible for documents to make the
downsides clear, if only so as to make it difficult to say "nobody told us"
when negligent deployments are compromised.

On Wed, Jul 24, 2024 at 3:00 PM Alan DeKok <[e-mail]>
wrote:

> On Jul 24, 2024, at 1:37 PM, Margaret Cullen <[e-mail]> wrote:
> >
> > On a separate but related note….
> >
> > I came across this attack while reading about TLS mutual authentication:
> >
> > https://eprint.iacr.org/2019/347.pdf
> >
>   Nice!  And :(
>
> > Is this something we should consider before we recommend the use of
> TLS-PSK with TLS 1.3? Or has this issues already been addressed?
>
>   This is discussed in RFC 9527:
>
>   https://datatracker.ietf.org/doc/html/rfc9257#section-8
>
>   I'll have to do a deeper dive to see how this affects the TLS-PSK
> document.
>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>