El servicio de autenticación remota telefónica de usuario ( RADIUS ) es un protocolo de red que proporciona administración centralizada de autenticación, autorización y contabilidad ( AAA ) para los usuarios que se conectan y utilizan un servicio de red. RADIUS fue desarrollado por Livingston Enterprises en 1991 como un protocolo de autenticación y contabilidad de servidor de acceso. Más tarde se incorporó a los estándares IEEE 802 e IETF .
RADIUS es un protocolo cliente/servidor que se ejecuta en la capa de aplicación y puede utilizar TCP o UDP . Los servidores de acceso a la red , que controlan el acceso a una red, suelen contener un componente cliente RADIUS que se comunica con el servidor RADIUS. [1] RADIUS suele ser el back-end de elección para la autenticación 802.1X . [2] Un servidor RADIUS suele ser un proceso en segundo plano que se ejecuta en UNIX o Microsoft Windows . [1]
El ataque Blast-RADIUS rompe RADIUS cuando se ejecuta en un protocolo de transporte no cifrado como UDP. [3]
RADIUS es un protocolo AAA (autenticación, autorización y contabilidad) que administra el acceso a la red. RADIUS utiliza dos tipos de paquetes para administrar todo el proceso AAA: solicitud de acceso, que administra la autenticación y la autorización, y solicitud de contabilidad, que administra la contabilidad. La autenticación y la autorización se definen en RFC 2865, mientras que la contabilidad se describe en RFC 2866.
El usuario o la máquina envían una solicitud a un servidor de acceso a la red (NAS) para obtener acceso a un recurso de red en particular mediante credenciales de acceso. Las credenciales se pasan al dispositivo NAS a través del protocolo de capa de enlace , por ejemplo, el protocolo punto a punto (PPP) en el caso de muchos proveedores de acceso telefónico o DSL , o se publican en un formulario web seguro HTTPS .
A su vez, el NAS envía un mensaje de solicitud de acceso RADIUS al servidor RADIUS, solicitando autorización para otorgar acceso a través del protocolo RADIUS. [4]
Esta solicitud incluye credenciales de acceso, normalmente en forma de nombre de usuario y contraseña o certificado de seguridad proporcionado por el usuario. Además, la solicitud puede contener otra información que el NAS conoce sobre el usuario, como su dirección de red o número de teléfono, e información sobre el punto físico de conexión del usuario al NAS.
El servidor RADIUS comprueba que la información sea correcta mediante esquemas de autenticación como PAP , CHAP o EAP . Se verifica la prueba de identificación del usuario, junto con, opcionalmente, otra información relacionada con la solicitud, como la dirección de red o el número de teléfono del usuario, el estado de la cuenta y los privilegios de acceso a servicios de red específicos. Históricamente, los servidores RADIUS verificaban la información del usuario con una base de datos de archivos planos almacenada localmente. Los servidores RADIUS modernos pueden hacer esto o pueden hacer referencia a fuentes externas (comúnmente SQL , Kerberos , LDAP o servidores de Active Directory ) para verificar las credenciales del usuario.
Luego, el servidor RADIUS devuelve una de tres respuestas al NAS: 1) Rechazo de acceso, 2) Desafío de acceso o 3) Aceptación de acceso.
Cada una de estas tres respuestas RADIUS puede incluir un atributo de mensaje de respuesta que puede indicar el motivo del rechazo, el mensaje para el desafío o un mensaje de bienvenida para la aceptación. El texto del atributo se puede pasar al usuario en una página web de retorno.
Los atributos de autorización se transmiten al NAS y estipulan los términos del acceso que se concederá. Por ejemplo, los siguientes atributos de autorización pueden incluirse en una aceptación de acceso:
Cuando un cliente está configurado para utilizar RADIUS, cualquier usuario del cliente presenta información de autenticación al cliente. Esto puede ser mediante un mensaje de inicio de sesión personalizable, donde se espera que el usuario ingrese su nombre de usuario y contraseña. Como alternativa, el usuario puede utilizar un protocolo de enmarcado de enlaces, como el Protocolo punto a punto (PPP), que tiene paquetes de autenticación que transportan esta información.
Una vez que el cliente ha obtenido dicha información, puede optar por autenticarse mediante RADIUS. Para ello, el cliente crea una "Solicitud de acceso" que contiene atributos como el nombre del usuario, la contraseña del usuario, el ID del cliente y el ID del puerto al que accede el usuario. Cuando hay una contraseña, se oculta mediante un método basado en el algoritmo RSA Message Digest MD5.
La contabilidad se describe en RFC 2866.
Cuando el NAS concede acceso a la red al usuario , el NAS envía un inicio de contabilidad (un paquete de solicitud de contabilidad RADIUS que contiene un atributo Acct-Status-Type con el valor "start") al servidor RADIUS para indicar el inicio del acceso a la red del usuario. Los registros de "inicio" normalmente contienen la identificación del usuario, la dirección de red, el punto de conexión y un identificador de sesión único. [5]
Periódicamente, el NAS puede enviar registros de actualización provisional (un paquete de solicitud de contabilidad RADIUS que contiene un atributo Acct-Status-Type con el valor "interim-update") al servidor RADIUS para actualizarlo sobre el estado de una sesión activa. Los registros "provisionales" normalmente transmiten la duración de la sesión actual e información sobre el uso actual de los datos.
Finalmente, cuando se cierra el acceso a la red del usuario, el NAS emite un registro de detención de contabilidad final (un paquete de solicitud de contabilidad RADIUS que contiene un atributo Acct-Status-Type con el valor "stop") al servidor RADIUS, proporcionando información sobre el uso final en términos de tiempo, paquetes transferidos, datos transferidos, motivo de la desconexión y otra información relacionada con el acceso a la red del usuario.
Normalmente, el cliente envía paquetes de solicitud de contabilidad hasta que recibe un acuse de recibo de respuesta de contabilidad, utilizando un intervalo de reintento.
El objetivo principal de estos datos es poder facturar al usuario en consecuencia; los datos también se utilizan habitualmente para fines estadísticos y para la monitorización general de la red.
RADIUS se utiliza comúnmente para facilitar el roaming entre ISP , incluso mediante:
RADIUS facilita esto mediante el uso de reinos , que identifican dónde el servidor RADIUS debe reenviar las solicitudes AAA para su procesamiento.
Un dominio se suele añadir al nombre de usuario de un usuario y se delimita con un signo "@", similar al nombre de dominio de una dirección de correo electrónico. Esto se conoce como notación de sufijo para el dominio. Otro uso común es la notación de prefijo , que implica anteponer el dominio al nombre de usuario y usar "\" como delimitador. Los servidores RADIUS modernos permiten utilizar cualquier carácter como delimitador de dominio, aunque en la práctica se suelen utilizar "@" y "\".
Los reinos también se pueden componer utilizando notación de prefijo y sufijo, para permitir escenarios de itinerancia complicados; por ejemplo, somedomain.com\[email protected] podría ser un nombre de usuario válido con dos reinos.
Aunque los dominios suelen parecerse a los reinos, es importante señalar que, de hecho, los reinos son texto arbitrario y no necesitan contener nombres de dominio reales. Los formatos de los reinos están estandarizados en RFC 4282, que define un identificador de acceso a la red (NAI) en la forma 'usuario@reino'. En esa especificación, se requiere que la parte 'reino' sea un nombre de dominio. Sin embargo, esta práctica no siempre se sigue. RFC 7542 [6] reemplazó a RFC 4282 en mayo de 2015.
Cuando un servidor RADIUS recibe una solicitud AAA para un nombre de usuario que contiene un dominio, el servidor hará referencia a una tabla de dominios configurados. Si se conoce el dominio, el servidor enviará la solicitud mediante proxy al servidor local configurado para ese dominio. El comportamiento del servidor proxy con respecto a la eliminación del dominio de la solicitud ("eliminación") depende de la configuración en la mayoría de los servidores. Además, el servidor proxy se puede configurar para agregar, eliminar o reescribir solicitudes AAA cuando se envían mediante proxy nuevamente con el tiempo.
El encadenamiento de proxy es posible en RADIUS y los paquetes de autenticación/autorización y contabilidad generalmente se enrutan entre un dispositivo NAS y un servidor doméstico a través de una serie de proxies. Algunas de las ventajas de usar cadenas de proxy incluyen mejoras de escalabilidad, implementaciones de políticas y ajustes de capacidad. Pero en escenarios de roaming, el NAS, los proxies y el servidor doméstico podrían ser administrados típicamente por diferentes entidades administrativas. Por lo tanto, el factor de confianza entre los proxies adquiere mayor importancia en tales aplicaciones entre dominios. Además, la ausencia de seguridad de extremo a extremo en RADIUS se suma a la criticidad de la confianza entre los proxies involucrados. Las cadenas de proxy se explican en RFC 2607.
El roaming con RADIUS expone a los usuarios a diversos problemas de seguridad y privacidad. En términos más generales, algunos socios de roaming establecen un túnel seguro entre los servidores RADIUS para garantizar que las credenciales de los usuarios no puedan ser interceptadas mientras se transmiten a través de Internet. Esto es un problema, ya que el hash MD5 integrado en RADIUS se considera inseguro. [7]
RADIUS se transporta a través de UDP/IP en los puertos 1812 y 1813. [8]
A la derecha se muestra el formato de datos del paquete RADIUS . Los campos se transmiten de izquierda a derecha, comenzando por el código, el identificador, la longitud, el autenticador y los atributos.
Los códigos RADIUS asignados (decimales) incluyen los siguientes: [9]
El campo Identificador ayuda a hacer coincidir solicitudes y respuestas.
El campo Longitud indica la longitud de todo el paquete RADIUS, incluidos los campos Código, Identificador, Longitud, Autenticador y Atributo opcional.
El autenticador se utiliza para autenticar la respuesta del servidor RADIUS y se utiliza para cifrar contraseñas; su longitud es de 16 bytes.
Los pares de valores de atributos (AVP) de RADIUS contienen datos tanto en la solicitud como en la respuesta para las transacciones de autenticación, autorización y contabilidad. La longitud del paquete RADIUS se utiliza para determinar el final de los AVP.
RADIUS es extensible; muchos proveedores de hardware y software RADIUS implementan sus propias variantes utilizando atributos específicos del proveedor (VSA). Microsoft ha publicado algunos de sus VSA. [10] Las definiciones de VSA de muchas otras empresas siguen siendo exclusivas y/o ad hoc, no obstante, se pueden encontrar muchos diccionarios VSA descargando el código fuente de las implementaciones RADIUS de código abierto, por ejemplo, FreeRADIUS .
La sección 5.26 del RFC 2865 proporciona una codificación sugerida que la mayoría de los proveedores siguen:
Algunos proveedores utilizan formatos diferentes. Por ejemplo, algunos proveedores omiten el campo "Longitud del proveedor" o utilizan 2 octetos para los campos "Tipo de proveedor" o "Longitud del proveedor".
La Sección 3.14 del RFC 8044 define el tipo de datos "vsa" que exige el formato de la Sección 5.26 del RFC 2865.
El protocolo RADIUS transmite contraseñas ofuscadas utilizando un secreto compartido y el algoritmo de hash MD5 . Como esta implementación particular proporciona solo una protección débil de las credenciales del usuario, [11] se debe utilizar protección adicional, como túneles IPsec o redes de centros de datos físicamente seguras, para proteger aún más el tráfico RADIUS entre el dispositivo NAS y el servidor RADIUS. Además, las credenciales de seguridad del usuario son la única parte protegida por el propio RADIUS, aunque otros atributos específicos del usuario, como las identificaciones de grupos de túneles o las membresías de VLAN transmitidas a través de RADIUS, también pueden considerarse información confidencial (útil para un atacante) o privada (suficiente para identificar al cliente individual). [ cita requerida ] .
El protocolo RadSec soluciona el problema de la seguridad RADIUS/UDP heredada "envolviendo" el protocolo RADIUS en TLS . Sin embargo, los paquetes dentro del transporte TLS aún utilizan MD5 para las comprobaciones de integridad de los paquetes y para ofuscar el contenido de ciertos atributos.
El ataque Blast-RADIUS rompe el protocolo RADIUS cuando se transporta mediante UDP simple al atacar MD5 dentro de RADIUS. [3] RadSec bloquea este ataque. [3] Otra mitigación recomendada es requerir atributos Message-Authenticator para todas las solicitudes y respuestas. [3] Se ha asignado CVE - 2024-3596 para el ataque Blast-RADIUS.
En 1991, a medida que más clientes de acceso telefónico utilizaban NSFNET , Merit Network envió una solicitud de propuestas para consolidar sus diversos sistemas propietarios de autenticación, autorización y contabilidad. Entre los primeros que respondieron se encontraba Livingston Enterprises y, tras una reunión, se escribió una versión preliminar de RADIUS. El primer servidor RADIUS se instaló en un sistema operativo UNIX . Livingston Enterprises fue adquirida por Lucent Technologies y, junto con Merit, se tomaron medidas para lograr la aceptación de RADIUS como protocolo en la industria. Ambas empresas ofrecieron un servidor RADIUS sin cargo. [12] En 1997, RADIUS se publicó como RFC 2058 y RFC 2059; las versiones actuales son RFC 2865 y RFC 2866. [13]
El estándar RADIUS original especificaba que RADIUS no tiene estado y debe ejecutarse sobre el Protocolo de datagramas de usuario (UDP). Para la autenticación, se previó que RADIUS debería soportar el Protocolo de autenticación de contraseña (PAP) y el Protocolo de autenticación por desafío mutuo (CHAP) sobre el Protocolo punto a punto . Las contraseñas se ocultan tomando el hash MD5 del paquete y un secreto compartido, y luego se realiza una operación XOR con ese hash y la contraseña. El RADIUS original también proporcionaba más de 50 pares de atributos y valores, con la posibilidad de que los proveedores configuraran sus propios pares. [14]
La elección del modelo de seguridad salto a salto, en lugar del cifrado de extremo a extremo , significó que si se utilizan varios servidores proxy RADIUS, cada servidor debe examinar, ejecutar lógica y transmitir todos los datos en una solicitud. Esto expone datos como contraseñas y certificados en cada salto. Los servidores RADIUS tampoco tenían la capacidad de detener el acceso a los recursos una vez que se había emitido una autorización. Los estándares posteriores, como RFC 3576 y su sucesor RFC 5176, permitieron que los servidores RADIUS cambiaran dinámicamente la autorización de un usuario o desconectaran a un usuario por completo. [15]
Actualmente existen varios servidores RADIUS comerciales y de código abierto. Las características pueden variar, pero la mayoría puede buscar usuarios en archivos de texto, servidores LDAP , diversas bases de datos, etc. Los registros de contabilidad se pueden escribir en archivos de texto, diversas bases de datos, reenviar a servidores externos, etc. SNMP se utiliza a menudo para la supervisión remota y la comprobación de la actividad de un servidor RADIUS. Los servidores proxy RADIUS se utilizan para la administración centralizada y pueden reescribir paquetes RADIUS sobre la marcha por razones de seguridad o para convertir entre dialectos de proveedores.
El protocolo Diameter fue pensado como reemplazo de RADIUS. Si bien ambos son protocolos de autenticación, autorización y contabilidad (AAA), los casos de uso para los dos protocolos han divergido desde entonces. Diameter se utiliza principalmente en el espacio 3G . RADIUS se utiliza en otros lugares. Una de las mayores barreras para que Diameter reemplace a RADIUS es que los conmutadores y puntos de acceso generalmente implementan RADIUS, pero no Diameter. Diameter usa SCTP o TCP , mientras que RADIUS generalmente usa UDP como capa de transporte . A partir de 2012, RADIUS también puede usar TCP como capa de transporte con TLS para seguridad.
El protocolo RADIUS está definido actualmente en los siguientes documentos RFC de IETF .