4.7. Operazioni GCKS (GCKS Operations)

Il GCKS o il suo delegato può avviare un messaggio di Rekey per diversi motivi, ad esempio, l'appartenenza al gruppo è cambiata o le chiavi stanno per scadere.

Per iniziare il datagramma di rekey, il GCKS costruisce un HDR ISAKMP con la coppia di cookie corretta e un payload SEQ che include un numero di sequenza maggiore di uno rispetto al datagramma di rekey precedente.

Viene quindi aggiunto un payload SA. Questo è identico in struttura e significato a un payload SA inviato in uno scambio GROUPKEY-PULL. Se ci sono modifiche al KEK (nel caso di un KEK statico) o nell'appartenenza al gruppo (nel caso di LKH), viene aggiunto un attributo SA_KEK alla SA. Se ci sono uno o più nuovi TEK, vengono aggiunti attributi SA_TEK per descrivere quella politica.

Viene quindi aggiunto un payload KD. Questo è identico in struttura e significato a un payload KD inviato in uno scambio GROUPKEY-PULL. Se un attributo SA_KEK è stato incluso nel payload SA, vengono incluse le chiavi KEK corrispondenti (o un array KEK). Le chiavi TEK vengono inviate per ogni attributo SA_TEK incluso nel payload SA.

Viene aggiunto un payload CERT se l'iniziatore deve fornire il suo certificato.

Nel penultimo passaggio, l'iniziatore esegue l'hash della stringa "rekey" seguita dal messaggio di gestione delle chiavi già formato. L'hash viene firmato, inserito in un payload SIG e aggiunto al datagramma.

Infine, i payload che seguono l'HDR vengono crittografati utilizzando la chiave di crittografia KEK corrente. Il datagramma può ora essere inviato.