Ich möchte ein IKEv2-VPN-Gateway für mehrere Remotebenutzer konfigurieren, um auf ein privates Netzwerk zuzugreifen.
Ich habe ein Test-Setup, bei dem sich der Responder mit einem selbstsignierten Zertifikat authentifiziert. Der Initiator authentifiziert sich mit einem Benutzernamen und einem Passwort.
Ein paar Probleme:
- Das Zertifikat ist zu kompliziert. Ich werde keine richtige PKI einrichten, daher ist ein selbstsigniertes Zertifikat, das an jeden Client verteilt und als vertrauenswürdig konfiguriert werden muss, ein Pre-Shared Key (PSK), der jedoch wesentlich schwieriger zu generieren und zu verwalten ist.
- Der Initiator wird authentifiziertnurdurch einen Benutzernamen und ein Passwort, und so kann ein externer Angreifer leicht versuchen, schwache oder kompromittierte Passwörter zu erraten.
Wenn ich keine richtige PKI einsetze, würde ich liebergegenseitigAuthentifizierung der Initiator- und Responder-Hosts über einen PSK. Dieser Schlüssel wird sicher an alle Benutzer verteilt. Externe Angreifer verfügen nicht über den PSK und daher reicht ein schwaches oder kompromittiertes Passwort für den Zugriff nicht aus. Die Authentifizierung mit Benutzername und Passwort ermöglicht die Identifizierung und Autorisierung eines bestimmten Benutzers gegenüber einem vorhandenen Verzeichnissystem, ohne dass für jeden Benutzer eindeutige Schlüssel generiert und verteilt werden müssen.
Ist so etwas mit IKEv2 möglich? Soweit ich weiß, war es mit Xauth in IKEv1 möglich. Aber bei IKEv2 bin ich mir nicht so sicher: bei flüchtigem Lesen vonRFC 5996, Abschnitt 2.16, es scheint, dass dies nicht der Fall ist. Die Authentifizierung mit Benutzername und Passwort würde über eine EAP-Methode erfolgen und:
Ein Initiator gibt den Wunsch an, EAP zu verwenden, indem er die AUTH-Nutzlast aus der ersten Nachricht im IKE_AUTH-Austausch weglässt. (Beachten Sie, dass die AUTH-Nutzlast für die Nicht-EAP-Authentifizierung erforderlich ist und daher im Rest dieses Dokuments nicht als optional gekennzeichnet ist.)
Dies scheint darauf hinzudeuten, dass der Initiator nur EAP (Benutzername und Passwort) oder PSK verwenden kann.
Obwohl sich die Frage auf das IKEv2-Protokoll bezieht, beabsichtige ich, das Responder-Ende mit Strongswan zu implementieren. Daher wäre ich für jede zusätzliche Expertise in diesem Bereich dankbar.
Antwort1
Client- und Serverauthentifizierung in IKEV2 haben keinen Bezug zueinander. Theoretisch können Sie den Server also mit einem PSK und den Client mit EAP authentifizieren. AllerdingsRFC gibt folgendes anzur EAP-Authentifizierung:
Zusätzlich zur Authentifizierung mit öffentlichen Schlüsselsignaturen und gemeinsamen Geheimnissen unterstützt IKE die Authentifizierung mit Methoden, die in RFC 3748 [EAP] definiert sind. Normalerweise sind diese Methoden asymmetrisch (für die Authentifizierung eines Benutzers gegenüber einem Server konzipiert) und sie sind möglicherweise nicht gegenseitig. Aus diesem Grund werden diese Protokolle normalerweise verwendet, um den Initiator gegenüber dem Antwortenden zu authentifizieren.und MUSS in Verbindung mit einer Public-Key-Signatur-basierten Authentifizierung des Antwortenden gegenüber dem Initiator verwendet werden.
Daher ist die Kombination von PSK-Serverauthentifizierung mit EAP-Clientauthentifizierung nicht RFC-konform. Es ist jedoch möglich, dies mit strongSwan zu konfigurieren. Beachten Sie jedoch, dass die meisten Clients diese Kombination nicht zulassen.
Viele Roadwarrior-Clients unterstützen die PSK-Authentifizierung tatsächlich überhaupt nicht, da es in solchen Szenarien ein potenzielles Sicherheitsrisiko darstellt, wenn derselbe PSK mit mehreren Clients verwendet wird, weil alle Clients, die den PSK kennen, theoretisch in der Lage sind, sich als Server auszugeben.
Ich habe ein Test-Setup, bei dem sich der Responder mit einem selbstsignierten Zertifikat authentifiziert.
Warum nicht verwendenLass uns verschlüsseln?
Der Initiator wird nur durch einen Benutzernamen und ein Kennwort authentifiziert, sodass ein externer Angreifer leicht versuchen kann, schwache oder kompromittierte Kennwörter zu erraten.
Die Verwendung eines PSK zur Authentifizierung des Servers ändert daran nichts. Sie müssten der Client-Authentifizierung einen zweiten Faktor hinzufügen, um etwas dagegen zu tun (d. h. zuerst ein Zertifikat oder PSK verwenden und dann EAP ausführen). Dies erfordert jedoch die Unterstützung fürRFC 4739, was vielen Clients fehlt (strongSwan unterstützt es jedoch).