[radext] Re: Selfie Attack on TLS-PSK

[Alan DeKok <[e-mail]>]

On Jul 24, 2024, at 6:11 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? 

  Ideally yes, but we likely need to support all possible other scenarios.

> 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. 

  I'm not clear how this is any different from existing RADIUS routing (or lack thereof).  There's nothing in RADIUS/UDP which addresses these issues.

  RADIUS/UDP is perhaps "protected" from this by the simple fact that client-server relationships are manually configured.  Things change when there is dynamic discovery, as with RFC 7585.  What I can't find in 7585 is any mention of filtering packets inside of the TLS tunnel.  It looks like these issues were missed in that document.

  So the historic RADIUS way of dealing with these issues is to ignore them.

  Do we want to have the TLSbis document solve these issues, or just mention them?

> 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. 

  I think we will get "nobody told us" when the specifications are explicit and clear, but your point is still valid.

  Alan DeKok.