KERBEROS. Un Sistema de Autenticacion para Redes. ANDREA PAOLA ALONSO DE ARMIÑO. PROFESOR: JORGE EDUARDO SZNEK MATERIA: SEGURIDAD INFORMÁTICA.

Transcripción

1 KERBEROS Un Sistema de Autenticacion para Redes. ANDREA PAOLA ALONSO DE ARMIÑO. PROFESOR: JORGE EDUARDO SZNEK MATERIA: SEGURIDAD INFORMÁTICA. UNIVERSIDAD NACIONAL DEL COMAHUE

2 Página 2 KERBEROS: UN SERVICIO DE AUTENTICACIÓN PARA REDES....3 RESUMEN... 3 INTRODUCCIÓN... 4 OBJETIVOS: AUTENTICACIÓN, INTEGRIDAD, CONFIDENCIALIDAD Y PERMISO(AUTORIZACIÓN)... 5 Debilidades de KERBEROS:... 6 QUÉ HACE KERBEROS, CÓMO TRABAJA... 6 Cross Realm Authentication... 9 Los tres pasos de KERBEROS:... 9 USANDO KERBEROS Aplicaciones Kerberizadas OTRAS FORMAS DE MEJORAR LA SEGURIDAD DISEÑANDO UN SISTEMA DE AUTENTICACIÓN Diálogo en cuatro escenas VERSIÓN 4 DE KERBEROS Y VERSIÓN Limitaciones de la versión 4 de Kerberos Cambios en la Versión 5: Nuevas características de la V Implementación V Interacción del Usuario Compatibilidad con la versión Comparación entre la V4 de Kerberos y la V PROBLEMAS TÉCNICOS Y LIMITACIONES DE KERBEROS Trabajo futuro CONCLUSIÓN REFERENCIAS:... 28

3 Página 3 KERBEROS: Un Servicio de autenticación para redes. Resumen Los métodos de autenticación que se basan en la criptografía, evitan que un atacante que esté escuchando en la red pueda entender lo que se está transmitiendo y por lo tanto no sabrá cómo enmascararse y hacerse pasar por otro. En la actualidad los sistemas de computación brindan servicios a muchos usuarios, cada uno con ciertos permisos y restricciones, por lo que es necesario identificarlos de manera confiable. En los sistemas tradicionales bastaba con chequear un password en el momento del login para determinar los privilegios que le correspondían y definir las operaciones que tenía permitidas cada usuario. Pero esta forma de autenticación no es útil en los sistemas actuales que hacen uso de las conexiones de redes...un password viajando a través de la red podría ser interceptado por un atacante y luego ser usado para enmascararse como si fuera el usuario legítimo. KERBEROS provee una forma de verificar la identidad de un principal(ej. un usuario de una workstation o un servidor de red) en una red abierta (desprotegida). Esto es logrado sabiendo que no se puede confiar de la dirección del host, sin requerir seguridad física de los host de la red, y bajo la suposición de que los paquetes que viajan en la red pueden ser leídos, modificados e incluso insertados. Así, bajo éstas características, KERBEROS hace la autenticación, que consiste en un servicio de autenticación de tres partes y usando la criptografía convencional (es decir compartiendo claves secretas). Un caso concreto es el del U.S. Departament of Energy (DOE), que requiere acceso a un gran número de sistemas y fuentes de información externas a sus propios laboratorios. La comunicación electrónica y el uso de Internet han pasado a ser una necesidad para lograr la colaboración entre Universidades, industrias, gobiernos. DOE s Energy Sciences Network (Esnet) necesita esta comunicación asegurando a la vez la protección de los recursos computacionales del gobierno de usos no autorizados. La información sensitiva y las propiedad intelectual deben ser protegidas de modificaciones, destrucción o alteración. En 1993, DOE funda 4 sitios Esnet para comenzar a implementar y evaluar el servicio de autenticación Esnet basado en Kerberos V5. El propósito de este proyecto era identificar, entender y resolver las cuestiones de autenticación técnicas, procedurales, culturales y políticas en una Internet inter-organización.. Como conclusión se llegó a que la V5 de Kerberos es una tecnología que permite a los usuarios Esnet compartir libremente los recursos e información sin comprometer la integridad de los sistemas y datos. En éste trabajo comenzaremos con una introducción en la que explicaremos brevemente de que se trata Kerberos, basándonos sobre todo en la versión 5. Comentaremos los objetivos definiendo cada uno y las debilidades del protocolo. Seguidamente pasaremos a ver cómo trabaja Kerberos y que cosas se asumen para su funcionamiento, veremos gráficamente el intercambio de mensajes que hay entre clientes y servidores para hacer la autenticación. Dentro de esta sección veremos también la Cross

