Einfacher VPN-Tunnelbau dank IKEv2

Inhaltsverzeichnis

Der IPSec-Standard hat den Ruf, schwierig in der Konfiguration und im Betrieb zu sein. Schuld daran ist zum größten Teil die hohe Komplexität des Schlüsselaustausch-Protokolls IKE: Nicht selten scheitert der Verbindungsaufbau wegen minimaler Einstellungsunterschiede auf den Endgeräten - oftmals gerade dann, wenn sich Produkte unterschiedlicher Hersteller miteinander unterhalten sollen. Zudem lässt etwa die Fülle der kryptografischen Optionen beim Einrichten einer Verbindung einen Administrator verzweifeln, was unter Umständen zu unsicheren Konfigurationen führt, damit es überhaupt zu einer Verbindung kommt. In einer vielbeachteten Studie schrieben die Krypto-Gurus Niels Ferguson und Bruce Schneier dem IPSec-Standard aufgrund seiner Komplexität potenzielle Sicherheitsrisiken zu [1]. Auch die Authentifizierungsoptionen wirken kaum wie aus einem Guss und nicht zuletzt hadert das rudimentäre IKEv1 mit der weit verbreiteten Network Adress Translation (NAT), dynamischen IP-Adressen sowie mobilen Endgeräten. Deshalb sind viele Benutzer in den letzten Jahren zu SSL-basierten VPNs wie OpenVPN abgewandert, die sich wesentlich einfacher konfigurieren und betreiben lassen [2].

Jetzt will man es besser machen und hat dazu die IPSec- und IKE-Standards überarbeitet. IPSec wurde geringfügig erweitert, wobei die kryptografischen Änderungen den größten Teil ausmachen. Während in der ersten Version von IPSec die einfache DES-Verschlüsselung für den Tunnelmode ESP noch Pflicht war, so rät der neue RFC 4305 nun stark davon ab, einen nur 56 Bit langen Schlüssel einzusetzen - den schon fast jeder Fachmann mit ausreichendem Equipment über das Wochenende knacken kann. Der Standard-Algorithmus bleibt weiterhin die dreifache DES-Verschlüsselung mit einer nominellen Schlüssellänge von 168 Bit. Alternativ wird der Advanced Encryption Standard (AES) mit 128 Bit Schlüssellänge empfohlen. Besonders vorsichtige Anwender können die AES-Schlüssellänge optional auf 256 Bit erhöhen, müssen aber einen zusätzlichen Rechenaufwand von rund 40 Prozent in Kauf nehmen.

Der Hauptteil der Änderungen bezog sich auf IKE. Zunächst ist IKEv2 in einem einzigen RFC-Dokument (4306) zusammengefasst, statt über diverse RFCs als Framework verteilt zu sein [3]. Augenfällig bei IKEv2 ist der beschleunigte Verbindungsaufbau: Den klassischen Main/Aggressive Mode und den Quick Mode gibt es nicht mehr. Benötigte das Vorgängerprotokoll IKEv1 noch sechs Meldungen für den Main Mode und drei weitere für den Quick Mode, also zusammen neun Nachrichten, so reichen bei IKEv2 im Normalfall vier Meldungen aus, um eine IPSec-Verbindung aufzubauen (siehe auch Kasten). Damit kommt die Verbindung schneller zustande, inbesondere bei Störungen steht der Tunnel recht fix wieder. IKEv2 verzichtet zudem auf einen präventiven Cookie-Austausch, der Gateways vor Denial-of-Service-Attacken mit gespooften Adressen schützen soll, womit sich zwei weitere Meldungen einsparen lassen. Die Entscheidung gegen den Cookie-Austausch rührt aus der Erfahrung her, dass in den letzten Jahren kaum Probleme aufgrund von DoS-Angriffen gegen VPN-Gateways verzeichnet wurden.

Bei IKEv1 war die Verantwortlichkeit bei Paketverlusten nicht klar geregelt, sodass oftmals beide Seiten gleichzeitig ihre zuletzt gesendeten Meldungen wiederholten, was für Verwirrung bei den Peers sorgte und damit der Verbindungsstabilität abträglich war. Unter IKEv2 sind die Zuständigkeiten der Peers klarer geregelt: Es gibt nur Meldungspaare, die aus einem Request eines Initiators und einer quittierenden Antwort eines Responders bestehen. Dabei ist beim Ausbleiben einer Response allein der Initiator für die zeitlich gestaffelten Meldungswiederholungsversuche zuständig. Kommt keine IPSec-Verbindung zustande, sendet der Responder differenzierte Fehlermeldungen (Notify Payload) an den Absender, woran der Versuch gescheitert ist. Anders als unter IKEv1 ist damit eine leichtere Fehlersuche möglich.

