RadSec: Wie RADIUS über TLS die Sicherheit der WiFi-Authentifizierung verbessert

RadSec: How RADIUS over TLS Improves WiFi Authentication Security A Purple Enterprise WiFi Intelligence Briefing Approximate runtime: 10 minutes --- [INTRODUCTION & CONTEXT — approx. 1 minute] Welcome to the Purple Enterprise WiFi Intelligence series. I'm your host, and today we're tackling a topic that sits right at the intersection of network security and operational risk: RadSec — formally defined in RFC 6614 — and why it should be on your infrastructure roadmap if it isn't already. If you're an IT manager, network architect, or CTO responsible for enterprise WiFi across a hotel group, a retail estate, a stadium, or a public-sector campus, this briefing is for you. We're going to cover what RadSec actually is, why the traditional RADIUS protocol leaves you exposed, how to deploy RadSec in a real-world environment, and the pitfalls that catch teams out. No theory for theory's sake — just the information you need to make a decision this quarter. Let's get into it. --- [TECHNICAL DEEP-DIVE — approx. 5 minutes] So, let's start with the problem. RADIUS — Remote Authentication Dial-In User Service — has been the backbone of enterprise WiFi authentication since the 1990s. When a user or device connects to your corporate or guest WiFi, the access point acts as a RADIUS client, forwarding authentication requests to a RADIUS server, which validates credentials against your directory — Active Directory, LDAP, or a cloud identity provider — and either grants or denies access. This is the 802.1X authentication model that underpins WPA2-Enterprise and WPA3-Enterprise networks. The problem is that traditional RADIUS was designed for a different era. It runs over UDP — User Datagram Protocol — on ports 1812 and 1813. UDP is connectionless, which means there's no handshake, no session state, and critically, no native encryption. The only protection between your access point and your RADIUS server is a shared secret — essentially a password — used to obfuscate the user's password in transit using MD5 hashing. MD5, as most of you will know, is cryptographically broken. It's been broken for years. What does that mean in practice? It means that on any network segment where an attacker can intercept RADIUS traffic — and that includes compromised switches, rogue devices on your management VLAN, or any point between a remote access point and a cloud-hosted RADIUS server — they can potentially capture authentication exchanges, attempt offline dictionary attacks against the shared secret, and in some configurations, expose user credentials entirely. For a hotel group running guest WiFi across 200 properties, or a retail chain with access points in every store backhauling to a central RADIUS server over the public internet, this is not a theoretical risk. It is a live attack surface. This is exactly what RadSec solves. RadSec — defined in RFC 6614 and updated by RFC 7360 — wraps RADIUS traffic inside a TLS tunnel. Instead of UDP, it uses TCP on port 2083. Instead of a shared secret and MD5, it uses mutual TLS authentication with X.509 certificates. Both the RADIUS client and the RADIUS server present certificates, verify each other's identity, and establish an encrypted session before any authentication data is exchanged. TLS 1.3 is the current recommended version, providing forward secrecy and eliminating a range of legacy cipher vulnerabilities. The practical effect is significant. Credential data, user attributes, and session tokens are encrypted end-to-end between the access point — or a RadSec proxy — and the RADIUS server. An attacker intercepting traffic on the wire sees only encrypted TLS records. The shared secret is still present for backward compatibility, but it's no longer doing any meaningful security work — TLS is carrying the load. There's another dimension here that's increasingly relevant: roaming. The Eduroam federation, used by universities and research institutions across Europe and beyond, has been running RadSec for years as part of its inter-institutional roaming infrastructure. More recently, the Wi-Fi Alliance's OpenRoaming standard — which enables seamless WiFi roaming across participating venues — mandates RadSec for all federation traffic. If you're deploying OpenRoaming-capable infrastructure, RadSec is not optional; it's a prerequisite. Purple supports OpenRoaming under its Connect licence, acting as an identity provider within the federation, and RadSec is central to how that secure roaming fabric operates. From a compliance standpoint, RadSec is increasingly relevant to PCI DSS 4.0, which tightens requirements around the protection of authentication data in transit. If your WiFi infrastructure touches payment card environments — and in retail and hospitality, it frequently does — the encryption gap in traditional RADIUS is a finding waiting to happen. GDPR similarly requires appropriate technical measures to protect personal data; user credentials and session metadata flowing unencrypted across your network are hard to defend in a data protection audit. Now let's talk architecture. There are two primary deployment patterns for RadSec. The first is native RadSec support on your RADIUS server and access points. FreeRADIUS 3.0 and above supports RadSec natively. Microsoft NPS does not support RadSec natively as of current releases, which is a significant constraint for organisations running Windows-centric infrastructure. Cisco ISE supports RadSec. Aruba ClearPass supports RadSec. If your RADIUS server and your access point vendor both support RadSec natively, this is the cleanest path — configure TLS certificates on both ends, open TCP 2083 on your firewall, and you're encrypting RADIUS traffic end-to-end. The second pattern is a RadSec proxy. This is the more common deployment in practice, particularly for organisations with legacy RADIUS infrastructure or mixed-vendor environments. A RadSec proxy — radsecproxy is the most widely deployed open-source implementation — sits between your access points and your RADIUS server. The access points send standard RADIUS over UDP to the proxy on the local network. The proxy terminates that connection, re-encapsulates the RADIUS traffic inside a TLS tunnel, and forwards it to the upstream RADIUS server over TCP 2083. This approach lets you add RadSec to an existing infrastructure without replacing your RADIUS server, and it's particularly useful when your RADIUS server is hosted in the cloud or accessed over the public internet. Certificate management is the operational complexity you need to plan for. You'll need a PKI — Public Key Infrastructure — to issue and manage the X.509 certificates used for mutual TLS. That means a Certificate Authority, certificate issuance for each RADIUS client and server, and a process for certificate rotation before expiry. Certificates that expire unnoticed will break authentication for every user on your network simultaneously — and that is a scenario you want to avoid. Automate certificate renewal using ACME or your CA's API, and set monitoring alerts well in advance of expiry dates. --- [IMPLEMENTATION RECOMMENDATIONS & PITFALLS — approx. 2 minutes] Let me give you the practical recommendations. First: audit before you deploy. Map every RADIUS client — access points, VPN concentrators, switches doing 802.1X — and every RADIUS server in your environment. Understand which ones support RadSec natively and which will need a proxy. This audit typically surfaces legacy devices that don't support TLS at all, and those need to be on your replacement roadmap. Second: start with the highest-risk traffic. If you have RADIUS traffic traversing the public internet — remote sites, cloud-hosted RADIUS, multi-property hotel groups — that's your first priority. Local RADIUS traffic on a well-segmented management VLAN is lower risk, but it should still be on the roadmap. Third: test mutual TLS thoroughly before go-live. The most common failure mode in RadSec deployments is certificate validation errors — mismatched Common Names, expired intermediate certificates, or clients that don't trust the CA that signed the server certificate. Use openssl s_client to test TLS handshakes before you cut over production traffic. Fourth: don't neglect monitoring. RadSec adds a TCP connection layer that traditional RADIUS doesn't have. TCP connection failures, TLS handshake timeouts, and certificate errors will manifest as authentication failures for your users. Make sure your RADIUS server logs and your proxy logs are feeding into your SIEM or monitoring platform so you can distinguish a RadSec connectivity issue from an authentication policy issue. The pitfall I see most often is organisations deploying RadSec on the server side but forgetting to update their firewall rules. TCP 2083 needs to be open between every RADIUS client and the RADIUS server or proxy. If you're used to managing UDP 1812 rules, TCP 2083 can get missed in the firewall change process. --- [RAPID-FIRE Q&A — approx. 1 minute] Let me run through a few questions I hear regularly. "Does RadSec replace 802.1X?" No. RadSec secures the transport layer between the access point and the RADIUS server. 802.1X is the authentication framework between the client device and the access point. They operate at different layers and are complementary. "Is RadSec supported on all access point vendors?" Not universally. Cisco, Aruba, Ruckus, and Meraki all have varying levels of RadSec support — check your specific firmware version. Where native support is absent, a RadSec proxy is your solution. "What about DTLS — RADIUS over DTLS?" RFC 7360 defines RADIUS over DTLS, which uses UDP rather than TCP, preserving some of the connectionless characteristics of traditional RADIUS while adding encryption. It's less widely deployed than RadSec over TLS but is worth evaluating if latency is a concern in high-throughput environments. "How does this affect roaming performance?" RadSec's TCP connection is persistent, which can actually improve roaming performance in federated environments by reducing connection setup overhead for subsequent authentication requests. --- [SUMMARY & NEXT STEPS — approx. 1 minute] To wrap up: RadSec is the mature, standards-based answer to a genuine security gap in traditional RADIUS. If you're running enterprise WiFi at scale — across multiple sites, over the internet, or in environments subject to PCI DSS or GDPR — the question isn't whether to deploy RadSec, it's when and how. Your next steps: audit your RADIUS infrastructure this week. Identify your highest-risk traffic flows. Check your RADIUS server and access point vendor documentation for native RadSec support. If you're running FreeRADIUS, you can have a test RadSec deployment running in a day. If you're on Microsoft NPS, start evaluating a proxy or a migration path to a RadSec-capable server. Purple's platform is designed to integrate with enterprise RADIUS infrastructure, supporting secure authentication flows for both corporate and guest WiFi environments. If you want to understand how RadSec fits into your specific deployment, the Purple team can walk you through it. Thanks for listening. Until next time. --- END OF SCRIPT