Résumé

  • Dans RFC 1964, le checksum spécial de l’authentificateur transporte l’empreinte des liaisons fournies par l’appelant, les services demandés et disponibles, puis éventuellement un KRB_CRED contenant un TGT transférable.
  • Un champ de liaison nul n’identifie aucun canal, un KRB_AP_REQ unilatéral ne confirme pas le serveur, et ni la délégation ni les jetons MIC/Wrap ne prouvent à eux seuls une autorisation ou une acceptation métier.

On pourrait lire une capture Kerberos comme un passeport couvert de tampons. L’OID semble nommer l’autorité, TOK_ID semble classer l’acte, les drapeaux semblent certifier les pouvoirs et KRB_CRED ressemble à une procuration. RFC 1964 propose une lecture plus rigoureuse : ces champs servent à l’interopérabilité, non à fabriquer un verdict universel.

Publié en juin 1996, le texte place le mécanisme Kerberos V5 sous l’OID 1.2.840.113554.1.2.2. Le premier jeton de contexte contient KRB_AP_REQ précédé de 01 00. KRB_AP_REP porte 02 00, KRB_ERROR 03 00. Les jetons par message disposent de leurs propres identifiants. Le bénéfice est immédiat pour un parseur : il sait quelle structure attendre. Mais l’étiquette n’authentifie pas le contenu et ne relie pas automatiquement le message à la bonne session.

L’empreinte dépend d’une décision prise avant le mécanisme

Le checksum 0x8003 de l’authentificateur commence par une longueur de 16 octets, puis par MD5 des composantes non nulles de la structure de liaison de canal. RFC 1964 précise l’ordre little-endian des entiers et l’inclusion des longueurs. Lorsque l’appelant passe GSS_C_NO_BINDINGS, la valeur Bnd devient seize octets à zéro.

Ce cas n’est pas une empreinte générique du transport. Il dit que l’application n’a fourni aucune liaison. Le mécanisme ne choisit pas seul si l’adresse, un secret TLS ou une autre propriété représente le canal. Les travaux ultérieurs sur les liaisons ont rappelé que les applications doivent s’accorder au préalable sur leur usage. Un contrôle peut comparer deux entrées ; il ne peut pas suppléer leur absence.

Les quatre octets suivants composent un vecteur de services. Délégation, mutualité, détection de rejeu et séquençage sont l’intersection entre la demande de l’initiateur et ce que l’implémentation rend disponible. Confidentialité et intégrité signalent la disponibilité des protections par message. Le choix lexical est important : disponible n’est pas consommé, demandé n’est pas accompli.

La mutualité se voit dans le trajet retour

Sans mutual_req, la séquence est unilatérale. La cible ne renvoie aucun jeton de confirmation au KRB_AP_REQ. Il peut exister une authentification utile de l’initiateur vers la cible, mais l’initiateur ne possède pas la confirmation de la cible.

Si l’application exige cette confirmation, elle demande l’authentification mutuelle. Le bit mutual-required est posé dans les options KRB_AP_REQ et le drapeau correspondant apparaît dans le checksum. La cible répond alors par KRB_AP_REP ou KRB_ERROR. Ces deux retours terminent le dialogue, mais un seul signale la réussite. Un audit doit donc conserver le sens, le type et la validation du retour, plutôt que la simple présence d’un paquet en sens inverse.

Même un KRB_AP_REP valide ne signe pas le résultat d’une opération applicative. Il clôt l’établissement mutuel du contexte. L’autorisation d’une commande et sa persistance arrivent plus tard, dans d’autres journaux.

KRB_CRED ouvre une possibilité

La délégation allonge le checksum : option 1, longueur, puis message KRB_CRED. RFC 1964 exige, dans ce cas, un TGT avec l’attribut FORWARDABLE. Le destinataire peut ainsi disposer d’un moyen de demander d’autres tickets.

Le verbe « peut » protège l’analyse. Il faut encore déchiffrer et accepter KRB_CRED, stocker la crédentiale, vérifier sa durée, joindre le bon KDC, demander un ticket de service et passer la politique d’autorisation de ce service. Le transfert n’est ni la preuve d’une utilisation ni une décision d’accès. Confondre ces plans transformerait une capacité transportée en résultat imaginaire.

MIC et Wrap tiennent un registre différent

MIC (01 01) authentifie l’intégrité de données séparées. Wrap (02 01) enveloppe les données avec intégrité et, selon le choix, chiffrement. Les champs de séquence incorporent aussi la direction. Pourtant, les services de rejeu et d’ordre restent optionnels et peuvent être désactivés à la demande de l’appelant.

Une MIC vérifiée atteste une relation cryptographique entre les octets et le contexte. Un Wrap correctement ouvert atteste le traitement de la protection. Le logiciel métier doit encore interpréter le message, vérifier les droits et effectuer l’action. Le dernier contrôle cryptographique n’est pas le premier accusé de réception métier.

RFC 4121 a modernisé le mécanisme et RFC 6649 a déprécié des algorithmes faibles de cette époque. Ces changements interdisent de présenter la cryptographie de 1996 comme une recommandation actuelle. Ils laissent intacte une leçon d’architecture : une norme minimale nomme les transitions communes ; les participants qui exécutent le code conservent les décisions locales. C’est ici que la primauté du code en fonctionnement, utilisée comme grille éditoriale, empêche un symbole de revendiquer plus que son effet observable.

Sources