Résumé

  • Publiée le 1er octobre, la révision 08 de draft-ietf-tcpm-tcp-ao-algs précise que KMAC256-KDF suit la variante KMAC# de NIST SP 800-56C Revision 2, et non une simple invocation laissée à l’interprétation du nom KMAC256.
  • La réception d’un déploiement doit donc produire un reçu d’instance : variante normative, paramètres publics, encodages, contexte de connexion, résultat de vecteur, octets TCP-AO et résultat observé chez le pair.

Dans un journal de changements, une ligne comme « passage à KMAC256 » paraît précise. Elle peut pourtant cacher l’information dont dépend toute la session : quelle fonction exacte a été appelée, avec quels rôles d’arguments et quelle représentation binaire ? Deux équipes peuvent approuver la même ligne et construire deux Traffic Keys différentes.

La révision 08 du projet TCPM met ce risque de langage en pleine lumière. Le texte indique que KMAC256 et ses arguments ont été définis dans NIST SP 800-185, puis que SP 800-56C Revision 2 définit une variante nommée KMAC# dont l’ensemble d’arguments diffère. Le KMAC256-KDF du projet se conforme explicitement à cette variante. La nouvelle révision ajoute aussi que l’entier 32 bits 1, encodé dans l’ordre réseau, indique la version du KDF.

Il ne faut pas surinterpréter cette modification. Le document daté du 1er octobre 2026 reste un Internet-Draft actif, destiné au Standards Track. Le groupe TCPM vise une soumission à l’IESG en novembre ; ce calendrier n’est ni une adoption ni une approbation. Le registre IANA capturé pour cette enquête contient encore SHA1 et AES128. Les deux nouveaux noms sont demandés par le projet, pas encore établis par cette demande.

Le contrat de dérivation réunit des éléments très concrets. Le sel est une chaîne de 132 octets nuls. Le compteur vaut 1 sur 32 bits en ordre réseau. Z est la Master Key. FixedInfo est le contexte TCP-AO. La sortie fait 256 bits. La chaîne de personnalisation est constituée des trois octets ASCII KDF. Comme la longueur demandée correspond à la sortie auxiliaire, une seule invocation suffit.

Le calcul du MAC forme une deuxième instance, qu’il faut documenter séparément. KMAC256-128 prend comme clé la Traffic Key de 256 bits, authentifie le message construit selon TCP-AO, emploie cette fois une chaîne de personnalisation vide et demande directement 128 bits. Avec 16 octets de MAC, l’option TCP-AO entière occupe 20 des 40 octets disponibles pour les options TCP.

Cette séparation entre dérivation et authentification interdit un raccourci fréquent : reporter partout une valeur « par défaut ». KDF est obligatoire dans la première opération ; la chaîne vide appartient à la seconde. Une bibliothèque peut exposer ces choix avec des noms différents, inverser l’ordre apparent de ses arguments ou masquer certaines valeurs. Le résultat doit néanmoins reproduire le contrat, octet pour octet.

RFC 5925 explique pourquoi le contexte compte autant que la primitive. Adresses source et destination, ports et numéros de séquence initiaux entrent dans la dérivation. Les clés sont directionnelles. Pour un SYN dont le numéro de séquence distant n’est pas encore connu, la valeur correspondante est zéro. Les segments ultérieurs utilisent les deux valeurs connues. Un pair qui construit le contexte depuis son point de vue sans appliquer la direction prévue ne calcule pas la même entrée.

Le paquet ne révèle pas tout. L’option TCP-AO contient Kind, Length, KeyID, RNextKeyID et le MAC. Elle n’encode pas le nom de l’algorithme. Celui-ci est rattaché au Master Key Tuple configuré hors bande. Deux équipements peuvent donc afficher le même KeyID dans une capture tout en associant localement cet identifiant à des paramètres différents.

Un contrôle sérieux doit relier les couches. Le reçu proposé par BTW comprendrait la révision du projet, les identifiants KDF et MAC, les versions des sources NIST, le sel public, le compteur et son ordre d’octets, les tailles de sortie, les deux chaînes de personnalisation, un identifiant non secret du Master Key Tuple, puis le produit et sa version de build. Il conserverait aussi le condensat d’un vecteur connu, les octets de l’option observée, la validation par le pair, l’état TCP et le résultat applicatif.

La Master Key et la Traffic Key de production n’ont pas leur place dans ce dossier. La traçabilité ne justifie pas la divulgation. Une identité de clé contrôlée et des calculs sur des vecteurs publics suffisent à comparer deux chemins d’implémentation sans transformer le système de logs en dépôt de secrets.

Les vecteurs du projet couvrent IPv4 et IPv6, avec inclusion ou omission des autres options TCP. Réussir l’un de ces cas prouve qu’un build a reproduit une sortie attendue pour une entrée déterminée. Cela ne prouve pas que le site a chargé la bonne MKT, choisi le bon sens de connexion ou authentifié les mêmes octets. Le vecteur est une marche de l’escalier, pas tout l’escalier.

On doit donc refuser le mot unique « compatible » lorsqu’il remplace plusieurs observations. Une fonctionnalité annoncée, un vecteur réussi, un segment accepté, une connexion établie et un échange BGP sont cinq constats. Le premier ne garantit pas le second ; le troisième ne prouve pas le cinquième. Cette discipline réduit considérablement la zone de recherche lors d’un incident.

La Minimum Initial Specification de Heng Lu fournit ici une règle productive. La couche commune doit rester étroite, mais chaque élément nécessaire à un résultat identique doit y être strict : variante, fonctions des paramètres, encodages, contexte et longueurs. Les opérateurs restent libres de choisir bibliothèque, interface et stockage. Ils ne peuvent pas rendre local ce qui détermine l’interopérabilité.

Running-Code Primacy place ensuite la preuve dans les vecteurs reproductibles et les octets produits par les systèmes. Reality Layers empêche de confondre projet, demande IANA, configuration, accord de clé, MAC valide, connexion et service. Il s’agit d’une lecture éditoriale de Daniel Kade à partir de Heng Lu, et non d’une doctrine attribuée à l’IETF ou au NIST.

La prudence reste essentielle. La révision ne démontre ni rupture de KMAC, ni désaccord entre implémentations de la version 07, ni erreur d’un fournisseur. Une revue Security Directorate antérieure posait des questions sur le bénéfice des nouvelles paires, les sorties plus longues et l’espace des options TCP ; les éléments publics ne permettent pas d’en faire la cause de la précision ajoutée en version 08.

L’enseignement opérationnel est plus solide lorsqu’il reste étroit : le nom de l’algorithme est une adresse, pas le contenu livré à cette adresse. L’instance complète, son vecteur et son observation sur le fil constituent le véritable objet de compatibilité.

Sources