Résumé

  • RFC 2410 a défini NULL comme la fonction identité, avec une clé et un vecteur d’initialisation de zéro bit. « Ne pas chiffrer » devenait ainsi un choix négociable et interopérable, non une omission tacite.
  • ESP pouvait associer ce choix à une authentification forte. Mais un paquet ESP ordinaire ne signalait pas de manière déterministe à un intermédiaire qu’il transportait du clair ; voir le clair ne suffisait pas davantage à autoriser son inspection.

L’histoire intéressante ne se trouve pas dans ce que faisait l’algorithme NULL. Il ne faisait rien. Elle se trouve dans les institutions techniques construites autour de ce rien : un numéro de transformée, des paramètres obligatoires, une négociation entre pairs, un état installé dans les machines et, plus tard, des observateurs incapables de déduire avec certitude ce que les pairs savaient.

RFC 2410 écrit l’opération sans détour : NULL(b) = I(b) = b. L’entrée ressort inchangée. La plaisanterie sur les cryptographes romains amuse le lecteur, mais la spécification est stricte. La taille de clé pour l’extraction IKE doit être de zéro bit. La taille de l’IV doit être de zéro bit. L’algorithme est sans état et son bloc mesure un octet.

Ces zéros ne sont pas décoratifs. Deux implémentations devaient produire la même représentation et ne pas inventer chacune une manière différente de signifier l’absence. Le protocole traitait ainsi « pas de confidentialité » comme une valeur explicite dans la place réservée au chiffrement.

Le choix répondait à un besoin réel. ESP séparait le service de confidentialité du service d’authentification et d’intégrité. Un opérateur pouvait vouloir détecter les modifications et authentifier l’origine des données sans masquer le contenu. ESP_NULL permettait de conserver l’enveloppe ESP et d’y associer un algorithme d’authentification.

NULL, pris seul, ne fournissait aucun service de sécurité. C’est une limite essentielle du texte. La sécurité venait de l’autre transformée, de sa clé, de la politique qui l’avait autorisée et du traitement effectivement exécuté. Dire « ESP_NULL sécurisé » sans nommer l’intégrité revient à attribuer au zéro la force d’un mécanisme absent.

RFC 2406 imposait déjà qu’une SA ESP emploie au moins un algorithme cryptographiquement fort, de chiffrement ou d’authentification. RFC 4303 a maintenu le principe : confidentialité et intégrité peuvent être optionnelles dans des cas définis, mais elles ne doivent pas être toutes les deux NULL. Une enveloppe ESP ne devait pas devenir une étiquette vide.

La comparaison avec AH était elle aussi bornée. Avec le même algorithme d’authentification, RFC 2410 ne voyait pas de raison de considérer ESP_NULL comme cryptographiquement moins sûr. Mais la couverture différait : AH incluait certaines parties immuables de l’en-tête IP, tandis que l’authentification ESP_NULL ne le faisait pas. Similarité de service ne signifiait ni identité de format, ni identité de traversée, ni identité de politique.

Le registre IKEv1/IPsec DOI a donné la valeur 11 à ESP_NULL. Le registre IKEv2 conserve la valeur 11 pour ENCR_NULL dans le contexte ESP, tout en indiquant que cette transformée n’est pas autorisée pour protéger IKEv2 lui-même. Le nombre est donc inutilisable sans le registre, le type de transformée et le protocole qui lui donnent sens.

Une entrée de registre prouve un vocabulaire commun. Elle ne prouve aucune utilisation. Pour affirmer qu’une SA employait ENCR_NULL, il faut le transcript de proposition et de sélection ou l’état authentique installé. Pour affirmer que l’intégrité protégeait le paquet, il faut l’algorithme associé et le résultat de vérification. Pour affirmer que le service a fonctionné, il faut encore l’observation du traitement ultérieur.

Cette chaîne évite de confondre usage légitime et déclassement. Une politique peut choisir volontairement l’intégrité seule. Dans ce cas, NULL est la réalisation correcte de la décision. Si la politique exigeait la confidentialité mais qu’une négociation a accepté NULL, la même valeur peut devenir la trace d’un déclassement. L’algorithme ne décide pas lequel des deux récits est vrai ; la politique et les preuves de négociation le décident.

RFC 8221 a continué à exiger l’implémentation d’ENCR_NULL pour permettre ESP avec authentification seule, notamment parce qu’ESP se prête mieux que AH à la traversée de NAT. Exiger une capacité d’interopérabilité n’est pas exiger son activation. La décision de déploiement demeure locale.

