Résumé

  • Dans le RFC 2085, le champ Replay Prevention de 64 bits était optionnel par association de sécurité ; le SPI sélectionnait l’état où ce champ existait ou non.
  • Le compteur commençait à 1, ne devait pas boucler sous une même clé, et chaque récepteur choisissait sa tolérance au désordre tout en n’admettant une valeur qu’une fois.
  • Un HMAC valide et un compteur inédit prouvaient une admission locale sous une SA partagée, pas l’identité d’un émetteur multicast, une chronologie globale, la livraison, l’autorisation ou l’effet applicatif.

Un paquet IP authentifié pouvait être une copie exacte d’un ancien paquet : le MAC restait correct puisque les octets n’avaient pas changé. Le RFC 2085, publié en 1997, ajouta une réponse étroite. Il authentifiait aussi un compteur et obligeait le récepteur à conserver assez d’histoire pour refuser une valeur déjà admise.

Le SPI choisissait la présence du champ

Le format plaçait le Replay Prevention optionnel entre le SPI et Authentication Data. Sans protection anti-rejeu, les données d’authentification suivaient directement le SPI. Dans le RFC 1826, ce dernier permettait au récepteur de retrouver une association unidirectionnelle, son algorithme, sa clé et son état. Il sélectionnait donc un contrat de traitement, pas une identité humaine.

Le compteur partait de 1 et augmentait. La clé partagée ne devait pas survivre jusqu’au bouclage de 2^64 paquets. Présent, le compteur entrait dans le calcul HMAC : un tiers sans la clé ne pouvait remplacer un ancien numéro par un nouveau sans casser l’authentificateur. Mais deux contrôles demeuraient séparés. Le HMAC liait paquet et numéro au secret partagé ; l’historique du récepteur décidait si cette valeur authentifiée restait admissible.

Croissant ne voulait pas dire livré dans l’ordre

Le RFC autorisait les paquets désordonnés et laissait la profondeur de fenêtre à l’implémentation. L’invariant était précis : toute valeur acceptée hors ordre devait ne jamais avoir été acceptée auparavant.

Une valeur inférieure au maximum pouvait donc être un retard légitime, si elle restait dans la fenêtre et si son état « vu » était libre. Une valeur à gauche de la fenêtre était trop ancienne ; une valeur déjà marquée était un doublon ; une valeur nouvelle à droite pouvait déplacer la frontière après authentification. Le RFC 6479 décrivit plus tard cette mécanique comme une plage et des bits de présence, et montra pourquoi le parallélisme cryptographique peut imposer une fenêtre plus large.

Cette fenêtre appartenait au récepteur. Deux destinataires pouvaient voir le même flux dans un ordre différent et retenir des profondeurs différentes. Un trou ne prouvait pas la perte, un retard ne prouvait pas l’attaque, et l’admission par A ne prouvait pas l’admission par B. Le reçu exact était seulement : sous cette SA et cet état local, ce numéro authentifié n’avait encore jamais été admis.

Le multicast partagé effaçait la lignée

Le RFC 2085 exposait lui-même sa limite. Lorsque plusieurs émetteurs partageaient une même SA vers une destination multicast, la protection anti-rejeu ne devait pas être activée. Pour la conserver, chaque émetteur devait disposer de sa propre SA.

Le HMAC ne cessait pas de fonctionner. Tout détenteur du secret pouvait produire une valeur valide. Ce qui manquait était la propriété du compteur. Plusieurs émetteurs démarrant à 1 entraient immédiatement en collision ; chacun pouvait avoir un compteur local sain tandis que le flux agrégé répétait les mêmes valeurs. Aucun séquenceur multi-émetteur n’était défini.

Séparer les SA restaurait la lignée : le SPI dirigeait chaque paquet vers le bon historique. Désactiver l’anti-rejeu reconnaissait honnêtement que l’authentification de groupe subsistait, mais que cette couche ne pouvait plus décider de la première apparition.

Le RFC 4302 conserva plus tard cette limite, tout en rendant le numéro de séquence obligatoire et en ajoutant l’ESN logique de 64 bits. Cette évolution éclaire le problème sans changer rétroactivement le format : le RFC 2085 transmettait directement son champ optionnel de 64 bits.

Le MAC partagé prouvait la possession du secret, non le locuteur unique

Le RFC 1826 avertissait qu’un détenteur de clé symétrique pouvait aussi fabriquer du trafic attribué à un autre participant légitime. Un HMAC réussi prouvait donc la possession du secret et l’intégrité des données couvertes. Il ne distinguait pas les membres d’un groupe partageant cette clé.

Le compteur resserrait l’admission après ce contrôle ; il ne transformait pas un secret collectif en signature individuelle. AH n’offrait pas non plus la confidentialité. Un paquet pouvait être authentique pour la SA et frais pour la fenêtre tout en restant non autorisé par l’application, non livré ou sans effet durable.

Un audit doit conserver séparément : résolution SA, présence du champ, compteur, position dans la fenêtre, état déjà-vu, résultat HMAC, admission, réception applicative, autorisation et effet validé. Le compteur ne nommait pas l’émetteur. Il nommait une place dans l’histoire d’admission d’un récepteur.

Sources