2. Extensible Authentication Protocol (EAP)

Der EAP-Authentifizierungsaustausch verläuft wie folgt:

[1] Der Authentifikator (authenticator) sendet eine Anforderung (Request), um den Peer zu authentifizieren.

Die Anforderung hat ein Type-Feld, um anzugeben, was angefordert wird. Beispiele für Anforderungstypen sind Identity (Identität), MD5-Challenge usw. Der MD5-Challenge-Typ entspricht eng dem CHAP-Authentifizierungsprotokoll [RFC1994]. Normalerweise sendet der Authentifikator eine anfängliche Identity Request; eine anfängliche Identity Request ist jedoch nicht erforderlich und DARF umgangen werden. Beispielsweise kann die Identität nicht erforderlich sein, wenn sie durch den Port bestimmt wird, mit dem der Peer verbunden ist (Standleitungen, dedizierte Switch- oder Einwahlports), oder wenn die Identität auf andere Weise erhalten wird (über die Identität der rufenden Station oder MAC-Adresse, im Name-Feld der MD5-Challenge-Response usw.).

[2] Der Peer sendet ein Response-Paket als Antwort auf eine gültige Anforderung.

Wie beim Request-Paket enthält das Response-Paket ein Type-Feld, das dem Type-Feld der Anforderung entspricht.

[3] Der Authentifikator sendet ein zusätzliches Request-Paket, und der Peer antwortet mit einer Response.

Die Abfolge von Requests und Responses wird so lange fortgesetzt, wie erforderlich. EAP ist ein "Lock-Step"-Protokoll, sodass außer der anfänglichen Anforderung keine neue Anforderung gesendet werden kann, bevor eine gültige Response empfangen wurde. Der Authentifikator ist für die Neuübertragung von Anforderungen verantwortlich, wie in Abschnitt 4.1 beschrieben. Nach einer angemessenen Anzahl von Neuübertragungen SOLLTE der Authentifikator die EAP-Konversation beenden. Der Authentifikator DARF NICHT ein Success- oder Failure-Paket senden, wenn er neu überträgt oder wenn er keine Response vom Peer erhält.

[4] Die Konversation wird fortgesetzt, bis der Authentifikator den Peer nicht authentifizieren kann (inakzeptable Responses auf eine oder mehrere Requests), in diesem Fall MUSS die Authentifikator-Implementierung einen EAP Failure (Code 4) übertragen. Alternativ kann die Authentifizierungskonversation fortgesetzt werden, bis der Authentifikator feststellt, dass eine erfolgreiche Authentifizierung stattgefunden hat, in diesem Fall MUSS der Authentifikator einen EAP Success (Code 3) übertragen.

Vorteile:

o Das EAP-Protokoll kann mehrere Authentifizierungsmechanismen unterstützen, ohne dass ein bestimmter Mechanismus vorab ausgehandelt werden muss.

o Network Access Server (NAS)-Geräte (z. B. ein Switch oder Access Point) müssen nicht jede Authentifizierungsmethode verstehen und DÜRFEN als Pass-Through-Agent für einen Backend-Authentifizierungsserver fungieren. Die Unterstützung für Pass-Through ist optional. Ein Authentifikator DARF lokale Peers authentifizieren und gleichzeitig als Pass-Through für nicht-lokale Peers und Authentifizierungsmethoden fungieren, die er lokal nicht implementiert.

o Die Trennung des Authentifikators vom Backend-Authentifizierungsserver vereinfacht die Verwaltung von Anmeldeinformationen und die Entscheidungsfindung bei Richtlinien.

Nachteile:

o Für die Verwendung in PPP erfordert EAP das Hinzufügen eines neuen Authentifizierungstyps zu PPP LCP, sodass PPP-Implementierungen geändert werden müssen, um es zu verwenden. Es weicht auch vom vorherigen PPP-Authentifizierungsmodell ab, bei dem während LCP ein bestimmter Authentifizierungsmechanismus ausgehandelt wird. Ebenso müssen Switch- oder Access-Point-Implementierungen [IEEE-802.1X] unterstützen, um EAP zu verwenden.

