Kerberos (protocolo)

Kerberos () es un protocolo de autenticación de red informática que funciona sobre la base de tickets para permitir que los nodos se comuniquen a través de una red no segura para probar su identidad a uno otro de forma segura. Sus diseñadores lo dirigieron principalmente a un modelo cliente-servidor y proporciona autenticación mutua: tanto el usuario como el servidor verifican la identidad del otro. Los mensajes del protocolo Kerberos están protegidos contra escuchas ilegales y ataques de reproducción.

Kerberos se basa en criptografía de clave simétrica y requiere un tercero de confianza y, opcionalmente, puede usar criptografía de clave pública durante ciertas fases de autenticación. Kerberos usa el puerto UDP 88 de forma predeterminada.

El protocolo lleva el nombre del personaje Kerberos (o Cerberus) de la mitología griega, el feroz perro guardián de tres cabezas del Hades.

Historia y desarrollo

El Instituto Tecnológico de Massachusetts (MIT) desarrolló Kerberos en 1988 para proteger los servicios de red proporcionados por Project Athena. El protocolo se basa en el anterior protocolo de clave simétrica de Needham-Schroeder. Existen varias versiones del protocolo; las versiones 1-3 ocurrieron solo internamente en el MIT.

La versión 4 de Kerberos fue diseñada principalmente por Steve Miller y Clifford Neuman. Publicada a fines de la década de 1980, la versión 4 también estaba dirigida al Proyecto Athena.

Neuman y John Kohl publicaron la versión 5 en 1993 con la intención de superar las limitaciones y problemas de seguridad existentes. La versión 5 apareció como RFC 1510, que luego quedó obsoleta por RFC 4120 en 2005.

Las autoridades de los Estados Unidos clasificaron a Kerberos como "equipo militar auxiliar" en la Lista de municiones de EE. UU. y prohibió su exportación porque utilizaba el algoritmo de cifrado del Estándar de cifrado de datos (DES) (con claves de 56 bits). Una implementación de Kerberos 4 desarrollada en el Royal Institute of Technology de Suecia llamada KTH-KRB (renombrada como Heimdal en la versión 5) hizo que el sistema estuviera disponible fuera de EE. UU. antes de que EE. UU. cambiara sus regulaciones de exportación de criptografía (alrededor de 2000). La implementación sueca se basó en una versión limitada llamada eBones. eBones se basó en la versión exportada de MIT Bones (despojada tanto de las funciones de cifrado como de las llamadas a ellas) basada en la versión Kerberos 4 parche nivel 9.

En 2005, el grupo de trabajo Kerberos del Grupo de Trabajo de Ingeniería de Internet (IETF) actualizó las especificaciones. Actualizaciones incluidas:

• Especificaciones de cifrado y chequeo (RFC 3961).
• Encryption Standard (AES) Encryption for Kerberos 5 (RFC 3962).
• Una nueva edición de la especificación Kerberos V5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Esta versión obsoleta RFC 1510, aclara aspectos del protocolo y el uso previsto en una explicación más detallada y más clara.
• Una nueva edición de la interfaz del programa de aplicaciones de servicios de seguridad genéricos (GSS-API) especificación "La interfaz del programa de aplicaciones de servicio de seguridad genérico Versión 5 (GSS-API) Mecanismo: Versión 2" (RFC 4121).

MIT pone a disposición gratuitamente una implementación de Kerberos, con permisos de copyright similares a los que se utilizan para BSD. En 2007, el MIT formó el Consorcio Kerberos para fomentar el desarrollo continuo. Los patrocinadores fundadores incluyen proveedores como Oracle, Apple Inc., Google, Microsoft, Centrify Corporation y TeamF1 Inc. e instituciones académicas como el Instituto Real de Tecnología de Suecia, la Universidad de Stanford, el MIT y proveedores como CyberSafe que ofrece versiones con soporte comercial..

Microsoft Windows

Windows 2000 y versiones posteriores utilizan Kerberos como método de autenticación predeterminado. Algunas adiciones de Microsoft al conjunto de protocolos Kerberos están documentadas en RFC 3244 "Microsoft Windows 2000 Kerberos Cambiar contraseña y establecer protocolos de contraseña". RFC 4757 documenta el uso de Microsoft del cifrado RC4. Si bien Microsoft usa y amplía el protocolo Kerberos, no usa el software MIT.

Kerberos se usa como el método de autenticación preferido: en general, unir un cliente a un dominio de Windows significa habilitar Kerberos como el protocolo predeterminado para las autenticaciones de ese cliente a los servicios en el dominio de Windows y todos los dominios con relaciones de confianza con ese dominio.

Por el contrario, cuando el cliente, el servidor o ambos no están unidos a un dominio (o no forman parte del mismo entorno de dominio de confianza), Windows utilizará NTLM para la autenticación entre el cliente y el servidor.

