3.5. The KRB_PRIV Exchange (L'Échange KRB_PRIV)
3.5. L'Échange KRB_PRIV
Le message KRB_PRIV PEUT être utilisé par les clients nécessitant la confidentialité et la capacité de détecter les modifications des messages échangés. Il y parvient en chiffrant les messages et en ajoutant des informations de contrôle.
3.5.1. Génération d'un Message KRB_PRIV
Lorsqu'une application souhaite envoyer un message KRB_PRIV, elle collecte ses données et les informations de contrôle appropriées (spécifiées dans la Section 5.7.1) et les chiffre sous 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). Dans le cadre des informations de contrôle, le client DOIT choisir d'utiliser soit un horodatage soit un numéro de séquence (ou les deux); voir la discussion dans la Section 3.4.1 pour des directives sur lequel utiliser. Après que les données utilisateur et les informations de contrôle sont chiffrées, le client transmet le texte chiffré et certaines informations 'd'enveloppe' au destinataire.
3.5.2. Réception du Message KRB_PRIV
Lorsqu'une application reçoit un message KRB_PRIV, 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_PRIV. 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.
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. Si une adresse de destinataire est spécifiée ou si le destinataire nécessite une adresse, alors une des adresses du destinataire DOIT également apparaître comme l'adresse du destinataire dans le message. Lorsque l'adresse d'un expéditeur ou d'un destinataire pourrait autrement ne pas correspondre à l'adresse dans un message en raison de la traduction d'adresses réseau, une application PEUT être écrite pour utiliser des adresses du type d'adresse directionnelle à la place de l'adresse réseau réelle.
Une correspondance échouée pour l'un ou l'autre cas génère une erreur KRB_AP_ERR_BADADDR. Pour fonctionner avec la traduction d'adresses réseau, les implémentations PEUVENT utiliser le type d'adresse directionnelle défini dans la Section 7.1 pour l'adresse de l'expéditeur et n'inclure aucune adresse de destinataire.
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. 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, 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.
Si toutes les vérifications réussissent, l'application peut supposer que le message a été généré par son pair et a été transmis de manière sécurisée (sans que des intrus voient le contenu non chiffré).