o Wenn der Authentifikator vom Backend-Authentifizierungsserver getrennt ist, erschwert dies die Sicherheitsanalyse und gegebenenfalls die Schlüsselverteilung.

2.1. Unterstützung für Sequenzen (Support for Sequences)

Eine EAP-Konversation DARF eine Sequenz von Methoden verwenden. Ein häufiges Beispiel hierfür ist eine Identity-Anforderung, gefolgt von einer einzelnen EAP-Authentifizierungsmethode wie MD5-Challenge. Der Peer und der Authentifikator MÜSSEN jedoch innerhalb einer EAP-Konversation nur eine Authentifizierungsmethode (Typ 4 oder größer) verwenden, danach MUSS der Authentifikator ein Success- oder Failure-Paket senden.

Sobald ein Peer eine Response desselben Typs wie die anfängliche Anforderung gesendet hat, DARF ein Authentifikator vor Abschluss der letzten Runde einer bestimmten Methode (mit Ausnahme einer Notification-Request) KEINE Anforderung eines anderen Typs senden und DARF nach Abschluss der anfänglichen Authentifizierungsmethode KEINE Anforderung für eine zusätzliche Methode eines beliebigen Typs senden; ein Peer, der solche Anforderungen erhält, MUSS sie als ungültig behandeln und stillschweigend verwerfen. Infolgedessen wird Identity Requery nicht unterstützt.

Ein Peer DARF nach dem Senden einer anfänglichen Nicht-Nak-Response KEIN Nak (Legacy oder Expanded) als Antwort auf eine Anforderung senden. Da gefälschte EAP-Request-Pakete von einem Angreifer gesendet werden können, SOLLTE ein Authentifikator, der ein unerwartetes Nak erhält, es verwerfen und das Ereignis protokollieren.

Mehrere Authentifizierungsmethoden innerhalb einer EAP-Konversation werden aufgrund ihrer Anfälligkeit für Man-in-the-Middle-Angriffe (siehe Abschnitt 7.4) und der Inkompatibilität mit bestehenden Implementierungen nicht unterstützt.

Wenn eine einzelne EAP-Authentifizierungsmethode verwendet wird, aber andere Methoden darin ausgeführt werden (eine "getunnelte" Methode), gilt das Verbot mehrerer Authentifizierungsmethoden nicht. Solche "getunnelten" Methoden erscheinen für EAP als eine einzelne Authentifizierungsmethode. Abwärtskompatibilität kann bereitgestellt werden, da ein Peer, der eine "getunnelte" Methode nicht unterstützt, auf die anfängliche EAP-Request mit einem Nak (Legacy oder Expanded) antworten kann. Um Sicherheitslücken zu beheben, MÜSSEN "getunnelte" Methoden Schutz vor Man-in-the-Middle-Angriffen unterstützen.

2.2. EAP-Multiplexing-Modell (EAP Multiplexing Model)

Konzeptionell bestehen EAP-Implementierungen aus den folgenden Komponenten:

[a] Untere Schicht (Lower layer). Die untere Schicht ist für die Übertragung und den Empfang von EAP-Frames zwischen Peer und Authentifikator verantwortlich. EAP wurde über eine Vielzahl von unteren Schichten ausgeführt, einschließlich PPP, kabelgebundenen IEEE 802 LANs [IEEE-802.1X], IEEE 802.11 WLAN [IEEE-802.11], UDP (L2TP [RFC2661] und IKEv2 [IKEv2]) und TCP [PIC]. Das Verhalten der unteren Schicht wird in Abschnitt 3 erläutert.

[b] EAP-Schicht (EAP layer). Die EAP-Schicht empfängt und überträgt EAP-Pakete über die untere Schicht, implementiert Duplikaterkennung und Neuübertragung und liefert und empfängt EAP-Nachrichten an die und von den EAP-Peer- und Authentifikator-Schichten.

