Résumé

  • RFC 3962 codait le nombre d’itérations PBKDF2 dans quatre octets non signés en ordre gros-boutiste : quatre zéros présents signifiaient 4 294 967 296 tours, tandis que l’absence du champ conduisait à 4 096 lorsque le KDC avait pu le fournir.
  • Une valeur trop haute pouvait immobiliser le client ; une valeur trop basse pouvait réduire le coût d’une attaque par dictionnaire. L’authenticité de la source et les bornes locales comptaient donc autant que le nombre lui-même.

La différence la plus coûteuse du document tenait dans une question de grammaire : le paramètre est-il présent ? RFC 3962 décrivait une chaîne de quatre octets représentant, en ordre gros-boutiste, un entier non signé. Cet entier pilotait le nombre de tours de PBKDF2. Mais la valeur binaire entièrement nulle ne valait pas zéro tour. Elle désignait (2^{32}), soit 4 294 967 296 itérations.

Le silence du message avait un autre sens. Quand le KDC avait eu l’occasion de transmettre les paramètres de conversion du mot de passe en clé et que le champ restait absent, la valeur interprétée était 00 00 10 00, soit 4 096. Le texte insistait : cette règle n’était ni une obligation générale pour les bases Kerberos, ni une recommandation pour la préauthentification optimiste.

Une présence à conserver de bout en bout

Une interface peut afficher zéro dans une case vide. Un décodeur peut produire la même valeur pour un tableau d’octets nul et pour un champ inexistant. Un sérialiseur peut omettre les valeurs jugées « falsy ». Chacune de ces commodités change ici le protocole. Passer de l’absence à quatre octets nuls multiplie le travail par 1 048 576.

Publié en février 2005, RFC 3962 installait AES dans le cadre cryptographique de RFC 3961. Il définissait des clés de 128 ou 256 bits, des blocs AES de 128 bits, le mode CBC avec vol de texte chiffré et HMAC-SHA1-96. Les types de chiffrement 17 et 18 et les types de somme de contrôle 15 et 16 figurent encore dans le registre IANA des paramètres Kerberos. Le registre attribue des noms ; il ne mesure ni l’activation dans les domaines, ni le choix lors d’un échange.

Pour produire une clé depuis un mot de passe, PBKDF2 traitait la phrase secrète et le sel, puis l’opération de dérivation de RFC 3961 utilisait la constante kerberos. RFC 2898 décrivait alors PBKDF2 dans PKCS #5 ; RFC 8018 en a ensuite publié la version révisée. La largeur finale de 256 bits ne transformait pas un mot de passe humain en secret de 256 bits. Les tours rendaient chaque essai plus cher, sans créer l’entropie absente de l’entrée.

La défense ralentissait aussi son utilisateur

Le facteur de travail ne favorisait pas naturellement le défenseur. Multiplier les tours ralentissait l’attaquant qui essayait un dictionnaire, mais exactement le même coefficient ralentissait l’utilisateur légitime qui connaissait le bon mot de passe. RFC 3962 traitait donc le compteur comme un compromis de coût, non comme un score de sécurité absolu.

Un adversaire capable de fabriquer une réponse attribuée au KDC pouvait exploiter les deux extrêmes. Avec un nombre très élevé, il forçait le client à consommer du processeur pour calculer une clé incorrecte : une forme de déni de service. Le RFC autorisait une borne supérieure et précisait qu’elle ne devrait pas être inférieure à 50 000. Face aux quatre milliards de tours encodés par zéro, offrir un mécanisme d’interruption restait raisonnable.

Avec un nombre artificiellement bas, le même adversaire poursuivait un autre but. Après avoir observé la réponse du client, il pouvait tester les mots de passe à moindre coût. Des bornes inférieures étaient donc pertinentes elles aussi. Accepter tout nombre reçu n’était pas prudent ; maximiser mécaniquement le nombre ne l’était pas davantage. Il fallait une plage définie par le site et une preuve de la provenance du paramètre.

Cette provenance manque dans une trace qui dit seulement iterations=4096. La valeur venait-elle d’un message authentifié, d’une erreur non protégée, d’un cache, de la configuration locale ou de la règle d’absence ? Le contrôle des bornes a-t-il précédé le calcul ? Sans ces éléments, la même ligne peut décrire une politique saine, un repli de compatibilité ou une donnée injectée.

L’optimisme avait une dette de fraîcheur

La préauthentification optimiste permettait au client d’envoyer d’emblée un horodatage protégé, en dérivant la clé avant de demander les paramètres actuels au KDC. Elle économisait un aller-retour si l’hypothèse était correcte. En l’absence d’autres informations, elle ne pouvait cependant que deviner le compteur.

Même la valeur utilisée quelques heures plus tôt pour le même principal pouvait être périmée. Le document envisageait justement une augmentation régulière des coûts au fil du progrès matériel. Il refusait donc de consacrer un chiffre universel et recommandait une configuration propre au site, située entre les bornes d’acceptation.

Ce passage évite une lecture anachronique. Le sujet n’est pas de proclamer 4 096 anciennement suffisant, ni 50 000 éternellement juste. Le sujet est l’autorité qui choisit, l’instant où la valeur a été observée et l’état d’authentification de cette observation. Quand le client supprime un échange, il doit remplacer l’information fraîche par une politique explicitement gouvernée.

Une clé calculée n’était pas encore une identité acceptée

La fin de PBKDF2 produisait un matériau cryptographique, pas une décision métier. RFC 4120 porte le protocole Kerberos V5, ses tickets, ses authentificateurs et son traitement des rejeux. La réussite de la dérivation ne prouve ni le mot de passe, ni l’acceptation par le KDC, ni la validité du ticket, ni l’autorisation de l’application.

RFC 4537 a ensuite séparé les types proposés du type choisi par le serveur. RFC 6113 a généralisé la préauthentification et le transport de paramètres. RFC 8009 a introduit des profils AES avec HMAC-SHA2, tandis que RFC 8429 a déconseillé plusieurs algorithmes anciens. Ces évolutions modifient la chaîne sans confondre dérivation, authentification et autorisation.

Le vol de texte chiffré posait par ailleurs une limite différente : sans bourrage supplémentaire, la longueur du texte chiffré révélait exactement celle du texte clair. Une couche supérieure devait ajouter son propre camouflage si cette longueur était sensible. Augmenter PBKDF2 n’apportait rien à cette fuite.

Une preuve exploitable relierait donc : présence du champ, quatre octets exacts, entier obtenu, source et authenticité du message, bornes locales, type de chiffrement, provenance du sel, version de bibliothèque, durée, ressources et éventuelle interruption. Puis elle enregistrerait séparément la préauthentification, le ticket, le rejeu, l’autorisation et le résultat du service. Ni le mot de passe ni la clé ne doivent être consignés.

La notice RFC Editor, l’historique Datatracker et la recherche d’errata ferment le dossier documentaire ; cette dernière ne renvoyait aucun erratum correspondant lors de la capture. Cela décrit un registre, pas l’absence garantie de bogues dans les logiciels.

La leçon de RFC 3962 dépasse son chiffre spectaculaire. Zéro, absence et valeur par défaut racontent trois faits différents. Un système de sécurité qui les fusionne ne perd pas seulement une nuance : il perd la capacité d’expliquer pourquoi il a dépensé son calcul et qui le lui a demandé.

Sources