Zum Hauptinhalt springen

2.16. Methoden des Extensible Authentication Protocol

2.16. Methoden des Extensible Authentication Protocol​

Zusätzlich zur Authentifizierung mit öffentlichen Schlüsselsignaturen und gemeinsamen Secrets unterstützt IKE die Authentifizierung mittels in RFC 3748 [EAP] definierter Methoden. Typischerweise sind diese Methoden asymmetrisch (für einen Benutzer konzipiert, der sich bei einem Server authentifiziert) und sie sind möglicherweise nicht gegenseitig. Aus diesem Grund werden diese Protokolle typischerweise verwendet, um den Initiator gegenüber dem Responder zu authentifizieren, und MÜSSEN in Verbindung mit einer auf öffentlichen Schlüsselsignaturen basierenden Authentifizierung des Responders gegenüber dem Initiator verwendet werden. Diese Methoden werden oft mit Mechanismen in Verbindung gebracht, die als „Legacy Authentication"-Mechanismen bezeichnet werden.

Während dieses Dokument [EAP] mit der Absicht referenziert, dass zukünftig neue Methoden ohne Aktualisierung dieser Spezifikation hinzugefügt werden können, werden hier einige einfachere Varianten dokumentiert. [EAP] definiert ein Authentifizierungsprotokoll, das eine variable Anzahl von Nachrichten erfordert. Erweiterbare Authentifizierung wird in IKE als zusätzliche IKE_AUTH-Austausche implementiert, die zur Initialisierung der IKE-SA abgeschlossen sein MÜSSEN.

Ein Initiator zeigt den Wunsch, EAP zu verwenden, indem er den AUTH-Payload aus der ersten Nachricht des IKE_AUTH-Austauschs weglässt. (Beachten Sie, dass der AUTH-Payload für die Nicht-EAP-Authentifizierung erforderlich ist und daher im restlichen Teil dieses Dokuments nicht als optional markiert ist.) Durch das Einschließen eines IDi-Payloads, aber nicht eines AUTH-Payloads, hat der Initiator eine Identität erklärt, aber nicht bewiesen. Wenn der Responder bereit ist, eine EAP-Methode zu verwenden, wird er einen EAP-Payload (Extensible Authentication Protocol) in die Antwort des IKE_AUTH-Austauschs aufnehmen und das Senden von SAr2, TSi und TSr verschieben, bis die Initiator-Authentifizierung in einem nachfolgenden IKE_AUTH-Austausch abgeschlossen ist. Im Fall einer minimalen EAP-Methode erscheint die anfängliche SA-Errichtung wie folgt:

Initiator Responder​

HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr }

Wie in Abschnitt 2.2 beschrieben, werden bei Verwendung von EAP die Nachrichtennummern jedes Paars von IKE-SA-Initialsetup-Nachrichten inkrementiert; das erste AUTH-Nachrichtenpaar hat die ID 1, das zweite hat 2, und so weiter.

Für EAP-Methoden, die als Nebeneffekt der Authentifizierung einen gemeinsamen Schlüssel erzeugen, MUSS dieser gemeinsame Schlüssel von sowohl Initiator als auch Responder verwendet werden, um in den Nachrichten 7 und 8 AUTH-Payloads unter Verwendung der in Abschnitt 2.15 für gemeinsame Secrets angegebenen Syntax zu erzeugen. Der aus EAP stammende gemeinsame Schlüssel ist das im EAP-Spezifikation als MSK bezeichnete Feld. Dieser während eines IKE-Austauschs erzeugte gemeinsame Schlüssel DARF NICHT für einen anderen Zweck verwendet werden.

EAP-Methoden, die keinen gemeinsamen Schlüssel etablieren, SOLLTEN NICHT verwendet werden, da sie einer Reihe von Man-in-the-Middle-Angriffen [EAPMITM] unterliegen, wenn diese EAP-Methoden in anderen Protokollen verwendet werden, die keinen server-authentifizierten Tunnel verwenden. Bitte siehe den Abschnitt Sicherheitsüberlegungen für weitere Einzelheiten. Wenn EAP-Methoden verwendet werden, die keinen gemeinsamen Schlüssel erzeugen, MÜSSEN die AUTH-Payloads in den Nachrichten 7 und 8 unter Verwendung von jeweils SK_pi und SK_pr erzeugt werden.

Der Initiator einer EKE-SA, die EAP verwendet, muss in die Lage versetzt werden, den anfänglichen Protokollaustausch auf mindestens zehn IKE_AUTH-Austausche zu erweitern, falls der Responder Benachrichtigungsnachrichten sendet und/oder die Authentifizierungsaufforderung wiederholt. Sobald der durch die gewählte EAP-Authentifizierungsmethode definierte Protokollaustausch erfolgreich beendet wurde, MUSS der Responder einen EAP-Payload senden, der die Success-Nachricht enthält. Ebenso MUSS der Responder, wenn die Authentifizierungsmethode fehlgeschlagen ist, einen EAP-Payload senden, der die Failure-Nachricht enthält. Der Responder KANN den IKE-Austausch jederzeit beenden, indem er einen EAP-Payload sendet, der die Failure-Nachricht enthält.

Nach einem solchen erweiterten Austausch MÜSSEN die EAP-AUTH-Payloads in den zwei Nachrichten enthalten sein, die auf diejenige folgen, die die EAP-Success-Nachricht enthält.

Wenn die Initiator-Authentifizierung EAP verwendet, ist es möglich, dass der Inhalt des IDi-Payloads nur für Authentifizierungs-, Autorisierungs- und Accounting-Zwecke (AAA) sowie zur Auswahl der zu verwendenden EAP-Methode verwendet wird. Dieser Wert kann sich von der durch die EAP-Methode authentifizierten Identität unterscheiden. Es ist wichtig, dass Richtlinienabfragen und Zugriffskontrollentscheidungen die tatsächlich authentifizierte Identität verwenden. Oft wird der EAP-Server in einem separaten AAA-Server implementiert, der mit dem IKEv2-Responder kommuniziert. In diesem Fall muss die authentifizierte Identität, falls sie sich von der im IDi-Payload unterscheidet, vom AAA-Server an den IKEv2-Responder gesendet werden.