Protocolos LDAP y Kerberos

LDAP

Descripción y Origen de LDAP.

LDAP son las siglas de Lightweight Directory Access Protocol (en español Protocolo Ligero/Simplificado de Acceso a Directorios) que hacen referencia a un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también se considera una base de datos a la que pueden realizarse consultas.

Un directorio es un conjunto de objetos con atributos organizados en una manera lógica y jerárquica.

Un árbol de directorio LDAP a veces refleja varios límites políticos, geográficos u organizacionales, dependiendo del modelo elegido. Los despliegues actuales de LDAP tienden a usar nombres de Sistema de Nombres de Dominio para estructurar los niveles más altos de la jerarquía. Conforme se desciende en el directorio pueden aparecer entradas que representan personas, unidades organizacionales, impresoras, documentos, grupos de personas o cualquier cosa que representa una entrada dada en el árbol (o múltiples entradas).

Habitualmente, almacena la información de autenticación (usuario y contraseña) y es utilizado para autenticarse aunque es posible almacenar otra información (datos de contacto del usuario, ubicación de diversos recursos de la red, permisos, certificados, etc.). A manera de síntesis, LDAP es un protocolo de acceso unificado a un conjunto de información sobre una red.

En las primeras etapas de ingeniería de LDAP, éste era conocido como Lightweight Directory Browsing Protocol, o LDBP. Posteriormente fue renombrado dado que el ámbito del protocolo había sido expandido para incluir no sólo navegación en el directorio y funciones de búsqueda, sino también funciones de actualización de directorio.

LDAP ha influenciado protocolos posteriores de Internet, incluyendo versiones posteriores de X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), y Service Location Protocol (SLP).

Protocolo ligero de acceso a los servicios de directorio, específicamente X.500 basados ​​en los servicios de directorio. Se ejecuta sobre TCP/IP LDAP está descrito en los RFCs 1777 y 2251.

El objetivo del protocolo LDAP fue reemplazar al protocolo DAP integrándolo al TCP/IP. Desde 1995, DAP se convirtió en LDAP independiente, con lo cual se dejó de utilizar sólo para acceder a los directorios tipo X500. LDAP es una versión más simple del protocolo DAP.

Versiones de LDAP.

El protocolo LDAP actualmente se encuentra en su 3era versión y el IETF (Grupo de Trabajo de Ingeniería de Internet) lo ha estandarizado. Por lo tanto, existe una para cada versión de LDAP que constituye un documento de referencia:

·         RFC 1777 para LDAP v.2

·         RFC 2251 para LDAP v.3

LDAP le brinda al usuario métodos que le permiten:

·         Conectarse

·         Desconectarse

·         Buscar información

·         Comparar información

·         Insertar entradas

·         Cambiar entradas

·         Eliminar entradas

Asimismo, el protocolo LDAP (en versión 3) ofrece mecanismos de cifrado (SSL, etc.) y autenticación para permitir el acceso seguro a la información almacenada en la base.

Nivel de la arquitectura de red en el que actúa LDAP.

Actúa en la capa de aplicación del modelo TCP/IP y en la capa de aplicación, sesión y presentación del modelo OSI.

Características técnicas de LDAP.

El modelo de la información en un directorio LDAP se basa en entradas. Una entrada es una colección de atributos que posee un único Nombre Distinguido (DN)”. El DN se utiliza para referirse a la entrada de manera unívoca.

Cada atributo de una entrada tiene un tipo y uno o más valores. Los tipos son típicamente cadenas nemotécnicas como CN o “Nombre Común” para los nombres comunes, o mail para las direcciones de correo electrónico. La sintaxis de los valores depende del tipo de atributo.

¿Cómo está organizada la información? 

En LDAP, las entradas del directorio se organizan en una estructura jerárquica en forma de árbol invertido. Tradicionalmente, ésta estructura refleja las fronteras o límites geográficos y/u organizativos.

Por ejemplo, las entradas que representan a los países aparecen en la parte superior del árbol. Debajo de ellas estarán las entradas que representan a estados y organizaciones nacionales, después podrán existir entradas que representen unidades organizativas, personas, impresoras, documentos, o cualquier otra cosa que seamos capaces de pensar.

