Kerberos

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 21 de marzo de 2020; la verificación requiere 21 ediciones .

Kerberos /kɛərbərəs/ es un protocolo de autenticación de red que ofrece un mecanismo para la autenticación mutua de un cliente y un servidor antes de establecer una conexión entre ellos. Kerberos realiza la autenticación como un servicio de autenticación de terceros de confianza mediante un secreto criptográfico compartido, siempre que un atacante pueda interceptar, modificar y utilizar los paquetes que viajan a través de una red insegura. Kerberos se basa en criptografía de claves simétricas y requiere un centro de distribución de claves. Las extensiones de Kerberos pueden proporcionar el uso de criptografía de clave pública en ciertos pasos de autenticación.

Historial de creación

La primera versión del protocolo Kerberos se creó en 1983 en el Instituto Tecnológico de Massachusetts (MIT) como parte del proyecto Athena.. El objetivo principal del proyecto era desarrollar un plan para la introducción de computadoras en el proceso educativo del MIT y software relacionado. El proyecto fue educativo, pero el resultado final incluyó varios productos de software que todavía se usan ampliamente en la actualidad (como el sistema X Window ). Este protocolo está disponible públicamente desde la versión 4.

Conceptos básicos

Describamos el concepto básico del protocolo Kerberos. Supongamos que hay dos personas que conocen el mismo secreto, conocido solo por estos dos. Entonces cualquiera de ellos puede estar seguro de que está tratando con su pareja. Para ello, solo tiene que comprobar si su interlocutor conoce el secreto compartido.

Ejemplo.

Artículo 1. Acuerdo sobre la contraseña. Deja que Alice se comunique con Bob. En este caso, Bob usa la información solo cuando está seguro de que Alice la recibió. Para evitar la falsificación, acordaron entre ellos una contraseña que solo ellos dos conocen. Al recibir un mensaje, Bob puede deducir de la carta si su interlocutor conoce la contraseña. Si el interlocutor de Bob conoce la contraseña, se puede argumentar que su interlocutor es Alice.

Ítem 2. La ocurrencia de un problema de transmisión de contraseña. Ahora determinemos cómo mostrarle a Alice y Bob el conocimiento de la contraseña. Por supuesto, simplemente puede incluir la contraseña en el cuerpo del correo electrónico. Por ejemplo: “Hola Bob. Nuestra contraseña. Si Bob y Alice estuvieran seguros de que nadie lee sus cartas, entonces se podría usar este método. Pero, por desgracia, el correo se transmite a través de una red en la que trabajan otros usuarios, entre los que se encuentra una curiosa Eva. Eve se impuso la tarea de encontrar la contraseña, conocida solo por Bob y Alice, con la que intercambian mensajes entre ellos. Ahora está bastante claro que no puede especificar la contraseña simplemente en el cuerpo de la carta. Esto significa que no puede hablar abiertamente sobre la contraseña, pero al mismo tiempo debe informarle al interlocutor que conoce la contraseña.

Punto 3. Solucionar el problema de la transmisión de contraseñas. El protocolo Kerberos resuelve el problema de la transmisión de contraseñas mediante criptografía de clave secreta. En lugar de decirse una contraseña, los participantes en una sesión de comunicación intercambian una clave criptográfica, cuyo conocimiento confirma la identidad del interlocutor. Pero para que tal tecnología sea posible, es necesario que la clave compartida sea simétrica , es decir, la clave debe proporcionar tanto el cifrado como el descifrado del mensaje.

Punto 4. El problema del intercambio de contraseñas. Hay un problema importante cuando se utilizan protocolos simples como el descrito anteriormente. En el caso de Bob y Alice, debe comprender cómo acuerdan una clave secreta para comunicarse entre sí. Por supuesto, las personas pueden reunirse y ponerse de acuerdo, pero las máquinas también participan en las negociaciones de la red. Si Alice se entiende como un programa cliente y Bob como un servicio en un servidor de red, entonces no pueden encontrarse de ninguna manera. El problema es que cuando un cliente necesita enviar un mensaje a varios servidores, en este caso tendrá que adquirir una clave separada para cada servidor. Y luego el servidor necesitará tantas claves secretas como clientes tenga. La necesidad de almacenar tantas claves en cada ordenador supone un riesgo para todo el sistema de seguridad.