4 Página 4 Realm Authentication, es decir cómo funciona Kerberos cuando el cliente y servidor pertenecen a distintas organizaciones (remotos). Luego veremos algunas cuestiones de Implementación y qué pasa con las aplicaciones que quieran usar la autenticación. Finalmente incluimos un diálogo ficticio que permite, a través de un supuesto diálogo entre dos desarrolladores, ver como se van individualizando problemas y ajustando las soluciones para llegar finalmente al protocolo de autenticación Kerberos (éste diálogo solo incluye hasta la versión 4 ya que la 5 incluye otras características que surgieron luego al ir detectándose nuevas necesidades y deficiencias). Luego explicaremos algunas debilidades de la versión 4 para ver como evolucionó hacia la 5. Introducción Varios mecanismos han sido desarrollados con el propósito de evitar los posibles ataques a los que se expone la información al viajar en una red abierta (por ej. ser capturada, lo cuál es inaceptable cuando se trata de información sensitiva o en el caso de información de autenticación) pero segmentar la red y el uso de passwords de una vez obstruyen el paso no solo a los usuarios no autorizados sino también a los usuarios legítimos. KERBEROS es un servicio de autenticación desarrollado por el MIT a mediados de los 80, fue usado por mas de 5 años en varias organizaciones de gobierno, educación y comerciales para autenticar el acceso de los usuarios a los recursos dentro de los confines de la organización. Sin embargo el problema de autenticación entre organizaciones en un área de red grande, tal como Esnet llevó a que se siga trabajando. Hoy la versión V5 es considerada el estándar- desarrollada en El nombre KERBEROS proviene del mitológico perro de tres cabezas guardián de la entrada del infierno; el sistema de seguridad Kerberos sería el guardián de las transmisiones electrónicas que viajan a través de Internet, autenticando tanto a usuarios como servidores con el uso de claves y encriptado. Es decir, que hace que la autenticación sea mas confiable, ya no basta que un usuario diga quién es para creerle (Authentication by assertion). Por ejemplo, un usuario que hace un rlogin, no necesitaría reingresar su password para loguearse en la nueva máquina, ya que ésta confiaría en su identidad por estar logueado en una máquina que ya lo ha verificado, pero otro podría estar haciéndose pasar por el verdadero usuario. Hacer que el usuario reingrese su password cada vez que necesita un servicio tiene otros inconvenientes: por un lado lleva tiempo al usuario, además es inseguro cuando el servicio está en una máquina remota. KERBEROS evita tener que divulgar esta información privada, se basa en el modelo de distribución de claves de Needhan y Schroeder. Otras características de KERBEROS son el uso de timestamps, el ticket-granting service que permite hacer la autenticación sin tener que reingresar el pasword cada vez., y otros procedimientos de cross-realm authentication. Con el uso de claves se encripta un mensaje (texto plano), y se obtiene el texto cifrado, cualquiera que lo vea pensará que es basura ya que no podrá entenderlo. Solo con una rutina de desencriptación sobre el texto cifrado y usando una clave para ello, se obtendrá el texto plano nuevamente. En KERBEROS ambas claves son la misma, similar a la encriptación tradicional; en cambio en la criptografía de clave pública hay dos claves, una usada durante la encriptación y la otra en el proceso inverso, pero no hay forma de obtener una a partir de la otra.

5 Página 5 El protocolo KERBEROS consiste de varios sub-protocolos (o exchanges). Hay dos métodos por los cuales un cliente puede pedir su credencial a los servidores KERBEROS. En el primero el cliente manda en texto plano una solicitud por un ticket para un servidor dado al authentication server(as). La respuesta vuelve encriptada con la clave del usuario. Usualmente esta solicitud es por el ticket-granting ticket (TGT) que luego podrá usarse con el ticket-granting server(tgs). En el segundo caso el cliente manda un request al TGS igual que si estuviera tratando de conectar un servidor de aplicación cualquiera que requiere credenciales. La respuesta va encriptada con la clave de sesión que va en el TGT. Una vez obtenidas las credenciales pueden usarse para verificar la identidad del principal en una transacción, para asegurar la integridad de los mensajes intercambiados en ellas o para preservar la privacidad de los mensajes. La aplicación verá que tipo de protección necesita. Para verificar la identidad del principal en una transacción, el cliente manda el ticket al server. Pero para evitar que el ticket sea captado y vuelto a usar por otro, es necesaria información adicional para probar que el mensaje fue enviado por el principal para el cuál el ticket fue creado. Esta información es el autenticador que incluye un timestamp y va encriptado con la clave de sesión. Con el timestamp se asegura que el mensaje fue generado recientemente y no está siendo reutilizado. Como la clave de sesión solo la conocen el servidor y el principal que hizo el requerimiento, se garantiza la identidad del cliente. La integridad de los mensajes intercambiados entre el cliente y servidor también puede ser garantizada usando la clave de sesión. En los mensajes iría un checksum (encriptado con la clave de sesión) que permitiría detectar alteraciones. Se podría lograr privacidad e integridad encriptando los datos con la clave de sesión. Estos intercambios mencionados antes, requieren un acceso de solo lectura a la base de datos de KERBEROS. Sin embargo algunas veces es necesario cambiar alguna clave o agregar otra en caso por ej. de un nuevo usuario. Esto se hace usando un protocolo entre un cliente y un tercer servidor KERBEROS: el Servidor de Administración de Kerberos (KAS). Aunque el tema de administración no será desarrollado aquí. Objetivos: Autenticación, Integridad, Confidencialidad y Permiso(Autorización) Autenticación: es la verificación de la identidad de alguien, es decir: la comprobación de que realmente es quién dice ser. Llamamos principal a la parte cuya identidad quiere ser verificada, y verifier a quién requiere o necesita esta validación. La Integridad de los datos es la garantía de que los datos recibidos son los mismos que fueron enviados. Los diferentes métodos de autenticación ofrecen distintos grados de confianza, por ejemplo unos solo garantizan que los datos fueron generados por el principal. También hay otras características que los diferencian, una muy importante es si soportan no repudiación, es decir la habilidad de probar que alguien fue realmente el generador de un mensaje. Estas características afectan la performance, así es necesario contemplar cuáles son las que necesita la aplicación.

