Résumé

  • Dans RFC 2408, les deux cookies repéraient l’association ISAKMP et limitaient certains coûts d’attaque ; le Message ID suivait une négociation de phase 2. Aucun de ces champs ne remplaçait l’authentification forte.
  • La preuve complète devait encore relier le message à un justificatif d’identité, une règle locale, un choix de proposition, l’installation de la SA, le traitement des paquets et un résultat observable. Même CONNECTED ou Delete n’attestait qu’une étape bornée.

Le cas le plus instructif n’est pas celui d’un cookie invalide. C’est celui d’un cookie parfaitement valide.

Le destinataire recalcule la valeur avec son secret local, l’adresse, les ports et la matière temporelle. Le test réussit. Le paquet appartient vraisemblablement à un état que le serveur sait reconnaître. Pourtant le nom du pair, son certificat, son droit à demander cette association et l’effet final ne sont pas encore établis.

RFC 2408 appelait le cookie un jeton anti-engorgement. Sa fonction première était économique : éviter de consacrer trop de calcul à un demandeur qui pouvait usurper une adresse. La fonction devait être rapide ; seul l’émetteur devait pouvoir produire une valeur acceptée ; le résultat devait dépendre des parties et varier à chaque établissement de SA.

Cette construction résistait à certaines attaques. Elle ne supprimait pas le déni de service. Le texte exigeait aussi une collecte des états abandonnés, car un attaquant pouvait toujours pousser un serveur à créer de la mémoire avec des paquets forgés. Le cookie ne promettait donc ni disponibilité absolue, ni chemin durable, ni identité.

Une fois le dialogue engagé, la paire Initiator Cookie et Responder Cookie devenait l’identifiant de l’association ISAKMP. Le premier message portait le cookie de l’initiateur ; celui du répondant et le Message ID restaient à zéro. La réponse ajoutait le second cookie. Après la phase 1, la paire suivait les communications suivantes.

Le vocabulaire « cookie de l’entité » pouvait tromper un lecteur moderne. Il ne s’agissait pas d’un nom public ou d’une preuve de personne. C’était une valeur émise localement pour retrouver une association. RFC 2408 imposait ailleurs une authentification forte et précisait que l’identification d’une entité ne pouvait être crue sans elle.

L’ordre fournit le meilleur guide de preuve. Le serveur pouvait valider son cookie avant d’avoir fini l’échange d’authentification. Le journal devait donc conserver deux verdicts : « le jeton correspond à mon état » et « la méthode convenue lie ce pair à ce justificatif ». Les fusionner rendrait invisible une usurpation qui franchit le premier contrôle mais pas le second.

Le Message ID appartenait à une portée encore différente. Il était nul pendant la phase 1. Pendant la phase 2, l’initiateur le choisissait aléatoirement pour repérer l’état du protocole. Deux négociations lancées presque simultanément sous la même association ISAKMP pouvaient ainsi avancer sans confondre leurs réponses.

La paire de cookies nommait donc le contexte parent. Le Message ID nommait une négociation enfant. Les SPI des propositions nommaient les associations de protocole en cours de création. Une fois l’établissement achevé, les paquets ESP ou AH utilisaient leurs propres SPI pour sélectionner l’état d’exécution. Quatre identifiants, quatre portées.

Un outil qui affiche seulement « session IKE 42 » perd cette architecture. Il ne permet plus de savoir si une collision concerne le parent, une négociation de phase 2, une proposition ou la SA effectivement utilisée par les paquets. L’observabilité doit respecter les frontières du protocole, non les aplatir.

Le reste de l’en-tête fixe formait une grammaire. Exchange Type déterminait l’ordre des messages et charges. Next Payload indiquait la première charge ; chaque en-tête générique indiquait la suivante. Version, drapeaux et longueur fixaient d’autres conditions de lecture.

Le récepteur vérifiait successivement cookies, Next Payload, version, type d’échange, drapeaux et Message ID. Un échec entraînait le rejet. La consignation et l’envoi d’une notification restaient souvent facultatifs et soumis à la politique locale. Une spécification commune de l’erreur ne garantissait donc pas un journal commun.

Cette nuance compte dans l’incident. Une alerte INVALID-MESSAGE-ID peut montrer qu’un nœud a reconnu une incohérence. Elle ne montre pas que le pair a reçu l’alerte, que l’association parent était authentique, que la règle locale était la bonne ou que l’état orphelin a été nettoyé. Il faut relier message, décision et mutation.

