4.7. Opérations GCKS (GCKS Operations)

Le GCKS ou son délégué peut initier un message de re-clé pour plusieurs raisons, par exemple, l'appartenance au groupe a changé ou les clés doivent expirer.

Pour commencer le datagramme de re-clé, le GCKS construit un HDR ISAKMP avec la paire de cookies correcte, et une charge utile SEQ qui inclut un numéro de séquence supérieur d'une unité au datagramme de re-clé précédent.

Une charge utile SA est ensuite ajoutée. Elle est identique en structure et en signification à une charge utile SA envoyée dans un échange GROUPKEY-PULL. S'il y a des changements à la KEK (dans le cas d'une KEK statique) ou dans l'appartenance au groupe (dans le cas de LKH), un attribut SA_KEK est ajouté à la SA. S'il y a une ou plusieurs nouvelles TEK, des attributs SA_TEK sont ajoutés pour décrire cette politique.

Une charge utile KD est ensuite ajoutée. Elle est identique en structure et en signification à une charge utile KD envoyée dans un échange GROUPKEY-PULL. Si un attribut SA_KEK a été inclus dans la charge utile SA, les clés KEK correspondantes (ou un tableau KEK) sont incluses. Les clés TEK sont envoyées pour chaque attribut SA_TEK inclus dans la charge utile SA.

Une charge utile CERT est ajoutée si l'initiateur doit fournir son certificat.

Dans l'avant-dernière étape, l'initiateur hache la chaîne "rekey" suivie du message de gestion de clés déjà formé. Le hachage est signé, placé dans une charge utile SIG et ajouté au datagramme.

Enfin, les charges utiles suivant le HDR sont chiffrées en utilisant la clé de chiffrement KEK actuelle. Le datagramme peut maintenant être envoyé.