Punto 5. Solucionar el problema del intercambio de contraseñas. Para resolver estos problemas, el proyecto Athena desarrolló un protocolo especial: Kerberos. Por analogía con la mitología griega antigua, este protocolo recibió su nombre del perro de tres cabezas que protegía la salida del reino de Hades : Cerberus , o más precisamente, Cerberus. Las tres cabezas de Cerberus en el protocolo corresponden a tres participantes en la comunicación segura: un cliente, un servidor y un intermediario de confianza entre ellos. El papel de intermediario aquí lo desempeña el Centro de distribución de claves, KDC.

Centro de distribución de claves KDC (o TGS - servidor de tickets o permisos)

Un Centro de distribución de claves (KDC) es un servicio que se ejecuta en un servidor físicamente seguro. El Centro mantiene una base de datos con información sobre las cuentas de todos los clientes de la red. Junto con la información sobre cada suscriptor, la base de datos del centro de distribución de claves almacena una clave criptográfica conocida únicamente por este suscriptor y el servicio del centro. Esta clave se utiliza para conectar al cliente con el centro.

Cliente a servidor a través de KDC

Si el cliente quiere ponerse en contacto con el servidor, envía un mensaje al centro de distribución de claves. El Centro envía a cada participante de la sesión copias de la clave de sesión válida por un corto período de tiempo. El propósito de estas claves es autenticar al cliente y al servidor. Una copia de la clave de sesión enviada al servidor se cifra con la clave a largo plazo del servidor y se envía al cliente con la clave a largo plazo del cliente. Teóricamente, para realizar las funciones de un intermediario de confianza, basta con que un centro de distribución de claves envíe claves de sesión directamente a los suscriptores de seguridad. Sin embargo, es extremadamente difícil implementar tal esquema en la práctica. Por lo tanto, en la práctica, se utiliza un esquema de administración de contraseñas diferente, lo que hace que el protocolo Kerberos sea mucho más eficiente.

Entradas de sesión

En respuesta a una solicitud de un cliente que intenta conectarse al servidor, el servicio KDC envía ambas copias de la clave de sesión al cliente. El mensaje destinado al cliente se cifra con una clave a largo plazo compartida entre el cliente y el KDC, y la clave de sesión para el servidor, junto con la información sobre el cliente, se integra en un bloque de datos denominado ticket de sesión. A continuación, el ticket de sesión completo se cifra con una clave a largo plazo que solo conocen el servicio KDC y este servidor. A partir de ahí, toda la responsabilidad del procesamiento del ticket, que lleva la clave de sesión cifrada, recae en el cliente, que debe entregarlo al servidor. Al recibir la respuesta del KDC, el cliente extrae el ticket y su copia de la clave de sesión, que coloca en un almacenamiento seguro (no se encuentra en el disco, sino en la RAM ). Cuando necesita comunicarse con un servidor, el cliente le envía un mensaje que consiste en un ticket, aún encriptado con la clave a largo plazo del servidor, y su propio autenticador, encriptado con la clave de sesión. Esta credencial, combinada con el autenticador, constituye la credencial mediante la cual el servidor determina la "identidad" del cliente. El servidor, después de haber recibido la "tarjeta de identidad" del cliente, en primer lugar, utilizando su clave secreta, descifra el ticket de sesión y extrae la clave de sesión, que luego utiliza para descifrar el autenticador del cliente. Si todo va bien, se concluye que la identidad del cliente fue emitida por un intermediario de confianza, es decir, por el servicio KDC. El cliente puede requerir que el servidor realice la autenticación mutua. En este caso, el servidor, utilizando su copia de la clave de sesión, cifra la marca de tiempo del autenticador del cliente y la envía al cliente como su propio autenticador. Una ventaja de utilizar las credenciales de sesión es que el servidor no necesita almacenar claves de sesión para comunicarse con los clientes. Se almacenan en la "caché de credenciales" del cliente, que reenvía el ticket al servidor cada vez que quiere contactarlo. El servidor, por su parte, habiendo recibido el ticket del cliente, lo descifra y extrae la clave de sesión. Cuando ya no se necesita la clave, el servidor simplemente puede borrarla de su memoria. Este método tiene otra ventaja: el cliente no necesita ponerse en contacto con el KDC antes de cada sesión con un servidor específico. Las credenciales de sesión se pueden reutilizar. En caso de robo de los mismos, se fija la fecha de caducidad del ticket, que el KDC indica en la propia estructura de datos. Este tiempo está determinado por la política de Kerberos específica del dominio. Por lo general, el período de validez de los boletos no supera las ocho horas, es decir, la duración estándar de una sesión en la red. Cuando un usuario cierra sesión, la memoria caché de credenciales se restablece y todas las credenciales de sesión, junto con las claves de sesión, se destruyen.

