2. Extensible Authentication Protocol (EAP)

Der EAP-Authentifizierungsaustausch verläuft wie folgt:

[1] Der Authenticator sendet eine Request, um den Peer zu authentifizieren. Diese Request enthält ein Type-Feld, das angibt, was angefordert wird. Beispiele für Request-Typen sind Identity, MD5-challenge usw. Der MD5-challenge-Typ ähnelt sehr dem CHAP-Authentifizierungsprotokoll [RFC1994]. Im Allgemeinen sendet der Authenticator eine anfängliche Identity Request; jedoch ist die anfängliche Identity Request nicht zwingend erforderlich und kann weggelassen werden. Beispielsweise ist die Identität möglicherweise nicht erforderlich, wenn sie durch den Port bestimmt wird, mit dem der Peer verbunden ist (Festverbindung, privater Nebenstellenanschluss oder Wählport), oder auf andere Weise erhalten wird (über die Anrufer-ID oder MAC-Adresse, im Name-Feld der MD5-Challenge Response usw.).

[2] Der Peer sendet ein Response-Paket als Antwort auf eine gültige Request. Wie das Request-Paket enthält das Response-Paket ein Type-Feld, das dem Type-Feld der Request entspricht.

[3] Der Authenticator sendet eine zusätzliche Request, auf die der Peer mit einer Response antwortet. Die Sequenz von Request und Response wird so lange fortgesetzt, wie nötig. Da EAP ein "Lock-Step"-Protokoll (lock step) ist, darf vor dem Erhalt einer gültigen Response (mit Ausnahme der anfänglichen Request) keine neue Request gesendet werden. Der Authenticator ist für die Retransmission von Requests wie in Abschnitt 4.1 beschrieben verantwortlich. Nach einer angemessenen Anzahl von Retransmissionen sollte der Authenticator den EAP-Dialog beenden. Bei einer Retransmission oder wenn keine Antwort vom Peer erhalten wird, DARF der Authenticator KEINE Success- oder Failure-Pakete senden.

[4] Der Dialog wird fortgesetzt, bis der Authenticator den Peer nicht authentifizieren kann (inakzeptable Response auf eine oder mehrere Requests), in welchem Fall die Implementierung ein EAP Failure (Code 4) senden MUSS. Alternativ kann der Authentifizierungsdialog so lange fortgesetzt werden, bis der Authenticator feststellt, dass der Peer erfolgreich authentifiziert wurde, in welchem Fall der Authenticator ein EAP Success (Code 3) senden MUSS.

Vorteile:

o Das EAP-Protokoll kann mehrere Authentifizierungsmechanismen unterstützen, ohne einen bestimmten im Voraus aushandeln zu müssen.

o NAS-Geräte (Network Access Server, wie Switches oder Access Points) müssen nicht jede Authentifizierungsmethode verstehen und KÖNNEN als Pass-Through-Proxy für einen Backend-Authentifizierungsserver fungieren. Die Pass-Through-Unterstützung ist optional. Der Authenticator kann den Peer lokal authentifizieren und gleichzeitig als Pass-Through für entfernte Peers und Authentifizierungsmethoden fungieren, die er nicht lokal implementiert.

o Die Trennung von Authenticator und Backend-Authentifizierungsserver vereinfacht die Verwaltung von Anmeldedaten und die Richtlinienentscheidung.

Nachteile:

o Bei Verwendung in PPP erfordert EAP das Hinzufügen eines neuen Authentifizierungstyps zum PPP LCP, wodurch PPP-Implementierungen geändert werden müssen, um es zu verwenden. Es weicht zudem vom bisherigen PPP-Authentifizierungsmodell ab, das während des LCP einen spezifischen Authentifizierungsmechanismus aushandelte. Ebenso müssen Switch- oder Access-Point-Implementierungen [IEEE-802.1X] unterstützen, um EAP zu verwenden.

o In Fällen, in denen der Authenticator vom Backend-Authentifizierungsserver getrennt ist, wird die Sicherheitsanalyse kompliziert, ebenso wie die Schlüsselverteilung, wenn erforderlich.

