¿Qué es el protocolo RADIUS? Características y fases de autenticación

A la pregunta, ¿qué es RADIUS? (Remote Authentication Dial-In User Service) podríamos definirlo como un anciano protocolo de autenticación, autorización y auditoría que se diseñó a partir de una necesidad concreta: controlar y garantizar el acceso a recursos de computación heterogéneos.

En un tiempo en que Merit Networks -una empresa fundacional de lo que es internet tal como lo conocemos- operaba acceso a internet vía modem en EEUU (California), la autenticación de los diferentes aparatos de acceso se realizaba de formas diferentes, según marcas, lo que originaba mucho trabajo y sobrecarga.

Era necesario contar con un protocolo que se adaptase a los sistemas propietarios para ofrecer flexibilidad y compatibilidad, algo que en lo que colaboró en primer momento la empresa Livingston Enterprises.

RADIUS se sustenta sobre varios RFCs elaborados por ambas empresas: 2865, 2866 y 3579 que además actualmente ofrecen una implementación de servidor radius sin coste.

Características de RADIUS

Los actuales servicios destinados a AAA (Authentication, Authorization & Accounting) tienen mucho que ver con RADIUS porque persiguen objetivos similares, aunque este último es mucho más antiguo, ya que data del año 2000 al 2003.

El paradigma actual de control de accesos (AAA) está avanzando, mientras RADIUS está comenzando su lento pero inexorable declive, a pesar de ser todavía ubicuo durante mucho tiempo, gracias a su compatibilidad.

Propiedades

Según sus diferentes RFC, establecemos que:

• Protocolo no orientado a conexión, que usa UDP y no emplea conexiones directas
• El modelo de seguridad es punto-a-punto
• Es stateless (no es consciente del estado de la conexión)
• Soporta mecanismos de autenticación PAP (Password Authentication Protocol) y CHAP (Challenge Handshake Authentication Protocol) mediante PPP
• Usa MD5 para ocultar las credenciales transferidas
• Proporciona unos 50 atributos/valores diferentes, con la opción de definir otros específicos de cada proveedor
• Implementa el modelo autenticación-autorización-auditoría

Además, RADIUS está soportado por absolutamente cualquier producto de tipo NA (Network Access Server), lo que asegura un largo futuro para él. Incluyendo, por ejemplo, servicios de autenticación fuerte o 2FA.

Este protocolo tiene también sus limitaciones. No soporta el acceso condicional o de-autenticación por sí mismo (salvo que se implemente a mano). Es stateless, lo que le impide mantener continuidad entre sesiones. Finalmente, su rendimiento tiende a ser malo en entornos muy grandes.

Formatos de paquete y puertos

El protocolo RADIUS emplea paquetes de tipo UDP (por diferentes motivos, uno de ellos que UDP es stateless también) y se comunica en el puerto 1812, suponiendo un cambio respecto al RFC original, que establecía el puerto 1645). Esto se acabó modificando porque interfería con el servicio Datametrics.

Se emplea una estructura predecible de paquetes, basada en dos partes principales:

• Cabecera/header
  • Código
  • Identificador
  • Longitud
  • Autenticador

• Carga/datos
  • Atributos
  • Valores

Ejemplo:

Códigos

La primera parte del encabezado es el octeto Código, que distingue el tipo de mensaje RADIUS que estamos enviando o recibiendo (su propósito).

ID Mensaje	Descripción
1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
12	Status-Server
13	Status-Client
255	Reservado

Identificador

Este apartado es otro octeto que se emplea para realizar el encolado de los mensajes. Es decir, para mantener el orden correcto de la conversación según sean solicitudes, respuestas o challenge-response.

Normalmente, los servidores pueden detectar y descartar mensajes duplicados examinando elementos como direcciones IDP, puertos UDP de origen, marcas temporales o el campo identificador.

Longitud

Este campo ocupa dos octetos y se usa para determinar la longitud de un mensaje RADIUS. Se calcula analizándolos campos código, identificador, longitud, autenticador y atributos para obtener la suma total. Los valores aceptados por el RFC son de entre 20 y 4096 bytes.

Autenticador

Autenticator es una región formada por 16 octetos, siendo el campo donde se inserta el control de integridad correspondiente a la carga o payload, es decir, a los datos principales del mensaje.

Hay dos tipos de valores:

1. Request authenticators se emplea con los paquetes de tipo Access-Request y Accounting-Request. El valor «request» se calcula aleatoriamente para evitar ataques.
2. Response autenticator se mplea con los mensajes de tipo Access-Accept, Access-Request y Access-Challenge. Se obtiene calculando un hash MD5 unidireccional, generado teniendo en cuenta los valores «códig», «identificador», «longitud» y «request-authenticators», seguido por los datos del paquete y el shared secret (secreto compartido)

