Hallo,
ich würde es begrüßen, dass die IPSec-implementierung des LANCOMs um IKEv2 erweitert wird, dass einfacher funktioniert und eine Benutzerautnetifizierung mit Username/passwort oder auch mit OTPs dank EAP bietet, wie es jetzt von Xauth / ModeCFG Drafts realisiert wird.
Ich weiß, dass der Wunsch noch recht früh erscheint, aber damit würde die IPSec-Implmentierung gerade im Roadwarriorbereich aufgewertet werden.
IKEv2 Erweiterung
Moderator: Lancom-Systems Moderatoren
IKEv2 Erweiterung
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
Hi ittk
Aus Sicherheitsgründen kann ich von einer Authentifizierung über Username/Paßwort nur abraten... Für Roadwarrior sind Zertifikate auf USB-Token die bessere Wahl.
Und XAUTH ist im Hinblick auf die Sicherheit eine wahre Katastrophe, da hier die verschlüsselte IKE-Verhandlung mit einem Gruppen-Key gesichert wird, den *JEDES* Mitglid der Gruppe - und vor allem auch ehemalige - kennt . Damit ist jeder, der den Gruppen-Key kennt, in der Lage die Verhandlung mitzulesen - und kommt somit auch alle Paßwörter, die bei XAUTH ja im Klartext übermittelt werden.
Ach ja... da XAUTH zudem noch nur in Verbindung mit dem Aggressive-Mode gefahren wird, ist nichtmal die Kenntnis des Gruppen-Keys nötig, der läßt sich mit Hilfe eines gefälchten Pakets und der Antwort des Servers auf dieses Paket offline ermitteln...
Bist du sicher, daß du das willst?
Gruß
Backslash
Aus Sicherheitsgründen kann ich von einer Authentifizierung über Username/Paßwort nur abraten... Für Roadwarrior sind Zertifikate auf USB-Token die bessere Wahl.
Und XAUTH ist im Hinblick auf die Sicherheit eine wahre Katastrophe, da hier die verschlüsselte IKE-Verhandlung mit einem Gruppen-Key gesichert wird, den *JEDES* Mitglid der Gruppe - und vor allem auch ehemalige - kennt . Damit ist jeder, der den Gruppen-Key kennt, in der Lage die Verhandlung mitzulesen - und kommt somit auch alle Paßwörter, die bei XAUTH ja im Klartext übermittelt werden.
Ach ja... da XAUTH zudem noch nur in Verbindung mit dem Aggressive-Mode gefahren wird, ist nichtmal die Kenntnis des Gruppen-Keys nötig, der läßt sich mit Hilfe eines gefälchten Pakets und der Antwort des Servers auf dieses Paket offline ermitteln...
Bist du sicher, daß du das willst?
Gruß
Backslash
Ja, zumindest hast du Recht mit den beschriebenen Sicherheitslücken, die aber beim Hybrid-Auth nicht bestehen, die Sicherheit entspricht dabei ca einem Passwort, dass über SSH übermittelt wird. Die Unsicheren verfahren könnte man ja auslassen.
Außerdem ist es ohne weiteres möglich OTP also Einmalpasswörter mit RADIUS-OTP zu nutzen und/oder RSA-Signaturen im Mainmode + Xauth als zusätzliche Authenfizierungsmethode.
Also im groben hat der VPN-Gateway ein von einer CA ausgestelltes Zertifikat mit einem bestimmten CN und dazugehörigem private Key.
Der Client hat nur den öffentlichen Teil des CA-Rootzertifikates. Dies sichert den Xauth-Username/Passwort Austausch ab.
Die andere Methode ist eigentlich schon im LANCOM vorhanden RSA-Signaturen auf LANCOM + VPN-Client. Hier würde das XAuth die Option der zusätzlichen Benutzerauthentifizierung mit Username/Passwort oder besser mittels OTP noch mehr Sicherheit bringen.
Das X509 Zertifikat kann natürlich auf eTokens abgelegt werden, sodass der Zugriff auf den private Keys nur noch Eingabe eines Passwortes möglich ist. Der NCP Client unterstützt das ja alles. Dann können CRLs mit OSCP + Username/Passwortcheck einzeln sperrbar und die Möglichkeit zur CN-Verifikation zur Sicherheitssteigerung eingesetzt werden.
Siehe dazu die folgenden Drafts:
draft-ietf-ipsec-isakmp-hybrid-auth-05.txt
draft-beaulieu-ike-xauth-06.txt
draft-dukes-ike-mode-cfg-02.txt
P.S.: Die neue Slimline-Produkt-CD, die den neuen LANCOM Produkten beileigt gefällt mir gut
Außerdem ist es ohne weiteres möglich OTP also Einmalpasswörter mit RADIUS-OTP zu nutzen und/oder RSA-Signaturen im Mainmode + Xauth als zusätzliche Authenfizierungsmethode.
Also im groben hat der VPN-Gateway ein von einer CA ausgestelltes Zertifikat mit einem bestimmten CN und dazugehörigem private Key.
Der Client hat nur den öffentlichen Teil des CA-Rootzertifikates. Dies sichert den Xauth-Username/Passwort Austausch ab.
Die andere Methode ist eigentlich schon im LANCOM vorhanden RSA-Signaturen auf LANCOM + VPN-Client. Hier würde das XAuth die Option der zusätzlichen Benutzerauthentifizierung mit Username/Passwort oder besser mittels OTP noch mehr Sicherheit bringen.
Das X509 Zertifikat kann natürlich auf eTokens abgelegt werden, sodass der Zugriff auf den private Keys nur noch Eingabe eines Passwortes möglich ist. Der NCP Client unterstützt das ja alles. Dann können CRLs mit OSCP + Username/Passwortcheck einzeln sperrbar und die Möglichkeit zur CN-Verifikation zur Sicherheitssteigerung eingesetzt werden.
Siehe dazu die folgenden Drafts:
draft-ietf-ipsec-isakmp-hybrid-auth-05.txt
draft-beaulieu-ike-xauth-06.txt
draft-dukes-ike-mode-cfg-02.txt
P.S.: Die neue Slimline-Produkt-CD, die den neuen LANCOM Produkten beileigt gefällt mir gut
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a