3.4. The KRB_SAFE Exchange (L'Échange KRB_SAFE)
3.4. L'Échange KRB_SAFE
Le message KRB_SAFE PEUT être utilisé par les clients nécessitant la capacité de détecter les modifications des messages qu'ils échangent. Il y parvient en incluant une somme de contrôle indexée résistante aux collisions des données utilisateur et de certaines informations de contrôle. La somme de contrôle est indexée avec une clé de chiffrement (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).
3.4.1. Génération d'un Message KRB_SAFE
Lorsqu'une application souhaite envoyer un message KRB_SAFE, elle collecte ses données et les informations de contrôle appropriées et calcule une somme de contrôle sur elles. L'algorithme de somme de contrôle devrait être la somme de contrôle indexée mandatée pour être implémentée avec le système cryptographique utilisé pour la clé de sous-session ou de session. La somme de contrôle est générée en utilisant la clé de sous-session, si présente, ou la clé de session. Certaines implémentations utilisent un algorithme de somme de contrôle différent pour les messages KRB_SAFE, mais le faire de manière interopérable n'est pas toujours possible.
Les informations de contrôle pour le message KRB_SAFE incluent à la fois un horodatage et un numéro de séquence. Le concepteur d'une application utilisant le message KRB_SAFE DOIT choisir au moins l'un des deux mécanismes. Ce choix DEVRAIT être basé sur les besoins du protocole d'application.
Les numéros de séquence sont utiles lorsque tous les messages envoyés seront reçus par son pair. L'état de connexion est actuellement requis pour maintenir la clé de session, donc maintenir le prochain numéro de séquence ne devrait pas présenter de problème supplémentaire.
Si le protocole d'application est censé tolérer les messages perdus sans qu'ils soient renvoyés, l'utilisation de l'horodatage est le mécanisme de détection de rejeu approprié. L'utilisation d'horodatages est également le mécanisme approprié pour les protocoles multi-diffusion dans lesquels tous les pairs partagent une clé de sous-session commune, mais certains messages seront envoyés à un sous-ensemble des pairs.
Après avoir calculé la somme de contrôle, le client transmet ensuite les informations et la somme de contrôle au destinataire dans le format de message spécifié dans la Section 5.6.1.
3.4.2. Réception du Message KRB_SAFE
Lorsqu'une application reçoit un message KRB_SAFE, elle le vérifie comme suit. Si une erreur se produit, un code d'erreur est signalé pour utilisation par l'application.
Le message est d'abord vérifié en vérifiant que les champs de version du protocole et de type correspondent respectivement à la version actuelle et à KRB_SAFE. Une non-correspondance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application vérifie que la somme de contrôle utilisée est une somme de contrôle indexée résistante aux collisions qui utilise des clés compatibles avec la clé de sous-session ou de session appropriée (ou avec la clé d'application dérivée des clés de session ou de sous-session). Si ce n'est pas le cas, une erreur KRB_AP_ERR_INAPP_CKSUM est générée. L'adresse de l'expéditeur DOIT être incluse dans les informations de contrôle; le destinataire vérifie 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 (si une adresse de destinataire est spécifiée ou si le destinataire nécessite une adresse) qu'une des adresses du destinataire apparaît comme l'adresse du destinataire dans le message. Pour fonctionner avec la traduction d'adresses réseau, les expéditeurs PEUVENT utiliser le type d'adresse directionnelle spécifié dans la Section 8.1 pour l'adresse de l'expéditeur et ne pas inclure d'adresses de destinataire. Une correspondance échouée pour l'un ou l'autre cas génère une erreur KRB_AP_ERR_BADADDR. Ensuite, les champs d'horodatage et usec et/ou de numéro de séquence sont vérifiés. Si l'horodatage et usec sont attendus et non présents, ou s'ils sont présents mais pas actuels, l'erreur KRB_AP_ERR_SKEW est générée. Les horodatages ne sont pas tenus d'être strictement ordonnés; ils sont seulement tenus d'être dans la fenêtre de décalage. Si le nom du serveur, avec le nom du client, les champs d'heure et de microsecondes de l'Authenticator correspondent à des tuples récemment vus (envoyés ou reçus), l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais non présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un horodatage et usec ni un numéro de séquence n'est présent, une erreur KRB_AP_ERR_MODIFIED est générée. Enfin, la somme de contrôle est calculée sur les données et les informations de contrôle, et si elle ne correspond pas à la somme de contrôle reçue, une erreur KRB_AP_ERR_MODIFIED est générée.
Si toutes les vérifications réussissent, l'application est assurée que le message a été généré par son pair et n'a pas été modifié en transit.
Les implémentations DEVRAIENT accepter tout algorithme de somme de contrôle qu'elles implémentent qui a à la fois une sécurité adéquate et des clés compatibles avec la clé de sous-session ou de session. Les sommes de contrôle non indexées ou non résistantes aux collisions ne conviennent pas à cette utilisation.