Passa al contenuto principale

1. Introduzione (Introduction)

Questo documento presenta un ISAKMP Domain of Interpretation (DOI) per la gestione delle chiavi di gruppo, denominato "Group Domain of Interpretation" (GDOI). In questo modello di gestione delle chiavi di gruppo, il protocollo GDOI viene eseguito tra un membro del gruppo e un "group controller/key server" (GCKS), che stabilisce le Security Association [Sezione 4.6.2 RFC2401] tra i membri autorizzati del gruppo. ISAKMP definisce due "fasi" di negoziazione [p. 16 RFC2408]. Il GDOI MUST essere protetto da una Security Association di Fase 1. Questo documento incorpora la definizione della Security Association (SA) di Fase 1 dall'Internet DOI [RFC2407, RFC2409]. Altri possibili tipi di Security Association di Fase 1 sono indicati nell'Appendice A. Lo scambio di Fase 2 è definito in questo documento e propone nuovi payload e nuovi scambi conformi allo standard ISAKMP [p. 14 RFC2408].

Sono previsti sei nuovi payload:

  1. GDOI SA
  2. SA KEK (SAK), che segue il payload SA
  3. SA TEK (SAT), che segue il payload SA
  4. Key Download Array (KD)
  5. Sequence Number (SEQ)
  6. Proof of Possession (POP)

Sono previsti due nuovi scambi.

1) Uno scambio di Fase 2 crea le SA di Re-key e di Data-Security Protocol.

Il nuovo scambio di Fase 2, denominato "GROUPKEY-PULL", scarica le chiavi per la SA di "Re-key" e/o la SA di "Data-security" di un gruppo. La SA di Re-key comprende una chiave di cifratura delle chiavi, o KEK, comune al gruppo; una SA di Data-security comprende una chiave di cifratura dei dati, o TEK, utilizzata da un protocollo di data-security per cifrare o decifrare il traffico dati [Sezione 2.1 RFC2407]. La SA per il KEK o il TEK comprende chiavi di autenticazione, chiavi di cifratura, policy crittografiche e attributi. Lo scambio GROUPKEY-PULL adotta un comportamento di tipo "pull", poiché è il membro a iniziare il recupero di queste SA da un GCKS.

2) Un datagramma stabilisce successivamente ulteriori SA di Re-key e/o di Data-Security Protocol.

Il datagramma GROUPKEY-PUSH viene "inviato" (pushed) dal GCKS ai membri per creare o aggiornare una SA di Re-key o di Data-security. Una SA di Re-key protegge i messaggi GROUPKEY-PUSH. Pertanto, è necessario un GROUPKEY-PULL per stabilire almeno una SA di Re-key, al fine di proteggere i successivi messaggi GROUPKEY-PUSH. Il GCKS cifra il messaggio GROUPKEY-PUSH utilizzando la SA di Re-key KEK. GDOI supporta l'uso di array di KEK per gli algoritmi di gestione delle chiavi di gruppo che impiegano l'algoritmo Logical Key Hierarchy (LKH), al fine di aggiungere e rimuovere in modo efficiente i membri del gruppo [RFC2627]. L'implementazione dell'algoritmo LKH è OPTIONAL.

Sebbene il GROUPKEY-PUSH specificato da questo documento possa essere utilizzato per rinnovare una SA di Re-key, l'uso più comune di GROUPKEY-PUSH consiste nello stabilire una SA di Data-security per un protocollo di data security. GDOI può accogliere estensioni future a supporto di una varietà di protocolli di data security. Questo documento specifica le SA di data-security per un solo protocollo di sicurezza, IPsec ESP. Un RFC separato specificherà il supporto per altri protocolli di data security, come un futuro Real-time Transport Protocol sicuro. Un protocollo di sicurezza utilizza il TEK e "possiede" la SA di data-security allo stesso modo in cui IPsec ESP utilizza le chiavi di Fase 2 di IKE e possiede la SA di Fase 2; per GDOI, IPsec ESP utilizza il TEK.

GDOI è quindi un protocollo di gestione delle Security Association di gruppo: tutti i messaggi GDOI sono utilizzati per creare, mantenere o eliminare le Security Association di un gruppo. Come descritto sopra, queste Security Association proteggono una o più chiavi di cifratura delle chiavi, chiavi di cifratura del traffico, o dati condivisi dai membri del gruppo per applicazioni multicast e di sicurezza di gruppo.

Le parole chiave MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY e OPTIONAL, quando compaiono in questo documento, devono essere interpretate come descritto in BCP 14, RFC 2119 [RFC2119].

1.1. Applicazioni di GDOI (GDOI Applications)​

Le applicazioni multicast sicure includono la trasmissione video (video broadcast) e il trasferimento di file in multicast. In un ambiente aziendale, molte di queste applicazioni richiedono sicurezza di rete e possono utilizzare IPsec ESP per proteggere il proprio traffico dati. La Sezione 5.4.1 specifica come GDOI trasporta i parametri SA necessari per ESP. In questo modo, GDOI supporta ESP multicast con autenticazione di gruppo dei pacchetti ESP mediante la chiave di gruppo condivisa (non è possibile l'autenticazione delle singole sorgenti dei pacchetti ESP).

GDOI può inoltre proteggere applicazioni di gruppo che non utilizzano il trasporto multicast, come il video-on-demand. Ad esempio, il messaggio GROUPKEY-PUSH può stabilire una SA IPsec ESP punto-punto per un membro di un gruppo in abbonamento, senza la necessità di scambi di gestione delle chiavi e di costose operazioni di crittografia asimmetrica.

1.2. Estensione di GDOI (Extending GDOI)​

Non tutte le applicazioni multicast o multimediali sicure possono utilizzare IPsec ESP. Ad esempio, molte applicazioni basate sul Real Time Transport Protocol richiedono sicurezza al di sopra del livello IP, per preservare l'efficienza della compressione dell'header RTP e l'indipendenza dal trasporto [RFC3550]. Un futuro protocollo di sicurezza per RTP potrebbe trarre vantaggio dall'uso di GDOI per stabilire SA di gruppo.

Per aggiungere un nuovo protocollo di data security, un nuovo RFC MUST specificare i parametri della SA di data-security che GDOI trasporta per tale protocollo di sicurezza; tali parametri sono elencati nella Sezione 5.4.2 di questo documento.

Una SA di un protocollo di data security MUST proteggere il traffico di gruppo. GDOI non pone alcuna restrizione sul fatto che tale traffico di gruppo sia consegnato come pacchetti unicast o multicast. Tuttavia, GDOI MUST NOT essere utilizzato da un protocollo di data security come meccanismo di gestione delle chiavi quando i pacchetti protetti dalla SA di data-security sono destinati a rimanere privati e a non far mai parte di una comunicazione di gruppo.