[RADIATOR] move Message-Authenticator to the top ?

[Patrik Forsberg]

Follow up question on this .. is there a way to disable sending the Message-Authenticator attribute ? .. I know I know but I think I ran into a device that actually _hate_ this attribute for some weird reason.. at least it worked prior to upgrading and now it doesn't .. so at least to exclude this possibility it would be good to be able to remove it without degrading Radiator..

---
Best Regards,
Patrik

> -----Original Message-----
> From: radiator <radiator-bounces at lists.open.com.au> On Behalf Of Heikki
> Vatiainen via radiator
> Sent: Wednesday, September 11, 2024 11:40 AM
> To: radiator at lists.open.com.au
> Subject: Re: [RADIATOR] move Message-Authenticator to the top ?
> 
> On 9.9.2024 9.10, Patrik Forsberg wrote:
> 
> > Upgrade sounds like a good plan then :>
> 
> It's good to upgrade and especially so if there'a possibility that the Radius
> request are transmitted over links where an attacker has the possibility to try
> to alter the messages.
> 
> After the upgrade Radiator will automatically, no config changes needed, reply
> to Access-Requests with Message-Authenticator included as the first
> attribute. Proxied Access-Requests will also automatically include Message-
> Authenticator as the first attribute.
> 
> There are also two new configuration to parameters, one to require Message-
> Authenticator in proxied replies and another to use with Radius clients that are
> not able to send a Message-Authenticator. There are more details in the Blast-
> RADIUS website and in our security notice on our web pages.
> 
> >> Hmm, can you let me know what's the device in question? You can reply
> >> to me directly too. The position of Message-Authenticator should not
> >> matter, even when considering Blast-RADIUS mitigation.
> >
> > That was my thinking and I've already pushed a ticket to the vendor about it
> - I'll respond privately to you which - but as it is the bleeding edge release of a
> software it might be that the configuration knob to disable this behavior
> hasn't been implemented yet...
> 
> Adding the Message-Authenticator as the first attribute is a mitigation for
> clients that *do not* check the Message-Authenticator. This might be because
> of the client has been kept as simple as possible, hasn't been configured to
> require Message-Authenticator, etc. In this case the position is important: it
> prevents the hash collision method the attack uses.
> 
> Requiring Message-Authenticator and checking it too is better because it's a
> HMAC, not a simple hash, and HMAC is not known to be broken. For this
> reason Message-Authenticator can be at any position among the attributes.
> 
> In short, if the client requires Message-Authenticator, the attack prevention is
> not dependent on Message-Authenticator position.
> 
> Hopefully the vendor reviews the information that's now publicly available for
> implementers.
> 
> --
> Heikki Vatiainen
> Radiator Software, makers of Radiator
> Visit radiatorsoftware.com for Radiator AAA server software
> 
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> open.com.au%2Fmailman%2Flistinfo%2Fradiator&data=05%7C02%7Cpatrik.
> forsberg%40globalconnect.se%7C361fbe63c8cd4c69efe408dcd245c054%7C
> dfbb0d3b8276458197a42b844a84ea35%7C0%7C0%7C638616444235388
> 710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=YgaPT9z
> PuLtEuUiNhIFbFfDjQSKeXaP3ugHp345YVGY%3D&reserved=0