Um auch über NAT-Router hinweg eine Verbindung aufbauen zu können, ist NAT-Traversal nun fester Bestandteil von IKEv2, wobei die Unterstützung dieser Option von den Endgeräten nicht mehr über ein Vendor-ID-Feld mitgeteilt wird. Vielmehr signalisieren die Peers bereits im ersten IKE_SA_INIT-Request, dass sie NAT-Traversal unterstützen. Dazu senden sie im Header einen NAT-Discovery-Hash mit. Stellen beide Peers dann eine NAT-Situation fest, wechseln sie automatisch auf den UDP-Port 4500, um darüber den weiteren IPSec-Verkehr mittels UDP-Encapsulation abzuwickeln.

Es lebt!

Es lebt!

Auch die Dead Peer Detection (DPD), die unter IKEv1 als Zusatzprotokoll definiert ist, wird unter IKEv2 relativ einfach gelöst. IKEv2 kennt eine INFORMATIONAL-Meldung, die ebenfalls durch die Gegenseite quittiert werden muss und dazu verwendet wird, Fehlermeldungen oder das Löschen von Verbindungen zu übermitteln. Durch periodisches Senden eines leeren INFORMATIONAL-Requests kann eine Peer die Erreichbarkeit des Partners ständig überprüfen. Kommt keine Antwort zurück, wird der normale Meldungswiederholungszyklus gefahren. Kommt dann immer noch keine Antwort, wird die Gegenseite für tot erklärt und das Endgerät löscht die mittels IKE ausgehandelten Security Associations (IKE-SAs) und dazugehörige CHILD_SAs, in denen die verwendeten Verschlüsselungsalgorithmen und andere Parameter festgehalten sind.

Apropos CHILD_SAs: Sie sind äquivalent zu den IPSec-SAs, in denen die Parameter zum Schutz des eigentlichen Paket-Tunnels abgelegt sind. Die Informationen für die initialen CHILD_SAs werden bereits mit den dritten und vierten IKE-Nachrichten übertragen, sodass anschließend der Tunnel steht. Dazu gehören auch die sogenannten Traffic Selectors, mit denen die Endgeräte ihre Wünsche anmelden, welche Subnetze über den Tunnel gekoppelt werden sollen. Dabei lässt sich sogar der Zugriff auf bestimmte Ports und Adressbereiche einengen, was den Einsatz eines zusätzlichen Paketfilters erspart. Sollen innerhalb einer bestehenden Verbindung weitere Subnetze gekoppelt werden, so reicht der Austausch zweier CREATE_CHILD_SA-Nachrichten. Auch die Erneuerung abgelaufener Schlüssel in den IPSsec-Modi ESP und AH wickeln die Peers über CHILD_SAs ab.

Flexiblere Authentifizierung

Einige proprietäre Protokollerweiterungen für IKv1 haben es nach zähen Verhandlungen innerhalb der IETF IPSec Working Group geschafft, einen offiziellen Platz im IKEv2-RFC zu bekommen. So wurde für die Zuteilung einer virtuellen IP-Adresse sowie der Bekanntmachung der internen DNS- und WINS-Server etwa eines Unternehmensnetzes eine reguläre Configuration Payload geschaffen. Unter IKEv1 ließ sich dies nur über die sogenannte Config-Mode-Erweiterung bewerkstelligen, die nicht alle Hersteller unterstützen.

Auch ein Hybrid-Authentifizierungsmodus wird nun offiziell unterstützt: In einem Remote-Access-Szenario kann sich das zentrale VPN-Gateway mit einer durch ein Zertifikat beglaubigten RSA-Signatur ausweisen, während die Clients althergebrachte Pre-Shared Keys (PSKs) verwenden können, so dass man auf eine aufwendige Public-Key-Infrastruktur verzichten kann. Alternativ zum Übermitteln des Zertifikats bietet IKEv2 die Möglichkeit, nur eine URL zu senden, von der die Gegenstelle ein Zertifikat zur Verifizierung herunterladen kann. Mit dieser Variante umgeht man Probleme bei der Übermittlung großer Zertifikate mittels fragmentierter UDP-Pakete, die Router oder Firewalls unter Umständen verwerfen.