Evolución del protocolo

Primeras versiones

MIT desarrolló Kerberos para proteger los servicios de red proporcionados por el proyecto Athena. El protocolo lleva el nombre del personaje mitológico griego Kerberos (o Cerberus ), conocido en la mitología griega como el monstruoso perro guardián de tres cabezas Hades. Hay varias versiones del protocolo. Las primeras versiones de Kerberos (1 a 3) fueron creadas internamente por el MIT y se utilizaron con fines de prueba. Estas implementaciones contenían limitaciones significativas y solo eran útiles para explorar nuevas ideas e identificar problemas que pudieran surgir durante el desarrollo.

Steve Miller y Clifford Neuman , los principales diseñadores de la versión 4 de Kerberos (que usaba el algoritmo de cifrado DES con claves de 56 bits), publicaron esta versión en 1989, aunque todavía la estaban planeando principalmente en ese momento en el proyecto Athena.

Kerberos 4

Kerberos 4 se publicó por primera vez el 24 de enero de 1989 . Fue la primera versión distribuida fuera del MIT, preparada para que varios proveedores la incluyeran en sus sistemas operativos. Además, otros grandes proyectos de sistemas distribuidos (por ejemplo, Andrew File System ) utilizaron las ideas de Kerberos 4 para sus sistemas de autenticación.

Los cimientos de lo que se convertiría en Kerberos 4 se describieron en el documento técnico de Athena [1] y la versión final se consolidó en el código fuente de la implementación de referencia publicada por el MIT.

Sin embargo, debido a las restricciones del gobierno de EE. UU. sobre la exportación de software cifrado, Kerberos 4 no se pudo distribuir fuera de los Estados Unidos. Dado que Kerberos 4 usaba el algoritmo DES para el cifrado , las organizaciones fuera de los Estados Unidos no podían usar el software legalmente. En respuesta, el equipo de desarrollo del MIT creó una versión especial de Kerberos 4, excluyendo todo el código relacionado con el cifrado. Estas medidas permitieron eludir la restricción a las exportaciones.

Posteriormente, Errol Young de la Universidad Bond de Australia agregó su propia implementación de DES a esta versión. Se llamó "E-Bones" (abreviatura de "huesos encriptados" [2] ) y se distribuyó gratuitamente fuera de los Estados Unidos.

En 2006, se anunció la compatibilidad con Kerberos 4 [3] .

Kerberos 5

Para superar los problemas de seguridad de la versión anterior, John Kohl y Clifford Neuman desarrollaron la versión 5 del protocolo, que se publicó en 1993 en RFC 1510 . Con el tiempo, en 2005, el grupo de trabajo de IETF Kerberos comenzó a trabajar con la especificación. Los documentos que han publicado incluyen:

características de cifrado y suma de comprobación ( RFC 3961 );
el Estándar de cifrado avanzado (AES) ( RFC 3962 );
Kerberos 5 "El servicio de autenticación de red Kerberos (V5)" ( RFC 4120 ), aclara algunos aspectos de RFC 1510 y tiene la intención de usarse para una descripción más detallada y clara;
nueva edición de la especificación GSS-API "El mecanismo de interfaz de programa de aplicación de servicio de seguridad genérico (GSS-API) Kerberos versión 5: versión 2". ( RFC 4121 ).

