Résumé

  • Dans la séquence de référence de RFC 9838, la modification des membres renouvelle d’abord la KEK ; une seconde opération distribue ensuite la politique et les clés TEK sous la nouvelle KEK. Le retrait administratif et l’exclusion cryptographique sont deux événements.
  • Le message multicast GSA_REKEY n’est pas acquitté et peut se perdre. Les copies chiffrées identiques et GSA_NEXT_SPI réduisent le risque sans fournir l’état installé de chaque destinataire.
  • Les délais ATD et DTD organisent volontairement le passage entre nouvelles et anciennes associations de sécurité. Toute promesse d’exclusion doit mesurer cette période au lieu de l’effacer derrière l’heure du ticket.

À 10 heures, le registre des membres ne contenait plus son nom. Ce constat dit qui était autorisé. Il ne dit pas encore quelle clé la machine détenait ni jusqu’à quand elle pouvait parler au groupe.

RFC 9838 normalise G-IKEv2, la gestion de clés de groupe fondée sur IKEv2. Sa notice RFC Editor date le texte de novembre 2025, le classe Standards Track et indique qu’il remplace RFC 6407. Ce statut prouve la maturité du document, pas l’exécution d’une révocation réelle.

L’architecture découle des travaux MSEC décrits par RFC 3740, RFC 4046 et RFC 5374. Un GCKS, contrôleur et serveur de clés, authentifie et autorise un membre. Il lui remet ensuite une association de sécurité de groupe, avec les politiques et clés des SA de données et, le cas échéant, une SA de renouvellement multicast.

L’inscription constitue le premier état ; le renouvellement le transforme. IKEv2 apporte la relation bilatérale, tandis que l’architecture IPsec, AH et ESP fournissent les associations et protections de paquets. Le défi propre au groupe est que tous les membres ne répondent pas à la même émission.

Pourquoi l’ancienne KEK ne peut pas porter la nouvelle TEK

Le contrôle d’accès vers l’avant empêche un membre exclu d’obtenir une nouvelle clé de groupe. Le contrôle vers l’arrière empêche un nouvel arrivant d’obtenir une ancienne clé. RFC 9838 précise que ces propriétés ne sont pas la Perfect Forward Secrecy d’IKEv2.

Lorsqu’un message change la composition du groupe, il reste lisible par les détenteurs de l’ancienne KEK. Y joindre immédiatement la nouvelle politique TEK et ses clés les révélerait donc au membre que l’on retire. Pour préserver l’accès vers l’avant, le message de changement de membres ne doit pas contenir ce matériel. Un second renouvellement peut l’apporter sous la nouvelle KEK.

Si même la nouvelle politique doit rester secrète pour l’exclu, le GCKS envoie deux renouvellements successifs qui modifient chacun la KEK. Le premier établit une clé que le membre retiré ne reçoit pas, même s’il voit encore la politique véhiculée sous l’ancienne. Le second change de nouveau la KEK et transporte la politique nouvelle. La norme interdit de modifier la politique sans créer une nouvelle KEK.

Cette discipline vaut pour la méthode décrite, non pour tout algorithme imaginable. Le texte autorise de futures méthodes, notamment des variantes de hiérarchie logique, à n’utiliser qu’un message si elles expliquent comment elles conservent le contrôle d’accès. RFC 2627 donne le contexte LKH. La conclusion opérationnelle reste nette : un écran ne doit pas fusionner le retrait, la nouvelle KEK et la nouvelle TEK en un seul statut vert.

Une émission multicast n’est pas un inventaire d’installation

G-IKEv2 propose un renouvellement unicast en bande ou le pseudo-échange multicast GSA_REKEY. Ce dernier est à sens unique et sans acquittement. Une perte réseau suffit à laisser un membre légitime sur l’ancien état.

Le serveur peut envoyer plusieurs copies chiffrées strictement identiques, dans un intervalle de quelques secondes, pour limiter les pertes sans fausser les durées de vie des SA. Avec GSA_NEXT_SPI, il peut également annoncer les SPI attendus et permettre à un membre attentif de détecter un trou puis de se rétablir.

Ces mécanismes augmentent la probabilité de réception ; ils ne la transforment pas en certitude auditée. La trace « envoyé trois fois » ne signifie pas « installé partout ». Une alerte de SPI futur atteste qu’un terminal a vu une discontinuité, pas que tous les autres ont convergé.

La fragmentation rend cette absence de retour encore plus concrète. Avec RFC 7383, le GCKS multicast ne peut ni tester d’abord un paquet non fragmenté, ni utiliser un mécanisme PMTU fondé sur les réponses. Il doit appliquer un seuil préconfiguré. La taille du groupe, la hiérarchie de clés et la croissance du message deviennent ainsi des paramètres de la révocation.

Le chevauchement a deux horloges

L’ATD indique combien de temps les émetteurs attendent avant d’utiliser les nouvelles SA. Le DTD indique combien de temps les membres attendent avant de supprimer les anciennes SA après une demande. Ces délais protègent la disponibilité pendant que l’état se propage, mais ils créent une fenêtre où « exclu » dépend de l’horloge observée.

Un dossier probant distingue au moins la révocation d’autorisation, la création de la KEK, l’installation de la TEK, l’activation de la nouvelle SA et la suppression de l’ancienne. Un test de trafic ajoute l’instant où l’ancien membre a participé pour la dernière fois.

Les modes à compteur imposent un registre supplémentaire. En s’appuyant sur RFC 6054, RFC 9838 exige des Sender-ID propres à chaque émetteur et de nouveaux identifiants à chaque inscription, car le GCKS ignore quels nonces ont déjà servi. À épuisement, il doit exclure tous les membres et imposer une réinscription avec de nouvelles SA. Les exigences d’algorithme de RFC 8221 et les IV implicites de RFC 8750 n’annulent pas cette obligation d’état.

La protection anti-rejeu est elle aussi locale. Plusieurs émetteurs partageant une SA avancent leurs numéros de séquence indépendamment ; une fenêtre commune fiable peut devenir impossible. Le récepteur décide de vérifier ou non les rejouements. Le GCKS peut isoler les émetteurs dans des SA séparées, au prix d’une plus grande échelle opérationnelle.

Le registre IANA d’IKEv2 consigne les valeurs attribuées, et RFC 8174 fixe la portée des mots normatifs. Aucun des deux ne décrit l’état installé d’un parc. RFC 6407, désormais remplacée, éclaire l’héritage sans certifier G-IKEv2.

Le principe de Heng Lu d’une spécification initiale minimale et de décisions futures localisées place correctement la frontière : la norme définit la transition sûre ; l’opérateur fixe son délai acceptable et produit les preuves. La primauté du code en fonctionnement donne plus de poids à la clé installée et au trafic observé qu’au ticket fermé. Le reporting fondé sur la réalité interdit de vendre un RFC Standards Track comme une garantie déjà déployée.

Sources