Re: [saag] RADIUS is deprecating MD5

[Jan-Frederik Rieckers <[e-mail]>]

Hi Peter,

I think you are missing at least one point.
Yes, the RADIUS protocol has been around for many decades, but that 
doesn't mean that we can't touch it, just because it would affect 
existing deployments.


There are two aspects that are the reasoning behind the deprecation effort:

First: Protecting passwords.
That one you referenced and, as far as I read your mail, this is not the 
one that you have a problem with.
If you use plain RADIUS for authentication with plaintext-Password, then 
the password is encrypted (more accurately: "obfuscated") using the 
RADIUS-built-in MD5/shared-secret/... algorithm, which, to be honest, 
does not provide actual security, with the known weaknesses of MD5.

This is unfortunately still used in the wild, despite better knowledge.
Deprecating this use should be a no-brainer, no one should send data 
encrypted this way over the internet.

Second: Privacy
RADIUS does not encrypt the packets. And this is, IMHO, the more 
important reason to deprecate unencrypted RADIUS, because RADIUS packets 
contain a lot of data, which can be used to identify a person.
As eduroam operator at a national level, this concerns me the most.

Granted, the actual login process and maybe the identity of the user is 
protected using tunneled authentication methods like EAP-TTLS or 
EAP-PEAP, but that only protects the username and password.
There are still a lot of RADIUS attributes that are sent in plaintext, 
i.e. the device's MAC address, the MAC address and SSID of the server, 
if Accounting is enabled than usage statistics, all with an identifier 
that may not directly point to a person, but enough information that an 
attacker that just monitors the connection can gather a lot of data.


So I strongly disagree with your assessment of "this is not worth 
attacking, so we don't need to break stuff that currently works", 
because this is not how we do things here. (At least not from what I 
have taken away from my IETF experiences).

If there is a possible attack, than we need to closely analyze it before 
we come to the conclusion that we ignore it, and I would certainly be 
very concerned if we (as IETF) made that decision based on "oh, if we 
get attacked, that would just be a damage equivalent to 100$, so we'll 
just ignore it, nobody would attack this and we haven't seen attacks, 
there are more lucrative targets out there. Move on, nothing to see here."


The RADIUS/(D)TLS (RFC6614/7360) RFCs (although they are experimental) 
have been around long enough for vendors to implement it. Most of them 
haven't done it, probably because there was no request for this in the 
market.
So deprecating this demonstrably insecure way of sending RADIUS packets 
is a good way to raise people's attention to it, and maybe lead to 
administrators questioning their choices of sending unencrypted RADIUS 
traffic.

Cheers,
Janfred

On 31.03.24 12:49, Peter Gutmann wrote:
> Alan DeKok <[e-mail]> writes:
> 
>> We will be deprecating the use of RADIUS/UDP, in large part due to it's
>> reliance on MD5.  Everyone shipping RADIUS clients should take a serious look
>> at moving to TLS immediately.
> 
> Maybe I'm missing something here but won't this break pretty much every RADIUS
> implementation in existence, in particular stuff that's been around forever
> and is unlikely to change?
> 
> Also since the cases I'm familiar with just use RADIUS as an extremely awkward
> transport mechanism for EAP-xTLS, with user = "anonymous" and password = some
> widely-known dummy value at the RADIUS level so there's no security there to
> begin with, it seems like the draft should emphasise that this applies to raw
> RADIUS, not RADIUS used purely as a transport mechanism for something else.
> 
> Also, just to be nitpicky:
> 
>> While MD5 has been broken, it is a testament to the design of RADIUS that
>> there have been (as yet) no attacks on RADIUS Authenticator signatures which
>> are stronger than brute-force.
> 
> I'd say that's more a testament to the fact that there's nothing there worth
> attacking, meaning that there are far easier and more effective attacks
> elsewhere.  Use it to secure BTC transactions or something similar and I'm
> sure we'd see attacks turn up fairly quickly.  This is based on experience
> with very weak DKIM signing keys, which were breakable without too much effort
> but where no-one ever bothered because they weren't protecting anything of
> value that wasn't attackable through easier means.
> 
> Peter.
>