Passa al contenuto principale

3. Scambio GROUPKEY-PULL (GROUPKEY-PULL Exchange)

L'obiettivo dello scambio GROUPKEY-PULL è stabilire SA di re-key e/o di sicurezza dei dati presso il membro per un particolare gruppo. Una SA di fase 1 protegge il GROUPKEY-PULL; ci possono (MAY) essere più scambi GROUPKEY-PULL per una data SA di fase 1. Lo scambio GROUPKEY-PULL scarica le chiavi di sicurezza dei dati (TEK) e/o la chiave di crittografia delle chiavi di gruppo (KEK) o l'array KEK sotto la protezione della SA di fase 1.

3.1. Autorizzazione (Authorization)​

Esistono due mezzi alternativi per autorizzare il messaggio GROUPKEY-PULL. In primo luogo, l'identità di fase 1 può essere utilizzata per autorizzare la richiesta di fase 2 (GROUPKEY-PULL) per una chiave di gruppo. In secondo luogo, una nuova identità può essere passata nella richiesta GROUPKEY-PULL. La nuova identità potrebbe essere specifica per il gruppo e utilizzare un certificato firmato dal proprietario del gruppo per identificare il titolare come membro autorizzato del gruppo. Il payload di prova del possesso (Proof-of-Possession Payload) valida che il titolare possieda la chiave segreta associata all'identità di fase 2.

3.2. Messaggi (Messages)​

Il GROUPKEY-PULL è uno scambio di fase 2. La fase 1 calcola SKEYID_a che è la "chiave" nell'hash con chiave utilizzato nei payload HASH di GROUPKEY-PULL. Quando si utilizza la fase 1 definita in questo documento, SKEYID_a è derivato secondo [RFC2409]. Come per la generazione del payload HASH IKE [RFC 2409 sezione 5.5], ogni messaggio GROUPKEY-PULL esegue l'hash di un insieme di valori definito in modo univoco. I nonce (Nonces) permutano l'HASH e forniscono una certa protezione contro gli attacchi replay (Replay Attacks). La protezione contro il replay è importante per proteggere il GCKS dagli attacchi che un server di gestione delle chiavi attirerà.

Il GROUPKEY-PULL utilizza i nonce per garantire la "vivacità" (liveliness), o contro il replay di un recente messaggio GROUPKEY-PULL. L'attacco replay è utile solo nel contesto della fase 1 corrente. Se un messaggio GROUPKEY-PULL viene rigiocato sulla base di una fase 1 precedente, il calcolo HASH fallirà a causa di un SKEYID_a errato. Il messaggio fallirà l'elaborazione prima che il nonce venga mai valutato. Affinché uno dei peer benefici della protezione contro il replay, deve posticipare il più possibile l'elaborazione fino a quando non riceve il messaggio nel protocollo che dimostra che il peer è vivo. Ad esempio, il risponditore non deve (MUST NOT) calcolare il numero Diffie-Hellman condiviso (se sono stati inclusi payload KE) o installare le nuove SA fino a quando non riceve un messaggio con Nr incluso correttamente nel payload HASH.

I nonce richiedono un messaggio aggiuntivo nello scambio di protocollo per garantire che il GCKS non aggiunga un membro del gruppo fino a quando non dimostra la vivacità. L'iniziatore membro GROUPKEY-PULL si aspetta di trovare il suo nonce, Ni, nell'HASH di un messaggio restituito. E il risponditore GCKS GROUPKEY-PULL si aspetta di vedere il suo nonce, Nr, nell'HASH di un messaggio restituito prima di fornire materiale di chiavi di gruppo come nel seguente scambio.

Iniziatore (Membro)                  Risponditore (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]

Gli hash sono calcolati come segue:

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])

Il payload POP è costruito come descritto nella Sezione 5.7.

Nota: Protetto dalla SA di fase 1, la crittografia si verifica dopo HDR

HDR è un payload di intestazione ISAKMP che utilizza i cookie di fase 1 e un identificatore di messaggio (M-ID) come in IKE [RFC2409]. Si noti che i nonce sono inclusi nei primi due scambi, con il GCKS che restituisce solo il payload di policy SA prima che la vivacità sia dimostrata. I payload HASH [RFC2409] dimostrano che il peer ha il segreto di fase 1 (SKEYID_a) e il nonce per lo scambio identificato dall'ID messaggio, M-ID. Una volta stabilita la vivacità, l'ultimo messaggio completa l'elaborazione effettiva del download del payload KD.

Oltre ai payload Nonce e HASH, l'iniziatore membro identifica il gruppo a cui desidera unirsi tramite il payload ID ISAKMP. Il risponditore GCKS informa il membro del valore corrente del numero di sequenza nel payload SEQ; il numero di sequenza ordina i datagrammi GROUPKEY-PUSH (sezione 4); il membro deve (MUST) verificare che il numero di sequenza sia maggiore rispetto al payload SEQ precedente che il membro detiene per il gruppo (se ne detiene uno) prima di installare nuove SA. Il payload SEQ deve (MUST) essere presente se il payload SA contiene un attributo SA KEK.

3.2.1. Segretezza perfetta in avanti (Perfect Forward Secrecy)​

La segretezza perfetta in avanti (Perfect Forward Secrecy, PFS) per il GROUPKEY-PULL è ottenuta mediante l'inclusione opzionale del payload di scambio di chiavi (Key Exchange, KE) come descritto in RFC 2409. Se viene utilizzato KE, c'è uno scambio Diffie-Hellman come parte del GROUPKEY-PULL. Ciò garantisce che il TEK o KEK non possa essere recuperato senza accesso all'accordo di chiavi Diffie-Hellman.

3.2.2. Inizializzazione dell'intestazione ISAKMP (ISAKMP Header Initialization)​

I campi HDR per il GROUPKEY-PULL sono inizializzati come segue.

  • I cookie provengono dalla fase 1. Ogni GROUPKEY-PULL condivide i cookie di fase 1.
  • L'ID del messaggio è generato casualmente dall'iniziatore e viene utilizzato per abbinare REQUEST e REPLY.
  • Il payload successivo è HASH.
  • Il tipo di scambio è GDOI_GROUPKEY_PULL (valore 32).

3.3. Operazioni dell'iniziatore (Initiator Operations)​

L'iniziatore GROUPKEY-PULL deve (MUST) generare un nonce, Ni, e proteggere tutti i messaggi con una SA di fase 1. La SA di fase 1 fornisce crittografia e autenticazione dell'origine dei dati per tutti i payload GROUPKEY-PULL.

3.4. Operazioni del ricevitore (Receiver Operations)​

Il risponditore GROUPKEY-PULL (GCKS) deve (MUST) verificare tutti i payload HASH e quindi decrittografare i payload successivi. Il GCKS deve (MUST) verificare che i nonce, Ni e Nr, nei calcoli HASH corrispondano ai nonce inviati nei payload in chiaro. Se la verifica del payload HASH fallisce, il GCKS deve (MUST) rifiutare il messaggio e può (MAY) auditare l'evento.

Il GCKS deve (MUST) validare l'autorizzazione dei membri del gruppo tramite una policy al di fuori dell'ambito di questo documento.

Ultimo aggiornamento il