Auch Ciscos XAUTH-Protokoll, das zwar nie einen offiziellen RFC-Status erlangt hat, aber dennoch von sehr vielen VPN-Herstellern eingesetzt wird, ist noch zu späten Ehren gekommen. Musste bei IKEv1 zwischen Main Mode und Quick Mode noch eine spezielle "Phase 1.5" eingelegt werden, damit zusätzliche Client-Authentifizierungsmechanismen wie RADIUS, SecurID und andere zum Einsatz kommen konnten, fordert der Initiator bei IKEv2 durch bewusstes Auslassen der PSK oder RSA-AUTH-Payload das VPN-Gateway auf, das aus PPP-Dialup-Verbindungen altbekannte Extensible Authentication Protocol (EAP) zu starten. Ähnlich wie beim WLAN-Sicherheitsstandard IEEE 802.1x ist es damit möglich, sämtliche denkbaren erweiterten Authentifizierungsprotokolle einzubeziehen. Darunter fallen Hardware-Token, die Einmalpasswörter generieren, aber auch die aus dem Mobilfunkbereich bekannten Verfahren EAP-SIM und EAP-AKA, die auf der SIM- respektive USIM-Chipkarte aufsetzen. Das EAP-Protokoll wird über eine IKEv2 EAP Payload abgewickelt. Um aber die unter IKEv1 durch die Kombination von IKE-Aggressive-Mode und XAUTH-Client-Authentisierung möglichen Man-in-the-Middle-Attacken effektiv zu verhindern, schreibt der IKEv2-Standard vor, dass sich das VPN Gateway gegenüber dem EAP-Client mit einer RSA-Signatur ausweisen muss, so dass keine Täuschung möglich ist.

MOBIKE macht mobil

MOBIKE macht mobil

Da die IPSec- und IKE-Standards ursprünglich zur Kopplung von Netzen erdacht wurden, weisen sie erhebliche Schwächen im mobilen Bereich auf. Das Mobility and Multihoming Protocol (MOBIKE) verspricht als IKEv2-Erweiterung eine große Flexibilität beim Aufrechterhalten von IPSec-Verbindungen in mobilen Anwendungen respektive Geräten [4]. Nicht nur der dynamische Wechsel der eigenen IP-Adresse, wie er von vielen ADSL-Providern periodisch erzwungen wird, wird problemlos abgewickelt. Auch der fliegende Wechsel von einem Netzwerk-Interface zu einem anderen ist möglich, falls verschiedene Medien wie WLAN, GPRS oder UMTS den Weg ins Internet anbieten. Ob ein Peer MOBIKE-Fähigkeiten besitzt, signalisiert er im IKE_AUTH-Request (MOBIKE_SUPPORTED Notification) wobei er präventiv auf den UDP-Port 4500 für NAT-Traversal wechselt, unabhängig davon, ob wirklich eine NAT-Situation besteht.

Merkt nun ein Initiator, dass sich seine IP-Adresse oder sein aktives Netzwerk-Interface geändert hat, so sendet er mit seiner neuen IP-Adresse in einer INFORMATIONAL-Meldung eine UPDATE_SA_ADDRESSES-Nachricht an die Gegenseite, wobei alle ausgehandelten IKE_SA-Parameter inklusive der Kryptoschlüssel und Authentifizierungsinformationen beibehalten werden. Die andere Seite quittiert diese Meldung und ändert die IPSec-SA auf die neue IP-Adresse des Initiators um. Besitzen beide Seiten über Multi-Homing mehrere Netzwerkschnittstellen, so machen sie diese über ADDITIONAL_IP4_ADDRESS oder ADDITIONAL_IP6_ADDRESS-Nachrichten gegenseitig bekannt. Es steht in der Verantwortung des Initiators herauszufinden, welche der n x m möglichen Adresskombinationen eine funktionierende Verbindung ergibt.

