Résumé

  • Datée du 1er octobre 2026, la révision 08 du projet TCPM sur les algorithmes TCP-AO précise que sa fonction KMAC256-KDF suit la variante KMAC# de NIST SP 800-56C Rév. 2. Elle distingue explicitement cette variante de l'interface KMAC256 initiale de SP 800-185 et indique que le compteur réseau de 32 bits, égal à un, identifie la version de la dérivation.
  • Le calcul décrit et les vecteurs de test figuraient déjà dans la version 07. Le changement fixe l'interprétation d'une recette existante ; il ne prouve ni un changement de clés en production ni l'approbation d'un RFC.

Une fiche de configuration peut dire « KMAC256 » aux deux extrémités d'une session, puis laisser la session échouer. Le nom ne précise pas à lui seul quelle variante reçoit la clé maître, le contexte et les autres arguments. Si ces octets sont assemblés différemment, les clés de trafic divergeront et les authentificateurs TCP-AO ne correspondront pas. Ce risque d'écart entre vocabulaire et calcul donne tout son intérêt à quelques lignes ajoutées au projet du groupe TCPM.

Dans la section 3.1.2 de draft-ietf-tcpm-tcp-ao-algs-08, les auteurs rattachent la fonction de dérivation à l'option 3 de la section 4.1 de NIST SP 800-56C Rév. 2. Ils ajoutent que ce texte définit une variante KMAC#, dotée d'arguments différents de ceux du KMAC256 publié à l'origine dans SP 800-185. Le compteur, entier de 32 bits valant un et encodé dans l'ordre réseau, est désormais présenté comme indicateur de version de KMAC256-KDF. La formule elle-même n'est pas nouvelle dans cette révision : l'amendement éclaire la lecture de la formule plutôt qu'il ne remplace les valeurs de sortie.

Cette formule combine un sel nul de 132 octets, le compteur, la clé maître désignée par Z, les informations de connexion sous FixedInfo, une sortie de 256 bits et la chaîne de personnalisation ASCII KDF. Une invocation produit la clé de trafic de 256 bits. Le projet associe cette dérivation à un MAC KMAC256-128 de 128 bits ; il propose également HMAC-SHA256-128 et une dérivation HKDF-SHA256. Les deux familles, les vecteurs d'essai et l'effet d'un MAC de 16 octets sur l'espace des options TCP étaient déjà décrits avant octobre. Il serait trompeur de les présenter comme des fonctionnalités nées avec la version 08.

La vérification utile porte donc sur les entrées et les sorties, pas seulement sur la présence d'un nom dans une interface. Dans un essai de conformité proposé par la rédaction, deux implémentations indépendantes dériveraient leurs clés, puis confronteraient leurs MAC aux vecteurs du projet pour des paquets avec ou sans options TCP couvertes. Une différence devrait conduire à examiner la variante KMAC, l'ordre des arguments, le compteur et le contexte avant d'accuser le réseau. Ce protocole d'essai est une déduction opérationnelle, non un programme de certification imposé par l'IETF.

Le texte conserve aussi des limites que la précision terminologique ne fait pas disparaître. Le MAC de 16 octets occupe, une fois porté par TCP-AO, 20 des 40 octets d'options TCP disponibles. La clé maître doit atteindre au moins 256 bits ; choisir une primitive reconnue ne corrige pas une clé médiocre ni un contournement dans l'ingénierie du protocole. Aucune source ici ne mesure le parc compatible, ne décrit une panne entre fournisseurs ou ne démontre qu'une session BGP en service aurait changé de clé. TCP-AO protège le transport ; il ne valide pas l'autorité de chaque annonce de route.

Le Datatracker classe toujours le document comme Internet-Draft actif du groupe TCPM, à l'étape I-D Exists. Son en-tête annonce une trajectoire Standards Track, tandis que le champ de statut visé du Datatracker est vide ; aucun des deux éléments ne vaut approbation. Ce que la version 08 rend plus vérifiable est plus étroit et plus concret : pour partager une clé de trafic, les parties doivent partager une recette exacte, non seulement une étiquette cryptographique.

Sources