Seguridad en Unix y Redes
Libro en Formato HTML y PDF de seguridad informática realizado por Antonio Villalon Huerta

Los contenidos pueden estar desactualizados con respecto al original

Este documento se encuentra disponible también en formato PDF

Kerberos


next up previous contents
Siguiente: Otros aspectos de la Subir: Seguridad de la subred Anterior: Sistemas de detección de   Índice General

Subsecciones

Kerberos

Introducción

Durante 1983 en el M.I.T. (Massachussetts Institute of Technology) comenzó el proyecto Athena con el objetivo de crear un entorno de trabajo educacional compuesto por estaciones gráficas, redes de alta velocidad y servidores; el sistema operativo para implementar este entorno era Unix 4.3BSD, y el sistema de autenticación utilizado en el proyecto se denominó Kerberos ([MNSS87]) en honor al perro de tres cabezas que en la mitología griega vigila la puerta de entrada a Hades, el infierno.

Hasta que se diseñó Kerberos, la autenticación en redes de computadores se realizaba principalmente de dos formas: o bien se aplicaba la autenticación por declaración (Authentication by assertion), en la que el usuario es libre de indicar el servicio al que desea acceder (por ejemplo, mediante el uso de un cliente determinado), o bien se utilizaban contraseñas para cada servicio de red. Evidentemente el primer modelo proporciona un nivel de seguridad muy bajo, ya que se le otorga demasiado poder al cliente sobre el servidor; el segundo modelo tampoco es muy bueno: por un lado se obliga al usuario a ir tecleando contínuamente su clave, de forma que se pierde demasiado tiempo y además la contraseña está viajando contínuamente por la red. Kerberos trata de mejorar estos esquemas intentando por un lado que un cliente necesite autorización para comunicar con un servidor (y que esa autorización provenga de una máquina confiable), y por otro eliminando la necesidad de demostrar el conocimiento de información privada (la contraseña del usuario) divulgando dicha información.

Kerberos se ha convertido desde entonces en un referente obligatorio a la hora de hablar de seguridad en redes. Se encuentra disponible para la mayoría de sistemas Unix, y viene integrado con OSF/DCE (Distributed Computing Environment). Está especialmente recomendado para sistemas operativos distribuidos, en los que la autenticación es una pieza fundamental para su funcionamiento: si conseguimos que un servidor logre conocer la identidad de un cliente puede decidir sobre la concesión de un servicio o la asignación de privilegios especiales. Sigue vigente en la actualidad (en su versión V a la hora de escribir este trabajo), a pesar del tiempo transcurrido desde su diseño; además fué el pionero de los sistemas de autenticación para sistemas en red, y muchos otros diseñados posteriormente, como KryptoKnight ([MTHZ92], [JTY97]...), SESAME ([PPK93]) o Charon ([Atk93]) se basan en mayor o menor medida en Kerberos.

El uso de Kerberos se produce principalmente en el login, en el acceso a otros servidores (por ejemplo, mediante rlogin) y en el acceso a sistemas de ficheros en red como NFS. Una vez que un cliente está autenticado o bien se asume que todos sus mensajes son fiables, o si se desea mayor seguridad se puede elegir trabajar con mensajes seguros (autenticados) o privados (autenticados y cifrados). Kerberos se puede implementar en un servidor que se ejecute en una máquina segura, mediante un conjunto de bibliotecas que utilizan tanto los clientes como las aplicaciones; se trata de un sistema fácilmente escalable y que admite replicación, por lo que se puede utilizar incluso en sistemas de alta disponibilidad (aunque como veremos al final del capítulo está fuertemente centralizado).

Arquitectura de Kerberos

Un servidor Kerberos se denomina KDC (Kerberos Distribution Center), y provee de dos servicios fundamentales: el de autenticación (AS, Authentication Service) y el de tickets (TGS, Ticket Granting Service). El primero tiene como función autenticar inicialmente a los clientes y proporcionarles un ticket para comunicarse con el segundo, el servidor de tickets, que proporcionará a los clientes las credenciales necesarias para comunicarse con un servidor final que es quien realmente ofrece un servicio. Además, el servidor posee una base de datos de sus clientes (usuarios o programas) con sus respectivas claves privadas, conocidas únicamente por dicho servidor y por el cliente que al que pertenece.

