3.1.1. Protocolos Autenticación.
RADIUS
(Acrónimo
en inglés de Remote Authentication Dial-In User Service). Es un protocolo de
autenticación y autorización para aplicaciones de acceso a la red o movilidad
IP. Utiliza el puerto 1812 UDP para establecer sus conexiones.
El
protocolo de RADIUS fue desarrollado originalmente para su uso con el acceso telefónico
a redes. Aunque todavía es principalmente utilizada para autenticar las cuentas
de dial-up, se ha convertido en una herramienta popular para la autenticación
de otros dispositivos de red. Este crecimiento tiene sentido, ya que muchos
administradores no les gusta la idea de mantener un servidor AAA para routers y
switches, y otro para marcar a los usuarios.
RADIUS
opera en el puerto 1812, el transporte sobre UDP, y se especifica en el RFC
2865. El protocolo original RADIUS incluyó el apoyo para el Punto-to-Point Protocol
(PPP) y el inicio de sesión de Unix, los proveedores han incorporado soporte para
otros tipos de accesos a sus versiones de RADIUS.
La
autenticación RADIUS se maneja mediante el intercambio de claves secretas enviadas
a través de paquetes de texto plano, sin embargo, las contraseñas son encriptadas
utilizando MD5. Dado que se envían los paquetes de RADIUS mediante UDP, existen
varios mecanismos de seguridad a fin de ayudar a garantizar que los datos llegan
a su destino. Un cliente RADIUS puede ser configurado para reenviar las transmisiones
a intervalos predefinidos, hasta que se recibe una respuesta, o puede ser ajustado
a prueba de fallos a un segundo o tercer servidor RADIUS en el caso de un fracaso.
La Figura 3.1 describe el proceso para
el éxito de la autenticación RADIUS.
Fig. 3.2 Proceso de Autentificación de
Radius
El
router tiene software, conocido como un cliente de RADIUS, que interactúa con
el servidor RADIUS cuando intenta autenticar a los usuarios. El servidor RADIUS
podrá remitir la solicitud a otro servidor RADIUS, o hacer una consulta sobre
un Lightweight Directory Access Protocol (LDAP) para autenticar el servidor de
información. En los casos en que el servidor RADIUS autentica contra otro, el
servidor RADIUS actúa como el cliente y envía la solicitud de autenticación en
un formato codificado.
Si
es compatible, el servidor RADIUS puede expedir una nueva solicitud desafío
respuesta de autenticación de usuario. Si ese es el caso, el servidor RADIUS
emitirá un "desafío-acceso" a petición del cliente, que a su vez lo transmite
al usuario. El usuario debe responder con una respuesta adecuada al desafío.
Si
el servidor RADIUS no es capaz de localizar al usuario, o las contraseñas no coinciden,
el servidor RADIUS cuestiona acceso-rechazar, junto con un mensaje de error,
para el cliente, que lo transmite al usuario final. Después del mensaje de
acceso rechazar enviado, es descartado.
Porque
las transacciones de RADIUS se realizan a través de UDP, no hay una confirmación
entre el cliente y el servidor que el éxito de una solicitud se ha hecho hasta que
el servidor responde al cliente. Con el fin de resolver este problema un
paquete de acceso-petición acompaña a cada solicitud a un servidor RADIUS. El
acceso-petición contiene el nombre de usuario y la contraseña del usuario, así
como la identificación del cliente y el puerto cliente al que el usuario está
intentando acceder. El cliente mantiene esta información y contando hacia atrás
y comienza. Si la respuesta no se recibe desde el servidor RADIUS en un
determinado periodo de tiempo, el cliente o bien reenviar la solicitud, o
prueba un servidor RADIUS secundario en función de cómo ha configurado el
cliente el administrador de RADIUS.
La
capacidad para tratar de autentificar los inicios de sesión varias veces contra
el mismo servidor o en contra de varios servidores RADIUS ayuda a hacer un
protocolo robusto que es muy resistente a los problemas de red. De hecho, RADIUS
tiene que ser resistentes, ya que su uso
primario es en el acceso telefónico a redes. Earthlink, MSN, y
AT&T,
todos utilizan RADIUS para la autenticación de acceso telefónico a sus redes.
Ellos
tienen millones de usuarios de marcación en sus redes al mismo tiempo, si RADIUS
no es robusto, estos proveedores experimentaran frecuentes cortes. RADIUS actúa
sobre la capa 7 del modelo OSI, ya que es precisamente en la capa de Aplicación
donde se definen y engloban los protocolos que utilizan las aplicaciones para
el intercambio de datos. El usuario no suele manejar directamente estos
protocolos de intercambio de datos, sino a través de alguna aplicación que a su
vez maneja este lenguaje. En esta capa se incluyen una creciente cantidad de
protocolos que se dedican a muchas y muy diferentes funciones, entre ellos
algunos protocolos de autenticación como RADIUS y Kerberos.
Algunos
servidores de autenticación basados en Radius son:
FreeRADIUS
GNU RADIUS
OpenRADIUS
Cistron RADIUS
BSDRadius
TekRADIUS
WinRADIUS
Cuando se realiza la conexión con un ISP
mediante módem, DSL, cable módem, Ethernet o Wi-Fi, se envía una información
que generalmente es un nombre de usuario y una contraseña. Esta información se
transfiere a un dispositivo Network Access Server (NAS) sobre el protocolo PPP,
quien redirige la petición a un servidor RADIUS sobre el protocolo RADIUS. El
servidor RADIUS comprueba que la información es correcta utilizando esquemas de
autenticación como PAP, CHAP o EAP. Si es aceptado, el servidor autorizará el
acceso al sistema del ISP y le asigna los recursos de red como una dirección
IP, y otros parámetros como L2TP, etc.
Una
de las características más importantes del protocolo RADIUS es su capacidad de
manejar sesiones, notificando cuando comienza y termina una conexión, así que
al usuario se le podrá determinar su consumo y facturar en consecuencia; los
datos se pueden utilizar con propósitos estadísticos.
RADIUS
fue desarrollado originalmente por Livingston Enterprises para la serie
PortMaster de sus Servidores de Acceso a la Red(NAS), más tarde se publicó como
RFC 2138y RFC 2139. Actualmente existen muchos servidores RADIUS, tanto
comerciales como de código abierto. Las prestaciones pueden variar, pero la
mayoría pueden gestionar los usuarios en archivos de texto, servidores LDAP,
bases de datos varias, etc. A menudo se utiliza SNMP para monitorear
remotamente el servicio. Los servidores Proxy RADIUS se utilizan para una
administración centralizada y pueden reescribir paquetes RADIUS al vuelo (por
razones de seguridad, o hacer conversiones entre dialectos de diferentes
fabricantes)....
RADIUS
es extensible; la mayoría de fabricantes de software y hardware RADIUS
implementan sus propios dialectos.
TACACS
(Acrónimo de Terminal Access Controller Access Control System , en inglés ‘sistema de control de
acces TACACS
(acrónimo de Terminal Access Controller Access Control System , en inglés
‘sistema de control de acceso mediante control del acceso desde terminales’) es
un protocolo de autenticación remota, que se usa para comunicarse con un
servidor de autenticación comúnmente usado en redes Unix. TACACS permite a un
servidor de acceso remoto comunicarse con un servidor de autenticación para
determinar si el usuario tiene acceso a la red. TACACS está documentado en el
RFC 1492.
TACACS+ es un protocolo
similar a RADIUS que fue desarrollado por Cisco Systems. TACACS+ se inspira en
dos protocolos depreciados, TACACS y TACACS ampliada (XTACACS), TACACS+ es
incompatible tanto con TACACS y XTACACS. A causa de graves fallas de seguridad
en el TACACS XTACACS y diseños, se recomienda que no se utilicen en favor del
modelo de TACACS+. Mientras que TACACS+ fue desarrollado por Cisco, el pliego
de condiciones del protocolo TACACS+ se ha puesto a disposición del público.
Otros proveedores de redes, incluyendo Extreme Networks y Foundry Networks, han
incorporado TACACS+ en sus productos.
TACACS+, mientras que
realiza la misma función como radio, sus orígenes son diferentes. TACACS + fue
desarrollado originalmente como un protocolo para el control de la AAA para los
dispositivos de red, por lo que la arquitectura es diferente a la de RADIUS,
que fue desarrollado originalmente para el acceso telefónico a redes. TACACS+
opera a través de TCP, en lugar de UDP, y utiliza el puerto 49 por defecto,
aunque TACACS+ se puede configurar para usar cualquier puerto de un
administrador de red deseos. También a diferencia de RADIUS, TACACS+ encripta
todos los paquetes de datos, no sólo la contraseña. El protocolo TACACS+ es
similar a RADIUS en la forma en que autentifica a los usuarios. Un usuario
inicia sesión en un router o switch de interfaz que tenga TACACS+ habilitado.
El dispositivo de la red obtiene el nombre de usuario y contraseña del servidor
TACACS+ que está configurado para la interfaz y se lo pasa al usuario intentar
autenticarse. El usuario introduce el nombre de usuario y contraseña, que se
cifra y se pasó de la red al dispositivo de servidor de TACACS+. El servidor
TACACS+ enviará una de las cuatro respuestas a la red de dispositivo: ACEPATAR,
RECHARZAR, ERROR, o CONTINUAR. ACEPTAR una respuesta se indica que la
autenticación se ha realizado correctamente, y puede comenzar el período de
sesiones. Adicional si se necesita información de autenticación, el usuario se
le solicita que en este momento. Un mensaje RECHAZAR indica que la
autenticación fallo. El usuario tendrá que volver a introducir la contraseña, o
la sesión se desconectará. Este comportamiento varía en función de la TACACS+
demonio. Si es un ERROR, entonces hay un problema con el servidor de TACACS+,
el dispositivo de red de la consulta, o un problema con la red. Si el
dispositivo de red recibe el mensaje de error que se trate, ya sea nuevo o que
intentará un suplente TACACS + servidor, dependiendo de cómo el administrador
de la red se ha configurado. CONTINUAR la respuesta se enviará cuando la
autenticación es satisfactoria, pero se necesita información adicional.
TACACS+ permite múltiples
tipos de autenticación. Autenticación de contraseña es el usado más comúnmente,
la forma más básica de autenticación. Sin embargo, un administrador de red no
se limita a la contraseña de autenticación, de hecho, cualquier forma de
autenticación que cuenta con el apoyo de la TACACS + software puede ser
utilizado. Además, las múltiples formas de autenticación puede ser necesaria,
siempre y cuando el elegido TACACS + software apoya. Por ejemplo, si la contraseña
de autenticación no es suficiente, un administrador puede configurar TACACS +
para exigir un nombre de usuario / contraseña y una clave RSA para obtener
acceso. El usuario se autentique primero por el envío el nombre de usuario y
contraseña. En caso de que tuviera éxito, el servidor TACACS + ACEPTAR enviar
un mensaje, seguido por solicitud de un nuevo desafío, para la clave RSA.
Cuando los dos niveles de autenticación que se hayan completado, el usuario se
puede acceder al router.
Algunos servidores de autenticación
basados en TACACS+ son:
ClearBox TACACS+ RADIUS Server
KERBEROS
Kerberos se desarrolló
originalmente para sistemas basados en Unix y se define en el RFC 1510. Es una
infraestructura de autenticación utilizada para garantizar la identidad de los
usuarios y sistemas en una red. Kerberos tiene como primer objetivo el asegurar
las contraseñas para que nunca sean enviadas por la red sin ser previamente
encriptadas. Kerberos es el protocolo que más a menudo es asociado con el marco
AAA. La versión actual de Kerberos es la 5.0 y actualmente hay clientes de
Kerberos para casi cualquier sistema operativo. Para entender el funcionamiento
de Kerberos, lo primero es familiarizarse con su terminología. Lo términos a
emplear son los siguientes:
Caché credencial o archivo de ticket: Fichero que contiene las claves
para encriptar las comunicaciones entre el usuario y varios servicios de red.
Centro de distribución de claves (KDC): Servicios que emite ticket
Kerberos, que habitualmente se ejecutan en el mismo host que un Ticket Graming
Server.
Clave: Datos usados para encriptar o desencriptar otros datos. Los datos
encriptados no pueden desencriptarse sin una clave correcta.
Cliente: Usuario, host o aplicación que puede obtener un ticket desde
Kerberos
Dominio: Red que usa Kerberos compuesta de uno o varios servidores
(también conocidos como KDC) y un número potencial de clientes. También
conocido como Reino o Realm.
Keytab: Fichero que incluye una lista desencriptada de los principal y
sus claves.
Principal: Usuario o servicio que puede autenticar mediante el uso de
Kerberos. Un nombre de principal está en el formato siguiente:
root[/instance]@REALM.
Para un usuario típico, el
root es igual a su ID de login. El instance es opcional. Si el principal tiene
un instance, se separa del root con (“/”). Una cadena vacía (“) es un instance
válido (que difiere del instance por defecto NULL), pero usarlo puede ser
confuso. Todos los principal de un dominio tienen su propia clave, que se
deriva de su contraseña (para usuarios) o aleatoriamente (para servicios).
Servicio: Programa al que se accede en la red.
Texto cifrado: Datos encriptados.
Texto sin retocar: Datos no encriptados.
Ticket: Grupo temporal de credenciales electrónicas que verifican la
identidad de un cliente para un servicio particular.
Ticket Granting Service (TGS): Emite ticket para un servicio deseado que
usa el usuario para ganar acceso al servicio. El TGS se ejecuta en el mismo
host que KDC.
Ticket Granting Ticket (TGT): Ticket especial que permite al cliente
obtener tickets adicionales sin aplicarlos desde KDC.
Kerberos se basa en una
combinación de clave de cifrado y protocolos criptográficos para garantizar la
autenticación de los usuarios. El proceso se indica en la Figura 2-9, es
bastante simple, un administrador de la red se ha creado un servidor de
autenticación, conocido como Ticket Granting Server (TGS). Uno o varios reinos
(por lo general, los dominios) se crean en el TCG. Un usuario solicita el
acceso a un determinado ámbito debe obtener un boleto de la TGS, mediante la
autenticación en el servidor.
Fig. 3.2 Proceso de autenticación
Kerberos.
Cuando un usuario se
autentica en contra de la TGS un ticket es emitido. Ticket Granting Ticket
(TGT), se utiliza en cualquier momento que las necesidades de los usuarios a el
acceso a un servicio o un dispositivo en el ámbito que requiere autenticación.
El usuario presenta el TGT a la TGS, que emite un ticket para ese dispositivo o
servicio. El usuario sólo tiene que autenticarse en el TGS una vez durante una
sesión. El resto del tiempo, el TGS utiliza la información en el TGT para
conceder el acceso. Kerberos crea una clave basada en la contraseña del usuario
para cifrar el TGT usando el paquete de cifrado de datos estándar (DES). Las
versiones modernas utilizan cifrado 3DES. El usuario descifra el paquete y
utiliza la entrada para acceder al servicio o el dispositivo. Kerberos versión
4.0 se han encontrado varios fallos de seguridad, especialmente en el ámbito de
la autenticación de contraseña. Es especialmente susceptible a ataques de
diccionario, ya que sólo se utiliza una contraseña de base, una función de hash
como manera de generar la codificación. Kerberos 5.0 evita este problema
utilizando la contraseña y el campo para generar la encriptación. Esto hace que
sea mucho más difícil para un atacante lanzar un ataque de contraseña.
A continuación se detalla el
modo del funcionamiento del sistema Kerberos, cabe aclarar que el principal
problema para Kerberos consiste en cómo usar contraseñas para autenticarse sin
enviarlas a la red. En una red “kerberizada” la base de datos de
Kerberos contiene sus claves
(para los usuarios sus claves derivan de sus contraseñas). La base de datos
Kerberos también contiene claves para todos los servicios de la red. Cuando un
usuario, en una red que utiliza el sistema Kerberos, se registra en su estación
de trabajo, su principal se envía al Key Distribution Center (KDC) como una
demanda para un Ticket Granting Ticket (TGT). Esta demanda puede ser enviada
por el programa login (para que sea transparente al usuario) o puede ser
enviada por el programa kinit después de que el usuario se registre. El KDC
verifica el principal en su base de datos. Si lo encuentra, el KDC crea un TGT,
lo encripta usando las claves del usuario y lo devuelve al usuario. El programa
login o kinit desencripta el TGP utilizando las claves del usuario. El TGT, que
caduca después de un cierto periodo de tiempo, es almacenado en su caché de
credenciales. Sólo se puede usar durante un cierto periodo de tiempo, que suele
ser ocho horas (a diferencia de una contraseña comprometida, que puede usarse
hasta que se cambie). El usuario no tiene que introducir su contraseña otra vez
hasta que el TGT caduca o se desconecta y vuelve a conectarse. Cuando el
usuario necesita acceder a un servicio de red, el cliente usa el TGT para pedir
un ticket para utilizar el servicio Ticket Granting Service (TGS), que se
ejecuta en el KDC. El TGS emite un ticket por el servicio deseado que se usa
para autenticar el usuario. Kerberos depende de ciertos servicios de red para
trabajar correctamente. Primero, Kerberos necesita una sincronización de reloj
entre las computadoras y su red. Si no se ha configurado un programa de
sincronización de reloj para la red, será necesaria su instalación. Ya que
ciertos aspectos de Kerberos se apoyan en el DNS (Domain Name System), las
entradas DNS y los host en la red deben estar configurados correctamente [10].
Algunos servidores de
autenticación basados en Kerberos son:
Windows Server 2008
KERBEROS MIT
KERBEROS Heimdal
Actividad Desarrollar una tabla comparativa de los protocolos de
Autenticación.
No hay comentarios:
Publicar un comentario