VPNs mit Strongswan-IKEv2

IPsec gilt als komplex, schwierig zu konfigurieren und es verlangt in NAT-Netzwerken Klimmzüge. So ist es kein Wunder, dass viele Benutzer zu SSL-basierten VPN-Lösungen wie dem populären OpenVPN abwandern. Als Wurzel des Übels lässt sich Version 1 des Internet Key Exchange Protokolls (IKEv1, [1]) aus dem Jahr 1999 ausmachen, das die IPsec-Verbindung aufbaut und die VPN-Endpunkte authentisiert. Die Komplexität des Protokolls erzeugt einen ziemlichen Overhead: Es benötigt sechs Meldungen in der Phase 1 des Main Mode und drei Meldungen in der Phase 2 des Quick Mode. Das ergibt neun UDP-Datagramme, um einen IPsec-Tunnel aufzusetzen.

Da die meisten VPN-Betreiber den Aufwand von X.509-Zertifikaten scheuen, statten sie die Benutzer lieber mit althergebrachten Passwörtern aus. Der IKEv1 Main Mode unterstützt aber per Design keine Pre-Shared Keys (PSK) bei dynamischen IP-Adressen. Das hat sogar seinen Grund: Der Main-Modus von IKEv1 überträgt die Benutzeridentität verschlüsselt. Der PSK des Benutzers ist dabei Teil dieses Schlüssels. Das VPN-Gateway vermag jedoch den zum Entschlüsseln notwendigen PSK nicht zu selektieren, solange die Identität nicht bekannt ist - ein klassisches Henne-Ei-Dilemma!

Klartext bei Aggressive

Admins greifen deshalb gern zum Aggressive Mode von IKEv1, der die Identität, unglücklicherweise aber auch den PSK-Hash, im Klartext überträgt. Das macht ihn für Offline-Wörterbuch- und Brute-Force-Attacken anfällig. Als Konsequenz kombinieren viele VPNs den IKEv1 Aggressive Mode mit einem Gruppenpasswort - ein Benutzer authentisiert sich dann individuell mit Xauth (Extended Authentication), Ciscos proprietärer IKEv1-Erweiterung. Weil aber Gruppenpasswörter sich schnell zum Allgemeingut sozialisieren und sich das VPN-Gateway bei Xauth nicht mehr ausweisen muss, öffnet dies Man-in-the-Middle-Attacken Tür und Tor. Im Ergebnis spioniert ein falsches Gateway kinderleicht Xauth-Klartext-Benutzerpasswörter aus [2].

Wegen dieser Widrigkeiten erschien Ende 2005 das grundüberholte IKE-Protokoll in Version 2 (IKEv2, [3]). Es baut einen IPsec-Tunnel blitzschnell mit nur vier Meldungen, nämlich einem »IKE_SA_INIT« und einem anschließenden »IKE_AUTH«-Request-Response-Paar auf (siehe Abbildung 1). Das Protokoll verlangt jeden Request konsequent durch eine Response zu quittieren, auch bei Meldungen vom Type »INFORMATIONAL«, zum Beispiel »DELETE«-Notifications. Dadurch ist IKEv2 robuster als sein Vorgänger - bei jedem IKE-Paketverlust ist klar, was der Sender zu wiederholen hat.

Abbildung 1: IKEv2 baut Verbindungen mit nur vier Meldungen auf, einem »IKE_SA_INIT«- und einem »IKE_AUTH«-Request-Response-Paar.

IKE handelt neuerdings den Authentisierungstyp nicht mehr aus. Jede Seite authentisiert sich auf ihre Weise über eine Auth-Payload, die sie in der »IKE_AUTH«-Meldung überträgt. Das macht eine gemischte PSK/RSA- oder EAP/RSA-Authentisierung möglich. An die Stelle von Xauth tritt offiziell EAP. Das Extensible Authentication Protocol findet auch bei PPP oder der WLAN-Authentisierung mit 802.1x Anwendung.

Um Man-in-the-Middle-Attacken zu verhindern, muss sich das VPN-Gateway immer mit einer auf einem X.509-Zertifikat basierenden RSA-Signatur ausweisen. Häufige EAP-Typen sind EAP-GTC, EAP-MD5 sowie die SIM-Karten-Verfahren EAP-SIM und EAP-AKA beim GSM- und UMTS-Mobilfunk.

Einer fängt an

IKE ist zwar ein Peer-to-Peer-Protokoll zwischen Gleichen, aber einer der Endpunkte ergreift als Initiator stets die Initiative, indem er einen »IKE_SA_INIT«-Request an die Gegenstelle sendet. Die Meldung enthält eine SA1i-Payload, die eine Auswahl von kryptographischen Algorithmen für die Sicherung der IKE-Kommunikation vorschlägt, einen öffentlichen Diffie-Hellman-Faktor KEi sowie eine Zufallszahl Ni (Abbildung 2). Der Responder wählt einen Krypto-Vorschlag aus und sendet ihn als SA1r zurück und generiert ebenfalls einen Faktor KEr sowie eine Zufallszahl Nr.

Abbildung 2: Ein Endpunkt ergreift als Initiator die Initiative, indem er einen »IKE_SA_INIT«-Request an die Gegenstelle sendet. Die bestätigt den Erhalt und löst damit den »IKE_SA_AUTH«-Meldungsaustausch aus.

Zusammen mit ihren privaten Faktoren können nun beide Seiten ein gemeinsames Geheimnis berechnen, aus dem sie das Schlüsselmaterial für die gesicherte IKE-Verbindung ableiten. Da Diffie-Hellman sehr rechenintensiv ist, sendet ein Responder, wenn er einen Denial-of-Service-Verdacht hat, dem Initiator nur ein Cookie zurück, das dieser der »IKE_SA_INIT«-Wiederholung beifügen soll.

Im zweiten Schritt schickt der Initiator einen »IKE_AUTH«-Request, der die eigene Identität IDi und als Option die gewünschte Identität IDr der Gegenstelle enthält, falls sie mehrere Identitäten besitzt (Abbildung 2). Der Aufbau der Auth-Payload hängt vom Authentisierungstyp ab: Fehlt sie ganz, weiß der Responder, dass er eine EAP-Authentisierung starten muss. Ist eine digitale Signatur im Spiel, ergänzt sie der Sender optional um ein Zertifikat. Da große Zertifikate zu einer IP-Fragmentierung des UDP-Datagramms führen, überträgt der Initiator alternativ nur eine URL und einen Hash über das Zertifikat. Anhand der Informationen bezieht der Peer das Zertifikat dann via HTTP.