Kerberos

Historia y desarrollo

El MIT desarrolló Kerberos para proteger los servicios de red del Proyecto Atenea. El protocolo recibe su nombre del personaje mitológico griego Kerberos (o Cerbero), conocido en la mitología griega por ser el monstruoso perro guardián de tres cabezas de Hades. Existen varias versiones del protocolo; las versiones 1 a 3 sólo se utilizan internamente en el MIT.

Steve Miller y Clifford Neuman, los principales diseñadores de la versión 4 de Kerberos (que utilizaba el algoritmo de cifrado DES con claves de 56 bits), publicaron esa versión en 1989, aunque la habían destinado principalmente al Proyecto Athena.

La versión 5, diseñada por John Kohl y Clifford Neuman, apareció como RFC 1510 en 1993 (quedó obsoleta con la RFC 4120 en 2005), con la intención de superar las limitaciones y problemas de seguridad de la versión 4. El MIT pone a disposición del público una implementación de la versión 5 de Kerberos, bajo una licencia de software similar a la utilizada por la licencia BSD.

Varias empresas utilizaron la versión 5 de Kerberos en software comercial, entre ellas:

·         Windows 2000 de Microsoft y posteriores utilizan Kerberos como método de autenticación por defecto.
Algunas adiciones de Microsoft al conjunto de protocolos Kerberos se documentan en el RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". El RFC
4757 documenta el uso de Microsoft del cifrado RC4.
Aunque Microsoft utiliza el protocolo Kerberos, no utiliza el software del MIT[1].

·         Mac OS X de Apple también utiliza Kerberos tanto en su versión cliente como en su versión servidor.

·         La versión 4 de Red Hat Linux y posteriores utilizan Kerberos tanto en la versión cliente como en la versión servidor.

En 2005, el grupo de trabajo de Kerberos del IETF introdujo una nueva especificación actualizada para la versión 5 de Kerberos [2]. Las actualizaciones incluyen:

·         "Encryption and Checksum Specifications" (RFC 3961),

·         "Advanced EncryptionStandard (AES) Encryption for Kerberos 5" (RFC 3962),

·         Una nueva edición de la especificación de la versión 5 de Kerberos "The Kerberos Network Authentication Service (V5)" (RFC 4120). Esta versión obvia el RFC 1510, aclara aspectos del protocolo y el uso previsto en una explicación clara más detallada,

·         Una nueva edición de la especificación GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Versión 2". (RFC 4121).

En 2007, el MIT formó el Consorcio Kerberos para continuar el desarrollo.

Protocolo

Kerberos utiliza como base el protocolo Needham-Schroeder. Hace uso de una tercera parte de confianza para la autenticación conocida como "centro de distribución de claves (KDC)", que consta de dos partes lógicamente separadas: un servidor de autenticación (AS) y un servidor de concesión de tickets (TGS). Kerberos funciona sobre la base de "tickets" (llamados tickets Kerberos) que sirven para demostrar la identidad de los usuarios.

Base de datos Kerberos: El centro de distribución de claves (KDC) mantiene una base de datos de claves secretas; cada entidad de la red -ya sea un cliente o un servidor- comparte una clave secreta conocida sólo por ella misma y por el KDC. El conocimiento de esta clave sirve para demostrar la identidad de cada entidad. Para la comunicación entre dos entidades, el KDC genera una clave de sesión que pueden utilizar para asegurar sus comunicaciones.

El término "servidor Kerberos" se refiere generalmente al KDC. Por motivos de fiabilidad, es posible tener KDC de reserva. Estos se denominan "servidores esclavos de Kerberos". Todos los esclavos sincronizan sus bases de datos desde el servidor Kerberos maestro.

El término "servidor de aplicaciones Kerberizado" generalmente se refiere a los programas Kerberizados con los que los clientes se comunican utilizando tickets Kerberos para la autenticación. Por ejemplo, el servidor telnet de Kerberos es un ejemplo de servidor de aplicaciones Kerberizado. Mientras que el término "aplicaciones Kerberizadas" se utiliza para referirse al lado cliente del servidor de aplicaciones Kerberizadas , Por ejemplo, el cliente telnet Kerberos es un ejemplo de aplicaciones Kerberizadas

La seguridad del protocolo depende en gran medida de:

1. Los participantes mantienen un tiempo poco sincronizado.
2. Una declaración de autenticidad de corta duración: los tickets Kerberos.

Descripción simplificada del protocolo

Se utilizarán las siguientes abreviaturas:

·         AS = Servidor de autenticación

·         TGS = Servidor de concesión de billetes

·         SS o Servidor = Servidor de servicios (usuario del servidor que solicita su servicio, como un servidor de impresión, un servidor de archivos,etc...)

·         TGT = Ticket Granting Ticket (ticket Kerberos para el TGS. Preparado por el AS, luego utilizado para hablar con el TGS).

En resumen, el cliente se autentifica ante el AS utilizando un secreto compartido a largo plazo y recibe un ticket del AS. Posteriormente, el cliente puede utilizar este ticket para obtener tickets adicionales para SS utilizando el mismo secreto compartido. Estos tickets pueden utilizarse para demostrar la autenticación a los SS.

