RadSec: Securing RADIUS Authentication Traffic with 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. Hablemos de la mecánica. RadSec opera en el puerto TCP 2083, que es el puerto asignado por la IANA para este protocolo. Cuando un dispositivo NAS inicia una conexión RadSec, abre una conexión TCP al servidor RADIUS en el puerto 2083 y realiza un saludo TLS. Este saludo es mutuo: tanto el cliente (es decir, su NAS) como el servidor presentan certificados X.509. El certificado del servidor se valida contra una CA de confianza. El certificado del cliente identifica al NAS ante el servidor RADIUS. Una vez establecida la sesión TLS, los paquetes RADIUS fluyen dentro de ese túnel cifrado exactamente como lo harían sobre UDP, pero ahora con total confidencialidad, integridad y protección contra ataques de replicación. Esto representa un cambio significativo respecto al RADIUS tradicional en tres aspectos importantes. Primero, el transporte es TCP, no UDP. Esto significa que obtiene una entrega confiable y ordenada. Los paquetes perdidos se retransmiten automáticamente. Segundo, la autenticación de ambos extremos se basa en certificados, no en secretos compartidos. Esto elimina toda una clase de ataques basados en secretos compartidos débiles o comprometidos. Tercero, se cifra todo el paquete RADIUS, no solo el atributo de contraseña. Eso significa que los nombres de usuario, los identificadores de sesión y todos los atributos de RADIUS están protegidos en tránsito. Desde la perspectiva de la gestión de certificados, necesita una PKI (Infraestructura de Clave Pública) para emitir y gestionar certificados tanto para su servidor RADIUS como para sus dispositivos NAS. En la práctica, la mayoría de los proveedores de RADIUS en la nube, incluida la infraestructura de autenticación nativa de la nube de Purple, se encargan de la gestión de certificados del lado del servidor por usted. Su responsabilidad es aprovisionar los certificados de cliente en sus dispositivos NAS. Para implementaciones a gran escala, esto se gestiona normalmente a través de su plataforma de gestión de red o un sistema dedicado de gestión de certificados. Los certificados deben utilizar RSA de 2048 bits o ECDSA P-256 como mínimo, con un periodo de validez que equilibre la carga operativa con la higiene de seguridad; doce meses es un valor predeterminado razonable. Ahora, abordemos la comparación con el enfoque alternativo que muchas organizaciones utilizan hoy en día: túneles IPsec o superposiciones de VPN para proteger el tráfico RADIUS. IPsec es un enfoque perfectamente válido, pero opera en una capa diferente. Está cifrando todo el tráfico entre dos extremos, lo que añade complejidad: debe gestionar IKE, claves precompartidas o certificados para el propio túnel, y la carga operativa de mantener el estado del túnel en potencialmente cientos de sitios. RadSec es más quirúrgico. Cifra específicamente el tráfico del protocolo RADIUS, opera en la capa de aplicación y se integra directamente con su infraestructura RADIUS. Para implementaciones de RADIUS en la nube donde se conectan muchos dispositivos NAS en sitios distribuidos a un servidor centralizado en la nube, RadSec es arquitectónicamente más limpio y operativamente más sencillo. Permítame guiarle a través de cómo se ve una implementación multisitio en la práctica. Tiene un servidor RADIUS en la nube —digamos que es la plataforma de Purple— con un certificado TLS válido de una CA de confianza. Tiene tres tipos de sedes: un hotel, una tienda minorista y un centro de conferencias. Cada uno tiene dispositivos NAS: puntos de acceso, switches o controladores de LAN inalámbrica. Cada dispositivo NAS debe configurarse con la dirección del servidor RadSec, el puerto 2083 y un certificado de cliente. El NAS inicia la conexión TLS, se completa el saludo mutuo y, a partir de ese momento, todo el tráfico de autenticación 802.1X para huéspedes y personal en esa sede fluye de forma cifrada hacia el servidor RADIUS en la nube. Si la conexión TLS se cae —por ejemplo, debido a una interrupción de la red— el NAS la restablece automáticamente. Este modelo de conexión persistente es en realidad más eficiente que UDP para implementaciones de gran volumen porque evita la sobrecarga del procesamiento por paquete. Por el lado del firewall, debe permitir el tráfico TCP saliente en el puerto 2083 desde su red de administración de NAS hacia la dirección IP o FQDN de su servidor RADIUS. Si tiene una política de egreso estricta, también querrá permitir el tráfico de retorno. Esto es más sencillo que administrar las reglas de firewall de IPsec, que a menudo requieren excepciones del protocolo ESP e IKE en UDP 500 y 4500. Recomendaciones de implementación y errores comunes. Hablemos de lo que realmente sale mal en las implementaciones de RadSec, porque hay algunos modos de falla constantes que veo en las organizaciones. El primer problema y el más común son las fallas en la validación de la cadena de certificados. Su dispositivo NAS debe confiar en la CA que firmó el certificado del servidor RADIUS. Si utiliza un proveedor de RADIUS en la nube con un certificado de una CA pública reconocida —DigiCert, Let's Encrypt, Sectigo— la mayoría de los dispositivos NAS modernos confiarán en él de forma predeterminada. Pero si utiliza una CA interna, debe enviar el certificado de la CA a cada dispositivo NAS. Esto a menudo se pasa por alto durante la implementación inicial y se manifiesta como fallas en el saludo TLS que parecen problemas de conectividad. El segundo error común es la expiración del certificado. A diferencia de los secretos compartidos, que no expiran, los certificados tienen un período de validez definido. Si el certificado de su servidor RADIUS expira, todos los dispositivos NAS de su propiedad fallarán al autenticarse simultáneamente. Necesita una gestión del ciclo de vida de los certificados: renovación automatizada donde sea posible y monitoreo con alertas mucho antes de la expiración. Un aviso de noventa días es el mínimo; treinta días es mejor. El tercer problema es la compatibilidad de los dispositivos NAS. No todos los dispositivos NAS soportan RadSec de forma nativa. Las versiones anteriores de Cisco IOS, algunos controladores heredados de Aruba y ciertos puntos de acceso de nivel de consumo no cuentan con soporte para RadSec. Antes de comprometerse con un despliegue de RadSec, realice una auditoría de su parque de NAS para verificar la compatibilidad. Cisco IOS-XE 16.x y versiones posteriores, Aruba AOS-CX, Ruckus SmartZone y la serie Juniper EX tienen un soporte sólido para RadSec. Para los dispositivos que no soportan RadSec de forma nativa, un proxy RadSec (una opción de código abierto como radsecproxy) puede cerrar la brecha, aceptando UDP RADIUS de los dispositivos heredados y reenviándolo a través de TLS al servidor RADIUS en la nube. La cuarta consideración es la persistencia de la conexión y los keepalives. RadSec utiliza conexiones TCP persistentes, pero los firewalls y los dispositivos NAT con políticas de tiempo de espera agresivas pueden interrumpir silenciosamente las conexiones inactivas. Configure los keepalives de TCP en sus conexiones RadSec; por lo general, un intervalo de keepalive de sesenta segundos es suficiente para evitar la interrupción prematura de la conexión. La mayoría de las implementaciones de servidores RADIUS y dispositivos NAS soportan esta configuración. Para Cisco IOS-XE, la configuración de RadSec se ve así. Se define un servidor RADIUS con la dirección de su endpoint de RADIUS en la nube, se especifica TLS como transporte, se hace referencia a su trustpoint (que es el almacén de certificados en el dispositivo) y se establece el puerto de destino en 2083. Luego, se hace referencia a este servidor en la configuración de su grupo de servidores AAA. Los detalles específicos varían según la versión de la plataforma, pero la estructura lógica es consistente entre los diferentes proveedores. Para los controladores de Aruba que ejecutan AOS, se configura el servidor RADIUS con la opción RadSec habilitada, se especifica el certificado CA para la validación del servidor y, opcionalmente, se configura un certificado de cliente para TLS mutuo. La implementación de Aruba es madura y está bien documentada. Preguntas y respuestas rápidas. Permítame repasar las preguntas que me hacen con más frecuencia sobre RadSec. ¿RadSec añade latencia? El handshake de TLS añade una pequeña sobrecarga en el establecimiento inicial de la conexión, normalmente de menos de 100 milisegundos. Una vez establecida la conexión, la sobrecarga por paquete es insignificante. Para la autenticación 802.1X, donde el handshake ocurre una vez por sesión, esto no representa una preocupación significativa. ¿Puedo ejecutar RadSec junto con el RADIUS UDP tradicional? Sí. La mayoría de los servidores RADIUS soportan ambos simultáneamente. Durante una migración, puede ejecutar RadSec para los sitios que lo soporten y recurrir a UDP para los sitios heredados. Este es el enfoque de migración recomendado. ¿Se requiere RadSec para el cumplimiento de PCI DSS? La versión 4.0 de PCI DSS exige que el tráfico de autenticación esté protegido en tránsito. RadSec es una de las formas más directas de cumplir con este requisito para la autenticación basada en RADIUS. Si procesa pagos con tarjeta a través de una red que utiliza autenticación RADIUS, RadSec debería estar en su plan de cumplimiento. ¿Funciona RadSec con EAP? Sí. EAP (Extensible Authentication Protocol) se encapsula dentro de RADIUS, por lo que EAP-TLS, PEAP y EAP-TTLS funcionan de manera transparente sobre RadSec. El intercambio de EAP en sí no se ve afectado. ¿Qué pasa con la contabilidad de RADIUS? RFC 6614 cubre tanto el tráfico de autenticación como el de contabilidad. Sus datos de contabilidad (registros de inicio, parada y actualizaciones provisionales de sesión) también se cifran a través de la misma conexión TLS en el puerto 2083. Resumen y próximos pasos. En resumen: RadSec es la capa de transporte adecuada para RADIUS en cualquier implementación donde el tráfico de autenticación cruce infraestructura que usted no controla por completo. Eso significa RADIUS en la nube, implementaciones multisitio, entornos SD-WAN y cualquier escenario donde el tráfico de RADIUS atraviese el internet público o la infraestructura de un operador compartido. Las acciones clave para su equipo son: primero, auditar su infraestructura de NAS para verificar la compatibilidad con RadSec e identificar cualquier dispositivo que requiera un proxy. Segundo, contactar a su proveedor de RADIUS en la nube (o evaluar proveedores que admitan RadSec de forma nativa) y comprender su enfoque de gestión de certificados. Tercero, establecer un proceso de gestión del ciclo de vida de los certificados antes de la puesta en marcha. Cuarto, actualizar las reglas de su firewall para permitir TCP 2083 saliente desde su red de gestión de NAS. Quinto, probar su configuración de RadSec en un entorno de pruebas antes de implementarla en producción, prestando especial atención a la validación de la cadena de certificados y a la persistencia de la conexión bajo carga. Para las organizaciones que ejecutan la plataforma de Purple para WiFi de invitados y autenticación en sedes distribuidas, RadSec es el transporte recomendado para la conectividad de RADIUS en la nube. Se alinea con la arquitectura nativa de la nube de Purple y garantiza que los datos de autenticación que fluyen entre sus sedes y la plataforma estén completamente protegidos, lo cual es fundamental tanto para su postura de seguridad como para sus obligaciones de cumplimiento bajo GDPR y PCI DSS. Si está planeando una implementación o desea analizar su arquitectura específica, el equipo de Purple es el punto de partida adecuado. Este ha sido un informe técnico de Purple sobre RadSec. Gracias por su atención.