IKEv2 – Internet Key Exchange Version 2
Abkürzung: IKEv2
IPsec verschlüsselt Pakete, aber es klärt nicht, mit welchen Schlüsseln und mit wem. Genau das ist die Aufgabe von IKEv2: Es prüft die Gegenseite, vereinbart über Diffie-Hellman ein gemeinsames Geheimnis, legt die Schutzbeziehungen für den Nutzverkehr an und erneuert sie, solange die Verbindung besteht.
Das Protokoll läuft über UDP auf Port 500, nach dem Erkennen einer Adressumsetzung auf Port 4500. Die zweite Fassung ist eine Neuentwicklung, nicht eine Fortschreibung — sie ist als STD 79 Teil der kleinen Gruppe vollwertiger Internetstandards.
Der Ablauf
Ein vollständiger Aufbau braucht vier Nachrichten, also zwei Umläufe:
Initiator Responder
1 IKE_SA_INIT ──────────────────────────────▶
Verfahrensvorschläge, key_share, Nonce
2 ◀────────────────────────────── IKE_SA_INIT
Auswahl, key_share, Nonce
ab hier ist der weitere Austausch verschlüsselt
3 IKE_AUTH ──────────────────────────────▶
Identität, Nachweis, Vorschlag für die erste SA
4 ◀────────────────────────────── IKE_AUTH
Identität, Nachweis, Zusage
Tunnel stehtIKE_SA_INIT handelt die Verfahren aus und tauscht die Schlüsselanteile. Dieser erste Umlauf ist zwangsläufig unverschlüsselt.
IKE_AUTH läuft bereits geschützt. Erst hier nennen beide Seiten ihre Identität und belegen sie — ein wesentlicher Gewinn gegenüber der Vorgängerfassung, in deren schnellem Betriebsmodus die Identitäten offen übertragen wurden.
CREATE_CHILD_SA ist der dritte Austauschtyp. Er legt weitere Schutzbeziehungen an und übernimmt die Schlüsselerneuerung im Betrieb, ohne dass der Tunnel abreißt.
Dazu kommt INFORMATIONAL für Statusmeldungen, Fehler und den geordneten Abbau.
Schutz gegen Überlastung
Ein offener Dienst, der auf eine erste Nachricht hin sofort eine aufwendige Rechnung anstößt, ist ein verlockendes Ziel. IKEv2 hat dafür einen Rückweiser eingebaut: Unter Last antwortet der Responder zunächst nur mit einem Cookie, das der Initiator in einem erneuten Versuch zurückschicken muss. Erst dann wird gerechnet. Das kostet einen zusätzlichen Umlauf, entwertet aber Anfragen mit gefälschter Absenderadresse.
Authentifizierung
Drei Verfahren stehen zur Verfügung, und sie dürfen auf beiden Seiten unterschiedlich sein — das ist der Schlüssel zum Verständnis des Fernzugriffs:
Gemeinsames Geheimnis. Einfach einzurichten, skaliert aber nicht und ist nur so gut wie seine Länge.
Zertifikat. Nachweis über eine Signatur mit RSA oder ECDSA, geprüft gegen eine Zertifizierungsstelle. Das übliche Verfahren zwischen Standorten.
EAP. Der Rahmen für Benutzeranmeldungen, einschließlich zweitem Faktor.
Beim Remote Access ergibt sich daraus die gängige Aufteilung: Das Gateway weist sich mit einem Zertifikat aus, der Nutzer meldet sich über EAP an. Die Verbindung ist damit serverseitig kryptografisch belegt, ohne dass auf jedem Endgerät ein eigenes Zertifikat verwaltet werden muss.
Zuverlässigkeit ohne Transportprotokoll
IKEv2 läuft über UDP, muss Verluste also selbst behandeln. Es tut das mit einem strengen Wechselspiel: Jede Anfrage trägt eine laufende Nummer, auf jede Anfrage folgt genau eine Antwort, und für Wiederholungen ist ausschließlich die anfragende Seite zuständig. Dieses Modell ist der Grund, warum IKEv2 bei Paketverlust verlässlich aufräumt, wo die Vorgängerfassung in unklare Zustände geriet.
Darauf baut die Erkennung abgängiger Gegenstellen auf: Eine leere INFORMATIONAL-Nachricht verlangt eine Antwort. Bleibt sie aus, gilt die Gegenseite als nicht erreichbar und die Beziehungen werden abgeräumt. Ohne diese Prüfung bleiben nach einem Leitungsausfall auf beiden Seiten Zustände stehen, die einen Neuaufbau verhindern — eines der häufigsten Störungsbilder im Betrieb.
Adresswechsel im Betrieb
MOBIKE erlaubt es, die Adresse eines Endpunkts zu wechseln, ohne den Tunnel neu aufzubauen. Für ein Endgerät, das zwischen Mobilfunk und WLAN wechselt, ist das der Unterschied zwischen einer durchlaufenden und einer ständig abbrechenden Verbindung.
Fragmentierung
Das praktisch wichtigste Betriebsproblem entsteht bei der Authentifizierung mit Zertifikaten: Die IKE_AUTH-Nachricht trägt dann eine ganze Kette und wird größer als die Maximalgröße der Strecke. Auf IP-Ebene fragmentierte UDP-Pakete werden unterwegs häufig verworfen, womit der Aufbau genau in Schritt 3 hängen bleibt — der erste Umlauf gelingt, der zweite nicht.
RFC 7383 löst das, indem IKEv2 seine Nachrichten selbst in mehrere Pakete aufteilt, die jedes für sich durchkommen. Unterstützen beide Seiten das, verschwindet dieses Fehlerbild; unterstützt es nur eine, bleibt es bestehen.
Der Übergang zu quantensicheren Verfahren
Hier liegt die aktuelle Entwicklung, und IKEv2 ist dabei ungewöhnlich gut vorbereitet.
RFC 9370 erlaubt mehrere Schlüsseleinigungen in einem Aufbau, deren Ergebnisse gemeinsam in das Schlüsselmaterial eingehen. Das ist genau die hybride Anwendung, die das BSI für quantensichere Schlüsseleinigung verlangt: Die Verbindung bleibt sicher, solange mindestens eines der beteiligten Verfahren hält.
RFC 9242 ergänzt einen Zwischenaustausch. Er ist nötig, weil die neuen Verfahren deutlich größere Schlüssel haben und sich diese sonst nicht unterbringen ließen, ohne wieder im Fragmentierungsproblem zu landen.
RFC 8784 ist der konservative Weg: ein zusätzliches, vorab verteiltes Geheimnis, das in die Schlüsselableitung einfließt. Es schützt gegen späteres Entschlüsseln aufgezeichneten Verkehrs, ohne neue Kryptografie zu verlangen — sinnvoll dort, wo die Gegenstellen überschaubar und ohnehin verwaltet sind.
Siehe Post-Quantum-Kryptografie.
Was gegen IKEv1 spricht
RFC 9395 hat die erste Fassung förmlich abgekündigt. Die Gründe sind mehr als Altersgründe:
Der schnelle Betriebsmodus von IKEv1 überträgt die Identitäten offen und liefert bei Authentifizierung über ein gemeinsames Geheimnis einen Wert, der sich offline gegen Kandidaten nachrechnen lässt — ein schwaches Geheimnis fällt damit, ohne dass der Angreifer das Netz berühren muss. Dazu kommen zwei nicht austauschbare Betriebsmodi, eine unvollständige Verlustbehandlung, Adressumsetzung erst als Nachrüstung und ein insgesamt größerer Aufbau.
IKEv2 ist in keiner Hinsicht rückwärtskompatibel. Eine Umstellung ist deshalb immer ein Wechsel auf beiden Seiten.