Résumé

  • RFC 2407 a donné au monde ISAKMP un vocabulaire IPsec commun : DOI, Situation, identités, protocoles, transforms, attributs et notifications. Un code partagé rendait une affirmation lisible ; il ne la rendait ni vraie ni automatiquement autorisée.
  • Le document laissait explicitement la politique de sécurité aux hôtes. La preuve opérationnelle devait relier le message authentifié à la règle locale, au choix du répondant, à l’installation de la SA et au résultat des paquets.

INITIAL-CONTACT concentre toute l’ambiguïté dans un seul code. L’émetteur déclarait qu’il s’agissait de sa première SA avec le système distant. Le récepteur pouvait en déduire que l’autre machine avait redémarré et n’avait plus ses anciennes clés. Il pouvait alors effacer l’état précédent. Mais la norme ne disait pas qu’un capteur avait observé le redémarrage. Elle décrivait une déclaration et une décision locale fondée sur une hypothèse.

Cette distinction explique RFC 2407, publiée en novembre 1998. ISAKMP fournissait des échanges et des formats génériques. Le Domain of Interpretation IPsec leur donnait un sens commun : le DOI 1, les bits de Situation, les types d’identité, les numéros de protocoles et de transforms, les attributs de SA et les notifications privées au domaine.

Le registre résolvait les collisions sémantiques. Deux produits indépendants pouvaient reconnaître PROTO_IPSEC_ESP, un identifiant FQDN ou un attribut de durée. Ils ne devaient plus deviner quelle table interprétait l’octet. Cette victoire d’interopérabilité restait volontairement plus étroite qu’une décision de sécurité.

La Situation comportait trois bits : identité seule, secret étiqueté et intégrité étiquetée. L’identité était obligatoire ; une négociation de phase I dépourvue d’Identification Payload devait être abandonnée. Les deux situations étiquetées ajoutaient un identifiant de domaine, un niveau et des catégories.

Or l’identifiant de domaine ne contenait pas la politique. Il désignait l’espace dans lequel les niveaux et catégories étaient censés exister. L’IANA pouvait attribuer ce nombre sur demande, sans documentation obligatoire. La valeur empêchait deux espaces de porter le même numéro public. Elle ne garantissait pas que deux organisations appliqueraient la même règle à une même catégorie.

La norme disait ensuite ce que les tableaux de conformité oublient souvent : le DOI IPsec n’imposait aucune politique particulière. Les questions de politique de l’hôte se trouvaient hors périmètre. Une implantation minimale pouvait utiliser des adresses et des masques ; une autre, des noms génériques, une direction et une passerelle mandataire. Le réseau partageait la grammaire, pas le livre de décisions.

L’identité suivait le même principe. L’Identification Payload pouvait porter une adresse, un sous-réseau, une plage, un FQDN, un nom d’utilisateur, un nom ASN.1 ou un identifiant de clé opaque. Ces données aidaient le répondant à choisir sa politique. Elles n’étaient pas toutes des preuves de même nature.

RFC 2407 demandait que les identités utilisées par la politique soient contenues dans le certificat lorsque le certificat authentifiait l’échange. C’était le joint nécessaire entre une chaîne d’octets et une autorité. ID_KEY_ID, au contraire, pouvait rester un sélecteur opaque et propre au fournisseur pour choisir une clé prépartagée. Le type était commun ; sa signification restait locale.

Les propositions n’échappaient pas à cette séparation. ISAKMP pouvait négocier simultanément plusieurs suites de phase II. RFC 2407 nommait ISAKMP, AH, ESP et IPComp, puis précisait que leur combinaison relevait de la politique de l’hôte. Un transform pouvait en outre dépendre d’un attribut d’authentification précis ; d’autres associations étaient indéfinies.

Accepter une proposition ne prouvait donc pas que le noyau avait installé la SA, que le sélecteur avait capturé le bon trafic ou que l’application avait reçu un résultat utile. Cela prouvait une décision dans la négociation. Le chemin d’exécution commençait ensuite.

Les notifications montraient même les décisions du répondant comme des faits séparés. RESPONDER-LIFETIME annonçait la durée réellement choisie. REPLAY-STATUS pouvait dire si le répondant avait activé l’anti-rejeu. Un numéro de séquence dans un paquet ESP n’apportait pas cette réponse ; la politique du récepteur la déterminait.

La protection de ces notifications dépendait de leur emplacement. Elles étaient interdites dans Aggressive Mode, qui ne fournissait pas la liaison nécessaire. Main Mode n’offrait qu’une protection partielle à certains emplacements, tandis que Quick Mode incluait entièrement la notification dans le condensat. Le même code sémantique n’avait pas toujours la même force probante.

Revenons à INITIAL-CONTACT. Une console moderne pourrait traduire le code en « pair redémarré » et déclencher un nettoyage automatique. Ce libellé ajouterait une certitude absente du protocole. Le pair avait déclaré un premier contact. Le récepteur pouvait agir. L’exploitation devait conserver la déclaration, l’identité authentifiée, les anciennes SA examinées, la règle de suppression et le résultat.

La lecture de Lu Heng sur les couches de réalité fournit ici une discipline. Le numéro enregistré appartient à la couche symbolique. Le payload appartient à la couche des messages. L’authentification établit une liaison. La politique autorise. Le noyau exécute. Le trafic et l’application produisent enfin des effets. Aucun étage ne peut emprunter le reçu du suivant.

L’agence est également distribuée. L’IANA garantit l’unicité des numéros. L’autorité de certification parle pour une identité. Le démon IKE négocie. La politique locale décide. Le noyau installe et traite. L’équipe d’audit conserve ou perd la mémoire. « IKE réussi » attribue à un seul voyant le travail de tous ces mandataires.

RFC 4306 a remplacé en 2005 les trois documents séparés RFC 2407, 2408 et 2409 par IKEv2. En 2023, l’IESG a classé le trio comme Historic, après le déploiement large d’IKEv2 et une longue absence de nouveaux travaux IKEv1. RFC 7296 a depuis porté IKEv2 au rang d’Internet Standard.

L’intérêt historique de RFC 2407 n’est donc pas de remettre ses algorithmes en service. Il est de voir une norme qui savait où s’arrêter. Elle a rendu des nombres communs sans prétendre que le registre était une politique, que l’identité déclarée était déjà liée, ou qu’une négociation achevée était un résultat opérationnel.

Sources