El protocolo con más detalle

Pasos de inicio de sesión basados en el cliente del usuario:

1. Un usuario introduce un nombre de usuario y una contraseña en la máquina cliente.
2. El cliente realiza una función unidireccional (principalmente una función Hash) sobre la contraseña introducida, y ésta se convierte en la clave secreta del cliente/usuario.

Pasos de autenticación del cliente:

1. El cliente envía un mensaje en texto claro al AS solicitando servicios en nombre del usuario.
   Ejemplo de mensaje: "El usuario XYZ desea solicitar servicios".
   Nota: No se envía al EA ni la clave secreta ni la contraseña.
2. El AS comprueba si el cliente está en su base de datos. Si lo está, el AS devuelve al cliente los dos mensajes siguientes:
• Mensaje A: Clave de Sesión Cliente/TGS encriptada utilizando la clave secreta del cliente/usuario.
• Mensaje B: TGT (que incluye el ID del cliente, la dirección de red del cliente, el periodo de validez del ticket y la clave de sesión del cliente/TGS) cifrado mediante la clave secreta del TGS.
3. Una vez que el cliente recibe los mensajes A y B, descifra el mensaje A para obtener la clave de sesión cliente/TGS. Esta clave de sesión se utiliza para las comunicaciones posteriores con el TGS. En este punto, el cliente tiene suficiente información para autenticarse ante el TGS.
   Nota: El cliente no puede descifrar el mensaje B, ya que está cifrado con la clave secreta del TGS.

Pasos de autorización del servicio al cliente:

1. Al solicitar servicios, el cliente envía los dos mensajes siguientes al TGS:
• Mensaje C: Compuesto por el TGT del mensaje B y el ID del servicio solicitado.
• Mensaje D: Autenticador (que está compuesto por el ID del cliente y la marca de tiempo), encriptado usando la Clave de Sesión Cliente/TGS.
2. Al recibir los mensajes C y D, el TGS recupera el mensaje B del mensaje C. Descifra el mensaje B utilizando la clave secreta del TGS. De este modo, obtiene la clave de sesión Cliente/TGS. Usando esta clave, el TGS descifra el mensaje D (Autenticador) y envía los siguientes dos mensajes al cliente:
• Mensaje E: billete cliente-servidor (que incluye el ID del cliente, la dirección de red del cliente, el periodo de validez y la clave de sesión cliente-servidor) cifrado mediante la clave secreta SS.
• Mensaje F: Clave de Sesión Cliente/Servidor encriptada con la Clave de Sesión Cliente/TGS.

Pasos de la solicitud de servicio del cliente:

1. Al recibir los mensajes E y F del TGS, el cliente tiene suficiente información para autenticarse ante el SS. El cliente se conecta al SS y envía los dos mensajes siguientes:
• Mensaje E: del paso anterior (el ticket Cliente-Servidor, cifrado con la clave secreta SS).
• Mensaje G: un nuevo autentificador, que incluye el ID del cliente, la marca de tiempo y está encriptado utilizando la clave de sesión cliente/servidor.
2. El SS descifra el ticket utilizando su propia clave secreta para recuperar la clave de sesión cliente/servidor. Utilizando la clave de sesión, el SS descifra el autentificador y envía el siguiente mensaje al cliente para confirmar su verdadera identidad y su voluntad de servir al cliente:
• Mensaje H: la marca de tiempo encontrada en el Autentificador del cliente más 1, encriptada usando la Clave de Sesión Cliente/Servidor.
3. El cliente descifra la confirmación utilizando la clave de sesión cliente/servidor y comprueba si la marca de tiempo está correctamente actualizada. Si es así, el cliente puede confiar en el servidor y puede empezar a emitir solicitudes de servicio al servidor.
4. El servidor proporciona los servicios solicitados al cliente.

Inconvenientes

• Punto único de fallo: Requiere la disponibilidad continua de un servidor central. Cuando el servidor Kerberos no funciona, nadie puede iniciar la sesión. Esto puede resolverse utilizando varios servidores Kerberos y mecanismos de autenticación de emergencia.
• Kerberos requiere que los relojes de todos los hosts involucrados estén sincronizados. Los tickets tienen un periodo de disponibilidad de tiempo y si el reloj del host no está sincronizado con el del servidor Kerberos, la autenticación fallará. La configuración por defecto requiere que las horas de los relojes no estén separadas más de 10 minutos. En la práctica, se suele utilizar el protocolo de tiempo de red (NTP) para mantener sincronizados todos los hosts.
• El protocolo de administración no está estandarizado y difiere entre las implementaciones del servidor. Los cambios de contraseña se describen en el RFC 3244.
• Dado que las claves secretas de todos los usuarios se almacenan en el servidor central, un compromiso de ese servidor comprometerá las claves secretas de todos los usuarios.
• Un cliente comprometido comprometerá la contraseña del usuario.

Páginas relacionadas

• Gestión de la identidad
• Protocolo de contraseña remota segura (SRP)
• Interfaz de programa de los servicios de seguridad genéricos (GSS-API)