1. Introduction (Einführung)
1. Introduction (Einführung)
IP Security (IPsec, IP-Sicherheit) bietet Vertraulichkeit, Datenintegrität, Zugriffskontrolle und Datenquellenauthentifizierung für IP-Datagramme. Diese Dienste werden durch die Aufrechterhaltung eines gemeinsamen Zustands zwischen Quelle und Ziel eines IP-Datagramms bereitgestellt. Dieser Zustand definiert unter anderem die spezifischen Dienste, die dem Datagramm bereitgestellt werden, welche kryptografischen Algorithmen zur Bereitstellung der Dienste verwendet werden, und die Schlüssel, die als Eingabe für die kryptografischen Algorithmen verwendet werden.
Die manuelle Einrichtung dieses gemeinsamen Zustands skaliert nicht gut. Daher wird ein Protokoll benötigt, um diesen Zustand dynamisch einzurichten. Dieses Dokument beschreibt ein solches Protokoll -- den Internet Key Exchange (IKE, Internet-Schlüsselaustausch). Version 1 von IKE wurde in den RFCs 2407 [DOI], 2408 [ISAKMP] und 2409 [IKEV1] definiert. IKEv2 ersetzte alle diese RFCs. IKEv2 wurde in [IKEV2] (RFC 4306) definiert und in [Clarif] (RFC 4718) klargestellt. Dieses Dokument ersetzt und aktualisiert RFC 4306 und RFC 4718. IKEv2 war eine Änderung des IKE-Protokolls, die nicht rückwärtskompatibel war. Im Gegensatz dazu bietet das aktuelle Dokument nicht nur eine Klarstellung von IKEv2, sondern nimmt minimale Änderungen am IKE-Protokoll vor. Eine Liste der wesentlichen Unterschiede zwischen RFC 4306 und diesem Dokument ist in Abschnitt 1.7 angegeben.
IKE führt eine gegenseitige Authentifizierung zwischen zwei Parteien durch und richtet eine IKE-Sicherheitsassoziation (IKE security association, SA) ein, die gemeinsame geheime Informationen enthält, die verwendet werden können, um effizient SAs für Encapsulating Security Payload (ESP, Kapselungssicherheitsnutzlast) [ESP] oder Authentication Header (AH, Authentifizierungsheader) [AH] einzurichten, sowie einen Satz kryptografischer Algorithmen, die von den SAs zum Schutz des von ihnen getragenen Verkehrs verwendet werden. In diesem Dokument bezieht sich der Begriff "Suite" oder "kryptografische Suite" auf einen vollständigen Satz von Algorithmen, die zum Schutz einer SA verwendet werden. Ein Initiator schlägt eine oder mehrere Suiten vor, indem er unterstützte Algorithmen auflistet, die auf Mix-and-Match-Weise zu Suiten kombiniert werden können. IKE kann auch die Verwendung von IP Compression (IPComp, IP-Kompression) [IP-COMP] in Verbindung mit einer ESP- oder AH-SA aushandeln. Die SAs für ESP oder AH, die über diese IKE-SA eingerichtet werden, nennen wir "Child SAs (Kind-SAs)".
Alle IKE-Kommunikationen bestehen aus Nachrichtenpaaren: einer Anfrage und einer Antwort. Das Paar wird als "exchange (Austausch)" bezeichnet und manchmal als "request/response pair (Anfrage/Antwort-Paar)" bezeichnet. Der erste Nachrichtenaustausch, der eine IKE-SA einrichtet, wird IKE_SA_INIT- und IKE_AUTH-Austausch genannt; nachfolgende IKE-Austausche werden CREATE_CHILD_SA- oder INFORMATIONAL-Austausche genannt. Im üblichen Fall gibt es einen einzelnen IKE_SA_INIT-Austausch und einen einzelnen IKE_AUTH-Austausch (insgesamt vier Nachrichten), um die IKE-SA und die erste Kind-SA einzurichten. In Ausnahmefällen kann es mehr als einen von jedem dieser Austausche geben. In allen Fällen müssen alle IKE_SA_INIT-Austausche vor jedem anderen Austauschtyp abgeschlossen werden, dann müssen alle IKE_AUTH-Austausche abgeschlossen werden, und danach kann eine beliebige Anzahl von CREATE_CHILD_SA- und INFORMATIONAL-Austauschen in beliebiger Reihenfolge stattfinden. In einigen Szenarien wird nur eine einzelne Kind-SA zwischen den IPsec-Endpunkten benötigt, und daher würde es keine zusätzlichen Austausche geben. Nachfolgende Austausche können verwendet werden, um zusätzliche Kind-SAs zwischen demselben authentifizierten Endpunktpaar einzurichten und Wartungsfunktionen auszuführen.
Ein IKE-Nachrichtenfluss besteht immer aus einer Anfrage, gefolgt von einer Antwort. Es liegt in der Verantwortung des Anfragenden, die Zuverlässigkeit sicherzustellen. Wenn die Antwort nicht innerhalb eines Timeout-Intervalls empfangen wird, muss der Anforderer die Anfrage erneut übertragen (oder die Verbindung aufgeben).
Der erste Austausch einer IKE-Sitzung, IKE_SA_INIT, handelt Sicherheitsparameter für die IKE-SA aus, sendet Nonces und sendet Diffie-Hellman-Werte.
Der zweite Austausch, IKE_AUTH, überträgt Identitäten, beweist die Kenntnis der den beiden Identitäten entsprechenden Geheimnisse und richtet eine SA für die erste (und oft einzige) AH- oder ESP-Kind-SA ein (es sei denn, das Einrichten der AH- oder ESP-Kind-SA schlägt fehl, in diesem Fall wird die IKE-SA dennoch ohne die Kind-SA eingerichtet).
Die Typen nachfolgender Austausche sind CREATE_CHILD_SA (das eine Kind-SA erstellt) und INFORMATIONAL (das eine SA löscht, Fehlerbedingungen meldet oder andere Wartungsarbeiten durchführt). Jede Anfrage erfordert eine Antwort. Eine INFORMATIONAL-Anfrage ohne Nutzdaten (außer der von der Syntax geforderten leeren verschlüsselten Nutzdaten) wird häufig als Lebendigkeitsprüfung verwendet. Diese nachfolgenden Austausche können nicht verwendet werden, bis die anfänglichen Austausche abgeschlossen sind.
In der folgenden Beschreibung gehen wir davon aus, dass keine Fehler auftreten. Änderungen am Ablauf bei Auftreten von Fehlern werden in Abschnitt 2.21 beschrieben.