Von BSD: Isakmpd

Ursprünglich aus der OpenBSD-Welt kommt Isakmpd [8]. Der IPsec-Daemon aus Berkeley unterscheidet sich schon auf den ersten Blick durch den Stil der Konfiguration. Windows-Administratoren freuen sich, weil die Datei »isakmpd.conf« (Listing 6) stark dem bekannten ».ini« -Format ähnelt, das Microsoft in seinen Betriebssystemen verwendet.

Der Sektion »General« , die den Daemon selbst konfiguriert, folgen die Definitionen der Connections, der Clients, des Netzwerks und im Beispiel die Pfade zu den verwendeten X.509-Zertifikaten. Die Datei »isakmpd.policy« (Listing 7) speichert die Sicherheitspolicies.

In Isakmpd ist IKEv1 voll umgesetzt und es funktioniert mit geringem Konfigurationsaufwand tadellos. Die IKE-Version 2 beherrscht die aktuelle Version von Isakmpd leider nicht. Praktisch ist aber »certpatch« , mit dem sich Attribute in X.509-Zertifikaten nachträglich verändern lassen. So kann der Admin IP-basierte Identitätsdaten der X509.V3-Extension »subjectAltnames« hinzufügen.

Ähnlich wie Linux beherrscht auch Windows XP das IPsec-Protokoll mit den gängigsten Verschlüsselungen und Datenintegritätsprüfungen. Die Konfiguration des Windows-Stacks ist allerdings wie üblich grafisch gestaltet und wirkt etwas behäbig. Der Zeitaufwand für die Konfiguration ist definitiv höher als bei den Textdateien der Linux-Varianten, vor allem weil neben einem eigenen MMC-Snapin auch eine neue lokale Security Policy definiert sein will. Darüber hinaus empfiehlt es sich, für die Verschlüsselung auf 3DES zu setzen, XP kann nämlich kein AES. Fürs sinnvolle Debuggen muss der Admin noch das standardmäßig deaktivierte Logging der SA-Informationen einschalten. Das geht allerdings nur über die Windows-Registry [8].

Grundsätzlich arbeiten sowohl Isakmpd, Racoon als auch die beiden Schwäne harmonisch mit dem IPsec-Stack von Windows XP zusammen (siehe Abbildung 2). Schnell an die Grenzen stößt jedoch, wer Windows XP mit IKEv2 oder Mode Configuration in Roadwarrior-Szenarien benutzen möchte. Hierfür hat Microsoft aktuell noch keine Lösung integriert

Abbildung 2: Die freien Implementierungen arbeiten problemlos mit Microsofts IPsec-Implementierung auf Windows zusammen. Schwierig wird es allerdings in anspruchsvolleren Setups.

Was Eigenes: Cisco

Noch frickeliger gestaltet sich die Kommunikation mit Geräten von Herstellern wie Cisco. Der Tunnelbau zwischen Linux und beispielsweise einer Cisco Pix ist leider seit Jahren unverändert nur fortgeschrittenen Usern mit spezifischem Netzwerk-Know-how vorbehalten.

Die Konfiguration der Cisco-Hardware, speziell in Verbindung mit X.509-Zertifikaten, Xauth und Mode Configuration scheitert oft an Problemen wie der eigenwilligen Identitätsprüfung von Cisco. Wo der Hardwarehersteller mit Group-IDs und IP-Adressen arbeitet, benutzen Racoon und Strongswan die Distinguished Names oder Teile davon. Hier muss sich der hoffentlich geübte Admin einige Tricks einfallen lassen, zum Beispiel einen IP-basierten »Subject Alternative Name« im X.509-Zertifikat einfügen, um eine IP-basierte Authentifizierung auf Cisco-Ebene für Racoon zu ermöglichen.

Im Gegensatz dazu haben die Schwäne gar keine Option für IP-basierte Zertifikatsidentifizierung. Ciscos IOS interpretiert dagegen den »Organisation Unit Name« (OU) in einem X.509-Zertifikat als Group Name oder ermöglicht über »Certificate Maps« auch eine Authentifizierung auf Basis anderer Felder (Subject Names, Subject Alternative Names, …). Wer Xauth und Mode Configuration verwenden will, erlebt dank der fehlenden Standardisierung Probleme.

Racoon hat Probleme mit der bei Cisco obligatorischen Abfrage von optionalen Parametern für Xauth. Eine Lösung hierfür suchten die Autoren vergebens. Im Test funktionierte deshalb nur die Kombination Strongswan/Openswan mit Cisco tadellos (Abbildung 3, Tabelle 1).

Abbildung 3: Geschafft: Die IPsec-Verbindung zwischen Cisco und einem Strongswan-Roadwarrior steht.

Zusätzlich zu den Änderungen an den Zertifikaten sind bei Strongswan dafür nur die Zeilen »authby=xauthrsasig« und »leftsourceip =%modeconfig« anzupassen. Auf dem Cisco-Gerät braucht es einen neuen IP-Pool, aus dem der Server dem Roadwarrior eine Adresse zuweist.