[radext] Re: Selfie Attack on TLS-PSK

[Margaret Cullen <[e-mail]>]

Another (D)TLS security factor concerns _when_ RADIUS packets containing privacy-sensitive or security-sensitive data are sent over the (D)TLS session.  We need to make sure that the mechanisms we are using will not transmit the initial RADIUS packet contents until an encrypted session has been established with a properly authenticated and authorized peer.

I am currently trying to learn enough about DTLS to understand whether that is guaranteed by the DTLS protocol, or if the RADIUS server needs to do something to make sure that happens.

I would welcome help understanding how this works  from people with good DTLS knowledge and experience…

Margaret

On Jul 24, 2024, at 8:12 PM, Bernard Aboba <[e-mail]> wrote:



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" rel="noreferrer nofollow" target="_blank">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" rel="noreferrer nofollow" target="_blank">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]