Résumé

  • RFC 2402 calculait l’Integrity Check Value d’AH sur une vue préparée : champs immuables conservés, champs mutables prévisibles placés dans leur état d’arrivée attendu, contenus mutables imprévisibles remplacés par zéro.
  • Une ICV correcte ne prouvait pas que tous les bits observés étaient restés identiques. La fragmentation suivait AH à l’émission, le réassemblage précédait AH à la réception, l’anti-rejeu pouvait être désactivé par association et les décisions de politique ou d’application venaient ensuite.

Deux captures du même datagramme pouvaient être différentes et néanmoins conduire à la même vérification. Entre les deux, un routeur diminuait la durée de vie, pouvait toucher certains indicateurs et recalculait la somme de contrôle IPv4. RFC 2402 ne niait pas ces changements. Il construisait une représentation commune dans laquelle ils cessaient de rendre le calcul impossible.

Publié en novembre 1998, l’IP Authentication Header fournissait intégrité sans connexion et authentification de l’origine, avec un service anti-rejeu que le récepteur choisissait pour chaque association. AH n’apportait aucune confidentialité. Il couvrait les données des couches supérieures et autant d’en-tête IP que possible, mais le texte qualifiait lui-même cette couverture de fragmentaire : certains champs étaient faits pour changer en chemin.

L’en-tête AH portait le type suivant, sa longueur, des bits réservés, le Security Parameters Index, un numéro de séquence et les données d’authentification. SPI, destination et protocole AH retrouvaient l’association unidirectionnelle, donc l’algorithme et la clé. Le numéro de séquence était toujours transmis et incrémenté, même lorsque le récepteur n’utilisait pas le service anti-rejeu.

Le calcul séparait trois catégories. Les champs IP immuables et les données supérieures entraient avec leur valeur. Un champ mutable dont la valeur finale était prévisible était placé dans l’état attendu à l’arrivée. Un contenu mutable de façon imprévisible était rempli de zéros. Les données d’authentification elles-mêmes étaient aussi mises à zéro pendant le calcul, puisqu’elles devaient accueillir le résultat.

Remplir de zéros n’était pas supprimer. Les octets restaient à leur position, préservant l’alignement et faisant entrer la longueur du champ dans la structure authentifiée. Le résultat avait donc la silhouette du paquet sans reproduire toutes ses valeurs. L’expression « vue normalisée » explique bien le mécanisme ; le RFC parlait de champs immuables, mutables mais prévisibles, et mutables.

Pour IPv4, Version, longueur d’en-tête, longueur totale, Identification, valeur de protocole AH, source et destination ordinaire étaient inclus. Une destination modifiée par routage à la source était mutable mais prévisible. Type of Service, Flags, Fragment Offset, Time to Live et Header Checksum étaient remis à zéro. Les raisons étaient opérationnelles : certains routeurs modifiaient TOS, pouvaient positionner DF, diminuaient normalement TTL et changeaient ainsi la somme de contrôle.

Une ICV valide ne prétendait donc pas que le TTL reçu égalait le TTL envoyé. Elle disait que, sous la même association, clé et règle de préparation, les deux extrémités avaient obtenu la même entrée authentifiée. Le paquet vu sur le fil contenait davantage de valeurs que la revendication d’intégrité.

IPv6 appliquait la même méthode. Class, Flow Label et Hop Limit étaient remis à zéro dans le modèle de 1998. Une destination sous en-tête de routage pouvait être prévisible. Les options Hop-by-Hop et Destination indiquaient si leur Option Data pouvait changer. Si oui, ces données devenaient des octets nuls pour l’ICV, tandis que type et longueur restaient couverts. Une nouvelle option devait donc documenter correctement sa mutabilité pour rejoindre ce contrat.

Le bourrage séparait encore vue calculée et image transmise. Le bourrage explicite des données d’authentification voyageait et était authentifié. Un algorithme pouvait également exiger un bourrage implicite de zéros jusqu’à une frontière de bloc. Ces octets participaient au calcul sans être transmis. L’entrée authentifiée pouvait ainsi contenir à la fois des valeurs substituées et des octets absents du réseau.

La fragmentation fixait l’unité du contrôle. En mode transport, AH s’appliquait au datagramme entier avant toute fragmentation. Des routeurs pouvaient ensuite le diviser, mais le récepteur devait le réassembler avant AH. Un objet encore présenté comme fragment à cette étape devait être rejeté et audité. En mode tunnel, l’enveloppe AH pouvait en revanche protéger une charge interne déjà fragmentée : les deux niveaux ne devaient pas être confondus.

À la réception, l’implémentation reconstruisait la vue. Elle sélectionnait l’association, conservait l’ICV reçu, remettait à zéro Authentication Data et les champs imprévisibles, ajoutait le bourrage implicite requis, recalculait puis comparait. Si l’anti-rejeu était actif, un numéro candidat pouvait être filtré d’abord, mais la fenêtre ne progressait qu’après réussite de l’ICV. S’il était inactif, la présence du numéro ne prouvait aucun contrôle de rejeu.

RFC 2402 déclarait alors le datagramme valide à l’étape AH. L’architecture de RFC 2401 imposait encore le contrôle de politique entrant avant remise ou routage. L’application décidait plus tard. Il fallait donc préserver une chaîne : association et algorithme, vue de l’émetteur, insertion de l’ICV, éventuels fragments, réassemblage, reconstruction du récepteur, comparaison, anti-rejeu éventuel, politique puis application.

Le document n’est pas une recommandation cryptographique actuelle. Il remplaçait RFC 1826 et fut remplacé par RFC 4302 et RFC 4305. Les exigences HMAC-MD5 et HMAC-SHA-1 de l’époque ne doivent pas être réutilisées comme conseil. RFC 4302 conserva le principe de couverture fragmentaire tout en révisant les recherches d’association, les numéros étendus et la gestion des algorithmes.

Les textes ultérieurs de Lu Heng sur le code en fonctionnement et les couches de réalité offrent ici une lecture, non le vocabulaire du RFC : l’étiquette d’authentification ne vaut que par la vue effectivement construite et comparée. Elle ne peut absorber les champs exclus, les vérifications optionnelles ni les résultats encore situés en aval.

Sources