6 Página 6 En cuanto a Confidencialidad se refiere a no revelar la información, y Autorización es comprobar si un principal está autorizado a llevar a cabo un proceso. KERBEROS permite la autenticación de un cliente a un servidor y brinda integridad y confidencialidad para los datos que se mandan entre ellos. Los distintos métodos de autenticación aseguran distintas cosas, según su capacidad variará también su performance; por ello es necesario entender lo requerimientos de una aplicación cuando se va a elegir uno de estos métodos. Por ejemplo en el caso del correo electrónico es necesario asegurar la no repudiación, pero en este caso no es tan importante la performance. Debilidades de KERBEROS: Cómo una limitación de KERBEROS podemos decir que no puede hacer nada si un atacante logra adivinar un password, es decir no logra reconocer al impostor cuando se enmascara y logra servicios haciéndose pasar por otro. Para evitar esto KERBEROS debe ser combinado con otras herramientas. Qué hace KERBEROS, cómo trabaja... Podríamos decir que KERBEROS se parece a un carnet de conductor, reúne una cantidad de información, algunos datos serán únicos para cada uno, puede haber también alguna restricción (en el ejemplo edad mayor que 21) y un lapso de vida o de validez. Este método de autenticación será usado cada vez que un usuario de una red, solicite un servicio de red y éste necesite verificar la identidad del cliente. El usuario recibe desde el authentication server un ticket (análogo a la licencia de conducir) que servirá para que el verifier compruebe su identidad. El ticket debe llevar el password del usuario para identificarlo unívocamente. Un atacante que capte el ticket no debe poder obtener información sobre el usuario que luego le permita enmascararse. Kerberos lo evita usando encriptado. Agrega también el uso de timestamps, y el ticket-granting service para soportar subsecuentes autenticaciones de un usuario sin que tenga que reingresar su password. Kerberos hace algunas Asunciones sobre el medio en el que puede funcionar apropiadamente : Los ataques que producen la denegación de servicios no son tratados por Kerberos. Un intruso podría afectar la participación de una aplicación en el proceso de autenticación. Las claves deben ser mantenidas en secreto, tanto de los usuarios como de los servidores, para que un atacante no logre enmascararse. Los password no son malos, así no se considera el problema de que sean adivinados.

7 Página 7 Cada host debe tener un reloj cercanamente sincronizado con los de los otros host, para poder distinguir el reenvío de los mensajes. Verificar que un usuario es quién dice ser, es ver que conoce el password (que a la vez es la clave de encriptación) que solo él puede saber y el authentication server (AS). El AS tiene registrados a todos los usuarios; de cada uno guarda una clave que obtiene desde su password. Además cada application server comparte una clave con el AS: server key. Kerberos se basa en el método de encriptación DES, los datos son desencriptados con la misma clave con la que se los encriptó (si no se conoce la clave o los datos fueron alterados no se logra desencriptar: integridad y confiabilidad). En rasgos generales podemos describir los pasos que lleva a cabo el método de autenticación: 1. El usuario manda un mensaje al AS diciendo qué usuario es y cuál es el servicio que quiere. 2. El AS recibe el mensaje y crea una clave, que será compartida entre cliente y servidor: session key. 3. El AS pone una copia de la session key en un mensaje, junto con el nombre del servidor y un tiempo de expiración fuera del cuál la session key no será valida, y encripta todo con la clave del usuario (podemos verlo como una caja: C1, que cierra con una llave). 4. Toma una segunda copia de la session key mas el nombre del usuario, y encripta con la clave del servidor (C2 cerrada con otra llave). 5. Envía las dos cajas al usuario. 6. Con su clave el usuario puede abrir la C1 donde lee el nombre del servidor. 7. La caja C2 no la puede abrir, así crea una tercera caja donde pone la hora actual y encripta con la session key que obtuvo al abrir la C1. Envía las cajas 2 y 3 al server. 8. El server recibe las cajas, con su clave puede abrir la 2 y leer el nombre del usuario, ahora con la session key abre la tercera y ve la hora que allí se indica. De esta forma ha comprobado la identidad del usuario. La hora que lleva C3 sirve por si mas tarde un atacante intenta usar una copia de C2, ya no será valida. En KERBEROS la caja 2 es el ticket y la 3 el authenticator : éste contiene otra información como un checksum, tiempo actual y una clave de encriptación opcional (que serviría para los sucesivos diálogos entre el cliente y el servidor). Gráficamente el intercambio de mensajes:

8 Página 8 1 AS C V En algunas aplicaciones el cliente necesita autenticar también al server, así éste crea el application response en el que incluye información (como el tiempo que venía en el auntheticator), y lo envía todo encriptado con la session key. El cliente necesita un ticket y session key por cada servicio con el que se quiera comunicar, y lo obtiene a través de una solicitud al AS, para luego mandar su request al verifier. Tenemos así el protocolo básico de autenticación: authentication request and response y application request and response. Vemos que cada vez que el usuario quiera contactar un nuevo server debe enviar un request al AS, presentando así, cada vez, su password; lo que amenaza su seguridad, ya que puede ser robado. Aunque el ticket y la clave asociada tienen un tiempo de expiración corto, el password del usuario podría ser usado para obtener nuevos tickets y lograr así el enmascaramiento. Kerberos soluciona el problema incorporando otro elemento, el ticket granting server (TGS). Cuando el usuario quiera obtener un servicio, primero debe autenticarse ante el TGS. Se pide un ticket para el TGS, igual que se hace para cualquier servicio, obteniéndose el ticket granting ticket (TGT). Una vez hecho esto, cada vez que el usuario quiera pedir un servicio, le pide un ticket al TGS, no al AS: la respuesta ahora no va encriptada con la clave del usuario sino con la session key que el AS mandó para usar con el TGS. Así se evita que el usuario esté reingresando su password cada vez y que pueda ser robado. Además el TGT es válido por un tiempo corto (no así el password). AS TGS 1 2 C V