Las aplicaciones web de Internet pueden aplicar Kerberos como método de autenticación para clientes unidos a un dominio mediante el uso de API proporcionadas bajo SSPI.

Microsoft Windows y Windows Server incluyen setspn, una utilidad de línea de comandos que se puede usar para leer, modificar o eliminar los nombres principales de servicio (SPN) para Active Directory cuenta de servicio

Unix y otros sistemas operativos

Muchos sistemas operativos similares a Unix, incluidos FreeBSD, OpenBSD, macOS de Apple, Red Hat Enterprise Linux, Solaris de Oracle, AIX de IBM, HP-UX y otros, incluyen software para Autenticación Kerberos de usuarios o servicios. Una variedad de sistemas operativos que no son similares a Unix, como z/OS, IBM i y OpenVMS, también cuentan con compatibilidad con Kerberos. La implementación integrada del protocolo de autenticación Kerberos V para agentes de clientes y servicios de red que se ejecutan en plataformas integradas también está disponible en empresas.

Protocolo

Descripción

El cliente se autentica en el Servidor de autenticación (AS) que reenvía el nombre de usuario a un centro de distribución de claves (KDC). El KDC emite un ticket de otorgamiento de boletos (TGT), que tiene una marca de tiempo y lo encripta usando la clave secreta del servicio de otorgamiento de boletos (TGS) y devuelve el resultado cifrado a la estación de trabajo del usuario. Esto se hace con poca frecuencia, normalmente en el inicio de sesión del usuario; el TGT caduca en algún momento, aunque el administrador de sesión del usuario puede renovarlo de forma transparente mientras está conectado.

Cuando el cliente necesita comunicarse con un servicio en otro nodo (un "principal", en la jerga de Kerberos), el cliente envía el TGT al TGS, que generalmente comparte el mismo host que el KDC. El servicio ya debe haber sido registrado en el TGS con un Service Principal Name (SPN). El cliente utiliza el SPN para solicitar acceso a este servicio. Luego de verificar que la TGT es válida y que el usuario tiene permiso para acceder al servicio solicitado, la TGS emite el ticket y las claves de sesión al cliente. Luego, el cliente envía el ticket al servidor de servicio (SS) junto con su solicitud de servicio.

KerberosNegociaciones

El protocolo se describe en detalle a continuación.

Inicio de sesión basado en cliente de usuario sin Kerberos

1. Un usuario introduce un nombre de usuario y contraseña en la máquina(s) del cliente. Otros mecanismos credenciales como pkinit (RFC 4556) permiten el uso de claves públicas en lugar de una contraseña. El cliente transforma la contraseña en la clave de un cifrado simétrico. Esto utiliza la programación de clave incorporada, o un hash de un solo sentido, dependiendo del código-suite utilizado.
2. El servidor recibe el nombre de usuario y el cifrado simétrico y lo compara con los datos de la base de datos. Iniciar sesión fue un éxito si el cifrado coincide con el cifrado que se almacena para el usuario.

Autenticación de cliente

1. El cliente envía un mensaje de texto claro del ID del usuario al AS (Authentication Server) solicitando servicios en nombre del usuario. (Nota: Ni la clave secreta ni la contraseña se envía a la AS.)
2. El AS verifica si el cliente está en su base de datos. Si lo es, el AS genera la clave secreta al piratear la contraseña del usuario que se encuentra en la base de datos (por ejemplo, Active Directory in Windows Server) y envía los siguientes dos mensajes al cliente:
   • Mensaje A: Clave de sesión cliente/TGS encriptado usando la clave secreta del cliente/usuario.
   • Mensaje B: Ticket-Granting-Ticket (TGT, que incluye el ID del cliente, la dirección de red del cliente, el período de validez del ticket y el Clave de sesión cliente/TGS) encriptado usando la clave secreta del TGS.
3. Una vez que el cliente recibe mensajes A y B, intenta descifrar el mensaje A con la clave secreta generada por la contraseña ingresada por el usuario. Si el usuario ingresa contraseña no coincide con la contraseña en la base de datos AS, la clave secreta del cliente será diferente y por lo tanto no puede descifrar el mensaje A. Con una contraseña válida y clave secreta el cliente descifra el mensaje A para obtener el Clave de sesión cliente/TGS. Esta clave de sesión se utiliza para nuevas comunicaciones con el TGS. (Nota: El cliente no puede descifrar el Mensaje B, ya que está encriptado usando la clave secreta de TGS.) En este punto, el cliente tiene suficiente información para autenticarse al TGS.

Autorización de Servicio al Cliente

1. Al solicitar servicios, el cliente envía los siguientes mensajes al TGS:
   • Mensaje C: Compuesto del mensaje B (el TGT cifrado utilizando la clave secreta de TGS) y el ID del servicio solicitado.
   • Mensaje D: Authenticator (que está compuesto por el ID del cliente y el timetamp), cifrado utilizando el Clave de sesión cliente/TGS.
