Seite 2: Es lebt!

Inhaltsverzeichnis

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.