KERBEROS

DEFINICIÓN

Kerberos es un protocolo de validación de identificación usado en muchos sistemas reales, basado en una variación del de Needham-Schroeder; se llama así por un perro de varias cabezas de la mitología griega que solía cuidar la entrada al averno (supuestamente para mantener fuera a los indeseables). Kerberos se diseñó en el M.I.T. para permitir a los usuarios de estaciones de trabajo el acceso a recursos de una manera segura; su principal diferencia respecto del protocolo de Needham-Schroeder es el supuesto de que todos los relojes están bastante bien sincronizados.

HISTORIA

Durante 1983 en el M.I.T. ( Massachussetts Institute of Technology) comenzó el proyecto Athena con el objetivo de crear un entorno de trabajo educacional compuesto por estaciones gráficas, redes de alta velocidad y servidores; el sistema operativo para implementar este entorno era Unix 4.3BSD, y el sistema de autenticación utilizado en el proyecto se denominó Kerberos en honor al perro de tres cabezas que en la mitología griega vigila la puerta de entrada a Hades, el infierno.

Hasta que se diseñó Kerberos, la autenticación en redes de computadores se realizaba principalmente de dos formas: o bien se aplicaba la autenticación por declaración (Authentication by assertion) o bien se utilizaban contraseñas para cada servicio de red. Evidentemente el primer modelo proporciona un nivel de seguridad muy bajo y el segundo modelo obliga al usuario a ir tecleando continuamente su clave. Kerberos trata de mejorar estos esquemas intentando por un lado que un cliente necesite autorización para comunicar con un servidor (y que esa autorización provenga de una máquina confiable), y por otro eliminando la necesidad de demostrar el conocimiento de información privada (la contraseña del usuario) divulgando dicha información.

Kerberos se ha convertido desde entonces en un referente obligatorio a la hora de hablar de seguridad en redes. Se encuentra disponible para la mayoría de sistemas Unix, y viene integrado con OSF/DCE ( Distributed Computing Environment). Está especialmente recomendado para sistemas operativos distribuidos, en los que la autenticación es una pieza fundamental para su funcionamiento: si conseguimos que un servidor logre conocer la identidad de un cliente puede decidir sobre la concesión de un servicio o la asignación de privilegios especiales. Sigue vigente en la actualidad (en su versión V), a pesar del tiempo transcurrido desde su diseño; además fue el pionero de los sistemas de autenticación para sistemas en red, y muchos otros diseñados posteriormente, como KryptoKnight, SESAME o Charon se basan en mayor o menor medida en Kerberos.

ELEMENTOS

Un servidor Kerberos se denomina KDC ( Kerberos Distribution Center), y provee de dos servicios fundamentales: el de autenticación (AS, Authentication Service) y el de tickets (TGS, Ticket Granting Service). El primero tiene como función autenticar inicialmente a los clientes y proporcionarles un ticket para comunicarse con el segundo, el servidor de tickets, que proporcionará a los clientes las credenciales necesarias para comunicarse con un servidor final que es quien realmente ofrece un servicio. Además, el servidor posee una base de datos de sus clientes (usuarios o programas) con sus respectivas claves privadas, conocidas únicamente por dicho servidor y por el cliente que al que pertenece.

La arquitectura de Kerberos está basada en tres objetos de seguridad: Clave de Sesión, Ticket y Autenticador.

• La clave de sesión es una clave secreta generada por Kerberos y expedida a un cliente para uso con un servidor durante una sesión; no es obligatorio utilizarla en toda la comunicación con el servidor, sólo si el servidor lo requiere (porque los datos son confidenciales) o si el servidor es un servidor de autenticación. Se suele denominar a esta clave KCS , para la comunicación entre un cliente C y un servidor S.

Las claves de sesión se utilizan para minimizar el uso de las claves secretas de los diferentes agentes: éstas últimas son válidas durante mucho tiempo, por lo que es conveniente para minimizar ataques utilizarlas lo menos posible.

• El ticket es un testigo expedido a un cliente del servicio de tickets de Kerberos para solicitar los servicios de un servidor; garantiza que el cliente ha sido autenticado recientemente. A un ticket de un cliente C para acceder a un servicio S se le denomina {ticket (C, S)} KS = { C, S, t1, t2 }KS . Este ticket incluye el nombre del cliente C, para evitar su posible uso por impostores, un periodo de validez { t1 , t2 } y una clave de sesión KS asociada para uso de cliente y servidor. Kerberos siempre proporciona el ticket ya cifrado con la clave secreta del servidor al que se le entrega.

