RADIUS Security Guide: Blast-RADIUS, RadSec and Safe Deployment

RADIUS still decides who gets onto Wi-Fi, VPNs, switches and network device consoles in most organisations, and its packet integrity rests on MD5 and a shared secret designed in the 1990s. The Blast-RADIUS disclosure in July 2024 (CVE-2024-3596) showed that an attacker on the network path can turn an Access-Reject into an Access-Accept without knowing the password or the shared secret. This guide explains how RADIUS protects packets under RFC 2865, what Blast-RADIUS changes, which settings close it on common servers, and where RADIUS over TLS (RadSec) stands in the IETF today. It is written for network and identity engineers who run RADIUS servers, NAS devices, wireless controllers and VPN gateways, and for architects planning the move off RADIUS over UDP.

Key takeaways

• Blast-RADIUS forges responses, not passwords. An on-path attacker uses an MD5 chosen-prefix collision to make a forged Access-Accept carry a valid Response Authenticator.
• Message-Authenticator is the short-term fix. Require it on every Access-Request and put it first in every response, upgrading servers before clients.
• EAP-only deployments were not practically exposed. EAP already requires Message-Authenticator, so PAP, CHAP and other non-EAP flows (VPN, device administration, MFA proxies) carry the risk.
• RADIUS over UDP should stay on trusted networks. Current IETF work says RADIUS/UDP and RADIUS/TCP must not be used outside secure networks; use RadSec or at least IPsec across untrusted links.
• RadSec is still moving to the standards track. RFC 6614 and RFC 7360 are Experimental; their replacement is with the IESG and RADIUS/1.1 (RFC 9765) removes MD5 entirely, also as Experimental.

How RADIUS protects packets, and why that is weak

RFC 2865 defines RADIUS over UDP to port 1812 (accounting uses 1813; early deployments used 1645, which clashes with another registered service). The client, called the NAS (a switch, wireless controller, VPN gateway or other network device), and the server share a secret, which the server selects by the packet's source IP address. Everything else follows from that secret and MD5:

RFC 2865 asks for a shared secret of at least 16 octets, as unguessable as a well-chosen password, and forbids an empty secret because packets could then be forged trivially. The packet codes worth recognising in logs are 1 Access-Request, 2 Access-Accept, 3 Access-Reject and 11 Access-Challenge. For the network access control systems that sit on top of this, see the Network Access Control (NAC) Guide.

Blast-RADIUS (CVE-2024-3596) explained for defenders

CERT/CC published VU#456537 on 9 July 2024. The researchers' site and the advisory describe the issue as a protocol weakness rather than a bug in one product:

• What the attacker gains: the ability to change any valid response into another, so a rejected login becomes accepted. CERT/CC notes that turning an Access-Challenge into an Access-Accept can bypass multi-factor authentication that is delivered through RADIUS challenges.
• What the attacker needs: a position on the path between NAS and server, or between any two hops in a proxy chain, and RADIUS over UDP carrying a non-EAP method such as PAP.
• What the attacker does not get: user passwords or the shared secret.
• Practicality: the published proof of concept needed minutes of computation per forgery on older hardware, longer than typical NAS timeouts, but the researchers warn that GPUs or dedicated hardware would make it faster. Plan as if it is practical.
• What is lower risk: RADIUS/TLS, accounting-only traffic and EAP-only deployments. The Wi-Fi Alliance stated that its specifications use RADIUS only for EAP, so WPA2 and WPA3 Enterprise flows are not forgeable this way.

The researchers are explicit that several intuitive fixes are not enough on their own: shorter timeouts, MFA, rejecting unexpected Proxy-State attributes, strong shared secrets and a unilateral switch away from MD5. The fixes that work change how packets are authenticated or wrap them in TLS. In ATT&CK terms the attack is a form of T1557 Adversary-in-the-Middle that results in T1556 Modify Authentication Process outcomes, without stealing credentials.

Exposure by deployment type

Closing Blast-RADIUS: settings on common servers

The fix has two halves. Servers must send Message-Authenticator as the first attribute in every Access-Accept, Access-Reject and Access-Challenge, and NAS devices must check it. Servers should also require Message-Authenticator in Access-Requests. Upgrade servers first, then clients, because a server that requires the attribute will drop requests from clients that do not yet send it.

