3. Lower Layer Behavior

3.1. Anforderungen an die untere Schicht

EAP macht die folgenden Annahmen über die untere Schicht:

[1] Unzuverlässiger Transport. In EAP überträgt der Authenticator Requests, für die keine Response empfangen wurde, erneut, daher geht EAP nicht davon aus, dass die untere Schicht zuverlässig ist. Da EAP sein eigenes Retransmissionsverhalten definiert, ist es bei EAP-Betrieb über einer zuverlässigen unteren Schicht möglich (wenn auch unerwünscht), dass Retransmissionen sowohl in der unteren Schicht als auch in der EAP-Schicht auftreten.

Beachten Sie, dass EAP Success- und Failure-Pakete nicht erneut übertragen werden. Ohne zuverlässige untere Schicht und bei nicht vernachlässigbarer Fehlerrate können diese Pakete verloren gehen und ein Timeout verursachen. Daher ist es wünschenswert, dass Implementierungen ihre Widerstandsfähigkeit gegen den Verlust von EAP Success- oder Failure-Paketen wie in Abschnitt 4.2 beschrieben erhöhen.

[2] Fehlererkennung der unteren Schicht. Obwohl EAP nicht davon ausgeht, dass die untere Schicht zuverlässig ist, verlässt es sich auf die Fehlererkennung der unteren Schicht (z. B. CRC, Checksum, MIC usw.). EAP-Methoden enthalten möglicherweise kein MIC, oder selbst wenn sie eines enthalten, wird es möglicherweise nicht über alle Felder des EAP-Pakets (z. B. Code-, Identifier-, Length- oder Type-Felder) berechnet. Daher können ohne Fehlererkennung der unteren Schicht unentdeckte Fehler in die Headerfelder der EAP-Schicht oder der EAP-Methodenschicht gelangen und einen Authentifizierungsfehler verursachen.

Beispielsweise berechnet EAP TLS [RFC2716] sein MIC nur über das Type-Data-Feld und behandelt einen MIC-Validierungsfehler als fatalen Fehler. Ohne Fehlererkennung der unteren Schicht können diese und ähnliche Methoden nicht zuverlässig funktionieren.

[3] Sicherheit der unteren Schicht. EAP verlangt nicht, dass die untere Schicht Sicherheitsdienste wie Vertraulichkeit, Authentifizierung, Integrität und Replayschutz pro Paket bereitstellt. Wenn diese Sicherheitsdienste jedoch bereitgestellt werden, können EAP-Methoden, die die Schlüsselableitung 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 deren Änderung, Spoofing oder Replay zu verhindern. Details siehe Abschnitt 7.1.

[4] Minimale MTU. EAP kann über einer unteren Schicht betrieben werden, die eine EAP-MTU-Größe von 1020 Byte oder mehr bereitstellt.

EAP unterstützt keine Path-MTU-Discovery, und Fragmentierung und Reassemblierung werden von EAP nicht unterstützt, ebenso wenig von den in diesem Dokument definierten Methoden: Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) und expanded Nak Response (254) Typen.

Normalerweise erhält der EAP-Peer Informationen über die EAP-MTU von der unteren Schicht und setzt die EAP-Rahmengröße auf einen entsprechenden Wert. Wenn der Authenticator im Pass-Through-Modus betrieben wird, hat der Authentifizierungsserver keine direkte Möglichkeit, die EAP-MTU zu bestimmen, und verlässt sich daher darauf, dass der Authenticator ihm diese Information zur Verfügung stellt, z. B. über das Framed-MTU-Attribut, wie in [RFC3579] Abschnitt 2.4 beschrieben.

Obwohl 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 für Kontrollrahmen eine MTU von 1500 Byte garantiert ist, siehe [RFC1661] Abschnitt 6.1), möglicherweise keine Fragmentierungs- und Reassemblierungsfunktion aufweisen.

Ohne andere Informationen kann eine EAP-Methode eine minimale EAP-MTU von 1020 Byte annehmen. Wenn die Nutzlast einer EAP-Methode größer als diese minimale EAP-MTU sein könnte, SOLLTE sie die Unterstützung für Fragmentierung und Reassemblierung enthalten.

