Uso de los tipos de cifrado de Kerberos

Los tipos de cifrado identifican los algoritmos criptográficos y el modo en que se deben usar cuando se realizan las operaciones criptográficas. Los tipos de cifrado aes, des3-cbc-sha1 y rc4–hmac permiten la creación de claves que se pueden utilizar para las operaciones criptográficas más resistentes. Estas operaciones más resistentes mejoran la seguridad general del servicio Kerberos.

Cuando un cliente solicita un ticket del KDC, el KDC debe usar claves cuyo tipo de cifrado sea compatible tanto con el cliente como con el servidor. Mientras que el protocolo Kerberos permite al cliente solicitar que el KDC utilice determinados tipos de cifrado para la parte del cliente de la respuesta de ticket, el protocolo no permite que el servidor especifique tipos de cifrado para el KDC.

A continuación se enumeran algunos de los problemas que deben tenerse en cuenta antes de cambiar los tipos de cifrado.

• El KDC supone que el servidor admite el primer conjunto de claves y tipos de cifrado asociados a la entrada del principal de servidor en la base de datos del principal.

• En el KDC, debe asegurarse de que las claves generadas para el principal sean compatibles con los sistemas en los que se autenticará el principal. De manera predeterminada, el comando kadmin crea claves para todos los tipos de cifrado admitidos. Si los sistemas en los que se utiliza el principal no admiten este conjunto de tipos de cifrado predeterminado, debe restringir los tipos de cifrado cuando crea un principal. Puede restringir los tipos de cifrado mediante el uso del indicador -e en kadmin addprinc o la definición del parámetro supported_enctypes en el archivo kdc.conf de este subconjunto. El parámetro supported_enctypes debe utilizarse cuando la mayoría de los sistemas de un dominio Kerberos admiten un subconjunto del conjunto predeterminado de tipos de cifrado. Al definir supported_enctypes, se especifica el conjunto predeterminado de tipos de cifrado que kadmin addprinc utiliza cuando crea un principal para un dominio en particular. Como regla general, es mejor controlar los tipos de cifrado utilizados por Kerberos con alguno de estos dos métodos.

• Cuando vaya a determinar los tipos de cifrado que admite un sistema, tenga en cuenta la versión de Kerberos que se ejecuta en el sistema y los algoritmos criptográficos que admite la aplicación de servidor para la que se crea un principal de servidor. Por ejemplo, cuando se crea un principal de servicio nfs/hostname, debe restringir los tipos de cifrado para los tipos que admite el servidor NFS en ese host. Tenga en cuenta que, en la versión Solaris 10, el servidor NFS también admite todos los tipos de cifrado de Kerberos.

• El parámetro master_key_enctype del archivo kdc.conf se puede utilizar para controlar el tipo de cifrado de la clave maestra que cifra las entradas de la base de datos del principal. No utilice este parámetro si la base de datos del principal del KDC ya se ha creado. El parámetro master_key_enctype se puede usar en el momento de la creación de la base de datos para cambiar el tipo de cifrado predeterminado para la clave maestra, de des-cbc-crc a un tipo de cifrado más resistente. Cuando configure los KDC esclavos, asegúrese de que todos admitan el tipo de cifrado seleccionado y tengan una entrada master_key_enctype idéntica en su archivo kdc.conf. Asimismo, asegúrese de que master_key_enctype se encuentre definido en uno de los tipos de cifrado en supported_enctypes si supported_enctypes está definido en kdc.conf. Si alguno de estos problemas no se trata adecuadamente, es posible que el KDC maestro no pueda trabajar con los KDC esclavos.

• En el cliente, puede controlar qué tipos de cifrado el cliente solicita cuando obtiene los tickets procedentes del KDC mediante algunos parámetros de krb5.conf. El parámetro default_tkt_enctypes especifica los tipos de cifrado que el cliente está dispuesto a utilizar cuando el cliente solicita un ticket de otorgamiento de tickets (TGT) desde el KDC. El cliente utiliza el TGT para adquirir otros tickets del servidor con más eficacia. Se define default_tkt_enctypes a fin de otorgarle al cliente un poco de control sobre los tipos de cifrado que se utilizan para proteger la comunicación entre el cliente y el KDC cuando el cliente solicita un ticket de servidor con el TGT (esto se llama solicitud TGS). Tenga en cuenta que los tipos de cifrado especificados en default_tkt_enctypes deben coincidir, al menos, con uno de los tipos de cifrado de la clave de principal en la base de datos del principal que se almacena en el KDC. De lo contrario, la solicitud TGT fallará. En la mayoría de las situaciones, es mejor no definir default_tkt_enctypes, porque este parámetro puede generar problemas de interoperabilidad. De manera predeterminada, el código de cliente pide que todos los tipos de cifrado admitidos y el KDC seleccionen los tipos de cifrado en función de las claves que el KDC encuentre en la base de datos del principal.

• El parámetro default_tgs_enctypes restringe los tipos de cifrado que el cliente solicita en sus solicitudes TGS, que se utilizan para adquirir tickets de servidor. Este parámetro también restringe los tipos de cifrado que el KDC utiliza cuando crea la clave de sesión que el cliente y el servidor comparten. Por ejemplo, si un cliente quiere usar solamente el cifrado 3DES cuando emplea NFS seguro, debe definir default_tgs_enctypes = des3-cbc-sha1. Asegúrese de que los principales de servidor y de cliente tengan una clave des-3-cbc-sha1 en la base de datos del principal. Al igual que con default_tkt_enctype, probablemente sea mejor, en la mayoría de los casos, no establecer esto, ya que puede provocar problemas de interoperabilidad si las credenciales no están configuradas correctamente en el KDC o en el servidor.

• En el servidor, puede controlar los tipos de cifrado aceptados por el servidor con permitted_enctypes en kdc.conf. Además, puede especificar los tipos de cifrado utilizados en la creación de entradas keytab. Por lo general, es mejor no utilizar ninguno de estos métodos para controlar los tipos de cifrado y, en su lugar, dejar que el KDC determine los tipos de cifrado que se usarán, porque el KDC no se comunica con la aplicación del servidor para determinar qué clave o tipo de cifrado se usarán.