[radext] Re: Selfie Attack on TLS-PSK

[[e-mail]]

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

Without wishing to speak for her, I think Margaret is noting that RADIUS over (D)TLS does not offer end-to-end assurances in the way that people tend to assume that TLS provides. 

The absence of this property is obvious in the UDP world: the trust boundary is clearly demarcated with explicit, manual configuration. It is intuitively obvious that a downstream proxy can modify packets in many ways, undetected.

(D)TLS does not (and cannot) change this. However, TLS -- and certificates in particular -- offers new ways of defining the trust boundary. So, the security properties resulting from a given configuration could be hard to assess across a heterogenous deployment. As a data point, about 0.1% of requests on US eduroam originate from RADIUS clients that have nothing to do with WiFi because of proxy misconfiguration. Imagine having a VPN concentrator that can be accessed by a large part of the world's student population.

The document does not set out to solve this problem; and nor should it. However, I think it would be good to discuss the issue in the Security Considerations section.

I agree with your characterisation of this issue as a routing problem. One of the legacies of the NAI is that we're stuck in a realm-based forwarding paradigm, but this discussion shows that it is not sufficient to that a packet arrives at the right destination (a problem of discovery). It needs to travel there in a way that is consistent with policy (a problem of trust).

Josh