Da EAP ein "Lock-Step"-Protokoll (lock step) ist, gibt es eine gewisse Ineffizienz bei der Verarbeitung von Fragmentierung und Reassemblierung. Daher ist es möglicherweise vorzuziehen, dass Fragmentierung und Reassemblierung in der unteren Schicht (nicht in EAP) erfolgen, wenn die untere Schicht Fragmentierung und Reassemblierung unterstützt (z. B. wenn EAP über IP transportiert wird). Dies kann erreicht werden, indem EAP eine künstlich größere EAP-MTU bereitgestellt wird, sodass die Fragmentierung in der unteren Schicht behandelt wird.

[5] Mögliche Duplikate. Im Fall einer zuverlässigen unteren Schicht stellt sie der EAP-Schicht einen nicht duplizierten Paketstrom zur Verfügung. Obwohl die Bereitstellung von Nicht-Duplikaten wünschenswert ist, ist dies keine Anforderung. Das Identifier-Feld bietet sowohl Peer als auch Authenticator die Möglichkeit zur Duplikaterkennung.

[6] Reihenfolgegarantien. EAP verlangt nicht, dass Identifier monoton steigt, und verlässt sich daher für den korrekten Betrieb auf die Reihenfolgegarantien der unteren Schicht. EAP wurde ursprünglich für den Betrieb über PPP definiert, und [RFC1661] Abschnitt 1 enthält eine Reihenfolgeanforderung:

"Das Point-to-Point Protocol ist für einfache Verbindungen zwischen zwei Peers konzipiert. Diese Verbindungen bieten vollduplexen simultanen bidirektionalen Betrieb und gehen von der paketweisen Zustellung in Reihenfolge aus."

Der EAP-Transport der unteren Schicht MUSS die Reihenfolge zwischen Quelle und Ziel bei einer bestimmten Prioritätsstufe beibehalten (von [IEEE-802] bereitgestellte Reihenfolgegarantien).

Wenn eine Neuordnung auftritt, führt dies im Allgemeinen zu einem EAP-Authentifizierungsfehler, der die erneute Ausführung der EAP-Authentifizierung auslöst. Daher sind EAP-Authentifizierungsfehler in Umgebungen, in denen eine Neuordnung auftreten kann, voraussichtlich häufig. Es wird empfohlen, EAP nur über untere Schichten zu betreiben, die Reihenfolgegarantien bieten; der Betrieb von EAP über rohes IP oder UDP wird NICHT EMPFOHLEN. Die Kapselung von EAP in RADIUS [RFC3579] erfüllt die Reihenfolgeanforderung, da RADIUS ein "Lock-Step"-Protokoll ist, das Pakete in Reihenfolge zustellt.

3.2. Verwendung von EAP in PPP

Um die Kommunikation über eine Punkt-zu-Punkt-Verbindung herzustellen, sendet jedes Ende der PPP-Verbindung zunächst LCP-Pakete, um die Datenverbindung in der Verbindungsaufbauphase zu konfigurieren. Nach dem Verbindungsaufbau bietet PPP vor dem Eintritt in die Netzwerkschichtprotokollphase eine optionale Authentifizierungsphase an.

Standardmäßig ist die Authentifizierung nicht obligatorisch. Wenn eine Authentifizierung der Verbindung erforderlich ist, MUSS die Implementierung die Konfigurationsoption des Authentifizierungsprotokolls in der Verbindungsaufbauphase angeben.

Wenn die Identität des Peers in der Authentifizierungsphase bestimmt wird, kann der Server diese Identität bei der Auswahl der Optionen für die anschließende Aushandlung der Netzwerkschicht verwenden.

