Terminología de Kerberos

La siguiente sección presenta los términos de Kerberos con sus definiciones. Estos términos se utilizan en toda la documentación de Kerberos. Para incorporar los conceptos de Kerberos, resulta esencial comprender estos términos.

Terminología específica de Kerberos

Para administrar los KDC, debe comprender los términos de esta sección.

El Centro de distribución de claves, o KDC, es el componente de Kerberos que se encarga de la emisión de credenciales. Para crear estas credenciales, se utiliza la información que está almacenada en la base de datos del KDC. Cada dominio necesita al menos dos KDC, uno que sea maestro y al menos uno que sea esclavo. Todos los KDC generan credenciales, pero únicamente el KDC maestro realiza los cambios en la base de datos del KDC.

El archivo intermedio la clave maestra para el KDC. Esta clave se utiliza cuando se reinicia un servidor para autenticar el KDC automáticamente antes de iniciar los comandos kadmind y krb5kdc. Como este archivo contiene la clave maestra, el archivo y cualquier copia de seguridad del archivo deben permanecer seguros. El archivo se crea con permisos de sólo lectura para el usuario root. Para mantener el archivo seguro, no cambie los permisos. Si el archivo corre peligro, la clave podría ser utilizada para acceder a la base de datos del KDC o para modificarla.

Terminología específica de la autenticación

Debe conocer los términos de esta sección para comprender el proceso de autenticación. Los programadores y los administradores del sistema deben estar familiarizados con estos términos.

El cliente es el software que se ejecuta en la estación de trabajo del usuario. El software de Kerberos que se ejecuta en el cliente realiza muchas solicitudes durante este proceso. Por lo tanto, es importante establecer la diferencia entre las acciones de este software y el usuario.

Los términos servidor y servicio suelen utilizarse de manera indistinta. El término servidor se utiliza para definir el sistema físico en el que se ejecuta el software de Kerberos. El término servicio corresponde a una determinada función que se admite en un servidor (por ejemplo, ftp o nfs). Con frecuencia, la documentación define los servidores como una parte de un servicio, pero esta definición hace que el significado de los términos sea confuso. Por lo tanto, el término servidor se refiere al sistema físico. El término servicio se refiere al software.

El producto Kerberos usa dos tipos de claves. Un tipo de clave es una clave derivada de contraseña. La clave derivada de contraseña se otorga a cada principal de usuario, y sólo el usuario y el KDC la conocen. El otro tipo de clave que el producto Kerberos utiliza es una clave aleatoria que no está asociada con una contraseña y que, por lo tanto, no es adecuada para que la usen los principales de usuario. Por lo general, las claves aleatorias se usan para los principales de servicio que tienen entradas en un archivo keytab y claves de sesión generadas por el KDC. Los principales de servicio pueden usar claves aleatorias, ya que el servicio puede acceder a la clave que se encuentra en el archivo keytab y entonces puede ejecutarse de manera no interactiva. Las claves de sesión son generadas por el KDC (y compartidas entre el cliente y el servicio) a fin de facilitar las transacciones seguras entre un cliente y un servicio.

El ticket es un paquete de información que se utiliza para transferir la identidad de un usuario a un servidor o servicio de manera segura. Un ticket es válido únicamente para un solo cliente y un servicio determinado en un servidor específico. El ticket contiene:

• Nombre de principal del servicio

• Nombre de principal del usuario

• Dirección IP del host del usuario

• Indicación de hora

• Valor que define la duración del ticket

• Copia de la clave de sesión

Todos estos datos se encuentran cifrados en la clave de servicio del servidor. Tenga en cuenta que el KDC emite el ticket integrado en una credencial, que se describe en el siguiente párrafo. Una vez que se emitió un ticket, éste puede volver a usarse hasta que caduque.

La credencial es un paquete de información que incluye un ticket y una clave de sesión coincidente. La credencial está cifrada con la clave del principal solicitante. Generalmente, el KDC genera una credencial en respuesta a una solicitud de ticket de un cliente.

El autenticador es la información utilizada por el servidor para autenticar el principal del usuario cliente. El autenticador incluye el nombre de principal del usuario, la indicación de hora y otros datos. A diferencia del ticket, el autenticador puede utilizarse sólo una vez; por lo general, cuando se solicita acceso a un servicio. El autenticador se cifra mediante la clave de sesión compartida por el cliente y el servidor. Habitualmente, el cliente crea el autenticador y lo envía con el ticket de un servidor o de un servicio para que se autentique en el servidor o el servicio.

Tipos de tickets

Los tickets tienen propiedades que establecen el modo en que pueden utilizarse. Estas propiedades se asignan al ticket en el momento que éste se crea, pero pueden modificarse más adelante. Por ejemplo, un ticket puede cambiar de forwardable a forwarded. Puede ver las propiedades del ticket con el comando klist. Consulte Visualización de tickets de Kerberos.

Los tickets pueden describirse con uno o más de los siguientes términos:

Reenviable/reenviado

El ticket reenviable puede enviarse de un host a otro, sin la necesidad de que un cliente vuelva a autenticarse. Por ejemplo, si el usuario david obtiene un ticket reenviable cuando está en el equipo del usuario jennifer, puede iniciar sesión en su propio equipo sin obtener un ticket nuevo (ni volver a autenticarse). Consulte el Ejemplo 26-1 para ver un ejemplo de un ticket reenviable.

