4. Encryption and Checksum Specifications (Spécifications du Chiffrement et des Sommes de Contrôle)
4. Spécifications du Chiffrement et des Sommes de Contrôle
Les protocoles Kerberos décrits dans ce document sont conçus pour chiffrer des messages de tailles arbitraires, en utilisant des chiffrements de flux ou de bloc. Le chiffrement est utilisé pour prouver les identités des entités réseau participant aux échanges de messages. Le Centre de Distribution de Clés pour chaque domaine est considéré par tous les principaux enregistrés dans ce domaine comme fiable pour stocker une clé secrète en toute confidentialité. La preuve de la connaissance de cette clé secrète est utilisée pour vérifier l'authenticité d'un principal.
Le KDC utilise la clé secrète du principal (dans l'échange AS) ou une clé de session partagée (dans l'échange TGS) pour chiffrer les réponses aux demandes de tickets; la capacité d'obtenir la clé secrète ou la clé de session implique la connaissance des clés appropriées et l'identité du KDC. La capacité d'un principal à déchiffrer la réponse KDC et à présenter un Ticket et un Authenticator correctement formé (généré avec la clé de session de la réponse KDC) à un service vérifie l'identité du principal; de même, la capacité du service à extraire la clé de session du Ticket et à prouver sa connaissance de celle-ci dans une réponse vérifie l'identité du service.
Le [RFC3961] définit un cadre pour définir des mécanismes de chiffrement et de somme de contrôle à utiliser avec Kerberos. Il définit également plusieurs de ces mécanismes, et d'autres peuvent être ajoutés dans de futures mises à jour de ce document.
L'opération chaîne-vers-clé (string-to-key) fournie par [RFC3961] est utilisée pour produire une clé à long terme pour un principal (généralement pour un utilisateur). La chaîne de sel par défaut, si aucune n'est fournie via des données de pré-authentification, est la concaténation du domaine du principal et des composants de nom, dans l'ordre, sans séparateurs. Sauf indication contraire, l'ensemble de paramètres opaques chaîne-vers-clé par défaut tel que défini dans [RFC3961] est utilisé.
Les données chiffrées, les clés et les sommes de contrôle sont transmises en utilisant les objets de données EncryptedData, EncryptionKey et Checksum définis dans la Section 5.2.9. Les opérations de chiffrement, de déchiffrement et de somme de contrôle décrites dans ce document utilisent les opérations de chiffrement, de déchiffrement et get_mic correspondantes décrites dans [RFC3961], avec la génération de "clé spécifique" implicite en utilisant les valeurs "d'utilisation de clé" (key usage) spécifiées dans la description de chaque objet EncryptedData ou Checksum pour varier la clé pour chaque opération. Notez que dans certains cas, la valeur à utiliser dépend de la méthode de choix de la clé ou du contexte du message.
Les utilisations de clé sont des entiers non signés de 32 bits; zéro n'est pas autorisé. Les valeurs d'utilisation de clé pour chiffrer ou calculer la somme de contrôle des messages Kerberos sont indiquées dans la Section 5 avec les définitions de messages. Les valeurs d'utilisation de clé 512-1023 sont réservées pour des utilisations internes à une implémentation Kerberos. (Par exemple, ensemencer un générateur de nombres pseudo-aléatoires avec une valeur produite en chiffrant quelque chose avec une clé de session et une valeur d'utilisation de clé non utilisée à d'autres fins.) Les valeurs d'utilisation de clé entre 1024 et 2047 (inclus) sont réservées pour l'utilisation d'applications; les applications DEVRAIENT utiliser des valeurs paires pour le chiffrement et des valeurs impaires pour les sommes de contrôle dans cette plage. Les valeurs d'utilisation de clé sont également résumées dans un tableau dans la Section 7.5.1.
Il peut exister d'autres documents qui définissent des protocoles en termes des types de chiffrement ou types de somme de contrôle du RFC 1510. Ces documents ne sauraient rien des utilisations de clé. Afin que ces spécifications continuent d'avoir un sens jusqu'à ce qu'elles soient mises à jour, si aucune valeur d'utilisation de clé n'est spécifiée, alors les utilisations de clé 1024 et 1025 doivent être utilisées pour dériver les clés pour le chiffrement et les sommes de contrôle, respectivement. (Cela ne s'applique pas aux protocoles qui font leur propre chiffrement indépendamment de ce cadre, en utilisant directement la clé résultant de l'échange d'authentification Kerberos.) Les nouveaux protocoles définis en termes des types de chiffrement et de somme de contrôle Kerberos DEVRAIENT utiliser leurs propres valeurs d'utilisation de clé.
Sauf indication contraire, aucun chaînage d'état de chiffrement n'est effectué d'une opération de chiffrement à une autre.
Note d'implémentation: Bien que cela ne soit pas recommandé, certains protocoles d'application continueront à utiliser les données de clé directement, même si c'est seulement dans les spécifications de protocole actuellement existantes. Une implémentation destinée à prendre en charge les applications Kerberos générales peut donc avoir besoin de rendre les données de clé disponibles, ainsi que les attributs et opérations décrits dans [RFC3961]. L'une des raisons les plus courantes pour effectuer directement le chiffrement est le contrôle direct sur la négociation et la sélection d'un algorithme de chiffrement "suffisamment fort" (dans le contexte d'une application donnée). Bien que Kerberos ne fournisse pas directement de facilité pour négocier les types de chiffrement entre le client d'application et le serveur, il existe des approches pour utiliser Kerberos afin de faciliter cette négociation. Par exemple, un client peut demander uniquement des types de clés de session "suffisamment forts" au KDC et s'attendre à ce que tout type retourné par le KDC soit compris et pris en charge par le serveur d'application.