1. Introduction (Introduzione)
1. Introduction (Introduzione)
IP Security (IPsec, Sicurezza IP) fornisce riservatezza, integrità dei dati, controllo degli accessi e autenticazione della sorgente dei dati ai datagrammi IP. Questi servizi sono forniti mantenendo uno stato condiviso tra la sorgente e la destinazione di un datagramma IP. Questo stato definisce, tra le altre cose, i servizi specifici forniti al datagramma, quali algoritmi crittografici verranno utilizzati per fornire i servizi e le chiavi utilizzate come input per gli algoritmi crittografici.
Stabilire questo stato condiviso in modo manuale non scala bene. Pertanto, è necessario un protocollo per stabilire questo stato dinamicamente. Questo documento descrive tale protocollo: l'Internet Key Exchange (IKE, scambio di chiavi Internet). La versione 1 di IKE è stata definita nelle RFC 2407 [DOI], 2408 [ISAKMP] e 2409 [IKEV1]. IKEv2 ha sostituito tutte queste RFC. IKEv2 è stato definito in [IKEV2] (RFC 4306) ed è stato chiarito in [Clarif] (RFC 4718). Questo documento sostituisce e aggiorna RFC 4306 e RFC 4718. IKEv2 è stato una modifica al protocollo IKE che non era retrocompatibile. Al contrario, il documento attuale non solo fornisce un chiarimento di IKEv2, ma apporta modifiche minime al protocollo IKE. Un elenco delle differenze significative tra RFC 4306 e questo documento è fornito nella sezione 1.7.
IKE esegue l'autenticazione reciproca tra due parti e stabilisce un'associazione di sicurezza IKE (IKE security association, SA) che include informazioni segrete condivise che possono essere utilizzate per stabilire efficientemente SA per Encapsulating Security Payload (ESP, payload di sicurezza incapsulante) [ESP] o Authentication Header (AH, intestazione di autenticazione) [AH] e un insieme di algoritmi crittografici da utilizzare dalle SA per proteggere il traffico che trasportano. In questo documento, il termine "suite" o "suite crittografica" si riferisce a un insieme completo di algoritmi utilizzati per proteggere una SA. Un iniziatore propone una o più suite elencando gli algoritmi supportati che possono essere combinati in suite in modo misto. IKE può anche negoziare l'uso della compressione IP (IPComp) [IP-COMP] in connessione con una SA ESP o AH. Le SA per ESP o AH che vengono configurate tramite quella SA IKE le chiamiamo "Child SAs (SA figlio)".
Tutte le comunicazioni IKE consistono in coppie di messaggi: una richiesta e una risposta. La coppia è chiamata "exchange (scambio)", e talvolta è chiamata "request/response pair (coppia richiesta/risposta)". Il primo scambio di messaggi che stabilisce una SA IKE è chiamato scambio IKE_SA_INIT e IKE_AUTH; gli scambi IKE successivi sono chiamati scambi CREATE_CHILD_SA o INFORMATIONAL. Nel caso comune, c'è un singolo scambio IKE_SA_INIT e un singolo scambio IKE_AUTH (un totale di quattro messaggi) per stabilire la SA IKE e la prima SA figlio. In casi eccezionali, può esserci più di uno di ciascuno di questi scambi. In tutti i casi, tutti gli scambi IKE_SA_INIT devono completarsi prima di qualsiasi altro tipo di scambio, quindi tutti gli scambi IKE_AUTH devono completarsi, e successivamente, un numero qualsiasi di scambi CREATE_CHILD_SA e INFORMATIONAL può verificarsi in qualsiasi ordine. In alcuni scenari, è necessaria solo una singola SA figlio tra gli endpoint IPsec, e quindi non ci sarebbero scambi aggiuntivi. Gli scambi successivi possono essere utilizzati per stabilire SA figlio aggiuntive tra la stessa coppia di endpoint autenticati e per eseguire funzioni di manutenzione.
Un flusso di messaggi IKE consiste sempre in una richiesta seguita da una risposta. È responsabilità del richiedente garantire l'affidabilità. Se la risposta non viene ricevuta entro un intervallo di timeout, il richiedente deve ritrasmettere la richiesta (o abbandonare la connessione).
Il primo scambio di una sessione IKE, IKE_SA_INIT, negozia i parametri di sicurezza per la SA IKE, invia nonce e invia valori Diffie-Hellman.
Il secondo scambio, IKE_AUTH, trasmette le identità, dimostra la conoscenza dei segreti corrispondenti alle due identità e configura una SA per la prima (e spesso unica) SA figlio AH o ESP (a meno che non vi sia un fallimento nella configurazione della SA figlio AH o ESP, nel qual caso la SA IKE viene comunque stabilita senza la SA figlio).
I tipi di scambi successivi sono CREATE_CHILD_SA (che crea una SA figlio) e INFORMATIONAL (che elimina una SA, segnala condizioni di errore o esegue altre operazioni di manutenzione). Ogni richiesta richiede una risposta. Una richiesta INFORMATIONAL senza payload (diverso dal payload crittografato vuoto richiesto dalla sintassi) è comunemente utilizzata come controllo di vitalità. Questi scambi successivi non possono essere utilizzati fino al completamento degli scambi iniziali.
Nella descrizione che segue, assumiamo che non si verifichino errori. Le modifiche al flusso quando si verificano errori sono descritte nella sezione 2.21.