How to Configure RadSec (RADIUS over TLS) Securely
As strong as the RADIUS protocol is, its reliance on the aging MD5 hash algorithm makes it susceptible to modern forgery and MITM attacks. Hardening networks and isolating traffic can mitigate some of these risks, but these strategies break once RADIUS traffic traverses untrusted domains or the internet.
Modern security guidance largely treats MD5 as an unreliable legacy hash function, with practical collision attacks demonstrating its inadequacy. In environments where RADIUS still relies on MD5, networks need to be transitioned to TLS-protected transports like RadSec to ensure modern, end-to-end cryptographic protection.
We’ll explain what RadSec is and how it works, followed by a breakdown of the differences between RadSec and RADIUS, the benefits of RadSec, configuration options, and more.
What is RadSec?
RadSec, defined in RFC 6614, encapsulates standard RADIUS packets within a TLS session over TCP while preserving existing RADIUS packet structure and AAA semantics. With RadSec in place, RADIUS traffic can traverse untrusted networks with transport-layer encryption and mutual peer authentication provided by TLS.
Enabling RADIUS communication over TLS increases the level of security for authentication carried out across the cloud network. When configured, this feature ensures that the RadSec protocol is used to safely transmit the authentication and accounting data between the Instant AP and the RadSec server.
How RadSec works
RadSec, or RADIUS over TLS, changes how RADIUS messages move across networks, wrapping the entire packet in an encrypted TLS session over TCP. This is how it works:
- RadSec uses TCP and TLS to carry standard RADIUS payloads inside an encrypted tunnel versus cleartext over UDP.
- TLS relies on certificates and negotiated symmetric keys from the handshake to authenticate peers and encrypt traffic between them.
- RadSec uses TCP (default IANA port 2083, though configurable) instead of traditional RADIUS UDP ports 1812 and 1813.
- TCP provides ordered delivery and retransmission at the transport layer, improving reliability over lossy WAN links, though it may introduce additional latency compared to UDP.
- Finally, existing foundational RADIUS semantics (identity, policy, and accounting attributes) stay the same, letting organizations upgrade their transport layer without completely redesigning their AAA logic.
What is the difference between RADIUS and RadSec?
RADIUS relies on UDP (User Datagram Protocol) to transfer information UDP itself is not insecure; the risk lies in RADIUS over UDP lacking encryption and strong integrity protections for the entire packet. UDP is acceptable if package loss is not a concern, but it makes RADIUS communication more vulnerable because important data packets could be lost. Attackers can exploit this vulnerability to infiltrate your network and farm credentials.
How roaming breaks traditional RADIUS
Traditional RADIUS relies on clients communicating with known server IPs using pre-configured shared secrets. This is perfect for a static LAN, but it quickly breaks once requests start to cross multiple proxies and domains, as is common with modern traffic flows to and from a public internet.
In today’s roaming federations like eduroam and OpenRoaming, authentication often travels through proxies controlled by others, making certificate-driven mutual TLS a safer and more scalable strategy for establishing trust across these more dynamic paths.
RadSec and OpenRoaming
RadSec is imperative when it comes to OpenRoaming. OpenRoaming traffic is sent over the internet, meaning most of the time, you won’t know where it will end up or whether it will arrive in the correct order.
The transfer of RADIUS packets over the internet involves breaking them down and reassembling them upon arriving at their destination. Usually, admins aren’t concerned about losing some data over UDP, but it can cause frustration or even security issues. A quick Google search of “lost RADIUS packets” shows how packet loss can become a real headache for admins.
OpenRoaming causes an issue with the RADIUS protocol because the latter relies on the client and server sharing IP addresses and using a shared secret to establish a connection. A roaming solution, like eduroam, requires considerable coordination that normal RADIUS isn’t equipped to handle.
With RadSec, the connection is limited within the PKI. One organization issues certificates to the client and the server. The PKI serves as a trust anchor, so the RADIUS server and client can safely communicate, and no prior knowledge is necessary.
Key benefits of RadSec vs. RADIUS
Beyond solving roaming and federation challenges, RadSec, or RADIUS over TLS, offers other key advantages over legacy RADIUS/UDP.
- E2E encryption for all RADIUS data
RadSec encapsulates the entire RADIUS exchange within TLS tunnelling, so credentials and metadata such as outer identity, NAS IP, and calling station ID are encrypted on the wire instead of exposed in plaintext. - Robust integrity and anti-tampering features
TLS ensures packets cannot be altered in transit without being detected, reducing the risk of spoofing, forgery, and MITM (man-in-the-middle) attacks that target legacy RADIUS/UDP environments. - Mutual certificate-based authentication
RadSec uses X.509 certificates from a trusted CA to mutually authenticate client and server during the TLS handshake, eliminating reliance on risky and complicated static shared secrets for transport-level trust. - Reliable delivery over untrusted networks
Running over TCP gives RadSec ordered, predictable delivery of authentication and accounting records, which are critical when RADIUS traffic traverses lossy or congested WAN paths. - Minimal impact on existing policies
RadSec preserves standard RADIUS semantics of identities, attributes, and policies. This means organizations can upgrade reliability and security at the transport layer without additional re-work of AAA logic.
Since RadSec is only as strong as the PKI underneath it, certificate management must become part of your core network hygiene. Automating certificate issuance, renewal, and revocation for RadSec endpoints preserves the new, stronger protections without driving outages or trust gaps when certs expire.
When is plain RADIUS/TDP sufficient?
For small, single-site environments where RADIUS traffic never leaves a trusted LAN, and there are no roaming or federation requirements, traditional RADIUS/UDP can still be sufficient. Even here, though, best practices call for hardening networks and isolating traffic.
As organizations adopt cloud identity models and build for multi-site access and roaming networks, RadSec becomes the safe and clear choice for futureproofing networks, building on RADIUS fundamentals without redesigning networks from scratch.
RadSec in eduroam: Real-world RADIUS over TLS deployment
Eduroam has quickly become the standard 802.1X network in higher education. It works by allowing students and staff members to use credentials from their home university directory to access Wi-Fi at a remote campus that is also part of the eduroam federation.
Eduroam is a shared SSID that is commonly broadcast in educational institutions around the world, which makes it a target for attackers to exploit as an imitation network. This is one of the primary reasons thousands of universities provide onboarding solutions — to ensure devices are properly configured with server certificate validation enabled so credentials are only provided to the institution’s proper RADIUS server.
However, this service requires a large amount of coordination, top-down management, and admin work. Broadcasting eduroam worldwide requires governmental bodies and institutions to coordinate with one another, but only a select number of locations have been approved for eduroam access. Only time will tell how future RadSec advances will impact eduroam.
How to configure RadSec (RADIUS over TLS)
The RadSec Configuration Process can be broken down into a few high-level steps: configure the RadSec destination and the TLS Connection. You need to specify the RADIUS server transferring the data and define the RadSec destination so the RADIUS traffic can be directed there.
- Import the server CA certificate that issues server certificates.
- You can cross-import CAs if you have two separate CAs issuing server and client certificates.
- This will establish Server Certificate Validation.
- Configure the destination hostname (server name).
- Optional: Specify the port you want to use if the default RadSec port (2083) isn’t ideal.
- Specify the TLS parameters.
- TLS dictates how data will be transferred through RadSec.
- The best practice is to use the EAP-TLS protocol (SecureW2 JoinNow is pre-built for EAP-TLS).
Does RadSec work with NPS and Active Directory?
Currently, it doesn’t appear RadSec is possible with an Active Directory/NPS setup unless you have a third-party extension. However, RadSec would likely be unnecessary for most AD environments.
It is possible to implement RadSec with a radsecproxy that converts legacy RADIUS into RadSec, but this only works for on-premise systems. In order to forward connection requests to a remote NPS or another RADIUS server:
- Create a Remote RADIUS Server Group.
- Configure a connection request policy that forwards requests to that Remote RADIUS Server Group.
With this configuration, NPS can forward authentication requests to any RADIUS server, and users with accounts in untrusted domains can be authenticated. This Windows forum post explains in more detail.
Best practices for secure RadSec deployments
Deploying RadSec is a solid first step, but you still need to treat the TLS layer as critical security infrastructure. This means hardening it with the same attention paid to the rest of your PKI infrastructure.
Enforce modern TLS versions and strong cipher suites
TLS 1.2 should be considered the minimum supported version, with TLS 1.3 preferred where supported by the RADIUS implementation.
Strictly validate servers and hostnames
Ensure RadSec clients validate the server certificate chain, check revocation status where possible, and verify that the certificate’s name matches the expected RadSec endpoint.
Automate certificate lifecycle management
Upgrade issuance, renewal, and revocation operations from manual to automated, to prevent outages or trust gaps from expired certifications, all while reducing IT workload.
Monitor and log RadSec activity
Turn on detailed logging for all RadSec connections and alert on repeated TLS handshake failures, certificate errors, or unusual patterns that indicate possible misconfiguration or attack.
How to enable RadSec with JoinNow Cloud RADIUS
While RadSec is an open protocol that anyone can use, you need the right hardware to implement it. This GitHub link allows you to implement RadSec if your current hardware doesn’t natively support it, but configuration can be a monumental task. Luckily, the SecureW2 JoinNow Cloud RADIUS license supports RadSec.
Cloud RADIUS is a turnkey RADIUS solution that can be implemented into virtually any environment because it works with all major SAML and LDAP Identity Providers like Google, Okta, and Azure. Designed from the ground up for certificate-based authentication, it eliminates the risk of sending credentials over the internet and the potential for credential theft.
Our turnkey PKI solution easily distributes client and server certificates, including provisioning RadSec servers with a server certificate. And our JoinNow onboarding solution can be completed by users in minutes. Or, use API gateways to equip managed devices with certificates, all without end-user interaction.
Everything you need for certificate-based authentication can be set up in under an hour! Check out our affordable solutions for bringing certificate-based authentication to your network resources.
