Standard mit Schwächen
IP Security und Fernzugriff
Die Grundlage der Sicherheitsmechanismen bildet die so genannte IKE-Phase-1-Verhandlung (Internet Key Exchange). Sie kann in zwei Hauptmodi erfolgen: dem Main und dem Aggressive Mode. Im Main Mode oder Identity Protection Mode werden sechs Nachrichten ausgetauscht und die dabei übermittelten IDs oder Zertifikate verschlüsselt. Im Aggressive-Mode hingegen werden nur drei Nachrichten übermittelt. IDs und Zertifikate bleiben unverschlüsselt.
Unabhängig vom Handshake-Verfahren sind mehrere bidirektionale Authentifizierungsverfahren zu unterscheiden. Am häufigsten werden folgende eingesetzt: Preshared Key, bei dem der Client und das VPN-Gateway jeweils dieselben vorkonfigurierten Schlüssel besitzen, sowie RSA Signatures, die digitale Zertifikate unterstützen.
IPSec weist im Zusammenspiel mit Remote Access eine Reihe von Schwachpunkten auf:
1. Wenn Preshared Key, Main Mode und dynamische IP-Adressen genutzt werden, muss der Preshared Key für alle IPSec-Clients gleich sein.
2. IPSec unterstützt nicht die traditionell beim Fernzugriff eingesetzten unidirektionalen Authentifizierungsmethoden Radius (PAP/CHAP), Secure ID oder OTP.
3. Die IP-, DNS- und WINS-Adresszuweisung vom VPN-Gateway zum Client ist innerhalb des IKE-Protokolls nicht spezifiziert. Die privaten IP-, DNS- und WINS-Adressen müssten danach in jedem IPSec-Client fest konfiguriert werden.
4. Bei größeren Remote-Access-Netzen mit mehr als 300 Teilnehmern können Ressourcen-Probleme im Gateway auftreten. Die IPSec-Clients unterbrechen immer wieder ihre Layer-2-(PPP-)Verbindung zum Provider und löschen unter Umständen ihre eigenen Security Associations (SA), die nach wie vor im VPN-Gateway existieren.
5. Zwischen IPSec-Client und VPN-Gateway darf kein IP-NAT-Verfahren eingesetzt werden, weil der IPSec-ESP-Header nicht über genügend Informationen verfügt. Setzt beispielsweise ein Filial-Router IP-NAT bei der Einwahl zum Provider ein, muss sich der Tunnelendpunkt im Router befinden. Das heißt, es findet nur eine Authentifizierung des LAN statt, jedoch keine persönliche Authentifizierung der Teilnehmer am Arbeitsplatzrechner. Vor allem beim Einsatz von digitalen Zertifikaten (PKI) muss aber der Tunnelendpunkt im Rechner in der Außenstelle liegen.
6. In großen Remote-Access-Installationen ist die Konfiguration und Administration der SPD-Einträge (Security Policy Database) sowohl auf Clientseite als auch im Zentralsystem sehr aufwändig.
Mittlerweile gibt es Ansätze, die diese Unzulänglichkeiten beseitigen sollen. So hat Cisco im Draft "XAUTH" (Extended Authentication) eine Lösung für die ersten beiden Punkte vorgeschlagen. Sie setzt jedoch voraus, dass das IKE-Protokoll erweitert wird. Ein vergleichbarer Draft für das Zuweisen von IP-, DNS- und WINS-Adressen (Punkt 3) liegt noch nicht vor. Um das in Punkt 4 dargestellte Problem zu lösen, gibt es einen Vorschlag, keinen Draft, der eine Art Polling beschreibt. Mithilfe dieses Verfahrens soll signalisiert werden, dass eine Security Association nicht mehr aktiv ist. Polling wird allerdings zu einem Problem, wenn der Client im Shorthold-Modus arbeitet, weil die Layer-2-(PPP-)Verbindung zum Provider immer bestehen bleibt.
Das Problem mit dem Übersetzen der Netzwerkadressen zwischen IPSec-Client und VPN-Gateway (Punkt 5) soll der neue Draft "NAT Traversal 28/2-2001" der Firma SSH lösen. Damit Geräte, die Network Address Translation einsetzen, kommunizieren können, wird jedes IPSec-Paket zusätzlich in einen IP- und UDP- Header verpackt. Der sechste Punkt ist davon abhängig, wie ein Hersteller die Verwaltung der Security-Policy-Datenbanken implementiert.
Der wohl interessanteste Ansatz, um die in den Punkten 1 bis 5 aufgezeigten Probleme zu lösen, ist im Informational RFC 2888 "IPSec over L2TP (Secure Remote Access with L2TP)" beschrieben. IPSec over L2TP verlangt keine Änderungen an den Requests for Comment 2401 bis2409 und dürfte deshalb die Zustimmung der IPSec- und IPSRA-Arbeitsgruppen finden.
RFC 2888 sieht vor, dass zunächst ein Layer-2-Tunnel zwischen VPN-Client und VPN-Gateway aufgebaut wird, anschließend eine Standard-PPP-Verbindung, sprich eine ohne erweiterte Sicherheitsfunktionen wie bei PPP-EAP-TLS. Über sie werden die IKE-Verhandlung (Handshake) und die IPSec-Datenpakete übertragen (Punkte 1 bis 3). Trennt der Client die Layer-2-Verbindung zum Provider, wird der Tunnel automatisch abgebaut und die IPSec-SAs können gelöscht werden (Punkt 4). Mit Punkt 5 (IP-NAT) gibt es, wie eingangs beschrieben, bei einem L2TP-Tunnel sowieso keine Probleme.