RADIUS Message-Authenticator protects a response path attackers can rewrite
RADIUS carries authentication and authorization decisions for VPNs, switches, wireless controllers, and remote-access gateways. The protocol has a response authenticator, but BlastRADIUS research showed that an attacker able to modify traffic and observe a response could exploit the construction in some deployments. Adding a Message-Authenticator attribute to requests and requiring it on responses closes the specific integrity gap without turning every RADIUS packet into a modern authenticated protocol.
The proxy response is the important object
In a typical exchange, a network access server sends an Access-Request and the RADIUS server returns Access-Accept or Access-Reject. A proxy can sit between them. BlastRADIUS attacks depend on the attacker's ability to manipulate that exchange, not on a remote client simply sending a malformed packet. The consequence is still serious: an Access-Reject can become an Access-Accept, and the network device may then grant access.
The Message-Authenticator is an attribute that authenticates the packet. RFC 2869 defines it, including the requirement to use it for EAP messages. FreeRADIUS's BlastRADIUS guidance recommends upgrading and setting require_message_authenticator and limit_proxy_state for the relevant clients. Both settings matter because they constrain which packets the server accepts and how proxy state is handled.
Do not only test the happy path
A configuration proves more when it tests both directions. Send a normal Access-Request and confirm the server returns the expected decision. Then use a lab client or packet capture to inspect whether the request and response carry Message-Authenticator. Check a client that omits the attribute and confirm the server rejects it when the policy requires the attribute. Test a rejected login as well as an accepted one, because the attack changes a negative decision into a positive one.
Client compatibility is the part that usually blocks rollout. Some network devices are old enough to omit the attribute, and some proxies rewrite packets in ways that break the check. Inventory every client and proxy by vendor, firmware, and configured shared secret. Put a deadline on exceptions instead of adding a permanent bypass. Rotate shared secrets after any period when a proxy or client accepted unauthenticated RADIUS traffic.
Treat RADIUS as one control in a chain
Message-Authenticator uses HMAC-MD5 in the RADIUS construction. The fact that the mechanism is necessary does not make MD5 a general-purpose hash choice for new designs. The recommendation is to implement the protocol's existing integrity check correctly and move authentication traffic to TLS-based protocols such as RadSec where the deployment supports it. Do not infer that a packet is safe because its shared secret is long.
Keep the RADIUS server off the public internet. Restrict management interfaces and shared secrets to network-management segments. Log the client identity, source address, request type, response code, and whether Message-Authenticator validation succeeded. Alert on a rise in invalid authenticator checks or on clients that suddenly start omitting the attribute.
The rollout is small enough to plan: upgrade the server, require the attribute, test each client, remove temporary exceptions, and retain evidence that a modified rejection path is now rejected. That is a stronger outcome than a configuration screenshot.
Top comments (0)