Ein spezielles Szenario, welches aber weiterhin auch bei MOBIKE explizit ausgeklammert wird, ist der Double-NAT-Fall, bei dem beide VPN-Endpunkte hinter einem NAT-Router stecken und ohne die Vermittlungsdienste eines sogenannten Mediation-Servers keine Verbindung aufbauen können. Dieser Speziallfall soll durch einen zusätzlichen Internet Draft abgedeckt werden, der zurzeit im Rahmen des strongSwan-Projekts am Institut für Internet-Technologien und Anwendungen der Hochschule für Technik Rapperswil verfasst wird.

Warten auf Godot

Seit der IKEv2-RFC 4306 im Dezember 2005 verabschiedet wurde, sind 18 Monate vergangen und alle namhaften VPN-Hersteller haben eine IKEv2-Implementierung in der Pipeline. Im März 2007 fand in Orlando, Florida, der dritte IKEv2-Interoperabilitäts-Workshop statt, an dem Alcatel-Lucent, Certicom, Check Point, Cisco Systems, Furukawa, Ixia, Juniper Networks, Nokia, Reef Point Systems, SafeNet, Secure Computing Corporation, SonicWALL und das Open-Source-Projekt strongSwan ihre IKEv2-Produkte untereinander mit Erfolg testeten. In der Open-Source-Community tut sich zudem Weiteres: Die IKE-Daemons ikev2, OpenIKEv2 und racoon2 sind unter Linux beziehungsweise BSD bereits verfügbar. StrongSwan bietet dabei nach Einschätzung des Autors, der das Projekt als Professor an der Hochschule für Technik Rapperswil betreut, den größten Funktionsumfang. Unter anderem unterstützt es seit Version 4.1.4 MOBIKE-Grundfunktionen [5].

Die ersten praktischen IKEv2-Anwendungen sind seit Mitte dieses Jahres etwa bei T-Mobile USA für den HotSpot@Home-Dienst erfolgreich im Einsatz. Die neueste Handy-Generation von Samsung und Nokia kann im Einzugsbereich eines Wireless-LAN anstatt über das GSM- oder UMTS-Mobilfunknetz zu einem reduzierten Tarif über das Internet telefonieren (Unlicensed Mobile Access, UMA). Der dazugehörige 3GPP-Standard TS 33.234 schreibt vor, dass über das WLAN und die Internetverbindung vom Handy zu einem Security-Gateway des Mobilfunknetzbetreibers eine sichere Verbindung mittels IKEv2 aufgebaut werden muss. Vom Gateway wird dann das Gespräch in das normale Telekommunikationsnetz eingespeist. Der Benutzer authentifiziert sich mit seiner SIM-Karte über das IKEv2-Protokoll EAP-SIM oder EAP-AKA, während das Security-Gateway des Providers ein Zertifikat sendet. Das ganze erfordert keine zusätzliche Konfiguration vom Anwender auf dem Handy oder seinem Router und geschieht völlig transparent.

Es bleibt abzuwarten, ob IKEv2 in der Praxis auch bei stationären Anwendungen mehr Akzeptanz als IKEv1 findet. Leider sind IKEv1 und IKEv2 nicht miteinander interoperabel, sodass Anwender sich auf ein Protokoll festlegen müssen. Die neuen, besseren Funktionen von IKEv2 sollten aber die Wahl zwischen den beiden Protokollen einfach machen. Man darf gespannt auf die kommende IKEv2-Produktgeneration sein.

Mit Version 2 sind zwar die leidigen Probleme beseitigt, allerdings lässt auch der RFC 4306 einigen Spielraum für (Miss-)Interpretationen, die bei der Implementierung der Hersteller zu Inkompatibilitäten führen können. Der RFC 4718 "IKEv2 Clarifications and Implementation Guidelines" beschreibt die Details von IKEv2 erheblich genauer. Paul Hoffman vom VPNC Konsortium hat die beiden RFCs in einem Draft zusammengefasst, der zukünftig RFC 4306 ersetzen soll.

Eine genauere Beschreibung des Verbindungsaufbaus bei IKEv2 ist auf der folgenden Seite zu finden: IKEv2-Protokoll im Detail.

Literatur

[1] Niels Ferguson, Bruce Schneier, A Cryptographic Analysis of IPSec

[2] Daniel Bachfeld, Andreas Steffen, VPN Knigge

[3] Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, RFC 4306

[4] Pasi Eronen, IKEv2 Mobility and Multihoming Protocol (MOBIKE), RFC 4555

[5] strongSwan Projekt

IKEv2-Protokoll im Detail

IKEv2-Protokoll im Detail

