Résumé

  • Les RFC 2403 et 2404 placent toutes deux les 96 premiers bits d’un HMAC calculé dans ESP ou AH, malgré des sorties complètes et des clés requises différentes.
  • Les recommandations ultérieures pour ESP/AH ont séparé les algorithmes : la RFC 8221 classe HMAC-MD5-96 MUST NOT et HMAC-SHA1-96 MUST-. Une longueur de tag commune n’a jamais garanti un jugement de sécurité commun.

Un champ, deux constructions

En novembre 1998, les RFC 2403 et 2404 ont défini des transformations d’authentification par clé secrète pour l’Encapsulating Security Payload (ESP) et l’Authentication Header (AH) d’IPsec. L’une associe HMAC à MD5 ; l’autre à SHA-1. Toutes deux visent l’authentification de l’origine des données et leur intégrité, à condition que la clé reste réservée aux parties qui communiquent. Aucune ne fournit à elle seule la confidentialité.

Le nombre visible dans le paquet était identique : 96 bits. La sortie HMAC-MD5 complète de la RFC 2403 compte 128 bits, contre 160 bits pour HMAC-SHA-1 dans la RFC 2404. Pour chaque transformation, l’émetteur place les 96 premiers bits dans le champ d’authentificateur. Le destinataire calcule le HMAC complet et compare ces mêmes 96 bits. Ce choix correspondait à la longueur par défaut d’AH et donnait aux deux constructions une empreinte commune sur le fil. Il ne transformait pas les condensés complets en hachages de 96 bits.

Les règles de clé différaient également : la RFC 2403 exige une clé HMAC de 128 bits ; la RFC 2404 en exige une de 160. Une même longueur de champ coexistait ainsi avec deux tailles de sortie et deux tailles de clé fixes. L’identité de la transformation négociée et la gestion de la clé comptaient toujours ; compter les seuls bits visibles ne décrivait pas tout le mécanisme.

La résistance aux collisions n’épuise pas la question HMAC

Les textes de 1998 n’assimilaient pas une collision du hachage non clé à une rupture immédiate de HMAC. La RFC 2403 indique que HMAC dépend moins fortement de la résistance aux collisions de MD5 que les signatures fondées sur MD5 et ne rapporte alors aucune attaque pratique contre HMAC-MD5-96. La RFC 2404 formule une évaluation parallèle, située dans le temps, pour HMAC-SHA-1-96. Ces constats historiques ne garantissaient rien pour l’avenir.

L’évolution des exigences d’implémentation montre comment l’évaluation a changé sans faire de la longueur du tag le critère décisif. En 2005, la RFC 4305 place HMAC-SHA1-96 au niveau MUST et HMAC-MD5-96 à MAY. En 2007, la RFC 4835 maintient cette distinction et note que les faiblesses de collision alors connues ne devraient pas affecter ces fonctions avec HMAC. En 2014, la RFC 7321 évoque des résultats théoriques contre HMAC-MD5, mais ne relève pas de vulnérabilité pratique apparente et ne juge pas urgent de le retirer des protocoles existants ; elle estime encore HMAC-SHA-1 sûr malgré la faiblesse de collision de SHA-1.

Publiée en 2017, la RFC 8221 trace une frontière plus nette dans les exigences d’implémentation ESP/AH : HMAC-MD5-96 passe à MUST NOT ; HMAC-SHA1-96 descend de MUST à MUST-. Elle justifie l’interdiction par la vulnérabilité connue de MD5 aux collisions et attribue la baisse de SHA-1 à une tendance générale de l’industrie à abandonner son usage. Cela ne signifie ni que le champ de 96 bits a changé, ni que la RFC 2404 a soudain défini un tag différent.

Un tableau de statut n’est pas une trace du trafic

La RFC 9395 a ensuite mis à jour la RFC 8221 et modifié un registre de transformations IKEv2, où figure une entrée AUTH_HMAC_MD5_96 marquée DEPRECATED. Ce registre n’est pas la table des exigences d’implémentation ESP/AH de la RFC 8221. Un nom apparemment identique traverse plusieurs contextes IPsec voisins ; il faut donc rattacher chaque statut à son protocole et au périmètre du document.

Ces textes consignent des paramètres de protocole et des recommandations datées. Ils ne comptent pas les équipements déployés, n’identifient pas la dernière association de sécurité négociée avec HMAC-MD5 et ne fixent aucune date universelle de retrait. Pour un opérateur, il faut distinguer le protocole choisi, l’identifiant de transformation, les capacités des pairs, l’association installée et le trafic observé. Le tag de 96 bits n’est qu’un élément de preuve.

Sources