Résumé

  • Dans l’échange agressif à trois messages de la RFC 2412, les signatures pouvaient être validées et le KEYID déclaré authentifié alors que le secret partagé restait marqué uncomputed.
  • Une preuve de communication n’était donc ni une preuve de calcul, ni une preuve d’installation bilatérale, ni la preuve qu’un paquet protégé ou un service avait réellement fonctionné.

Le mot « authentifié » rassure parce qu’il paraît fermer une question. La RFC 2412 l’employait au contraire pour tracer une frontière.

Publiée en novembre 1998 avec le statut Informational, elle décrivait OAKLEY, un protocole de détermination de clés fondé sur Diffie-Hellman. Deux parties devaient pouvoir s’authentifier, convenir d’un matériau secret, choisir des algorithmes, bénéficier de la confidentialité persistante et s’insérer dans l’architecture ISAKMP. La promesse était ambitieuse ; l’état interne restait minutieusement découpé.

L’exemple dit « agressif » tient en trois messages. L’initiateur présente son cookie, son groupe, sa demi-clé g^x, ses choix d’algorithmes, ses identités et son nonce, puis signe cet ensemble. Le répondant renvoie son propre cookie, g^y, les choix retenus, les deux nonces et une signature qui lie sa réponse à la première offre. L’initiateur conclut avec une dernière signature couvrant le transcript désormais complet.

La RFC explique que ces signatures offrent une preuve de communication susceptible d’être conservée et présentée à un tiers. Puis elle retire immédiatement toute ambiguïté sur la portée de cette preuve : le matériau de clé impliqué par les exponentielles de groupe n’est pas nécessaire pour achever l’échange.

Le logiciel peut enregistrer x et g^y, qualifier le matériau de uncomputed, et remettre le calcul à plus tard.

Ce choix est encore plus visible dans la procédure détaillée. Après avoir vérifié la signature du répondant, l’initiateur ajoute g^y à son état. Il peut calculer (g^y)^x, mais il peut aussi différer cette opération jusqu’après l’envoi du dernier message. Il marque pourtant le KEYID authentifié. Le répondant, lorsque la dernière signature est valide, marque à son tour la clé authentifiée et doit ensuite calculer g^xy puis l’associer au KEYID.

L’authentification du transcript et le calcul du secret ne sont pas deux noms pour le même événement. Ce sont deux transitions.

Le KEYID rend la distinction tangible. Dans OAKLEY, la concaténation des cookies de l’initiateur et du répondant sert à la fois de mécanisme faible contre l’engorgement et de nom réutilisable du matériau de clé. sKEYID, lui, désigne le matériau secret associé à ce nom ; il n’est jamais transmis et dépend, dans cet exemple, de g^xy, des nonces et des cookies. Un identifiant peut donc exister avant son contenu. Il peut même être authentifié avant que ce contenu soit calculé.

Une interface d’exploitation qui ne montre qu’un voyant vert efface ce détail. « Authentifié » peut alors être lu comme « canal utilisable », puis comme « association installée aux deux extrémités », puis comme « trafic protégé ». Chaque glissement ajoute une conclusion que le reçu précédent ne portait pas.

La déférence du calcul avait pourtant une logique. À la fin des années 1990, une exponentiation modulaire coûtait cher. La retirer du chemin critique du dernier message pouvait réduire le délai visible et répartir la charge. Le pair recevait le même transcript signé ; l’interopérabilité sur le fil ne dépendait pas nécessairement de l’instant précis où l’instruction coûteuse s’exécutait.

Mais une économie de calcul immédiat devient une dette d’état. Il faut conserver le bon exposant privé, la bonne valeur publique reçue, le groupe choisi, les deux cookies, les nonces, les identités et les algorithmes. Il faut vérifier la valeur reçue, calculer le secret, dériver le bon matériau et le rattacher au bon échange. Une expiration, un redémarrage, une réutilisation de référence ou une promotion trop précoce peut laisser une preuve signée parfaitement valide sans clé exploitable.

La chaîne probante doit donc rester séquentielle. Un reçu de transcript atteste que la signature attendue porte sur les champs attendus. Un reçu de validation atteste que la valeur Diffie-Hellman reçue satisfait les contrôles applicables. Un reçu de calcul atteste que g^xy et les dérivés existent. Un reçu d’association relie ces octets aux identités, aux algorithmes et au KEYID prévus. Un reçu d’installation les place dans la bonne association de sécurité. Un paquet protégé démontre ensuite que le chemin de données fonctionne. Le résultat appartient enfin au service.