La figura a continuación es un ejemplo del árbol de un directorio LDAP en el que se utilizan los nombres tradicionales.

LDAP permite el control de los atributos que necesitamos para una entrada mediante el uso de un atributo especial denominado objectClass. El valor del atributo objectClass determina las Reglas del Esquema que la entrada debe obedecer.

¿Cómo hacemos referencia a la información? 

Hacemos referencia a una entrada mediante su Nombre Distinguido, el cual se construye a partir del nombre de la entrada en si misma (denominada Nombre Relativo Distinguido (RDN)), concatenada con el nombre de las entradas de sus antecesores.

¿Cómo accedemos a la información? 

LDAP tiene definidas las operaciones necesarias para interrogar y actualizar el directorio. Entre ellas se consideran las operaciones de adicionar y borrar una entrada, modificar una entrada existente, y cambiar el nombre de una entrada.

No obstante, la mayor parte del tiempo LDAP se utiliza para buscar información almacenada en el directorio. Las operaciones de búsqueda permiten que en una porción del directorio se busquen entradas que cumplan con algún criterio especificado en el filtro de búsqueda. De esa forma podemos buscar en cada entrada que cumplió con el criterio de búsqueda.

¿Cómo protegemos la información de accesos no autorizados?

Algunos servicios de directorios no tienen protección y permiten que cualquier persona consulte su información. LDAP provee un mecanismo para que los clientes se autentiquen, o confirmen su identidad ante un servicio de directorio, con el objetivo de garantizar un control de acceso para proteger la información que el servidor contiene.

LDAP soporta además los servicios de seguridad de datos, tanto con respecto a la integridad como a la confidencialidad.

Escalabilidad

Los directorios LDAP, particularmente cuando una base de datos relacional hace una copia de seguridad de ellos. El rendimiento de los directorios de gran tamaño con millones de entradas es excelente. Debido a la base estándar común, otro factor de escalabilidad es la posibilidad de configurar de manera simple hardware y software de mayores prestaciones. LDAP no se basa en un sistema operativo específico y es independiente del proveedor.

Disponibilidad

LDAP soporta la réplica y división de espacios de nombres. La réplica permite a varios servidores LDAP almacenar el contenido del mismo directorio. Esto permite a los clientes disponer de estos servidores adicionales cuando uno presenta anomalías. La división permite almacenar las secciones de todo el directorio en diferentes ubicaciones de servidores distintos. Esto no sólo aumenta la disponibilidad si no que simplifica la gestión distribuida.

Seguridad

LDAP soporta características de seguridad que impiden el acceso no autorizado a datos. Los protocolos de comunicación segura, como SSL y procedimientos de autenticación, junto con las políticas de listas de control de accesos (ACL) para entradas de datos, garantizan el máximo nivel de seguridad.

Gestionabilidad

Las versiones actuales de LDAP, como IBM SecureWay Directory, proporcionan una interfaz gráfica de usuario tanto para la administración de sistemas como para la administración de datos de directorio. Su esquema ampliable dinámicamente le permite ampliar el esquema de directorios sin interrumpir el servicio.

Estándares que se aplican a LDAP.

Está basado en el estándar X.500 para compartir directorios, pero es menos complejo e intensivo en el uso de recursos. Por esta razón, a veces se habla de LDAP como "X.500 Lite." El estándar X.500 es un directorio que contiene información de forma jerárquica y categorizada, que puede incluir nombres, directorios y números telefónicos.

El protocolo LDAP está definido por estándares oficiales o los RFC correspondientes.

Por ejemplo, Lightweight Directory Access Protocol (v3), RFC 2251, define el protocolo LDAP básico.

En borradores de Internet hay definidas otras características, ampliamente aceptadas e implementadas. Gran parte de este trabajo lo llevan a cabo IETF (Internet Engineering Task Force) y DMTF (Distributed Management Task Force).

La versión actual es LDAPv3, y se encuentra definido en los RFCs RFC 2251 y RFC 2256 (documento base de LDAP), RFC 2829 (método de autentificación para LDAP),RFC 2830 (extensión para TLS), y RFC 3377 (especificación técnica)

Documentos de referencia que definen y explican su funcionamiento.

