Overview
RADIUS protects less than most deployments assume. The shared secret hides the password and supports integrity checks on some packets, but the rest of the exchange, including usernames and most attributes, travels in the clear. Full confidentiality means carrying RADIUS inside TLS, as RadSec does. After an audit finding or a vendor bulletin, the useful question about RADIUS protocol security is which parts of your traffic are exposed and what to do about them.
Is RADIUS secure? What RADIUS protocol security covers
RADIUS protects the password attribute well and little else. The role of RADIUS in network security was set in the dial-up era, when the link between the network access server (NAS) and the RADIUS server was assumed to be private, so the design relies on one shared secret per client and a few MD5-derived checks. Nothing in the base protocol, RFC 2865, encrypts the packet.
The RADIUS shared secret
Every client (a BNG, a Wi-Fi controller, a VPN gateway) holds a secret the server also holds. The secret never travels on the wire. It is mixed into MD5 computations so each side can prove it knows the secret, and so the User-Password attribute can be obscured. RFC 2865 asks for at least 16 octets.
Request and Response Authenticators
Each Access-Request carries a random 16-byte Request Authenticator which, combined with the secret, keys the transform that hides the password. The reply’s Response Authenticator is an MD5 digest over the reply, the Request Authenticator and the secret, so the client can confirm the reply came from a holder of the secret. The request itself gets no integrity check.
What the shared secret does not protect
What does RADIUS not protect? Almost everything except the password. The rest of the exchange crosses the network as plain text, readable by anyone on the path. Most risk assessments never draw that line; the table below does.
| Part of the exchange | Covered by the shared secret? | In practice |
| User-Password | Yes, obscured | Recovering the secret unmasks every captured password. |
| CHAP-Challenge and CHAP-Password | No | Both visible; weak passwords guessable offline. |
| User-Name | No | Subscriber identity or device login is visible. |
| NAS-IP-Address, NAS-Identifier, Called- and Calling-Station-Id | No | Device, port and client MAC address are visible. |
| Framed-IP-Address, VLAN, QoS, VSAs and other reply attributes | No | Session address and granted policy are visible. |
| Access-Request as a whole | Only with Message-Authenticator | Attributes can be altered in transit. |
| Access-Accept, Access-Reject, Access-Challenge | Weakly | A bare MD5 digest; forgeable under specific conditions. |
| Accounting packets | Integrity only | Tamper-evident but readable. |
| Replay | No | No timestamp or sequence protection. |
An observer who never touches the secret still learns who is connecting, from which device, and what they were granted. The secret itself is all that stands between a packet capture and the passwords inside it. Those two facts are why RADIUS needs TLS protection for anything beyond the password.
The Message-Authenticator attribute
Message-Authenticator is an HMAC-MD5 signature over the whole RADIUS packet, keyed with the shared secret. It is the only standard mechanism that gives an Access-Request integrity protection. Attribute type 80 was defined in RFC 2869 and made mandatory on EAP packets by RFC 3579. Because HMAC is keyed, the collision weaknesses of plain MD5 do not carry over. A receiver that checks the attribute can be sure the packet came from a holder of the secret and was not changed in transit.
Why enforcing it matters
RFC 5080 recommended the attribute in 2007. Even so, many clients never sent it on non-EAP requests, and most servers accepted its absence, so unauthenticated requests got through. Enforcement has two halves: clients include the attribute on every Access-Request, and servers reject any request without it.
PAP vs CHAP vs EAP inside RADIUS
The authentication method decides what crosses the wire and what the server has to store. It does not change the fact that the wire itself is unprotected, which is the part the PAP vs CHAP debate usually leaves out.
| Method | What crosses the wire | What the server must hold | Shared-secret protection | Exposure on an unprotected link |
| PAP | User-Password, obscured | Any form, including a salted hash | Password hidden; nothing else | Safe only while the secret is; identity and attributes visible. |
| CHAP (MS-CHAPv2 behaves similarly) | A challenge and an MD5 response | The clear-text or reversible password | None | Response visible. Weak passwords guessable offline. |
| EAP with a TLS-based method | EAP-Message attributes carrying a TLS session | Depends on the method; certificates for EAP-TLS | Message-Authenticator mandatory (RFC 3579) | Credentials protected end to end. Outer identity and reply attributes visible. |
Why the method choice depends on transport
CHAP is often chosen because it “does not send the password.” On an observable link, though, the IETF’s current security review (draft-ietf-radext-review-radius-02, August 2026) rates cracking a CHAP response as roughly as costly as cracking the shared secret, so the advantage is thin. PAP is weak on the wire and strong on the server, since the password can be stored as a hash. Inside TLS its wire weakness disappears. EAP-TLS removes the password entirely where device certificates are practical. The companion piece on certificate-based authentication covers that path.
Known RADIUS protocol vulnerabilities
RADIUS protocol security weaknesses are properties of the design rather than bugs in one product. Two matter most: MD5 as an ad hoc integrity mechanism, and an Access-Request with no integrity check unless Message-Authenticator is present.
BlastRADIUS (CVE-2024-3596)
BlastRADIUS was disclosed on 9 July 2024 under CERT/CC Vulnerability Note VU#456537. An on-path (man-in-the-middle) attacker can turn a valid response into a different one, for example a reject into an accept, by exploiting the MD5 weakness in the Response Authenticator. The forged reply passes the client’s check without the attacker knowing the shared secret. The attack applies to non-EAP methods over UDP. EAP exchanges are unaffected because RFC 3579 already requires Message-Authenticator. CERT/CC’s guidance is to update clients and servers, require Message-Authenticator, move to TLS or DTLS, and keep RADIUS traffic off untrusted networks.
RADIUS security best practices: a hardening checklist
How to harden a RADIUS deployment, in order. Items 1 and 2 close the forgery problem, 3 to 5 limit the damage from a leaked secret, and 6 and 7 remove the weakness rather than patching around it. Worked through in that order, it doubles as a RADIUS vulnerability mitigation checklist for an audit response.
- Patch every RADIUS client and server for Message-Authenticator support.
- Require Message-Authenticator on every Access-Request; reject requests without it.
- Replace short or reused secrets with long, random, per-client secrets.
- Restrict RADIUS ports to known clients and keep the traffic off untrusted segments.
- Rotate secrets on a schedule and after staff or vendor changes, with rollback tested.
- Move authentication traffic to RADIUS over TLS (RadSec) or DTLS; retire plain UDP.
- Prefer EAP-TLS where device certificates are practical; otherwise PAP inside TLS rather than CHAP over UDP.
Item 2 causes outages if rushed. Inventory which clients already send the attribute, update the rest, confirm compliance in the server logs, then switch the server to reject. Item 4 is covered in the piece on RADIUS ports and transport, item 6 in the companion guide to RADIUS over TLS, and server-side controls under AAA server hardening best practices.
Planning this across a large estate? Talk to an expert about securing AAA infrastructure.
Carrier RADIUS security at operator scale
At operator scale, secret rotation and transport migration stop being configuration tasks. Forty RADIUS clients are easy. Thousands of BNGs, Wi-Fi controllers, VPN concentrators and roaming proxies turn items 3, 5 and 6 into projects with their own plans.
Rotating secrets across a large device estate
Many operators still run one secret per vendor or region and have never rotated at scale. The protocol offers no help here: the secret must change on client and server at the same moment, or that client stops authenticating. Keep one secret per device in the AAA client inventory, so uniqueness is enforced by the system rather than by a policy document. Run a platform that accepts old and new secrets for the same client during a defined window, so a flag day becomes a rolling change. After each device update, send a Status-Server probe (RFC 5997). It requires Message-Authenticator, so a pass confirms the new secret without touching a subscriber. Roll out in rings — lab, one region, then the rest.
Staged migration to encrypted transport
Not every network element supports RADIUS over TLS. Add a TLS listener beside UDP and move inter-server and roaming links first, since proxies are usually the most capable clients. Then migrate access devices as support allows, front the rest with a local RadSec proxy or an IPsec tunnel, and keep Message-Authenticator enforced on UDP for as long as it exists. Before you plan the migration, check that your carrier-grade AAA server supports per-client secrets, dual-secret windows and a staged TLS rollout.
Frequently asked questions
Q1. Is RADIUS secure?
Partially, and by design. RADIUS protocol security covers the password attribute and gives responses a weak integrity check. Everything else travels in the clear, and requests have no integrity protection unless Message-Authenticator is enforced.
Q2. Does RADIUS encrypt the password?
It obscures it. The User-Password attribute is transformed with an MD5-based operation keyed by the shared secret and the Request Authenticator. Anyone who recovers the secret can reverse it.
Q3. What is the Message-Authenticator attribute?
An HMAC-MD5 signature over the whole packet, keyed with the shared secret. RFC 3579 made it mandatory for EAP, and enforcing it on every Access-Request is the short-term fix for BlastRADIUS.
Q4. What is BlastRADIUS?
A protocol-level vulnerability, CVE-2024-3596, disclosed in July 2024 under CERT/CC VU#456537. An on-path attacker can turn a reject into an accept without knowing the shared secret. It affects non-EAP authentication over UDP. Patching and requiring Message-Authenticator mitigate it.
Q5. What is the difference between PAP and CHAP?
Which is more secure, PAP or CHAP? Neither, on an unprotected link. PAP sends the password, obscured by the shared secret, and lets the server store it as a hash. CHAP sends a challenge-response that exposes a guessable hash and forces the server to keep a recoverable copy. Neither protects the rest of the packet.
Q6. How long should a RADIUS shared secret be?
RFC 2865 asks for at least 16 octets. The IETF’s draft on deprecating insecure RADIUS practices goes further: long, random secrets, never shared across clients, with anything short assumed already recovered.
Q7. Does RadSec fix these issues?
It fixes the transport exposure. RADIUS over TLS, defined in RFC 6614, wraps the exchange in an authenticated, encrypted session, removing the clear-text problem and the MD5 forgery on that leg. It does not change what the server stores. RFC 6614 is Experimental, and a standards-track successor is in progress at the IETF.
Q8. Which RFC covers RADIUS security?
No single RFC defines a RADIUS security protocol. RFC 2865, Section 8 sets out the base model and its limits, RFC 3579 specifies Message-Authenticator, and RFC 6614 and RFC 7360 cover RADIUS over TLS and DTLS. The AAA protocols reference on this site collects them.
RADIUS protocol security is achievable, but only for a team that knows exactly what the shared secret covers and has protected everything it does not. Enforce Message-Authenticator now, then read the companion guide to RADIUS over TLS for the structural fix; if you need the fundamentals first, start with how the RADIUS protocol works.
