Radius

Antes de hablar del Radius en sí mismo resulta conveniente introducir el marco AAA al lector, que implica una serie de conceptos básicos de los que se encarga el protocolo que nos ocupa. AAA son las siglas de Authentication, Authorization y Accounting, los tres aspectos de los que se ocupa la arquitectura:

Autenticación:

es el proceso de verificar si la identidad de una persona o una máquina es efectivamente la que declara. Busca establecer una relación de confianza entre los interlocutores. Cuando hablamos de autenticar usuarios el primer ejemplo que se nos viene a la cabeza es el del nombre de usuario y la contraseña, aunque no todo es tan simple. Infraestructuras tan completas como los certificados digitales son soluciones más actuales y complejas al problema de la autenticación.

Autorización:

involucra la utilización de reglas y plantillas para decidir si un usuario previamente autenticado goza de privilegios suficientes para acceder o no a un recurso. Por ejemplo, los permisos en un sistema de ficheros que determinan si un usuario puede leer, escribir o incluso ejecutar un archivo.

Cuentas:

entorno a la arquitectura AAA se encuentran las cuentas de usuario, que miden y documentan los recursos que un usuario utiliza durante su acceso. Por ejemplo, en un sistema UNIX es frecuente limitar a sus usuarios el número de procesos que pueden ejecutar concurrentemente, o la cantidad de CPU a utilizar.

Centrándonos en el aspecto que nos interesa de la arquitectura AAA, la autenticación se puede realizar siguiendo diversos esquemas:

Secuencia de agente:

en esta secuencia, el servidor AAA actúa como delegado entre el equipamiento que presta el servicio^1.26 y el usuario final. El usuario contacta inicialmente con el servidor AAA, quien autoriza su petición y notifica al equipamiento de su decisión para que se le preste el servicio al usuario. El equipamiento del servicio notifica al servidor AAA cuando ha cumplido su petición, y el mismo servidor AAA notifica en última instancia al usuario.

Secuencia de tiro o pull:

la más frecuente en servicios dial (de marcación telefónica) tradicionales. El usuario realiza la petición directamente al NAS y éste comprueba con el servidor AAA si debe proporcionar acceso.

Secuencia de empuje o push:

esta secuencia, por contra, hace que el usuario pida algún tipo de certificación al servidor AAA, la cual deberá presentar más tarde al equipamiento que presta el servicio para garantizar su identidad y acceso al mismo.

La primera intuición hace pensar en usuarios, equipamientos y servidores de autenticación dentro de una misma red corporativa. El hecho es que esto no tiene por qué ser así en absoluto, y es muy común encontrar escenarios en los que existe la distinción entre empresa que contrata al cliente, y empresa que provee el acceso al servicio. Un ejemplo claro son los actuales proveedores de acceso a Internet en España, que suelen utilizar las infraestructuras propiedad de Telefónica para dar acceso al servicio a sus propios usuarios. El dueño de la infraestructura que llega al usuario tiene algún tipo de acuerdo con el prestador del servicio final de forma que el equipamiento del primero ha de ponerse en contacto con los servidores de autenticación del segundo. Este ejemplo ilustra muy por encima el concepto de roaming.

Radius es una implementación concreta de la arquitectura AAA, descrito en [8] con sumo detalle. Se encuentra ampliamente extendido al ser el primer protocolo de su tipo (de hecho, la especificación de Radius es previa al modelo AAA). Provee servicios de autenticación, autorización y cuentas de usuarios de forma genérica y completamente personalizable, y utiliza un esquema de autorización de secuencia pull, descrito ya previamente.

Pero como protocolo ya con bastantes años a sus espaldas tiene severas deficiencias que lo hacen cada día más reemplazable. Utiliza MD5 como algoritmo de dispersión para almacenar contraseñas, algoritmo que por otra parte se ha demostrado inseguro hace apenas unos meses. Tiene graves problemas de escalabilidad, admitidos ya en su propia RFC. Al estar basado en UDP y no implementar el concepto de conexión, no permite llevar ningún tipo de control sobre el uso de un servicio una vez el usuario ha sido autenticado.

Adicionalmente, Radius es un protocolo salto a salto^1.27, lo que quiere decir que cada servidor Radius en la cadena de autenticación tiene acceso a los datos de autenticación del usuario. Este modelo de seguridad puede parecer suficiente cuando se utilizan escenarios simples en los que no existe el concepto de roaming, pero la realidad es que por lo general las cadenas de autenticación son largas e implican diversos servidores de distintas empresas. En estas circunstancias, el modelo salto a salto es claramente inseguro.

Radius se sirve de identificadores conocidos como realms^1.28 para distinguir a los usuarios por tipos y saber en todo momento quién debe autenticarlos. Los realms pueden encontrarse en forma de sufijo o prefijo junto al nombre de usuario, separados por caracteres definibles, típicamente barras o arrobas. De esta forma un servidor Radius puede extraer patrones en los nombres de los usuarios en los que basarse a la hora de autenticar a un usuario. Por ejemplo, un servidor de la compañía Telefónica al que le llegue una petición de autenticación con un realm del tipo usuario@telefonica.net sabrá que para autenticar a ese usuario debe consultar, por ejemplo, una base de datos local. Por contra, si recibe un realm del tipo usuario@urjc.es sabrá inmediatamente que debe redireccionar la petición a uno de los servidores de autenticación de la Universidad Rey Juan Carlos que tenga configurados. Esta es la base conceptual que permite a Radius implementar esquemas complejos de roaming.

Para información más detallada sobre este extenso protocolo sin duda conviene consultar su RFC [8]. [13] presenta además una excelente explicación de la arquitectura AAA en su conjunto y de una implementación concreta de Radius: FreeRadius.