Résumé

  • draft-smyslov-ipsecme-ikev2-psp-02 propose d’authentifier d’abord les pairs au sein d’une SA IKEv2 sans Child SA, puis d’échanger dans CREATE_CHILD_SA les clés PSP que chaque récepteur a choisies pour le trafic qui lui sera envoyé.
  • La réponse lie un pair, des sélecteurs, un SPI, des paramètres PSP et une clé enveloppée. Elle ne constate ni l’installation dans le chemin d’émission, ni un paquet protégé, ni la dérivation côté réception, ni la validation de l’ICV.
  • La révocation individuelle n’existe pas dans l’architecture PSP et le rejeu est laissé à une autre couche. La rotation, la migration, l’éviction et le résultat applicatif ont donc besoin de reçus autonomes.

Une rotation commence par créer deux vérités valides

Un tableau de bord annonce « rotation terminée » dès que la nouvelle clé maîtresse devient active. Le message paraît définitif. Dans PSP, il décrit seulement l’époque utilisée pour les nouvelles associations. Les associations existantes peuvent encore dépendre de l’ancienne clé, et le récepteur doit la garder afin de dériver leurs clés à partir des SPI reçus.

La spécification d’architecture PSP l’explique avec une précision utile. Deux clés maîtresses de 256 bits résident côté réception. Le bit de poids fort du SPI désigne celle qui sert à la dérivation. Après une rotation, les nouvelles demandes utilisent la clé désormais active, tandis que l’ancienne reste disponible pour les connexions en cours. Seule une « double rotation » finit par l’évincer. Avant ce deuxième passage, les associations qui en dépendent doivent avoir été recréées.

Le projet draft-smyslov-ipsecme-ikev2-psp-02 donne à IKEv2 un moyen de transporter les clés nécessaires à cette recréation. Il ne montre pas que le basculement a eu lieu. Le distinguer évite de confondre trois événements: la nouvelle clé maîtresse devient active, une nouvelle SA PSP est négociée, puis le trafic utilise effectivement cette SA avant que l’ancienne puisse disparaître.

Le récepteur choisit ce que l’émetteur devra installer

PSP cherche à économiser l’état de réception. Au lieu de conserver une clé pour chaque SA entrante, le récepteur la redérive avec son secret maître et le SPI présent dans le paquet. Il est donc le seul à savoir quel SPI correspond à quelle époque et quelle clé doit être utilisée. Il choisit le couple et transmet la clé dérivée à l’autre pair, qui devra l’employer pour émettre vers lui.

Le sens de la remise est facile à inverser dans les journaux. Le pair qui envoie un payload KD ne donne pas une clé pour son propre émetteur. Il fournit le matériel que son interlocuteur utilisera afin d’envoyer du trafic que lui-même recevra. Une communication bidirectionnelle réclame deux SA simples et deux remises symétriques.

RFC 7296 produit normalement le matériel d’une Child SA à partir de secrets et de nonces issus des échanges IKEv2. PSP a besoin d’une valeur contrôlée par le récepteur. Le projet réutilise donc le mécanisme Key Download de RFC 9838, conçu pour distribuer du matériel de groupe, dans un contexte unicast.

Cette réutilisation est une réponse au problème de transport. Elle ne tranche pas le problème d’exécution. Le pair distant peut recevoir une clé enveloppée valide sans que son service local sache encore dans quelle carte, file, table ou description d’émission la poser.

L’authentification précède volontairement la clé sensible

Le déroulé impose d’abord IKE_SA_INIT. Les pairs négocient un Key Wrap Algorithm; le répondant compatible annonce aussi CHILDLESS_IKEV2_SUPPORTED. RFC 6023 permet précisément d’établir une SA IKEv2 sans tenter immédiatement de créer une Child SA.

Le projet interdit de créer la SA PSP pendant IKE_AUTH. À cet instant, l’initiateur devrait envoyer sa clé de réception avant que le répondant soit authentifié. Les pairs terminent donc leur authentification, puis utilisent un CREATE_CHILD_SA modifié.

Cette contrainte protège une frontière réelle. Elle ne transforme pas IKE_AUTH en attestation du matériel. L’identité IKE peut représenter un service de contrôle situé devant plusieurs hôtes, VM, cartes ou accélérateurs. Le certificat ou le secret prouve le pair selon la méthode choisie; il ne nomme pas nécessairement l’objet local qui devra exécuter le chiffrement.

De même, la négociation du Key Wrap Algorithm ne réserve pas la SA IKE à PSP. Le texte indique qu’elle peut aussi créer des SA ESP. Le statut « capacité disponible » doit rester distinct du statut « type de SA demandé », puis du statut « SA installée ».

La réponse CREATE_CHILD_SA ferme un échange, pas une file matérielle

Le message PSP proposé porte un identifiant de protocole encore <TBA>, un transform PSP lui aussi non attribué, des Traffic Selectors, un SPI et un payload Key Download dans chaque direction. Chaque Key Bag lie son SPI à une proposition. L’attribut SA_KEY contient la clé enveloppée par SK_w, calculée à partir de SK_d et de la chaîne « Key Wrap for PSP ».

Ces éléments permettent un journal de contrôle rigoureux. Ils répondent à « qui a déclaré quoi, pour quels sélecteurs, avec quel SPI et quel paramètre ». Ils ne répondent pas à « quel paquet a été traité ». Entre les deux se trouve une interface d’installation que le projet ne spécifie pas.