Documento sobre LDAP:  LDAP y Kerberos\protocolo-ldap-269-k8u3gp.pdf
RFC 1777 para LDAP v.2: http://www.ietf.org/rfc/rfc1777.txt
RFC 2251 para LDAP v.3: http://www.ietf.org/rfc/rfc2251.txt

Documento de LDAP sobre introducción, configuración, funcionamiento, certificado y soluciones de problemas: LDAP y Kerberos\cv_mfc8510dn_spa_ldap_a.pdf

Funcionalidad o modo de actuación.

El servicio de directorio LDAP se basa en un modelo cliente-servidor. Uno o más servidores LDAP contienen los datos que conforman el árbol del directorio o base de datos troncal. El cliente LDAP se conecta con el servidor LDAP y le hace una consulta. El servidor contesta con la respuesta correspondiente, o bien con una indicación de dónde puede el cliente hallar más información. No importa con qué servidor LDAP se conecte el cliente: siempre observará la misma vista del directorio; el nombre que se le presenta a un servidor LDAP hace referencia a la misma entrada a la que haría referencia en otro servidor LDAP. Es ésta una característica importante de un servicio de directorios universal como LDAP.

LDAP brinda un conjunto de funciones (procedimientos) para llevar a cabo solicitudes en los datos para buscar, cambiar y eliminar entradas en los directorios.

A continuación encontrará una lista de las principales operaciones que puede realizar LDPA:

Interacción de los clientes y servidores utilizando dicho protocolo.

El servicio DNS se encarga de la traducción de nombres de dominio a direcciones IP y viceversa.

Tiene además una ligera similitud con el servicio de directorio, ya que ambos proporcionan un interfaz de acceso a una base de datos jerárquica. Pero difieren en otros aspectos:

·         El servicio DNS esta optimizado para realizar su cometido, es decir, la traslación de nombres de ordenadores a direcciones IP, mientras que los servidores de directorio están optimizados de forma más general.

·         La información almacenada en el servicio DNS tiene una estructura fija, mientras que el servicio de directorio suele permitir la extensión de dicha estructura.

·         El servicio de directorio permite actualizaciones, mientras que el servicio DNS no las permite.

El servicio DNS opera con protocolos no orientados a conexión (UDP), mientras que los servicios de directorio suelen utilizar protocolos orientados a conexión.

Kerberos

Descripción y Origen de Kerberos.

Kerberos es un protocolo de autenticación de redes de ordenador creado por el Instituto Tecnológico de Massachusetts (MIT) que permite a dos ordenadores en una red insegura demostrar su identidad mutuamente de manera segura. Sus diseñadores se concentraron primeramente en un modelo de cliente-servidor, y brinda autenticación mutua: tanto cliente como servidor verifican la identidad uno del otro. Los mensajes de autenticación están protegidos para evitar eavesdropping y ataques de Replay.

Kerberos se basa en criptografía de clave simétrica y requiere un tercero de confianza. Además, existen extensiones del protocolo para poder utilizar criptografía de clave asimétrica. MIT desarrollaron Kerberos para proteger los servicios de red proporcionados por Proyecto Athena. El protocolo se basa en el anterior protocolo de clave simétrica Needham-Schroeder.

Windows 2000, Windows XP y Windows Server 2003 usan una variante de Kerberos como su método de autenticación por defecto. Algunos agregados de Microsoft al conjunto de protocolos de Kerberos están documentados en la RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" (Protocolos de cambio y establecimiento de clave de tipo Kerberos en Microsoft Windows 2000). Mac OS X de Apple también usa Kerberos tanto en sus versiones de cliente y de servidor.

En 2005, la Internet Engineering Task Force grupo de trabajo Kerberos actualiza especificaciones. Incluyen actualizaciones:

• Cifrado y Checksum Especificaciones (RFC 3961).
• Advanced Encryption Standard (AES) para Kerberos 5 (RFC 3962).
• Una nueva edición de la especificación de Kerberos V5 "El servicio Kerberos Network Authentication (V5)" (RFC 4120). Esta versión obsoleta RFC 1510, aclara aspectos del protocolo y uso previsto en una explicación más detallada y clara.
• Una nueva edición de la GSSAPI especificación (GSS-API) "La versión de Kerberos 5 Generic Security Service Application Program Interface (GSS-API) Mecanismo: Versión 2." (RFC 4121).

      Kerberos se utiliza como método de autenticación preferido: En general, unirse a un cliente a un dominio de Windows significa permitir Kerberos como protocolo predeterminado para autenticaciones de ese cliente a los servicios en el dominio de Windows y todos los dominios con relaciones de confianza a dicho dominio.