Cette localité crée une asymétrie d’information. Les extrémités consultent la SA et savent quelle transformée a été négociée. Un équipement intermédiaire ne possède pas nécessairement cet état. Le SPI aide le destinataire à trouver sa SA ; il n’est pas une déclaration publique de confidentialité adressée à tous les appareils du trajet.

Or certains réseaux voulaient inspecter les charges utiles non chiffrées pour contrôler les accès, détecter des logiciels malveillants ou appliquer une règle interne. Avec AH, le protocole et la longueur facilitaient l’identification. Avec ESP, le format extérieur ne révélait pas de façon déterministe si la charge était chiffrée ou seulement authentifiée.

RFC 5840 est né de ce manque. WESP ajoutait une enveloppe permettant à l’intermédiaire de savoir si la confidentialité était employée et, sinon, de localiser ce qui pouvait être inspecté. L’existence de ce mécanisme prouve que l’ESP ordinaire ne fournissait pas cette visibilité. Elle ne prouve ni l’adoption universelle de WESP ni la légitimité de toute inspection.

RFC 5879 a documenté une solution différente : des heuristiques pour reconnaître ESP-NULL sans modifier les hôtes. Une heuristique examine des structures plausibles, vérifie des longueurs et cherche la cohérence d’un protocole interne. Elle produit une probabilité opératoire, pas une attestation signée par les extrémités.

Le document plaçait d’ailleurs ce travail dans un domaine administré où la politique pouvait interdire aux hôtes de contourner l’inspection en choisissant le chiffrement. Cette condition compte autant que la technique. Hors de cette relation, la lisibilité d’octets ne crée ni mandat, ni consentement, ni finalité autorisée.

Il existe donc au moins quatre vérités distinctes. La SA dit ce que les pairs ont choisi. Le paquet montre une forme extérieure. L’intermédiaire applique une méthode de classification. La politique dit ce qu’il peut faire du résultat. Les fusionner dans un champ « trafic visible » supprime précisément les responsabilités qu’un audit doit conserver.

La réception ajoute d’autres frontières. Une SA entrante et une SA sortante sont différentes. Une configuration désirée peut diverger de l’état du noyau. Le contrôle d’intégrité peut échouer. La fenêtre anti-rejeu peut rejeter un paquet correctement authentifié mais ancien. Le pare-feu intérieur peut ensuite bloquer le flux. L’application peut ne jamais l’accepter.

La lisibilité du contenu n’est donc qu’une propriété parmi d’autres. Elle ne prouve ni la sélection correcte, ni l’installation symétrique, ni l’origine, ni l’autorisation, ni la livraison. À l’inverse, l’absence de confidentialité ne signifie pas absence de structure ou de responsabilité.

Le déplacement historique des registres confirme cette prudence. RFC 9395 a rendu IKEv1 historique et fermé ses anciens registres. Il a déprécié plusieurs algorithmes vieillissants, mais pas ENCR_NULL. Le registre IKEv2 renvoie toujours à RFC 8221 pour les exigences ESP. Il faut distinguer la fermeture d’une famille de négociation de la survie du service intégrité seule dans ESP moderne.

La grille de Lu Heng aide à lire cette architecture. Le registre appartient à la couche symbolique. La sélection appartient à l’accord entre pairs. La SA installée appartient au code en exécution. L’heuristique appartient à l’observation. Le droit d’inspecter appartient à l’autorité définie par la politique. Le résultat appartient à l’application.

Le problème d’agence apparaît quand un acteur parle au nom des autres. Le fournisseur du boîtier d’inspection n’est pas le propriétaire de la politique. Le démon IKE n’est pas le noyau. Le noyau n’est pas l’application. Le rédacteur de la norme ne connaît pas le résultat d’un déploiement futur.

La primauté du code en exécution ne nie pas le rôle du document ; elle limite sa prétention. La norme fournit la fonction identité et les invariants minimaux. L’exploitation doit fournir le reste : politique versionnée, transcript, SA entrante et sortante, algorithme d’intégrité, résultat anti-rejeu, méthode de classification, autorisation d’inspection et résultat applicatif.

RFC 2410 a donné un nom précis à l’absence de chiffrement. Son histoire montre pourquoi une absence bien nommée reste incapable de parler au nom de toutes les couches qui la suivent.

Sources