9 Página 9 En la figura se ve el protocolo completo, los mensajes 1 y 2 solo ocurren cuando el usuario se loguea con el sistema, el 3 y 4 cada vez que se deba autenticar a un verifier. Cross Realm Authentication Cuando la red crece mucho, el AS / TGS pueden volverse un cuello de botella en el proceso de autenticación. Es decir que se ve afectada la escalabilidad, uno de los principales objetivos de los sistemas distribuidos. Además, cuando un sistema sobrepasa los límites organizacionales, no es apropiado tener a todos los usuarios registrados en el mismo servidor de autenticación. El protocolo KERBEROS fue diseñado para operar aún entre límites organizacionales. Un cliente dentro de una organización puede ser autenticado ante un servidor en otra organización. Cada organización con su propio servidor KERBEROS establece su Realm. El nombre del realm al que pertenece un cliente es parte de su propio nombre y puede ser usado por el servidor para decidir brindar el servicio o no. Entonces la alternativa es dividir la red, cada uno con su AS y TGS responsables de una parte de los usuarios y servers. A un subconjunto de éstos lo llamamos Realm. Estableciendo claves inter-realm, los administradores de dos realms pueden permitir que los clientes autenticados en uno de ellos puedan usar su autenticación en el realm remoto. El intercambio de claves inter-realm requiere registrar el ticket-granting service de cada realm en el otro. Así un cliente es capaz de obtener un TGT para el ticket-granting service remoto(rtgs) desde su realm local. Cuando el ticket-granting ticket es usado, el ticket-granting service remoto usa la clave inter-realm para desencriptar el TGT y autenticar al usuario, los ticket para los servicios que él provea dirán que el cliente pertenece a otro realm. Ahora a nuestro protocolo de comunicación se agrega un nuevo intercambio de mensajes. Primero el usuario contacta al AS para acceder al TGS. Luego contacta al TGS para acceder al RTGS, y finalmente se contacta con éste para llegar al service. En la versión 4 de KERBEROS era necesario que cada server se registre con cada realm con el que necesite Cross realm authentication, lo que hace que el número de interconexiones crezca exponencialmente (dos realm se podían comunicar si compartían un clave inter-realm, o si entre ambos existía un realm intermedio). En la versión 5 en cambio existe un jerarquía entre los realms, cada uno comparte una clave con sus hijos y padre; por ello, para contactar un service de otro realm puede ser necesario atravesar varios realms intermedios. Hay también mecanismos que permiten acortar el camino en el proceso de autenticación para mejorar la performance. Cada verifier hace la validación del ticket analizando el camino de realms que se ha atravesado (ya que se van registrando en el ticket). Los tres pasos de KERBEROS: 1. Intercambio de mensajes para la autenticación: Esta comunicación entre el cliente y el servidor de autenticación de Kerberos comienza cuando el cliente solicita una credencial de autenticación. La clave del cliente es usada para la encriptación y desencriptación. Generalmente este paso se da al comienzo de una sesión para obtener la credencial para acceder al ticket-granting service y así a través de él obtener los tickets que permitan usar

10 Página 10 otros servicios sin tener que volver a ingresar el password del usuario. También sirve para obtener credenciales que sirvan para acceder a servicios que no requieran al ticketgranting service como intermediario (por ej. el password-changing service). En el request el cliente manda en texto plano su identidad, la respuesta (en la que va el ticket y la clave de sesión) está encriptada con la clave del usuario. Otra información que va en el mensaje de vuelta sirve para detectar los reusos. En verdad el servidor de autenticación no sabe si el cliente que hizo el request se corresponde con el nombre de usuario dado, pero no le afecta ya que si no es, no le va a servir la respuesta porque no conocerá la clave para desencriptarlo. 2. Intercambio de mensajes con el Ticket-Granting Service (TGS): Se llega a esta etapa cuando un cliente quiere obtener un ticket para algún servicio y ya posee el ticketgranting ticket. El intercambio de mensajes es similar al anterior, solo que ahora no se usa como clave de encriptación el password del cliente sino la clave de sesión que se ha obtenido junto con el ticket-granting ticket. En el request va información de autenticación, que en este caso es el ticket. La respuesta va encriptada con la clave de sesión para este servicio y llevará la credencial solicitada. Antes de enviar su request el cliente debe ver en que realm el servidor está registrado. Si el cliente no posee un ticket-granting ticket apropiado para el realm debe primero obtener uno, así un ticket de estos es requerido al realm destino desde el realm local (se puede tener que atravesar varios realms intermedios hasta obtener finalmente el TGT deseado). Una vez conseguido puede solicitar el ticket para el servicio que quiera. Al recibir la solicitud el ticket-granting service hace algunos chequeos mas, por un lado debe ver cuál es el servicio solicitado para determinar la clave con que debe desencriptar. En general se trata del ticket-granting service por lo que usa la clave del TGS, pero si el mensaje es remoto debe usar una clave inter-realm. Una vez desencriptado el ticket obtiene la clave de sesión con la que desencripta el autenticador y comprueba la identidad del usuario. En la respuesta envía el ticket para el servicio solicitado encriptado con la clave para éste. Si el request es para un ticket-granting ticket para un realm remoto, y no se comparte una clave con él, se elige el realm mas cercano con el que se comparte una clave y se lo usa. 3. Comunicación cliente-servidor : Este intercambio de mensajes es usado por las aplicaciones de red para autenticar a los clientes frente a los servidores y viceversa. El cliente para esto ya debe haber obtenido el ticket desde el AS y el ticket para el servicio desde el TGS. La información que va en el request es el ticket, un autenticador y alguna información extra. El autenticador servirá para que otros no puedan reutilizar tickets haciéndose pasar por el cliente legítimo que lo obtuvo (ya que solo éste puede conocer la clave de sesión). El cliente puede reusar los tickets hasta su expiración, pero creará cada vez un autenticador (lleva la hora, un número de secuencia inicial que se elige aleatoriamente, etc.) todo encriptado con la clave de sesión. El servidor desencripta el ticket con su clave (debe ver cuál usar por el caso de que la solicitud provenga de un realm remoto). Ahora que ha obtenido la clave de sesión puede desencriptar el autenticador y comprobar la identidad del usuario (comparando el nombre del cliente y su realm), controla también la hora.

