3. Verhalten der unteren Schicht

3.1. Anforderungen an die untere Schicht (Lower Layer Requirements)

EAP trifft die folgenden Annahmen über untere Schichten:

[1] Unzuverlässiger Transport. In EAP überträgt der Authentifikator Anforderungen erneut, die noch keine Antworten erhalten haben, sodass EAP nicht annimmt, dass untere Schichten zuverlässig sind. Da EAP sein eigenes Neuübertragungsverhalten definiert, ist es möglich (wenn auch unerwünscht), dass Neuübertragungen sowohl in der unteren Schicht als auch in der EAP-Schicht auftreten, wenn EAP über eine zuverlässige untere Schicht ausgeführt wird.

Beachten Sie, dass EAP Success- und Failure-Pakete nicht erneut übertragen werden. Ohne eine zuverlässige untere Schicht und bei einer nicht zu vernachlässigenden Fehlerrate können diese Pakete verloren gehen, was zu Timeouts führt. Es ist daher wünschenswert, dass Implementierungen ihre Resilienz gegenüber dem Verlust von EAP Success- oder Failure-Paketen verbessern, wie in Abschnitt 4.2 beschrieben.

[2] Fehlererkennung der unteren Schicht. Während EAP nicht annimmt, dass die untere Schicht zuverlässig ist, verlässt es sich auf die Fehlererkennung der unteren Schicht (z. B. CRC, Prüfsumme, MIC usw.). EAP-Methoden können keinen MIC enthalten, oder falls doch, wird er möglicherweise nicht über alle Felder im EAP-Paket berechnet, wie z. B. die Code-, Identifier-, Length- oder Type-Felder. Ohne Fehlererkennung der unteren Schicht könnten daher nicht erkannte Fehler in die EAP-Schicht oder EAP-Methodenschicht-Header-Felder eindringen, was zu Authentifizierungsfehlern führt.

Beispielsweise berechnet EAP TLS [RFC2716], das seinen MIC nur über das Type-Data-Feld berechnet, MIC-Validierungsfehler als fatalen Fehler. Ohne Fehlererkennung der unteren Schicht wird diese Methode und andere wie sie nicht zuverlässig funktionieren.

[3] Sicherheit der unteren Schicht. EAP erfordert nicht, dass untere Schichten Sicherheitsdienste wie Vertraulichkeit, Authentifizierung, Integrität und Replay-Schutz pro Paket bereitstellen. Wenn diese Sicherheitsdienste jedoch verfügbar sind, können EAP-Methoden, die Key Derivation unterstützen (siehe Abschnitt 7.2.1), verwendet werden, um dynamisches Schlüsselmaterial bereitzustellen. Dies ermöglicht es, die EAP-Authentifizierung an nachfolgende Daten zu binden und vor Datenänderung, Spoofing oder Replay zu schützen. Siehe Abschnitt 7.1 für Details.

[4] Minimale MTU. EAP ist in der Lage, auf unteren Schichten zu funktionieren, die eine EAP-MTU-Größe von 1020 Oktetten oder größer bereitstellen.

EAP unterstützt keine Pfad-MTU-Erkennung, und Fragmentierung und Reassemblierung werden weder von EAP noch von den in dieser Spezifikation definierten Methoden unterstützt: Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) und expanded Nak Response (254) Typen.

Typischerweise erhält der EAP-Peer Informationen über die EAP-MTU von den unteren Schichten und setzt die EAP-Frame-Größe auf einen geeigneten Wert. Wenn der Authentifikator im Pass-Through-Modus arbeitet, hat der Authentifizierungsserver keine direkte Möglichkeit, die EAP-MTU zu bestimmen, und verlässt sich daher darauf, dass der Authentifikator ihm diese Informationen zur Verfügung stellt, beispielsweise über das Framed-MTU-Attribut, wie in [RFC3579], Abschnitt 2.4 beschrieben.

Während Methoden wie EAP-TLS [RFC2716] Fragmentierung und Reassemblierung unterstützen, können EAP-Methoden, die ursprünglich für die Verwendung in PPP entwickelt wurden, wo eine MTU von 1500 Oktetten für Kontroll-Frames garantiert ist (siehe [RFC1661], Abschnitt 6.1), keine Fragmentierungs- und Reassemblierungsfunktionen aufweisen.

EAP-Methoden können in Abwesenheit anderer Informationen eine minimale EAP-MTU von 1020 Oktetten annehmen. EAP-Methoden SOLLTEN Unterstützung für Fragmentierung und Reassemblierung einschließen, wenn ihre Payloads größer als diese minimale EAP-MTU sein können.