La arquitectura de Kerberos está basada en tres objetos de seguridad: Clave de Sesión, Ticket y Autenticador.
  • La clave de sesión es una clave secreta generada por Kerberos y expedida a un cliente para uso con un servidor durante una sesión; no es obligatorio utilizarla en toda la comunicación con el servidor, sólo si el servidor lo requiere (porque los datos son confidenciales) o si el servidor es un servidor de autenticación. Se suele denominar a esta clave , para la comunicación entre un cliente C y un servidor S.
    Las claves de sesión se utilizan para minimizar el uso de las claves secretas de los diferentes agentes: éstas últimas son válidas durante mucho tiempo, por lo que es conveniente para minimizar ataques utilizarlas lo menos posible.
  • El ticket es un testigo expedido a un cliente del servicio de tickets de Kerberos para solicitar los servicios de un servidor; garantiza que el cliente ha sido autenticado recientemente. A un ticket de un cliente C para acceder a un servicio S se le denomina . Este ticket incluye el nombre del cliente C, para evitar su posible uso por impostores, un periodo de validez y una clave de sesión asociada para uso de cliente y servidor. Kerberos siempre proporciona el ticket ya cifrado con la clave secreta del servidor al que se le entrega.
  • El autenticador es un testigo construido por el cliente y enviado a un servidor para probar su identidad y la actualidad de la comunicación; sólo puede ser utilizado una vez. Un autenticador de un cliente C ante un servidor S se denota por . Este autenticador contiene, cifrado con la clave de la sesión, el nombre del cliente y un timestamp.
Kerberos sigue de cerca el protocolo de Needham y Schroeder ([NS78]) con clave secreta, utilizando timestamps como pruebas de frescura con dos propósitos: evitar reenvíos de viejos mensajes capturados en la red o la reutilización de viejos tickets obtenidos de zonas de memoria del usuario autorizado, y a la vez poder revocar a los usuarios los derechos al cabo de un tiempo.

Autenticación

El protocolo de autenticación de Kerberos es un proceso en el que diferentes elementos colaboran para conseguir identificar a un cliente que solicita un servicio ante un servidor que lo ofrece; este proceso se realiza en tres grandes etapas que a continuación se describen. En la tabla 19.1 se muestran las abreviaturas utilizadas, y en la figura 19.1 un resumen gráfico de este protocolo.

Tabla 19.1: Abreviaturas utilizadas.
C Cliente que solicita un servicio
S Servidor que ofrece dicho servicio
A Servidor de autenticación
T Servidor de tickets
K Clave secreta del cliente
K Clave secreta del servidor
K Clave secreta del servidor de tickets
K Clave de sesión entre el cliente y el servidor de tickets
K Clave de sesión entre cliente y servidor


Login