[c] EAP-Peer- und Authentifikator-Schichten (EAP peer and authenticator layers). Basierend auf dem Code-Feld demultiplext die EAP-Schicht eingehende EAP-Pakete an die EAP-Peer- und Authentifikator-Schichten. Typischerweise unterstützt eine EAP-Implementierung auf einem bestimmten Host entweder Peer- oder Authentifikator-Funktionalität, aber es ist möglich, dass ein Host sowohl als EAP-Peer als auch als Authentifikator fungiert. In einer solchen Implementierung sind sowohl EAP-Peer- als auch Authentifikator-Schichten vorhanden.

[d] EAP-Methodenschichten (EAP method layers). EAP-Methoden implementieren die Authentifizierungsalgorithmen und empfangen und übertragen EAP-Nachrichten über die EAP-Peer- und Authentifikator-Schichten. Da die Fragmentierungsunterstützung nicht von EAP selbst bereitgestellt wird, liegt dies in der Verantwortung der EAP-Methoden, die in Abschnitt 5 erläutert werden.

Das EAP-Multiplexing-Modell ist in Abbildung 1 unten dargestellt. Beachten Sie, dass es keine Anforderung gibt, dass eine Implementierung diesem Modell entspricht, solange das Verhalten auf der Leitung damit übereinstimmt.

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

Abbildung 1: EAP-Multiplexing-Modell

Innerhalb von EAP funktioniert das Code-Feld ähnlich wie eine Protokollnummer in IP. Es wird angenommen, dass die EAP-Schicht eingehende EAP-Pakete gemäß dem Code-Feld demultiplext. Empfangene EAP-Pakete mit Code=1 (Request), 3 (Success) und 4 (Failure) werden von der EAP-Schicht an die EAP-Peer-Schicht geliefert, falls implementiert. EAP-Pakete mit Code=2 (Response) werden an die EAP-Authentifikator-Schicht geliefert, falls implementiert.

Innerhalb von EAP funktioniert das Type-Feld ähnlich wie eine Portnummer in UDP oder TCP. Es wird angenommen, dass die EAP-Peer- und Authentifikator-Schichten eingehende EAP-Pakete gemäß ihrem Typ demultiplexen und sie nur an die EAP-Methode liefern, die diesem Typ entspricht. Eine EAP-Methodenimplementierung auf einem Host kann sich registrieren, um Pakete von den Peer- oder Authentifikator-Schichten oder beiden zu empfangen, abhängig davon, welche Rolle(n) sie unterstützt.

Da EAP-Authentifizierungsmethoden möglicherweise auf die Identität zugreifen möchten, SOLLTEN Implementierungen die Identity Request und Response für Authentifizierungsmethoden (Typen 4 oder größer) zusätzlich zur Identity-Methode zugänglich machen. Der Identity-Typ wird in Abschnitt 5.1 erläutert.

Eine Notification Response wird nur als Bestätigung verwendet, dass der Peer die Notification Request erhalten hat, nicht dass er sie verarbeitet oder die Nachricht dem Benutzer angezeigt hat. Es kann nicht angenommen werden, dass die Inhalte der Notification Request oder Response einer anderen Methode zur Verfügung stehen. Der Notification-Typ wird in Abschnitt 5.2 erläutert.

Nak (Typ 3) oder Expanded Nak (Typ 254) werden für Zwecke der Methodenverhandlung verwendet. Peers antworten auf eine anfängliche EAP-Anforderung für einen inakzeptablen Typ mit einer Nak Response (Typ 3) oder Expanded Nak Response (Typ 254). Es kann nicht angenommen werden, dass die Inhalte der Nak Response(s) einer anderen Methode zur Verfügung stehen. Die Nak-Typ(en) werden in Abschnitt 5.3 erläutert.

EAP-Pakete mit Codes von Success oder Failure enthalten kein Type-Feld und werden nicht an eine EAP-Methode geliefert. Success und Failure werden in Abschnitt 4.2 erläutert.

Angesichts dieser Überlegungen DÜRFEN die Success-, Failure-, Nak Response(s)- und Notification Request/Response-Nachrichten NICHT verwendet werden, um Daten zu transportieren, die zur Zustellung an andere EAP-Methoden bestimmt sind.

2.3. Pass-Through-Verhalten (Pass-Through Behavior)