En junio de 2006, se introdujo el RFC 4556 que describía una extensión para la versión 5 denominada PKINIT (criptografía de clave pública para autenticación inicial en Kerberos ) . Este RFC describe cómo utilizar el cifrado asimétrico durante la fase de autenticación del cliente .

Al año siguiente (2007), el MIT formó el Consorcio Kerberos para promover un mayor desarrollo.

Uso y distribución

La distribución de la implementación de Kerberos se realiza bajo derechos de autor, de forma similar a los derechos de BSD.

Actualmente, muchos sistemas operativos admiten este protocolo, incluidos:

Windows 2000 y posteriores, que utilizan Kerberos como método de autenticación en un dominio entre miembros. Algunas adiciones a este protocolo se reflejan en RFC 3244 "Microsoft Windows 2000 Kerberos Cambiar contraseña y establecer protocolos de contraseña". RFC 4757 describe el uso de RC4 Kerberos en Windows;
varios sistemas operativos UNIX y similares a UNIX (Apple Mac OS X , Red Hat Enterprise Linux 4, FreeBSD , Solaris , AIX , OpenVMS ). Sin embargo, hay dos implementaciones de código abierto más utilizadas: MIT Kerberos y Heimdal, la última de las cuales se creó originalmente en Suecia debido a las restricciones a la exportación de software criptográfico desde los Estados Unidos .

Cómo funciona

Kerberos 4

Kerberos 4 se basa en gran medida en el protocolo Needham-Schroeder , pero con dos cambios significativos.

El primer cambio de protocolo redujo la cantidad de mensajes enviados entre el cliente y el servidor de autenticación.
El segundo cambio más significativo en el protocolo subyacente es la introducción del concepto TGT ( boleto de concesión de boletos ) , que permite a los usuarios autenticarse en múltiples servicios utilizando sus datos de confianza solo una vez.

Como resultado, el protocolo Kerberos 4 contiene dos componentes lógicos:

Servidor de autenticación (abreviado CA, ing. Servidor de autenticación, abreviado AS )

Servidor para emisión de tickets o permisos (ing. Ticket Granting Server, abreviatura TGS ).

Por lo general, estos componentes se entregan como un solo programa que se ejecuta en un centro de distribución de claves (KDC: contiene una base de datos de inicios de sesión/contraseñas para usuarios y servicios que utilizan Kerberos).

El servidor de autenticación realiza una función: recibe una solicitud que contiene el nombre del cliente que solicita la autenticación y le devuelve un boleto encriptado para obtener un boleto (TGT). Luego, el usuario puede usar este boleto para solicitar boletos posteriores para otros servicios. En la mayoría de las implementaciones de Kerberos, la vida útil de TGT es de 8 a 10 horas. Después de eso, el cliente debe volver a solicitarlo al servidor de autenticación.

El primer mensaje enviado al centro de distribución de claves es una solicitud al servidor de autenticación, también conocido como AS_REQ. Este mensaje se envía en texto no cifrado y contiene la identidad del cliente, la marca de tiempo del cliente y el identificador del servidor de concesión de tickets (TGS).

Cuando el centro de distribución de claves recibe un mensaje AS_REQ, verifica que el cliente del que proviene la solicitud exista y que su marca de tiempo esté cerca de la hora local del centro (generalmente ± 5 minutos). Esta verificación no se realiza para protegerse contra las repeticiones (el mensaje se envía en texto claro), sino para verificar el tiempo. Si al menos una de las comprobaciones falla, se envía un mensaje de error al cliente y no se autentica.

Si tiene éxito, el servidor de autenticación genera una clave de sesión aleatoria que se compartirá entre el cliente y el vale o el servidor de concesión (esta clave protege futuras solicitudes de vales para otros servicios). El Centro de distribución de claves crea 2 copias de la clave de sesión: una para el cliente y otra para el servidor de concesión de tickets.

Luego, el centro de distribución de claves responde al cliente con un mensaje del servidor de autenticación (AS_REP) encriptado con la clave a largo plazo del cliente. Este mensaje incluye el TGT encriptado con la clave TGS, una copia de la clave de sesión del cliente, la vigencia del ticket y el ID de TGS (el TGT contiene: una copia de la clave de sesión del TGS, la ID del cliente, la vigencia del ticket, Marca de tiempo del centro de distribución de claves (KDC), cliente de dirección IP).

