Ella lo hace

Pero no quiero decir "que el cliente hace esto y aquello" cada vez que me refiero a una transacción entre el usuario y el servidor de red. Yo había dicho "yo hago esto y esto", teniendo en mente desde luego que un programa cliente esta haciendo cosas en mi representación. ¿te parece bien?

Pausa

Digamos que tu quieres usar un servicio, el servicio de correo. En mi sistema tu no puedes usar un servicio a menos que, ah, Charon le diga al servicio que tu eres quien dices que eres. Y tu no puedes recibir el permiso para usar un servicio hasta que te hayas autentificado con Charon. Cuando tu requieres a Charon que te autentifique, tienes que decirle a Charon el servicio para el cual quieres la autorización. Si quieres utilizar el servicio de correo debes decircelo a Charon.

Charon te pide que pruebes tu identidad. Tu lo haces dándole tu password secreto. Charon toma tu password y lo compara con el que tiene registrado en su base de datos. Si los dos passwords concuerdan, Charon considera que tu identidad ha sido aprobada.

Charon ahora tiene que convencer al servidor de correo de que tu eres, quien dices que eres. Debido que Charon sabe todos los password de los servicios , sabe el password del servicio de correo. Es concebible de que Charon pudiera darte el password, el cual puedes mandar el servicio de correo como prueba de que tu te haz autentificado ante Charon.

El problema es, que Charon no puede darte el password directamente porque entonces tu lo sabrías. La siguiente vez que tu quisieras correo podrías darle la vuelta a Charon y usar el servidor de correo sin identificarte correctamente. Inclusive podrías pretender ser otra persona y usar el servidor de correo con el nombre de otra persona.

Así que en lugar de darte el password del servidor de correo Charon te da un TICKET de servicio de correo. Este ticket contiene una versión de tu username que ha sido ENCRIPTADO USANDO EL PASSWORD DEL SERVIDOR DE CORREO

Ahora con tu ticket en mano, puedes pedir al servidor de correo tu correo. Haces tu petición diciéndole al servidor quien eres, y entregándole el ticket que prueba que tu eres quien dices que eres.

El servidor usa su password para desencriptar el ticket, y si el ticket se desencripta apropiadamente el servidor va obtener el nombre el username que Charon puso en el ticket

El servido compare este nombre con el nombre que tu enviaste con el ticket. Si los nombres coinciden el servidor de correo considera que tu entidad ha sido probada y procede a darte tu correo

¿Qué piensas de esas manzanas¿

(Ella escribe sobre un pedazo e papel)

TICKET - {username:servicename}

Lo ilustraré. Supón que me robo tu ticket de correo en este momento. El ticket tiene la dirección de red de tu estación de trabajo, y esta dirección no coincide con la dirección de mi estación de trabajo. En tu nombre yo le mando el ticket robado al servidor de correo. El programa servidor extrae el username y la dirección de red del ticket e intenta comparar esa información con el username y la dirección de red de la entidad que envío el ticket. El username coincide pero la dirección de red no. El servidor rechaza el ticket porque obviamente fue robado.

Ella escribe lo siguiente en un pizarrón

TICKET -   {username:ws_address:servicename}

Ahora estoy realmente emocionada. Construyamos un sistema Charon y veamos si funciona!!

Athea suspira

Los dos se dirigieron al pequeño cuarto de conferencias

Athena aclara su garganta

El servicio de entrega de tickets en realidad es una versión de Charon tanto que tiene acceso a la base de datos de Charon es una parte de Charon que permite autentificarte con un tickets en lugar de un password.

De todas manera, el sistema de autentificación ahora trabaja de manera siguiente: tu te conectas en una estación de trabajo y usas un programa llamado Kinit para contactar al servidor de Chanon. Tu pruebas tu identidad a Charon, y el programa Kinit te da un ticket para entrega de ticket

Ahora digamos que quieres obtener tu correo del servidor de correo. No tienes un ticket para servicio de correo, todavía, así que usas el ticket de entrega de tickets para que obtenga el ticket del servidor de correo por ti. No tienes que usar tu password para obtener el nuevo ticket

