1. Introduction

Ce document présente un domaine d'interprétation ISAKMP (ISAKMP Domain of Interpretation, DOI) pour la gestion des clés de groupe appelé « domaine d'interprétation de groupe » (Group Domain of Interpretation, GDOI). Dans ce modèle de gestion des clés de groupe, le protocole GDOI s'exécute entre un membre du groupe et un « contrôleur de groupe/serveur de clés » (Group Controller/Key Server, GCKS), qui établit des associations de sécurité (Security Associations) [Section 4.6.2 RFC2401] entre les membres autorisés du groupe. ISAKMP définit deux « phases » de négociation [p.16 RFC2408]. Le GDOI doit (MUST) être protégé par une association de sécurité de phase 1. Ce document intègre la définition de l'association de sécurité (SA) de phase 1 du DOI Internet [RFC2407, RFC2409]. D'autres types possibles d'associations de sécurité de phase 1 sont notés dans l'annexe A. L'échange de phase 2 est défini dans ce document et propose de nouvelles charges utiles (Payloads) et échanges (Exchanges) selon la norme ISAKMP [p. 14 RFC2408].

Il y a six nouvelles charges utiles :

1. GDOI SA
2. SA KEK (SAK), qui suit la charge utile SA
3. SA TEK (SAT), qui suit la charge utile SA
4. Tableau de téléchargement de clés (Key Download Array, KD)
5. Numéro de séquence (Sequence Number, SEQ)
6. Preuve de possession (Proof of Possession, POP)

Il y a deux nouveaux échanges.

1) Un échange de phase 2 crée des SA de re-clé et de protocole de sécurité des données.

Le nouvel échange de phase 2, appelé « GROUPKEY-PULL », télécharge les clés pour la SA de « re-clé » (Re-key) et/ou la SA de « sécurité des données » (Data-security) d'un groupe. La SA de re-clé comprend une clé de chiffrement de clés (Key Encrypting Key, KEK) commune au groupe ; une SA de sécurité des données comprend une clé de chiffrement de données (Data Encryption Key, TEK) utilisée par un protocole de sécurité des données pour chiffrer ou déchiffrer le trafic de données [Section 2.1 RFC2407]. La SA pour le KEK ou le TEK comprend des clés d'authentification, des clés de chiffrement, une politique cryptographique et des attributs. L'échange GROUPKEY-PULL utilise un comportement « pull » puisque le membre initie la récupération de ces SA à partir d'un GCKS.

2) Un datagramme établit ensuite des SA de re-clé et/ou de protocole de sécurité des données supplémentaires.

Le datagramme GROUPKEY-PUSH est « poussé » (pushed) du GCKS vers les membres pour créer ou mettre à jour une SA de re-clé ou de sécurité des données. Une SA de re-clé protège les messages GROUPKEY-PUSH. Ainsi, un GROUPKEY-PULL est nécessaire pour établir au moins une SA de re-clé afin de protéger les messages GROUPKEY-PUSH ultérieurs. Le GCKS chiffre le message GROUPKEY-PUSH en utilisant la SA de re-clé KEK. Le GDOI accommode l'utilisation de tableaux de KEK pour les algorithmes de gestion des clés de groupe utilisant l'algorithme de hiérarchie de clés logiques (Logical Key Hierarchy, LKH) pour ajouter et supprimer efficacement des membres du groupe [RFC2627]. L'implémentation de l'algorithme LKH est optionnelle (OPTIONAL).

Bien que le GROUPKEY-PUSH spécifié par ce document puisse (CAN) être utilisé pour rafraîchir une SA de re-clé, l'utilisation la plus courante de GROUPKEY-PUSH est d'établir une SA de sécurité des données pour un protocole de sécurité des données. Le GDOI peut (CAN) accommoder des extensions futures pour prendre en charge une variété de protocoles de sécurité des données. Ce document spécifie uniquement les SA de sécurité des données pour un protocole de sécurité, IPsec ESP. Une RFC distincte spécifiera la prise en charge d'autres protocoles de sécurité des données tels qu'un futur protocole de transport en temps réel sécurisé (Secure Real-time Transport Protocol). Un protocole de sécurité utilise le TEK et « possède » la SA de sécurité des données de la même manière qu'IPsec ESP utilise les clés IKE Phase 2 et possède la SA Phase 2 ; pour le GDOI, IPsec ESP utilise le TEK.

Ainsi, le GDOI est un protocole de gestion des associations de sécurité de groupe : tous les messages GDOI sont utilisés pour créer, maintenir ou supprimer des associations de sécurité pour un groupe. Comme décrit ci-dessus, ces associations de sécurité protègent une ou plusieurs clés de chiffrement de clés, clés de chiffrement de trafic ou données partagées par les membres du groupe pour les applications de multicast et de sécurité de groupe.

Les mots-clés MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY et OPTIONAL, lorsqu'ils apparaissent dans ce document, doivent être interprétés comme décrit dans le BCP 14, RFC 2119 [RFC2119].

1.1. Applications GDOI (GDOI Applications)

Les applications de multicast sécurisé incluent la diffusion vidéo (Video Broadcast) et le transfert de fichiers multicast (Multicast File Transfer). Dans un environnement d'entreprise, bon nombre de ces applications nécessitent la sécurité du réseau et peuvent (MAY) utiliser IPsec ESP pour sécuriser leur trafic de données. La section 5.4.1 spécifie comment le GDOI transporte les paramètres SA nécessaires pour ESP. De cette manière, le GDOI prend en charge le multicast ESP avec l'authentification de groupe des paquets ESP en utilisant la clé de groupe partagée (Shared Group Key) (l'authentification des sources uniques de paquets ESP n'est pas possible).

Le GDOI peut (CAN) également sécuriser des applications de groupe qui n'utilisent pas de transport multicast telles que la vidéo à la demande (Video-on-Demand). Par exemple, le message GROUPKEY-PUSH peut (MAY) établir une SA IPsec ESP par paire (Pair-wise) pour un membre d'un groupe d'abonnement sans nécessiter d'échanges de gestion des clés et de cryptographie asymétrique coûteuse (Asymmetric Cryptography).

1.2. Extension du GDOI (Extending GDOI)

Toutes les applications de multicast sécurisé ou multimédia ne peuvent pas utiliser IPsec ESP. Par exemple, de nombreuses applications de protocole de transport en temps réel (Real Time Transport Protocol) nécessitent une sécurité au-dessus de la couche IP pour préserver l'efficacité de la compression d'en-tête RTP et l'indépendance du transport [RFC3550]. Un futur protocole de sécurité RTP peut (MAY) bénéficier de l'utilisation du GDOI pour établir des SA de groupe.

Pour ajouter un nouveau protocole de sécurité des données, une nouvelle RFC doit (MUST) spécifier les paramètres SA de sécurité des données que le GDOI transporte pour ce protocole de sécurité ; ces paramètres sont énumérés dans la section 5.4.2 de ce document.

Une SA de protocole de sécurité des données doit (MUST) protéger le trafic de groupe. Le GDOI n'impose aucune restriction quant à savoir si ce trafic de groupe est livré sous forme de paquets unicast (Unicast) ou multicast (Multicast). Cependant, le GDOI ne doit pas (MUST NOT) être utilisé par un protocole de sécurité des données comme mécanisme de gestion des clés lorsque les paquets protégés par la SA de sécurité des données sont destinés à rester privés et à ne jamais faire partie d'une communication de groupe.