Microsoft NPS (KB5040268)

• Per RADIUS client: "Access-Request messages must contain the message-authenticator attribute", or netsh nps set client name = <client name> requireauthattrib = yes.
• Per remote RADIUS server (NPS as proxy): "The request must contain the Message-Authenticator attribute", or netsh nps set remoteserver ... requireauthattrib = yes.
• limitProxyState: drops requests with Proxy-State but no Message-Authenticator. Modes Audit, Enable and Disable, for example netsh nps set limitproxystate all = "audit", with per-client exceptions.
• requireMsgAuth: when NPS proxies, requires Message-Authenticator in responses from remote servers, with the same modes.
• Events: 4418 (request dropped), 4419 (would be dropped, audit), 4420 (proxy response without Message-Authenticator, audit), 4421 (protections not in Enable mode at service start).

FreeRADIUS

• Settings: in the security section of radiusd.conf, require_message_authenticator = auto and limit_proxy_state = auto. The project notes that upgrading does not add these to an existing configuration, so they must be set by hand.
• Caveats: auto learns per client, so several NAS devices behind one NAT address stay exposed until each is upgraded; setting true can drop legitimate clients that do not send the attribute. Versions 2.x and earlier are end of life with no fix.

NAS devices and appliances

• Firmware: apply the vendor's Blast-RADIUS update to wireless controllers, switches, VPN gateways and firewalls, then enable the option to require Message-Authenticator in responses.
• Proxies: every hop in a proxy chain must be fixed; one unpatched proxy keeps the chain exposed.

RadSec and the current RFC status

The long-term answer from the researchers, CERT/CC and the IETF RADEXT working group is to stop relying on MD5 and run RADIUS inside an authenticated, encrypted transport. The status of the relevant documents, checked on 26 October 2026:

Because these drafts are not yet RFCs, wording and numbers may change. The practical message is stable: RadSec with mutual certificate authentication is the transport to plan for, especially for anything that crosses a network you do not control.

Choosing a transport

RadSec certificates are machine identities with the same expiry and issuance risks as any other. See the mTLS Guide and the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Safe deployment beyond Blast-RADIUS

• Prefer EAP-TLS for network access: certificate-based EAP removes passwords from 802.1X and is unaffected by Blast-RADIUS. See the Wi-Fi Security Guide.
• Retire MS-CHAPv2: the deprecation draft says MS-CHAP must not be used unless protected by RadSec and that new clients must not implement MS-CHAPv1, MS-CHAPv2 or EAP-MSCHAPv2. Where a password method is unavoidable, the draft prefers PAP inside a protected transport over CHAP and MS-CHAP.
• Shared secrets: unique per NAS, generated from a secure random source, at least 24 octets as the draft recommends for administrators, and stored in a secrets manager rather than in spreadsheets or device configuration backups. They are long-lived machine credentials; see the Service Account Security Guide for ownership and rotation practice.
• Isolate RADIUS traffic: keep NAS to server traffic on a management VLAN with ACLs allowing only known NAS addresses to reach UDP 1812 and 1813. The researchers stress this reduces exposure but does not fix the protocol.
• Protect the directory behind RADIUS: RADIUS servers usually check passwords against AD or LDAP, so their bind accounts need the controls in the LDAP Security Deep Dive Guide.
• Limit what an Accept grants: return VLAN, ACL or privilege attributes per policy rather than full access, so a forged or stolen Accept yields as little as possible.

Rolling out the fixes

1. Inventory: list every RADIUS server, proxy and NAS, the method each flow uses (EAP, PAP, CHAP, MS-CHAP) and whether traffic crosses untrusted networks. Non-EAP flows and internet-crossing proxies go first.
2. Patch servers: upgrade NPS, FreeRADIUS or the commercial server so it sends Message-Authenticator first in all responses.
3. Audit requests: set NPS limitProxyState and requireMsgAuth to Audit, or FreeRADIUS to auto, and collect events 4419 and 4420 or equivalent logs to find clients that do not comply.
4. Patch NAS devices: upgrade firmware and enable response verification on each NAS, in pilot groups (one wireless controller, one VPN gateway) before the estate.
5. Enforce: move to Enable or true per client as each one is confirmed, keeping a time-limited exception list.
6. Move cross-network links to RadSec: start with cloud RADIUS and partner proxies, then inter-site links.
7. Rollback: per-client exceptions (NPS exception = "yes") or returning one client to audit mode restores service for a broken device without weakening the rest. Record each rollback with an owner and a date.