11 Página 11 En todos los mensajes request desde un cliente a cualquiera de estos servidores se pueden setear ciertas banderas para solicitar ciertas características de los tickets, por ej. una bandera que indique que un ticket es renovable, etc. Usando KERBEROS La implementación consiste de uno o varios authenticator servers que deben mantener una base de datos con los passwords (claves de encriptación) para todos los principals (usuarios y servers), es importante que estas máquinas sean seguras. En lo posible dedicadas a correr el server de autenticación. Para agregar autenticación a las transacciones, una aplicación de red debe agregar llamadas a las librerías de KERBEROS (librerías de código que proveen encriptación e implementan el protocolo), lo que resulta en la transmisión de los mensajes necesarios para lograr la autenticación. Un usuario que quiera usar KERBEROS debe primero establecerse como un principal, en general como una cuenta en una máquina, el nombre del principal consiste del nombre mas el realm al que pertenece: your_name@your.realm. Con cada principal hay asociada una clave almacenada en la Base de datos de Kerberos junto con alguna otra información (todo encriptado con una clave privada de Kerberos). Para el usuario Kerberos es casi transparente. Muchos servicios requieren de la autenticación. Por ej. rlogin, para poder usarlas es necesario obtener un TGT primero, el comando para esto es kinit. %kinit Password para your_name@your.realm Al ingresar el password el programa kinit hace un request al AS por un TGT, con la clave desencriptará la respuesta (en verdad al password se le aplica una función con la que se obtiene la clave real con la que se ha encriptado y con la cuál se hará la desencriptación). Para verificar que se ha obtenido el TGT se puede usar el siguiente comando: %klist Ticket cache: /var/tmp/krb5cc_1234 Default principal: your _name@your.realm Valid starting Expires Service principal 24-Jul-95 12:58:02 24-Jul-95 20:58:15 Krbtgt/YOUR.REALM@your.realm El ticket cache dice que archivo contiene la credencial, el default principal es el principal para el cuál es el TGT, el resto es la lista de los ticket que se poseen. Si ahora se usa el rlogin, este programa usará el TGT para obtener el ticket para el rlogin, esto ocurre automáticamente al ejecutar: %rlogin newhost.domain Last login: Fri Jul 21 12:04:40 from etc etc Ahora si se ejecuta Klist aparecerá el nuevo ticket en la lista. Para destruir credenciales que no se van a necesitar se puede usar el comando:

12 %kdestroy %Klist Klist: No credential cache file found while setting cache flags (ticket cache /var/tmp/krb5cc_1234) Página 12 Se eliminan todos los tickets incluso el TGT. El administrador del sistema debe configurar el AS y TGS, los principal deben ser registrados y los servicios deben hacerse disponibles. Aplicaciones Kerberizadas Las aplicaciones cliente/servidor deben ser modificadas para soportar el uso de Kerberos para la autenticación. Las aplicaciones deben generar y enviar Kerberos application request al server de aplicación, y éste debe verificar la información de autenticación. En versiones recientes de Kerberos, existe la Generic Security Application Programmer Interface (GSSAPI). GSSAPI provee una interface de programación estándar independiente del mecanismo de autenticación. Esto permite al programador de aplicación diseñar una aplicación y protocolo de aplicación que puede usar tecnologías de autenticación diferentes (incluso Kerberos). Las aplicaciones deben : 1. Obtener la identidad del usuario. 2. Obtener la credencial para el usuario. 3. Verificar si existe un ticket para un servicio dado. 4. Si no está presente usar el TGT y la clave de sesión para pedir uno. Otras formas de mejorar la seguridad Kerberos no es una solución total para todos los problemas de seguridad en redes, pero puede convinarse con otras herramientas, por ej. one-time passwords y publickeycryptography. Un mecanismo de autenticación con passwords de una sola vez usa un password distinto cada vez que se necesite autenticación. Aunque un método como éste presenta otros inconvenientes, no es bueno almacenar información en cada server con el que un cliente interactúa, pero tampoco es práctico que un usuario tenga que reingresar su password cada vez. En la criptografía de clave pública, la encriptación y la desencriptación se hacen usando un par de claves, una pública y la otra privada (no se puede obtener una a partir de la otra). Algunas ventajas frente a la criptografía tradicional cuando es usada para la autenticación es la no repudiación y la eliminación de la clave de encriptación secreta para el authenticator server. Una desventaja sería la performance (por ello es necesario considerar en cada aplicación cual es el nivel de seguridad que se quiere frente al costo de lograrlo).

