RadSec: Proteger o Tráfego de Autenticação RADIUS com TLS

RadSec: Securing RADIUS Authentication Traffic with TLS. A Purple Technical Briefing. Introduction and Context. Welcome to this Purple technical briefing. I'm going to walk you through RadSec — RADIUS over TLS — what it is, why it matters right now, and how you actually deploy it. This is aimed squarely at network architects and security engineers who are either running cloud RADIUS today or planning to move there. If you're still running on-premise RADIUS servers with UDP and a shared secret, this briefing is for you. Let's set the scene. RADIUS has been the backbone of network authentication for over thirty years. It underpins 802.1X, WPA2-Enterprise, WPA3-Enterprise, and virtually every captive portal system in production today. The protocol itself, defined in RFC 2865, was designed in an era when the internet was a very different place. Authentication traffic between your NAS devices — your access points, switches, and controllers — and your RADIUS server travelled over UDP, port 1812 for authentication, port 1813 for accounting. And that traffic? Largely unencrypted. The only protection was a shared secret used to obfuscate the user password attribute, and even that has well-documented weaknesses. For years, this was acceptable because RADIUS traffic stayed on private, controlled networks. Your NAS devices and your RADIUS server were on the same LAN, or connected via a dedicated MPLS circuit. The attack surface was manageable. But the world has changed. Cloud-native infrastructure, distributed venue deployments, SD-WAN overlays, and the shift to cloud RADIUS services have fundamentally altered the threat model. Your authentication traffic is now traversing the public internet, or at best, shared infrastructure you don't fully control. That's where RadSec comes in. Technical Deep-Dive. RadSec, formally defined in RFC 6614, is RADIUS over TLS. The concept is straightforward: instead of sending RADIUS packets over UDP, you encapsulate them inside a TLS connection over TCP. The result is that all authentication and accounting traffic between your NAS and your RADIUS server is fully encrypted, mutually authenticated, and integrity-protected. RFC 7360 extends this to DTLS — Datagram TLS over UDP — which preserves some of the latency characteristics of the original UDP transport while adding encryption. For most enterprise deployments, TLS over TCP is the right choice. DTLS is worth considering in high-throughput, latency-sensitive environments like large stadium deployments. Let's talk about the mechanics. RadSec operates on TCP port 2083, which is the IANA-assigned port for this protocol. When a NAS device initiates a RadSec connection, it opens a TCP connection to the RADIUS server on port 2083 and performs a TLS handshake. This handshake is mutual — both the client, that's your NAS, and the server present X.509 certificates. The server's certificate is validated against a trusted CA. The client certificate identifies the NAS to the RADIUS server. Once the TLS session is established, RADIUS packets flow inside that encrypted tunnel exactly as they would over UDP, but now with full confidentiality, integrity, and replay protection. This is a significant departure from traditional RADIUS in three important ways. First, the transport is TCP, not UDP. This means you get reliable, ordered delivery. Lost packets are retransmitted automatically. Second, the authentication of both endpoints is certificate-based, not shared-secret-based. This eliminates an entire class of attacks based on weak or compromised shared secrets. Third, the entire RADIUS packet is encrypted, not just the password attribute. That means usernames, session identifiers, and all RADIUS attributes are protected in transit. From a certificate management perspective, you need a PKI — a Public Key Infrastructure — to issue and manage certificates for both your RADIUS server and your NAS devices. In practice, most cloud RADIUS providers, including Purple's cloud-native authentication infrastructure, handle the server-side certificate management for you. Your responsibility is provisioning client certificates to your NAS devices. For large-scale deployments, this is typically handled via your network management platform or a dedicated certificate management system. Certificates should use RSA 2048-bit or ECDSA P-256 as a minimum, with a validity period that balances operational overhead against security hygiene — twelve months is a reasonable default. Now, let's address the comparison with the alternative approach that many organisations use today: IPsec tunnels or VPN overlays to protect RADIUS traffic. IPsec is a perfectly valid approach, but it operates at a different layer. You're encrypting all traffic between two endpoints, which adds complexity — you need to manage IKE, pre-shared keys or certificates for the tunnel itself, and the operational overhead of maintaining tunnel state across potentially hundreds of sites. RadSec is more surgical. It encrypts specifically the RADIUS protocol traffic, operates at the application layer, and integrates directly with your RADIUS infrastructure. For cloud RADIUS deployments where you're connecting many NAS devices at distributed venues to a centralised cloud server, RadSec is architecturally cleaner and operationally simpler. Let me walk you through what a multi-site deployment looks like in practice. You have a cloud RADIUS server — let's say it's Purple's platform — with a valid TLS certificate from a trusted CA. You have three venue types: a hotel property, a retail store, and a conference centre. Each has NAS devices — access points, switches, or wireless LAN controllers. Each NAS device needs to be configured with the RadSec server address, port 2083, and a client certificate. The NAS initiates the TLS connection, the mutual handshake completes, and from that point forward, all 802.1X authentication traffic for guests and staff at that venue flows encrypted to the cloud RADIUS server. If the TLS connection drops — say, due to a network interruption — the NAS re-establishes it automatically. This persistent connection model is actually more efficient than UDP for high-volume deployments because you avoid the overhead of per-packet processing. On the firewall side, you need to allow outbound TCP on port 2083 from your NAS management network to your RADIUS server's IP address or FQDN. If you're running a strict egress policy, you'll also want to allow the return traffic. This is simpler than managing IPsec firewall rules, which often require ESP protocol exceptions and IKE on UDP 500 and 4500. Implementation Recommendations and Pitfalls. Let's talk about what actually goes wrong in RadSec deployments, because there are some consistent failure modes I see across organisations. The first and most common issue is certificate chain validation failures. Your NAS device needs to trust the CA that signed the RADIUS server's certificate. If you're using a cloud RADIUS provider with a certificate from a well-known public CA — DigiCert, Let's Encrypt, Sectigo — most modern NAS devices will trust it out of the box. But if you're using an internal CA, you need to push the CA certificate to every NAS device. This is often overlooked during initial deployment and surfaces as TLS handshake failures that look like connectivity issues. The second pitfall is certificate expiry. Unlike shared secrets, which don't expire, certificates have a defined validity period. If your RADIUS server certificate expires, every NAS device in your estate will fail to authenticate simultaneously. You need certificate lifecycle management — automated renewal where possible, and monitoring with alerting well ahead of expiry. Ninety days' notice is the minimum; thirty days is better. The third issue is NAS device compatibility. Not all NAS devices support RadSec natively. Older Cisco IOS versions, some legacy Aruba controllers, and certain consumer-grade access points don't have RadSec support. Before committing to a RadSec deployment, audit your NAS estate for compatibility. Cisco IOS-XE 16.x and later, Aruba AOS-CX, Ruckus SmartZone, and Juniper EX series all have solid RadSec support. For devices that don't support RadSec natively, a RadSec proxy — an open-source option like radsecproxy — can bridge the gap, accepting UDP RADIUS from legacy devices and forwarding it over TLS to the cloud RADIUS server. The fourth consideration is connection persistence and keepalives. RadSec uses persistent TCP connections, but firewalls and NAT devices with aggressive timeout policies can silently drop idle connections. Configure TCP keepalives on your RadSec connections — typically a keepalive interval of sixty seconds is sufficient to prevent premature connection teardown. Most RADIUS server implementations and NAS devices support this configuration. For Cisco IOS-XE, the RadSec configuration looks like this. You define a RADIUS server with the address of your cloud RADIUS endpoint, specify TLS as the transport, reference your trustpoint — which is the certificate store on the device — and set the destination port to 2083. You then reference this server in your AAA server group configuration. The specifics vary by platform version, but the logical structure is consistent across vendors. For Aruba controllers running AOS, you configure the RADIUS server with the RadSec option enabled, specify the CA certificate for server validation, and optionally configure a client certificate for mutual TLS. Aruba's implementation is mature and well-documented. Rapid-Fire Questions and Answers. Let me run through the questions I get asked most often about RadSec. Does RadSec add latency? The TLS handshake adds a small overhead on initial connection establishment — typically under 100 milliseconds. Once the connection is established, the per-packet overhead is negligible. For 802.1X authentication, where the handshake happens once per session, this is not a meaningful concern. Can I run RadSec alongside traditional UDP RADIUS? Yes. Most RADIUS servers support both simultaneously. During a migration, you can run RadSec for sites that support it and fall back to UDP for legacy sites. This is the recommended migration approach. Is RadSec required for PCI DSS compliance? PCI DSS version 4.0 requires that authentication traffic be protected in transit. RadSec is one of the most direct ways to satisfy this requirement for RADIUS-based authentication. If you're processing card payments over a network that uses RADIUS authentication, RadSec should be on your compliance roadmap. Does RadSec work with EAP? Yes. EAP — Extensible Authentication Protocol — is encapsulated within RADIUS, so EAP-TLS, PEAP, EAP-TTLS all work transparently over RadSec. The EAP exchange itself is unaffected. What about RADIUS accounting? RFC 6614 covers both authentication and accounting traffic. Your accounting data — session start, stop, and interim update records — is also encrypted over the same TLS connection on port 2083. Summary and Next Steps. To bring this together: RadSec is the right transport layer for RADIUS in any deployment where authentication traffic crosses infrastructure you don't fully control. That means cloud RADIUS, multi-site deployments, SD-WAN environments, and any scenario where RADIUS traffic traverses the public internet or shared carrier infrastructure. The key actions for your team are: first, audit your NAS estate for RadSec compatibility and identify any devices that will need a proxy. Second, engage your cloud RADIUS provider — or evaluate providers who support RadSec natively — and understand their certificate management approach. Third, establish a certificate lifecycle management process before you go live. Fourth, update your firewall rules to allow TCP 2083 outbound from your NAS management network. Fifth, test your RadSec configuration in a staging environment before rolling out to production, paying particular attention to certificate chain validation and connection persistence under load. For organisations running Purple's platform for guest WiFi and authentication across distributed venues, RadSec is the recommended transport for cloud RADIUS connectivity. It aligns with Purple's cloud-native architecture and ensures that the authentication data flowing between your venues and the platform is fully protected — which matters both for your security posture and for your compliance obligations under GDPR and PCI DSS. If you're planning a deployment or want to discuss your specific architecture, the Purple team is the right starting point. This has been a Purple technical briefing on RadSec. Thanks for listening.