Detection and measurement

Log Access-Accepts with unexpected or random-looking Proxy-State attributes, which the researchers identify as a sign of forgery attempts, along with NPS 4418 to 4421 or FreeRADIUS drops for missing Message-Authenticator, Accepts for users the backing directory rejected, and admin logins to network devices that do not match a change window. Password guessing through a VPN's RADIUS front end shows up as bursts of Access-Rejects across many users (T1110.003 Password Spraying).

• Message-Authenticator coverage: percentage of RADIUS clients in Enable or true mode, target 100 per cent for non-EAP flows.
• Audit events: daily count of 4419 and 4420 (or equivalents), trending to zero.
• Transport: percentage of RADIUS flows crossing untrusted networks that use RadSec or IPsec.
• Legacy methods: number of flows still using MS-CHAPv2 or CHAP.
• Secret hygiene: percentage of NAS entries with a unique secret of at least 24 octets rotated in the last 12 months.

Framework mapping

In ISO/IEC 27001:2022 Annex A the work maps mainly to A.8.5 Secure authentication, A.8.20 Networks security, A.8.24 Use of cryptography and A.8.15 Logging.

Common failure patterns

• Patching the server and stopping: the server sends Message-Authenticator, but NAS devices never verify it, so forged responses are still accepted.
• Assuming Wi-Fi coverage means everything is safe: EAP flows are fine, while the VPN, MFA proxy and switch administration flows on the same server use PAP and stay exposed.
• Relying on MFA: when the second factor is delivered through RADIUS challenges, a forged Accept skips it.
• One secret everywhere: the same short shared secret on every switch, copied into configuration backups and support tickets, so one leak exposes every flow.
• RADIUS across the internet: cloud RADIUS or partner proxies reached over plain UDP, where on-path access is easiest.
• Enforcing without audit: requiring Message-Authenticator before older NAS firmware is updated, causing a VPN outage and a permanent rollback.

Practitioner checklist

• Inventory every RADIUS server, proxy and NAS with its authentication method and network path.
• Upgrade RADIUS servers so Message-Authenticator is the first attribute in every response.
• Run NPS limitProxyState and requireMsgAuth in Audit, or FreeRADIUS settings at auto, and clear the non-compliant clients.
• Upgrade NAS firmware and enable response verification, then move each client to enforcement.
• Move every RADIUS flow that crosses an untrusted network to RadSec with mutual certificate authentication, or IPsec as a stopgap.
• Replace MS-CHAPv2 and PEAP-MSCHAPv2 with EAP-TLS where possible.
• Give each NAS a unique random shared secret of at least 24 octets held in a secrets manager.
• Restrict UDP 1812 and 1813 to known NAS addresses on a management network.
• Alert on unexpected Proxy-State in Accepts and on NPS 4418 to 4420 events, and track the five metrics monthly.

Standards and references

• IETF: RFC 2865 Remote Authentication Dial In User Service (RADIUS)
• IETF: RFC 6614 Transport Layer Security (TLS) Encryption for RADIUS
• IETF: RFC 9765 RADIUS/1.1, Leveraging ALPN to Remove MD5
• IETF: Deprecating Insecure Practices in RADIUS (Internet-Draft)
• IETF: (Datagram) Transport Layer Security ((D)TLS) Encryption for RADIUS (Internet-Draft)
• CERT/CC: VU#456537 RADIUS Protocol Susceptible to Forgery Attacks
• Blast-RADIUS: RADIUS protocol forgery research (CVE-2024-3596)
• Microsoft: KB5040268 Managing the Access-Request packets vulnerability (CVE-2024-3596)

Related NHI Mgmt Group resources: Network Access Control (NAC) Guide · Wi-Fi Security Guide · VPN Security Guide · LDAP Security Deep Dive Guide · mTLS Guide