13 Página 13 Diseñando un Sistema de Autenticación Diálogo en cuatro escenas El siguiente diálogo es un cuento ficticio del diseño de un sistema de autenticación para una red abierta que se llamará Charon. A medida que el diálogo avanza, los involucrados van descubriendo los problemas de seguridad en un medio de red abierto. Cada problema debe ser resuelto en el diseño de Charon. El diseño final del sistema es el que conocemos como KERBEROS. Introducción: Los dos personajes que participan son desarrolladores de sistemas. Escena 1: Athena y Euripides trabajan en terminales vecinas. Hey Rip, este sistema de tiempo compartido es muy lento. No puedo hacer nada porque cualquiera se logue y entra. No te quejes a mi, yo solo estoy trabajando acá. Sabes que necesitamos?, que cada uno tenga su estación de trabajo y así evitamos compartir ciclos de CPU. Y usaríamos la red para comunicarnos unos a otros. Si...pero necesitaríamos muchas workstations... Además el tamaño de la unidad de disco de una workstation típica no es suficiente para todo el software que hay en una máquina de tiempo compartido. Podría estar fuera, tener máquinas servidoras con copias del software del sistema. Cuando uno se loguea en una workstation, ésta se conecta a un server y accede al software. Además facilitaría el hecho de la actualización. Y qué pasa con los archivos personales?, en un sistema de tiempo compartido yo puedo loguearme y obtener mis archivos desde cualquier terminal conectada al sistema. Podría seguir haciendo eso? o tendría que hacer como los usuarios de PC y cargar mis archivos en disquetes? Pienso que podría haber otras máquinas que provean el almacenamiento de los archivos personales. Así uno podría loguearse desde cualquier workstation y obtener los archivos. Y que pasa para imprimir?, cada uno tendría que tener su impresora?. Y que pasa con el correo electrónico? cómo harías para distribuirlo a cada workstation? Bueno, sería costoso tener tantas impresoras, pero se podrían dedicar algunas máquinas al servicio. Lo mismo para el correo, para obtener los mails habría que loguearse a una máquina que diera tal servicio.

14 Página 14 La verdad que este sistema de workstation suena bien, pero hay algo...alguien podría usar mi nombre de usuario y hacerse pasar por mi, y obtener por ejemplo mi correo electrónico... Los servers no podrían distinguir esto. Es verdad...hay que pensar algo. Escena 2: La mañana siguiente. Ya pense la forma de brindar seguridad en un ambiente de red tal que nadie pueda hacerse pasar por otro. En serio?, y en qué consiste? En uno de éstos sistemas es necesario que las máquinas servidoras sean capaces de confirmar la identidad de las personas que requieren sus servicios. Si yo solicito al servidor de correo mis mails, él debe poder verificar que soy quien digo que soy, no es así? Estoy de acuerdo. El problema se resolvería haciendo que el servidor de correo requiera un password antes de que alguien pueda usarlo, para demostrarle así quien es. Pero así cada server debería conocer todos los passwords de todos los clientes, además si se cambia el password habría que avisar a todos los servers. El sistema es así, no solo los clientes tienen password sino también los servers. Cada usuario conoce su password, y hay un SERVER DE AUTENTICACION que conoce todos los passwords (de usuarios y servidores) almacenados en una base de datos centralizada. Y que nombre le diste a este servicio de autenticación? Aún no tiene uno. Que te parece Charon. Okay, es un lindo nombre...aunque no describe de que se trata el sistema. Supongamos ahora que vos queres usar un servicio, la única forma sería que Charon le diga al server que sos quien decís. Cuando le pedís a Charon que corrobore tu identidad tenes que decirle cuál es el servicio que queres. Charon te solicita que pruebes tu identidad, así vos le mandas tu password secreto. Charon lo compara con el que tiene registrado en su BD, si son iguales considera que tu identidad es la verdadera. Ahora debe convencer al server que solicitas que sos vos. Ya que Charon conoce todos los password conoce también el de este server (por ej. el servidor de mails). Así si te lo da y vos se lo mandas en tu request, él confiaría en tu identidad, porque si sabes ese password secreto es porque te lo dio el servidor de autenticación.

15 Página 15 El problema es que ahora conociendo el password podrías pedir otra vez algo al server sin hacer la autenticación correspondiente, y lo que es peor hacerte pasar por otro. La opción sería que el autenticador no de los passwords sino un ticket para el servidor solicitado, que contenga tu nombre de usuario encriptado con la clave de tal server. Con el ticket podes solicitar ahora el servicio al servidor dado, diciendo que usuario sos. Con su password el server desencripta el ticket y verifica tu identidad con la que dice allí, si son iguales brindará el servicio. Una pregunta, puede saber el server si el ticket se ha desencriptado bien o no? No lo sé... Podría incluirse en el ticket también el nombre del servidor, así podría darse cuenta si la desencriptación fue mal hecha. Suena bien (y anota en un papel: Ticket(username:servicename)) No creo que el hecho de que vaya todo encriptado sea suficiente. Mira si yo me hago una copia de un ticket que te manda el autenticador mientras viaja por la red. Y yo hago creer a mi insegura workstation que mi nombre de usuario es el tuyo, luego pediría el servicio a tu nombre y con el ticket robado, obteniendo así el servicio. Oh! que mal! Pero se me está ocurriendo algo para solucionar el problema. Charon debería incluir mas información en los tickets, como una DIRECCION DE RED desde donde proviene la consulta, lo que nos daría un nivel de seguridad mayor. En el caso anterior, como el ticket llevaba tu dirección de red, mi intento de hacerme pasar por vos fallaría ya que el server podría ver que la dirección que lleva el ticket no es la mía y rechaza el pedido. Bárbaro!: (el formato del ticket sería ahora: Ticket(username:ws_address:servicename)) Otra duda...cada vez que necesite un servicio tendría que solicitar un ticket, incluso aunque repita algunos servicios (por ej. si quiero pedir mis mails mas de una vez en el día)? Este...no veo porqué no podrían rehusares los tickets...por ej. si vos obtenes un ticket para el servidor de mails deberías poder usarlo una y otra vez, tal vez almacenando una copia. Pero aún hay problemas. Yo debería mandar mi password al autenticador cada vez que necesite un servicio distinto para el que no tenga un ticket.

