require_message_authenticator = auto

[David Herselman]

Hi,

I'd like to thank everyone that contributes to the RADIUS standards and particularly FreeRADIUS developers for their tireless efforts. I realise that the Blast RADIUS protocol vulnerability (CVE-2024-3596) could have been avoided should the standards have adopted recommendations put forward in the past, it must be very frustrating to work on things to have users asking questions more than a year later.

We're diligently upgrading vendor equipment to support message authenticator, where CheckPoint, FortiNet and MikroTik have recently backported support to LTS versions. Whilst security devices (eg firewalls) have unique client definitions to match fixed IPs, we have approximately 1500+ routers that live in non-publicly accessible management subnets, although these are arguably still public as they are reachable from client environments. The main issue with these is that they connect via LTE mobile APNs.

We configured client prefix definitions that cover hundreds of routes (eg 198.19.200.0/23), where we can't simply blindly upgrade these in large batches, requiring client scheduled maintenance windows. Due to how mobile operators assign IPs out of pools for the APNs, it's not possible for us to configure individual client statements.


Any possibility of there being an additional option to augment the auto setting? So that each individual IP in a defined range is flipped to enforcing message-authenticator?

Let me try to explain in way of example, let's say we have a client configured as follows:
    client managed.routers {
            ipaddr        = 198.19.200.0
            netmask     = 23
            secret         = ****************
            nastype      = cisco
            require_message_authenticator = auto-per-IP
    }

We're hoping that other networks would benefit from an option whereby FreeRADIUS would possibly use a bloom filter to mark individual IPs in those subnets to requiring message authenticator should they receive a request which includes the M-A attribute. We would actually prefer FreeRADIUS to additionally flip on enforcement should a request contains the M-A attribute, irrespective of whether or not it's the first packet to arrive after FreeRADIUS was restarted.

This way technicians could schedule and upgrade equipment and thereafter enforce M-A validation without having to reach out to people that have access to restart FreeRADIUS thereafter. It would also inconvenience technicians, forcing them to use special jump hosts that log in using _break glass_ local admin accounts without revealing those credentials in the process (we're hoping that this would motivate technicians to add routers to a _to be upgraded_ list to catch those that fall through cracks).


Any suggestions from anyone that's walked this road before? Have we completely missed the boat or simply unaware of clever ways to handle this scenario?


Regards
David Herselman