RADIO

El usuario o la máquina envía una solicitud a un servidor de acceso a la red (NAS) para obtener acceso a un recurso de red específico mediante credenciales de acceso. Estas credenciales se transmiten 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, generalmente 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 de conexión física del usuario al NAS.

El servidor RADIUS verifica la exactitud de la información mediante esquemas de autenticación como PAP , CHAP o EAP . Se comprueba la identificación del usuario y, opcionalmente, otra información relacionada con la solicitud, como su dirección de red o número de teléfono, el estado de su cuenta y sus privilegios de acceso a servicios de red específicos. Tradicionalmente, los servidores RADIUS cotejaban la información del usuario con una base de datos local de archivo plano. Los servidores RADIUS modernos pueden realizar esta comprobación o consultar fuentes externas —generalmente servidores SQL , Kerberos , LDAP o Active Directory— para verificar las credenciales del usuario.

El servidor RADIUS devuelve entonces una de tres respuestas al NAS: 1) Acceso rechazado, 2) Acceso solicitado o 3) Acceso aceptado.

Rechazar acceso

Se deniega incondicionalmente al usuario el acceso a todos los recursos de red solicitados. Entre los motivos se incluyen la falta de presentación de una prueba de identificación o una cuenta de usuario desconocida o inactiva.

Desafío de acceso

Solicita información adicional al usuario, como una contraseña secundaria, PIN, token o tarjeta. El desafío de acceso también se utiliza en diálogos de autenticación más complejos, donde se establece un túnel seguro entre el equipo del usuario y el servidor Radius, de manera que las credenciales de acceso queden ocultas para el NAS.

Acceder Aceptar

Se concede acceso al usuario. Una vez autenticado, el servidor RADIUS suele comprobar que el usuario está autorizado a utilizar el servicio de red solicitado. Por ejemplo, un usuario puede tener permiso para usar la red inalámbrica de la empresa, pero no su servicio VPN. Esta información puede almacenarse localmente en el servidor RADIUS o consultarse en una fuente externa como LDAP o Active Directory.

Cada una de estas tres respuestas RADIUS puede incluir un atributo Reply-Message que puede indicar el motivo del rechazo, la solicitud de confirmación o un mensaje de bienvenida en caso de aceptación. El texto de este atributo se puede mostrar al usuario en una página web de respuesta.

Los atributos de autorización se transmiten al NAS, estipulando los términos de acceso que se otorgarán. Por ejemplo, los siguientes atributos de autorización pueden incluirse en un Access-Accept:

• La dirección IP específica que se asignará al usuario.
• El grupo de direcciones del que se debe elegir la dirección IP del usuario.
• El tiempo máximo que el usuario puede permanecer conectado
• Una lista de acceso, cola de prioridad u otras restricciones en el acceso de un usuario.
• Parámetros L2TP
• Parámetros de VLAN
• Parámetros de calidad de servicio (QoS)

Cuando un cliente está configurado para usar RADIUS, cualquier usuario del cliente debe proporcionarle información de autenticación. Esto puede hacerse mediante una solicitud de inicio de sesión personalizable, donde se espera que el usuario ingrese su nombre de usuario y contraseña. Alternativamente, el usuario puede usar un protocolo de enmarcado de enlace, como el Protocolo Punto a Punto (PPP), que incluye paquetes de autenticación que contienen esta información.

Una vez que el cliente obtiene dicha información, puede optar por autenticarse mediante RADIUS. Para ello, crea una solicitud de acceso que contiene atributos como el nombre de usuario, la contraseña, el ID del cliente y el ID del puerto al que accede el usuario. Si se incluye una contraseña, esta se oculta mediante un método basado en el algoritmo de resumen de mensajes RSA MD5.

La contabilidad se describe en el RFC 2866.

Cuando el NAS otorga acceso a la red al usuario , envía un registro de 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 del usuario a la red. Los registros "Start" suelen contener 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 informarle sobre el estado de una sesión activa. Los registros "provisionales" suelen indicar 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 final de parada de contabilidad (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 Accounting-Request hasta que recibe una confirmación Accounting-Response, utilizando un intervalo de reintento determinado.

El objetivo principal de estos datos es que se pueda facturar al usuario en consecuencia; además, los datos se utilizan habitualmente con fines estadísticos y para la monitorización general de la red.

Un dominio se suele añadir al nombre de usuario y se delimita con el símbolo '@', de forma similar a un dominio de correo electrónico. Esto se conoce como notación posfija para el dominio. Otra forma común de uso es la notación prefija , que consiste en anteponer el dominio al nombre de usuario y usar la barra invertida ('\') como delimitador. Los servidores RADIUS modernos permiten usar cualquier carácter como delimitador de dominio, aunque en la práctica se suelen usar '@' y '\'.

Los dominios también pueden combinarse utilizando notación de prefijo y sufijo, para permitir escenarios de itinerancia complejos; por ejemplo, somedomain.com\username@anotherdomain.com podría ser un nombre de usuario válido con dos dominios.

Aunque los reinos suelen parecerse a los dominios, son textos arbitrarios y no necesariamente contienen nombres de dominio reales. Los formatos de reino están estandarizados en la RFC 4282, que define un Identificador de Acceso a la Red (NAI) con el formato «usuario@reino». En dicha especificación, la parte «reino» debe ser un nombre de dominio. Sin embargo, esta práctica no siempre se sigue. La RFC 7542 ^{[ 6 ]} reemplazó a la RFC 4282 en mayo de 2015.

Cuando un servidor RADIUS recibe una solicitud AAA para un nombre de usuario que contiene un dominio, consulta una tabla de dominios configurados. Si el dominio es conocido, el servidor reenvía la solicitud al servidor principal 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 puede configurarse para agregar, eliminar o reescribir las solicitudes AAA cuando se reenvían a través del proxy en el futuro.

El encadenamiento de proxies es posible en RADIUS, y los paquetes de autenticación, autorización y contabilidad suelen enrutarse 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 proxies incluyen mejoras en la escalabilidad, implementaciones de políticas y ajustes de capacidades. Sin embargo, en escenarios de itinerancia, el NAS, los proxies y el servidor doméstico suelen ser administrados por diferentes entidades administrativas. Por lo tanto, el factor de confianza entre los proxies cobra mayor importancia en este tipo de aplicaciones entre dominios. Además, la ausencia de seguridad de extremo a extremo en RADIUS aumenta la criticidad de la confianza entre los proxies involucrados. Las cadenas de proxies se explican en el RFC 2607 .

El uso de RADIUS para la itinerancia expone a los usuarios a diversos problemas de seguridad y privacidad. En general, algunos proveedores de servicios de itinerancia establecen un túnel seguro entre los servidores RADIUS para garantizar que las credenciales de los usuarios no puedan ser interceptadas durante la conexión a través de internet. Esto resulta preocupante, ya que el algoritmo hash MD5 integrado en RADIUS se considera inseguro. ^{[ 7 ]}

Los pares atributo-valor (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.