Résumé

  • Quick Mode protégeait trois messages sous l’association ISAKMP de phase 1. HASH(1) liait l’offre et le nonce de l’initiateur, HASH(2) la sélection et le nonce du répondant, puis HASH(3) apportait au répondant une preuve finale de vivacité.
  • Cette dernière preuve était directionnelle. Le protocole de base ne renvoyait pas de quatrième accusé à l’initiateur et ne plaçait dans aucun hash le résultat d’une écriture de SA, l’activation de sélecteurs, un compteur de paquets ou un résultat applicatif.

Le répondant savait davantage à la fin de Quick Mode que l’initiateur. Cette asymétrie ne provenait pas d’une faiblesse mathématique. Elle venait simplement du sens du dernier message.

L’initiateur envoyait HASH(3). Le répondant le recevait. S’il le vérifiait, il apprenait que l’initiateur connaissait les deux nonces et possédait encore l’état secret de la phase 1. L’initiateur, lui, n’obtenait pas de message suivant lui prouvant que cette vérification avait eu lieu.

RFC 2409 construisait IKE sur une séparation antérieure. RFC 2408 définissait un cadre de messages et d’associations de sécurité sans imposer une méthode unique d’échange de clés. RFC 2407 donnait au domaine IPsec son vocabulaire de propositions et de transformations. IKE réunissait ces pièces avec les mécanismes d’Oakley et de SKEME pour créer des échanges concrets.

La première phase établissait une association ISAKMP bidirectionnelle et authentifiée. Main Mode devait être pris en charge, Aggressive Mode était recommandé. Les deux produisaient du matériel de clé authentifié à partir d’un échange Diffie-Hellman éphémère, mais ils n’exposaient ni ne protégeaient les identités de la même manière.

La seconde phase ne recommençait pas tout. Quick Mode réutilisait l’association de phase 1 pour négocier des SA non-ISAKMP, notamment celles destinées à AH ou ESP. Cette économie permettait plusieurs négociations courtes sous un canal parent coûteux à établir.

Les coordonnées reflétaient cette hiérarchie. La paire de cookies désignait l’association ISAKMP. Un Message ID distinct désignait une instance de Quick Mode. Le premier vecteur d’initialisation de cette instance dépendait du dernier bloc chiffré de phase 1 et de ce Message ID. Des Quick Modes concurrents pouvaient ainsi garder des chaînes IV indépendantes.

Le Message ID localisait un état; il n’accordait pas de pouvoir. Son inclusion dans les hash liait l’état sélectionné au transcript authentifié. Cela renforçait la preuve sur cette négociation sans transformer quatre octets en identité, en règle d’autorisation ou en reçu de noyau.

Le premier message contenait HASH(1), une offre SA et le nonce Ni. Il pouvait aussi contenir un nouvel échange Diffie-Hellman et les identités clientes IDci et IDcr. Toutes les charges utiles après l’en-tête ISAKMP étaient chiffrées sous la SA de phase 1.

HASH(1) couvrait le Message ID et la totalité du message qui suivait le hash, en incluant les en-têtes de charges utiles et en excluant le remplissage de chiffrement. Le répondant pouvait donc vérifier que le détenteur de l’état authentifié avait proposé ces paramètres précis dans cette instance précise.

Cette vérification ne décidait pas si la politique locale accepterait l’offre. Elle ne prouvait pas qu’un pilote, un noyau ou un accélérateur pouvait installer le résultat. Elle authentifiait une proposition, pas son effet.

Le deuxième message transportait HASH(2), la sélection SA et Nr. Le calcul ajoutait le nonce de l’initiateur avant le reste de la réponse. Le document qualifiait cette inclusion de preuve de vivacité. Le répondant liait ainsi son choix à un défi frais reçu dans le premier message.

Après vérification, l’initiateur savait que le détenteur de l’état de phase 1 avait lu son offre, utilisé Ni, choisi des paramètres et fourni Nr. Les deux côtés pouvaient calculer le même matériel de clé candidat si leurs interprétations des propositions concordaient.

Restait le troisième message. HASH(3) était calculé sur un octet zéro, le Message ID, Ni et Nr. Cette construction ne répétait pas les propositions. Elle prouvait au répondant que l’initiateur avait reçu son nonce et pouvait encore calculer sous l’état authentifié.

La valeur du hash était symétriquement calculable, mais sa réception ne l’était pas. Le répondant obtenait le dernier élément. L’initiateur ne recevait pas une quatrième affirmation protégée disant: « j’ai vérifié HASH(3) ».

Constater cette absence n’est pas accuser IKEv1 de promettre ce qu’il ne promettait pas. RFC 2409 définit un échange à trois messages. On en déduit seulement que le transcript de base ne contient pas un accusé bilatéral de sa propre clôture. D’autres observations pouvaient compléter le tableau, mais elles demeuraient d’autres observations.

RFC 2408 proposait par ailleurs le bit Commit et le message CONNECTED pour réduire certains écarts de préparation. Ce mécanisme possédait sa propre possibilité de perte du dernier message et sa propre logique de récupération. Il éclaire la difficulté, mais il n’est pas le sujet possédé par cet article.

Même un accusé supplémentaire n’aurait pas prouvé à lui seul l’installation dans deux noyaux. IKE négociait. AH ou ESP traitaient ensuite les paquets à partir d’un état local: SPI, algorithmes, clés, durées, sélecteurs, fenêtres de rejeu, routes, interfaces et parfois matériel spécialisé.

La réception d’un message par le démon n’est pas le retour réussi d’une opération d’installation. Le retour réussi d’une opération d’installation n’est pas un paquet protégé. Un paquet protégé n’est pas encore un service utile. Chaque passage ajoute un propriétaire et un type de preuve.