Esto es lo que realmente pasa. Cuando tu uses el programa Kinit para obtener el ticket para entrega de tickets, kinit no manda tu password al servidor de Charon. Knit manda solo tu username

Tu estación de trabajo recibe el paquete del ticket, tu ingresas tu password, kinite intenta desencriptar el ticket con el password que ingresaste, Si kinit tiene éxito, te haz autentificado ante Charon. Ahora posees un ticket para entrega de tickets, y ese ticket puede darte los demás tickets que requieras.

Qué tal esas modernas ideas?

Ahora supón que me conecto en la estación de trabajo y encuentro esos tickets. Y me siento con ganas de causar problemas, entonces hago que la estación de trabajo piense que soy tu. Debido que los tickets están hechos a tu nombre, puedo usar el programa cliente de correo para accesar a tu correo, puedo usar el servicio de archivos y borrar tus archivos, y puedo usar el comando de impresión para causar cargos a tu cuenta. Y todo gracias a esos tickets que se dejaron accidentalmente.

Y nada puede detenerme de copias estos tickets a mi lugar. Puedo seguir usándolos por toda la eternidad.

Tengo un programa que vigila la red y copia los tickets de servicio cuando están viajando en la red. Supón que quiero hacerte mi víctima. Espero a que inicies una sesión, activo mi programa y copio un montón de tus tickets.

Espero que termines tu sesión, y eventualmente tu te sales y te vas. Yo juego con el software de red de mi estación de trabajo y cambio su dirección de tal manera que concuerde con la dirección de la estación de trabajo que estabas usando cuando te robe los tickets. Hago creer a mi estación de trabajo que yo soy tu. Tengo tus tickets, tu username, y la dirección de red correcta. Puedo mandar estos tickets y usar servicios en tu nombre.

No importa que hallas destruido tus tickets antes de haber terminado tu sesión. Los tickets que he robado son validos tanto como tenga cuidado para usarlos, ya que tu diseño actual de tickets no pone un límite en el número de veces que puedes reutilizar un ticket, o cuanto tiempo permanece vigente un ticket.

Eurípides se dirige al pizarrón escribe lo siguiente:

TICKET   {username:address:servicename:lifespan:timestamp}

Ahora cuando un servicio desencripte tickets, compara el username y la dirección del ticket contra el username y la dirección de la persona que esta enviando el ticket, y usa la información de la duración media y el sello de tiempo para ver si el ticket ha expirado.

Pero te robe los tickets y son buenos por cerca de seis horas. Eso me da un buen de tiempo para jugar con tus archivos e imprimir mil copias de quien sabe que, a tu nombre.

Checas?, el arreglo del sello de tiempo y del periodo de expiración funcionan bien en el evento de que un ladrón de tickets elija mandar un ticket después de que ha expirado. Si el ladrón puede mandar el ticket antes de eso...

Pausa

Creo que eso significa que vas a estar ocupada esta noche. Más café?

Bien, voy a replantear el problema otra vez, esta vez en la forma de un requerimiento. Un servicio de red debe ser capaz de probar que la persona que esta usando un ticket es la misma para la cual el ticket fue expedido.

Déjame trazar de nuevo el proceso de autentificación y ver si puedo encontrar una manera apropiada para ilustrar mi solución a este problema.

Quiero usar un cierto servicio de red. Acceso ese servicio iniciando un programa cliente en mi estación de trabajo. El cliente manda tres cosas al servidor, mi nombre, la dirección de red de mi estación de trabajo, y el ticket de servicio apropiado.

El ticket contiene el nombre de la persona a quien fue emitido y la dirección de la estación de trabajo que la persona estaba usando cuando el o ella adquirió el ticket. Además contiene una fecha de expiración en forma de un tiempo de vida y un sello de tiempo. Toda esta información ha sido encriptada con el password del servicio Charon

Nuestro esquema de autentificación actual descansa sobre las siguientes pruebas:

• El servicio puede desencriptar el ticket?
• Ha expirado el ticket?
• Coinciden el username y la dirección de la estación de trabajo especificadas en el ticket con el nombre y dirección de la persona que lo envió?

Qué arrojan estas pruebas?. la primera prueba, dice si el ticket vino o no vino de Charon. Si el ticket no puede ser desencriptado no viene de Charon. El Charon real habría encriptado el ticket con el password del servicio. Charon y el servicio son las únicas dos entidades que saben el password del servicio. Si el ticket se desencripta correctamente, el servicio sabe si vino de Charon realmente. Estas pruebas previenen de que alguien construya tickets falsos de Charon.

La segunda prueba checa el tiempo de vida y el sello de tiempo. Si ya expiro el servicio rechaza el ticket. Esta prueba detiene a gente usando tickets viejos, tickets que tal vez fueron robados.

La tercera prueba checa el username y la dirección del ticket contra el username y la dirección de la persona especificada en el ticket. Si la prueba falla el usuario del ticket ha obtenido el ticket de otra persona. El ticket es rechazado

Si los nombre y las direcciones coinciden, qué se probo? Nada. los chicos malos pueden robar tickets de la red, cambiar la dirección de su estación de trabajo y su username y saquear los recursos de otras personas. Como señale ayer, los tickets pueden ser reenviados siempre y cuando no hayan expirado. Pueden ser reenviados porque un servicio no puede determinar que la persona que esta enviando el ticket es su dueño legitimo.

El servicio no puede hacer esta determinación debido a que no comparte un secreto con el usuario. Veámoslo de esta forma. Si estoy vigilando Elsinore, tu sabes, el castillo en Hamlet, y se supone que me vas a relevar, no te voy a dejar tomar mi lugar hasta que me des el password correcto. Ese es el caso donde los dos compartimos un secreto. Y es probablemente un secreto que alguien mas invento para cualquier vigía.

Así que estaba pensando anoche, porque no hacer que Charon invente un password para el dueño legitimo del ticket para compartirlo con el servicio? Charon le da una copia de esta llave de sesión al servicio, y una copia al usuario. Cuando el servicio recibe un ticket de un usuario. Puede usar la llave de sesión para probar la identidad del usuario.

CHARON REPLY - [sessionkey|ticket]

La copia de la llave de sesión del servicio viene dentro del ticket, y el servio obtiene la llave cuando desencripta el ticket así es que el ticket se ve así:

TICKET - {sessionkey:username:address:servicename:lifespan:timestamp}

Cuando quieras obtener un servicio, el programa cliente que tu incias construye a lo que yo le llamo AUTENTIFICADOR. El autentificador contiene tu nombre y tu dirección. El cliente encripta esta información con la llave de sesión, la copia de la llave de sesión que tu recibiste cuando pediste ese ticket

AUTHENTICATOR - {username:address} encrypted with session key

Después de construir el autentificador, el cliente lo manda con el ticket al servicio. El servicio no puede desencriptar el autentificador todavía porque no tiene la llave de sesión. Esa llave esta en el ticket así que el servicio primero desencripta el ticket.

Después de que se descripta el ticket, el servicio termina con la siguiente información.

• El periodo de vida del ticket y el sello de tiempo
• El nombre del dueño del ticket
• La dirección de red del dueño del ticket
• La llave de sesión

El servicio checa si el ticket ha expirado. Si todo va bien en ese sentido, El servicio entonces utiliza la llave de sesión para desencriptar el autentificador. Si la desencriptación procede sin obstáculo el servicio termina con un username y una dirección de red. El servicio prueba esta información contra el nombre y dirección encontrados en el ticket, Y el nombre y dirección de la persona quien envió el ticket y el autentificador. Si todo concuerda, el servicio ha determinado que quien envió el ticket es el verdadero dueño del ticket.

Athena se detiene, aclara su garganta y toma café

Creo que la llave de sesión y el autentificador se hacen cargo del problema del reenvío.