Cuando el usuario quiera acceder al servicio, preparará un mensaje para TGS_REQ que constará de 3 partes: el identificador del servicio, la copia de la TGT recibida anteriormente y el autenticador (el autenticador consiste en un sello de tiempo encriptado con la clave de sesión recibida del servidor de autenticación y sirve para proteger contra repeticiones).

Al recibir una solicitud de ticket de un cliente, el KDC genera una nueva clave de sesión para la interacción cliente/servicio. Luego envía un mensaje de respuesta (TGS_REP) encriptado con la clave de sesión recibida del servidor de autenticación. Este mensaje contiene la nueva clave de sesión, el ticket de servicio cifrado con la clave de servicio a largo plazo, la ID del servicio y la vigencia del ticket (contiene una copia de la nueva clave de sesión, la ID del cliente, la vigencia del ticket, la hora local del centro de distribución de claves, la dirección IP del cliente ).

Kerberos 4 no estandariza los detalles del último paso, el envío del ticket de servicio al servidor de aplicaciones, por lo que su implementación depende completamente de la aplicación.

Kerberos 5

Kerberos 5 es un desarrollo de la cuarta versión, incluye toda la funcionalidad anterior y contiene muchas extensiones. Sin embargo, desde el punto de vista de la implementación, Kerberos 5 es un protocolo completamente nuevo.

La razón principal de la aparición de la quinta versión fue la imposibilidad de expansión. Con el tiempo, un ataque de fuerza bruta al DES utilizado en Kerberos 4 se volvió relevante, pero los campos utilizados en los mensajes tenían un tamaño fijo y no era posible utilizar un algoritmo de cifrado más fuerte.

Para solucionar este problema, se decidió crear un protocolo extensible que se pueda utilizar en varias plataformas basado en la tecnología ASN.1. Esto permitió el uso de varios tipos de cifrado en las transacciones. Gracias a esto, se implementó la compatibilidad con la versión anterior. Además, el KDC tiene la capacidad de elegir el protocolo de cifrado más seguro admitido por las partes participantes.

Además, el protocolo Kerberos 4 original está sujeto a enumeración de diccionario. Esta vulnerabilidad está relacionada con el hecho de que el KDC emite un TGT encriptado bajo demanda a cualquier cliente. La importancia de este problema también se enfatiza por el hecho de que los usuarios suelen elegir contraseñas simples.

Para dificultar este ataque, Kerberos 5 introdujo la autenticación previa. En esta etapa, el KDC requiere que el usuario verifique su identidad antes de que se le pueda emitir un boleto.

La política de KDC es responsable de la autenticación previa, si es necesaria, el usuario recibirá un mensaje KRB_ERROR en la primera solicitud al servidor de autenticación. Este mensaje le indicará al cliente que envíe una solicitud AS_REQ con sus credenciales para autenticarse. Si el KDC no los reconoce, el usuario recibirá otro mensaje KRB_ERROR que indica un error y no se emitirá ningún TGT.

Descripción formal Notaciones criptográficas utilizadas en protocolos de autenticación e intercambio de claves

$A$	Identificadores de Alice ( Alice ), la iniciadora de la sesión
$B$	Identificador de Bob ( Bob ), el lado desde el que se establece la sesión
$T$	Identificador de Trent ( Trent ), una parte intermediaria de confianza
$K_{A},K_{B},K_{T}$	Las claves públicas de Alice, Bob y Trent
$K_{A}^{-1},K_{B}^{-1},K_{T}^{-1}$	Claves secretas de Alice, Bob y Trent
$E_{A},\izquierda\{...\derecha\}_{K_{A}}$	Cifrado de datos con la clave de Alice o la clave conjunta de Alice y Trent
$E_{B},\izquierda\{...\derecha\}_{K_{B}}$	Cifrado de datos con la clave de Bob o la clave conjunta de Bob y Trent
$\izquierda\{...\derecha\}_{K_{B}^{-1}},\izquierda\{...\derecha\}_{K_{A}^{-1}}$	Cifrado de datos con claves secretas de Alice, Bob (firma digital)
$yo$	Número de secuencia de la sesión (para evitar ataques de reproducción)
$k$	Clave de sesión aleatoria que se utilizará para el cifrado de datos simétrico
$E_{K},\izquierda\{...\derecha\}_{K}$	Cifrado de datos con una clave de sesión temporal
$T_{A},T_{B}$	Marcas de tiempo añadidas a los mensajes por Alice y Bob respectivamente
$R_{A},R_{B}$	Números aleatorios ( nonce ) que fueron elegidos por Alice y Bob respectivamente

