Kerberos: una de las aplicaciones más utilizadas como servicio de autentificación

Introducción

En la actualidad, el uso de aplicaciones que nos permitan verificar la identidad de los usuarios de una red es uno de los temas más preocupantes y fundamentales de la seguridad informática, pues, de lo contrario, cualquier usuario podría acceder a toda la información de una determinada red, indistintamente de su carácter confidencial o no.

Debido a ello, las empresas que no tengan mecanismos ni servicios de autentificación de usuarios pueden augurar grandes pérdidas tanto de información como económicas, pues los atacantes serían capaces de robar información y llevarla a su propia empresa, o bien, simplemente tomarla y eliminarla para afectar a la organización víctima.

Por lo anterior, se han desarrollado algunas aplicaciones que les brinden a las empresas y a sus redes la posibilidad de tener bien controlado quién es quién y qué cosas puede hacer realmente. Las más populares son Kerberos y X-509; en el presente ensayo, se describirá el protocolo que sigue el primero, Kerberos, en sus versiones 4 y 5.

Desarrollo

Kerberos es un protocolo de autentificación de los nodos de una red, creado a finales de los años 1980 por Steve Miller y Clifford Neuman, quienes trabajaban para el Proyecto Athena del Instituto Tecnológico de Massachusetts (MIT).  

Su nombre proviene del perro mitológico de la antigua Grecia, quien era un gran perro con tres cabezas que vigilaba la entrada del Hades, es decir, el inframundo. Este protocolo se llama así puesto que originalmente tendría tres funciones, aunque al final sólo cumplió con aquella de autentificación (es como si Hércules le hubiera cortado dos cabezas al perro).

Se han desarrollado cinco versiones, aunque las primeras tres fueron implementadas únicamente en dicha institución. La quinta versión fue publicada en 1993, y su sub-versión más estable data de hace mes y medio, es decir, del 25 de septiembre de 2017: krb5-1.15.2. Todas las versiones de Kerberos se basan en el cifrado convencional, o de clave secreta, a diferencia de la mayoría de los demás, quienes usan la de clave pública.

Existen tres amenazas principales por las que se creó Kerberos: por si un usuario opera desde una estación ajena de trabajo, altera la dirección de red de dicha estación, o visualiza la información confidencial para después repetirla.

Además de ser capaz de cubrir con las cuatro amenazas anteriores, Kerberos es muy utilizado por cubrir estas cuatro características: es seguro (impide totalmente los ataques, pasivos o activos), es fiable (tanto que todo el sistema fallaría si Kerberos llegara a fallar), es transparente (los usuarios no saben cómo se lleva a cabo la autentificación) y es escalable (puede soportar una gran cantidad de usuarios).

El protocolo de seguridad de la versión 4 de Kerberos es muy elaborado, pues se encarga de eliminar todo tipo de problemas relacionados al proceso de autenticación obligando al usuario a identificarse en cada paso, pero, a la vez, reduciendo considerablemente la cantidad de veces en que una contraseña deba ser ingresada. A continuación, explicaré con mis palabras el complicado protocolo que sigue la cuarta versión de Kerberos.

Este protocolo consta de cuatro entidades fundamentales: el cliente (y sus usuarios), un servidor de autenticación, un servidor “otorgador” de tickets y un servidor común de la red. El servidor de autenticación se encarga únicamente de validar que un usuario sea efectivamente quien dice ser, mientras que el servidor de tickets le otorga al usuario un documento en el que le da permiso de contactar a un servidor para ejecutar una determinada acción.

Kerberos utiliza aquellos dos servidores de manera distinta, y no como uno sólo, debido a que sería muy repetitivo tener que estar ingresando la contraseña del usuario cada que desee solicitarse un servicio. Al separarlos, la clave se introduce una sola vez al servidor de autenticación, mientras que por cada servicio diferente se solicita un ticket al otro servidor, quien ya no tiene que pedir ninguna clave.

En primer lugar, el cliente le envía al servidor de autentificación (SA) su propio identificador, el identificador del servicio otorgador de tickets con quien desea conectarse, y un sello de tiempo, con el fin de que el S. A. verifique que su reloj esté coordinado con el del cliente, y así emitir un tiempo de vida útil del ticket.

El servidor de autentificación responde con un ticket que a su vez permite que el cliente solicite otro ticket al servidor correspondiente. Dicha respuesta contiene una clave de sesión que compartirán el cliente y el servidor de tickets (TGS); así, este último podrá validar que el cliente es efectivamente él sin tener que introducir contraseñas. También incluye el ID del TGS solicitado, el momento de emisión del ticket y su tiempo de vida, y la dirección de red del cliente.

Los tiempos de vida se generan para evitar que un oponente espere hasta que un cliente se desconecte para que pueda suplantarlo; así, si espera demasiado, el tiempo de vida expirará y no podrá usarlo. Sin embargo, si el tiempo de vida es muy corto se tendrán que introducir contraseñas constantemente; y si es muy largo, un atacante tiene más oportunidad de usarlo.

Por ello se creó la clave de sesión, así, un TGS identifica al cliente y verifica que es el mismo a quien se expidió el ticket. Si el tiempo de vida es muy largo y un atacante logra tomar el ticket, no podrá hacerlo sin la clave de sesión.

La dirección de red se incluye por si un oponente intenta hacer un ataque de suplantación desde otra dirección; así, el SA o el TGS comprueban de dónde viene el cliente y si su dirección es la correcta.

El ticket que emite el AS está cifrado con una clave basada en la contraseña del usuario, la cual posee el SA en una base de datos. Por ello, cuando el cliente recibe el ticket, solicita al usuario su contraseña, y así poder descifrarlo. Si la contraseña es correcta, el ticket queda descifrado y ya puede utilizarse, evitando así que la contraseña clara sea enviada por la red.