Bei Betrieb als "Pass-Through-Authentifikator" führt ein Authentifikator Prüfungen der Code-, Identifier- und Length-Felder durch, wie in Abschnitt 4.1 beschrieben. Er leitet EAP-Pakete, die vom Peer empfangen werden und für seine Authentifikator-Schicht bestimmt sind, an den Backend-Authentifizierungsserver weiter; vom Backend-Authentifizierungsserver empfangene Pakete, die für den Peer bestimmt sind, werden an ihn weitergeleitet.

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

Sofern der Authentifikator nicht eine oder mehrere Authentifizierungsmethoden lokal implementiert, die die Authentifikator-Rolle unterstützen, werden die EAP-Methodenschicht-Header-Felder (Type, Type-Data) nicht als Teil der Weiterleitungsentscheidung untersucht. Wenn der Authentifikator lokale Authentifizierungsmethoden unterstützt, DARF er das Type-Feld untersuchen, um zu bestimmen, ob er auf das Paket selbst reagiert oder es weiterleitet. Konforme Pass-Through-Authentifikator-Implementierungen MÜSSEN standardmäßig EAP-Pakete jeden Typs weiterleiten.

EAP-Pakete, die mit Code=1 (Request), Code=3 (Success) und Code=4 (Failure) empfangen werden, werden von der EAP-Schicht demultiplext und an die Peer-Schicht geliefert. Daher werden diese Pakete stillschweigend verworfen, wenn ein Host keine EAP-Peer-Schicht implementiert. Ebenso werden EAP-Pakete, die mit Code=2 (Response) empfangen werden, von der EAP-Schicht demultiplext und an die Authentifikator-Schicht geliefert. Daher werden diese Pakete stillschweigend verworfen, wenn ein Host keine EAP-Authentifikator-Schicht implementiert. Das Verhalten eines "Pass-Through-Peers" ist in dieser Spezifikation nicht definiert und wird von AAA-Protokollen wie RADIUS [RFC3579] und Diameter [DIAM-EAP] nicht unterstützt.

Das Weiterleitungsmodell ist in Abbildung 2 dargestellt.

Peer Pass-Through-Authentifikator Authentifizierungsserver

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

Abbildung 2: Pass-Through-Authentifikator

Für Sitzungen, in denen der Authentifikator als Pass-Through fungiert, MUSS er das Ergebnis der Authentifizierung ausschließlich anhand der vom Backend-Authentifizierungsserver gesendeten Accept/Reject-Anzeige bestimmen; das Ergebnis DARF NICHT durch den Inhalt eines EAP-Pakets bestimmt werden, das zusammen mit der Accept/Reject-Anzeige gesendet wird, oder durch das Fehlen eines solchen gekapselten EAP-Pakets.

2.4. Peer-to-Peer-Betrieb (Peer-to-Peer Operation)

Da EAP ein Peer-to-Peer-Protokoll ist, kann eine unabhängige und gleichzeitige Authentifizierung in umgekehrter Richtung stattfinden (abhängig von den Fähigkeiten der unteren Schicht). Beide Enden der Verbindung können gleichzeitig als Authentifikatoren und Peers fungieren. In diesem Fall ist es erforderlich, dass beide Enden EAP-Authentifikator- und Peer-Schichten implementieren. Darüber hinaus müssen die EAP-Methodenimplementierungen auf beiden Peers sowohl Authentifikator- als auch Peer-Funktionalität unterstützen.

Obwohl EAP Peer-to-Peer-Betrieb unterstützt, unterstützen einige EAP-Implementierungen, Methoden, AAA-Protokolle und Verbindungsschichten dies möglicherweise nicht. Einige EAP-Methoden können asymmetrische Authentifizierung unterstützen, wobei eine Art von Anmeldeinformation für den Peer und eine andere Art für den Authentifikator erforderlich ist. Hosts, die Peer-to-Peer-Betrieb mit einer solchen Methode unterstützen, müssten mit beiden Arten von Anmeldeinformationen bereitgestellt werden.

