Terminología de SEAM

El apartado siguiente presenta términos que se utilizan a lo largo de la documentación de SEAM y sus definiciones. Para poder seguir muchas de las explicaciones, es esencial comprender estos términos.

Terminología específica de la autenticación

Los términos explicados a continuación son necesarios para comprender el proceso de autenticación. Los programadores y los administradores de sistemas deben estar familiarizados con estos términos.

Un cliente es el software que se ejecuta en la estación de trabajo de un usuario. El software SEAM que se ejecuta en el cliente hace muchas solicitudes durante este proceso y es importante diferencias las acciones de este software de las del usuario.

A menudo, los términos servidor y servicio se utilizan de forma intercambiable. Para aclarar las cosas, el término servidor se utiliza para definir el sistema físico en el que se está ejecutando el software de SEAM. El término servicio corresponde a una función determinada que se admite en un servidor (por ejemplo, ftp o nfs). A menudo, la documentación menciona a los servidores como parte de un servicio, pero el uso de esta definición confunde el significado de los términos; por tanto, los servidores hacen referencia al sistema físico y el servicio hace referencia al software.

El producto SEAM incluye tres tipos de claves. Una de ellas es la clave privada. que se proporciona a todos los principales de usuario y sólo la conocen el usuario del principal y el KDC. Para los principales de usuario, la clave se basa en la contraseña del usuario. Para los servidores y los servicios, la clave se conoce como clave de servicio, que sirve la misma función que la clave privada, pero la utilizan los servidores y los servicios. El tercer tipo de clave es la clave de sesión, que es una clave generada por el servicio de autenticación o el servicio de obtención de cupones. La clave de sesión se genera para proporcionar transacciones seguras entre un cliente y un servicio.

Un cupón es un paquete de información utilizado para pasar la identidad de un usuario a un servidor o un servicio de forma segura. Un cupón sólo es válido para un único cliente y un servicio determinado de un servidor específico. Contiene el nombre de principal del servicio, el nombre de principal del usuario, la dirección IP del sistema del usuario, una marca de tiempo y un valor para definir la vigencia del cupón. Los cupones se crean con una clave de sesión aleatoria para que la utilicen el cliente y el servidor. Después de que se haya creado un cupón, se puede volver a utilizar hasta que caduque.

Una credencial es un paquete de información que incluye un cupón y una clave de sesión concordante. A menudo, las credenciales están encriptadas mediante una clave privada o de servicio, dependiendo de lo que las desencriptará.

Un autenticador es otro tipo de información. Cuando se utiliza con un cupón, se puede utilizar un autenticador para autenticar a un principal de usuario. Los autenticadores incluyen el nombre de principal del usuario, la dirección IP del sistema del usuario y una marca de tiempo. A diferencia de un cupón, un autenticador sólo se puede utilizar una vez, habitualmente cuando se solicita el acceso a un servicio. Los autenticadores están encriptados mediante la clave de sesión para ese cliente y ese servidor.

Tipos de cupones

Los cupones tienen propiedades que regulan su uso, asignadas en el momento de su creación, aunque siempre es posible modificarlas con posterioridad (por ejemplo, un cupón puede cambiar de remitible a remitido.) Puede ver las propiedades de los cupones con el comando klist (véase "Visualización de los cupones").

Uno o varios de los términos siguientes pueden describir los cupones:

remitible/remitido

Los cupones remitibles se pueden enviar de un sistema a otro, lo que evita la necesidad de que un cliente se vuelva a autenticar. Por ejemplo, si el usuario david obtiene un cupón remitible mientras está en la máquina de susana, puede iniciar una sesión en su propia máquina sin tener que obtener un cupón nuevo (y tener que autenticarse de nuevo). Véase "Ejemplo: creación de un cupón" para obtener un ejemplo de un cupón remitible. Compare los cupones remitibles con los delegables, descritos a continuación.

inicial

El cupón inicial es el que se genera directamente, sin estar basado en un cupón de obtención de cupones. Algunos servicios, como las aplicaciones que cambian las contraseñas, pueden requerir que los cupones estén marcados como iniciales para asegurarse de que el cliente pueda demostrar el conocimiento de su clave secreta, ya que los cupones iniciales indican que el cliente se ha autenticado recientemente (en lugar de depender de un cupón de obtención de cupones, de mayor vigencia).

no válido

Los cupones no válidos tienen una fecha futura por lo que todavía no se pueden utilizar (véase fecha futura a continuación). Los servidores de aplicaciones los rechazarán hasta que estén validados. Para ello, el cliente debe presentarlos al KDC en una solicitud de TGS, con el indicador VALIDATE definido, después de que haya pasado su tiempo inicial.

que admite fecha futura/con fecha futura

Los cupones con fecha futura son los que no adquieren validez hasta un tiempo especificado después de su creación. Estos cupones son útiles, por ejemplo, para los trabajos por lotes que están previstos que se ejecuten por la noche, ya que si se robara el cupón no se podría utilizar hasta que se fuera a ejecutar este trabajo. Un cupón con fecha futura, se genera como no válido y permanece así hasta que: haya pasado su hora de inicio y el cliente solicite su validación por parte del KDC (véase no válido, anteriormente). Normalmente, los cupones con fecha futura son válidos hasta la hora de caducidad del cupón de obtención de cupones; no obstante, si están marcados como renovables, normalmente se define su vigencia para que sea igual a la duración de la vida completa del cupón de obtención de cupones. Véase renovable a continuación.