Bei Implementierung in PPP wählt EAP keinen spezifischen Authentifizierungsmechanismus in der Linkkontrollphase aus, sondern verschiebt ihn auf die Authentifizierungsphase. Dies ermöglicht es dem Authenticator, zusätzliche Informationen anzufordern, bevor ein bestimmter Authentifizierungsmechanismus festgelegt wird. Dies ermöglicht auch die Verwendung eines "Backend"-Servers, der die verschiedenen Mechanismen tatsächlich implementiert, während der PPP-Authenticator den Authentifizierungsaustausch lediglich durchleitet. Die PPP-Verbindungsaufbau- und Authentifizierungsphase sowie die Konfigurationsoption des Authentifizierungsprotokolls sind im Point-to-Point Protocol (PPP) [RFC1661] definiert.

3.2.1. PPP-Konfigurationsoptionformat

Das Format der PPP-Authentifizierungsprotokoll-Konfigurationsoption, die zur Aushandlung von EAP verwendet wird, ist unten zusammengefasst. Die Felder werden von links nach rechts übertragen.

Genau ein EAP-Paket wird im Information-Feld des Datenverbindungsschichtrahmens von PPP 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

Length

Authentication Protocol

C227 (hexadezimal) für das Extensible Authentication Protocol (EAP)

3.3. Verwendung von EAP in IEEE 802

Die Kapselung von EAP in IEEE 802 ist in [IEEE-802.1X] definiert. Die Kapselung von EAP durch IEEE 802 beinhaltet kein PPP, und IEEE 802.1X enthält keine Unterstützung für die Aushandlung von Verbindungs- oder Netzwerkschicht. Daher ist es in IEEE 802.1X nicht möglich, nicht-EAP-Authentifizierungsmechanismen wie PAP oder CHAP [RFC1994] auszuhandeln.

3.4. Hinweise der unteren Schicht

Die Zuverlässigkeit und Sicherheit der Hinweise der unteren Schicht hängen 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 der Peer, wenn er einen lower layer success-Hinweis wie in Abschnitt 7.2 definiert empfängt, schließen, dass ein Success-Paket verloren ging, und so handeln, als habe er das Success-Paket tatsächlich empfangen. Dazu gehört es, das Success in bestimmten Fällen zu ignorieren, wie in Abschnitt 4.2 beschrieben.

Eine Erörterung einiger Zuverlässigkeits- und Sicherheitsprobleme von Hinweisen der unteren Schicht in PPP, IEEE-802-Drahtnetzwerken und IEEE-802.11-Drahtlos-LANs findet sich in den Sicherheitsüberlegungen, Abschnitt 7.12.

Nach Abschluss der EAP-Authentifizierung überträgt der Peer normalerweise Daten über den Authenticator. Es wird erwartet, dass eine Garantie besteht, dass die Einheit, die Daten sendet und empfängt, dieselbe ist wie die, die die EAP-Authentifizierung erfolgreich abgeschlossen hat. Um dies zu erreichen, ist es notwendig, dass die untere Schicht paketweise Integrität, Authentifizierung und Replayschutz bereitstellt und diese paketweisen Dienste an die während der EAP-Authentifizierung abgeleiteten Schlüssel bindet. Andernfalls könnten nachfolgende Datenströme geändert, gefälscht oder wiedergegeben werden.

Wenn das Schlüsselmaterial der kryptografischen Suite der unteren Schicht von EAP selbst bereitgestellt wird, werden Aushandlung und Aktivierung der Schlüssel von der unteren Schicht gesteuert. In PPP wird die kryptografische Suite in ECP ausgehandelt, daher ist es vor Abschluss von ECP unmöglich, die aus der EAP-Authentifizierung abgeleiteten Schlüssel zu verwenden. Daher kann der anfängliche EAP-Austausch nicht durch die PPP-kryptografische Suite geschützt werden, obwohl die EAP-Re-Authentifizierung geschützt werden kann.

In IEEE-802-Medien erfolgt die anfängliche Schlüsselaktivierung normalerweise ebenfalls nach Abschluss der EAP-Authentifizierung. Daher kann der anfängliche EAP-Austausch normalerweise nicht durch die kryptografische Suite der unteren Schicht geschützt werden, obwohl der EAP-Re-Authentifizierungs- oder Pre-Authentifizierungsaustausch geschützt werden kann.