Aucun étage ne peut emprunter la certitude de l’étage précédent.

La RFC 2412 contenait déjà des précautions sur les valeurs exponentielles dégénérées et exigeait de bonnes sources aléatoires pour les cookies, nonces et exposants. Son erratum corrige une confusion terminologique entre nombres premiers sûrs et nombres premiers de Sophie Germain ; il ne change pas le mécanisme de calcul différé.

En 2013, la RFC 6989 a rendu plus explicites les tests de clés publiques Diffie-Hellman dans IKEv2, notamment face aux petits sous-groupes. Une charge KE invalide devait être rejetée et ne pas servir à créer l’association IKE. Cette règle ultérieure ne prouve rien sur les contrôles réellement exécutés par un produit OAKLEY ou IKEv1 en 1998. Elle confirme seulement un principe : recevoir des octets ne donne pas le droit de calculer avec eux.

La RFC 2409 a intégré des éléments d’ISAKMP et d’OAKLEY dans IKEv1. Son mode agressif conservait une possibilité analogue : le dernier contenu pouvait rester non protégé afin de repousser l’exponentiation jusqu’à la fin de la négociation. Le calendrier pouvait bouger ; la dérivation restait dépendante de la valeur partagée réelle. Le mot « terminé » ne produisait pas les bits manquants.

IKEv2 a ensuite réorganisé la succession des états. Les RFC 4306, 5996 puis 7296 ont remplacé les générations précédentes. Dans la RFC 7296, SKEYSEED naît des nonces et du secret Diffie-Hellman éphémère, avant la dérivation de clés distinctes pour le chiffrement, l’intégrité et l’authentification. Le texte distingue aussi une association IKE authentifiée d’une association enfant qui peut encore échouer.

Il ne faut pas projeter cette machine d’états moderne sur OAKLEY. Il faut constater une continuité intellectuelle : un état de contrôle sécurisé peut être établi alors que le chemin de données qu’il doit permettre ne l’est pas encore.

L’histoire documentaire impose la même discipline. La RFC 2412 n’était pas une norme Internet. IKEv1 a ensuite été normalisé, puis remplacé ; les recommandations algorithmiques ont évolué ; la RFC 9395 a déprécié IKEv1 et plusieurs anciens algorithmes. Une dépréciation modifie l’orientation actuelle. Elle ne désinstalle aucun équipement et ne réécrit pas la chronologie d’un échange ancien.

La primauté du code en fonctionnement formulée par Lu Heng aide à maintenir cet ordre. Le document peut définir une transition ; seul le système exécuté peut montrer qu’elle s’est produite. Les « couches de réalité » ne sont pas des versions rivales d’une même histoire. Elles sont des faits dépendants : transcript reçu, signature validée, valeur publique contrôlée, secret calculé, matériau associé, SA installée, paquet accepté, service rendu.

La spécification initiale minimale apporte une nuance essentielle. Il fallait normaliser ce que deux implémentations indépendantes devaient partager : champs signés, dérivation, identités, groupes et sens des états. Il n’était pas nécessaire d’imposer le cycle processeur exact auquel chaque machine devait effectuer son exponentiation, tant que la sécurité et l’interopérabilité demeuraient vérifiables.

Cette liberté locale ne supprime pas la responsabilité. Celui qui diffère le calcul contrôle l’intervalle caché entre l’authentification et la disponibilité de la clé. Il doit conserver les entrées, exposer l’état avec précision et échouer sans laisser un reçu faible se transformer en promesse forte. L’application qui supporte l’échec ne devrait pas avoir à deviner la différence.

Le mot uncomputed est ainsi l’un des détails les plus honnêtes de la RFC 2412. Il ne nie pas la valeur de la signature. Il refuse seulement de lui faire prouver un calcul qui n’a pas encore eu lieu.

L’échange était authentifié. Le secret partagé restait à calculer. L’association restait à lier et à installer. Le paquet restait à transmettre. Le service restait à vérifier.

La sécurité commence par le refus de confondre ces verbes.

Sources