2.1. Unterstützung von Sequenzen

Ein EAP-Dialog KANN eine Sequenz von Methoden nutzen. Ein häufiges Beispiel ist eine Identity-Anfrage gefolgt von einer einzelnen EAP-Authentifizierungsmethode wie MD5-Challenge. Der Peer und der Authenticator MÜSSEN jedoch in einem EAP-Dialog nur eine Authentifizierungsmethode (Typ 4 oder höher) verwenden, wonach der Authenticator ein Success- oder Failure-Paket senden MUSS.

Sobald der Peer eine Response desselben Typs wie die anfängliche Request gesendet hat, DARF der Authenticator KEINE Request eines anderen Typs senden (mit Ausnahme einer Notification-Request), bevor die finale Runde der spezifischen Methode abgeschlossen ist, und DARF nach Abschluss der anfänglichen Authentifizierungsmethode KEINE Request einer zusätzlichen Methode eines beliebigen Typs senden; ein Peer, der eine solche Request empfängt, MUSS sie als ungültig betrachten und stillschweigend verwerfen. Daher wird die erneute Identity-Abfrage nicht unterstützt.

Der Peer DARF nach dem Senden einer anfänglichen Nicht-Nak-Response KEINE Nak (traditionell oder erweitert) als Antwort auf eine Request senden. Da gefälschte EAP-Request-Pakete von einem Angreifer gesendet werden können, SOLLTE der Authenticator eine unerwartete Nak verwerfen und das Ereignis protokollieren.

Aufgrund der Anfälligkeit für Man-in-the-Middle-Angriffe (siehe Abschnitt 7.4) und der Inkompatibilität mit bestehenden Implementierungen wird die Verwendung mehrerer Authentifizierungsmethoden in einem EAP-Dialog nicht unterstützt.

Im Fall, dass nur eine einzelne EAP-Authentifizierungsmethode verwendet wird, aber andere Methoden ("tunneled" Methoden) innerhalb dieser Methode ausgeführt werden, gilt das Verbot mehrerer Authentifizierungsmethoden nicht. Solche "tunneled" Methoden erscheinen für EAP als eine einzelne Authentifizierungsmethode. Da Peers, die "tunneled" Methoden nicht unterstützen, mit einer Nak auf die anfängliche EAP-Request (traditionell oder erweitert) antworten können, kann Rückwärtskompatibilität geboten werden. Um die Sicherheitslücke zu beheben, MÜSSEN "tunneled" Methoden Schutz gegen Man-in-the-Middle-Angriffe unterstützen.

2.2. EAP-Multiplexing-Modell

Konzeptionell besteht eine EAP-Implementierung aus den folgenden Komponenten:

[a] Untere Schicht. Die untere Schicht ist für den Transport und Empfang von EAP-Rahmen zwischen Peer und Authenticator zuständig. EAP läuft über mehrere untere Schichten, einschließlich PPP, IEEE-802-Draht-LANs [IEEE-802.1X], IEEE-802.11-Drahtlos-LANs [IEEE-802.11], UDP (L2TP [RFC2661] und IKEv2 [IKEv2]) und TCP [PIC]. Das Verhalten der unteren Schicht wird in Abschnitt 3 erörtert.

[b] EAP-Schicht. Die EAP-Schicht empfängt und sendet EAP-Pakete über die untere Schicht, implementiert Duplikaterkennung und Retransmission und verteilt sowie empfängt EAP-Nachrichten an und von den EAP-Peer- und Authenticatorennschichten.

[c] EAP-Peer- und Authenticatorenschichten. Die EAP-Schicht demultiplext eingehende EAP-Pakete basierend auf dem Code-Feld an die EAP-Peer- und Authenticatorenschichten. Im Allgemeinen wird eine EAP-Implementierung auf einem bestimmten Host nur eine der Funktionen Peer oder Authenticator unterstützen, aber ein Host kann auch gleichzeitig als EAP-Peer und Authenticator fungieren. In einer solchen Implementierung werden sowohl die EAP-Peer- als auch die Authenticatorenschicht vorhanden sein.

