© Maximilien Brice, CERN (Wikipedia)

Das Protokoll IKEv2 möbelt das etwas verstaubte IPsec ordentlich auf. Zwei Entwickler erläutern die Vorteile des Designs gegenüber IKEv1 anhand ihrer Linux-Implementierung Strongswan.

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.

Selektoren als Basis

Eine Besonderheit von IKEv2 ist, dass das Protokoll CHILD_SAs direkt in die IKE_AUTH-Meldung mit einschließt. Der Responder trifft unter den Vorschlägen eine Auswahl SA2r und sendet die – jetzt eventuell eingeengten -Traffic-Selektoren TSi und TSr zurück.

Sind dann noch weitere Subnetze zwischen den beiden VPN-Endpunkten zu tunneln, so lassen sich zusätzliche Traffic-Selektoren mit einem »CREATE_CHILD_SA«-Paar aufsetzen (Abbildung 3). Auch das periodische Erneuern der Sessionschlüssel – sowohl für die IKE-Verbindung selbst (»IKE_SA«) als auch für die IPsec-Nutzverbindung (»CHILD_SA«) – bewerkstelligen »CREATE_CHILD_SA« und eine darin enthaltene Rekeying-Notification N. Ist Perfect Forward Secrecy (PFS) gewünscht, generiert der Benutzer mit den frischen Diffie-Hellman-Faktoren KEi und KEr neues Schlüsselmaterial, das nicht von der Vorgeschichte abhängt.

Abbildung 3: Der »CREATE_CHILD_SA«-IKE-Meldungsaustausch läuft paarweise ab.

Als wesentliche Verbesserung zu IKEv1, wo die im Quick Mode ausgetauschten Traffic-Selektoren exakt übereinstimmen müssen, damit eine IPsec-Verbindung zustande kommt, wendet IKEv2 ein so genanntes Narrowing an, bei dem die Gegenseite die Traffic-Selektoren einengen darf. So schlägt im Extremfall ein VPN-Client mit 0.0.0.0/0 das gesamte Internet vor und das VPN-Gateway beschränkt dies auf das zulässige interne Netzwerk, beispielsweise 10.1.0.0/16.

IKEv2 kann die NAT-Situation des vorliegenden Netzes bestimmen und kapselt die IPsec-ESP-Pakete automatisch in UDP-Datagramme, wenn nötig. Die Frage, ob die andere VPN-Seite noch reagiert (Dead Peer Detection, DPD), beantwortet das Protokoll elegant, indem es »INFORMATIONAL«-Requests periodisch sendet, um Responses als stetige Lebenszeichen von der Gegenstelle zu erhalten.

VPN auch unterwegs

Das IKEv2 Mobility and Multihoming Protocol (Mobike, [4]) erlaubt die IP-Adresse oder des Netzwerkinterfaces fliegend zu wechseln, ohne den IPsec-Tunnel neu aufzubauen – ähnlich wie OpenVPN das kann. Ändert sich die Netzwerksituation, sendet der Initiator IKEv2-»INFORMATIONAL«-Meldungen an alle IP-Adressen des Responders, welche dieser beim Verbindungsaufbau über »ADDITIONAL_IP4_ADDRESSES«-Notifications in der »IKE_AUTH«-Response bekannt gemacht hat. Auf Basis der erfolgreichen Rückantworten bestimmt der Initiator die optimale Route neu und sendet eine »UPDATE_SA_ADDRESSES«-Notification an seine Gegenstelle. Diese passt dann abschließend die bestehenden IPsec-Verbindungen an die neue Netzwerksituation an.

IKEv2 für Linux

Bekannte IKEv2-Implementierungen sind Ikev2 [5], Open IKEv2 [6], Openswan [7] sowie Racoon2 [8]. Leider setzen alle den IKEv2-Standard nur partiell um und zeigten im vorigen Jahr keine oder nur geringe Entwicklungsaktivitäten.

Strongswan [9] ist eine vollständige IKEv1- und IKEv2-Open-Source-Implementation, die das Institut für Internet-Technologien und -Anwendungen (ITA) der Hochschule für Technik Rapperswil in der Schweiz aktiv wartet und weiterentwickelt, was die monatlichen Updates seit Jahren bezeugen.

01 conn remote
02      leftcert=selfCert.der
03      leftsubnet=10.1.0.0/16
04      rightsourceip=10.3.0.0/22
05      rightid=*@example.org
06      eap=gtc
07      authby=rsasig
08      keyexchange=ikev2
09      auto=add

01 charon {
02   plugins {
03     eap_gtc {
04       pam_service = ipsec
05     }
06   }
07 }

Strongswan modular

Während die Entwickler den IKEv1-Pluto-Daemon aus dem Freeswan-Projekt übernommen haben, ist ihr IKEv2-Daemon Charon eine echte Neuentwicklung, bei dem, obwohl zu 100 Prozent in C geschrieben, moderne objektorientierte Ansätze zur Anwendung kamen. Durch den Einsatz von Multithreading erzielt der neue Daemon auf mehreren Prozessoren einen hohen Durchsatz.

Um den skalierbaren Einsatz von Strongswan vom schlanken Desktop-Client bis hin zum VPN-Gateway mit 16 Cores und 20 000 gleichzeitigen IPsec-Verbindungen zu ermöglichen, haben die Strongswan-Entwickler ihren 4.2-Entwicklungszweig radikal auf eine modulare Architektur umgebaut. Eine wachsende Anzahl von Plugins sowie eine Reihe von Tuning-Parametern, aktivierbar in der neuen »/etc/strongswan.conf«, erlauben es, Strongswan gezielt auf vielfältige Einsatzarten zuzuschneiden (siehe Kasten “Strongswan – ein Einsatzbeispiel”).

