Dado que es un servicio de mucha importancia y uno de los que cualquier persona que trabaje en administración de sistemas o seguridad debe conocer, me parece bien dedicar un artículo para describir como funciona. En un próximo artículo veremos cómo instalarlo y configurarlo en GNU/Linux.
Este artículo forma parte del proyecto Autenticación y administración centralizada de usuarios en GNU/Linux.
Qué es?
Kerberos es un protocolo de autenticación desarrollado por el MIT e implementado en varios sistemas operativos. La principal función es permitir que dos nodos puedan autenticarse entre sí sobre una red insegura. Se utiliza principalmente en modelos cliente-servidor donde cliente y servidor pueden autenticarse mutuamente.
Kerberos funciona utilizando criptografía simétrica y requiere de una tercera parte confiable (siempre hay que confiar en alguien...).
Dato interesante: el nombre kerberos proviene del perro con tres cabezas y cola de serpiente, guardian de la entrada del templo de Hades en la mitología griega. El nombre era acertado porque la idea era proveer 3 mecanismos de seguridad: autenticación, contabilidad y auditoria. Desgraciadamente, sólo se implementó el componente de autenticación.
En el modelo kerberos contamos con dos servidores lógicos (que en la práctica suelen estar implementados en un sólo servidor físico denominado Key Distribution Center o KDC):
- Authentication Server (AS): servidor encargado de autenticar al cliente y proveer un ticket para contactar al TGS. Este servidor almacena la clave de los clientes y las utiliza para autenticarlos.
- Ticket Granting Server (TGS): servidor encargado de proveer tickets a los clientes para que puedan acceder al servicio deseado.
Qué servicios se puede acceder con un ticket de kerberos? cualquiera que implemente este tipo de autenticación. Por ejemplo, la autenticación de usuarios en un sistema operativo, acceso a servicios ldap, web, smtp, etc. Para poder utilizar un servicio kerberizado, el cliente debe primero contactar al AS y el TGS para obtener un ticket, que luego utiliza para acceder el servicio.
Los tickets tienen una validez de tiempo limitada, para lo cual se utilizan timestamps. Debido a esto, tanto clientes como servidores deben tener sus relojes sincronizados, porque sino el sistema no funciona. Normalmente esta sincronización se realiza utilizando el protocolo NTP.
Descripción del protocolo
El handshake de autorización para acceder a un servicio es la siguiente:
- Cliente C contacta al AS requieriendo acceso a un servicio del Service Server (SS).
- AS utiliza la clave que tiene almacenada del usuario (user master key) para encriptar la clave de sesión necesaria para encriptar los mensajes con el TGS (TGSsk). Además, AS envía al cliente otra tupla (denominada Ticket Granting Ticket - TGT) pero encriptada con la clave del TGS, la cual contiene el ID del cliente, la dirección de red del mismo, el tiempo de validez del ticket y la clave de sesión (TGSsk).
- Cuando el cliente recibe los mensajes, desencripta el primero para obtener la clave de sesión TGSsk. Al desencriptar este mensaje, prueba quién es, dado que otro cliente no tendrá la clave necesaria para desencriptar el mensaje. El TGT no lo desencripta porque está encriptado con la clave del TGS.
- El cliente ahora envía el TGT al TGS y un mensaje autenticador, compuesto por el ID del cliente y el timestamp, encriptado con la clave de sesión TGSsk.
- Una vez que el TGS recibe los mensajes del cliente, desencripta el TGT para obtener la clave de sesión TGSsk, y con esta clave desencripta el otro mensaje (el autenticador) y responde al cliente enviando un nuevo ticket, muy similar al TGT, pero para ser utilizado con el Service Server, que provee el servicio deseado (por ejemplo ldap). Este mensaje contiene el ID del cliente, la dirección de red, el período de validez y una nueva clave de sesión para utilizar con el servidor (SSsk). Además, envía otro mensaje que contiene el SSsk, encriptado con la clave de sesión del TGS (TGSsk).
- Finalmente el cliente tiene todo lo necesario para acceder el servicio que desea, por lo que contacta al SS enviando el ticket que recibió del TGS y un nuevo autenticador encriptado con la SSsk.
- SS desencripta el ticket recibido para obtener la clave de sesión SSsk, con la cual desencripta el autenticador del cliente. SS responde con el último mensaje del handshake inicial que contiene el timestamp encontrado en el autenticador del cliente más 1, encriptado con la clave de sesión SSsk.
- Con el último mensaje el cliente puede comprobar la autenticidad del servidor.
Resumiendo, obtenemos el siguiente flujo:
C ---- pedido de servicio -----> AS
AS ---- TGSsk encriptada con clave del cliente ----> C
AS ---- TGT ----> C
C ---- TGT ----> TGS
C ---- autenticador encriptado con TGSsk ----> TGS
TGS ---- ticket para acceder servicio ----> C
TGS ---- SSsk encriptado con clave del cliente ----> C
C ----> ticket para acceder servicio ----> SS
C ----> autenticador encriptado con SSsk ----> SS
SS ----> timestamp +1 encriptado con la clave de sesión SSsk ----> C
Sí, parece (o es) tremendo lío el sistema de autenticación, pero es efectivo y seguro, y prestando atención llega a entenderse bien (aunque con el tiempo uno se vuelve a olvidar =P).
Gracias a que la autenticación con usuario y contraseña genera el TGT, para acceder a distintos servicios sólo necesitamos este ticket, por lo cual no es necesario cargar las credenciales por cada servicio accedido. Esto permite que sistemas como el single sign-on funcionen. Además el TGT puede ser renovable dentro de un dado período de tiempo, lo que da flexibilidad a servicios que necesitan mucho tiempo para completarse.
Se desprende de la explicación anterior que el KDC contiene todas las credenciales de todos sus usuarios. Obviamente estas credenciales no se almacenan de forma plana en la base de datos. La base de datos se encripta utilizando una master key que el administrador debe elegir al momento de configurar el KDC. Pero esta master key también debe estar almacenada en algún lugar si se desea que el servicio se cargue automáticamente! En el kerberos de MIT la master key se almacena en el archivo stash. En AD existe un usuario denominado kbrtgt cuya contraseña es la utilizada como master key del KDC, este usuario no puede loguearse y está deshabilitado.
Limitaciones y desventajas
- La obvia desventaja de un sistema de autenticación centralizado es el único punto de falla. Si se cae el AS o el TGS, nadie puede acceder a ningún servicio. Esto se soluciona utilizando más de un servidor y replicando los datos.
- Todos los participantes deben tener coordinados sus relojes, porque sino, los tickets no funcionan.
- Dado que todas las claves se almacenan en un servidor, si un atacante logra hackearlo, podrá acceder como cualquier usuario!
- Otro problema es el replay attack, un ataque que no simple, pero tampoco imposible como se demuestra en el paper Replay Attack on Kerberos V and SMB.
Terminología
En el mundo kerberos existen ciertas definiciones que es necesario conocer para poder configurarlo correctamente. Veamos entonces los términos utilizados:
- Realm (reino, interesante nombre): indica el dominio de autenticación. El realm establece los límites en los cuales un servidor de autenticación tiene autoridad para autenticar usuarios, hosts o servicios. Es posible, sin embargo, realizar autenticaciones cross-realm entre, por ejemplo, un usuario de un realm y un servicio de otro. Esto se lleva a cabo a través de una relación de confianza entre los realms que debe ser establecida previamente. Básicamente un usuario/servicio pertenece a un realm sólo si comparte un secreto (password/key) con el servidor de autenticación. Es recomendable que el nombre del realm sea igual al del dominio (DNS) en el que nos encontramos, escrito con letras mayúsculas (los nombres son case-sensitive). Si nuestro dominio es demasiadovivo.org, lo aconsejable es nombrar al realm DEMASIADOVIVO.ORG.
- Principal: es el nombre utilizado para referirse a las entradas en la base de datos del servidor de autenticación. Cada usuario/host/servicio del realm tiene asociado un principal (string) que lo identifica. Ejemplos de principals son el nombre de usuario, el nombre de un host, etc. Cada principal puede tener varios componentes, pero generalmente se usan 3:
- primary: la primera parte del principal. En el caso de un usuario, este es su nombre de usuario. En el caso de un servicio, es el nombre del servicio.
- instance: la segunda parte de principal. Da información que califica al primary y puede ser null. En el caso de un usuario, el instance suele usarse para describir el uso para el cual están destinadas las credenciales. En el caso de un host, el instance es el hostname.
- realm: el nombre del realm en mayúsculas.
- Ticket: en la explicación anterior se describió el concepto de tickets en kerberos. Un ticket permite demostrar la autenticidad de un cliente. Los tickets caducan luego de un cierto tiempo, y es necesario obtener uno nuevo cuando esto sucede, o bien renovarlo si esto es posible.
- Keytab: es un archivo que contiene pares principal -> clave. Este archivo se puede utilizar para obtener tickets sin que el sistema pida password en el proceso de autenticación. El uso más común es en scripts que necesitan utilizar kerberos sin interacción humana. Los archivos keytab son muy importantes y deben mantenerse seguros.
Referencias
- Kerberos protocol wik
- The Kerberos protocol and its implementation
- Kerberos FAQ, v2.0
0 comentarios:
Publicar un comentario