Por el contrario, cuando el cliente o el servidor o ambos no están unidos a un dominio (o no parte de un mismo entorno de dominio de confianza), Windows en lugar de utilizar NTLM para la autenticación entre el cliente y el servidor.

Muchos sistemas operativos UNIX y UNIX, incluyendo FreeBSD, de Apple Mac OS X, Red Hat Enterprise Linux, Oracle 's Solaris, IBM AIX y Z / OS, HP OpenVMS y otros, incluyen el software para la autenticación Kerberos de los usuarios o servicios.

Versiones.

Existen varias versiones del protocolo, versiones 1-3 ocurrieron sólo internamente en el Instituto Tecnológico de Massachusetts (MIT).

Steve Miller y Clifford Neuman, los principales diseñadores de Kerberos versión 4, publicaron esa versión a finales de 1980, aunque habían dirigido principalmente para Proyecto Athena.

Versión 5, diseñado por John Kohl y Clifford Neuman, apareció como RFC 1510 en 1993 (hace obsoleto por RFC 4120 en 2005), con la intención de superar las limitaciones y los problemas de seguridad de la versión 4.

Actualmente se encuentran en uso común dos versiones de Kerberos:

§        Versión 4: que es la más ampliamente usada, y

§       Versión 5: que corrige algunas deficiencias de seguridad de la versión 4.

La Versión 5 intenta solucionar las limitaciones de la Versión 4 en dos áreas: fallas del entorno y deficiencias técnicas.

La Versión 4 de Kerberos no cubrió completamente las necesidades de ser de propósito general. Así se produjeron las siguientes fallas del entorno:

• Dependencia del sistema de cifrado: la Versión 4 requiere el uso de DES (Data Encryption Standar). En la Versión 5, el texto es encriptado con un identificador del tipo de cifrado, entonces puede ser usada cualquier técnica de cifrado.
• Dependencia del protocolo de Internet: la Versión 4 requiere el uso de direccionamiento IP. Los direccionamientos de red de la Versión 5 son identificados con tipo y longitud, permitiendo el uso de cualquier tipo de direccionamiento.
• Tiempo de vida del ticket: en la versión 4 el máximo tiempo de vida puede ser 1280 minutos. Esto puede ser inadecuado en algunas aplicaciones. En la Versión 5, los tickets incluyen explícitamente el tiempo de inicio y de fin, permitiendo tickets con tiempo de vida arbitrarios.
• Forwarding de autenticación: la Versión 4 no permite a un cliente forwardear su identidad a algún otro host y ser usada por algún otro cliente. Esta capacidad habilitaría a un cliente acceder a un servidor y que éste tenga acceso a otro servidor en beneficio del cliente. La Versión 5 provee esa capacidad.

Además de las limitaciones de entorno, existen deficiencias técnicas en la Versión 4 del protocolo. Estas deficiencias son las siguientes:

• Doble cifrado: los tickets provistos a los clientes son cifrados dos veces, una vez con la clave secreta del servidor destino y luego con una clave secreta conocida por el cliente. El segundo cifrado no es necesario y computacionalmente no es económico.
• Cifrado PCBC: en la Versión 4 el cifrado usa un modo no estándar de DES, conocido como PCBC. Fue demostrado que este método es vulnerable a un ataque que involucre el intercambio de bloques de texto cifrado. PCBC fue propuesta para proveer un chequeo de integridad como parte de la operación de cifrado. La Versión 5 provee mecanismos de integridad explícitos.
• Claves de sesión: la clave de sesión debe ser usada por el cliente y el servidor para proteger mensajes transmitidos durante esta sesión. De esta manera, como el mismo ticket debe ser usado repetidas veces para obtener el servicio desde un servidor particular, existe el riesgo que un adversario repita el mensaje desde una sesión vieja al cliente o al servidor. En la Versión 5 es posible que el cliente y el servidor negocien una clave de subsesión, la cual es usada solamente para una conexión. Un nuevo acceso del cliente resultaría en el uso de una nueva clave de subsesión.
• Ataques a las passwords: una vulnerabilidad compartida por ambas versiones es el ataque a las passwords. El mensaje desde el AS al cliente incluye material encriptado con una clave basada en la password del cliente. Un adversario puede capturar esa password de intentar descifrarla intentando con varias passwords posibles. Si se descubre la password del cliente, el adversario podrá usarla posteriormente para obtener credenciales de autenticación de Kerberos. La Versión 5 provee un mecanismo conocido como preautenticación, que dificultaría el ataque a las password, pero no lo prevendría.

