Kerberos
Introducción
La autenticación de clientes de acceso remoto es una cuestión de gran importancia para la seguridad de un sistema.
Cuando se tenía un sólo ordenador compartido entre varias personas, para ayudar a mantener los archivos individuales privados, se desarrolló el concepto de contraseña, para que los usuarios solo pudieran acceder a sus propios contenidos. Fue Fernando Corbató quien introdujo la idea mientras trabajaba en el Massachusetts Institute of Technology (MIT) en 1960.
En aquellos tiempos, el uso de contraseñas con este fin era bastante limitado, principalmente reducido a personas como Corbató y su equipo, que estaban entre los primeros que realmente exploraron el poder de las computadoras, por lo que no era importante o preocupante el hecho de que las contraseñas fueran simples y por lo tanto vulnerables.
En la actualidad, en un entorno de computación de red abierta, una estación de trabajo no es confiable para identificar correctamente a sus usuarios en los servicios de red. Kerberos proporciona un enfoque alternativo por el que se utiliza un servicio confiable de autenticación de terceros para verificar las identidades de los usuarios.
Kerberos
Kerberos es un servicio de autentificación que se desarrolló como parte del Proyecto Athena en el MIT. Fue diseñado para abordar el problema que plantea el hecho de que en un entorno abierto distribuido, los usuarios de las estaciones de trabajo quieran acceder a servicios de servidores distribuidos por toda la red.
El objetivo de éste es evitar solicitudes/respuestas fraudulentas entre servidores y usuarios que deben tener índole confidencial y en grupos de al menos un usuario y un servicio.
En el sistema Kerberos, el cliente que desea contactar con un servidor para que le dé un servicio, debe pedir primero un ticket de una tercera parte de mutua confianza, el KAS("Kerberos Authentication Server"). Este ticket se obtiene como una función en la que uno de los componentes es una llave privada conocida sólo por el servicio y el KAS, de modo que el servicio puede estar seguro de que el ticket procede sólo de Kerberos. El KAS conoce al cliente por su nombre principal(c). La llave privada(K(c)) es la llave de autentificación conocida sólo por el usuario y el KAS.
Proceso detallado:- Cliente -> KAS: El cliente envía un mensaje {c, tgs, n}, al KAS, que contiene su identidad(c), una palabra temporal o "nonce"(un sello de tiempo u otro forma de identificar su solicitud), y solicita un ticket para usarlo con el servidor de tickets(TGS).
- KAS -> Cliente: El servidor de autentificación busca el nombre del cliente(c) y el nombre del servicio(TGS, el servidor de tickets)
en la base de datos de Kerberos, y obtiene una llave de encriptación para cada uno de ellos K(c) y K(TGS).
El KAS crea a continuación una respuesta para enviársela al cliente.
Esta respuesta contiene un ticket inicial T(c,TGS) que garantiza al cliente acceso al servidor solicitado(el TGS). T(c, TGS) contiene k(c,TGS), c, TGS, el "nonce", el tiempo de vida y otra información.
El KAS también genera una llave aleatoria de encriptación K(c, TGS), llamada llave de sesión. Luego encripta este ticket usando la llave de encriptación del TGS(K(TGS)). Este procedimiento es lo que se denomina un ticket sellado {T( c,tgs)}K( tgs).
Inmediatamente se crea un mensaje consistente en el ticket sellado y la llave de sesión de TGS K(c, TGS). - Cliente -> TGS: A la recepción del mensaje, el cliente lo desencripta usando su llave secreta K(c) que es la única que él y el KAS conocen. Comprueba que el "nonce" (n) coincide con la solicitud específica, y entonces guarda la llave de sesión K (c,tgs) para futuras comunicaciones con el TGS.
El cliente envía a continuación un mensaje al TGS. Este mensaje contiene el ticket inicial {T(c,tgs)}K(tgs), el nombre del servidor(s), un "nonce", y un nuevo autentificador A(c) que lleva un sello de tiempo. A(c) es {c, nonce}.
El mensaje es: {A(c)}K(c,tgs), {T(c,TGS)}K(TGS), s, n - TGS -> Cliente: El TGS recibe el mensaje anterior del cliente(c), y descifra primero el ticket sellado usando su llave de encriptación TGS(este ticket fue sellado originalmente por el KAS usando la misma llave). El TGS obtiene la llave de sesión para TGS de del ticket descifrado, y la emplea a su vez para descifrar el autentificador sellado (la validez se chequea comparando el nombre del cliente tanto en el ticket como en el autentificador, el nombre del servidor TGS que figura en el ticket, la dirección de red que debe ser igual en el ticket, en el autentificador y en el mensaje recibido).
Finalmente, chequea la hora actual en el autentificador para cerciorarse de que el mensaje es reciente. Esto requiere que todos los clientes y servidores mantengan sus relojes dentro de cierto margen prescrito de tolerancia. Ahora el TGS busca el nombre del servidor que aparece en el mensaje en la base de datos de Kerberos, y obtiene la llave de encriptación(K(s)) para el servicio especificado.
El TGS crea una nueva llave aleatoria de sesión K(c,s) para el cliente(c) y el servidor, para generar a continuación un nuevo ticket. T(c,s) que contiene: K(c,s), n, "nonce", tiempo de vida.
Luego ensambla un mensaje y lo envía al cliente. - Cliente -> Servidor: El cliente recibe este mensaje y lo descifra usando la llave de sesión para el TGS que sólo comparten él y el TGS.
De este mensaje calcula una nueva llave de sesión K( c,s) que comparte con el servidor(s) y un ticket sellado que no puede descifrar porque está cifrado con la llave secreta del servidor K(s).
El cliente construye un autentificador y lo sella con la nueva llave de sesión K(c,s). Por último, envía un mensaje que contiene el ticket sellado y el autentificador al servidor(s) para solicitar su servicio.
El servidor(s) recibe este mensaje y descifra primero el ticket sellado con su llave de encriptación, conocida sólo por él y el KAS. Luego usa la nueva llave de sesión contenida en el ticket para descifrar el autentificador y realiza el mismo proceso de validación que el descrito en el paso 4.
Una vez que el servidor ha validado a un cliente, el cliente tiene la opción de validar a su vez al servidor. Esto evita que un intruso suplante al servidor.
El cliente requiere que el servidor le devuelva un mensaje con el sello de tiempo(procedente del autentificador del cliente, incrementado en uno). Este mensaje se cifra con la llave de sesión que pasó del cliente al servidor.
- Con el fin de que la estación de trabajo emplee cualquier servidor, se requiere un ticket. Todos los tickets, a excepción del primero(también llamado ticket inicial) se obtienen del TGS. El primer ticket es especial: es un ticket para el propio TGS y se obtiene del KAS.
- Cada ticket está asociado con una llave de sesión que se asigna cada vez que se concede un ticket.
- Los tickets son reutilizables. Cada ticket tiene un tiempo de vida, típicamente de ocho horas. Después de que un ticket ha expirado, el usuario ha de identificarse de nuevo al Kerberos, introduciendo el nombre de usuario y el password.
- A diferencia de un ticket, que puede ser reutilizado, hace falta un nuevo autentificador cada vez que el cliente inicia una conexión con el servidor. El autentificador contiene un sello de tiempo que expira a los pocos minutos de haber sido expedido(esta es la razón por la que los relojes de clientes y servidores deben estar sincronizados).
Un servidor debería mantener un seguimiento de las solicitudes anteriores de los clientes para las que el sello de tiempo en el identificador es aún válido. De este modo el servidor puede rechazar solicitudes duplicadas que podrían surgir de un ticket y un identificador robados.
Conclusiones
Los kerberos ofrecen muchas ventajas, como es, por ejemplo, que en vez de crear protocolos elaborados de autentificación en cada servidor, proporciona un servidor centralizado de autentificación cuya función es la de autentificar los usuarios al servidor y los servidores a los usuarios, por esta razón es un método muy utilizado.
Sin embargo, existen otras opciones de autenticación que probablemente seguirán mejorando, por lo que es recomendable probar todas las consideradas confiables para saber manejar alternativas.
Muy bien OuO
ResponderEliminarEs mi blog favorito, no hay mejor blog que éste.