[d] EAP-Methodenschicht. Die EAP-Methode implementiert den Authentifizierungsalgorithmus und sendet/empfängt EAP-Nachrichten über die EAP-Peer- und Authenticatorenschichten. Da EAP keine Fragmentierung unterstützt, ist dies Aufgabe der EAP-Methode, die in Abschnitt 5 erörtert wird.

Das EAP-Multiplexing-Modell ist unten dargestellt. Beachten Sie, dass die Implementierung nicht an dieses Modell angepasst sein muss, solange das Verhalten auf dem Draht damit übereinstimmt.

         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
                 +------------>-------------+

Figure 1: EAP Multiplexing Model

In EAP spielt das Code-Feld eine ähnliche Rolle wie die Protokollnummer in IP. Es wird angenommen, dass die EAP-Schicht eingehende EAP-Pakete basierend auf dem Code-Feld demultiplext. EAP-Pakete mit Code=1 (Request), 3 (Success) und 4 (Failure) werden an die EAP-Peerschicht (falls implementiert) zugestellt. EAP-Pakete mit Code=2 (Response) werden an die EAP-Authenticatorenschicht (falls implementiert) zugestellt.

In EAP spielt das Type-Feld eine ähnliche Rolle wie die Portnummer in UDP oder TCP. Es wird angenommen, dass die EAP-Peer- und Authenticatorenschichten eingehende EAP-Pakete basierend auf dem Type demultiplext und sie nur an die dem Type entsprechende EAP-Methode zustellen. EAP-Methodenimplementierungen auf einem Host können sich registrieren, um Pakete von der Peer- oder Authenticatorenschicht (oder beiden) basierend auf der Rolle, die sie unterstützen, zu empfangen.

Da EAP-Authentifizierungsmethoden möglicherweise auf die Identität zugreifen möchten, SOLLTEN Implementierungen die Identity Request und Response für Authentifizierungsmethoden (Typ 4 oder höher) zugänglich machen, mit Ausnahme der Identity-Methode. Der Identity-Typ wird in Abschnitt 5.1 erörtert.

Die Notification Response wird nur verwendet, um zu bestätigen, dass der Peer die Notification Request empfangen hat, nicht um zu bestätigen, dass er die Nachricht verarbeitet oder dem Benutzer angezeigt hat. Der Inhalt von Notification Request oder Response ist nicht garantiert für andere Methoden verfügbar. Der Notification-Typ wird in Abschnitt 5.2 erörtert.

Nak (Typ 3) oder Expanded Nak (Typ 254) wird für die Methodenaushandlung verwendet. Der Peer antwortet auf eine anfängliche EAP-Request eines inakzeptablen Typs mit einer Nak Response (Typ 3) oder einer Expanded Nak Response (Typ 254). Der Inhalt von Nak Response(s) ist nicht garantiert für andere Methoden verfügbar. Die Nak-Typen werden in Abschnitt 5.3 erörtert.

EAP-Pakete, deren Code Success oder Failure ist, enthalten kein Type-Feld und werden nicht an EAP-Methoden zugestellt. Success und Failure werden in Abschnitt 4.2 erörtert.

Unter Berücksichtigung dieser Überlegungen DÜRFEN Success-, Failure-, Nak-Response(s)- und Notification-Request/Response-Nachrichten NICHT verwendet werden, um an andere EAP-Methoden gesendete Daten zu transportieren.

2.3. Pass-Through-Verhalten

Wenn er als "Pass-Through-Authenticator" betrieben wird, führt der Authenticator die in Abschnitt 4.1 beschriebenen Prüfungen der Code-, Identifier- und Length-Felder durch. Er leitet EAP-Pakete, die vom Peer empfangen und an seine Authenticatorenschicht adressiert sind, an den Backend-Authentifizierungsserver weiter; Pakete, die vom Backend-Authentifizierungsserver empfangen und an den Peer adressiert sind, werden an ihn weitergeleitet.

