2.8. Ricompilazione delle chiavi (Rekeying)

2.8. Ricompilazione delle chiavi (Rekeying)

La ricompilazione delle chiavi (rekeying) consiste nel sostituire una SA esistente con una nuova SA senza interrompere la comunicazione. Questo viene solitamente fatto quando la vecchia SA sta per scadere. Durante la ricompilazione delle chiavi, le due parti DEVONO concordare nuovo materiale di chiave. Entrambe le parti DEVONO essere in grado di gestire simultaneamente i pacchetti provenienti dalla vecchia e dalla nuova SA. La sezione 2.8 descrive la ricompilazione delle chiavi per le child SA, mentre la sezione 2.18 descrive la ricompilazione delle chiavi per la parent SA (IKE SA).

Sebbene la ricompilazione delle chiavi sia frequentemente utilizzata, lo scambio associato non è richiesto (REQUIRED) di essere implementato. Le implementazioni dotate della funzionalità di ricompilazione delle chiavi DEVONO supportare lo scambio CREATE_CHILD_SA descritto in questo documento. Le implementazioni prive della funzionalità di ricompilazione delle chiavi DEVONO semplicemente inviare, nel payload SA dello scambio IKE_SA_INIT, una proposta che non contiene alcun attributo specifico della ricompilazione delle chiavi, in modo che il peer non tenti di ricompilare le chiavi. Le implementazioni che non supportano la ricompilazione delle chiavi DEVONO rifiutare uno scambio CREATE_CHILD_SA contenente l'attributo REKEY_SA, e inviare una risposta con la notifica NO_ADDITIONAL_SAS.

Quando l'iniziatore desidera ricompilare le chiavi, esso avvia uno scambio CREATE_CHILD_SA contenente una proposta per la nuova SA, e includendo l'attributo REKEY_SA che specifica la SA da ricompilare. Il valore SPI nell'attributo REKEY_SA è lo SPI utilizzato dalla SA da ricompilare nella direzione di invio. Un payload SA con l'attributo REKEY_SA può anche essere utilizzato per ricompilare una SA eliminata, nel qual caso il valore SPI è lo SPI di invio della SA eliminata. Nello scambio CREATE_CHILD_SA, la vecchia SA [fade-out] è ancora in uso (cioè, la vecchia SA non viene rimossa dal database delle SA (SAD) finché lo scambio di ricompilazione non è completato), e la nuova SA [fade-in] viene stabilita. L'iniziatore utilizzerà la SA appena stabilita come nuova SA, e marcherà la vecchia SA come "morta" (cioè, da eliminare il prima possibile). Il risponditore marcherà la vecchia SA come "viva", ma utilizzerà la nuova SA stabilita come nuova SA. In altre parole, entrambe le parti passano dall'uso della vecchia SA all'uso della nuova SA, ma il risponditore DEVE attendere una conferma prima di poterlo fare.

Il detentore attuale della SA (cioè, la parte che ha inviato la proposta SA nello scambio IKE_SA_INIT) DEVE essere l'iniziatore nello scambio di ricompilazione delle chiavi, poiché la nuova SA DEVE essere proposta dal detentore. Ciò evita un deadlock di scambi di ricompilazione simultanei. Per ricompilare una SA, lo scambio CREATE_CHILD_SA DEVE essere avviato dal detentore della SA.

Prima che un'implementazione accetti una SA in procinto di essere usata, essa può attendere la conferma che la vecchia SA sia stata rimossa dalla SAD del peer. In tal caso, l'implementazione DEVE attendere la notifica di eliminazione in uno scambio INFORMATIONAL (vedere sezioni 2.4 e 3.11). Prima di ricevere tale notifica di eliminazione, l'implementazione DEVE conservare la vecchia SA, poiché il peer potrebbe ancora utilizzarla. Questa attesa è responsabilità sia dell'iniziatore che del risponditore. Le implementazioni non dovrebbero (SHOULD NOT) conservare la vecchia SA indefinitamente, ma DEVONO conservarla finché la notifica di eliminazione non arriva, o finché la durata di vita della SA (determinata dalla durata di vita negoziata di tale SA) non scade.

Se un'implementazione dotata della funzionalità di ricompilazione delle chiavi riceve una proposta con l'attributo REKEY_SA durante lo scambio IKE_SA_INIT, essa DEVE rifiutare la proposta con una risposta contenente la notifica NO_ADDITIONAL_SAS. Se l'implementazione non supporta la ricompilazione delle chiavi, DEVE rifiutare uno scambio CREATE_CHILD_SA contenente l'attributo REKEY_SA, e inviare una risposta con la notifica NO_ADDITIONAL_SAS. Una proposta contenente l'attributo REKEY_SA ricevuta durante lo scambio IKE_SA_INIT è un errore; tuttavia, una proposta contenente l'attributo REKEY_SA ricevuta durante uno scambio CREATE_CHILD_SA è valida.

Se lo scambio di ricompilazione delle chiavi fallisce (ad esempio, a causa di NO_ADDITIONAL_SAS o di una proposta non valida), la vecchia SA è ancora disponibile e una ricompilazione delle chiavi PUÒ essere tentata in seguito. Se la vecchia SA scade, la comunicazione viene interrotta, e se le politiche di entrambe le parti lo consentono, PUÒ essere stabilita una nuova SA (forse una IKE SA del tutto nuova).

L'esaurimento delle risorse è un attacco di negazione del servizio in cui l'attaccante consuma le risorse della vittima richiedendo troppe SA. Per evitare questo attacco, le implementazioni DOVREBBERO limitare il numero di SA in fase di ricompilazione in un dato momento, nonché il numero di child SA stabilite da una singola IKE SA.

2.8.1. Ricompilazione simultanea delle chiavi

La ricompilazione simultanea delle chiavi si verifica quando entrambi i peer avviano uno scambio di ricompilazione delle chiavi. Per evitare un deadlock quando due scambi CREATE_CHILD_SA indipendenti si verificano contemporaneamente, e per evitare il possibile problema che due nuove SA negozino ID incoerenti, le implementazioni DEVONO seguire le seguenti regole:

1. Il detentore originale della SA DEVE rimanere l'iniziatore del nuovo scambio CREATE_CHILD_SA.

2. Se il risponditore riceve uno scambio CREATE_CHILD_SA che tenta di ricompilare una SA per cui ha già emesso una richiesta di ricompilazione delle chiavi, allora il risponditore DEVE dare priorità alla richiesta di ricompilazione del peer sulla propria. In questo caso, il risponditore DOVREBBE eliminare la SA da esso stesso avviata, e utilizzare la SA creata dal peer. Il risponditore DEVE inviare il nuovo SPI all'iniziatore, affinché l'iniziatore sappia quale SPI utilizzare.

3. In un dato momento, non dovrebbero (SHOULD NOT) esserci più di due SA attive correlate alla stessa SA originale.

Per evitare la ricompilazione simultanea delle chiavi, le implementazioni POSSONO attendere una quantità di tempo casuale prima di iniziare lo scambio di ricompilazione delle chiavi. Se ricevono una richiesta di ricompilazione delle chiavi avviata dal peer mentre non hanno ancora avviato la propria ricompilazione, DOVREBBERO dare priorità alla richiesta del peer sulla propria.