Le dépôt PSP archivé illustre plusieurs possibilités sans prouver qu’elles sont déployées: clé dans une table de flux sur puce, base de SA en mémoire, ou clé attachée à un descripteur d’émission. Les capacités, acquittements et échecs diffèrent. Un service IKE qui reçoit HTTP 200 de sa propre base ne peut pas certifier la réussite de ces commandes asynchrones.

La preuve minimale de mise en service doit donc associer le SPI reçu à un objet local précis, sans réexposer la clé: identifiant de carte, file ou contexte, empreinte de la commande, résultat du pilote et époque. Ensuite seulement un paquet témoin peut vérifier le passage de l’intention à l’exécution.

« Stateless » ne signifie pas « sans état à auditer »

L’économie de PSP concerne surtout le stockage des clés de réception par SA. Le récepteur conserve toujours deux secrets maîtres, leur rôle actif ou ancien, l’espace de SPI, les durées de vie et le calendrier de rotation. L’émetteur doit conserver ou fournir chaque clé de transmission. Les couches supérieures peuvent maintenir une liste de SPI autorisés pour une socket.

RFC 4301 sépare depuis longtemps la gestion des SA de leur traitement de paquets. RFC 4303 fait de même pour ESP. PSP modifie l’endroit où se trouve une partie de l’état; il ne fusionne pas le plan de contrôle, la carte réseau et l’application.

Cette séparation empêche aussi de transformer les objectifs d’échelle en mesures. La spécification évoque des millions d’associations et des dizaines ou centaines de milliers de mises à jour de clés par seconde comme considérations de conception. Elle ne publie pas le benchmark d’une carte nommée. Une négociation peut rester rapide alors que la table d’émission sature.

Les compteurs commencent là où le projet IKEv2 s’arrête

La spécification PSP demande des compteurs de paquets et d’octets TX/RX traités avec succès, ainsi que des compteurs d’erreur de chiffrement, d’authentification, de format ou de clé maîtresse. Elle prévoit aussi qu’un indicateur de déchiffrement/authentification réussi et le SPI puissent remonter vers le logiciel.

Ce sont des surfaces de preuve différentes. Pour un paquet témoin, le dossier peut contenir la transaction IKE, l’acquittement d’installation TX, le SPI et l’IV émis, l’incrément du compteur TX, l’époque de dérivation RX, la validation ICV, le compteur RX et la réception applicative. Aucun de ces derniers éléments n’est implicitement contenu dans le payload KD.

Un échec devient alors localisable. TX sans RX authentifié oriente vers le chemin, le format, la version, l’époque maîtresse ou l’ICV. RX authentifié sans reçu applicatif déplace l’enquête vers la liste de SPI, le transport ou l’application. Sans ces étapes, « key exchange successful » devient un écran qui cache toutes les causes en aval.

Une nouvelle SA n’abolit pas immédiatement l’ancienne

La notification REKEY_SA peut désigner l’association PSP à remplacer. Dans IKEv2, le schéma général consiste à créer la nouvelle SA, déplacer le trafic, puis supprimer l’ancienne. Une réponse positive prouve la première partie, pas les deux suivantes.

La période de chevauchement doit être rendue visible: premier paquet accepté sur le nouveau SPI, dernier paquet sur l’ancien, changement de sélection d’émission, suppression locale et distante, pertes et réordonnancement. Si le nouveau matériel est installé mais que le classificateur continue de choisir l’ancien objet, le contrôle a réussi sans migration.

La rotation maîtresse ajoute un délai irréductible. PSP ne fournit pas de révocation individuelle des clés dérivées; la spécification dit que la rotation est la méthode d’invalidation. Un état administratif « révoqué » n’est donc pas encore l’éviction cryptographique. Il faut prouver la migration de toutes les SA concernées puis le passage qui rend l’ancienne clé maîtresse inutilisable.

Le rejeu reste une dépendance nommée

PSP n’intègre pas de protection contre le rejeu. Son architecture suppose qu’une couche 4, par exemple TCP, en fournisse une. Le projet IKEv2 ne change pas cette répartition. Une clé fraîche et un paquet authentique ne suffisent pas à prouver qu’un duplicata a été rejeté.

Cela ne signifie pas qu’un déploiement est sans défense. Cela signifie que la défense et son reçu se trouvent ailleurs. Une affirmation de rejet doit nommer la couche, sa fenêtre ou sa règle, le numéro observé et la décision. Le SPI, l’IV et l’ICV ne doivent pas devenir par glissement une preuve de politique anti-rejeu.

La révision 02 renouvelle le document, non ses garanties

L’API Datatracker date la révision 02 du 30 septembre 2026 et fixe son expiration au 3 avril 2027. La page du document la classe comme Internet-Draft individuel actif; l’historique enregistre trois versions.

Le diff avec la révision 01 ne change que les dates, le numéro et les en-têtes. Il ne faut donc pas raconter cette republication comme une nouvelle analyse de sécurité. Le document vise le statut Experimental mais n’a ni numéro RFC, ni stream, ni Area Director responsable. Sa section Security Considerations reste « To be added ».

Les identifiants PSP et le transform demandé restent <TBA>. Le registre IANA IKEv2 fait autorité pour les valeurs attribuées; une demande dans un projet n’est pas une attribution. La publication du texte ne prouve ni implémentation, ni interopérabilité, ni trafic protégé.

Sources et limites

L’analyse s’appuie sur le texte, le HTML et le XML de la révision 02, ses métadonnées Datatracker, RFC 7296, RFC 6023, RFC 9838, RFC 4301, RFC 4303, le registre IANA, le dépôt PSP et sa spécification. Ces sources n’établissent aucune adoption, production, performance, conformité, vulnérabilité, panne ou issue applicative observée.