./configure -prefix=/usr --sysconfdir=/etc --enable-eap-gtc

auth sufficient pam_unix.so likeauth nullok
auth required pam_deny.so

In traditioneller Freeswan-Manier definieren Admins die IPsec-Konfigurationen in »/etc/ipsec.conf« und Pre-Shared-Keys in »/etc/ipsec.secrets«, während sie X.509-Zertifikate und RSA-Schlüssel als Dateien im »/etc/ipsec.d/«-Verzeichnisbaum ablegen. Mit dem generischen SQL-Plugin (»–enable-sql«) sowie entweder einem SQLite- (»–enable-sqlite«) oder MySQL-Datenbankinterface (»–enable-mysql«) lassen sich Konfigurationsdaten und User-Credentials alternativ in einer relationalen Datenbank speichern.

Dies gilt auch für die Verwaltung von virtuellen IP-Adressen, die ein VPN-Gateway via IKEv2 Configuration Payload (CP) an einen VPN-Client vergeben kann. In der simpelsten Version genügt

conn remote
     right=%any
     rightsourceip=10.3.0.0/22

in der »ipsec.conf« des VPN-Gateway als Beispiel, um maximal 1022 IP-Adressen aus dem Pool 10.3.0.1 bis 10.3.3.254 zu vergeben. Da die Zuordnung der Adressen zu den Clients im RAM liegt, geht sie bei einem Neustart des Gateway verloren. Die nicht-flüchtige “Voll”-Version legt mit dem Befehl

ipsec pool --add bigpool --start 10.3.0.1 --end 10.3.255.254 --timeout 48

einen permanenten Pool in einer relationalen Datenbank an, die in der »strongswan.conf« definiert sein muss:

charon {
  plugins {
    sql {
      database = sqlite:///etc/ipsec.d/ipsec.db
    }
  }
}

Die »–timeout 48«-Option hält eine IP-Adresse bis zu 48 Stunden für den Client reserviert, den sie zuletzt freigegeben hat. Der Default »–timeout 0« weist statisch zu. Die Referenzierung in der »ipsec.conf« erfolgt über den Namen des Pools:

rightsourceip=%bigpool

Alle kryptographischen Funktionen sind ebenfalls als problemlos austauschbare Plugins realisiert. Wer zum Beispiel das OpenSSL-Plugin lädt (»–enable-openssl«), kann Diffie-Hellman-Gruppen und X.509-Zertifikate basierend auf elliptischen Kurven verwenden, die eine effizientere Alternative zu den immer größer werdenden RSA-Modulen darstellen. Wenn es sich als notwendig erweist, den IKEv2-Durchsatz zu großen VPN-Gateways weiter zu steigern, kann der Admin dedizierte Krypto-Hardware relativ einfach anflanschen, wenn sie eine OpenSSL Schnittstelle besitzt, was oft der Fall ist.

Strongswan-Client im Networkmanager

Nutzer, die Strongswan gern mit einem grafischen Frontend konfigurieren möchten, greifen zu dem Plugin für den Gnome Networkmanager 0.7 (»–enable-nm«). Die Quellen gibt es unter [11], fertige Ubuntu-Packages unter [12]. Zum Einrichten der VPN-Verbindung ruft der Benutzer dann das Networkmanager-Applet auf und konfiguriert die IP-Adresse des Gateway, das selbst signierte Gateway-Zertifikat und seine Identität in der Form einer E-Mail-Adresse (Abbildung 4). Zusätzlich kann er per Checkbox-Häkchen eine virtuelle IP-Adresse vom Gateway beziehen. Wer mit einer Firewall zu kämpfen hat, die ESP-Pakete verwirft, erzwingt die angebotene UDP-Kapselung von IPsec-Nutzpaketen.

Abbildung 4: Mit dem Gnome Networkmanager und dem passenden Applet gelingt die Strongswan-Konfiguration unter grafischer Oberfläche.

Beim Verbindungsaufbau fordert ein Fenster den Nutzer zur Eingabe seines Passworts auf, das er optional im Gnome-Keyring sicher speichern darf. Das Konfigurieren von Subnetzen ist unnötig, da der Client »0.0.0.0/0« vorschlägt und das Gateway ein Narrowing auf ein internes Subnetz vornimmt. Das Networkmanager-Plugin bietet noch andere Möglichkeiten der Authentisierung. Ist eine PKI vorhanden, kann sich auch der Client via X.509-Zertifikat ausweisen. Ein bereits vorhandener SSH-Agent lässt sich für die IKE-Authentisierung heranziehen, auch mit Chipkarte.

Was 2009 vom Projekt zu erwarten ist

Die kürzlich entwickelte PFKEYv2-Kernel-Schnittstelle, die alternativ zu XFRM Netlink mit dem Linux-IPsec-Stack kommuniziert, macht eine Portierung auf BSD und damit auf Mac OS X möglich, da die KAME-IPsec-Implementation dieser Betriebsysteme mit einem PFKEYv2-Interface ausgerüstet ist.

Hohe Verfügbarkeit und Loadbalancing in großen VPN-Gateway-Anwendungen sind weitere Themen, die das Strongswan-Team beschäftigen. Zunächst auf zwei Rechner beschränkt, aber später erweiterbar auf einen Cluster von mehreren Maschinen, wird sich die IKE- und IPsec-Last gleichmäßig auf die einzelnen Serverinstanzen verteilen. Beim Ausfall eines Rechners übernehmen andere Clustermitglieder dessen Verbindungen automatisch, ohne dass die IPsec-Tunnel zusammenbrechen. Mit diesem Feature, dessen Freigabe für Ende 2009 geplant ist, will Strongswan in die Liga der professionellen Gateways aufsteigen. (jk)