Nivel de la arquitectura de red en el que actúa Kerberos.

Nivel de aplicación: se usa en el nivel 7 del modelo OSI, TELNET y FTP (autentificación usuario-host)

Nivel de presentación: se usa en mecanismos del tipo RPC (autentificación del flujo de datos).

Niveles de red y transporte: se usa en IP, UDP y TCP (autentificando de host a host).

Características técnicas de Kerberos.

·         Proporciona una sola identificación para comprobar la identidad del usuario en todos los servidores de la red.

·         La seguridad reside en los servidores de autentificación y no en los clientes y servidores de la red.

·         Kerberos provee sólo la autentificación, cada servidor debe decidir por sí mismo los controles de acceso de los usuarios autentificados.

·         Probar la identidad de las entidades que se comunican por medio de la red.

·         Prevenir los ataques.

·         Detectar la modificación de los datos (integridad).

·         Prevenir la lectura no autorizada usando DES (confidencialidad).

Ventajas

Los servicios de redes más convencionales usan esquemas de autenticación basados en contraseñas. Tales esquemas requieren que cuando un usuario necesita una autenticación en un servidor de red, debe proporcionar un nombre de usuario y una contraseña. Lamentablemente, la información de autenticación para muchos servicios se transmite sin estar encriptado. Para que un esquema de este tipo sea seguro, la red tiene que estar inaccesible a usuarios externos, y todos los usuarios de la red deben ser de confianza.

Aún en este caso, una vez que la red se conecte a Internet, ya no puede asumir que la red es segura. Cualquier intruso del sistema con acceso a la red y un analizador de paquetes pueden interceptar cualquier contraseña enviada de este modo, comprometiendo las cuentas de usuarios y la integridad de toda la infraestructura de seguridad.

El primer objetivo de Kerberos es el de eliminar la transmisión a través de la red de información de autenticación. Un uso correcto de Kerberos erradica la amenaza de analizadores de paquetes que intercepten contraseñas en su red.

Desventajas

A pesar de que Kerberos elimina una amenaza de seguridad común, puede ser difícil de implementar por una variedad de razones:

La migración de contraseñas de usuarios desde una base de datos de contraseñas estándar UNIX, tal como /etc/passwd o /etc/shadow, a una base de datos de contraseñas Kerberos, puede ser tediosa y no hay un mecanismo rápido para realizar esta tarea.

Kerberos presupone que cada usuario es de confianza, pero que está utilizando una máquina no fiable en una red no fiable. Su principal objetivo es el de prevenir que las contraseñas no cifradas sean enviadas a través de la red. Sin embargo, si cualquier otro usuario, aparte del usuario adecuado, tiene acceso a la máquina que emite tickets (KDC) para la autenticación, Kerberos estaría en riesgo.

Para que una aplicación use Kerberos, el código debe ser modificado para hacer las llamadas apropiadas a las librerías de Kerberos. Las aplicaciones que son modificadas de esta forma son consideradas como kerberizadas. Para algunas aplicaciones, esto puede suponer un esfuerzo excesivo de programación, debido al tamaño de la aplicación o su diseño. Para otras aplicaciones incompatibles, los cambios se deben realizar en el modo en que el servidor de red y sus clientes se comunican; de nuevo, esto puede suponer bastante programación. En general, las aplicaciones de código cerrado que no tienen soporte de Kerberos son usualmente las más problemáticas.

