Aller au contenu principal

3. Échange GROUPKEY-PULL (GROUPKEY-PULL Exchange)

L'objectif de l'échange GROUPKEY-PULL est d'établir des SA de re-clé (Re-key) et/ou de sécurité des données chez le membre pour un groupe particulier. Une SA de phase 1 protège le GROUPKEY-PULL ; il peut (MAY) y avoir plusieurs échanges GROUPKEY-PULL pour une SA de phase 1 donnée. L'échange GROUPKEY-PULL télécharge les clés de sécurité des données (TEK) et/ou la clé de chiffrement de clés de groupe (KEK) ou le tableau KEK sous la protection de la SA de phase 1.

3.1. Autorisation (Authorization)​

Il existe deux moyens alternatifs pour autoriser le message GROUPKEY-PULL. Premièrement, l'identité de phase 1 peut être utilisée pour autoriser la demande de phase 2 (GROUPKEY-PULL) pour une clé de groupe. Deuxièmement, une nouvelle identité peut être transmise dans la demande GROUPKEY-PULL. La nouvelle identité pourrait être spécifique au groupe et utiliser un certificat signé par le propriétaire du groupe pour identifier le détenteur comme membre autorisé du groupe. La charge utile de preuve de possession (Proof-of-Possession Payload) valide que le détenteur possède la clé secrète associée à l'identité de phase 2.

3.2. Messages​

Le GROUPKEY-PULL est un échange de phase 2. La phase 1 calcule SKEYID_a qui est la « clé » dans le hachage à clé utilisé dans les charges utiles HASH de GROUPKEY-PULL. Lors de l'utilisation de la phase 1 définie dans ce document, SKEYID_a est dérivé conformément à [RFC2409]. Comme pour la génération de charge utile HASH IKE [RFC 2409 section 5.5], chaque message GROUPKEY-PULL hache un ensemble de valeurs défini de manière unique. Les nonces (Nonces) permutent le HASH et fournissent une certaine protection contre les attaques par rejeu (Replay Attacks). La protection contre le rejeu est importante pour protéger le GCKS contre les attaques qu'un serveur de gestion de clés attirera.

Le GROUPKEY-PULL utilise des nonces pour garantir la « vivacité » (liveliness), ou contre le rejeu d'un message GROUPKEY-PULL récent. L'attaque par rejeu n'est utile que dans le contexte de la phase 1 actuelle. Si un message GROUPKEY-PULL est rejoué sur la base d'une phase 1 précédente, le calcul HASH échouera en raison d'un SKEYID_a incorrect. Le message échouera le traitement avant que le nonce ne soit jamais évalué. Pour que l'un ou l'autre pair bénéficie de la protection contre le rejeu, il doit reporter autant de traitement que possible jusqu'à ce qu'il reçoive le message dans le protocole qui prouve que le pair est vivant. Par exemple, le répondeur ne doit pas (MUST NOT) calculer le nombre Diffie-Hellman partagé (si des charges utiles KE ont été incluses) ou installer les nouvelles SA jusqu'à ce qu'il reçoive un message avec Nr inclus correctement dans la charge utile HASH.

Les nonces nécessitent un message supplémentaire dans l'échange de protocole pour s'assurer que le GCKS n'ajoute pas de membre au groupe tant qu'il ne prouve pas sa vivacité. L'initiateur membre GROUPKEY-PULL s'attend à trouver son nonce, Ni, dans le HASH d'un message retourné. Et le répondeur GCKS GROUPKEY-PULL s'attend à voir son nonce, Nr, dans le HASH d'un message retourné avant de fournir le matériel de clés de groupe comme dans l'échange suivant.

Initiateur (Membre)                  Répondeur (GCKS)
------------------                   ----------------
HDR*, HASH(1), Ni, ID     -->
                          <--     HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I]     -->
   [,CERT] [,POP_I]
                          <--     HDR*, HASH(4),[KE_R,][SEQ,]
                                    KD [,CERT] [,POP_R]

Les hachages sont calculés comme suit :

HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | CERT ] [ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ] KD [ | CERT ] [ | POP_R])

La charge utile POP est construite comme décrit dans la section 5.7.

Note : Protégé par la SA de phase 1, le chiffrement se produit après HDR

HDR est une charge utile d'en-tête ISAKMP qui utilise les cookies de phase 1 et un identifiant de message (M-ID) comme dans IKE [RFC2409]. Notez que les nonces sont inclus dans les deux premiers échanges, le GCKS ne renvoyant que la charge utile de politique SA avant que la vivacité ne soit prouvée. Les charges utiles HASH [RFC2409] prouvent que le pair possède le secret de phase 1 (SKEYID_a) et le nonce pour l'échange identifié par l'identifiant de message, M-ID. Une fois la vivacité établie, le dernier message complète le traitement réel du téléchargement de la charge utile KD.

En plus des charges utiles Nonce et HASH, l'initiateur membre identifie le groupe qu'il souhaite rejoindre via la charge utile ID ISAKMP. Le répondeur GCKS informe le membre de la valeur actuelle du numéro de séquence dans la charge utile SEQ ; le numéro de séquence ordonne les datagrammes GROUPKEY-PUSH (section 4) ; le membre doit (MUST) vérifier que le numéro de séquence est supérieur à celui de la charge utile SEQ précédente que le membre détient pour le groupe (s'il en détient) avant d'installer de nouvelles SA. La charge utile SEQ doit (MUST) être présente si la charge utile SA contient un attribut SA KEK.

3.2.1. Confidentialité persistante parfaite (Perfect Forward Secrecy)​

La confidentialité persistante parfaite (Perfect Forward Secrecy, PFS) pour le GROUPKEY-PULL est obtenue par l'inclusion optionnelle de la charge utile d'échange de clés (Key Exchange, KE) comme décrit dans RFC 2409. Si le KE est utilisé, il y a un échange Diffie-Hellman dans le cadre du GROUPKEY-PULL. Cela garantit que le TEK ou KEK ne peut pas être récupéré sans accès à l'accord de clés Diffie-Hellman.

3.2.2. Initialisation de l'en-tête ISAKMP (ISAKMP Header Initialization)​

Les champs HDR pour le GROUPKEY-PULL sont initialisés comme suit.

  • Les cookies proviennent de la phase 1. Chaque GROUPKEY-PULL partage les cookies de phase 1.
  • L'identifiant de message est généré aléatoirement par l'initiateur et est utilisé pour faire correspondre REQUEST et REPLY.
  • La charge utile suivante est HASH.
  • Le type d'échange est GDOI_GROUPKEY_PULL (valeur 32).

3.3. Opérations de l'initiateur (Initiator Operations)​

L'initiateur GROUPKEY-PULL doit (MUST) générer un nonce, Ni, et protéger tous les messages avec une SA de phase 1. La SA de phase 1 fournit le chiffrement et l'authentification de l'origine des données pour toutes les charges utiles GROUPKEY-PULL.

3.4. Opérations du récepteur (Receiver Operations)​

Le répondeur GROUPKEY-PULL (GCKS) doit (MUST) vérifier toutes les charges utiles HASH puis déchiffrer les charges utiles suivantes. Le GCKS doit (MUST) vérifier que les nonces, Ni et Nr, dans les calculs HASH correspondent aux nonces envoyés dans les charges utiles en clair. Si la vérification de la charge utile HASH échoue, le GCKS doit (MUST) rejeter le message et peut (MAY) auditer l'événement.

Le GCKS doit (MUST) valider l'autorisation des membres du groupe par une politique hors de la portée de ce document.

Dernière mise à jour le