EAP ist ein Lock-Step-Protokoll, was eine gewisse Ineffizienz bei der Handhabung von Fragmentierung und Reassemblierung impliziert. Wenn die untere Schicht Fragmentierung und Reassemblierung unterstützt (z. B. wenn EAP über IP transportiert wird), kann es daher vorzuziehen sein, dass Fragmentierung und Reassemblierung in der unteren Schicht und nicht in EAP erfolgen. Dies kann erreicht werden, indem EAP eine künstlich große EAP-MTU bereitgestellt wird, wodurch Fragmentierung und Reassemblierung innerhalb der unteren Schicht behandelt werden.

[5] Mögliche Duplizierung. Wenn die untere Schicht zuverlässig ist, stellt sie der EAP-Schicht einen nicht duplizierten Paketstrom zur Verfügung. Es ist jedoch wünschenswert, dass untere Schichten Nicht-Duplizierung bereitstellen, dies ist jedoch keine Anforderung. Das Identifier-Feld bietet sowohl dem Peer als auch dem Authentifikator die Möglichkeit, Duplikate zu erkennen.

[6] Reihenfolgegarantien. EAP erfordert nicht, dass der Identifier monoton ansteigend ist, und ist daher für den korrekten Betrieb auf Reihenfolgegarantien der unteren Schicht angewiesen. EAP wurde ursprünglich definiert, um auf PPP zu laufen, und [RFC1661] Abschnitt 1 hat eine Reihenfolge-Anforderung:

"Das Point-to-Point-Protokoll ist für einfache Verbindungen konzipiert, die Pakete zwischen zwei Peers transportieren. Diese Verbindungen bieten vollduplexen gleichzeitigen bidirektionalen Betrieb und es wird angenommen, dass Pakete in der Reihenfolge zugestellt werden."

Untere Schichttransporte für EAP MÜSSEN die Reihenfolge zwischen einer Quelle und einem Ziel auf einer gegebenen Prioritätsebene bewahren (die von [IEEE-802] bereitgestellte Reihenfolgegarantie).

Eine Neuanordnung, falls sie auftritt, führt typischerweise zu einem EAP-Authentifizierungsfehler, der dazu führt, dass die EAP-Authentifizierung erneut ausgeführt wird. In einer Umgebung, in der eine Neuanordnung wahrscheinlich ist, wird daher erwartet, dass EAP-Authentifizierungsfehler häufig auftreten. Es wird EMPFOHLEN, dass EAP nur über untere Schichten ausgeführt wird, die Reihenfolgegarantien bieten; das Ausführen von EAP über reinen IP- oder UDP-Transport wird NICHT EMPFOHLEN. Die Kapselung von EAP innerhalb von RADIUS [RFC3579] erfüllt die Reihenfolge-Anforderungen, da RADIUS ein "Lock-Step"-Protokoll ist, das Pakete in der Reihenfolge zustellt.

3.2. EAP-Verwendung innerhalb von PPP (EAP Usage Within PPP)

Um die Kommunikation über eine Punkt-zu-Punkt-Verbindung herzustellen, sendet jedes Ende der PPP-Verbindung zunächst LCP-Pakete, um die Datenverbindung während der Link Establishment-Phase zu konfigurieren. Nachdem die Verbindung hergestellt wurde, bietet PPP eine optionale Authentifizierungsphase, bevor zur Netzwerkschicht-Protokollphase übergegangen wird.

Standardmäßig ist die Authentifizierung nicht obligatorisch. Wenn eine Authentifizierung der Verbindung gewünscht wird, MUSS eine Implementierung die Authentication Protocol Configuration Option während der Link Establishment-Phase angeben.

Wenn die Identität des Peers in der Authentifizierungsphase festgestellt wurde, kann der Server diese Identität bei der Auswahl von Optionen für die folgenden Netzwerkschicht-Verhandlungen verwenden.

Wenn EAP innerhalb von PPP implementiert wird, wählt es keinen spezifischen Authentifizierungsmechanismus in der PPP Link Control Phase aus, sondern verschiebt dies bis zur Authentifizierungsphase. Dies ermöglicht es dem Authentifikator, weitere Informationen anzufordern, bevor der spezifische Authentifizierungsmechanismus bestimmt wird. Dies ermöglicht auch die Verwendung eines "Backend"-Servers, der tatsächlich die verschiedenen Mechanismen implementiert, während der PPP-Authentifikator lediglich den Authentifizierungsaustausch durchleitet. Die PPP Link Establishment- und Authentifizierungsphasen sowie die Authentication Protocol Configuration Option sind im Point-to-Point Protocol (PPP) [RFC1661] definiert.