La chaîne de charges rendait ISAKMP modulaire. SA, Proposal, Transform, Key Exchange, Identification, Certificate, Hash, Signature, Nonce, Notification, Delete et Vendor ID pouvaient être combinés selon le type d’échange. Le bénéfice était une ossature commune indépendante d’un algorithme ou d’une méthode d’authentification particulière.

L’indépendance interdisait précisément de confondre ossature et preuve. Un parseur pouvait parcourir une chaîne correcte qui transportait une proposition refusée. Une signature pouvait être syntaxiquement présente mais échouer. Une proposition pouvait être acceptée puis ne jamais atteindre la base SA du noyau. Une SA installée pouvait ne capturer aucun paquet.

RFC 2408 séparait deux phases. La première créait une association ISAKMP et un chemin protégé pour les activités de gestion suivantes. La seconde négociait des associations pour d’autres protocoles. Plusieurs phases 2 pouvaient amortir le coût de la première.

Les sujets authentifiés pouvaient changer entre les phases : serveurs ou hôtes en phase 1, utilisateurs ou programmes en phase 2. La même paire de cookies ne signifiait donc pas nécessairement la même assertion d’identité à tous les étages. L’autorisation devait mentionner le sujet, le justificatif et la phase.

La politique intervenait également dans le choix. L’initiateur pouvait n’offrir qu’une proposition. S’il en offrait plusieurs, le répondant choisissait celle qui convenait à sa politique. Le protocole transportait le menu et la sélection ; il ne décidait pas quelle institution avait le droit d’imposer cette politique.

Le bit Commit révèle le problème opérationnel qui subsistait après le choix. Une partie pouvait exiger que l’autre attende un message Informatif protégé contenant CONNECTED. Le Message ID de la négociation de phase 2 reliait ce signal au bon état.

Mais le dernier message pouvait se perdre. RFC 2408 proposait des réactions sans les normaliser : accepter un trafic protégé vérifiable comme indice d’établissement, ou retransmettre le dernier message. Une implémentation pouvait conserver ce message jusqu’à obtenir plus de certitude. CONNECTED était un mécanisme de synchronisation, pas une preuve infaillible de service.

Delete allait plus loin dans la précision sémantique. La charge déclarait que l’émetteur avait retiré une SA de sa propre base. Ce n’était pas une demande adressée au répondant. Aucun accusé de réception n’était attendu. Le répondant devait normalement nettoyer son état, mais la politique locale décidait la suite.

Une capture contenant Delete atteste donc un avis protégé si sa protection est vérifiée. Elle n’atteste pas la suppression distante. Pour le démontrer, il faut la décision du récepteur, la mutation de base, les sélecteurs touchés, les paquets ensuite refusés et le chemin de rétablissement.

Le cadre montre ainsi plusieurs couches de réalité. Le cookie appartient à la corrélation. Message ID appartient au travail en cours. La chaîne appartient au parseur. Le justificatif et la méthode appartiennent à l’authentification. La proposition appartient à la négociation. La SA appartient à l’état exécutable. Le résultat appartient au réseau et à l’application.

La doctrine de spécification minimale de Lu Heng éclaire ce partage. Un commun suffisant permet aux systèmes de coopérer sans centraliser toutes les décisions. RFC 2408 donnait la forme commune ; DOI et échanges apportaient d’autres sens ; les hôtes gardaient leur politique. Le danger commence lorsqu’un opérateur exige du champ commun qu’il prouve les décisions locales.

Le problème d’agence suit la même trajectoire. L’émetteur du cookie, l’autorité de certification, l’administrateur de politique, le démon, le noyau et l’application agissent pour des responsabilités différentes. Un voyant unique récompense le premier composant qui répond et rend les autres invisibles.

La primauté du code en fonctionnement impose une chaîne vérifiable : paire de cookies, Message ID, transcript d’authentification, empreinte du justificatif, règle locale, choix retourné, résultat d’installation, SPI d’exécution, sélecteurs, compteurs, décision sur le paquet et observation applicative. Le protocole devient alors une source de précision plutôt qu’un alibi.

RFC 2408 date de novembre 1998. RFC 4306 a remplacé le trio 2407/2408/2409 en 2005 avec IKEv2. En 2023, l’IETF a classé la famille IKEv1 Historic ; RFC 9395 a fermé les registres concernés. RFC 7296 est devenu l’Internet Standard IKEv2. Lire RFC 2408 aujourd’hui, c’est étudier une répartition historique des preuves, non recommander ses algorithmes.

Le cookie revenait juste. Cette réussite avait une valeur réelle et limitée. L’identité, la permission, l’installation et l’effet restaient à prouver séparément.

Sources