Résumé

  • RFC 3961 a séparé la clé de protocole de la clé propre à une opération et a rendu obligatoire un numéro d’usage non nul pour contextualiser chiffrement et somme de contrôle.
  • Le profil simplifié dérivait Kc, Ke et Ki pour trois fonctions distinctes ; leur succès attestait un contexte cryptographique, pas la permission d’exécuter l’action suivante.

Le registre peut dire qu’un type de chiffrement existe. Une bibliothèque peut dire qu’elle le connaît. Un client peut l’offrir. Un serveur peut le choisir. Aucune de ces phrases n’est synonyme de la suivante. L’histoire de RFC 3961 commence précisément par ce refus de laisser un nom d’algorithme tenir lieu de preuve complète.

Publié en février 2005, le texte a extrait de Kerberos V5 une couche d’abstraction pour le chiffrement et les sommes de contrôle. Un profil complet devait fixer le format de clé, la conversion d’une chaîne ou d’un aléa en clé, la dérivation, l’état du chiffre, le chiffrement, la vérification d’intégrité et la fonction pseudo-aléatoire. Le numéro etype identifiait ce contrat ; il n’en remplaçait aucune partie.

Cette architecture prolongeait des matériaux de RFC 1510, ensuite remplacé par RFC 4120 pour le protocole Kerberos V5. Elle permettait au protocole de parler d’une clé de base et d’un usage, tout en laissant la représentation de la clé spécifique opaque. Le mécanisme pouvait changer sans que chaque application ne réinvente ses propres hypothèses sur les IV, le bourrage ou les MAC.

Le numéro décrivait le travail, pas le titulaire

RFC 3961 partait d’un constat : employer une même clé à plusieurs fins élargit les attaques par texte clair choisi. Les opérations Kerberos devaient donc recevoir un entier non signé de 32 bits, différent de zéro. La spécification consommatrice attribuait la valeur ; le profil cryptographique l’utilisait pour dériver le matériau propre à cette opération.

Dans le profil simplifié, les quatre octets du numéro étaient suivis de 0x99, 0xAA ou 0x55. Ces constantes produisaient respectivement Kc pour une somme de contrôle autonome, Ke pour chiffrer et Ki pour vérifier l’intégrité du message chiffré. La clé de base ne devait servir qu’à la dérivation. Ainsi, compromettre une clé dérivée ne devait pas donner les deux autres.

Le bénéfice historique apparaît dans les considérations de sécurité. Certains logiciels partageaient des clés entre Kerberos v4 et v5. Le comportement de chiffrement de v4 pouvait alors devenir un oracle contre v5. Le brouillage aléatoire réduisait la prévisibilité ; la séparation par usage empêchait surtout qu’une seule capacité cryptographique reste valable dans tous les contextes. Le RFC décrit une possibilité d’attaque, pas un incident nommé ni une fréquence mesurée.

« Vérifié » restait un reçu local

La fonction de déchiffrement devait contrôler l’intégrité et jeter le message en cas d’échec. En cas de réussite, elle prouvait la cohérence entre le texte chiffré, la clé dérivée, le numéro d’usage et le tag. Elle ne prouvait pas, à elle seule, quel principal possédait légitimement la clé de base, si l’application avait choisi le bon numéro, si le message était frais, si le ticket était encore acceptable ni si l’action demandée était autorisée.

RFC 6113 a ensuite réutilisé le cadre pour la préauthentification généralisée. Cette réutilisation confirme la portée de l’interface, mais ne fusionne pas préauthentification, émission du ticket et décision de l’application. Une trace exploitable doit donc joindre le type de message, l’etype offert et choisi, une référence non secrète à la version de clé, le numéro d’usage et sa clause normative, le condensat de l’objet, la version de bibliothèque, le résultat d’intégrité, les contrôles de fraîcheur et de rejeu, puis l’autorisation et l’effet observé.

Le vocabulaire a survécu aux chiffres

RFC 3962 a défini des types AES dans ce cadre. RFC 4537 a séparé l’offre de types, leur ordre de préférence, la sélection locale et la sous-clé effectivement créée. Le registre IANA enregistre les identifiants et leurs références ; il ne révèle ni configuration ni adoption.

Puis les recommandations ont changé. RFC 6649 a déconseillé le DES simple et RFC 8429 a mis à jour RFC 3961 en écartant d’autres algorithmes anciens. RFC 8009 s’est conformé au cadre général pour AES et HMAC-SHA2 tout en refusant le profil simplifié, afin d’authentifier le texte chiffré avant déchiffrement. La construction changeait ; la frontière entre protocole et mécanisme restait utile.

La fiche RFC Editor et l’historique Datatracker attestent le parcours documentaire. Les errata distinguent une correction Unicode vérifiée, une correction technique DES conservée pour une prochaine mise à jour et une proposition rejetée. Leur statut ne doit être transformé ni en panne déployée ni en adoption d’un correctif.

La leçon de RFC 3961 tient donc dans une discipline : avant de demander si une clé a fonctionné, demander pour quel travail elle a été dérivée. Le numéro rendait ce travail vérifiable. Il ne nommait pas celui qui avait le droit de commander la suite.

Sources