3.2.1. PPP-Konfigurationsoptionsformat (PPP Configuration Option Format)

Eine Zusammenfassung des PPP Authentication Protocol Configuration Option-Formats zur Verhandlung von EAP folgt. Die Felder werden von links nach rechts übertragen.

Genau ein EAP-Paket ist im Informationsfeld eines PPP-Datenlink-Layer-Frames gekapselt, wobei das Protokollfeld den Typ Hex C227 (PPP EAP) angibt.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type (Typ)

Length (Länge)

Authentication Protocol (Authentifizierungsprotokoll)

C227 (Hex) für Extensible Authentication Protocol (EAP)

3.3. EAP-Verwendung innerhalb von IEEE 802 (EAP Usage Within IEEE 802)

Die Kapselung von EAP über IEEE 802 ist in [IEEE-802.1X] definiert. Die IEEE 802-Kapselung von EAP beinhaltet kein PPP, und IEEE 802.1X enthält keine Unterstützung für Link- oder Netzwerkschicht-Verhandlungen. Infolgedessen ist es innerhalb von IEEE 802.1X nicht möglich, Nicht-EAP-Authentifizierungsmechanismen wie PAP oder CHAP [RFC1994] zu verhandeln.

3.4. Indikationen der unteren Schicht (Lower Layer Indications)

Die Zuverlässigkeit und Sicherheit von Indikationen der unteren Schicht hängt von der unteren Schicht ab. Da EAP medienunabhängig ist, wird das Vorhandensein oder Fehlen von Sicherheit der unteren Schicht bei der Verarbeitung von EAP-Nachrichten nicht berücksichtigt.

Um die Zuverlässigkeit zu verbessern, kann ein Peer, wenn er eine in Abschnitt 7.2 definierte Erfolgsanzeige der unteren Schicht erhält, schließen, dass ein Success-Paket verloren gegangen ist, und sich verhalten, als hätte er tatsächlich ein Success-Paket erhalten (MAY). Dies schließt ein, den Success in einigen Umständen zu ignorieren, wie in Abschnitt 4.2 beschrieben.

Eine Diskussion einiger Zuverlässigkeits- und Sicherheitsprobleme mit Indikationen der unteren Schicht in PPP, IEEE 802-Kabelnetzwerken und IEEE 802.11-WLAN findet sich in den Sicherheitsüberlegungen, Abschnitt 7.12.

Nach Abschluss der EAP-Authentifizierung wird der Peer typischerweise Daten über den Authentifikator senden und empfangen. Es ist wünschenswert, sicherzustellen, dass die Entitäten, die Daten übertragen, dieselben sind, die die EAP-Authentifizierung erfolgreich abgeschlossen haben. Um dies zu erreichen, ist es notwendig, dass die untere Schicht Integrität, Authentifizierung und Replay-Schutz pro Paket bereitstellt und diese Pro-Paket-Dienste an die während der EAP-Authentifizierung abgeleiteten Schlüssel bindet. Andernfalls ist es möglich, dass nachfolgender Datenverkehr geändert, gespooft oder wiedergegeben wird.

Wenn das Schlüsselmaterial für die Cipher-Suite der unteren Schicht selbst von EAP bereitgestellt wird, werden Cipher-Suite-Verhandlung und Schlüsselaktivierung von der unteren Schicht gesteuert. In PPP werden Cipher-Suites innerhalb von ECP verhandelt, sodass es nicht möglich ist, von der EAP-Authentifizierung abgeleitete Schlüssel bis zum Abschluss von ECP zu verwenden. Daher kann ein anfänglicher EAP-Austausch nicht durch eine PPP-Cipher-Suite geschützt werden, obwohl eine EAP-Neuauthentifizierung geschützt werden kann.

In IEEE 802-Medien erfolgt die anfängliche Schlüsselaktivierung typischerweise auch nach Abschluss der EAP-Authentifizierung. Daher kann ein anfänglicher EAP-Austausch typischerweise nicht durch die Cipher-Suite der unteren Schicht geschützt werden, obwohl ein EAP-Neuauthentifizierungs- oder Vorauthentifizierungsaustausch geschützt werden kann.