4. Messaggio GROUPKEY-PUSH (GROUPKEY-PUSH Message)

GDOI invia informazioni di controllo in modo sicuro utilizzando comunicazioni di gruppo. Tipicamente ciò avverrà utilizzando la distribuzione IP multicast di un messaggio GROUPKEY-PUSH, ma può anche essere "spinto" (pushed) utilizzando la consegna unicast se IP multicast non è possibile. Il messaggio GROUPKEY-PUSH sostituisce un KEK di SA di re-key o un array KEK, e/o crea una nuova SA di sicurezza dei dati.

Membro                               GCKS o Delegato
------                               ----------------

                    <---- HDR*, SEQ, SA, KD, [CERT,] SIG

Nota: Protetto dal KEK di SA di re-key; la crittografia si verifica dopo HDR

HDR è definito di seguito. Il payload SEQ è definito nella sezione Payloads. La SA definisce la policy (ad esempio, suite di protezione) e gli attributi (ad esempio, SPI) per SA di re-key e/o di sicurezza dei dati. Il GCKS o delegato fornisce opzionalmente un payload CERT per la verifica del SIG. KD è il payload di download delle chiavi come descritto nella sezione Payloads.

Il payload SIG è una firma di un hash dell'intero messaggio prima della crittografia (compreso l'header ed escludendo il payload SIG stesso), prefissato con la stringa "rekey". La stringa prefissata garantisce che la firma del datagramma di re-key non possa essere utilizzata per altri scopi nel protocollo GDOI.

Se la SA definisce un array KEK LKH o un singolo KEK, KD contiene un KEK o un array KEK per una nuova SA di re-key, che ha una nuova coppia di cookie. Quando il payload KD trasporta un nuovo attributo SA KEK (sezione 5.3), una SA di re-key viene sostituita con una nuova SA avente lo stesso identificatore di gruppo (ID specificato nel messaggio 1 della sezione 3.2) e incrementando lo stesso contatore di sequenza, che viene inizializzato nel messaggio 4 della sezione 3.2. Se la SA definisce un payload SA TEK, ciò informa il membro che è stata creata una nuova SA di sicurezza dei dati, con materiale di chiavi trasportato in KD (Sezione 5.5).

Se la SA definisce un grande array KEK LKH (ad esempio, durante l'inizializzazione del gruppo e il re-keying batch), parti dell'array possono (MAY) essere inviate in diversi datagrammi GROUPKEY-PUSH unici. Tuttavia, ciascuno dei datagrammi GROUPKEY-PUSH deve (MUST) essere un datagramma GROUPKEY-PUSH completamente formato. Ciò comporta che ogni datagramma contenga un numero di sequenza e la policy nel payload SA, che corrisponde alla porzione dell'array KEK inviata nel payload KD.

4.1. Segretezza perfetta in avanti (Perfect Forward Secrecy, PFS)

Il messaggio GROUPKEY-PUSH è protetto dal KEK di gruppo anche se in tutti i casi, il messaggio GROUPKEY-PUSH trasporta nuovi download di chiavi, tra le altre informazioni. Un segreto appena generato deve (MUST) proteggere il download delle chiavi affinché il messaggio GROUPKEY-PUSH abbia PFS. Questa questione è oggetto di ulteriori studi.

4.2. Controllo dell'accesso in avanti e all'indietro (Forward and Backward Access Control)

Attraverso GROUPKEY-PUSH, GDOI supporta algoritmi come LKH che hanno la proprietà di negare l'accesso a una nuova chiave di gruppo da parte di un membro rimosso dal gruppo (controllo dell'accesso in avanti) e a una vecchia chiave di gruppo da parte di un membro aggiunto al gruppo (controllo dell'accesso all'indietro). Una nozione non correlata a PFS, il "controllo dell'accesso in avanti" e il "controllo dell'accesso all'indietro" sono stati chiamati "sicurezza perfetta in avanti" e "sicurezza perfetta all'indietro" nella letteratura [RFC2627].

