[radext] Re: Selfie Attack on TLS-PSK

[Margaret Cullen <[e-mail]>]

Speaking as an individual…

I am not talking about trying to establish any sort of cryptographic end-to-end trust in a multi-hop RADIUS fabric.  I agree that we don’t have that today, and it is not our goal to change that.  I am talking about the security properties of a single RADIUS hop. I am also talking about how those properties feed into the security models of multi-hop deployments.

It doesn’t matter, for a single hop, whether the client or the server (or both) are proxies. Nor does it matter how or why a client wants to send a series of RADIUS packets to a particular RADIUS server. Talking about what happened at other hops is all smoke.  There might not even be other hops.

There is currently one standard way to send RADIUS  traffic across a single hop:

- RADIUS/UDP (using pre-shared secrets)

We are proposing to standardize 4 additional ways to send RADIUS traffic across a single hop:

- RADIUS/TLS-PSK
- RADIUS/TLS (using certificates)
- RADIUS/DTLS-PSK
- RADIUS/DTLS (using certificates)

These could be described as four variants of RadSec.

The security properties of these  four variants are similar but not the same, and they are all considerably different from RADIUS/UDP. 

I am trying to understand (and I personally believe that the WG should be trying to understand and document) the differences between the security properties of each of these variants, and the differences between these variants and RADIUS/UDP.  We should also take special note of how those properties differ from RADIUS/UDP, and understand the impact of those differences (if any) on current multi-hop RADIUS deployment models.

I don’t think it is sufficient to say “RADIUS isn’t secure, anyway, so it doesn’t matter” or to say “just use TLS” which doesn’t make any more sense, in my opinion, than saying “just use IPsec”.

There are differences between authenticating  a peer at the RADIUS layer (using shared secrets) vs. trusting that the peer was authenticated at the transport layer.  There are also differences between encrypting information based on a RADIUS layer key (the shared secret) vs sending sensitive information in clear text over an encrypted channel.  These differences have security implications that we need to understand and document.

I am particularly concerned about the second change, removing protection of the sensitive parts of the RADIUS packet, but that might just be because it is the first potentially damaging difference I noticed.

Let’s take Stefan Winter’s example where he said:

“But even then I can imagine operators to state: our internal network is perfectly secure, so we don't need custom shared secrets and allow a dumb copy & forward of the datagrams with the existing shared secret "radsec".”

As Stefan points out, copying of a RADIUS/TLS-transmitted RADIUS message on to a local network is different (and less secure) than dumb copying of a message that was transmitted via RADIUS/UDP, because sensitive data in the message transmitted via UDP will still be protected (to some degree) by the RADIUS secret and MD5, while the packet coming from RADIUS/TLS would use a well-known RADIUS secret, “radsec”, essentially equivalent to sending the sensitive parts of the packet in clear text.

Who is going to tell this operator that he has to consider this security regression when moving to RadSec? Do we think he will go read the RFCs (where we do not yet document this fact, but should), or that he will just assume that the newer, non-deprecated version of RADIUS is “more secure”?

This security difference would also apply to storing or transmitting raw RADIUS packets for logging or debugging.  With RadSec, more sensitive data would essentially be in clear text  in those packets, perhaps including passwords.

[Note: We could fix this problem, without reintroducing manually configured secrets, by using unique TLS channel information to protect sensitive parts of the RADIUS packet, ideally with a stronger algorithm than MD5…. But that is ranging away from the point of this message.]

My point is that we should make sure that moving away from the solution we are deprecating (RADIUS/UDP) and moving to any if the solutions we are recommending (any one of the RadSec variants) does not result in security regressions, and that any security model changes are well-documented.

Margaret












> On Jul 25, 2024, at 5:06 AM, [e-mail] wrote:
> 
>> 
>>> 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