1. Introduction (Introduzione)

IP Security (IPsec) fornisce riservatezza, integrità dei dati, controllo di accesso e autenticazione dell'origine ai datagrammi IP. Tali servizi si ottengono mantenendo stato condiviso tra sorgente e destinazione. Lo stato definisce, tra l'altro, i servizi offerti al datagramma, gli algoritmi crittografici e le chiavi in ingresso agli algoritmi.

Creare manualmente questo stato non scala. Serve un protocollo per stabilirlo dinamicamente. Questo documento descrive l'Internet Key Exchange (IKE). La versione 1 era definita nei RFC 2407 [DOI], 2408 [ISAKMP] e 2409 [IKEV1]. IKEv2 ha sostituito tutti questi RFC. IKEv2 è definito in [IKEV2] (RFC 4306) e chiarito in [Clarif] (RFC 4718). [RFC5996] ha sostituito e aggiornato i RFC 4306 e 4718. Questo documento sostituisce il RFC 5996. IKEv2 nel RFC 4306 era una modifica non retrocompatibile. Il RFC 5996 ha rivisto il 4306 chiarendo IKEv2 con cambiamenti minimi. Questo documento sostituisce il 5996 con lievi revisioni per la promozione a Internet Standard. Le differenze significative tra RFC 4306 e 5996 sono nella sezione 1.7, tra RFC 5996 e questo documento nella 1.8.

IKE esegue autenticazione reciproca e stabilisce una IKE Security Association (SA) con segreti condivisi per creare efficientemente SA per Encapsulating Security Payload (ESP) [ESP] o Authentication Header (AH) [AH] e algoritmi per proteggere il traffico. Qui "suite" o "cryptographic suite" indica l'insieme completo di algoritmi per una SA. L'initiator propone una o più suite elencando algoritmi combinabili. IKE può negoziare anche IP Compression (IPComp) [IP-COMP] con SA ESP o AH. Le SA ESP/AH create tramite quella IKE SA sono "Child SAs".

Tutte le comunicazioni IKE sono coppie richiesta/risposta ("exchange" o "request/response pair"). I primi due scambi sono IKE_SA_INIT e IKE_AUTH; poi CREATE_CHILD_SA o INFORMATIONAL. Di solito un IKE_SA_INIT e un IKE_AUTH (quattro messaggi) per IKE SA e prima Child SA; eccezionalmente di più. In ogni caso tutti gli IKE_SA_INIT DEVONO completarsi prima di ogni altro tipo, poi tutti gli IKE_AUTH, quindi un numero qualsiasi di CREATE_CHILD_SA e INFORMATIONAL in qualsiasi ordine. A volte basta una Child SA senza ulteriori scambi. Scambi successivi POSSONO aggiungere Child SA tra le stesse estremità autenticate e funzioni di manutenzione.

Un flusso IKE è sempre richiesta poi risposta. Chi richiede garantisce l'affidabilità. Senza risposta entro un timeout deve ritrasmettere o abbandonare.

Il primo scambio IKE_SA_INIT negozia parametri IKE SA, invia nonce e valori Diffie-Hellman.

Il secondo IKE_AUTH trasporta identità, prova la conoscenza dei segreti e crea la prima Child SA AH/ESP (se fallisce la Child SA, resta l'IKE SA senza Child SA).

Scambi successivi: CREATE_CHILD_SA (nuova Child SA) e INFORMATIONAL (cancellazione SA, errori, manutenzione). Ogni richiesta richiede risposta. Una richiesta INFORMATIONAL senza payload (salvo Encrypted vuoto richiesto dalla sintassi) spesso verifica l'attività. Non usabili prima degli scambi iniziali.

Si assume assenza di errori; le modifiche in caso di errore sono nella sezione 2.21.

1. Introduction (Introduzione)​

Contents​

1. Introduction (Introduzione)

Contents