Algoritmi di gestione del gruppo che forniscono controllo dell'accesso in avanti e all'indietro diversi da LKH sono stati proposti nella letteratura, tra cui OFT [OFT] e Subset Difference [NNL]. Questi algoritmi potrebbero essere utilizzati con GDOI, ma non sono specificati come parte di questo documento.

Il supporto per gli algoritmi di gestione del gruppo è supportato tramite l'attributo KEY_MANAGEMENT_ALGORITHM che viene inviato nel payload SA_KEK. GDOI specifica un metodo con cui LKH può essere utilizzato per il controllo dell'accesso in avanti e all'indietro. Altri metodi di utilizzo di LKH, così come altri algoritmi di gestione del gruppo come OFT o Subset Difference possono (MAY) essere aggiunti a GDOI come parte di un documento successivo. Qualsiasi tale aggiunta deve (MUST) essere dovuta a una Standards Action come definita in [RFC2434].

4.2.1. Requisiti di controllo dell'accesso in avanti (Forward Access Control Requirements)

Quando l'appartenenza al gruppo viene modificata utilizzando un algoritmo di gestione del gruppo, di solito sono necessari anche nuovi SA_TEK (e le loro chiavi associate). Nuove SA e chiavi garantiscono che i membri a cui è stato negato l'accesso non possano più partecipare al gruppo.

Se il controllo dell'accesso in avanti è una proprietà desiderata del gruppo, i nuovi SA_TEK e i pacchetti di chiavi associati nel payload KD non devono (MUST NOT) essere inclusi in un messaggio GROUPKEY-PUSH che modifica l'appartenenza al gruppo. Ciò è richiesto perché la policy SA_TEK e i pacchetti di chiavi associati nel payload KD non sono protetti con il nuovo KEK. Un secondo messaggio GROUPKEY-PUSH può consegnare i nuovi SA_TEKS e le loro chiavi associate perché sarà protetto con il nuovo KEK, e quindi non sarà visibile ai membri a cui è stato negato l'accesso.

Se la policy di controllo dell'accesso in avanti per il gruppo include il mantenimento dei cambiamenti di policy di gruppo dai membri a cui è negato l'accesso al gruppo, allora due messaggi GROUPKEY-PUSH sequenziali che cambiano il KEK di gruppo devono (MUST) essere inviati dal GCKS. Il primo messaggio GROUPKEY-PUSH crea un nuovo KEK per il gruppo. I membri del gruppo a cui viene negato l'accesso non saranno in grado di accedere al nuovo KEK, ma vedranno la policy di gruppo poiché il messaggio GROUPKEY-PUSH è protetto sotto il KEK corrente. Un successivo messaggio GROUPKEY-PUSH contenente la policy di gruppo modificata e nuovamente cambiando il KEK consente il controllo completo dell'accesso in avanti. Un messaggio GROUPKEY-PUSH non deve (MUST NOT) cambiare la policy senza creare un nuovo KEK.

Se altri metodi di utilizzo di LKH o altri algoritmi di gestione del gruppo vengono aggiunti a GDOI, tali metodi possono (MAY) rimuovere le restrizioni di cui sopra che richiedono più messaggi GROUPKEY-PUSH, a condizione che tali metodi specifichino come la policy di controllo dell'accesso in avanti viene mantenuta all'interno di un singolo messaggio GROUPKEY-PUSH.

4.3. Delega della gestione delle chiavi (Delegation of Key Management)

GDOI supporta la delega dei datagrammi GROUPKEY-PUSH attraverso le capacità di delega della PKI. Tuttavia, GDOI non specifica esplicitamente come il GCKS identifica i delegati, ma lascia questo alla PKI utilizzata da una particolare implementazione GDOI.

4.4. Uso delle chiavi di firma (Use of Signature Keys)

Il GCKS non dovrebbe (SHOULD NOT) utilizzare la stessa chiave per firmare il payload SIG nel messaggio GROUPKEY-PUSH come è stato utilizzato per l'autorizzazione nel payload POP di GROUPKEY-PULL. Se la stessa chiave deve essere utilizzata, una funzione hash diversa dovrebbe (SHOULD) essere utilizzata come base per il payload POP rispetto a quella utilizzata come base per il payload SIG.