On Oct 20, 2024, at 10:30 AM, ryslink@dialtelecom.cz wrote:
It seems that since version 3.2.6, Freeradius always sends the Message-Authenticator AVP, as discussed in the thread below (I did search the conference, but did not find anything more relevant).
The release notes explain this issue. There's a longer explanation on the web site, under the BlastRADIUS security notification. The default radiusd.conf file also has explanations.
I have upgraded the freeradius version on the server this weekend, and I have number of customer complaints whose obsolete BRASes fail to process replies containing the M-A AVP. Hence, I would need to selectively remove them from the replies - I tried to do it via the update-reply in the post-auth section of the configuration
update reply { Message-Authenticator !* ANY }
, but examining the packets via radsniff, the replies still do contain the M-A AVP.
Message-Authenticator is always added to replies. This isn't configurable, and cannot be changed or disabled. Please also name the vendor, and the model of BRAS which is behaving this way. The Message-Authenticator attribute has been defined for about 25 years. When a BRAS discards packets containing Message-Authenticator, it means that the vendor has gone out of their way to read the RFCs, and then decide to do something stupid. i.e. This behavior is incompetence bordering on maliciousness.
Could you please kindly advise on how to best remove the M-A attribute via the server configuration?
Downgrade to 3.2.5, and add the BlastRADIUS fixes manually. The BlastRADIUS security notification explains how to do this. Or, you have source. You can patch the server to remove the BlastRADIUS fixes. We are not going to make millions of installations of FreeRADIUS vulnerable to a security issue because some vendor is too lazy or stupid to read the RFCs. While this may sound harsh, there really is no other way to describe this behaviour. The vendor has added code to do something useless, stupid, and insecure. Alan DeKok.