2. Al recibir mensajes C y D, el TGS recupera el mensaje B del mensaje C. Descifra el mensaje B usando la clave secreta de TGS. Esto le da la Clave de sesión cliente/TGS y el ID del cliente (ambos están en el TGT). Usando esto Clave de sesión cliente/TGS, el mensaje de cifrado TGS D (Authenticator) y compara los IDs de los clientes de los mensajes B y D; si coinciden, el servidor envía los siguientes dos mensajes al cliente:
   • Mensaje E: Billete de cliente a servidor (que incluye el ID cliente, dirección de red cliente, período de validez y Cliente/Sesión del Usuario Clave) encriptado usando la clave secreta del servicio.
   • Mensaje F: Cliente/Sesión del Usuario Clave encriptado con el Clave de sesión cliente/TGS.

Solicitud de servicio al cliente

1. Al recibir mensajes E y F de TGS, el cliente tiene suficiente información para autenticarse al Servidor de Servicio (SS). El cliente se conecta a las SS y envía los siguientes dos mensajes:
   • Mensaje E: Desde el paso anterior (el Billete de cliente a servidor, encriptado usando la clave secreta del servicio).
   • Mensaje G: Un nuevo autenticador, que incluye el ID del cliente, el timetamp y está encriptado utilizando Cliente/Sesión del Usuario Clave.
2. La SS descifra el ticket (mensaje E) utilizando su propia clave secreta para recuperar el Cliente/Sesión del Usuario Clave. Utilizando la clave de las sesiones, SS descifra al autenticador y compara el ID de cliente de los mensajes E y G, si coinciden con el servidor envía el siguiente mensaje al cliente para confirmar su verdadera identidad y disposición para servir al cliente:
   • Mensaje H: El timetamp encontrado en el Authenticator del cliente (más 1 en la versión 4, pero no necesario en la versión 5), cifrado utilizando el Cliente/Sesión del Usuario Clave.
3. El cliente descifra la confirmación (mensaje H) utilizando el Cliente/Sesión del Usuario Clave y comprueba si el horario es correcto. Si es así, entonces el cliente puede confiar en el servidor y puede comenzar a emitir solicitudes de servicio al servidor.
4. El servidor proporciona los servicios solicitados al cliente.

Inconvenientes y limitaciones

• Kerberos tiene requisitos de tiempo estrictos, lo que significa que los relojes de los hosts involucrados deben sincronizarse dentro de límites configurados. Los boletos tienen un período de disponibilidad de tiempo, y si el reloj anfitrión no está sincronizado con el reloj servidor Kerberos, la autenticación fallará. La configuración predeterminada por MIT requiere que los tiempos de reloj no sean más de cinco minutos de distancia. En la práctica, los daemons Network Time Protocol se utilizan generalmente para mantener sincronizados los relojes host. Tenga en cuenta que algunos servidores (la implementación de Microsoft es uno de ellos) pueden devolver un resultado de KRB_AP_ERR_SKEW que contiene el tiempo de servidor cifrado si ambos relojes tienen un offset mayor que el valor máximo configurado. En ese caso, el cliente podría reiniciar calculando el tiempo utilizando el tiempo del servidor proporcionado para encontrar el offset. Este comportamiento está documentado en RFC 4430.
• El protocolo de administración no está estandarizado y difiere entre las implementaciones del servidor. Los cambios de contraseña se describen en RFC 3244.
• En caso de adopción de criptografía simétrica (Kerberos puede trabajar utilizando criptografía simétrica o asimétrica (público-key), ya que todas las autenticaciones están controladas por un centro centralizado de distribución clave (KDC), el compromiso de esta infraestructura de autenticación permitirá que un atacante infecte a cualquier usuario.
• Cada servicio de red que requiere un nombre de host diferente necesitará su propio conjunto de llaves Kerberos. Esto complica el alojamiento virtual y los racimos.
• Kerberos requiere cuentas de usuario y servicios para tener una relación de confianza con el servidor token Kerberos.
• La confianza necesaria del cliente hace difícil crear entornos escenificados (por ejemplo, dominios separados para entornos de prueba, entorno preproducción y entorno de producción): Es necesario crear relaciones de fideicomiso de dominio que impidan una separación estricta de los dominios del medio ambiente, o que se proporcionen clientes adicionales para cada entorno.

Vulnerabilidades

El cifrado del Estándar de cifrado de datos (DES) se puede usar en combinación con Kerberos, pero ya no es un estándar de Internet porque es débil. Existen vulnerabilidades de seguridad en muchos productos heredados que implementan Kerberos porque no se han actualizado para usar cifrados más nuevos como AES en lugar de DES.

En noviembre de 2014, Microsoft lanzó un parche (MS14-068) para corregir una vulnerabilidad explotable en la implementación de Windows del Centro de distribución de claves Kerberos (KDC). La vulnerabilidad supuestamente permite a los usuarios "elevar" (y abusar) de sus privilegios, hasta el nivel de Dominio.