RADIUS no emplea mecanismos para evitar la escucha del tráfico (como por ejemplo TLS) pero se estima que la aleatorización, unida a contraseñas robustas, hacen difícil descifrar los datos.

Ejemplo:

ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)

Tipos de paquetes RADIUS

Esta sección da para entretenerse un poco hablando de los tipos de paquetes RADIUS, que son básicamente 4: Access-Request, Access-Accept, Access-Reject y Access-Challenge.

Access-Request

Este tip de paquete se usa por parte del consumidor del servicio, cuando solicita un servicio en una red. El cliente envía un paquete «request» al servidor RADIUS junto a un listado del/los servicios requeridos. El campo código (1) es clave aquí, siempre debe tener el valor 1, que es el establecido para este tipo de solicitud.

El payload o datos deberán incluir la dirección IP o CN (nombre canónico) del equipo de red desde el que se solicita el acceso. También deberá incluir una contraseña de usuario, o bien un identificador de estado, pero no ambas cosas.

El RFC especifica que el servidor RADIUS debe enviar una respuesta para cada paquete válido, ya sea autorización o rechazo. También se deben crear nuevos paquetes cada vez que cambie algún atributo, para que haya sincronía.

Los atributos tipo shared secrets (claves pre-compartidas) deberán ser arrastrados de vuelta en la cadena desde el servidor proxy, en caso de utilizar proxy chains de tipo RADIUS.

Access-Accept

El paquete de tipo Access-Accept es enviado por el servidor al cliente, para confirmarle que se le ha concedido acceso. Si se cumplen los requisitos, el servidor RADIUS deberá establecer el código de respuesta (1) como valor 2.

Para garantizar que los paquetes request y accept se corresponden unos con otros (y no a otras solicitudes concurrentes) se verifica el encabezado -header- del paquete, que debe ser similar en los paquetes Access-request y Access-Accept.

Este paquete es muy flexible en cuanto a la cantidad y variedad de propiedades que puede contener. Normalmente se detallan los tipos de servicios que se han autenticado y autorizado, para que el «cliente» se asigne el uso de los mismos.

Access-Reject

Cuando el servidor debe denegar el uso/acceso a recursos, debe formular un paquete como este de vuelta al cliente. El paquete Access-Reject puede darse a causa de políticas de denegación, privilegios insuficientes o credenciales inválidas.

Este paquete puede enviarse en cualquier momento de una sesión, algo que lo hace recomendable para obligar a respetar límites de conexiones.

La carga de datos o «payload» incluye en este caso 2 atributos (oficialmente el RFC no soporte otros):

• Reply-Message
• Proxy-Message

Access-Challenge

El Access-Challenge (reto de acceso) se puede enviar por parte del servidor, tras haberse enviado un paquete RADIUS tipo 1 (recordemos, Access-Request) si este precisa más información o quiere reducir el riesgo de fraude en la transacción.

Si esto pasa, se envía este paquete al cliente pidiéndole más información. Una vez el cliente conteste de nuevo con otro Access-Request correcto (incluyendo la prueba requerida, que podría ser un token), el servidor decide si acepta, rechaza o pide nuevamente más datos.

Igual que sucede con el paquete Access-Reject, existen solamente dos atributos estándar aceptados, aunque se pueden incluir otros personalizados:

• State (estado)
• Reply-Message (mensaje de respuesta)

Es necesario destacar que no todos los clientes soportan el proceso challenge/response como en el modelo. En ciertos casos he encontrado algunos que no soportan estos «desafíos», así que tratan los paquetes Access-Challenge como si fueran Access-Reject o Access-Accept.

Los Shared Secret en una negociación RADIUS

Se utilizan secretos compartidos para mejorar la integridad transaccional y la seguridad de los datos transmitidos. Se trata de valores generados aleatoriamente (o manualmente) que son conocidos por ambos extremos (cliente-sevidor) y se utilizan en cualquier punto de la comunicación que requiera esconder datos.

Normalmente llamados «secretos» sin más, son únicos para cada duo de cliente y servidor RADIUS

Los secretos deben ser, según estipulación técnica, superiores a 0 en longitud (es decir, no ser «null») pero el RFC recomienda usar los 16 octetos disponibles, para que sean virtualmente imposibles de adivinar.

Finalmente, este es el aspecto de una negociación RADIUS exitosa si capturamos trazas con una herramienta como Wireshark.

Espero que el artículo de hoy os haya ayudado a aclarar dudas o aprender un poco más sobre este protocolo de autenticación tan utilizado hoy en día y que, de hecho, tiene bastante que ver con la ciberseguridad.