Protocolo Kerberos

Este tema cubre los siguientes conceptos del protocolo Kerberos:

  • La función de Kerberos
  • El proceso de autenticación
  • Las presunciones del entorno de seguridad
  • El objetivo de los reinos
  • Los archivos del protocolo Kerberos
  • La antememoria de credenciales
  • La antememoria de reproducción
  • La tabla de claves
  • La función de Kerberos

Kerberos realiza la autenticación como un servicio de autenticación de confianza de terceras partes utilizando el convencional cifrado de clave secreta compartida. Kerberos proporciona un modo de comprobar las identidades de los sujetos, sin confiar en la autenticación por parte del sistema operativo del sistema principal, sin tener que basar la confianza en direcciones del sistema principal, sin que sea necesaria una seguridad física de todos los sistemas principales de la red y asumiendo que los paquetes que viajan por la red pueden leerse, modificarse e insertarse a voluntad.

El proceso de autenticación

El proceso de autenticación incluye los siguientes pasos principales:

1) El cliente solicita credenciales. Los dos métodos para obtener credenciales, el intercambio de ticket inicial y el intercambio de ticket que otorga tickets, utilizan protocolos algo distintos y requieren rutinas de interfaz de programación de aplicaciones (API) diferentes.

La diferencia básica para un programador de aplicaciones es que el intercambio de ticket inicial no requiere un ticket que otorga tickets (TGT), sino que requiere la clave secreta del cliente. Normalmente, el intercambio de ticket inicial se utiliza para TGT y los intercambios de TGT se utilizan a partir de entonces. En un intercambio de TGT, el TGT se envía como parte de la petición de un ticket y la respuesta se cifra en la clave de sesión que se obtiene del TGT. Por lo tanto, cuando se ha utilizado una contraseña de usuario para obtener el TGT inicial, no se necesitará en posteriores intercambios de TGT para obtener tickets adicionales.

Un ticket que otorga tickets contiene el servidor Kerberos (krbtgt/realm) como nombre de servidor. Un ticket de servicio contiene el servidor de aplicación como nombre de servidor. Un ticket que otorga tickets se utiliza para obtener tickets de servicio. Para obtener un ticket de servicio para un servidor de otro reino, la aplicación debe antes obtener un ticket que otorga tickets del servidor Kerberos de dicho reino.

2) La respuesta del servidor Kerberos consiste en un ticket y una clave de sesión, cifrados en la clave secreta del usuario o la clave de sesión del TGT. La combinación de un ticket y una clave de sesión se conoce como juego decredenciales. Un cliente de aplicaciones puede utilizar estas credenciales para autenticarse en el servidor de aplicaciones enviando el ticket y un autenticador al servidor. El autenticador se cifra en la clave de sesión del ticket e incluye el nombre del cliente, el nombre del servidor y la hora en la que se creó el autenticador.

3) Para verificar la autenticación, el servidor de aplicaciones descifra el ticket utilizando su clave de servicio que sólo conoce el servidor de aplicaciones y el servidor Kerberos. Dentro del ticket, el servidor Kerberos ha incorporado el nombre del cliente, el nombre del servidor, una clave de sesión asociada con el ticket y cierta información adicional.

4) A continuación, el servidor de aplicaciones utiliza la clave de sesión del ticket para descifrar el autenticador y comprueba que la información del autenticador concuerda con la información del ticket. El servidor también comprueba que la indicación de la hora del autenticador es reciente para evitar ataques de reproducción (el valor por omisión es 5 minutos). Puesto que el servidor Kerberos generó la clave de sesión de forma aleatoria y dicha clave se envió cifrada en la clave de servicio y una clave que sólo conoce el usuario, si el usuario pudo descifrar el autenticador en la clave correcta, el servidor de aplicaciones puede estar seguro de que el usuario es verdaderamente quién dice ser.

