Zwei Identitäten in einer IKEv2-Anmeldung: erst die Maschine, dann der Benutzer

Ein Clientzertifikat wird validiert, der erste Austausch läuft durch, und dann bricht die Verbindung mit einem Fehler über eine zusätzliche Authentifizierungsrunde ab. In der Zertifikatskette ist nichts falsch, und im Netzwerk hat sich nichts geändert. Das Gateway ist so konfiguriert, dass es einen zweiten Nachweis von der sich verbindenden Seite verlangt, und der Client sendet nie einen. Zu entscheiden, wer was in welcher Reihenfolge nachweist, ist die ganze Aufgabe, und sie beginnt damit, die Richtlinie von dem Endpunkt zu lesen, auf dem Sie stehen. Zwei Nachweise unterschiedlicher Art in fester Reihenfolge sind eine Designentscheidung und kein Kontrollkästchen.

Das Symptom: Fehlschlag nach einem erfolgreichen ersten Nachweis

Der erste Austausch läuft durch, und das Protokoll sieht gesund aus, bis das Gateway eine Benutzeridentität über EAP verlangt. Dann bleibt der Handshake stehen oder liefert einen Protokollfehler, der die zusätzliche Runde benennt. Ein völlig gültiges Maschinenzertifikat wird aus einem Grund abgelehnt, der nichts mit seiner Gültigkeit zu tun hat. Die Richtlinie verlangte einen zweiten Nachweis, und die Antwort des Clients kam nie an.

Beide Beschreibungen dieses Fehlschlags stimmen, je nachdem, wo Sie stehen. Aus Sicht des Clients sieht es aus wie ein Server, der ein gültiges Zertifikat ablehnt, und aus Sicht des Servers wie ein Client, der die Anmeldung nicht abschließen kann. Dasselbe Ereignis liest sich in einem Protokoll als Vertrauensproblem und im anderen als Fähigkeitsproblem. Nur die konfigurierte Richtlinie sagt Ihnen, welches es ist.

Was die Erweiterung hinzufügt und was nicht

IKEv2 trägt eine Erweiterung, um mehr als einen Authentifizierungsaustausch innerhalb einer Sitzung auszuführen. RFC 4739 skizziert unter anderem eine Folge, in der ein Client eine Zertifikatsidentität nachweist und danach eine Person über EAP authentifiziert. Das Dokument ist Experimental, was bedeutet, dass keine Implementierung Ihnen die Funktion schuldet. Nehmen Sie nichts über Unterstützung an, bis die Gegenseite sie aushandelt.

Beide Seiten müssen die Erweiterung unterstützen und sich während des Austauschs darauf einigen. Ein für eine zweite Runde konfiguriertes Gateway kann einen Client nicht dazu zwingen, und ein Client, der sie unterstützt, nutzt sie nicht, wenn der Server nicht darum bittet. Diese Asymmetrie ist der Grund, warum sich der Fehlschlag meist als Zeitüberschreitung oder Protokollfehler zeigt statt als klare Aussage über die Fähigkeit. Die Konfiguration einer Seite zu lesen sagt Ihnen die Hälfte dessen, was passieren wird.

Ein Nachweis pro Endpunkt ist die normale Form, und das ist nicht dieses Design. Das Gateway zeigt sein Zertifikat, der Benutzer antwortet über EAP, und jede Seite hat die andere genau einmal authentifiziert. Diese beiden Nachweise kommen von entgegengesetzten Endpunkten, also sagt keiner von ihnen etwas Eigenes über die Maschine und die Person aus, die sie benutzt.

EAP-TLS ist eine dritte Form, und sie ist ebenfalls nicht diese. Dort wird ein Clientzertifikat innerhalb einer EAP-Methode vorgelegt, sodass der Client weiterhin eine einzige IKE-Authentifizierung abschließt. Die Anmeldedaten können identisch zum Mehrrundenfall aussehen, während das Protokoll eine Runde statt zwei trägt. Deshalb scheitert ein aus einer EAP-TLS-Installation kopiertes Design genau an der Stelle, an der der zweite Nachweis erwartet wird.

Dieselbe Datei liest sich auf dem Gateway anders

Dieselbe swanctl-Datei liest sich anders, je nachdem, wo sie läuft, und das ist der Teil, über den Menschen stolpern. Auf dem Laptop ist das Gateway die Gegenseite, und auf dem Gateway ist es der Laptop, schreiben Sie also die local-Seite als wer ich bin und die remote-Seite als wen ich annehmen werde. Ein local-Block beschreibt, wie sich dieser Endpunkt authentifiziert, und ein remote-Block gibt an, was er vom anderen Ende verlangt. Einen Block zwischen den beiden Dateien zu kopieren kehrt seine Bedeutung um, ohne ein einziges Zeichen zu ändern. Die beiden Dateien zu vergleichen sagt Ihnen fast nichts, weil dieselben Wörter in jeder von ihnen das Gegenteil bedeuten.