El protocolo utiliza solo cifrado simétrico y supone que cada corresponsal (Alice y Bob) comparte una clave secreta con un tercero de confianza (Trent).

Alice envía su identificación y Bob a la parte de confianza (Trent):

Alicia\a\izquierda\{A,B\derecha\}\a Trent

Trent genera dos mensajes. El primero incluye la marca de tiempo , la vigencia de la clave , la nueva clave de sesión para Alice y Bob , y la ID de Bob . Este mensaje está encriptado con la clave compartida de Alice y Trent. El segundo mensaje contiene lo mismo, excepto por el identificador: se reemplazó con el identificador de Alice . El mensaje en sí está encriptado con la clave compartida de Trent y Bob: $T_{T}$ $L$ $k$ $B$ $A$

Trent\to \left\{E_{A}\left(T_{T},L,K,B\right),E_{B}\left(T_{T},L,K,A\right)\right \}\a Alicia

Alice genera un mensaje a partir de su propia ID y una marca de tiempo , luego cifra el mensaje con la clave de sesión y se lo envía a Bob junto con el segundo mensaje de Trent: $A$ $T_{T}$ $k$

Alice\to \left\{E_{K}\left(A,T_{T}\right),E_{B}\left(T_{T},L,K,A\right)\right\}\to Beto

Para su propia autenticación, Bob cifra la marca de tiempo modificada con una clave de sesión compartida y se la envía a Alice: $T_{T}+1$ $k$

Bob\a \left\{E_{K}\left(T_{T}+1\right)\right\}\to Alice

Una suposición importante es que los relojes de todos los participantes del protocolo están sincronizados. Sin embargo, en la práctica, la sincronización se utiliza con una precisión de varios minutos, con el historial de transmisión almacenado (para detectar repeticiones) durante algún tiempo.

Descripción detallada

La forma en que Kerberos 5 funciona actualmente es la siguiente:

Inicio de sesión de usuario:

El usuario ingresa un nombre de usuario y contraseña en la máquina cliente.
La máquina cliente realiza una función unidireccional (generalmente un hash) en la contraseña y el resultado se convierte en la clave secreta del cliente/usuario.

Autenticación del cliente:

El cliente envía una solicitud (AS_REQ) a la CA para obtener las credenciales de autenticación y luego proporcionarlas al servidor TGS (luego las usará para obtener las credenciales sin solicitudes adicionales para usar la clave secreta del usuario). Esta solicitud contiene:
- El ID del cliente, su marca de tiempo y el ID del servidor.
Si la política de KDC requiere autenticación previa, el usuario recibe un mensaje KRB_ERROR, en respuesta al cual envía una segunda solicitud, pero con datos de autenticación.
La CA comprueba si existe tal cliente en la base de datos. Si es así, la CA devuelve un mensaje (AS_REP) que incluye:
- La clave de sesión del cliente o TGS, el identificador TGS y el tiempo de vida del ticket , encriptados con la clave privada del cliente .
- TGT (que incluye el ID del cliente y la dirección de red, la marca de tiempo del KDC, el período de validez del ticket y la clave de sesión del cliente o TGS) encriptado con la clave secreta de TGS.

De lo contrario, el cliente recibe un nuevo mensaje que indica que se ha producido un error.

Al recibir el mensaje, el cliente descifra su parte para obtener la clave de sesión del cliente, o TGS. Esta clave de sesión se utiliza para posteriores intercambios con el servidor TGS. (Importante: el cliente no puede descifrar el TGT porque está cifrado con la clave secreta de TGS) En este punto, el usuario tiene suficientes credenciales para iniciar sesión en el TGS.