IKEv2 definiert vier Meldungstypen: IKE_SA_INIT für die Initialisierung einer IPSec-Verbindung, IKE_AUTH für die Authentifizierung der Kommunikationspartner, CREATE_CHILD_SA für Schlüsseländerungen und die Erstellung zusätzlicher CHILD_SA sowie INFORMATIONAL für den weiteren Informationsaustausch.

Bei IKEv2 sendet der Initiator in einem IKE_SA_INIT-Request seine Krypto-Vorschläge SA1i, seinen öffentlichen Diffie-Hellman-Key-Exchange-Faktor KEi sowie eine Zufallszahl Ni. Der Responder gibt im IKE_SA_INIT Response seine Krypto-Auswahl SA1r, seinen DH Faktor KEr sowie eine eigene Zufallszahl Nr zurück. Aus KEi, KEr, Ni und Nr leiten nun beide Endpunkte gemeinsame Session-Schlüssel für die Verschlüsselung und Authentisierung aller nachfolgenden IKE-Meldungen ab. Da die Berechnung eines Diffie-Hellman-Geheimnisses wegen der bis zu 2048 Bit großen Zahlen ziemlich aufwendig ist, könnte ein Angreifer durch Senden einer Vielzahl von IKE_SA_INIT-Requests mit ständig wechselnder Absenderadresse ein IPSec-Gateway gezielt in die Knie zwingen.

Hat der Responder den Verdacht, angegriffen zu werden (manifestiert durch viele IKE_SA_INIT-Meldungen, auf die kein weitergehender IKE_AUTH Request folgt), so kann er in seiner IKE_SA_INIT-Response einzig ein zufällig gewähltes Cookie zurücksenden und der Initiator muss seinen Request, ergänzt mit dem empfangenen Cookie, wiederholen.

Ist die erste Kontaktaufnahme erfolgreich verlaufen, so schiebt der Initiator einen IKE_AUTH Request mit seiner Identität IDi und seiner Authentifizierungs-Payload Authi nach, die auf PSK (Pre-Shared Keys) oder RSA beruhen kann. Optional kann noch die gewünschte Identität IDr angegeben werden, falls die Gegenstelle mehrere Identitäten besitzt. Beruht die Authentifizierung auf einer RSA-Signatur, so sendet das Endgerät optional entweder das eigene X.509- Zertifikat mit oder alternativ eine HTTP-URL.

Mit der IKE_AUTH-Meldung kann im gleichen Aufwasch direkt eine erste sogenannte Child Security Association (CHILD_SA) erstellt werden. Mit SA2i wird eine Krypto-Auswahl mitgesendet, die vorschlägt, wie ESP (Encapsulating Security Payload) oder AH (Authentication Header) IPSec-Pakete verschlüsselt, authentisiert und optional komprimiert werden sollen. Weiter werden mit den Traffic-Selektoren TSi und TSr ein eigener und ein fremder IP-Adressbereich vorgeschlagen, die miteinander gekoppelt werden sollen. Die Traffic-Selektoren können den Tunnelverkehr auch auf ein einzelnes IP-Protokoll wie TCP und einen Portbereich oder sogar einen einzelnen Port wie http einschränken.

Der Responder sendet in der IKE_AUTH-Response seine eigene Identität IDr und seine Auth-Payload Authr zurück. Betreffend der CHILD_SA trifft er eine ESP/AH-Krypto-Auswahl SA2r und hat neu die Möglichkeit mit den Traffic-Selektoren TSi und TSr die Subnetze einzuengen. Wünscht der Initiator zum Beispiel TSr=10.1.0.0/16, so kann der Responder mit TSr=10.1.0.0/24 das Subnetz verkleinern. Im Extremfall kann der Initiator mit dem Vorschlag TSr=0.0.0.0/0 die Wahl des entfernten Subnetzes ganz der Gegenstelle überlassen. Das Gleiche gilt entsprechend auch für den TSi-Selektor. Dieses "Narrowing" genannte Vorgehen gestaltet die IPSec-Konfiguration wesentlich schmerzloser als in der düsteren IKEv1-Vergangenheit. Aus langjähriger Erfahrung des Autors haben die vielen Anwender nur schwer verstehen können, dass ein Verbindungsaufbau nicht zustande kommen wollte, nur weil keine exakte Übereinstimmung der Selektoren gegeben war. (dab)