Open Source im professionellen Einsatz
Linux-Magazin 02/2009
© Maximilien Brice, CERN (Wikipedia)

© Maximilien Brice, CERN (Wikipedia)

VPNs mit Strongswan-IKEv2

Tunnel-Design 2

,

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.

758

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Strongswan 5.0: Ein Daemon für IKEv1 und IKEv2

    Die freie IPsec-Implementierung Strongswan ist in der überarbeiteten Version 5.0 verfügbar.

  • Querbeet

    Beim Tunnelgraben mit IPsec hat der Admin mit Racoon, Isakmpd, Open- und Strongswan die Wahl aus vier Implementierungen. Der Artikel beleuchtet die Unterschiede und zeigt, wer in puncto Interoperabilität mit Microsofts und Ciscos IPsec-Varianten das Schnäuzchen vorn hat.

  • Stahlnetz

    Ipsec gilt für viele als der Standard unter den VPN-Technologien. Wer dabei ganz auf Nummer sicher gehen will, speichert seine Zugangsberechtigung in Form von X.509-Zertifikaten auf verschlüsselten Tokens oder USB-Sticks. Wie das geht, zeigt dieser Artikel am Beispiel von Strongswan.

  • StrongSwan mit fehlerhaftem Plugin
  • Doppelnase

    IPsec-Verkehr war beim Linux-Kernel 2.6 bisher weitaus schwieriger zu filtern als noch unter 2.4. Seit Ende März 2006 klappt mit den aktuellen Versionen von Kernel und IPtables das Zusammenspiel endlich wieder reibungslos: Das Policy-Match und ein Patch von McHardy machen's möglich.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.