Eso es un alivio. Así que todo lo que tenemos que hacer es inventar una manera en que el autentificador sea útil una sola vez.

El servidor recibe el ticket y el autentificador y se pone a trabajar. Cuando el servidor desencripta el autentificador checa su tiempo de vida y el sello de la hora. Si el autentificador no ha expirado y todo lo demás checa, el servidor te considera autentificado.

Imagina que copie el autentificador y el ticket mientras cruzaban la red. Tengo que cambiar mi dirección de red y mi username, y lo tengo que hacer en un par de minutos. Esta muy difícil que se pueda. De hecho no creo que sea posible. A menos...

Bueno aquí hay un problema potencial. Supón que en lugar de copiar el ticket y el autentificador mientras viaja de tu estación de trabajo al servidor copia el paquete original del ticket que viene de Charon, el paquete que recibes cuando le pides a Charon un ticket.

Este paquete según recuerdo, tiene dos copias de la llave de sesión, una para ti y otra para el servicio. La del servicio esta escondida en el ticket y no la puedes obtener, pero que hay de la otra, la que usas para construir autentificadores?

Si puedo obtener esa copia de la llave de sesión, entonces puedo construir mis propios autentificadores, si los puedo construir, puedo irrumpir en el sistema

Tu te sientas en una estación de trabajo y utilizas el programa kinit para obtener tu ticket para entrega de tickets. Kinit te pide tu username, y después de que lo ingresas, kinit le manda el nombre a Charon.

Charon usa tu nombre para buscar tu password, entonces procede a construir un ticket de entrega de ticket para ti. Como parte de este proceso, Charon crea una llave de sesión que tu compartirás con el servicio de entrega de ticket. Charon pone una copia de la llave de sesión en el ticket de entrega de ticket, y pone tu copia en el paquete del ticket que estas a punto de recibir. Pero antes de que te envíe este paquete, Charon encripta todo con tu password.

Charon envía el paquete a través de la red. Alguien puede copiar el paquete en su camino, pero no pueden hacer nada con el, porque ha sido encriptado con tu password, específicamente, nadie puede robar la llave de sesión de la entrega de ticket.

Kinit recibe el paquete del ticket y te pide un password, el cual tu ingresas. Si tu ingresas el password correcto Kinit puede desencriptar el paquete y darte tu copia de la llave de sesión.

Ahora que haz hecho cargo del rollo de kinit, quieres obtener tu correo. Tu inicias el programa cliente de correo. Este programa busca un ticket de servicio de correo y no lo encuentra. El cliente debe usar el ticket para entrega de ticket para pedirle al servicio de entrega de tickets un ticket de servicio de correo.

El cliente construye un autentificador para la transacción de entrega de tickets y encripta el autentificador con tu copia de la llave de sesión de la entrega de ticket. El cliente manda a Charon el autentificador, el ticket para entrega de tickets, tu nombre, la dirección de tu estación de trabajo y el nombre de servicio de correo.

El servicio de entrega de correo recibe estas cosas y ejecuta los chequeos de autentificación. Si todo checa apropiadamente. El servicio de entrega de ticket finaliza con una copia de la llave de sesión que comparte contigo Ahora el servicio de entrega de ticket te construye un ticket de servicio de correo, y durante este proceso, crea una nueva llave de sesión para ti, para compartir con el servicio de correo

El servicio de entrega de ticket ahora prepara un paquete de ticket para mandarlo a tu estación de trabajo. El paquete contiene el ticket y tu copia de la llave de sesión del servicio de correo. Pero antes de que mande el paquete, el servicio de entrega de ticket encripta el paquete con su copia de la llave de sesión de la entrega de ticket. Hecho esto, el paquete es enviado.