Inicialmente el cliente C (en este caso el usuario a través del programa login) necesita obtener las credenciales necesarias para acceder a otros servicios. Para ello cuando un usuario conecta a un sistema Unix `kerberizado' teclea en primer lugar su nombre de usuario, de la misma forma que en un sistema habitual; la diferencia está en que el programa login envía el nombre de usuario al servidor de autenticación de Kerberos para solicitar un ticket que le permita comunicarse posteriormente con el servidor de tickets, TGS:
Si el usuario es conocido, el servidor de autenticación retorna un mensaje que contiene una clave para la comunicación con TGS y un timestamp cifrado con la clave secreta del cliente, junto un ticket para la comunicación con TGS cifrado con la clave secreta de este servidor:
El programa de login intentará descifrar , con la clave que el usuario proporciona, y si ésta es correcta podrá obtener y : un cliente sólo podrá descifrar esta parte del mensaje si conoce su clave secreta, (en este caso el password). Una vez obtenida , la clave para comunicar al cliente con el servidor de tickets, el programa passwd la guarda para una posterior comunicación con el TGS y borra la clave del usuario de memoria, ya que el ticket será suficiente para autenticar al cliente; este modelo consigue que el password nunca viaje por la red.

Obtención de tickets

El cliente ya posee una clave de sesión para comunicarse con el servidor de tickets y el ticket necesario para hacerlo, cifrado con la clave secreta de este servidor (el cliente no puede descifrar este ticket). Cuando el cliente necesita acceder a un determinado servicio es necesario que disponga de un ticket para hacerlo, por lo que lo solicita al TGS enviándole un autenticador que el propio cliente genera, el ticket de T y el nombre del servicio al que desea acceder, S, y un indicador de tiempo:
Cuando TGS recibe el ticket comprueba su validez y si todo es correcto retorna un mensaje que contiene una clave para comunicación con S y un timestamp cifrado con la clave de sesión del par CT, junto a un ticket para que el cliente C y el servidor S se puedan comunicar cifrado con la clave secreta del servidor:
C sólo podrá obtener si conoce la clave secreta, .

Petición de servicio

Tras obtener el ticket para comunicarse con S el cliente ya está preparado para solicitar el servicio; para ello presenta la credencial autenticada ante el servidor final, que es quien va a prestar el servicio. C se comporta de la misma forma que cuando solicitó un ticket a T: envía a S el autenticador recién generado, el ticket y una petición que puede ir cifrada si el servidor lo requiere, aunque no es necesario:
El servidor envía entonces al cliente la prueba de actualidad cifrada con la clave secreta de la sesión:
Sólo S pudo obtener y por tanto enviar este mensaje.
Figura 19.1: Protocolo de autenticación Kerberos.

Problemas de Kerberos

A la vista de todo lo comentado en los puntos anteriores puede darnos la impresión de que Kerberos es la panacea de los sistemas de autenticación. Sin embargo, y aunque se trate de un sistema robusto, no está exento de ciertos problemas, tanto de seguridad como de implementación, que han hecho que este sistema no esté todo lo extendido que debería.

Uno de los principales problemas de Kerberos es que cualquier programa que lo utilice ha de ser modificado para poder funcionar correctamente, siguiendo un proceso denominado `kerberización'. Esto implica obviamente que se ha de disponer del código fuente de cada aplicación que se desee kerberizar, y también supone una inversión de tiempo considerable para algunas aplicaciones más o menos complejas que no todas las organizaciones se pueden permitir.

El problema anterior es simplemente de implementación; no afecta para nada a la seguridad - o inseguridad - del protocolo. Un problema que sí está relacionado con la seguridad de Kerberos es la gran centralización que presenta el sistema. Para un correcto funcionamiento se ha de disponer en todo momento del servidor Kerberos, de forma que si la máquina que lo alberga falla, la red se convierte en inutilizable; obviamente esto es una contradicción con lo que nos dice la teoría de sistemas distribuidos, donde se recalca el uso de la distribución para mantener la disponibilidad del sistema, intentado que si un equipo falla el resto pueda seguir funcionando, si no a pleno rendimiento, al menos correctamente. Por si esto no fuera suficiente, otro ejemplo de la centralización de Kerberos reside en el hecho de que casi toda la seguridad reside en el servidor que mantiene la base de datos de claves, de forma que si éste se ve comprometido, la red entera está amenazada.

Otro potencial problema de seguridad es el uso de timestamps como pruebas de frescura en Kerberos. Esto obliga a que todas las máquinas que ejecutan servicios autenticados mantengan sus relojes mínimamente sincronizados (con desfases máximos de pocos minutos), con todo lo que esto implica. Además ese tiempo global ha de ser accesible a todas las estaciones; aunque en el diseño no se asume que todas mantengan la hora exacta, sí que se les obliga a mantenerse dentro de los márgenes si desean solicitar tickets, para lo que se necesitan servidores de tiempo con los que los clientes puedan sincronizar periódicamente sus relojes, por ejemplo cada vez que arrancan.

Todos estos problemas, y algunos más ([BM91]) que se han ido solucionando en diferentes versiones del sistema, han propiciado que el uso de Kerberos no esté muy extendido; en la mayoría de redes es suficiente con un protocolo de comunicación cifrado para mantener una mínima seguridad, de forma que el complejo modelo de Kerberos se ve sustituido a ese efecto por programas tan simples y transparentes como SSH.
next up previous contents
Siguiente: Otros aspectos de la Subir: Seguridad de la subred Anterior: Sistemas de detección de   Índice General
2002-07-15