Beispielsweise ist EAP-TLS [RFC2716] ein Client-Server-Protokoll, bei dem typischerweise unterschiedliche Zertifikatprofile für Client und Server verwendet werden. Dies bedeutet, dass ein Host, der Peer-to-Peer-Authentifizierung mit EAP-TLS unterstützt, sowohl die EAP-Peer- als auch die Authentifikator-Schichten implementieren, sowohl Peer- als auch Authentifikator-Rollen in der EAP-TLS-Implementierung unterstützen und Zertifikate bereitstellen müsste, die für jede Rolle geeignet sind.

AAA-Protokolle wie RADIUS/EAP [RFC3579] und Diameter EAP [DIAM-EAP] unterstützen nur den "Pass-Through-Authentifikator"-Betrieb. Wie in [RFC3579] Abschnitt 2.6.2 vermerkt, antwortet ein RADIUS-Server auf eine Access-Request, die ein EAP-Request-, Success- oder Failure-Paket kapselt, mit einem Access-Reject. Es gibt daher keine Unterstützung für den "Pass-Through-Peer"-Betrieb.

Selbst wenn eine Methode verwendet wird, die gegenseitige Authentifizierung und Ergebnisanzeigen unterstützt, können mehrere Überlegungen vorschreiben, dass zwei EAP-Authentifizierungen (eine in jede Richtung) erforderlich sind. Diese umfassen:

[1] Unterstützung für bidirektionale Sitzungsschlüssel-Ableitung in der unteren Schicht. Untere Schichten wie IEEE 802.11 unterstützen möglicherweise nur die unidirektionale Ableitung und den Transport von transienten Sitzungsschlüsseln. Beispielsweise ist der in [IEEE-802.11i] definierte Gruppenschlüssel-Handshake unidirektional, da im IEEE 802.11-Infrastrukturmodus nur der Access Point (AP) Multicast/Broadcast-Verkehr sendet. Im IEEE 802.11 Ad-hoc-Modus, wo beide Peers Multicast/Broadcast-Verkehr senden können, sind zwei unidirektionale Gruppenschlüssel-Austausche erforderlich. Aufgrund von Designbeschränkungen bedeutet dies auch die Notwendigkeit für Unicast-Schlüssel-Ableitungen und EAP-Methodenaustausche in jede Richtung.

[2] Unterstützung für Tie-Breaking in der unteren Schicht. Untere Schichten wie IEEE 802.11 Ad-hoc unterstützen kein "Tie-Breaking", bei dem zwei Hosts, die sich gegenseitig authentifizieren, nur mit einer einzigen Authentifizierung fortfahren würden. Dies bedeutet, dass selbst wenn 802.11 einen bidirektionalen Gruppenschlüssel-Handshake unterstützen würde, zwei Authentifizierungen, eine in jede Richtung, dennoch auftreten könnten.

[3] Peer-Richtlinienerfüllung. EAP-Methoden können Ergebnisanzeigen unterstützen, die es dem Peer ermöglichen, dem EAP-Server innerhalb der Methode anzuzeigen, dass er den EAP-Server erfolgreich authentifiziert hat, sowie dem Server zu ermöglichen anzuzeigen, dass er den Peer authentifiziert hat. Ein Pass-Through-Authentifikator wird jedoch nicht wissen, dass der Peer die vom EAP-Server angebotenen Anmeldeinformationen akzeptiert hat, es sei denn, diese Informationen werden dem Authentifikator über das AAA-Protokoll zur Verfügung gestellt. Der Authentifikator SOLLTE den Empfang eines Schlüsselattributs in einem Accept-Paket als Anzeige interpretieren, dass der Peer den Server erfolgreich authentifiziert hat.

Es ist jedoch möglich, dass die Zugriffsrichtlinie des EAP-Peers während des anfänglichen EAP-Austauschs nicht erfüllt wurde, obwohl eine gegenseitige Authentifizierung stattgefunden hat. Beispielsweise hat der EAP-Authentifikator möglicherweise keine Berechtigung nachgewiesen, sowohl in Peer- als auch in Authentifikator-Rollen zu agieren. Infolgedessen kann der Peer eine zusätzliche Authentifizierung in umgekehrter Richtung erfordern, selbst wenn der Peer eine Anzeige gegeben hat, dass sich der EAP-Server erfolgreich bei ihm authentifiziert hat.