Autorización de clientes en TGS:

Para solicitar un servicio, el cliente genera una solicitud de TGS (TGS_REQ) que contiene los siguientes datos:
- TGT recibido anteriormente e ID de servicio.
- Un autenticador (compuesto por un ID de cliente y una marca de tiempo) encriptado en la clave de sesión del cliente/TGS.
Al recibir el TGS_REQ, TGS extrae el TGT y lo descifra utilizando la clave secreta de TGS. Esto le da la clave de sesión del cliente, o TGS. Con él, descifra el autenticador. Luego genera una clave de sesión de cliente/servicio y envía una respuesta (TGS_REP) que incluye:
- ticket de servicio (que contiene el ID del cliente, la dirección de red del cliente, la marca de tiempo del KDC, la hora de caducidad del ticket y la clave de sesión del cliente/servicio) cifrada con la clave secreta del servicio.
- La clave de sesión del cliente/servicio, el identificador del servicio y la duración del ticket encriptados en la clave de sesión del Cliente/TGS.

Solicitud de servicio por cliente:

Después de recibir TGS_REP, el cliente tiene información suficiente para autorizar el servicio. El cliente se conecta y envía un mensaje que contiene:
- El ticket de servicio encriptado recibido anteriormente.
- Un nuevo autenticador encriptado con la clave de sesión del cliente/servicio e incluyendo el ID del cliente y la marca de tiempo.
El servicio descifra el ticket utilizando su clave privada y obtiene la clave de sesión del cliente/servicio. Usando la nueva clave, descifra el autenticador y envía el siguiente mensaje al cliente para confirmar que está listo para atender al cliente y que el servidor es realmente quien dice ser:
- La marca de tiempo especificada por el cliente + 1 , cifrada con la clave de sesión del cliente/servicio.
El cliente descifra la confirmación utilizando la clave de sesión del cliente/servicio y comprueba que la marca de tiempo se ha actualizado correctamente. Si es así, el cliente puede confiar en el servidor y puede comenzar a enviar solicitudes al servidor.
El servidor proporciona al cliente el servicio solicitado.

PKINIT

La extensión PKINIT afectó la etapa de preautenticación del cliente, luego de lo cual comenzó a ocurrir de la siguiente manera:

El usuario se identifica en el sistema y presenta su clave privada.
La máquina cliente emite una solicitud a la CA (AS_REQ) indicando que se utilizará el cifrado asimétrico. La diferencia de esta solicitud es que está firmada (utilizando la clave privada del cliente) y, además de la información estándar, contiene el certificado de clave pública del usuario.
Al recibir la solicitud, el KDC primero verifica la validez del certificado del usuario y luego la firma digital (utilizando la clave pública del usuario recibida) . Después de eso, el KDC verifica la hora local enviada en la solicitud (para protegerse contra las repeticiones) .
Una vez verificada la autenticidad del cliente, el KDC genera una respuesta (AS_REP), en la que, a diferencia de la versión estándar, la clave de sesión se cifra con la clave pública del usuario. Además, la respuesta contiene el certificado KDC y está firmada con su clave privada (similar a la solicitud del cliente) .
Al recibir la respuesta, el usuario verifica la firma del KDC y descifra su clave de sesión (utilizando su clave privada) .

Los pasos adicionales ocurren de acuerdo con la descripción estándar de Kerberos V5.

Desventajas y limitaciones

