explicar como tengo 5 años: Kerberos – ¿qué es Kerberos, y por qué debería importarme?
si bien este tema probablemente no se puede explicar a un niño de 5 años y ser entendido, este es mi intento de desfragmentar la documentación con algunas ayudas visuales y lenguaje digerible.,
en pocas palabras
básicamente, Kerberos se reduce a esto:
- un protocolo para la autenticación
- Utiliza tickets para autenticar
- evita almacenar contraseñas localmente o enviarlas a través de internet
- implica un tercero de confianza
- construido sobre criptografía de clave simétrica
usted tiene un ticket-su prueba de identidad cifrada con clave secreta para el servicio solicitado en particular: en su máquina local (la creación de un ticket se describe a continuación); siempre que sea válida, puede acceder al servicio solicitado que se encuentra dentro de un reino Kerberos.,
normalmente, esto se usa dentro de entornos corporativos/internos. Tal vez desee acceder a su sitio interno de nómina para revisar el pequeño bono que su jefe le ha dado. En lugar de volver a ingresar sus credenciales de usuario/Contraseña, su ticket (almacenado en caché en su sistema) se utiliza para autenticarse, lo que permite el inicio de sesión único.
Su ticket se actualiza cuando inicia sesión en su computadora o cuando kinit USER dentro de su terminal.
para los amantes de la trivia, el nombre de Kerberos proviene de la mitología griega, el perro guardián de tres cabezas de Hades., Es bastante apropiado, ya que se necesita un tercero (un centro de distribución de claves) para autenticarse entre un cliente y un servicio o máquina host.
Kerberos Realm
Los administradores crean reinos – reinos Kerberos – que abarcarán todo lo que está disponible para acceder. Por supuesto, es posible que no tenga acceso a ciertos Servicios o máquinas host que se definen dentro de la administración de políticas; los desarrolladores no deben acceder a nada relacionado con las finanzas, cosas como esas. Pero un reino define lo que Kerberos maneja en términos de quién puede acceder a qué.,
Su máquina, El Cliente, vive dentro de este ámbito, así como el servicio o host que desea solicitar y el Centro de distribución de claves, KDC (no, No el KGB, aunque siempre pienso en eso también). En el siguiente ejemplo, separo el servidor de autenticación y el servidor de concesión de Tickets, pero ambos están dentro del KDC.
para mantenerlo en el fondo de su mente
es posible que desee volver aquí después de leer los detalles arenosos sobre cómo funciona el ejemplo.,
al solicitar acceso a un servicio o host, se producen tres interacciones entre usted y:
- El Servidor de autenticación
- El Servidor de concesión de Tickets
- El servicio o máquina host al que desea acceder.
Otros puntos importantes:
- Con cada interacción, usted recibirá dos mensajes. Cada mensaje es uno que se puede descifrar, y uno que no se puede.
- El servicio o la máquina a la que solicita acceso nunca se comunica directamente con el KDC.,
- El KDC almacena todas las claves secretas para máquinas y servicios de usuario en su base de datos.
- Las claves secretas son contraseñas más una sal que son hash – el algoritmo hash se elige durante la implementación de la configuración de Kerberos. Para servicios o máquinas host, no hay contraseñas (quién las ingresaría). Una clave es realmente generada por un administrador durante la configuración inicial y memorizada en la máquina de servicio/host.
- de nuevo, estas claves secretas se almacenan en la base de datos de KDC; recordemos la confianza de los Kerberos en la criptografía de clave simétrica.,
- El KDC en sí está cifrado con una clave maestra para agregar una capa de dificultad para robar claves de la base de datos.
- hay configuraciones e implementaciones de Kerberos que utilizan criptografía de Clave Pública en lugar de cifrado de clave simétrica.
an aparte: el orden de los mensajes y su contenido discutido aquí no refleja el orden en el que se envían a través de TCP o UDP.
el siguiente ejemplo describe lo que sucede cuando solicita algo de un servicio HTTP interno, como información sobre nómina dentro de su intranet corporativa.,
usted y el servidor de autenticación
desea acceder a un servicio HTTP, pero primero debe presentarse al servidor de autenticación. Iniciar sesión en su computadora, o kinit USERNAME, inicia esa introducción a través de una solicitud de texto plano para un Ticket de concesión de Ticket (TGT)., El mensaje de texto sin formato contiene:
- Su Nombre / ID
- El nombre/ID del servicio solicitado (en este caso, el servicio es el servidor de concesión de Tickets),
- Su dirección de red (puede ser una lista de direcciones IP para varias máquinas, o puede ser nula si desea usar en cualquier máquina), y
- vida útil solicitada para la validez del TGT,
y se envía al servidor de autenticación.
El Servidor de autenticación comprobará si está en la base de datos de KDC. Esta comprobación es solo para ver si existe; no se comprueban credenciales.,
Si no hay errores (por ejemplo, no se encuentra el usuario), generará aleatoriamente una clave llamada clave de sesión para su uso entre usted y el servidor de concesión de Tickets (TGS).
el servidor de autenticación le enviará dos mensajes., Un mensaje es el TGT que contiene:
- Su Nombre/ID,
- El nombre/ID de TGS,
- marca de tiempo,
- Su dirección de red (puede ser una lista de direcciones IP para varias máquinas, o puede ser nula si desea usar en cualquier máquina)
- vida útil del TGT (podría ser lo que solicitó inicialmente, menor si usted o las claves secretas del TGS están a punto de expirar, u otro límite que se implementó durante la configuración de Kerberos), y
- clave de sesión TGS,
y está cifrada con la clave secreta TGS ., El otro mensaje contiene:
- El nombre/ID de TGS,
- timestamp,
- lifetime (igual que el anterior) y
- TGS Session Key
y está cifrado con su clave secreta de cliente. Tenga en cuenta que la clave de sesión TGS es la clave compartida entre usted y el TGS.
Su clave secreta de cliente se determina solicitándole su contraseña, añadiendo una sal (compuesta por ) y hash todo. Ahora puede usarlo para descifrar el segundo mensaje con el fin de obtener la clave de sesión TGS., Si la contraseña es incorrecta, no podrá descifrar el mensaje. Tenga en cuenta que este es el paso en el que la contraseña que ingresa se valida implícitamente.
Sin embargo, no puede descifrar el TGT ya que no conoce la clave secreta TGS. El TGT cifrado se almacena en la caché de credenciales.
usted y el servidor de concesión de Tickets
en este punto, tiene el TGT que no puede leer porque no tiene la clave secreta TGS para descifrarlo. Usted, sin embargo, tiene la clave de sesión TGS.,
ahora es tu turno de enviar dos mensajes. Primero prepara el autenticador, cifrado con la clave de sesión TGS, que contiene:
- Su Nombre / ID y
- marca de tiempo.
envía un mensaje sin cifrar que contiene:
- El nombre/ID del servicio HTTP solicitado al que desea acceder, y
- La vida útil del Ticket para el servicio HTTP,
junto con el autenticador cifrado y TGT al servidor de concesión de Tickets.
el servidor de concesión de Tickets primero comprobará la base de datos de KDC para ver si existe el servicio HTTP.,
Si es así, el TGS descifra el TGT con su clave secreta . Dado que el TGT ahora sin cifrar contiene la clave de sesión TGS, el TGS puede descifrar el autenticador que envió.,owing:
- compare su ID de cliente del Authenticator con el del TGT
- compare la marca de tiempo del Authenticator con la del TGT (la tolerancia típica de diferencia del sistema Kerberos es de 2 minutos, pero se puede configurar de otra manera)
- compruebe si el TGT ha expirado (el elemento lifetime),
- compruebe que el Authenticator>
- si la dirección de red en la solicitud original no es nula, compara la dirección IP de la fuente con su dirección de red (o dentro de la lista solicitada) dentro del TGT.,
el servidor de concesión de Tickets genera aleatoriamente la clave de sesión del servicio HTTP y prepara el ticket de servicio HTTP para usted que contiene:
- Su Nombre/ID,
- Nombre/ID del servicio HTTP,
- Su dirección de red (puede ser una lista de direcciones IP para varias máquinas, o puede ser nula si desea usar en cualquier máquina),
- marca de tiempo,
- /li>
- http service session key,
y la cifra con la clave secreta del servicio HTTP.
Entonces el TGS envía dos mensajes., Uno es el Ticket de servicio HTTP cifrado; el otro contiene:
- Nombre/ID del servicio HTTP,
- marca de tiempo,
- Duración de la validez del ticket y
- clave de sesión del servicio HTTP,
que está cifrada con la clave de sesión TGS.
Su máquina descifra el último mensaje con la clave de sesión TGS que almacenó anteriormente para obtener la clave de sesión del servicio HTTP.
Su máquina no puede, sin embargo, descifrar el Ticket de servicio HTTP, ya que está cifrado con la clave secreta del servicio HTTP.,
usted y el servicio HTTP
para acceder ahora al servicio HTTP, su máquina prepara otro mensaje de Autenticador que contiene:
- Su Nombre/ID,
- marca de tiempo,
y está cifrado con la clave de sesión del servicio HTTP. A continuación, su máquina envía el autenticador y el Ticket de servicio HTTP todavía cifrado recibido del TGS.
el servicio HTTP descifra el Ticket con su clave secreta para obtener la clave de sesión del servicio HTTP., A continuación, utiliza esa clave de sesión para descifrar el mensaje de autenticación que envió.,su ID de cliente del autenticador al del Ticket,
el servicio HTTP envía un mensaje de autenticación que contiene su ID y marca de tiempo para confirmarle su identidad y se cifra con la clave de sesión del servicio HTTP.
Su máquina lee el mensaje Authenticator descifrando con la clave de sesión del servicio HTTP en caché, y sabe que tiene que recibir un mensaje con el ID y la marca de tiempo del servicio HTTP.
Y ahora ha sido autenticado para utilizar el Servicio HTTP., Las solicitudes futuras utilizan el Ticket de servicio HTTP almacenado en caché, siempre que no haya caducado como se define en el atributo lifetime.
mientras escribiré sobre esto más adelante, el propio servicio HTTP debe ser capaz de soportar Kerberos. Además, también debe tener un navegador que soporte SPNEGO / Negotiate.,
tal vez vuelva a leer los puntos descritos anteriormente; eche un vistazo a esta o esta implementación actual, especialmente la en la que me pagan por trabajar que se comunica con esta implementación popular; o revise un tutorial, guía de recursos, el video de referencia que me enviaron cuando empecé a aprender sobre Kerberos, o el propio RFC.
Las imágenes de arriba fueron renderizadas con Keynote con iconos usados de Font awesome y glyphicons, y están disponibles en slideshare.