Selective removal of the Message-Authenticator AVP from the Radius server replies

[ryslink at dialtelecom.cz]

Hello,

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).

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.

Could you please kindly advise on how to best remove the M-A attribute 
via the server configuration?

Thank you very much in advance.

-- 
Regards,
Daniel Ryšlink

Dne 19-Sep-24 v 13:27 Alan DeKok napsal(a):

> On Sep 19, 2024, at 4:21 AM, Bjørn Mork via Freeradius-Users<freeradius-users at lists.freeradius.org> wrote:
>> Unsurprisingly, many router vendors are still trying to implement the
>> BlastRADIUS recommendations in their RADIUS clients.  With "interesting"
>> effects as a result.
>    Vendors are "special".  There was one I found which would discard packets which contained Message-Authenticator.
>
>    Why?  "It's unexpected".  <sigh>
>
>> I got a complaint yesterday that vendor A now requires M-A in the
>> Accept-Accept, or the session is rejected. I guess that's good.  We were
>> running 3.2.2 on the servers in question.  An upgrade was obviously long
>> overdue in any case, so I upgraded to 3.2.6.  And everything was fine.
>> For several minutes.
>>
>> Then it turned out that vendor C also must have been working on their
>> BlastRADIUS implementation.  Unfortunately, it seems that they only got
>> as far as to make the authentication process crash if the Access-Accept
>> includes M-A.  Nice work!
>    :(
>
>> How are we supposed to handle real world vendors like that? It would be
>> nice to have some fine grained M-A enable/disable knobs.  E.g. by client
>> or account (virtual internal attribute?).  By client will not work well
>> for proxied requests, so that's probably not sufficient.
>    Vendors should just fix their products.  It's not hard.  Message-Authenticator has been defined for 20+ years.  It's not rocket surgery.
>
>> Will of course also work with the vendor, but that takes time.  And we
>> have a number of routers to upgrade before it's done. Testing is a bit
>> of a hassle when we have to switch FR versions to enable/disable M-A
>> (unless we cheat with a proxy filter).
>    Arg.
>
>    I _really_ don't want to add more configuration flags to work around broken vendor equipment.  That kind of nonsense tends to hang around for decades, because vendors go "well, there's a flag to work around it, so we don't have to fix our products!"
>
>    I'll see if there's a good solution, but I suspect not.  If vendors could ship products which aren't garbage, that would be great...
>
>    Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html