Inicial

El ticket inicial es un ticket que se emite directamente en lugar de emitirse por medio de un ticket de otorgamiento de tickets. Algunos servicios, como las aplicaciones que cambian las contraseñas, posiblemente requieran que los tickets se marquen como iniciales para garantizar que el cliente pueda demostrar que conoce su clave secreta. El ticket inicial indica que, recientemente, el cliente se ha autenticado por sí mismo, en lugar de recurrir al ticket de otorgamiento de tickets, que quizás haya estado funcionando durante mucho tiempo.

No válido

El ticket no válido es un ticket posfechado que todavía no se puede usar. Un servidor de aplicaciones rechaza un ticket no válido hasta que se valide. Para validar un ticket, el cliente debe presentarlo al KDC en una solicitud de ticket de otorgamiento de tickets, con el indicador VALIDATE definido, después de que haya pasado la hora de inicio.

Posfechable/posfechado

El ticket posfechado no es válido hasta que transcurra un tiempo especificado tras su creación. Un ticket de este tipo es útil, por ejemplo, para los trabajos por lotes que deben ejecutarse tarde por la noche, ya que si el ticket es robado, no se puede utilizar hasta que se ejecute el trabajo por lotes. Los tickets posfechados se emiten como no válidos y siguen teniendo ese estado hasta que haya pasado su hora de inicio, y el cliente solicite la validación por parte del KDC. Generalmente, un ticket posfechado es válido hasta la hora de vencimiento del ticket de otorgamiento de tickets. Sin embargo, si el ticket se marca como renovable, su duración suele definirse para que coincida con la duración total del ticket de otorgamiento de tickets.

Que admite proxy/proxy

A veces, es necesario que un principal permita que un servicio realice una operación en su nombre. El nombre de principal del proxy debe estar especificado cuando se crea el ticket. La versión de Oracle Solaris no es compatible con tickets que admiten proxy ni con tickets proxy.

El ticket que admite proxy es similar al ticket reenviable, excepto en que sólo es válido para un único servicio, mientras que el ticket reenviable otorga al servicio el uso total de la identidad del cliente. Por lo tanto, el ticket reenviable se puede considerar como una especie de superproxy.

Renovable

Debido a que los tickets con duraciones muy largas constituyen un riesgo de seguridad, los tickets se pueden designar como renovables. Un ticket renovable tiene dos horas de vencimiento: la hora de vencimiento de la instancia actual del ticket y la duración máxima de cualquier ticket, que es de una semana. Si un cliente desea seguir utilizando un ticket, debe renovarlo antes del primer vencimiento. Por ejemplo, un ticket puede ser válido por una hora, pero todos los tickets tienen una duración máxima de diez horas. Si el cliente que tiene el ticket desea conservarlo durante más de una hora, debe renovarlo dentro de esa hora. Cuando un ticket alcanza la duración máxima (diez horas), vence automáticamente y no se puede renovar.

Para obtener más información sobre cómo ver los atributos de tickets, consulte Visualización de tickets de Kerberos.

Duración de los tickets

En cualquier momento que un principal obtenga un ticket, incluido un ticket de otorgamiento de tickets (TGT), la duración del ticket se establece como el menor de los siguientes valores de duración:

• El valor de duración que establece la opción -l de kinit, si se usa kinit para obtener el ticket. De manera predeterminada, kinit usó el valor de duración máxima.

• El valor de duración máxima (max_life ) que se encuentra especificado en el archivo kdc.conf.

• El valor de duración máxima que se especifica en la base de datos de Kerberos para el principal de servicio que proporciona el ticket. En el caso de kinit, el principal de servicio es krbtgt/dominio.

• El valor de duración máxima que se especifica en la base de datos de Kerberos para el principal de usuario que solicita el ticket.

La Figura 27-1 muestra cómo se determina la duración de un TGT y de dónde provienen los cuatro valores de duración. Aunque esta figura muestra cómo se determina la duración de un TGT, básicamente, ocurre lo mismo cuando algún principal obtiene un ticket. Las únicas diferencias radican en que kinit no proporciona un valor de duración, y el principal de servicio que otorga el ticket proporciona un valor de duración máxima (en lugar del principal krbtgt/dominio).

Figura 27-1 Cómo se determina la duración de un TGT

La duración del ticket renovable también se determina a partir del mínimo de los cuatro valores, pero en su lugar se utilizan los valores de duración renovables, de la siguiente manera:

• El valor de duración renovable que especifica la opción -r de kinit, si kinit se utiliza para obtener o renovar el ticket.

• El valor de duración máxima renovable (max_renewable_life) que se especifica en el archivo kdc.conf.

• El valor de duración máxima renovable que se especifica en la base de datos de Kerberos para el principal de servicio que proporciona el ticket. En el caso de kinit, el principal de servicio es krbtgt/dominio.

• El valor de duración máxima renovable que se especifica en la base de datos de Kerberos para el principal de usuario que solicita el ticket.

Nombres de principales de Kerberos

Cada ticket se identifica con un nombre de principal. El nombre de principal puede identificar un usuario o un servicio. A continuación se muestran ejemplos de varios nombres de principal.

Tabla 27-4 Ejemplos de nombres de principales de Kerberos