Die Position eines Abschnitts bestimmt seine Reihenfolge, sofern keine Rundennummer sie überschreibt. Zusätzliche local- oder remote-Abschnitte beschreiben daher zusätzliche Runden und keine Alternativen, und die ausdrückliche Rundennummer in swanctl.conf-Referenz existiert genau dafür, diese Reihenfolge bewusst zu machen. Ohne sie ändert das Verschieben eines Blocks das Verhalten. Deshalb können sich zwei Konfigurationen, die auf dem Papier gleichwertig aussehen, in umgekehrter Reihenfolge verhalten.

Diese Ordnungsregel erzeugt den Fehlermodus, den es sich zu merken lohnt. Ein zweiter remote-Block ist keine weitere akzeptable Option; er ist eine zweite Anforderung, weshalb sich eine Richtlinie, die sich wie entweder/oder liest, wie und-dann verhält. Eine Gateway-Richtlinie kann das Zertifikat der registrierten Maschine annehmen und dann den EAP-Austausch dieses Benutzers verlangen, in dieser Reihenfolge.

Unterscheiden Sie Runden von unabhängigen Faktoren

Zwei Runden sind nicht automatisch zwei unabhängige Faktoren. Einen Nachweis zu wiederholen oder zwei Anmeldedaten im selben Speicher zu halten liefert nicht die Stärke, die das Design hinzufügen sollte. Unabhängigkeit ist eine Eigenschaft davon, wie die Geheimnisse gehalten werden und was sie kompromittiert, nicht davon, wie viele Austausche das Protokoll ausführt. Ein Design, das Runden als Faktoren zählt, überschätzt, was es hat. Diese Unterscheidung zählt am meisten, wenn eine Compliance-Frage fragt, wie viele Faktoren die Anmeldung tatsächlich verwendet.

Ein Maschinenzertifikat belegt den Besitz seines akzeptierten Schlüssels und nichts weiter. Es ist keine Hardware-Attestierung und kein Bericht zum Gerätezustand, eine Richtlinie, die Zustandsinformationen braucht, braucht also einen anderen Mechanismus. Auch das subject-Feld ist kein Inventaretikett, dem Sie trauen können, denn das subject wählt, wer das Zertifikat ausgestellt oder registriert hat. Wenn das Design einen Nachweis braucht, dass die Maschine gesund ist, muss dieser Nachweis von einer Komponente kommen, die die Maschine misst.

Schreiben Sie auf, was jede Runde tatsächlich belegt, bevor Sie sie hinzufügen. Wenn zwei Runden dasselbe zweimal belegen, fügt die zweite Latenz und Supporttickets hinzu statt Sicherheit. Diese Notiz ist auch das, was eine Diskussion darüber beendet, ob die zusätzliche Runde ihre Kosten wert ist.

Schreiben Sie die Paarungsregel und testen Sie die Ablehnungen

Entscheiden Sie, welche Maschinenidentitäten sich mit welchen Personen paaren dürfen, und schreiben Sie die Regel dorthin, wo die Durchsetzung lebt. Zwei gültige Anmeldedaten nebeneinander belegen nichts über die Paarung, denn die Paarung ist eine Autorisierungsentscheidung und kein Authentifizierungsergebnis. Die Registrierungsunterlagen oder das Authentifizierungs-Backend müssen die Beziehung durchsetzen, die die Organisation will.

Testen Sie dann, was scheitern soll: ein akzeptierter Benutzer auf einer nicht freigegebenen Maschine, ein nicht freigegebener Benutzer mit den Anmeldedaten der Maschine und eine Gegenseite, die die zusätzliche Runde nicht ausführen kann. Wenn alle drei still denselben Zugang erhalten, beschreibt die Richtlinie eine Absicht, statt eine durchzusetzen. Vergleichen Sie die erklärte Konfiguration mit dem, was der Daemon meldet, denn eine Verbindung, die nie gepasst hat, sieht identisch aus wie eine Regel, die durchgelaufen ist:

swanctl --list-conns
swanctl --list-sas

Prüfen Sie die ausgehandelten Runden und die daraus folgende Autorisierung, nicht nur die erfolgreiche Anmeldung. Und greifen Sie nicht zu alten IKEv1-XAuth-Einstellungen als Abkürzung: gleichen Sie Protokoll, Rollen, Reihenfolge und das tatsächliche Verhalten des Clients ab, statt eine erforderliche Runde zu löschen, bis eine Verbindung gelingt. Die scheiternde Runde zu löschen ist der Weg, auf dem ein Design mit zwei Nachweisen still zu einem Design mit einem Nachweis wird, das niemand geprüft hat. Behalten Sie die Löschung im Änderungsnachweis.