Kerberos

Publicado por

Índice

  1. Introducción
  2. Objetivos
  3. Arquitectura
  4. Protocolo en acción
  5. CLI

1. Introducción

Es un un protocolo que permite autenticación segura sobre una red insegura donde las comunicaciones entre hosts pueden ser interceptadas. Los servidores de autenticación, los servidores de aplicaciones (imap, pop, smtp, telnet, ftp,ssh, …) y los clientes deben mantenerse constantemente actualizados para que la autenticidad de las solicitudes de usuario y proveedores de servicios sea fiable.

Las estrategias que utiliza Kerberos no sirven de nada, si alguien que obtiene privilegios de usuario accede a un servidor y copia el fichero que contiene la clave. El intruso utilizará esta clave en otra máquina y solo tendrá que hacer un spoof de la IP para que el servidor aparezca a los clientes como el auténtico.

La autenticación Kerberos se basa en una criptografía de claves simétricas1 y requiere de un tercero de confianza, al que se le da el nombre de centro de generación de claves (KDC: Key Distributed Center).

El nombre de Kerberos viene de la mitología griega, es el perro de tres cabezas de Hades. Es bastante apropiado porque necesita de un tercero de confianza, el KDC, para autenticar un cliente con un servicio o máquina.

2. Objetivos

  • El password de un usuario nunca viajará a través de la red
  • El password de un usuario nunca se guardará en la máquina del cliente, debe ser descartada nada mas ser utilizada.
  • El password nunca debe ser guardado sin encriptar, incluso en la base de datos del servidor de autenticación.
  • El usuario solo debe ser preguntado por el password una vez por sesión. Single Sign-On.
  • La gestión de la autenticación es centralizada y reside en el servidor de autenticación. Los servidores de aplicaciones no deben tener información de autenticación de sus usuarios.
  • No solo los usuarios deben autenticarse, los servidores de aplicaciones deben probar su autenticidad frente a los usuarios. Autenticación mutua.
  •  Una vez autenticados los dos elementos, Kerberos también proporciona comunicaciones encriptadas entre ellos.

3. Arquitectura

  1. realm
  2. Principal
  3. Ticket
  4. Key Distributed Center (KDC)
  5. Clave de sesión
  6. Autenticador

a. realm:

Este termino indica el dominio administrativo de autenticación. Su función es establecer los límites dentro del cual el servidor de autenticación puede autorizar o no a un usuario o servicio. Esto no quiere decir que un usuario y un servicio que se autentican deban pertenecer al mismo realm: si son de realms diferentes y entre ellos hay una relación de confianza la autenticación se puede realizar. Esto es conocido como Cross-Authentication.

Básicamente un usuario o servicio pertenece a un realm si comparte un password secreta con el servidor de autenticación de ese realm. Normalmente se utiliza como nombre de realm el del dominio DNS.

b. Principal

Es el nombre que se da a las entradas de la base de datos del servidor de autenticación. Un principal esta asociado con cada usuario, servidor o servicio de un determinado realm.

Una entrada del principal de usuario sería así, aunque normalmente no se utiliza ninguna instancia.

Name[/Instance]@REALM

Para un servicio sería

Service/Hostname@REALM

c. Ticket

Un ticket es algo que un cliente presenta a un servidor de aplicaciones para demostrar la autenticidad de su identidad. Los tickets son generados por el servidor de autenticación y son encriptadas utilizando la clave secreta del servicio al que intentan acceder. Como la clave es compartida solo entre el servidor de autenticación y el servidor que proporciona el servicio, incluso el cliente que realiza la petición, es  incapaz de conocerla o cambiar su contenido.

La información principal de un ticket es:

  • El principal del usuario que solicita (username)
  • El principal del servicio que se quiere utilizar
  • La IP del ordenador del cliente que puede utilizar el ticket (Opcional).
  • El tiempo y la hora en timestamp desde que tiene validez el ticket
  • La vida máxima del ticket (10H)
  • La clave de sesión (rol fundamental)

d. Key Distributed Center (KDC)

El servidor de autenticación en un entorno Kerberos, basado en su función de distribución de tickets para acceder a servicios se llama Centro de Distribución de Claves, por su siglas en ingles KDC. Reside en una solo servidor y lógicamente puede ser dividido en tres: Base de datos, Servidor de Autenticación (AS) y Servidor de Cesión de Tickets (TGS: Ticket Granting Service).

Base de datos: es el contenedor para las entradas asociadas con un usuario o servicio. Nos referimos a una entrada utilizando el principal.

Servidor de Autenticación: es el que responde a la solicitud de autenticación del cliente. En respuesta a una solicitud de autenticación el AS genera un tipo de ticket especial conocido como Ticket Granting Ticket (TGT). Si el usuario es quien dice ser puede utilizar el TGT para obtener tickets para otros servicios sin tener que volver a introducir la password.

Servidor de Cesión de Tickets: es el componente que distribuye los tickets de servicio a los clientes con un TGT válido.  Puede considerarse como un servidor de aplicaciones  que proporciona la generación de tickets de servicio como servicio.

09fig07

Img: http://etutorials.org/

