Re: [saag] RADIUS is deprecating MD5

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

Hi Peter,

from what you are writing, I get the feeling that you don't know what 
RADIUS actually does and assume that it's only one thing.

You are focusing on one thing only - the authentication part. And yes, 
that is completely right, that is usually EAP based and the actual 
authentication is protected by a TLS layer already. But that's not all.

RADIUS is a AAA protocol, and you are only dealing with the first A 
(Authorization) here, but RADIUS also does Authorization and Accounting, 
and those two A's are done outside of EAP, so outside of the TLS layer.

I tried to think of a good analogy here, and I suppose this one fits:

If you are paying by card at a store, then you have to enter your PIN to 
authenticate (unless you don't, but let's just ignore that here and 
assume you have to enter a PIN)

In the RADIUS equivalent, this PIN entry would be encrypted using 
EAP-TLS, so no one but you and your bank can see the PIN. But everything 
else, your card number, the amount you want to pay, the place where you 
are paying, and on the return path, the information whether or not the 
PIN entry was successful, if you have enough money in your account, etc. 
is sent in the clear and protected against tampering by a weak integrity 
check.

But you need the different layers of encryption.
For the sake of this analogy, just assume that the PIN entry is done by 
a completely different part (some kind of secure enclave), that only 
deals with the PIN entry. So all this metadata (card number, amount, and 
on the return path the success information) needs to be in a different 
encryption layer than the PIN.

So we have two protocol layers that both need protection.
And that's what the problem is.

To bring it back to the actual RADIUS protocol:

There is a ton of metadata that is sent over the RADIUS protocol and a 
lot of authorization data as well, like bandwidth restrictions, the VLAN 
the user should be put in, etc.
All things that directly affect the network security, and if we still 
use RADIUS/UDP, then we can only pray that no on-path attacker is there 
and the security provided by the weak integrity protection mechanism holds.

Cheers,
Janfred

On 01.04.24 09:04, Peter Gutmann wrote:
> Viktor Dukhovni <[e-mail]> writes:
> 
>> Others can speak to whether or not the deprecation is or isn't overly
>> disruptive relative to the benefits.
> 
> It depends on whether RADIUS is being used for authentication or as a
> transport layer.  As I've already pointed out, with RADIUS-for-transport
> there's nothing to fix because RADIUS isn't doing anything that matters.
> 
> For those who aren't familiar with how this works, the layering is as follows:
> 
> UDP - Unreliable, and fragments
> RADIUS - Fragments again, but differently to UDP.
> EAP-over-RADIUS
> EAP - Fragments yet again, and differently again.
> A turtle
> More turtles
> Four elephants
> Some form of TLS encapsulation, e.g. EAP-TLS, PEAP, etc
> *** TLS ***
> EAP/DIAMETER/some mess Microsoft invented
> The authentication you're using, often MSCHAPv2 by the time you get here
> 
> Of all that mess, the only parts that matter are the TLS tunnel and the
> authentication run inside it.  Everything before the point marked *** TLS ***
> is irrelevant because its sole purpose is to comply with a decades-long
> accretion of unnecessary layering in various RFCs.
> 
> So when RADIUS is used this way there's nothing to "fix", since the bit that
> matters is already being run inside a TLS tunnel.  It's only when the layering
> is:
> 
> UDP
> RADIUS
> 
> that there's something that needs fixing.
> 
> Peter.
>