16 Página 16 Además enviar un password al autenticador por la red en texto plano no es nada seguro, cualquiera que esté monitoreando la red podría captarlo y copiarlo, e incluso enmascararse... Escena 3: La siguiente mañana se encuentran Athena y Euripides... Tengo una versión nueva de Charon que resuelve nuestros problemas! En serio!, tan rápido? Comencé a ver los problemas como requerimientos del sistema. El primero: Los usuarios deben ingresar su password una sola vez, cuando comienzan sus sesiones en las workstations. Es decir que no será necesario ingresar el password cada vez que se requiera un ticket para un servicio. Segundo: Los password no deben viajar por la red en texto plano. Veamos el primer requerimiento, el problema de que el usuario solo tenga que hacer uso de su password una vez. Para esto inventé un nuevo servicio de red, el ticket-granting service, un servicio que emitirá tickets a usuarios que ya han probado su identidad. Es decir que ya han obtenido previamente un ticketgranting ticket. El ticket-granting service es una versión de Charon que permite autenticarse con un ticket en lugar de con un password. Ahora el sistema de autenticación funciona así: vos te logueas en una workstation y usas un programa llamado kinit para contactar el servidor Charon. Vos probas tu identidad a Charon, y el programa kinit obtiene un ticket-granting ticket. Ahora si vos queres pedir al servidor de correo que te de tus mails, usando el ticket-granting ticket pedís a este nuevo servidor un ticket para ese servicio, sin tener que usar de nuevo tu password. Pero tendría que pedir un nuevo ticket-granting ticket cada vez que quiera pedir un ticket para un nuevo servicio que quiera usar... No, los tickets se podrían rehusar, una vez que obtenes un ticket-granting ticket no necesitas pedir otro, y con el obtenes los tickets para los servicios que precisas. Y ya que los tickets se pueden rehusar, si obtengo un ticket para un servicio particular, como el de correo o cualquier otro, no necesito seguir pidiendo nuevos tickets para ese servicio. Segundo: cuando se envía el password al server Charon para obtener el ticketgranting ticket, no debería viajar en texto plano. El tema es que, cuando usas el programa kinit para obtener el ticket-granting ticket, kinit no manda tu password al server Charon sino solo tu username. Charon conoce tu password conociendo quién sos, luego arma un paquete que contiene el ticket-granting ticket, y antes de enviarlo de vuelta lo encripta con tu clave. Cuando recibís el paquete ingresas tu password, kinit trata de desencriptarlo usando esa clave, si es la correcta tendrá éxito y habrás sido autenticado,

17 Página 17 sino...no. Con el ticket-granting ticket podrás pedir los tickets que necesites para acceder a los otros servicios. Que te parece? Estoy pensando en el hecho de identificarme solo una vez y que Charon sea capaz de darme tickets sin que yo me entere. Está relacionado con poder rehusar tickets, es algo necesario pero peligroso. A dónde queres llegar? Supone que estás usando una workstation insegura. Durante tu sesión obtenes varios tickets, y quedan allí luego de tu logout. Ahora yo ingreso a la workstation y los encuentro. Hago creer a la workstation que soy vos, y como los ticktes están a tu nombre puedo usarlos. Se podría resolver con un programa que destruya todos los tickets cada vez que un usuario salga de su sesión. No podemos confiar en que los usuarios no olviden destruir sus tickets cada vez que dejan su sesión, y aún cuando lo hagan mira esta situación: Tengo un programa que espía la red y copia los tickets que viajan por ella. Supongamos que mi víctima vas a ser vos, espero que inicies tu sesión en una workstation y copio tus tickets. Espero que termines tu sesión, y cambio mi dirección de red con la tuya para que coincida con la información que va en los tickets. Hago creer a mi workstation que soy vos, tengo tus tickets y nombre de usuario, y la dirección de red correcta; puedo usar los servicios en tu nombre. Ahora veo el problema, está en el hecho de que los tickets no tienen un límite de vida... Si, yo pienso que deberían tener información adicional: un tiempo por el cuál se considere un ticket válido(lifespan), y la fecha y hora en la cuál Charon emitió el ticket(timestamp). TICKET(username:address:servicename:lifespan:timestamp) Así cuando un servidor recibe un ticket debería chequear el nombre de usuario y dirección que dicen en el ticket con el nombre y dirección del que emite el pedido de servicio, y controlar la expiración del ticket mirando el timestamp y lifespan. Y en que como determinar el lifetime? No lo se...tal vez debería ser el tiempo de duración normal de una sesión: 8 horas. Así si me excedo de ese tiempo todos mis tickets expirarían, incluso el ticketgranting ticket, y yo tendría que volver a autenticarme con Charon. Es razonable, o no?

18 Página 18 Si, pero... Supongamos que yo hice copias de tus tickets, y vos abandonas tu sesión tras un par de horas de trabajo, aún los tickets seguirán siendo válidos por unas horas mas, y yo podría usarlos como antes. Es verdad! Habrá que seguir pensando una nueva solución.. Escena 5: La siguiente semana Athena se dirige a la oficina de Euripides... Lograrse encontrar alguna solución anoche? Pienso que si. Habíamos quedado en que los tickets serían reusables por un tiempo, pero el problema seguía si el usuario no completaba ese lapso y otro lo aprovechaba para enmascararse. No tendríamos ese problema si los tickets no fueran reusables. Pero estaríamos de nuevo en la situación de tener que solicitar un ticket cada vez que se quiera usar un servicio. Es verdad, pero planteemos el problema como un requerimiento: un servicio de red debe poder probar que una persona usando un ticket es la misma persona por la cual el ticket será usado. Es decir: yo quiero usar un cierto servicio, accedo al mismo a través a un programa cliente de mi workstation que envía a la máquina servidora mi nombre, dirección de red, y el ticket. necesario. En el ticket figuran el nombre de la persona que solicitó el ticket y la dirección de red desde donde lo hizo. También contiene el momento de expiración (lifespan y timestamp), todo encriptado por Charon. Respondamos las siguientes preguntas: Puede el servidor desencriptar el ticket? Ha expirado el ticket? Matchean el nombre de usuario y dirección de red del ticket con la persona que mandó el pedido? Con la primera pregunta se sabe si el ticket proviene de Charon, ya que él lo encripta con la clave del servicio especificado en la solicitud del cliente. La segunda pregunta nos dirá si sigue siendo válido el ticket o no. Si la tercer pregunta falla podría significar que otra persona ha captado el ticket. Pero si el nombre y dirección matchean, realmente no hay nada probado. Alguien podría cambiar su dirección de red y username apropiadamente para pasar como el usuario legítimo. La única forma de estar seguros sería mantener un secreto entre el servidor y el usuario en la forma de un password. O, porqué no, hacer que Charon mantenga un password entre el dueño legítimo de un ticket y el servidor. Charon envía una copia al servidor y una al usuario (una clave de sesión) así cuando el servidor recibe un ticket desde un usuario podría corroborar su identidad usando esta clave.