Para facilitar la detección de ataques de reproducción y ataques de modificación de la corriente del mensaje, también puede garantizarse la integridad de todos los mensajes intercambiados entre sujetos generando y transmitiendo una suma de comprobación a prueba de colisiones del mensaje del cliente, que incorpore la clave de la sesión. Puede garantizarse la privacidad e integridad del mensaje intercambiado entre sujetos cifrando los datos que se deben transmitir con la clave de sesión.

API de Servicios de seguridad genéricos y protocolo Kerberos

El servicio de autenticación de red utiliza el protocolo Kerberos junto con las API GSS (Generic Security Services) para la autenticación. El protocolo Kerberos proporciona un medio de verificar la identidad de un sujeto, ya sea un usuario o una aplicación, en una red sin protección. Cuando el sujeto solicita un servicio, un servidor centralizado de confianza, conocido como Centro de distribución de claves (KDC), verifica su identidad.

Las presunciones del entorno de seguridad

El protocolo Kerberos asume que todos los intercambios de datos se producen en un entorno en el que pueden insertarse, modificarse o interceptarse paquetes a voluntad. Utilice Kerberos como uno de los niveles de un plan de seguridad global. A pesar de que el protocolo Kerberos le permite autenticar usuarios y aplicaciones en la red, debe tener en cuenta ciertas restricciones al definir sus objetivos de seguridad de la red:

  • El protocolo Kerberos no protege contra ataques de denegación de servicio. Existen lugares en estos protocolos donde un intruso puede evitar que una aplicación participe en los pasos de autenticación apropiados. Es preferible dejar la detección y solución de dichos ataques en manos de administradores y usuarios humanos.
  • El proceso de compartir claves o el robo de claves puede permitir ataques de imitación. Si de algún modo los intrusos logran robar la clave de un sujeto, podrán hacerse pasar por dicho usuario o servicio. Para minimizar esta amenaza, prohíba a los usuarios compartir sus claves e incluya esta política en sus normas de seguridad.
  • El protocolo Kerberos no protege contra las vulnerabilidades típicas de las contraseñas, como el adivinar una contraseña. Si un usuario escoge una contraseña sencilla, un pirata podría montar con éxito un ataque de diccionario fuera de línea intentando repetidamente descifrar mensajes que se han cifrado bajo una clave derivada a partir de la contraseña del usuario. Para garantizar que los usuarios seleccionan una contraseña segura, defina directrices para la elección de contraseñas e inclúyalas en su política de seguridad de la empresa. Para obtener más detalles, consulte “Establecer reglas para las contraseñas ” en Consejos y herramientas iSeries 400 para proteger su iSeries 400.

El objetivo de los reinos

El protocolo Kerberos opera a través de los límites de la empresa. Si una empresa desea tener un control local de la autenticación de sus usuarios, puede ejecutar su propio servidor Kerberos. Todos los usuarios y las aplicaciones que utilizan un servidor Kerberos constituyen un reino. El nombre del reino en el que está registrado un cliente es parte del nombre del cliente y el servidor de aplicaciones puede utilizarlo para decidir si acepta una petición.

Estableciendo claves de varios reinos, los administradores de dos reinos pueden permitir que un cliente autenticado en un reino utilice sus credenciales en el otro reino. El intercambio de claves de varios reinos registra el servicio de concesión de tickets de cada reino como sujeto en el otro reino. Un sujeto puede solicitar un ticket para el servicio de concesión de tickets del reino remoto desde su servicio local de concesión de tickets. Entonces, un cliente puede obtener un ticket que otorga tickets para el servicio de concesión de tickets del reino remoto desde su servicio de concesión de tickets local. Los tickets emitidos a un servicio del reino remoto indican que el cliente se autenticó en otro reino.

Este método puede repetirse para autenticar sujetos de una empresa en múltiples reinos. Para crear una vía de autenticación válida a un reino remoto, el reino local debe compartir una clave de varios reinos con el reino de destino o con un reino intermedio que se comunique con el reino de destino o con otro reino intermedio.