Ein Host, der ein EAP-Paket empfängt, kann nur eine von drei Dingen tun: es verarbeiten, verwerfen oder weiterleiten. Die Weiterleitungsentscheidung basiert normalerweise nur auf der Prüfung der Code-, Identifier- und Length-Felder. Eine Pass-Through-Authenticator-Implementierung MUSS in der Lage sein, vom Peer empfangene EAP-Pakete mit Code=2 (Response) an den Backend-Authentifizierungsserver weiterzuleiten. Sie MUSS auch in der Lage sein, vom Backend-Authentifizierungsserver empfangene EAP-Pakete zu empfangen und Pakete mit Code=1 (Request), Code=3 (Success) und Code=4 (Failure) an den Peer weiterzuleiten.

Sofern der Authenticator nicht eine oder mehrere Authentifizierungsmethoden lokal implementiert, die die Authenticator-Rolle unterstützen, werden die Headerfelder der EAP-Methodenschicht (Type, Type-Data) nicht als Teil der Weiterleitungsentscheidung geprüft. Wenn der Authenticator lokale Authentifizierungsmethoden unterstützt, kann er das Type-Feld prüfen, um zu entscheiden, ob er das Paket selbst verarbeitet oder weiterleitet. Kompatible Pass-Through-Authenticator-Implementierungen MÜSSEN standardmäßig EAP-Pakete eines beliebigen Typs weiterleiten.

Erhaltene EAP-Pakete mit Code=1 (Request), Code=3 (Success) und Code=4 (Failure) werden von der EAP-Schicht demultiplext und an die Peerschicht zugestellt. Daher werden diese Pakete stillschweigend verworfen, sofern der Host nicht die EAP-Peerschicht implementiert. Ebenso werden empfangene EAP-Pakete mit Code=2 (Response) von der EAP-Schicht demultiplext und an die Authenticatorenschicht zugestellt. Daher werden diese Pakete stillschweigend verworfen, sofern der Host nicht die EAP-Authenticatorenschicht implementiert. Das Verhalten eines "Pass-Through-Peer" ist in diesem Dokument nicht definiert, und AAA-Protokolle wie RADIUS [RFC3579] und Diameter [DIAM-EAP] unterstützen dieses Verhalten nicht.

Das Weiterleitungsmodell ist in Abbildung 2 dargestellt.

Peer Pass-through Authenticator Authentication Server

   +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
         +-------->--------+           +--------->-------+

Figure 2: Pass-through Authenticator

Für eine Sitzung, in der der Authenticator als Pass-Through fungiert, MUSS er das Ergebnis der Authentifizierung ausschließlich auf Basis der vom Backend-Authentifizierungsserver gesendeten Accept/Reject-Anweisung bestimmen; das Ergebnis DARF NICHT durch den Inhalt der mit der Accept/Reject-Anweisung gesendeten EAP-Pakete oder das Fehlen solcher gekapselter EAP-Pakete bestimmt werden.

2.4. Peer-to-Peer-Betrieb

Da EAP ein Peer-to-Peer-Protokoll ist, kann eine unabhängige und gleichzeitige Reverse-Authentifizierung auftreten (abhängig von den Fähigkeiten der unteren Schicht). Beide Enden der Verbindung können gleichzeitig als Authenticator und Peer fungieren. In diesem Fall müssen beide Enden die EAP-Peer- und Authenticatorenschichten implementieren. Darüber hinaus müssen die EAP-Methodenimplementierungen an beiden Enden sowohl die Authenticator- als auch die Peer-Funktionen gleichzeitig unterstützen.

Obwohl EAP den Peer-to-Peer-Betrieb unterstützt, unterstützen einige EAP-Implementierungen, Methoden, AAA-Protokolle und Verbindungsschichten diese Funktion möglicherweise nicht. Einige EAP-Methoden können eine asymmetrische Authentifizierung unterstützen, die vom Peer einen Typ von Anmeldedaten und vom Authenticator einen anderen Typ verlangt. Hosts, die die Peer-to-Peer-Authentifizierung mit solchen Methoden unterstützen, müssen beide Typen von Anmeldedaten konfigurieren.