delegable/delegado

A veces, puede ser necesario que un principal permita que un servicio lleve a cabo una operación en su nombre (un ejemplo puede ser cuando un principal solicita que un servicio ejecute un trabajo de impresión en un tercer sistema). El servicio debe poder asumir la identidad del cliente, pero sólo es necesario para esa única operación. En ese caso, se dice que el servidor está actuando como delegado para el cliente. Cuando se crea el cupón, debe especificarse el nombre de principal del delegado.

Los cupones delegables son similares a los remitibles, exceptuando en que sólo son válidos para un único servicio, mientras que los remitibles conceden al servicio el uso completo de la identidad del cliente. Por tanto, puede pensarse que un cupón remitible es un tipo de super-delegado.

renovable

Como tener cupones de vigencia larga es un riesgo de seguridad, pueden designarse los cupones como renovables. Éstos pueden caducar en dos tiempos diferentes: el momento en el que caduca el ejemplar actual del cupón y la vigencia máxima para cualquier cupón. Si un cliente desea seguir utilizando un cupón, lo renueva antes de que se produzca la primera caducidad. por ejemplo, un cupón puede ser válido durante una hora y todos los cupones tienen una vigencia máxima de diez horas. Si el cliente que posee el cupón desea mantenerlo durante más de una hora, debe renovarlo durante esa hora. Cuando un cupón llega a su vigencia máxima (10 horas), caduca automáticamente y no es posible renovarlo.

Para obtener información sobre cómo ver los cupones para conocer sus atributos, véase "Visualización de los cupones".

Vigencia del cupón

Cada vez que un principal obtiene un cupón, incluidos los cupones de obtención de cupones, se define su vigencia como el más pequeño de los valores de vigencia siguientes:

• El valor de vigencia especificado por la opción -l de kinit, si se utiliza kinit para obtener el cupón

• El valor de vigencia máximo (max_life) especificado en el archivo kdc.conf

• El valor de vigencia máximo especificado en la base de datos de Kerberos para el principal de servicio que proporciona el cupón (en el caso de kinit, el principal de servicio es krbtgt/ámbito)

• El valor de vigencia máximo especificado en la base de datos de Kerberos para el principal de usuario que solicita el cupón.

Figura 7-1 muestra cómo se determina la vigencia de un TGT e ilustra de dónde provienen los cuatro valores de vigencia. Aunque Figura 7-1 muestra cómo se determina la vigencia de un TGT, básicamente sucede lo mismo cuando cualquier principal obtiene un cupón. Las únicas diferencias son que kinit no proporciona un valor de vigencia y que el principal de servicio que proporciona el cupón proporciona un valor de vigencia máximo (en lugar del principal krbtgt/ámbito ).

Figura 7-1 Determinación de la vigencia de un TGT

La vigencia de los cupones renovables también está determinada por el mínimo de cuatro valores, pero se utilizan en su lugar los valores de vigencia renovables:

• El valor de vigencia renovable especificado por la opción -r de kinit, si se utiliza kinit para obtener o renovar el cupón

• El valor de vigencia renovable máximo (max_renewable_life) especificado en el archivo kdc.conf

• El valor de vigencia renovable máximo especificado en la base de datos de Kerberos para el principal de servicio que proporciona el cupón (en el caso de kinit, el principal de servicio es krbtgt/ámbito)

• El valor de vigencia renovable máximo especificado en la base de datos de Kerberos para el principal de usuario que solicita el cupón

Nombres de principal

Un nombre de principal identifica todos los cupones. El nombre de principal puede identificar a un usuario o a un servicio. Éstos son ejemplos de varios nombres de principal.

Tabla 7-4 Ejemplos de nombres de principal

Nombre de principal	Descripción
root/puebla.acme.com@ACME.COM	Un principal asociado con la cuenta root en un cliente NFS. Se denomina un principal de root y es necesario para que sean satisfactorios los montajes de NFS autenticados.
host/puebla.acme.com@ACME.COM	Un principal utilizado por las aplicaciones (por ejemplo, klist y kprop) y los servicios (como ftp y telnet) adaptados a Kerberos. Se denomina principal de host o de servicio.
nombre_usuario@ACME.COM	El principal de un usuario
nombre_usuario/admin@ACME.COM	Un principal admin que se puede utilizar para administrar la base de datos del KDC
ftp/puebla.acme.com@ACME.COM	Un principal utilizado por el servicio ftp. Puede utilizarse en lugar de un principal host.
K/M@ACME.COM	El principal de nombre de clave maestra. Cada KDC maestro tiene asociados uno de ellos.
kadmin/history@ACME.COM	Un principal que incluye una clave utilizada para conservar los históricos de contraseña para otros principales. Cada KDC maestro dispone de uno.
kadmin/kdc1.acme.com@ACME.COM	Un principal para el servidor KDC maestro que permite el acceso al KDC mediante kadmind
changepw/kdc1.acme.com@ACME.COM	Un principal para el servidor KDC maestro que permite el acceso al KDC al cambiar las contraseñas
krbtgt/ACME.COM@ACME.COM	Este principal se utiliza al generar un cupón de obtención de cupones.