Normalmente los reinos se organizan jerárquicamente. Cada reino comparte una clave con su padre y una clave distinta con cada hijo. Si dos reinos no comparten directamente una clave de varios reinos, la organización jerárquica permite construir fácilmente una vía de autenticación. Si no utiliza una organización jerárquica, quizás deba consultar una base de datos para construir una vía de autenticación entre reinos.

A pesar de que los reinos normalmente son jerárquicos, es posible evitar reinos intermedios para lograr una autenticación de varios reinos mediante vías de autenticación alternativas. Es importante que el servicio final conozca qué reinos se cruzaron al decidir la confianza que deposita en el proceso de autenticación. Para facilitar esta decisión, existe un campo en cada ticket con los nombres de los reinos involucrados en la autenticación de un cliente.

Los archivos del protocolo Kerberos

El protocolo Kerberos utiliza este tipo de archivos durante el procesamiento:

  • Antememoria de credenciales
  • Antememoria de reproducción
  • Tabla de claves

Cada tipo de archivo tiene un conjunto de API para gestionar y manipular el archivo.

La antememoria de credenciales

La antememoria de credenciales guarda las credenciales del protocolo Kerberos (tickets, claves de sesión y otro tipo de información de identificación) en almacenamiento semipermanente. El protocolo Kerberos lee las credenciales de la antememoria cuando las necesita y almacena nuevas credenciales en la antememoria cuando las obtiene. De este modo se libera a la aplicación de la responsabilidad de gestionar las credenciales por sí misma.

El protocolo Kerberos soporta estos tipos de antememoria de credenciales: de archivo y de memoria. La antememoria de credenciales de archivo se guarda en un archivo y puede compartirse entre procesos. La antememoria de credenciales de memoria se guarda en depósito y sólo pueden acceder a ella el proceso y el grupo de activación que la crearon. Además, una antememoria de credenciales de archivo perdura hasta que se suprime, mientras que una antememoria de credenciales de memoria deja de existir cuando el sistema reclama el grupo de activación de la aplicación.

La antememoria de reproducción

La antememoria de reproducción se utiliza para detectar peticiones duplicadas. Cuando el protocolo Kerberos procesa una petición, efectúa una entrada en la antememoria de reproducción. Si posteriormente procesa una petición que concuerda con una entrada ya existente en la antememoria de reproducción, se devuelve un error al programa de la aplicación. La antememoria de depuración se purga periódicamente para suprimir las peticiones que han expirado.

El protocolo Kerberos soporta estos tipos de antememoria de reproducción: dfl y mem. La antememoria de reproducción dfl se guarda en un archivo y perdura más allá de la conclusión y reinicio de una aplicación. La antememoria de reproducción mem se guarda en la memoria y deja de existir cuando finaliza la aplicación. La antememoria de reproducción no debe compartirse entre procesos, pues el resultado podría ser la aparición de errores de falsa reproducción provocados por diferentes peticiones con la misma indicación de hora.

La tabla de claves

La tabla de claves se utiliza para almacenar claves de cifrado. Normalmente, las aplicaciones de servidor proporcionan las claves de cifrado que utiliza el protocolo Kerberos cuando necesita descifrar una petición. Cada clave tiene un número de versión asociado y cada vez que la clave cambia, se incrementa la versión. Cuando el servidor de protocolo Kerberos cifra un ticket de servicio, utiliza la última clave de cifrado almacenada en la tabla de claves y registra el número de versión de clave en el ticket. A continuación, cuando se presenta el ticket al servidor, se utiliza el número de versión de clave para recuperar la clave apropiada de la tabla de claves. De este modo el servidor puede modificar su clave sin invalidar los tickets existentes.

El protocolo Kerberos soporta estos tipos de antememoria de tablas de claves: FILE y WRFILE. Ambos tipos de tablas de claves se refieren a la misma tabla de claves basada en archivos. La diferencia radica en que una tabla de claves abierta como FILE es de sólo lectura, mientras que una tabla de claves abierta como WRFILE es de lectura/escritura. La tabla de claves puede compartirse con múltiples aplicaciones y procesos.

Etiquetado con:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*