Résumé

  • RFC 5926 imposait à toute implémentation pleinement conforme HMAC-SHA-1-96, AES-128-CMAC-96 et leurs KDF associées.
  • Les deux constructions produisaient une balise de 96 bits, tout en offrant une base commune et une voie de migration distincte.

L’agilité ne remplace pas l’accord

TCP-AO ne vérifie pas une promesse abstraite de « cryptographie robuste ». L’émetteur dérive une clé de trafic propre à la connexion, puis calcule un MAC avec un algorithme précis. Le récepteur doit refaire exactement la même dérivation et le même calcul. Si le couple diffère, la balise reçue ne constitue pas une autre interprétation valide : elle est invérifiable.

RFC 5926 associait donc le choix à un socle obligatoire. Une implémentation conforme devait fournir HMAC-SHA-1-96, AES-128-CMAC-96, KDF_HMAC_SHA1 et KDF_AES_128_CMAC. Cela ne signifiait pas qu’une connexion utilisait les deux suites simultanément, ni qu’une négociation était effectuée dans TCP. Les systèmes devaient disposer de choix communs qu’ils pouvaient configurer de façon cohérente.

Le MAC ne suffisait pas à définir le contrat. La KDF transforme la Master_Key configurée, le Context propre à la connexion et la longueur demandée en Traffic_Key. Chaque MAC défini par RFC 5926 indique sa KDF associée ; une KDF peut servir plusieurs MAC, mais le calcul de la clé de trafic ne pouvait rester indéterminé.

Deux primitives dans un espace limité

HMAC-SHA-1-96 part d’une clé de trafic de 160 bits et de la sortie HMAC-SHA1. AES-128-CMAC-96 utilise une clé de 128 bits et AES-CMAC. Dans les deux cas, la valeur placée dans l’option TCP-AO est tronquée à 96 bits. Cette longueur résultait d’un compromis entre la force d’authentification et l’espace réduit d’une option TCP ; les primitives sous-jacentes ne devenaient pas pour autant des primitives de 96 bits.

En 2010, HMAC-SHA1 était recommandé comme valeur par défaut d’interface parce qu’il était largement pris en charge. AES-128-CMAC était également obligatoire comme alternative distincte et possibilité de migration. Cette justification décrit le contexte de publication, et non une recommandation cryptographique actuelle.

La KDF AES-CMAC acceptait aussi des clés maîtresses de longueur variable : lorsque l’entrée ne comptait pas exactement 16 octets, elle dérivait une clé de 128 bits. Cette souplesse d’interface ne rendait pas sûre une clé faible ou prévisible.

Ce que le socle réglait — et ce qu’il ne réglait pas

Les quatre composants obligatoires donnaient aux logiciels conformes un terrain commun. Ils ne corrigeaient pas une configuration divergente. Les pairs devaient encore partager les mêmes choix et le même matériel secret, et le modèle de clés manuelles laissait cette coordination en dehors de l’échange TCP.

Le RFC prévoyait une interface pour de futurs MAC et KDF, assortie d’un objectif liant le nombre de messages protégés à la probabilité de collision. Il s’agissait d’une limite d’extensibilité, pas d’une négociation automatique.

Sources