• El autenticador es un testigo construido por el cliente y enviado a un servidor para probar su identidad y la actualidad de la comunicación; sólo puede ser utilizado una vez. Un autenticador de un cliente C ante un servidor S se denota por { auth ( C ) KCS = { C, t } KCS . Este autenticador contiene, cifrado con la clave de la sesión, el nombre del cliente y un timestamp.

Kerberos sigue de cerca el protocolo de Needham y Schroeder con clave secreta, utilizando timestamps como pruebas de frescura con dos propósitos: evitar reenvíos de viejos mensajes capturados en la red o la reutilización de viejos tickets obtenidos de zonas de memoria del usuario autorizado, y a la vez poder revocar a los usuarios los derechos al cabo de un tiempo.

OPERATIVO DE FUNCIONAMIENTO

Kerberos comprende tres servidores sdemás de Alicia (una estación de trabajo cliente):

El AS comparte una contraseña secreta con cada usuario. El trabajo del TGS es emitir billetes que puedan convencer a los servidores de que el portador del billete TGS en realidad es quien dice ser.

Para iniciar una sesión, Alicia se sienta frente a una estación de trabajo pública arbitraria y teclea su nombre. La estación de trabajo envía su nombre al AS como texto normal, como se ve en la siguiente figura.

Lo que regresa es una clave de sesión y un billete, KTGS (A, KS ), dirigido al TGS. Estos elementos se empacan juntos y se cifran usando la clave secreta de Alicia, de modo que sólo Alicia puede descifrarlos. No es sino hasta que llega el mensaje 2 que la estación de trabajo solicita la contraseña de Alicia. La contraseña entonces se usa para generar KA , a fin de descifrar el mensaje2 y obtener la clave de la sesión y el billete TGS contenido en ella. En este punto, la estación de trabajo sobrescribe la contraseña de Alicia para asegurarse que solamente esté en la estación de trabajo durante unos cuantos milisegundos a lo sumo. Si Trudy intenta establecer una sesión haciéndose pasar por Alicia, la contraseña que ella escriba estará equivocada y la estación de trabajo detectará esto porque la parte estándar del mensaje 2 será incorrecta.

Tras establecer la sesión, Alicia puede indicar a la estación de trabajo que quiere hacer contacto con Benjamín, el servidor de archivos. La estación de trabajo envía entonces el mensaje 3 al TGS solicitando un billete para usarlo con Benjamín. El elemento clave de esta solicitud es KTGS (A, KS ), que se cifra con la clave secreta de TGS y sirve como prueba de que el transmisor en realidad es Alicia. El TGS responde creando una clave de sesión, KAB , para que Alicia la use con Benjamín. Se devuelven dos versiones de esta clave. La primera se cifra sólo con KS , para que Alicia pueda leerla. La segunda se cifra con la clave de Benjamín, KB , para que Benjamín pueda leerla.

Trudy quiere copiar el mensaje 3 e intentar usarlo de nuevo, pero se verá frustrada por la marca de tiempo cifrada, t, que envía junto con él. Trudy no puede reemplazar la marca de tiempo por una más reciente, pues no conoce KS , la clave de sesión usada por Alicia para hablar con el TGS. Aun si Trudy repite el mensaje 3 rápidamente, todo lo que obtendrá es otra copia del mensaje 4, que no pudo descifrar la primera vez y no lo podrá descifrar la segunda vez tampoco.

Ahora Alicia puede enviar KAB a Benjamín para establecer una sesión con él. Este intercambio también recibe una marca de tiempo. La respuesta es prueba para Alicia de que en realidad está hablando con Benjamín, no con Trudy.

Tras esa serie de intercambios, Alicia puede comunicarse con Benjamín con la protección de KAB . Si luego ella decide que necesita hablar con otro servidor, Carolina, simplemente repetirá el mensaje 3 al TGS, sólo que ahora especificará C en lugar de B. El TGS responderá rápidamente con un billete cifrado con KC que Alicia puede enviar a Carolina y que Carolina aceptará como prueba de que vino de Alicia.

El objeto de todo este trabajo es que ahora Alicia puede acceder a los servidores de toda la red de una manera segura, y que su contraseña nunca ha tenido que atravesar la red. De hecho, la contraseña sólo tubo que estar en su propia estación de trabajo durante algunos milisegundos. Sin embargo, nótese que cada servidor efectúa su propia autorización. Cuando Alicia presenta su billete a Benjamín, éste simplemente indica a Benjamín quién lo envió. Lo que Alicia tenga permiso de hacer lo determinará Benjamín.

Dado que los diseñadores del Kerberos no esperaban que todo el mundo confiara en un solo servidor de validación de identificación, tomaron las providencias necesarias para tener varios reinos, cada uno con su propio AS y su propio TGS. Si quiere obtener un billete para un servidor de un reino distante, Alicia pedirá a su propio TGS un billete aceptado por el TGS del reino distante. Si el TGS distante se ha registrado con el TGS local (de la misma manera en que lo hacen los servidores locales), el GTS local le dará a Alicia un billete válido para el TGS distante. Entonces ella podrá trabajar por allá, por ejemplo obteniendo billetes para los servidores remotos de ese reino. Nótese, sin embargo, que para que partes de dos reinos trabajen, cada una debe confiar en el TGS de la otra.

VENTAJAS E INCONVENIENTES

VENTAJAS

Hasta que se diseñó Kerberos, la autenticación en redes de computadores se realizaba principalmente de dos formas: o bien se aplicaba la autenticación por declaración (Authentication by assertion), en la que el usuario es libre de indicar el servicio al que desea acceder (por ejemplo, mediante el uso de un cliente determinado), o bien se utilizaban contraseñas para cada servicio de red. Evidentemente el primer modelo proporciona un nivel de seguridad muy bajo, ya que se le otorga demasiado poder al cliente sobre el servidor; el segundo modelo tampoco es muy bueno: por un lado se obliga al usuario a ir tecleando continuamente su clave, de forma que se pierde demasiado tiempo y además la contraseña está viajando continuamente por la red. Kerberos trata de mejorar estos esquemas intentando por un lado que un cliente necesite autorización para comunicar con un servidor (y que esa autorización provenga de una máquina confiable), y por otro eliminando la necesidad de demostrar el conocimiento de información privada (la contraseña del usuario) divulgando dicha información.

INCONVENIENTES

A la vista de todo lo comentado en los puntos anteriores puede darnos la impresión de que Kerberos es la panacea de los sistemas de autenticación. Sin embargo, y aunque se trate de un sistema robusto, no está exento de ciertos problemas, tanto de seguridad como de implementación, que han hecho que este sistema no esté todo lo extendido que debería.

Uno de los principales problemas de Kerberos es que cualquier programa que lo utilice ha de ser modificado para poder funcionar correctamente, siguiendo un proceso denominado `kerberización'. Esto implica obviamente que se ha de disponer del código fuente de cada aplicación que se desee kerberizar, y también supone una inversión de tiempo considerable para algunas aplicaciones más o menos complejas que no todas las organizaciones se pueden permitir.

El problema anterior es simplemente de implementación; no afecta para nada a la seguridad - o inseguridad - del protocolo. Un problema que sí está relacionado con la seguridad de Kerberos es la gran centralización que presenta el sistema. Para un correcto funcionamiento se ha de disponer en todo momento del servidor Kerberos, de forma que si la máquina que lo alberga falla, la red se convierte en inutilizable; obviamente esto es una contradicción con lo que nos dice la teoría de sistemas distribuidos, donde se recalca el uso de la distribución para mantener la disponibilidad del sistema, intentado que si un equipo falla el resto pueda seguir funcionando, si no a pleno rendimiento, al menos correctamente. Por si esto no fuera suficiente, otro ejemplo de la centralización de Kerberos reside en el hecho de que casi toda la seguridad reside en el servidor que mantiene la base de datos de claves, de forma que si éste se ve comprometido, la red entera está amenazada.

Otro potencial problema de seguridad es el uso de timestamps como pruebas de frescura en Kerberos. Esto obliga a que todas las máquinas que ejecutan servicios autenticados mantengan sus relojes mínimamente sincronizados (con desfases máximos de pocos minutos), con todo lo que esto implica. Además ese tiempo global ha de ser accesible a todas las estaciones; aunque en el diseño no se asume que todas mantengan la hora exacta, sí que se les obliga a mantenerse dentro de los márgenes si desean solicitar tickets, para lo que se necesitan servidores de tiempo con los que los clientes puedan sincronizar periódicamente sus relojes, por ejemplo cada vez que arrancan.

Todos estos problemas, y algunos más que se han ido solucionando en diferentes versiones del sistema, han propiciado que el uso de Kerberos no esté muy extendido; en la mayoría de redes es suficiente con un protocolo de comunicación cifrado para mantener una mínima seguridad, de forma que el complejo modelo de Kerberos se ve sustituido a ese efecto por programas tan simples y transparentes como SSH.

1

Alicia

A

KA (KS ,KTGS (A, KS ))

KTGS (A, KS ), B, KS (t)

KS (B, KAB ), KB (A, KAB )

KB (A, KAB ), KAB (t)

KAB (T + 1)

AS

TGS

Benjamín

Establecimiento de sesión

Obtiene un billete

Hace el trabajo