Entonces viene el paquete del ticket del servicio de correo, a través de la red. Supón que un ogro de la red lo copia en su camino. El ogro no tiene suerte porque el paquete esta encriptado con la llave de sesión de entrega de ticket, tu y el servicio de entrega de ticket son las únicas entidades que conocen esta llave. Ya que el ogro no puede desencriptar el paquete del ticket de correo, el ogro no puede descubrir la llave de sesión de correo. Sin esta llave de sesión el ogro no puede usar ninguno de los ticket de servicio de correo que e puedan mandar subsecuentemente a través de la red.

Creo que estamos a Salvo, Que piensas?

Te importa si hablo por un minuto?

Supón que estas harto de tu trabajo actual y haz decido cambiarte, quieres imprimir tu curriculum en la impresora láser de tu compañía de manera que los buscadores de talentos y empleadores potenciales puedan tomar nota de la clase que tienes.

Así es que ingresas al comando de impresión, y lo direccionas al servidor de impresión adecuado. El comando obtiene el ticket de servicio apropiado, si no lo tiene todavía, entonces manda el ticket en tu nombre al servidor de impresión. Al menos eso es lo que tu crees que esta pensado. Tu no sabes que el requerimiento es direccionado al servidor de impresión correcto.

Imagina que algún hacker sin escrúpulos (digamos que es tu jefe) ha arreglado el sistema de manera tal que redirecciona tu petición y el ticket al servidor de impresión a su oficina. El programa de servicio de impresión no le importa el ticket o su contenido. Tira el ticket y envía un mensaje a tu estación de trabajo indicando que el ticket pasa, y que el servidor esta listo, esperando imprimir tu trabajo. El comando de impresión manda el trabajo al servidor de impresión fraudulento y el enemigo termina con tu curriculum.

Mostraré el problema por medio del contraste. Sin llaves de sesión y autentificadores, Charon pueden proteger a sus servidores de usuarios falsos, pero no puede proteger a loa usuarios de servidores falsos. El sistema necesita una manera para que los programas cliente autentifique el servidor antes de enviar información al servicio. El sistema debe permitir autentificación mutua

Pero la llave de sesión resuelve este problema siempre y cuando diseñes los programas cliente apropiadamente. Regresando al escenario del servidor de impresión, Quiero un programa cliente de impresión que se asegure de mandar los trabajos al servicio legitimo.

Esto es lo que hace un programa así. Ingreso el programa de impresión y le doy el nombre del archivo, el nombre de mi curriculum. Asumo que tengo un ticket de servicio de impresión y una llave de sesión. El programa cliente usa la llave de sesión para construir un autentificador, Después manda el autentificador y el ticket al "supuesto" servidor de

impresión. El cliente NO MANDA el curriculum todavía, espera una respuesta del servicio

El servicio real recibe el ticket y el autentificador, desencripta el ticket y extrae la llave de sesión, entonces usa la llave la sesión para desencriptar el autentificador. Hecho esto, el servicio corre todas las pruebas de autentificación apropiadas.

Asumo que las pruebas confirmaron mi identidad. Ahora el servidor prepara un paquete de respuesta de manera que pueda probar su identidad, al programa cliente. Usa su copia de llave de sesión para encriptar el paquete de respuesta, y envía el paquete al cliente que esta esperando.

El cliente recibe el paquete e intenta desencriptarlo con mi copia de la llave de sesión. Si el paquete se desencripta apropiadamente y produce el mensaje de respuesta correcto del servidor , mi programa cliente sabe que el servidor que encriptó el paquete es el servidor real. Ahora el cliente manda el curriculum al servicio de impresión.

Supón que mi jefe arreglo el sistema de manera tal que su servidor de impresión parece al que yo quiero. Mi cliente manda el autentificador y el ticket al servicio de impresión y espera su respuesta. El servicio de impresión falso no puede generar la respuesta correcta porque no puede desencriptar el ticket y obtener la llave de sesión. Mi cliente no mandará el trabajo hasta que reciba la respuesta correcta. Eventualmente el cliente se da por vencido.

Mi trabajo de impresión no se completa, pero al menos mi curriculum no termino en el escritorio del enemigo..

Sabes, creo que tenemos bases sólidas sobre las cuales implementar el Sistema de Autentificación Charon.