19 Pero como haría Charon para darle la clave a los dos? Página 19 El dueño del ticket obtendría la clave de sesión como parte de la respuesta de Charon: CHARON-REPLY [sessionkey ticket] Para el servidor la clave de sesión iría dentro del ticket: TICKET {sessionkey:username:address:servicename:lifespan:timestamp} Así un usuario que quiera un servicio debe construir algo así como un autenticador, éste contendría su nombre y la dirección de la workstation, todo encriptado con la clave de sesión (que recibiría al solicitar el ticket). AUTHENTICATOR {username:address} encriptado con la clave de sesión. El cliente envía el ticket mas el autenticador al servidor; éste primero desencripta el ticket (con su clave privada) y obtiene la siguiente información: El lifespan y timestamp del ticket. El nombre del dueño del ticket. La dirección de red del dueño del ticket. La clave de sesión. Si el ticket no ha expirado, el servidor usa la clave de sesión para desencriptar el autenticador, obteniendo el nombre de usuario y dirección de red, datos que compara con los obtenidos del ticket y con el nombre y dirección de la persona que envió el ticket y el autenticador. Si todo coincide el servidor puede concluir que el usuario es el dueño real del ticket. Estoy pensando que..., para romper el sistema necesitaría tener el autenticador correcto para el servicio... No, no solo necesitas tener el autenticador sino también el ticket, ya que el servidor necesita obtener de éste la clave de sesión para poder desencriptar el otro. Ok, pero...alguien podría robar tanto el ticket como el autenticador, y usarlos mientras el ticket no expire cambiando la dirección de red y nombre de usuario apropiadamente. O no? Es posible... Aunque, no necesitamos que los autenticadores sean reusables, y así evitamos ese problema! Entonces, el programa cliente crea el autenticador y lo manda junto con el ticket al servidor. Vos logras copiar ambos, pero ellos llegan al servidor antes de que vos alcances a usar las copias, como el autenticador solo sirve para una vez tu copia es inútil. Ahora la cuestión es cómo hacer para que el autenticador sirva para una sola vez...

20 Página 20 No hay problema, le agregamos un lifespan y timestamp lo suficientemente cortos. Cuando el server desencripta el autenticador chequea esos tiempos, si no ha expirado y todo lo demás es correcto te habrá autenticado. Si alguien hace una copia y cambia su dirección y nombre de usuario, el autenticador debería vencerse. Pero aquí hay otro problema, supongamos que lo que copio es el paquete que te manda Charon y que contiene dos copias de la clave de sesión: una para vos, y otra que va dentro del ticket. La que va dirigida a vos es la que usas para construir el autenticador, es decir que ahora lo podría construir yo y romper el sistema! Sobre eso también estuve pensando anoche. Cuando entras en una workstation usas el programa kinit para obtener un ticket-granting ticket, éste te pide nombre de usuario y se lo manda a Charon. Charon sabiendo quien sos conoce tu password, construye el ticket-granting ticket para vos, además crea una clave de sesión para que compartas con el ticket-granting service. Esta clave la pone en el ticket-granting ticket y otra copia en el paquete que va para vos, que además encripta con tu clave antes de mandártelo, así cualquiera que lo copie no podrá desencriptarlo si no conoce tu password. Kinit te pide ingresar tu password al recibir el paquete, al desencriptarlo obtiene la clave de sesión para el ticket-granting service.. Con el ticket-granting ticket un cliente puede solicitar un ticket para algún servicio. El cliente construye el autenticador para el ticket-granting service y lo encripta con la clave de sesión (ticket-granting session key), luego se lo manda junto con el ticket, nombre y dirección de red a Charon. El ticket-granting service recibe todo esto, luego de hacer los chequeos llega a obtener la clave de sesión que comparte con el usuario. Finalmente construye el ticket para el servicio requerido y una clave de sesión para que comparta con él. Arma el paquete para el usuario con el ticket y la clave de sesión para el servicio solicitado y lo manda todo encriptado con la ticket-granting session key. Así cualquiera que copie éste paquete no podrá conseguir el ticket para el servidor dicho porque no conocerá la clave de sesión que ha usado el grantingservice para encriptar el paquete. Creo que de esta manera logramos la seguridad, que te parece? Este sistema de claves de sesión parece aceptable. Ahora mirando desde otro punto de vista creo que sería necesario la autenticación mutua, que hay si información importante va a un servidor erróneo. Supongamos que todos los pasos se dan bien y el servidor llega a comprobar mi identidad, luego debería enviarme un mensaje de vuelta que confirme a mi (cliente) su identidad. Usando la sesión key encriptaría el mensaje de vuelta, yo podría desencriptarlo con la misma clave y comprobar así su identidad también. Un servidor falso no podría generar la respuesta correcta ya que no podría desencriptar el ticket y obtener la session key. Creo que tenemos la base para construir un Sistema de Autenticación. Luego de discutir sobre el nombre Athena y Euripides acuerdan en llamarlo Kerberos.