3.6. The KRB_CRED Exchange (L'Échange KRB_CRED)
3.6. L'Échange KRB_CRED
Le message KRB_CRED PEUT être utilisé par les clients nécessitant la capacité d'envoyer des identifiants Kerberos d'un hôte à un autre. Il y parvient en envoyant les tickets avec des données chiffrées contenant les clés de session et d'autres informations associées aux tickets.
3.6.1. Génération d'un Message KRB_CRED
Lorsqu'une application souhaite envoyer un message KRB_CRED, elle obtient d'abord (en utilisant l'échange KRB_TGS) des identifiants à envoyer à l'hôte distant. Elle construit ensuite un message KRB_CRED en utilisant le ticket ou les tickets ainsi obtenus, en plaçant la clé de session nécessaire pour utiliser chaque ticket dans le champ key de la séquence KrbCredInfo correspondante de la partie chiffrée du message KRB_CRED.
D'autres informations associées à chaque ticket et obtenues pendant l'échange KRB_TGS sont également placées dans la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRED. L'heure actuelle et, si elles sont spécifiquement requises par l'application, les champs nonce, s-address et r-address sont placés dans la partie chiffrée du message KRB_CRED, qui est ensuite chiffrée sous une clé de chiffrement précédemment échangée dans l'échange KRB_AP (généralement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'a eu lieu).
Note d'implémentation: Lors de la construction d'un message KRB_CRED pour inclusion dans un jeton de contexte initial GSSAPI, l'implémentation MIT de Kerberos ne chiffrera pas le message KRB_CRED si la clé de session est une clé DES ou triple DES. Pour l'interopérabilité avec MIT, l'implémentation Microsoft ne chiffrera pas le KRB_CRED dans un jeton GSSAPI si elle utilise une clé de session DES. À partir de la version 1.2.5, MIT Kerberos peut recevoir et décoder soit des jetons KRB_CRED chiffrés soit non chiffrés dans l'échange GSSAPI. L'implémentation Heimdal de Kerberos peut également accepter soit des messages KRB_CRED chiffrés soit non chiffrés. Puisque le message KRB_CRED dans un jeton GSSAPI est chiffré dans l'authentificateur, le comportement de MIT ne présente pas de problème de sécurité, bien qu'il s'agisse d'une violation de la spécification Kerberos.
3.6.2. Réception du Message KRB_CRED
Lorsqu'une application reçoit un message KRB_CRED, elle le vérifie. Si une erreur se produit, un code d'erreur est signalé pour utilisation par l'application. Le message est vérifié en vérifiant que les champs de version du protocole et de type correspondent respectivement à la version actuelle et à KRB_CRED. Une non-correspondance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre ensuite le texte chiffré et traite le texte en clair résultant. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.
Si présent ou requis, le destinataire PEUT vérifier que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et qu'une des adresses du destinataire apparaît comme l'adresse du destinataire dans le message. La vérification d'adresse ne fournit aucune sécurité supplémentaire, car l'adresse, si présente, a déjà été vérifiée dans le message KRB_AP_REQ et il n'y a aucun avantage à gagner par un attaquant en réfléchissant un message KRB_CRED vers son expéditeur. Ainsi, le destinataire PEUT ignorer l'adresse même si elle est présente afin de mieux fonctionner dans les environnements de traduction d'adresses réseau (NAT, Network Address Translation). Une correspondance échouée pour l'un ou l'autre cas génère une erreur KRB_AP_ERR_BADADDR. Les destinataires PEUVENT sauter la vérification d'adresse, car le message KRB_CRED ne peut généralement pas être réfléchi vers l'expéditeur. Les champs d'horodatage et usec (et le champ nonce, si requis) sont vérifiés ensuite. Si l'horodatage et usec ne sont pas présents, ou s'ils sont présents mais pas actuels, l'erreur KRB_AP_ERR_SKEW est générée.
Si toutes les vérifications réussissent, l'application stocke chacun des nouveaux tickets dans son cache d'identifiants avec la clé de session et d'autres informations dans la séquence KrbCredInfo correspondante de la partie chiffrée du message KRB_CRED.