2.8. Rekeying (Rinegoziazione delle chiavi)
2.8. Rekeying (Rinegoziazione delle chiavi)
Le IKE, ESP e AH Security Association usano chiavi segrete per un tempo e un volume di dati limitati, il che limita la vita dell'intera SA. Una SA scaduta NON DEVE essere usata. Nuove SA POSSONO essere istituite se necessario. Sostituire SA scadute si chiama « rekeying ».
Per implementazioni IPsec minime, la capacità di rekey senza riavviare l'intera IKE SA è opzionale. Un'implementazione PUÒ rifiutare tutte le richieste CREATE_CHILD_SA in una IKE SA. Se una SA è scaduta o sta per scadere e i tentativi di rekey falliscono, l'implementazione DEVE chiudere l'IKE SA e i Child SA associati e POI PUÒ avviarne di nuovi. Il rekey sul posto migliora spesso le prestazioni e riduce i pacchetti persi.
Per rekey un Child SA in una IKE SA esistente, creare una nuova SA equivalente (Sezione 2.17) e, quando la nuova è stabilita, eliminare la vecchia. In un rekey, il nuovo Child SA NON DOVREBBE avere Traffic Selector o algoritmi diversi dalla vecchia.
Per rekey una IKE SA, istituire una nuova IKE SA equivalente (Sezione 2.18) con il peer che condivide la vecchia IKE SA usando CREATE_CHILD_SA nell'IKE SA esistente. Una IKE SA così creata eredita tutti i Child SA della originale; la nuova IKE SA è usata per tutti i messaggi di controllo necessari a mantenerli. Dopo la creazione della nuova IKE SA equivalente, l'iniziatore elimina la vecchia IKE SA e il payload Delete per se stesso DEVE essere l'ultima richiesta sulla vecchia IKE SA.
Le SA dovrebbero essere rekey in modo proattivo: la nuova SA prima che la vecchia scada e diventi inutilizzabile, con tempo sufficiente per spostare il traffico.
IKEv1 negoziava le durate di vita; in IKEv2 ogni estremità applica la propria politica. Se le politiche differiscono, quella con vita più breve sarà sempre a richiedere il rekey. SA a lungo inattiva: l'estremità PUÒ chiudere invece di rekey alla scadenza, o se non c'è stato traffico dall'ultimo rekey.
IKEv2 consapevolmente permette SA parallele con gli stessi Traffic Selectors (QoS, vedi [DIFFSERVFIELD], [DIFFSERVARCH], [DIFFTUNNEL] sezione 4.1). A differenza di IKEv1, la combinazione di estremità e Traffic Selectors può non identificare univocamente una SA; l'euristica IKEv1 di eliminare SA per Traffic Selectors duplicati NON DOVREBBE essere usata.
Ci sono finestre temporali, soprattutto con pacchetti persi, in cui le estremità possono non concordare sullo stato di una SA. Il risponditore a CREATE_CHILD_SA DEVE essere pronto ad accettare messaggi su una SA prima di inviare la sua risposta alla richiesta di creazione. L'iniziatore PUÒ iniziare a inviare su una SA non appena elabora la risposta; tuttavia non può ricevere su una SA appena creata finché non riceve ed elabora la risposta alla sua richiesta CREATE_CHILD_SA. Come fa il risponditore a sapere quando è lecito inviare sulla nuova SA?
Da correttezza tecnica e interoperabilità, il risponditore PUÒ iniziare a inviare su una SA non appena invia la risposta CREATE_CHILD_SA; in alcuni casi ciò può far cadere pacchetti inutilmente, quindi un'implementazione PUÒ differire.
Il risponditore può essere certo che l'iniziatore è pronto a ricevere se (1) ha ricevuto un messaggio crittograficamente valido sull'altra metà della coppia di SA, o (2) la nuova SA rekey una SA esistente e riceve una richiesta IKE per chiudere la SA sostituita. In un rekey, il risponditore continua a inviare traffico sulla vecchia SA fino a uno di questi eventi. Con una nuova SA, il risponditore PUÒ differire l'invio finché non riceve un messaggio o scatta un timeout. Se l'iniziatore riceve un messaggio su una SA per cui non ha ancora ricevuto risposta CREATE_CHILD_SA, interpreta come probabile perdita e ritrasmette CREATE_CHILD_SA. L'iniziatore PUÒ inviare un messaggio ESP fittizio su un nuovo ESP SA se non ha messaggi in coda per assicurare al risponditore che è pronto a ricevere.
2.8.1. Simultaneous Child SA Rekeying
Se le due estremità hanno le stesse politiche di vita, entrambe possono avviare un rekey contemporaneamente (SA ridondanti). La tempistica delle richieste di rekey DOVREBBE essere jitterata.
Questo rekey può produrre temporaneamente più SA simili tra le stesse coppie di nodi. Quando due SA sono idonee a ricevere pacchetti, un nodo DEVE accettare pacchetti in ingresso su entrambe. Se collisioni creano SA ridondanti, la SA creata con il minore dei quattro nonce usati nei due scambi DOVREBBE essere chiusa dall'estremità che l'ha creata. « Minore » significa confronto ottetto per ottetto. Il nodo che ha avviato la SA rekey sopravvissuta DOVREBBE eliminare la SA sostituita dopo che la nuova è stabilita.
Esempio con host A e B e coppia (SPIa1,SPIb1):
Host A Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2
recv req2 <--
A sa che c'è un rekey simultaneo ma non sa ancora quale nonce è minimo.
send resp2: SA(..,SPIa3,..),
Nr1,.. -->
--> recv req1
B sa lo stesso e risponde.
<-- send resp1: SA(..,SPIb3,..),
Nr2,..
recv resp1 <--
--> recv resp2
Esistono tre coppie. Se Nr1 in resp2 è minimo, B (mittente di req2) elimina la nuova SA ridondante, A la vecchia.
send req3: D(SPIa1) -->
<-- send req4: D(SPIb2)
--> recv req3
<-- send resp3: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->
Con perdita del primo req1 di A:
Host A Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),
Ni1,.. --> (lost)
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2
recv req2 <--
send resp2: SA(..,SPIa3,..),
Nr1,.. -->
--> recv resp2
<-- send req3: D(SPIb1)
recv req3 <--
send resp3: D(SPIa1) -->
--> recv resp3
Per B il rekey è completato e non sa ancora che A ritrasmetterà req1.
resend req1 -->
--> recv req1
B risponde ad esempio con CHILD_SA_NOT_FOUND.
<-- send resp1: N(CHILD_SA_NOT_FOUND)
recv resp1 <--
A PUÒ ignorare l'errore se sa già che c'è stato un rekey simultaneo.
2.8.2. Simultaneous IKE SA Rekeying
Il caso più complesso è il rekey simultaneo della IKE_SA. Vale il testo della Sezione 2.8; i Child SA devono essere ereditati dalla IKE_SA corretta.
Se entrambe le estremità notano il simultaneo, come per i Child SA: dopo gli scambi CREATE_CHILD_SA esistono tre IKE SA tra A e B. La nuova IKE SA con il nonce minimo DOVREBBE essere eliminata da chi l'ha creata; l'altra nuova IKE SA DEVE ereditare tutti i Child SA.
Caso speciale: un peer termina il rekey prima di accorgersi dell'altro. Se solo un peer rileva il simultaneo, non si creano SA ridondanti. Il peer che non ha notato il simultaneo e riceve richiesta di rekey di una IKE SA già rekeyata DOVREBBE restituire TEMPORARY_FAILURE (IKE SA in chiusura). Se il peer che ha notato il simultaneo riceve la richiesta di eliminazione della vecchia IKE SA dall'altro, sa che l'altro non ha rilevato il simultaneo e PUÒ abbandonare il proprio tentativo di rekey.
Host A Host B
-------------------------------------------------------------------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
--> recv req3
B vede una richiesta di chiusura IKE_SA e risponde come al solito. B dovrebbe smettere di ritrasmettere req2 perché quando A riceve resp3 eliminerà tutto lo stato della vecchia IKE_SA e non potrà più rispondere.
<-- send resp3: ()
TEMPORARY_FAILURE non era in RFC 4306 e non è negoziato; i peer più vecchi che implementano RFC 4306 ma non questo documento possono ricevere queste notifiche e le trattano come altre notifiche di errore sconosciute, interrompendo lo scambio. Poiché l'altro ha già rekey, non ci sono effetti negativi.
2.8.3. Rekeying the IKE SA versus Reauthentication
Rekey della IKE SA e riautenticazione sono concetti distinti in IKEv2. Il rekey della IKE SA stabilisce nuove chiavi e azzera i contatori Message ID ma non autentica di nuovo le parti (nessun payload AUTH o EAP).
Sebbene il rekey IKE SA possa essere importante in alcuni ambienti, la riautenticazione (verifica che le parti abbiano ancora accesso alle credenziali a lungo termine) è spesso più importante.
IKEv2 non ha supporto speciale per la riautenticazione: si crea una nuova IKE SA da zero (scambi IKE_SA_INIT/IKE_AUTH senza payload Notify REKEY_SA), nuovi Child SA nella nuova IKE SA (senza REKEY_SA), poi si elimina la vecchia IKE SA (che elimina anche i vecchi Child SA).
La riautenticazione stabilisce anche nuove chiavi per IKE SA e Child SA; quindi, sebbene il rekey possa essere più frequente della riautenticazione, una « durata di autenticazione » più breve della « durata delle chiavi » non ha senso.
Sebbene la creazione di una nuova IKE SA possa essere avviata da entrambe le parti (iniziatore o risponditore nella IKE SA originale), l'uso di EAP e/o payload Configuration implica in pratica che la riautenticazione sia avviata dalla stessa parte della IKE SA originale. IKEv2 attualmente non consente al risponditore di richiedere la riautenticazione in questo caso; esistono estensioni come [REAUTH].