1. Introduction (Einführung)

IP Security (IPsec) bietet Vertraulichkeit, Datenintegrität, Zugriffskontrolle und Datenursprungsauthentifizierung für IP-Datagramme. Diese Dienste werden durch gemeinsamen Zustand zwischen Quelle und Senke eines IP-Datagramms bereitgestellt. Dieser Zustand definiert unter anderem die konkreten Dienste für das Datagramm, die kryptografischen Algorithmen und die als Eingabe dienenden Schlüssel.

Manuelles Aufsetzen dieses Zustands skaliert schlecht. Daher wird ein Protokoll zur dynamischen Einrichtung benötigt. Dieses Dokument beschreibt das Internet Key Exchange (IKE). IKE Version 1 war in RFC 2407 [DOI], 2408 [ISAKMP] und 2409 [IKEV1] definiert. IKEv2 ersetzte alle diese RFCs. IKEv2 war in [IKEV2] (RFC 4306) definiert und in [Clarif] (RFC 4718) geklärt. [RFC5996] ersetzte und aktualisierte RFC 4306 und 4718. Dieses Dokument ersetzt RFC 5996. IKEv2 gemäß RFC 4306 war eine nicht abwärtskompatible Änderung. RFC 5996 überarbeitete RFC 4306 zur Klärung von IKEv2 mit minimalen Protokolländerungen. Dieses Dokument ersetzt RFC 5996 und überarbeitet es geringfügig für den Aufstieg zu einem Internet Standard. Wesentliche Unterschiede zwischen RFC 4306 und 5996 stehen in Abschnitt 1.7, Unterschiede zwischen RFC 5996 und diesem Dokument in Abschnitt 1.8.

IKE führt gegenseitige Authentifizierung durch und etabliert eine IKE Security Association (SA) mit gemeinsamen Geheimnissen zum effizienten Aufbau von SAs für Encapsulating Security Payload (ESP) [ESP] oder Authentication Header (AH) [AH] sowie Algorithmen zum Schutz des Datenverkehrs. In diesem Dokument bezeichnet „suite“ oder „cryptographic suite“ die vollständige Algorithmenmenge für eine SA. Der Initiator schlägt eine oder mehrere Suites vor, indem er unterstützte Algorithmen kombinierbar auflistet. IKE kann auch IP Compression (IPComp) [IP-COMP] zu ESP- oder AH-SAs aushandeln. Über diese IKE SA aufgebaute ESP- oder AH-SAs heißen „Child SAs“.

Alle IKE-Kommunikation besteht aus Nachrichtenpaaren: Anfrage und Antwort. Das Paar heißt „exchange“ oder „request/response pair“. Die ersten beiden Austausche zum Aufbau einer IKE SA sind IKE_SA_INIT und IKE_AUTH; danach CREATE_CHILD_SA oder INFORMATIONAL. Üblich sind je ein IKE_SA_INIT und IKE_AUTH (vier Nachrichten) für IKE SA und erste Child SA. Ausnahmsweise kann es mehrere geben. In jedem Fall MÜSSEN alle IKE_SA_INIT zuerst abgeschlossen sein, dann alle IKE_AUTH, danach beliebig viele CREATE_CHILD_SA und INFORMATIONAL in beliebiger Reihenfolge. Manchmal genügt eine Child SA, dann gibt es keine weiteren Austausche. Spätere Austausche KÖNNEN weitere Child SAs zwischen denselben authentifizierten Endpunkten und Wartungsfunktionen dienen.

Ein IKE-Nachrichtenfluss ist immer Anfrage gefolgt von Antwort. Der Anforderer sorgt für Zuverlässigkeit. Ohne Antwort innerhalb eines Timeouts muss er retransmitieren oder abbrechen.

Der erste Austausch IKE_SA_INIT verhandelt Sicherheitsparameter der IKE SA, sendet Nonces und Diffie-Hellman-Werte.

Der zweite IKE_AUTH überträgt Identitäten, beweist Kenntnis der zugehörigen Geheimnisse und richtet die erste (oft einzige) AH- oder ESP-Child-SA ein (scheitert deren Aufbau, bleibt die IKE SA ohne Child SA).

Spätere Typen sind CREATE_CHILD_SA (neue Child SA) und INFORMATIONAL (SA löschen, Fehler, sonstige Wartung). Jede Anfrage braucht eine Antwort. Eine INFORMATIONAL-Anfrage ohne Nutzlasten (außer der leeren Encrypted-Payload) dient oft als Lebendigkeitstest. Diese Austausche erst nach den initialen.

Im Folgenden wird fehlerfreier Ablauf angenommen. Fehlerfälle stehen in Abschnitt 2.21.

1. Introduction (Einführung)​

Contents​

1. Introduction (Einführung)

Contents