El tercer paso ocurre cuando el cliente va con el TGS y le entrega el identificador del servicio que quiere solicitar, el ticket generado por el SA para garantizar que el usuario ya fue autentificado, y un autenticador extra para validar el ticket anterior, el cual contiene el ID del cliente, su dirección en la red, y su sello de tiempo.

El TGS devolverá al cliente el ticket que le da permiso de solicitar un servicio al servidor determinado. Este ticket es el más largo, pues contiene una clave de sesión que deberán compartir el cliente y el servidor final, el identificador de dicho servidor y del TGS, el identificador del cliente y su dirección, el sello de tiempo y tiempo de vida del ticket, y la clave de sesión. El ticket, además, se cifra con la clave de sesión que comparten el cliente y el TGS. Todo esto para autentificar que el cliente es efectivamente él.

Por último, el cliente envía al servidor final el ticket emitido por el TGS, así como su propio autenticador (con su ID y dirección). El servidor descifra el ticket, recupera la clave de sesión y descifrar el autenticador. Una vez pasado el proceso anterior, el servidor ya puede otorgar el servicio deseado.

Puede darse el caso, además de todo lo anterior, de que el servidor no esté autentificado, y por lo tanto esté suplantado por otro. Por ello, se agrega un paso más: el servidor debe autentificarse, devolviendo el sello de tiempo del ticket final incrementado en 1; el sólo hecho de haber devuelto el sello de tiempo quiere decir que el servidor es genuino, pues pudo descifrar el ticket con la clave compartida, y sumarle una unidad, sólo por convención.

A continuación, se anexa un diagrama que explica este laborioso pero cada vez más necesario proceso.

Figura 1. Esquema de la aplicación Kerberos. Tomada de Fundamentos de Seguridad en Redes.

Además, puede hacerse este mismo proceso con servidores Kerberos que estén fuera del dominio de otro servidor, es decir, que entre ellos no compartan los usuarios ni sus contraseñas. Dos servidores de dominios diferentes poseen claves secretas en común.

La versión 5 de Kerberos fue diseñada para hacerlo de uso más general, pues la cuarta versión aún estaba orientada al entorno local del proyecto Athena del MIT. William Stallings señala que había dos principales tipos de defectos que el Kerberos no cubría: los de entorno y técnicos.

Los de entorno se clasificaban en seis principales tipos: dependencia del sistema de cifrado (sólo admitía DES), dependencia del protocolo de Internet (sólo admitía direcciones IP), ordenación de los bytes del mensaje (se empleaba el orden deseado en vez del reglamentado), tiempo de vida del ticket (el tiempo límite era poco menos de un día), envío de autentificación (no se permitía que las credenciales emitidas a un cliente fueran usadas por otro), y autentificación entre dominios (se requerían más permisos para relaciones inter-dominios).

Los técnicos los clasifica en los aspectos concernientes al cifrado doble (es innecesario el segundo cifrado del protocolo), al cifrado PCBC (se incluía un tipo inseguro de cifrado), a las claves de sesión (no existían claves de sub-sesión, que brindan más seguridad) y a los ataques de contraseña (como el primer ticket se cifra con una clave basada en contraseñas, el descifrarlo por fuerza bruta podría desvelar la contraseña al cliente).

En cuanto al proceso de intercambio de servicio de autentificación (cliente con SA) y de TGT (cliente con TGS), se añaden nuevas características, como el dominio del usuario, algunas opciones determinadas del ticket de regreso, los tiempos de validez del ticket (inicio-fin) y nonce, un valor aleatorio que se debe repetir en la respuesta para garantizar que ésta es reciente y no ha sido interceptada. Por último, en el proceso de intercambio de autentificación cliente-servidor, se agregan dos elementos: una subclave, y un número de secuencia. Además, el sello de tiempo ya no se incrementa en uno.

Además, a los tickets se les puede poner algunos indicadores que describan algunas propiedades del ticket; éstas son INITAL, PRE-AUTHENT, HW-AUTHENT, RENEWABLE, MAY-POSTDATE, POSTDATED, INVALID, PROXIABLE, PROXY, FORWARDABLE y FORWARDED.

Conclusiones

En mi opinión, la aplicación Kerberos es únicamente funcional en aquellas grandes empresas que necesiten proporcionar seguridad y autenticación para guardar todos sus documentos, pues pueden manejar muchos archivos confidenciales y necesitan la aplicación para que ningún intruso pueda verlos, tomarlos, alterarlos o inclusive eliminarlos; además de tener los recursos económicos suficientes para poder pagar un servicio tan completo.

Sin embargo, no creo tan necesario que organizaciones pequeñas y/o locales deban utilizar Kerberos, pues deberían ser capaces de autentificar a sus usuarios por medios menos elaborados debido a la reducida cantidad de clientes que tienen con respecto a las otras empresas. Además, la implementación de aplicaciones como éstas implicaría un gasto excesivo de los recursos de la red, aunado al hecho de que ésta es local, en la mayoría de los casos.

Aunque a mí me gustan este tipo de aplicaciones por su complejidad y por lo que hacen, debo reconocer que me costó un poco de trabajo comprender del todo el protocolo que sigue Kerberos para autentificar a todos los usuarios de la red, pues utiliza muchos pasos que, como bien señala Stallings, parecen completamente innecesarios, pero que brindan mucha mayor seguridad a los sistemas ante los incesantes ataques y amenazas por parte de agentes externos.

Figura 2. Kerberos, el perro mitológico de tres cabezas, que cuidaba las puertas del Hares.