4. Message GROUPKEY-PUSH (GROUPKEY-PUSH Message)
GDOI envoie des informations de contrôle de manière sécurisée en utilisant les communications de groupe. Typiquement, cela se fera en utilisant la distribution IP multicast d'un message GROUPKEY-PUSH, mais il peut également être « poussé » (pushed) en utilisant la livraison unicast si IP multicast n'est pas possible. Le message GROUPKEY-PUSH remplace un KEK de SA de re-clé ou un tableau KEK, et/ou crée une nouvelle SA de sécurité des données.
Membre GCKS ou Délégué
------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
Note : Protégé par le KEK de SA de re-clé ; le chiffrement se produit après HDR
HDR est défini ci-dessous. La charge utile SEQ est définie dans la section Charges utiles. La SA définit la politique (par exemple, suite de protection) et les attributs (par exemple, SPI) pour une ou des SA de re-clé et/ou de sécurité des données. Le GCKS ou le délégué fournit optionnellement une charge utile CERT pour la vérification du SIG. KD est la charge utile de téléchargement de clés comme décrit dans la section Charges utiles.
La charge utile SIG est une signature d'un hachage de l'ensemble du message avant chiffrement (y compris l'en-tête et excluant la charge utile SIG elle-même), préfixé par la chaîne « rekey ». La chaîne préfixée garantit que la signature du datagramme de re-clé ne peut pas être utilisée à d'autres fins dans le protocole GDOI.
Si la SA définit un tableau KEK LKH ou un KEK unique, KD contient un KEK ou un tableau KEK pour une nouvelle SA de re-clé, qui a une nouvelle paire de cookies. Lorsque la charge utile KD transporte un nouvel attribut SA KEK (section 5.3), une SA de re-clé est remplacée par une nouvelle SA ayant le même identifiant de groupe (ID spécifié dans le message 1 de la section 3.2) et incrémentant le même compteur de séquence, qui est initialisé dans le message 4 de la section 3.2. Si la SA définit une charge utile SA TEK, cela informe le membre qu'une nouvelle SA de sécurité des données a été créée, avec le matériel de clés transporté dans KD (Section 5.5).
Si la SA définit un grand tableau KEK LKH (par exemple, pendant l'initialisation du groupe et la re-clé par lots), des parties du tableau peuvent (MAY) être envoyées dans différents datagrammes GROUPKEY-PUSH uniques. Cependant, chacun des datagrammes GROUPKEY-PUSH doit (MUST) être un datagramme GROUPKEY-PUSH entièrement formé. Cela entraîne que chaque datagramme contient un numéro de séquence et la politique dans la charge utile SA, qui correspond à la portion du tableau KEK envoyée dans la charge utile KD.
4.1. Confidentialité persistante parfaite (Perfect Forward Secrecy, PFS)
Le message GROUPKEY-PUSH est protégé par le KEK de groupe bien que dans tous les cas, le message GROUPKEY-PUSH transporte de nouveaux téléchargements de clés, entre autres informations. Un secret nouvellement généré doit (MUST) protéger le téléchargement de clés pour que le message GROUPKEY-PUSH ait la PFS. Cette question est à l'étude.
4.2. Contrôle d'accès avant et arrière (Forward and Backward Access Control)
À travers GROUPKEY-PUSH, le GDOI prend en charge des algorithmes tels que LKH qui ont la propriété de refuser l'accès à une nouvelle clé de groupe par un membre supprimé du groupe (contrôle d'accès avant) et à une ancienne clé de groupe par un membre ajouté au groupe (contrôle d'accès arrière). Une notion sans rapport avec la PFS, le « contrôle d'accès avant » et le « contrôle d'accès arrière » ont été appelés « sécurité avant parfaite » et « sécurité arrière parfaite » dans la littérature [RFC2627].
Des algorithmes de gestion de groupe fournissant un contrôle d'accès avant et arrière autres que LKH ont été proposés dans la littérature, notamment OFT [OFT] et Subset Difference [NNL]. Ces algorithmes pourraient être utilisés avec GDOI, mais ne sont pas spécifiés dans ce document.
La prise en charge des algorithmes de gestion de groupe est assurée via l'attribut KEY_MANAGEMENT_ALGORITHM qui est envoyé dans la charge utile SA_KEK. GDOI spécifie une méthode par laquelle LKH peut être utilisé pour le contrôle d'accès avant et arrière. D'autres méthodes d'utilisation de LKH, ainsi que d'autres algorithmes de gestion de groupe tels que OFT ou Subset Difference peuvent (MAY) être ajoutés à GDOI dans le cadre d'un document ultérieur. Tout ajout de ce type doit (MUST) être dû à une Standards Action telle que définie dans [RFC2434].
4.2.1. Exigences de contrôle d'accès avant (Forward Access Control Requirements)
Lorsque l'appartenance au groupe est modifiée à l'aide d'un algorithme de gestion de groupe, de nouveaux SA_TEK (et leurs clés associées) sont généralement également nécessaires. De nouvelles SA et clés garantissent que les membres auxquels l'accès a été refusé ne peuvent plus participer au groupe.
Si le contrôle d'accès avant est une propriété souhaitée du groupe, les nouveaux SA_TEK et les paquets de clés associés dans la charge utile KD ne doivent pas (MUST NOT) être inclus dans un message GROUPKEY-PUSH qui modifie l'appartenance au groupe. Cela est requis car la politique SA_TEK et les paquets de clés associés dans la charge utile KD ne sont pas protégés avec le nouveau KEK. Un deuxième message GROUPKEY-PUSH peut livrer les nouveaux SA_TEKS et leurs clés associées car il sera protégé avec le nouveau KEK, et ne sera donc pas visible pour les membres auxquels l'accès a été refusé.
Si la politique de contrôle d'accès avant du groupe inclut de garder les changements de politique de groupe des membres auxquels l'accès au groupe est refusé, alors deux messages GROUPKEY-PUSH séquentiels changeant le KEK de groupe doivent (MUST) être envoyés par le GCKS. Le premier message GROUPKEY-PUSH crée un nouveau KEK pour le groupe. Les membres du groupe auxquels l'accès est refusé ne pourront pas accéder au nouveau KEK, mais verront la politique de groupe puisque le message GROUPKEY-PUSH est protégé sous le KEK actuel. Un message GROUPKEY-PUSH ultérieur contenant la politique de groupe modifiée et changeant à nouveau le KEK permet un contrôle d'accès avant complet. Un message GROUPKEY-PUSH ne doit pas (MUST NOT) changer la politique sans créer un nouveau KEK.
Si d'autres méthodes d'utilisation de LKH ou d'autres algorithmes de gestion de groupe sont ajoutés à GDOI, ces méthodes peuvent (MAY) supprimer les restrictions ci-dessus nécessitant plusieurs messages GROUPKEY-PUSH, à condition que ces méthodes spécifient comment la politique de contrôle d'accès avant est maintenue dans un seul message GROUPKEY-PUSH.
4.3. Délégation de la gestion des clés (Delegation of Key Management)
GDOI prend en charge la délégation des datagrammes GROUPKEY-PUSH via les capacités de délégation de la PKI. Cependant, GDOI ne spécifie pas explicitement comment le GCKS identifie les délégués, mais laisse cela à la PKI utilisée par une implémentation GDOI particulière.
4.4. Utilisation des clés de signature (Use of Signature Keys)
Le GCKS ne devrait pas (SHOULD NOT) utiliser la même clé pour signer la charge utile SIG dans le message GROUPKEY-PUSH que celle utilisée pour l'autorisation dans la charge utile POP de GROUPKEY-PULL. Si la même clé doit être utilisée, une fonction de hachage différente devrait (SHOULD) être utilisée comme base pour la charge utile POP que celle utilisée comme base pour la charge utile SIG.