Beispielsweise ist EAP-TLS [RFC2716] ein Client-Server-Protokoll, das normalerweise unterschiedliche Zertifikatsprofile für Client und Server verwendet. Das bedeutet, dass Hosts, die die Peer-Authentifizierung mit EAP-TLS unterstützen, die EAP-Peer- und Authenticatorenschichten implementieren, die Peer- und Authenticator-Rollen in der EAP-TLS-Implementierung unterstützen und das entsprechende Zertifikat für jede Rolle konfigurieren müssen.

AAA-Protokolle wie RADIUS/EAP [RFC3579] und Diameter EAP [DIAM-EAP] unterstützen nur den "Pass-Through-Authenticator"-Betrieb. Wie in [RFC3579] Abschnitt 2.6.2 beschrieben, antwortet der RADIUS-Server auf einen Access-Request, der ein EAP-Request-, Success- oder Failure-Paket kapselt, mit einem Access-Reject. Daher wird der "Pass-Through-Peer"-Betrieb nicht unterstützt.

Selbst im Fall der Verwendung einer Methode, die bidirektionale Authentifizierung und Ergebnisanzeige unterstützt, können mehrere Überlegungen erfordern, dass zwei EAP-Authentifizierungen (eine in jede Richtung) durchgeführt werden. Dazu gehören:

[1] Unterstützung der bidirektionalen Sitzungsschlüsselableitung in der unteren Schicht. Untere Schichten wie IEEE 802.11 unterstützen möglicherweise nur die unidirektionale Ableitung und Übertragung von temporären Sitzungsschlüsseln. Beispielsweise ist der in [IEEE-802.11i] definierte Gruppenschlüsselaustausch unidirektional, da im IEEE-802.11-Infrastrukturmodus nur der Access Point (AP) Multicast-/Broadcast-Verkehr sendet. Im IEEE-802.11-Ad-hoc-Modus können beide Enden Multicast-/Broadcast-Verkehr senden, weshalb ein unidirektionaler Gruppenschlüsselaustausch in jede Richtung erforderlich ist. Aufgrund von Designbeschränkungen bedeutet dies auch, dass in jede Richtung eine unidirektionale Gruppenschlüsselableitung und ein EAP-Methodenaustausch erforderlich sind.

[2] Unterstützung des "Tie-Breaking" in der unteren Schicht. Untere Schichten wie der IEEE-802.11-Ad-hoc-Modus unterstützen kein "Tie-Breaking", bei dem zwei Hosts, die sich gegenseitig die Authentifizierung initiieren, nur eine Authentifizierung durchlaufen würden. Das bedeutet, dass selbst wenn 802.11 einen bidirektionalen Gruppenschlüsselaustausch unterstützen würde, weiterhin zwei Authentifizierungen in jede Richtung auftreten könnten.

[3] Erfüllung der Peer-Richtlinie. Die EAP-Methode kann eine Ergebnisanzeige unterstützen, die es dem Peer ermöglicht, innerhalb der Methode anzugeben, dass er den EAP-Server erfolgreich authentifiziert hat, und der Server anzugeben, dass er den Peer authentifiziert hat. Wenn diese Information jedoch nicht über ein AAA-Protokoll dem Authenticator zur Verfügung gestellt wird, weiß der Pass-Through-Authenticator nicht, dass der Peer die vom EAP-Server bereitgestellten Anmeldedaten akzeptiert hat. Der Authenticator SOLLTE den Empfang eines Schlüsselattributs in einem Accept-Paket als Hinweis interpretieren, dass der Peer den EAP-Server erfolgreich authentifiziert hat.

Selbst bei bidirektionaler Authentifizierung kann jedoch die Zugriffsrichtlinie des Peers während des anfänglichen EAP-Austauschs möglicherweise nicht erfüllt sein. Beispielsweise zeigt der EAP-Authenticator möglicherweise nicht die Autorisierung, gleichzeitig in den Peer- und Authenticator-Rollen zu handeln. Daher kann der Peer, selbst wenn er einen Hinweis gibt, dass er den EAP-Server erfolgreich authentifiziert hat, eine zusätzliche Authentifizierung in der Gegenrichtung benötigen.