e. Clave de sesión

Como hemos visto los usuarios y servicios comparten una clave secreta con el KDC . Para los usuarios esta clave esta derivada de su password, mientras que los servicios tiene su clave secreta establecida por el administrador. Esta clave es generada cuando se crea la sesión entre las dos entidades y solo es conocida por ellos.

Sin embargo, es necesario que el usuario también comparta una clave secreta con el servicio, al menos durante el tiempo en que un cliente tiene una sesión de trabajo abierta en un servidor: esta clave, generada por el KDC cuando se emite un ticket, se denomina Clave de sesión.

f. Autenticador

Junto con la solicitud que contien el ticket, el cliente agrega otro paquete (autenticador) en el que se incluye el principal del usuario y el timestamp actual y lo encripta con la clave de sesión. El servidor que debe ofrecer el servicio, al recibir la solicitud, descomprime el primer ticket, extrae la clave de sesión y si el usuario es quien dice ser, el servidor es capaz de desencriptar el autenticador extrayendo el timestamp. Si la diferencia con el tiempo del servidor es menor de dos minutos, entonces la autenticación es correcta. Esto subraya la criticidad de la sincronización entre máquinas.

4. Protocolo en acción

En resumen se podría decir que su funcionamiento es el siguiente:

  • AS_REQ es la solicitud inicial de autenticación. Este mensaje es dirigido al componente AS del KDC.
  • AS_REP es la respuesta del AS a la petición anterior. Básicamente contiene el TGT (encriptado utilizando la clave secreta del TGS) y la clave de sesión (encriptada utilizando la clave secreta de la petición del usuario)
  • TGS_REQ es la petición del cliente al TGS para obtener un ticket de servicio. Este paquete incluye el TGT anterior y un autenticador generado por el cliente y encriptado con la clave de sesión.
  • TGS_REP es la respuesta del TGS a la petición anterior. Este paquete contiene el ticket de servicio solicitado (encriptado con la clave secreta del servicio) y una sesión de servicio generada por el TGS encriptada con la misma clave de sesión que utilizo el AS.
  • AP_REQ es la petición que el cliente envía a un servidor de aplicaciones para acceder a un servicio. Esta formado por el ticket de servicio proporcionado por el TGS y un autenticador generado por el cliente pero ahora encriptado utilizando la clave de sesion del servicio generado por el TGS.
  • AP_REP es la respuesta que el servidor de aplicaciones da al cliente para probar que es realmente el servidor que el cliente quiere utilizar, solo cuando esta configurado la autenticación mutua.

krbmsg

Img: Zeroshell.org

También se puede realizar la autenticación entre elementos de dos realms diferentes:

ic833523

4. CLI

Normalmente Kerberos está configurado con un sistema de login, para recibir un ticket de servicio automáticamente cuando introducimos nuestro usuario y password.

shell% kinit david@EXAMPLE.COM
Password for david@EXAMPLE.COM:

Si por el contrario no está configurado deberemos utilizar el comando kinit.

AS_REQ: preguntar al AS por un TGT.

kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM

TGT_REQ: se realiza automáticamente cuando se accede a un servicio kerberizado, éste manda una petición al TGS para obtener el ticket de servicio presentando el TGT anterior.

Para ver los tickets que se utiliza klist. Cuando se obtienen tickets por primera vez, solo se vera el TGT (indicado en rojo).

shell% klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: jennifer@ATHENA.MIT.EDU

Valid starting Expires Service principal
06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU

Si ahora nos conectamos por ssh al equipo faffodil.mit.edu y hacemos klist

shell% klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: jennifer@ATHENA.MIT.EDU

Valid starting Expires Service principal
06/07/17 19:49:21 06/08/17 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
06/07/17 20:22:30 06/08/17 05:49:19 host/daffodil.mit.edu@ATHENA.MIT.EDU

Lo que ha sucedido es que al conectar con el host, el programa ssh ha presentado su TGT al KDC y le ha solicitado un ticket de servicio. El KDC ha enviado el ticket de servicio, que ssh ha presentado al host, que ha permitido conectar a Jennifer. Esto ha sido posible sin volver a introducir el password.

Si Jennifer tiene permiso para logarse en otro equipo de otro dominio pragsis.example.com perteneciente a un realm diferente, podrá listar y por ejemplo tener acceso a otros elementos.

shell% klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: jennifer@ATHENA.MIT.EDU

Valid starting Expires Service principal
06/07/17 19:49:21 06/08/17 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
06/07/17 20:22:30 06/08/17 05:49:19 host/daffodil.mit.edu@ATHENA.MIT.EDU
06/07/17 20:24:18 06/08/17 05:49:19 krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU
06/07/17 20:24:18 06/08/17 05:49:19 host/pragsis.example.com@EXAMPLE.COM

Los tickets prueban tu identidad, pero si alguien accede a tu máquina y roba el ticket podrá enmascarar tu identidad, por eso se deberían destruir los tickets cuando se este trabajando delante del ordenador. Para ello:

shell% kdestroy

Fuentes:

Pragsis University
Wikipedia
MIT Kerberos
Zeroshell
Etutorials

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s