Résumé

  • La GPAD de la RFC 5374 authentifie un GCKS puis limite séparément les identifiants de groupe et les sélecteurs de trafic qu’il peut imposer.
  • Un MAC calculé avec une clé partagée prouve la possession d’un secret de groupe, pas l’identité du membre précis qui a émis le paquet.
  • La conservation des adresses dans le tunnel protège une cohérence utile au routage multicast ; elle ne prouve ni l’auteur humain ni la réception applicative.

Un certificat n’était pas une juridiction universelle

Le Group Controller/Key Server distribue politique et matériel de clé. Ce pouvoir est considérable : une règle acceptée peut décider quels paquets sont protégés, rejetés ou laissés en clair. La RFC 5374 refuse donc qu’une authentification réussie transforme automatiquement le contrôleur en autorité sans limites.

Chaque membre conserve une Group Peer Authorization Database. L’entrée GPAD nomme le ou les GCKS reconnus, leur mécanisme d’authentification, les données de confiance, les identifiants de groupe dont ils peuvent s’occuper et les plages de sélecteurs qu’ils peuvent annoncer. La chaîne de décision reste locale même si la distribution des clés est centralisée.

Lors de l’enregistrement, le membre vérifie l’identité déclarée du GCKS. Avant de lui présenter un Group Identifier, il vérifie que ce groupe figure dans son mandat. Puis chaque flux reçu est comparé aux sources et destinations autorisées. Une politique hors périmètre est écartée et la cause devrait être journalisée.

Cette séquence produit quatre preuves distinctes : le pair contrôlait un identifiant accepté ; cet identifiant pouvait agir pour le groupe ; la proposition se situait dans les sélecteurs permis ; l’équipement a effectivement installé la règle. La seule réussite TLS, certificat ou secret prépartagé ne remplace aucune des trois autres.

La clé commune créait une classe d’auteurs possibles

Le même principe vaut pour les paquets. Avec deux parties, un MAC partagé peut souvent être interprété comme venant de l’autre détenteur. Dans un groupe, tous les membres possèdent la clé d’authentification. Tous peuvent produire le même type de tag valide.

La RFC 5374 appelle cela authentification de source de groupe. Le résultat exclut utilement l’extérieur qui ignore le secret et détecte une modification non autorisée. Mais il ne discrimine pas le véritable Group Sender parmi les membres admis. Une adresse source n’ajoute pas magiquement cette preuve : un initié muni de la clé peut fabriquer un paquet qui ressemble à celui d’un pair.

Pour une origine individuelle, le texte renvoie à une signature numérique ou à TESLA. Ce contrôle possède d’autres clés, d’autres hypothèses temporelles et un autre coût. La RFC envisage même deux enveloppes : un MAC de groupe peu coûteux rejette les intrus avant une vérification d’origine plus chère. Deux voyants verts ne doivent pas fusionner dans le journal ; ils attestent deux propriétés.

La fraîcheur reste séparée. Plusieurs émetteurs utilisent normalement des SA distinctes afin de garder un état anti-rejeu par source. Partager une SA entre eux n’est compatible qu’avec l’abandon de ce service IPsec. Dans un très grand groupe any-source, suivre chaque émetteur peut devenir impraticable ; une protection de rejeu exigée à cette échelle doit remonter vers un protocole applicatif capable de la porter.

Une adresse conservée restait une donnée de routage

Un tunnel IPsec ordinaire place ses extrémités dans l’en-tête externe. Le multicast a besoin de voir l’adresse du groupe, et les arbres source-spécifiques ou le contrôle RPF peuvent dépendre de la source. Le mode tunnel avec conservation d’adresse recopie donc la destination interne et, selon la politique, la source interne dans l’en-tête externe.

À l’arrivée, toute valeur marquée comme conservée doit être égale à sa valeur interne. Sinon le paquet est rejeté et l’écart devient un événement auditable. C’est une preuve de cohérence d’encapsulation. Elle empêche qu’un groupe soit visible pour le routage alors qu’un autre est livré sous protection.

Elle ne prouve pas que l’adresse appartient légitimement à un appareil, qu’une personne donnée a émis les octets ou qu’un récepteur les a présentés. La conservation de la source peut même empêcher la passerelle de recevoir certains messages ICMP Path MTU qui lui auraient été destinés. La propriété sert le chemin ; elle ne devient pas une identité.

Le cas SSM rend la temporalité visible. NAT, mobilité ou multihoming peuvent déplacer la source pendant la vie du groupe. Une ancienne règle GSPD risque alors de ne plus couvrir le nouveau localisateur. Au pire, une règle BYPASS laisse sortir les données sans protection. La RFC recommande un rejet par défaut pour toute source non autorisée vers cette destination SSM.

Le membre le plus faible bornait le groupe

La cryptographie de groupe amplifie les conséquences d’une admission. Un membre compromis peut révéler la clé ou les données. Il peut aussi imiter un pair lorsque seule l’authentification symétrique est employée. La sécurité n’est donc pas la moyenne des terminaux ; elle est bornée par le plus faible détenteur du secret.

Le routage multicast ajoute encore une frontière. Un join IGMP ou MLD peut déclencher une inscription auprès du GCKS, mais ce signal de topologie n’est pas un droit applicatif. Inversement, avoir les clés ne garantit pas que tous les routeurs ont transmis le paquet. Les systèmes intermédiaires ne participent pas nécessairement à IPsec ; suppression, corruption de chemin et inondation restent possibles.

Enfin, sender only, receiver only et symmetric existent parce qu’un groupe n’hérite pas de la symétrie d’une conversation unicast. Lire n’accorde pas le droit d’émettre. Émettre n’accorde pas forcément le droit de recevoir. Un registre qui ne retient que « membre actif » détruit le rôle sur lequel l’autorisation reposait.

Frontière de preuve

Un dossier exploitable conserve séparément l’identité et la preuve du GCKS, l’entrée GPAD applicable, le groupe demandé, les sélecteurs proposés et la décision locale. Il relie ensuite le rôle du membre, le GSA, les SA, le SPI, l’algorithme, l’époque de clé et l’état anti-rejeu.

Pour chaque paquet, il distingue la validation par clé commune de toute signature ou preuve TESLA. Il garde les adresses internes et externes ainsi que le résultat de leur comparaison. Les observations de routage, accusés de réception applicatifs, validation du contenu et conséquence métier suivent des lignes séparées.

La formule publique reste alors exacte : le paquet était valide pour une politique et une époque de groupe données. Désigner un auteur précis demande une preuve supplémentaire.