Les types de chiffrement identifient les algorithmes cryptographiques et le mode à utiliser lors d'opérations cryptographiques. Pour obtenir une liste des types de chiffrement pris en charge, reportez-vous aux pages de manuel krb5.conf(4) et kdb5_util(1M).
Lorsqu'un client demande un ticket au KDC, le KDC doit utiliser des clés dont le type de chiffrement est compatible à la fois avec le client et le serveur. Le protocole Kerberos permette au client de demander à ce que le KDC utilise certains types de chiffrement pour la partie de réponse du ticket du client. Le protocole n'autorise pas le serveur à spécifier des types de chiffrement au KDC.
Tenez compte des points suivants avant de modifier les types de chiffrement, procédez comme suit :
Le KDC suppose que le premier type de clé/chiffrement associé à l'entrée du principal du serveur dans la base de données du principal est pris en charge par le serveur.
Sur le KDC, vous devez vous assurer que les clés qui sont générées pour le principal sont compatibles avec les systèmes afin d'authentifier l'identité utilisateur (principal). Par défaut, la commande kadmin crée des clés pour tous les types de chiffrement pris en charge. Si les systèmes sur lesquels le principal est utilisé ne prennent pas en charge cette configuration par défaut des types de chiffrement, vous devez restreindre les types de chiffrement lors de la création d'un principal. Les deux méthodes recommandées de limitation des types de chiffrement sont l'utilisation de l'indicateur –e dans kadmin addprinc ou la définition du paramètre supported_enctypes dans le fichier kdc.conf à ce sous-ensemble. Utilisez le paramètre supported_enctypes parameter lorsque la plupart des systèmes d'un domaine Kerberos prennent en charge un sous-ensemble de l'ensemble par défaut des types de chiffrement. Le paramètre supported_enctypes spécifie l'ensemble par défaut des types de chiffrement kadmin addprinc utilisés lorsqu'il crée un principal pour un domaine particulier.
Au moment de déterminer les types de chiffrement pris en charge par un système, pensez à la fois à la version de Kerberos exécutée sur le système et aux algorithmes cryptographiques pris en charge par l'application du serveur pour lequel un principal de serveur est en cours de création. Par exemple, lors de la création d'un principal de service nfs/hostname, il est conseillé de limiter les types de chiffrement aux types pris en charge par le serveur NFS de l'hôte.
Le paramètre master_key_enctype dans le fichier kdc.conf peut être utilisé pour contrôler le type de chiffrement de la clé principale qui chiffre les entrées dans la base de données du principal. N'utilisez pas ce paramètre si la base de données du principal KDC a déjà été créée. Le paramètre master_key_enctype peut être utilisé au moment de la création de la base de données afin de faire passer le type de chiffrement de la clé principale par défaut de aes256-cts-hmac-sha1-96 à un type de chiffrement différent. Assurez-vous que tous les KDC esclaves prennent en charge le type de chiffrement choisi et qu'ils ont la même entrée master_key_enctype dans leur fichier kdc.conf lors de la configuration des KDC esclaves. Assurez-vous également que le paramètre master_key_enctype est défini sur l'un des types de chiffrement dans supported_enctypes, si supported_enctypes est défini dans kdc.conf. Si l'une ou l'autre de ces situations n'est pas gérée correctement, le KDC maître peut ne pas être en mesure de travailler avec les KDC esclaves.
Sur le client, vous pouvez contrôler les requêtes de type de chiffrement à partir du KDC à l'aide des paramètres dans le fichier krb5.conf. Le paramètre default_tkt_enctypes spécifie les types de chiffrement que le client est disposé à utiliser lorsqu'il demande un ticket d'octroi de tickets (TGT) au KDC. Le TGT est utilisé par le client pour acquérir d'autres tickets de serveur d'une manière plus efficace. L'effet du paramètre default_tkt_enctypes est de donner au client un contrôle sur les types de chiffrement utilisés pour protéger les communications entre le client et le KDC, lorsque le client demande un ticket de serveur via TGT (aussi appelé demande TGS). Notez que les types de chiffrement spécifiés dans default_tkt_enctypes doivent correspondre à au moins un des types de chiffrement de clé principal dans la base de données du principal stockée sur le KDC. Dans le cas contraire, la demande TGS échoue. Dans la plupart des cas, vous ne devez pas définir default_tkt_enctypes car ce paramètre peut être une source de problèmes d'interopérabilité. Par défaut, le code client demande tous les types de chiffrement pris en charge et le KDC choisit les types de chiffrement en fonction des clés que le KDC trouve dans la base de données du principal.
Le paramètre default_tgs_enctypes restreint les types de chiffrement demandés par le client dans ses demandes TGS, qui sont utilisées pour l'acquisition de tickets de serveur. Ce paramètre restreint également les types de chiffrement utilisés par le KDC lors de la création de la clé de session partagée par le client et le serveur. Par exemple, si un client souhaite utiliser uniquement le chiffrement 3DES pour un NFS sécurisé, vous devez définir default_tgs_enctypes = des3-cbc-sha1. Assurez-vous que les principaux du client et du serveur ont une clé des-3-cbc-sha1 dans la base de données du principal. Comme avec default_tkt_enctype, vous ne devez pas, dans la plupart des cas, définir ce paramètre, car il peut provoquer des problèmes d'interopérabilité si les informations d'identification ne sont pas configurées correctement sur le KDC et le serveur.
Sur le serveur, vous pouvez contrôler les types de chiffrement qu'il accepte avec le paramètre permitted_enctypes dans le fichier kdc.conf. De plus, vous pouvez spécifier les types de chiffrement utilisés lors de la création d'entrées keytab. Evitez d'utiliser l'une de ces méthodes pour contrôler les types de chiffrement et laisser plutôt le KDC déterminer les types de chiffrement à utiliser, car le KDC ne communique pas avec l'application de serveur pour déterminer la clé ou le type de chiffrement à utiliser.