What is RadSec? Configuring RadSec (RADIUS Over TLS)
As strong as the RADIUS protocol is, its reliance on the aging MD5 hash algorithm makes it susceptible to modern forgery and MITM attacks. Networks need to be transitioned to Transport Layer Security or TLS-protected transports like RadSec to ensure modern, end-to-end cryptographic protection.
We’ll explain what RadSec is and how it works. In addition, we’ll provide 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, is a secure transport method for RADIUS that encapsulates standard RADIUS packets within a TLS session over TCP. It preserves existing RADIUS packet structure and authentication, authorization and accounting (AAA) semantics while adding transport-layer encryption and mutual certificate-based authentication.
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 typically uses TCP port 2083 for RADIUS over TLS connection instead of traditional RADIUS ports 1812 (authentication) and 1813 (accounting).
- The use of TCP gives RadSec built-in reliability features like retransmission and ordered delivery, helping reduce packet loss and performance issues often seen with RADIUS/UDP over the internet.
- 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 .
How to Configure RadSec (RADIUS Over TLS)
The RadSec configuration process can be broken down into a few high-level steps: configuring 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. Here’s how to do that:
- 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 process 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).
What Is the Difference between RADIUS and RadSec?
RADIUS relies on UDP (User Datagram Protocol) to transfer information, while RadSec relies on TCP (Transmission Control Protocol). UDP is considered less secure than TCP because messages are sent without a requirement for setting up communication channels. UDP is acceptable if packet 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.
While both protocols support AAA services, the biggest differences between traditional RADIUS and RadSec come down to transport security, reliability and suitability for cloud-connected environments.
This comparison table highlights the main differences between RADIUS and RadSec.
| Feature | Traditional RADIUS | RadSec (RADIUS Over TLS) |
|---|---|---|
| Transport Protocol | UDP | TCP + TLS |
| Default Ports | 1812 / 1813 | 2083 |
| Encryption | Limited Protection Using Shared Secrets | Full TLS Encryption |
| Authentication Method | Shared Secret | Certificate-Based Authentication |
| Protection Against MITM Attacks | Limited | Strong |
| Reliability | No Guaranteed Packet Delivery | Ordered and Reliable Delivery |
| Internet Traversal | Less Secure Across Public Networks | Designed for Secure Internet Transport |
| Certificate Support | Not Required | Required |
| Best Use Cases | Small Internal Networks | Cloud, Roaming, Federated Authentication |
| Common Deployments | Legacy Enterprise Networks | eduroam, OpenRoaming, Cloud RADIUS |
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 connection.
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.
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.
- End-to-end encryption for all RADIUS data
RadSec encapsulates the entire RADIUS exchange within TLS tunnelling, so credentials and metadata like 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 man-in-the-middle (MITM) attacks that target legacy RADIUS/UDP environments. - Mutual certificate-based authentication
Instead of relying on shared secrets, RadSec uses X.509 certificates from a trusted CA to mutually authenticate client and server during the TLS handshake. - 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.
Best Practices for Secure RadSec Deployments
Deploying RadSec is an important 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
Prioritize for TLS 1.2+ (ideally 1.3 where possible) and disable weak or legacy cipher suites to avoid downgrades and known cryptographic weaknesses.
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! Request a demo to see how SecureW2 can bring certificate-based authentication to your network resources.