Les nonces avaient une mission réelle. Ils renouvelaient le matériel et empêchaient une répétition d’anciens messages de créer des SA frauduleuses. Sans charge utile KE dans Quick Mode, KEYMAT était dérivé de SKEYID_d, du protocole, du SPI, de Ni et de Nr.

Ce renouvellement n’offrait pas la PFS propre aux clés de phase 2. Il réutilisait le secret issu de l’exponentiation de phase 1. Avec une charge utile KE, un nouveau Diffie-Hellman ajoutait son secret partagé à la dérivation et fournissait la PFS aux nouvelles clés.

L’option KE devait être prise en charge, sans devoir être utilisée dans chaque négociation. Sa présence imposait aussi de la cohérence: le groupe Diffie-Hellman devait apparaître dans chaque transformation de chaque proposition concernée.

La PFS ne se confond pas avec l’installation. Elle limite l’exposition historique des clés lors d’une compromission ultérieure. Elle ne dit rien sur l’écriture d’une entrée SAD, le rattachement d’un sélecteur SPD, la programmation d’un accélérateur ou le passage du premier paquet.

Les identités clientes optionnelles rendaient la frontière politique encore plus nette. L’identité du pair authentifié en phase 1 pouvait être celle d’une passerelle, alors que IDci et IDcr décrivaient les flux ou sujets bénéficiaires. Les identités, si elles étaient présentes, devaient s’appliquer à toutes les SA négociées ensemble.

Une passerelle authentifiée ne recevait pas automatiquement le droit d’ouvrir n’importe quel couple de sous-réseaux. La politique locale restait souveraine. Le hash rendait l’offre attribuable au contexte cryptographique; il ne rendait pas la demande légitime dans l’organisation du répondant.

Les propositions pouvaient regrouper plusieurs SA et transformations. Le répondant choisissait selon sa politique. HASH(2) authentifiait ce choix. HASH(3) confirmait au répondant que l’initiateur avait vu la réponse. Aucun de ces calculs n’absorbait la réussite d’un composant d’exécution situé après IKE.

Les règles d’IV montrent que RFC 2409 savait déjà distinguer réception et progression. Pour les messages suivants d’un Quick Mode, le dernier bloc chiffré du message précédent devenait l’IV. Mais une implémentation ne devait pas avancer son IV avant qu’un message déchiffré ait passé les contrôles de base et fasse réellement progresser la machine d’état.

Une retransmission pouvait être cryptographiquement valide sans être une nouvelle étape. Un message forgé avec des cookies valides ne devait pas désynchroniser le chiffrement. L’implémentation devait donc distinguer octets reçus, déchiffrement réussi, validation syntaxique, progression de l’échange et mutation opérationnelle.

UDP rendait cette discipline concrète. Un dernier message pouvait se perdre. L’absence de trafic ou d’un autre signal pouvait déclencher une retransmission. Le récepteur devait reconnaître l’ancien message et répondre sans doubler les effets locaux.

Un tableau de bord qui affiche « établi » dès l’émission de HASH(3) choisit un point de vue: celui de l’initiateur. Un autre qui attend sa vérification choisit celui du répondant. Aucun ne peut honnêtement appeler ce seul événement « les deux noyaux sont prêts ».

La grille des couches de réalité de Lu Heng empêche ce glissement. Le Message ID appartient à la corrélation. Les hash appartiennent au transcript authentifié. KEYMAT appartient à la dérivation. La décision de politique appartient à l’autorité locale. L’entrée SAD appartient au code en fonctionnement. Le compteur ESP appartient au traitement de paquets. Le résultat applicatif appartient au service.

Le problème d’agence se trouve dans les jointures. L’autorité de certification ou de secrets prépartagés contrôle l’identité de phase 1. L’équipe sécurité contrôle les sélecteurs autorisés. Le démon IKE contrôle l’échange. Le noyau contrôle les SA. L’exploitation observe le trafic. L’application juge l’utilité. Le succès d’un agent ne mandate pas le suivant.

La spécification minimale commune laissait volontairement ces décisions locales. L’interopérabilité exigeait les formats, les calculs et l’ordre des messages. Elle n’exigeait pas une base de politique mondiale ni une méthode unique pour programmer chaque système. Cette liberté crée l’obligation de conserver des reçus locaux.

La primauté du code en fonctionnement indique quoi conserver: cookies, Message ID, empreinte du credential de phase 1, résultats d’authentification, Ni, Nr, groupes et valeurs KE, propositions, SPIs, résultats de HASH(1-3), version de politique, appels d’installation, identifiants des SA exécutables, sélecteurs, compteurs et test applicatif.

Avec ces preuves, une panne retrouve sa couche. Si le répondant n’a jamais reçu HASH(3), le transcript n’est pas clos de son côté. Si les deux démons sont clos mais qu’une SA manque dans un noyau, l’installation a échoué. Si les deux SA comptent des paquets mais que le service reste absent, l’échec se situe après IPsec.

RFC 2409 a été publié en novembre 1998. RFC 4109 a ensuite actualisé les exigences algorithmiques d’IKEv1. RFC 4306 a remplacé la famille séparée 2407/2408/2409 par IKEv2. RFC 7296 est devenu l’Internet Standard IKEv2. En 2023, l’IESG a placé IKEv1 dans la catégorie Historic et RFC 9395 a déprécié IKEv1 et fermé les registres associés.

Le protocole est historique; la faute de raisonnement reste actuelle. Une preuve reçue par un côté ne devient pas une preuve de l’état des deux machines. Le troisième hash renseignait le répondant. Il ne confirmait pas les deux noyaux.

Sources