Punto único de falla: Requiere un servidor central en todo momento. Cuando el servidor Kerberos deja de funcionar, los nuevos usuarios no pueden iniciar sesión. Esto se puede solucionar con varios servidores Kerberos y mecanismos de autenticación alternativos.
Kerberos tiene requisitos de tiempo estrictos, lo que significa que los relojes de los participantes deben mantenerse sincronizados dentro de los límites especificados. Las credenciales tienen vigencia y si el reloj del cliente no está sincronizado con el reloj del servidor Kerberos, la autenticación fallará. La configuración predeterminada requiere que los relojes no estén separados por más de cinco minutos. En la práctica, los daemons del protocolo de tiempo de red se utilizan normalmente para sincronizar los relojes de los clientes.
El protocolo de administración no está estandarizado y depende de la implementación específica del servidor. El cambio de contraseña se describe en RFC 3244.
En el caso de la criptografía simétrica (Kerberos puede funcionar con criptografía tanto simétrica como asimétrica (clave pública), dado que todos los métodos de autenticación son administrados centralmente por el centro de distribución de claves (KDC), esta función de la infraestructura de autenticación permitirá que un atacante se haga pasar por un usuario.
Cada servicio de red que requiera un cambio de nombre de host deberá actualizar su propio conjunto de claves Kerberos. Esto complica el uso de alojamiento compartido y clústeres.
Kerberos requiere que las cuentas de usuario, los clientes y los usuarios del servicio en el servidor confíen en el servidor Kerberos (todos deben estar en el mismo dominio con Kerberos o en dominios que tengan una relación de confianza entre sí). Kerberos no se puede usar en los casos en que los usuarios desean conectarse a servicios de clientes desconocidos o que no son de confianza, como en Internet normal.

Vulnerabilidades

El cifrado DES se puede usar con Kerberos, sin embargo, ya no es un estándar de Internet porque es vulnerable. Sin embargo, existen vulnerabilidades en muchos productos que utilizan Kerberos que no se han actualizado para reemplazar DES con cifrados más nuevos, como AES, por ejemplo.

En noviembre de 2014, Microsoft lanzó un parche (MS14-068) para corregir una vulnerabilidad en la implementación de Windows del servidor KDC. La vulnerabilidad, según el comunicado, permitía a los usuarios "elevar" sus privilegios al nivel del dominio.

Véase también

Tecnología de inicio de sesión único
gestión de identidad
SPNEGO
S/clave
SRP (Protocolo de contraseña remota segura)
GSS-API (interfaz de programa de aplicación de servicios de seguridad genéricos)
Protocolo de identidad del host (HIP)

Notas

↑ Plan técnico Archivado el 1 de enero de 2016 en Athena Project Wayback Machine .
↑ Historia del nombre E-Bones (enlace inaccesible)
↑ Anuncio de fin de vida útil de la versión 4 de Kerberos . Consultado el 11 de noviembre de 2011. Archivado desde el original el 3 de noviembre de 2011. (indefinido)

Literatura

Schneier B. Capítulo 3. Protocolos básicos. Protocolo Kerberos // Criptografía aplicada. Protocolos, algoritmos, código fuente en lenguaje C = Criptografía Aplicada. Protocolos, Algoritmos y Código Fuente en C. - M. : Triumf, 2002. - P. 81. - 816 p. - 3000 copias. - ISBN 5-89392-055-4 .
Schneier B. Capítulo 24. Ejemplos de implementaciones prácticas. Protocolo KERBEROS // Criptografía aplicada. Protocolos, algoritmos, código fuente en lenguaje C = Criptografía Aplicada. Protocolos, Algoritmos y Código Fuente en C. - M. : Triumf, 2002. - S. 627-633. — 816 pág. - 3000 copias. - ISBN 5-89392-055-4 .
Jason Garman . 1-3 // Kerberos: La guía definitiva (neopr.) . - 2003. - ISBN 0-596-00403-6 .
Schneier B. Capítulo 24.5 Kerberos Bruce Schneier // Criptografía aplicada. Protocolos, algoritmos, código fuente en lenguaje C = Criptografía Aplicada. Protocolos, Algoritmos y Código Fuente en C. - M. : Triumph, 2002. - 816 p. - 3000 copias. - ISBN 5-89392-055-4 .

Enlaces

Protocolos de autenticación e intercambio de claves
Con algoritmos simétricos	Rana de boca ancha Yahalom Protocolo de Needham-Schroeder Protocolo Otway-Risa Kerberos Protocolo Newman-Stubblebine
Con algoritmos simétricos y asimétricos	DASS Protocolo Denning-Sacco Protocolo Wu Lam SPKM
Protocolos y servicios utilizados en Internet	OAuth identificación abierta Identificación de Windows Live