Asegura que los datos no se modifican en tránsito. Se requiere autenticación de cada mensaje, sin importar el contenido del mismo. Éstos se denominan mensajes seguros.
Privacidad de datos:
Asegura que los datos no son leídos en tránsito. En este caso no sólo se autentica cada mensaje sino que también se encripta. Éstos son mensajes privados.
Especificación técnica
Hay tres fases básicas para el procedimiento de autenticación:
Solicitud de credenciales que se utilizarán al solicitar servicios.
Solicitud de credenciales para tener acceso a determinado servicio.
Presentación de credenciales al servidor deseado.
Hay dos tipos de credenciales que se utilizan en el modelo de autenticación de Kerberos: Tickets y Autenticadores. Aunque ambos se basan en encriptado de clave privada, se encriptan con claves diferentes. El ticket se usa para pasarle al servidor final la identidad de la persona para la que fue emitido. El autenticador es una prueba de que el ticket fue creado para el usuario y no fue robado; contiene información que al ser comparada contra la que está en el ticket prueba que el usuario que lo presenta es el mismo al que le fue emitido.
Notación:
c = cliente
s = servidor
addr = dirección de red del cliente
Kx = Clave privada de x
Kx,y = Clave de sesión de x e y
{info}Kx = Información encriptada con la clave privada de x
Tx,y = Ticket de x para usar y
Ax = Autenticador para x
Conexión inicial
Cuando el usuario entra a una estación de trabajo lo único que puede probar su identidad es su contraseña. El intercambio inicial con el AS está diseñado para minimizar la posibilidad de comprometer la contraseña, impidiendo a su vez que el usuario se autentique sin conocerla. Para el usuario, el proceso de "loguearse" al sistema será igual que el de "loguearse" a una red clásica. Sin embargo lo que ocurre por detrás es muy diferente.
Al usuario se le pide el nombre de usuario. El nombre del usuario tiene tres componentes básicos:
Nombre primario | – | Nombre del usuario | |||||||||||||||||||||||||||||||||||||||||
Instancia | – | Se usa para distinguir entre variantes del nombre primario o bien para determinar privilegios, como ser "root" o admin. | |||||||||||||||||||||||||||||||||||||||||
Dominio (Realm) | – | Es el nombre de una entidad administrativa que mantiene datos de autenticación. | |||||||||||||||||||||||||||||||||||||||||
Los nombres de usuario se forman como nombre.instancia@realm
Un ejemplo de nombre podría ser juan.root@mit
Una vez obtenido, se envía una solicitud al AS que consiste de el nombre de usuario y el nombre de un servicio especial llamado ticket-granting service, el cual se encuentra en un servidor que se llamará ticket-granting server (TGS). Este es el servicio que permitirá al cliente autenticarse con los servicios de red.
El AS chequea la información sobre el cliente. Si sabe quién es, genera una clave de sesión aleatoria que se usará luego entre el cliente y el TGS. Luego crea un ticket para el TGS que se llama ticket-granting ticket (TGT) y que deberá ser presentado al TGS cada vez que se solicite un servicio.
TGT ={Tc,tgs}Ktgs={c,tgs,addr,timestamp,lifetime,Kc,tgs}Ktgs
El TGT, al igual que cualquier otro ticket tiene 6 componentes:
Nombre del cliente
Nombre del servidor (en este caso TGS)
Dirección de red
Sello de tiempo (Timestamp)
Tiempo de vida (Lifespan)
Clave de sesión
Esta información se encripta con la clave privada del TGS, que sólo conocen el TGS y el AS. El AS envía el ticket al cliente, junto con una copia de la clave de sesión. La respuesta que recibe éste, está encriptada con la clave privada del cliente, que se deriva de la contraseña del usuario y que conocen sólo el AS y el cliente.
Una vez que la respuesta ha sido recibida por el cliente, se le pide la contraseña al usuario. La contraseña se convierte a una clave DES y se usa para desencriptar la respuesta del AS. El ticket y la clave de sesión se guardan para usar en el futuro, mientras que la contraseña del usuario y la clave DES se borran de la memoria. Así, si el cliente posee el ticket es porque el usuario conocía la contraseña correcta y por tanto debe ser quien dice ser.
3. ¿Porqué toda esta información en el ticket?
Un ticket sirve para un solo servidor y para un solo cliente pero una vez emitido, puede ser utilizado muchas veces por el cliente para tener acceso a ese servidor, hasta que el ticket expira. Como el ticket está encriptado con la clave del servidor no se pierde seguridad al permitir que el usuario le pase el ticket al servidor, ya que no podrá modificarlo.
El nombre del usuario es la información básica para pasarle al servidor. Así se le está informando quién está solicitando el servicio.
Si no estuviera el nombre del servidor, y solamente se enviara el nombre del usuario, entonces el servidor no sabría si desencriptó bien la información. En cambio al ver su nombre en el ticket, se asegura de que los datos son correctos.
Sin la dirección de red alguien podría copiar el ticket mientras viaja por la red, y luego, convencer a su estación de trabajo insegura de que el nombre de usuario del ladrón es el de la persona a quien se le está robando el ticket. Desde la estación envía el ticket al servidor, éste lo desencripta y ve que el nombre del que mandó el ticket es el mismo que está en el ticket, y por ende le da acceso. Agregar la dirección de red evita este problema.
El sello de tiempo se agrega para impedir lo que se llama ataques de "replay". Esto ocurre cuando se roba un mensaje mientras viaja por la red y se intenta usar más tarde.
El tiempo de vida es el tiempo durante el cual el ticket es válido. Los tickets deben tener un tiempo de vida fijo porque si no expiraran nunca, representarían un riesgo de seguridad muy grande. Por ejemplo, si los tickets no se destruyeran y alguien lograra entrar a la estación de trabajo, podría tomarlos y utilizarlos haciéndose pasar por su verdadero dueño.
Aun con el sello de tiempo, es posible que un ataque de "replay" se lleve a cabo. Si alguien dejara su estación de trabajo antes de que el ticket expirara, sería posible que éste fuera utilizado durante el tiempo que resta. Con la clave de sesión, las partes interesadas comparten un secreto y se impide a través del autenticador que pueda ocurrir un ataque de "replay".
Servicios
Como un ticket sirve para un solo servidor, es necesario obtener un nuevo ticket para cada servicio que el usuario quiera utilizar. Los tickets para los distintos servidores se pueden obtener a través del TGS.
La idea del TGS surge para evitar que el usuario deba entrar su contraseña más de una vez. Aunque pueden convivir en la misma máquina, el TGS es lógicamente distinto del AS. A veces se refiere a ambos como KDC ("Key Distribution Center").
Cuando un programa requiere un ticket que no ha sido solicitado aún, envía una solicitud al TGS. La solicitud contiene el nombre del servidor para el que se solicita el ticket, el TGT y un autenticador. A diferencia del ticket, el autenticador sólo se puede utilizar una vez. De lo contrario, sería posible robar el ticket y el autenticador juntos y hacer el "replay" de todas formas. Se debe generar uno nuevo cada vez que el cliente quiere utilizar un servicio, pero esto no presenta un problema porque como el cliente tiene toda la información necesaria, puede construir el autenticador por sí mismo. Un autenticador contiene el nombre del cliente, la dirección IP de la estación de trabajo, y el tiempo actual, y está encriptado con la clave de sesión que es parte del ticket; en este caso, la que comparten el cliente y el TGS.
El TGS chequea el autenticador y el TGT. Si son válidos genera una nueva clave de sesión aleatoria a ser usada entre el cliente y el nuevo servidor. Luego construye un ticket para el nuevo servidor con el nombre del cliente, el nombre del servidor, el tiempo actual, la dirección IP del cliente y la nueva clave de sesión. El tiempo de vida del nuevo ticket será el mínimo entre lo que queda de vida del TGT y el tiempo de vida por defecto del servicio.
Luego, el TGS envía el ticket junto con la clave de sesión nuevamente al cliente. Esta vez, sin embargo, la respuesta está encriptada con la clave de sesión que había en el TGT. De este modo, no hay necesidad para el usuario de volver a entrar su contraseña una vez más.
Solicitud de Servicios
Cuando el cliente tiene el ticket para el servidor deseado lo envía al servidor junto con el autenticador:
Una vez que el servidor recibió el ticket y el autenticador, desencripta el ticket con su clave privada. Si éste no expiró usa la clave de sesión que se encuentra dentro para desencriptar el autenticador y compara la información del ticket con la del autenticador. Si todo está bien, permite el acceso porque después de este intercambio, el servidor está seguro que de acuerdo a Kerberos, el usuario es quien dice ser.
Se asume que los relojes están sincronizados. Si el tiempo de la solicitud está muy lejos en el futuro o en el pasado, el servidor considera que la solicitud es un intento de hacer un "replay" de una solicitud anterior. Además, el servidor mantiene un registro de todas las solicitudes pasadas con sellos de tiempo aún válidos y si recibe una solicitud con el mismo ticket y el mismo sello de tiempo que una anterior, la descarta.
Finalmente, el cliente puede querer que el servidor pruebe su identidad también. Entonces, el servidor le suma uno al sello de tiempo que el cliente envió en el autenticador, encripta el resultado con la clave de sesión y envía el resultado de vuelta al cliente.
{timestamp +1}Kc,s
Esto demuestra que el servidor pudo leer el sello de tiempo del autenticador y para ello debió obtener la clave de sesión que se encontraba en el ticket encriptado con su clave privada. Entonces el cliente se cerciora de que el servidor es auténtico. Además, el cliente y el servidor comparten un secreto que nadie más sabe, y pueden asumir que un mensaje relativamente reciente encriptado con esa clave fue originado por el otro.
A los ojos del usuario
Para el usuario la presencia de Kerberos es casi imperceptible. El TGT se obtiene como parte del proceso de "login". Y los tickets son destruidos automáticamente cuando el usuario termina la sesión. El usuario notará la presencia de Kerberos si su sesión dura más de 8 horas. En ese caso, si intenta acceder a algún servicio que utilice autenticación por medio de Kerberos el intento fallará porque el ticket habrá expirado.
5. Administración
Administración General
Para el administrador del sistema, la presencia de Kerberos implica cierto mantenimiento.
El administrador debe inicializar la base de datos de Kerberos al instalarlo. Además en caso de tener la base de datos replicada (con slaves), también será necesario administrarlas para que se mantengan consistentes. Esto implica tener que sincronizar las bases de datos replicadas con la base de datos principal cada cierto tiempo.
Se debe tener especial cuidado con la administración de las máquinas que tienen la base de datos Kerberos, pues el sistema podría volverse inseguro si alguien obtiene el control de alguna de estas máquinas.
El administrador también debe asegurarse de que la fecha y hora de todas máquinas del sistema estén medianamente sincronizadas.
Cuando una aplicación Kerberos es agregada al sistema, el administrador debe realizar varias operaciones para dejarla funcional. El servidor kerberizado debe ser registrado en la base de datos, y se le debe asignar una clave privada. Luego algunos datos deben ser transferidos al nuevo servidor.
Además se aconseja tener la base de datos principal resguardada, en caso de que el disco en el que reside falle.
Administración entre sistemas Kerberos
Cada sistema Kerberos contiene como parte de su nombre el realm (dominio) asociado. Esto permite que distintos sistemas Kerberos se comuniquen entre sí para brindarse servicios.
Cuando un usuario se autentica con un sistema Kerberos, lo hace a un realm específico. Las aplicaciones kerberizadas generalmente reconocen credenciales de un realm particular; pero los usuarios pueden obtener credenciales de otros realms distintos del realm local. Para ello deben estar autenticados con el sistema Kerberos local, y los dos sistemas Kerberos (el local y el remoto) deben ponerse de acuerdo para brindar las credenciales necesarias en el sistema Kerberos remoto.
Los administradores de cada par de sistemas Kerberos que desean cooperar deben ponerse de acuerdo en la clave privada a utilizar para que los sistemas se comuniquen entre ellos.
Kerberos soporta la transitividad de la confianza; la idea es que si un sistema Kerberos confía en un segundo, y ese segundo confía en un tercer sistema Kerberos, entonces hay automáticamente una relación de confianza entre el primer y el tercer realm. La transitividad de la confianza asegura que los sistemas Kerberos sólo necesitan compartir una contraseña con los sistemas Kerberos de los realms inmediatamente encima y debajo de ellos en la jerarquía de realms (Kerberos se encarga del resto).
En Microsoft NT 4.0, el protocolo primario para la seguridad es NTLM (Windows NT LAN Manager). Para Windows 2000, Microsoft eligió un nuevo protocolo de seguridad: Kerberos, por tener algunas ventajas como ser un estándar, más eficiente en el uso de la red y permitir autenticación mutua.
Para permitir interoperabilidad con otras implementaciones, Kerberos en Windows 2000 soporta DES (Data Encription Standard), pero por defecto usa como algoritmo para encriptación RC4 (fue elegido porque es más rápido y seguro que DES). En Estados Unidos usa claves de 128-bits, mientras que en las versiones internacionales soporta claves de solamente 56-bits.
El protocolo de tickets de Kerberos fue adoptado y extendido por Microsoft, agregando un certificado de privilegios a los tickets (relacionado con el identificador único de NT, así como la lista de los grupos a los que el usuario pertenece).
Windows 2000 lo renovará automáticamente mientras el usuario permanezca "logueado". La primera vez que un usuario pide un ticket a Kerberos es cuando se "loguea" en alguna cuenta en el dominio de Windows 2000.
El KDC rechaza cualquier autenticador cuya timestamp sea demasiado vieja (por defecto 5 minutos máximo). Esto implica que los relojes de las máquinas que usen Kerberos deben estar sincronizados, por eso Windows 2000 usa el protocolo SNTP (Simple Network Time Protocol) de la IETF para sincronización.
Limitaciones
Kerberos no tiene efectividad frente a ataques como el de diccionario. Si el usuario escoge una contraseña pobre, un atacante que la consiga tratando de adivinarla puede hacerse pasar por él.
Kerberos requiere un camino seguro para entrar las contraseñas. Si un usuario entra una contraseña a un programa que ha sido modificado por un atacante, o si la comunicación entre el usuario y el programa de autenticación inicial puede ser monitoreada, entonces el atacante puede llegar a obtener suficiente información para hacerse pasar por el usuario. Kerberos puede combinarse con otras técnicas para eliminar estas limitaciones.
No hay un lugar seguro donde guardar las claves de sesión. De hecho, el lugar donde se guardan puede ser accedido por el root. Así es que un intruso que logre crackear el mecanismo de protección de la computadora local podrá robar las claves de sesión.
El protocolo liga los tickets a las direcciones de red y esto es un problema en hosts con más de una dirección IP. En las estaciones de trabajo esto rara vez ocurre.
Para que Kerberos sea útil debe integrarse con otras partes del sistema. No protege todos los mensajes que se envían entre dos computadoras. Sólo protege los mensajes desde el software que se ha escrito o modificado para usarlo. Aunque puede ser utilizado para intercambiar claves de encriptado cuando se establece un vínculo y niveles de seguridad de servicios de red, esto requeriría cambios en el software de los hosts involucrados.
Tiempo de vida de un ticket. La elección del tiempo de vida de los tickets no es trivial. Si se elige un tiempo de vida para los tickets muy largo, y un usuario desprevenido olvida desloguearse de una máquina, otra persona puede tomar su lugar. Por otro lado, si el tiempo de vida de los tickets es muy corto, el usuario va a ser molestado cada cierto tiempo para que ingrese nuevamente su contraseña.
Manejo de proxies. Todavía no esta claro cómo permitir autenticación mediante proxies, es decir que un servidor utilice servicios de otros servidores en nombre de un usuario autenticado. Una solución tentativa es la de permitir que un usuario transfiera momentáneamente sus credenciales hacia otra máquina para poder obtener servicios de ella; pero esto no siempre es deseable pues el usuario podría no confiar en la máquina remota.
Estados Unidos no permite exportar criptografía, por lo que Kerberos no se puede distribuir en otros países tal como fue creado. Pero hay mucho software legal, que se exporta y que se basa en el uso de Kerberos. Por esta razón, para poder sacarlo del país se creó Bones, que es una versión de Kerberos sin las llamadas a las funciones criptográficas (carece de toda funcionalidad). De todos modos, Errol Young se las ingenió para ponerle a Bones las llamadas criptográficas nuevamente, creando Encrypted Bones, o E-bones.
Jennifer G. Steiner, Clifford Neuman, Jeffrey I. Schiller.
Kerberos: An Authentication Service for Open Network Systems
ftp://athena-dist.mit.edu/pub/Kerberos/doc/usenix.txt (10 Mayo 2001, 15:36)
Bill Bryant.
Designing an Authentication System: a Dialogue in Four Scenes http://web.mit.edu/Kerberos/www/dialogue.html (10 Mayo 2001, 21:52)
Brian Tung.
The Moron"s Guide to Kerberos
http://www.isi.edu/gost/brian/security/Kerberos.html (11 Mayo 2001, 10:19)
Steven M. Bellovin, Michael Merritt.
Limitations of the Kerberos Authentication System
ftp://research.att.com/dist/internet_security/kerblimit.usenix.ps (10 Mayo 2001 15:40)
Roger M. Needham, Michael D. Schroeder.
Using Encryption for Authentication in Large Networks of Computers
Communications of the ACM 21(12) pp. 993-999 (Diciembre 1978)
John Kohl, Clifford Neuman.
RFC 1510
http://rfc.net/rfc1510.html (10 Mayo 2001, 22:00)
FAQ about Kerberos
http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html (10 Mayo 2001, 22:03)
Kerberos explained
http://www.microsoft.com/TechNet/win2000/kerberos.asp?a=printable (10 Mayo 2001, 22:07)
Exploring Kerberos, the protocol for distributed security in Windows 2000 http://www.microsoft.com/msj/0899/kerberos/kerberos.htm (10 Mayo 2001, 22:10)
Autor:
Tali Kimelman
Estudiante de 5º año
Facultad de Ingeniería
Universidad de la República Oriental del Uruguay
| Página siguiente |