Finalmente, si decide usar Kerberos en su red, debe darse cuenta de que es una elección de todo o nada. Si decide usar Kerberos en su red, debe recordar que si se transmite cualquier contraseña a un servicio que no usa Kerberos para autenticar, se corre el riesgo de que el paquete pueda ser interceptado. Así, su red no obtendrá ningún beneficio de usar Kerberos. Para asegurar su red con Kerberos, solo debe utilizar las versiones kerberizadas de todas las aplicaciones cliente/servidor que envíen contraseñas sin cifrar o no utilizar ninguna de estas aplicaciones en la red.

Niveles de protección

Autenticación: Prueba que el usuario es quien dice ser. Puede ser que la autenticidad se establezca al inicio de la conexión de red y luego se asuma que los siguientes mensajes de una dirección de red determinada se originan desde la parte autenticada.

Integridad de datos: Asegura que los datos no se modifican en tránsito. Se requiere autenticación de cada mensaje, sin importar el contenido del mismo. Esto se denomina 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 cifra. Estos mensajes son privados.

Arquitectura de kerberos

Un servidor Kerberos se denomina KDC (Kerberos Distribution Center), y provee 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 de trabajo.

El ticket es un testigo expedido a un cliente del servicio de tickets de Kerberos para solicitar los servicios de un servidor. El ticket garantiza que el cliente ha sido autenticado recientemente.

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.

Estándares que se aplican.

Kerberos V5 es un estándar de Internet.

• Kerberos V5 Release 1.12
• krb5-1.12.1
• krb5-1.12
• Kerberos V5 Release 1.11
• krb5-1.11.4
• krb5-1.11.3
• krb5-1.11.2
• krb5-1.11.1
• krb5-1.11
• Kerberos V5 Release 1.10
• krb5-1.10.7
• krb5-1.10.6
• krb5-1.10.5
• krb5-1.10.4
• krb5-1.10.3
• krb5-1.10.2
• krb5-1.10.1
• krb5-1.10
• Kerberos V5 Release 1.9
• krb5-1.9.4
• krb5-1.9.3
• krb5-1.9.2
• krb5-1.9.1
• krb5-1.9
• Kerberos V5 Release 1.8
• krb5-1.8.6
• krb5-1.8.5
• krb5-1.8.4
• krb5-1.8.3
• krb5-1.8.2
• krb5-1.8.1
• krb5-1.8
• Kerberos V5 Release 1.7
• krb5-1.7.2
• krb5-1.7.1
• krb5-1.7
• Kerberos V5 Release 1.6
• krb5-1.6.2
• krb5-1.6.1
• krb5-1.6
• Kerberos V5, versión 1.5
• krb5-1.5.4
• krb5-1.5.3
• krb5-1.5.2
• krb5-1.5.1
• krb5-1.5
• Kerberos V5 Release 1.4
• krb5-1.4.4
• krb5-1.4.3
• krb5-1.4.2
• krb5-1.4.1
• krb5-1.4
• Kerberos V5 Release 1.3
• krb5-1.3.6
• krb5-1.3.5
• krb5-1.3.4
• krb5-1.3.3
• krb5-1.3.2
• krb5-1.3.1
• krb5-1.3
• Kerberos V5 Release 1.2
• Kerberos V5 Release 1.1
• 1.0.6 Kerberos V5 Release

Funcionalidad o modo de actuación.

Kerberos se basa en el Protocolo de Needham-Schroeder. Usa un tercero de confianza, denominado "centro de distribución de claves" (KDC, por sus siglas en inglés: Key Distribution Center), el cual consiste de dos partes lógicas separadas: un "servidor de autenticación" (AS o Authentication Server) y un "servidor emisor de tiquetes" (TGS o Ticket Granting Server). Kerberos trabaja sobre la base de "tickets", los cuales sirven para demostrar la identidad de los usuarios.

Kerberos mantiene una base de datos de claves secretas; cada entidad en la red sea cliente o servidor comparte una clave secreta conocida únicamente por él y Kerberos. El conocimiento de esta clave sirve para probar la identidad de la entidad. Para una comunicación entre dos entidades, Kerberos genera una clave de sesión, la cual pueden usar para asegurar sus problemas.

Funcionamiento general:

•       Cada usuario dispone de una clave.
•       Cada servidor dispone de una clave.
•       Kerberos mantiene una base de datos que contendrá a todas estas claves.
•      La clave es un usuario será derivada de su contraseña y estará cifrada.
•       La clave de un servidor se genera aleatoriamente.
•      Los servicios de red que requieren autenticación, así como los usuarios que requieran estos servicios, se deben registrar con Kerberos.
•      Las claves privadas se negocian cuando los usuarios se registran.
•      Kerberos, en conocimiento de todas las claves privadas, crea mensajes para informar a un servidor de la autenticidad de un usuario que requiere servicios de éste.

A continuación se describe someramente el protocolo. Se usaran las siguientes abreviaturas:

·         AS = Authentication Server

·         TGS = Ticket Granting Server

·         SS = Service Server

En resumen el funcionamiento es el siguiente: el cliente se autentica a sí mismo contra el AS, así demuestra al TGS que está autorizado para recibir un ticket de servicio (y lo recibe) y ya puede demostrar al SS que ha sido aprobado para hacer uso del servicio kerberizado.

En más detalle:

·       Un usuario ingresa su nombre de usuario y password en el cliente

·       El cliente genera una clave hash a partir del password y la usará como la clave secreta del cliente.

·       El cliente envía un mensaje en texto plano al AS solicitando servicio en nombre del usuario. Nota: ni la clave secreta ni el password son enviados, solo la petición del servicio.

·       El AS comprueba si el cliente está en su base de datos. Si es así, el AS genera la clave secreta utilizando la función hash con la password del cliente encontrada en su base de datos. Entonces envía dos mensajes al cliente:

o  Mensaje A: Client/TGS session key cifrada usando la clave secreta del usuario

o  Mensaje B: Ticket-Granting Ticket (que incluye el ID de cliente, la dirección de red del cliente, el período de validez y el Client/TGS session key) cifrado usando la clave secreta del TGS.

·       Una vez que el cliente ha recibido los mensajes, descifra el mensaje A para obtener el client/TGS session key. Esta session key se usa para las posteriores comunicaciones con el TGS. (El cliente no puede descifrar el mensaje B pues para cifrar éste se ha usado la clave del TGS). En este momento el cliente ya se puede autenticar contra el TGS.

·       Entonces el cliente envía los siguientes mensajes al TGS:

o  Mensaje C: Compuesto del Ticket-Granting Ticket del mensaje B y el ID del servicio solicitado.

o  Mensaje D: Autenticador (compuesto por el ID de cliente y una marca de tiempo), cifrado usando el client/TGS session key.

·       Cuando recibe los mensajes anteriores, el TGS descifra el mensaje D (autenticador) usando el client/TGS session key y envía los siguientes mensajes al cliente:

o  Mensaje E: Client-to-server ticket (que incluye el ID de cliente, la dirección de red del cliente, el período de validez y una Client/Server session key) cifrado usando la clave secreta del servicio.

o  Mensaje F: Client/server session key cifrada usando el client/TGS session key.

·       Cuando el cliente recibe los mensajes E y F, ya tiene suficiente información para autenticarse contra el SS. El cliente se conecta al SS y envía los siguientes mensajes:

o  Mensaje E del paso anterior.

o  Mensaje G: un nuevo Autenticador que incluye el ID de cliente, una marca de tiempo y que está cifrado usando el client/server session key.

·       El SS descifra el ticket usando su propia clave secreta y envía el siguiente mensaje al cliente para confirmar su identidad:

o  Mensaje H: la marca de tiempo encontrada en el último Autenticador recibido del cliente más uno, cifrado el client/server session key.

·       El cliente descifra la confirmación usando el client/server session key y chequea si la marca de tiempo está correctamente actualizada. Si esto es así, el cliente confiará en el servidor y podrá comenzar a usar el servicio que este ofrece.

·       El servidor provee del servicio al cliente.

Interacción de los clientes y servidores utilizando dicho protocolo.

Un cliente que precise trabajar con un servidor debe autenticarse primero ante el KDC y proporcionar a este la autenticación del servidor. El KDC generará una clave que es transmitida a cliente y servidor.

]Volver a Inicio[