Arquitectura de Kerberos y flujo de tickets

Kerberos se desarrolló en el MIT como parte del Project Athena durante la década de 1980 para proporcionar autenticación de red segura en un entorno de computación distribuida. Su nombre proviene del perro de tres cabezas que custodiaba el inframundo y proporciona autenticación mutua entre clientes y servicios mediante un tercero de confianza: el Key Distribution Center.

El KDC tiene dos componentes lógicos: el Authentication Service (AS) y el Ticket Granting Service (TGS). En Microsoft Active Directory, ambos se ejecutan en el controlador de dominio. El AS gestiona el inicio de sesión inicial y emite Ticket Granting Tickets (TGT). El TGS emite tickets de servicio para acceder a servicios específicos.

El cliente inicia la autenticación enviando un AS-REQ al Authentication Service. Kerberos moderno requiere preautenticación: el cliente cifra una marca de tiempo con su clave de largo plazo (derivada de la contraseña) para demostrar que conoce la contraseña. Esto evita ataques de diccionario sin conexión contra mensajes AS-REQ no protegidos.

El AS verifica los datos de preautenticación y responde con un AS-REP que contiene un Ticket Granting Ticket (TGT) cifrado con la clave de largo plazo de la cuenta krbtgt (que el cliente no puede descifrar) y una clave de sesión cifrada con la clave de largo plazo del cliente. El cliente descifra únicamente su parte para obtener la clave de sesión del TGS.

Cuando el cliente quiere acceder a un servicio, envía un TGS-REQ al Ticket Granting Service, que incluye el TGT (como prueba de identidad) y un autenticador cifrado con la clave de sesión del TGS. El TGS descifra el TGT con la clave de krbtgt para verificar la identidad del cliente.

El TGS responde con un ticket de servicio cifrado con la clave de largo plazo del servicio de destino, además de una nueva clave de sesión cifrada para el cliente. El cliente no puede leer el contenido del ticket de servicio, sino únicamente la parte cifrada para él. Este ticket de servicio demuestra la identidad del cliente ante el servicio.

El cliente envía un AP-REQ al servicio de destino, que incluye el ticket de servicio y un nuevo autenticador cifrado con la clave de sesión del servicio. El servicio descifra el ticket de servicio mediante su propia clave de largo plazo, verifica el autenticador y autentica al cliente. Nunca se envía ninguna contraseña al servicio.

Un reino Kerberos es un dominio administrativo gestionado por un único KDC. La autenticación entre reinos se establece mediante claves entre reinos compartidas por los KDC de distintos reinos. Cuando un cliente del Reino A accede a un servicio del Reino B, el KDC del Reino A emite un ticket de referencia que el cliente presenta al KDC del Reino B.

Los tickets de Kerberos tienen una duración configurada (normalmente 10 horas para los TGT), tras la cual caducan y es necesaria una nueva autenticación. Los TGT también se pueden configurar como renovables, lo que permite al cliente solicitar un TGT nuevo al KDC sin volver a introducir las credenciales, hasta alcanzar una duración máxima de renovación.

Kerberos utiliza dos tipos de claves. Las claves de largo plazo se derivan de las contraseñas de las cuentas y se utilizan únicamente para cifrar partes de los mensajes de autenticación. Las claves de sesión se negocian de nuevo en cada intercambio de autenticación y se utilizan para la sesión de comunicación real. La vulneración de una clave de sesión no expone la clave de largo plazo.

Kerberos proporciona autenticación mutua (se verifican tanto el cliente como el servicio), protección contra repeticiones (mediante marcas de tiempo y autenticadores) y secreto perfecto hacia adelante para las sesiones individuales. Durante el funcionamiento normal, el KDC nunca expone las claves de largo plazo. La principal suposición de confianza es que el propio KDC no esté comprometido.

Kerberos utiliza un KDC con componentes AS y TGS. El inicio de sesión produce un TGT (AS-REQ/AS-REP). Para acceder a un servicio, el TGT se intercambia por un ticket de servicio (TGS-REQ/TGS-REP). El ticket de servicio se presenta al servicio de destino (AP-REQ). Solo el KDC y los servicios correspondientes pueden leer los tickets. Los reinos permiten la autenticación entre dominios mediante la confianza entre reinos.