4. EAP Packet Format

Eine Zusammenfassung des EAP-Paketformats ist nachstehend dargestellt. Die Felder werden von links nach rechts übertragen.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

Das Code-Feld ist ein Oktett und identifiziert den Pakettyp von EAP. Die EAP-Codes sind wie folgt zugewiesen:

     Request
     Response
     Success
     Failure

Da EAP nur die Codes 1-4 definiert, MÜSSEN EAP-Pakete mit anderen Codes sowohl vom Authenticator als auch vom Peer stillschweigend verworfen werden.

Identifier

Das Identifier-Feld ist ein Oktett und hilft, Antworten mit Anfragen abzugleichen.

Length

Das Length-Feld umfasst zwei Oktette und gibt die Länge des EAP-Pakets einschließlich der Felder Code, Identifier, Length und Data in Oktetten an. Oktette außerhalb des Bereichs des Length-Felds sollten als Füllung der Datensicherungsschicht behandelt und bei Empfang ignoriert werden. Eine Nachricht, deren Length-Feld auf einen Wert größer als die Anzahl der empfangenen Oktette gesetzt ist, MUSS stillschweigend verworfen werden.

Data

Das Data-Feld besteht aus null oder mehr Oktetten. Das Format des Data-Felds wird durch das Code-Feld bestimmt.

4.1. Request und Response

Beschreibung

Das Request-Paket (Code-Feld auf 1 gesetzt) wird vom Authenticator an den Peer gesendet. Jede Request hat ein Type-Feld, das angibt, was angefordert wird. Es MÜSSEN weitere Request-Pakete gesendet werden, bis eine gültige Response empfangen wird, ein optionaler Wiederholungszähler abläuft oder eine Fehleranzeige von der unteren Schicht empfangen wird.

Erneut gesendete Requests MÜSSEN mit demselben Identifier-Wert gesendet werden, um sie von neuen Requests zu unterscheiden. Der Inhalt des data-Felds hängt vom Request-Typ ab. Der Peer MUSS als Antwort auf ein gültiges Request-Paket ein Response-Paket senden. Responses SOLLTEN nur als Antwort auf eine gültige Request gesendet werden und DÜRFEN niemals über einen Timer erneut gesendet werden.

Wenn ein Peer eine gültige doppelte Request empfängt, für die er bereits eine Response gesendet hat, MUSS er seine ursprüngliche Response erneut senden, ohne die Request erneut zu verarbeiten. Requests MÜSSEN in der Reihenfolge ihres Eingangs verarbeitet werden und MÜSSEN vollständig verarbeitet werden, bevor die nächste Request untersucht wird.

Eine Zusammenfassung des Formats der Request- und Response-Pakete folgt. Die Felder werden von links nach rechts übertragen.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   1 for Request
   2 for Response

Identifier

Das Identifier-Feld ist ein Oktett. Das Identifier-Feld MUSS dasselbe sein, wenn ein Request-Paket aufgrund eines Timeouts beim Warten auf eine Response erneut gesendet wird. Jede neue Request (keine erneute Sendung) MUSS das Identifier-Feld ändern.

Das Identifier-Feld der Response MUSS mit dem der aktuell ausstehenden Request übereinstimmen. Ein Authenticator, der eine Response empfängt, deren Identifier-Wert nicht mit der aktuell ausstehenden Request übereinstimmt, MUSS die Response stillschweigend verwerfen.

Um Verwechslungen zwischen neuen Requests und erneuten Sendungen zu vermeiden, MUSS der für jede neue Request gewählte Identifier-Wert nur von der vorherigen Request abweichen, muss aber nicht innerhalb der Konversation eindeutig sein. Eine Möglichkeit, dies zu erreichen, besteht darin, den Identifier von einem Anfangswert zu starten und für jede neue Request zu erhöhen. Es wird empfohlen, den ersten Identifier mit einer Zufallszahl zu initialisieren, anstatt bei Null zu beginnen, da dies Sequenzangriffe etwas schwieriger macht.

Da der Identifier-Raum für jede Sitzung eindeutig ist, ist der Authenticator nicht auf nur 256 gleichzeitige Authentifizierungssitzungen beschränkt. Ebenso kann sich bei der Re-Authentifizierung ein EAP-Gespräch über einen langen Zeitraum erstrecken und ist nicht auf nur 256 Hin- und Rückläufe beschränkt.

Implementierungshinweis: Der Authenticator ist für die erneute Übertragung von Request-Nachrichten verantwortlich. Wenn die Request-Nachricht von anderswo (z. B. von einem Backend-Authentifizierungsserver) bezogen wird, muss der Authenticator eine Kopie der Request speichern, um dies ausführen zu können. Der Peer ist dafür verantwortlich, doppelte Request-Nachrichten zu erkennen und zu behandeln, bevor er sie in irgendeiner Weise verarbeitet, einschließlich ihrer Weitergabe an einen externen Teilnehmer. Der Authenticator ist darüber hinaus dafür verantwortlich, Response-Nachrichten mit nicht übereinstimmendem Identifier-Wert stillschweigend zu verwerfen, bevor er in irgendeiner Weise auf sie reagiert, einschließlich ihrer Weitergabe an den Backend-Authentifizierungsserver zur Überprüfung. Da der Authenticator möglicherweise erneut sendet, bevor er eine Response vom Peer erhält, kann der Authenticator mehrere Responses empfangen, jede mit übereinstimmendem Identifier. Bis eine neue Request vom Authenticator empfangen wird, wird der Identifier-Wert nicht aktualisiert, so dass der Authenticator die Responses dem Backend-Authentifizierungsserver nacheinander weiterleitet.

Length

Das Length-Feld umfasst zwei Oktette und gibt die Länge des EAP-Pakets einschließlich der Felder Code, Identifier, Length, Type und Type-Data an. Oktette außerhalb des Bereichs des Length-Felds sollten als Füllung der Datensicherungsschicht behandelt und bei Empfang ignoriert werden. Eine Nachricht, deren Length-Feld auf einen Wert größer als die Anzahl der empfangenen Oktette gesetzt ist, MUSS stillschweigend verworfen werden.

Type

Das Type-Feld ist ein Oktett. Dieses Feld gibt den Typ der Request oder Response an. Für jede Request oder Response EAP MUSS ein einzelner Type angegeben werden. Eine erste Spezifikation der Types folgt in Abschnitt 5 dieses Dokuments.

Das Type-Feld einer Response MUSS mit dem der Request übereinstimmen oder einer Legacy- oder erweiterten Nak entsprechen (siehe Abschnitt 5.3), die angibt, dass ein Request-Type für den Peer nicht akzeptabel ist. Ein Peer DARF keine Nak (Legacy oder erweitert) als Antwort auf eine Request senden, nachdem eine erste nicht-Nak-Response gesendet wurde. Ein EAP-Server, der eine Response empfängt, die diese Anforderungen nicht erfüllt, MUSS sie stillschweigend verwerfen.

Type-Data

Das Type-Data-Feld variiert mit dem Typ der Request und der entsprechenden Response.

4.2. Success und Failure

Das Success-Paket wird vom Authenticator an den Peer gesendet, nachdem eine EAP-Authentifizierungsmethode (Typ 4 oder höher) abgeschlossen ist, um anzugeben, dass sich der Peer erfolgreich beim Authenticator authentifiziert hat. Der Authenticator MUSS ein EAP-Paket mit dem auf 3 (Success) gesetzten Code-Feld übertragen. Wenn sich der Peer nicht authentifizieren kann (inakzeptable Responses auf eine oder mehrere Requests), MUSS die Implementierung nach dem fehlgeschlagenen Abschluss der laufenden EAP-Methode ein EAP-Paket mit dem auf 4 (Failure) gesetzten Code-Feld übertragen. Ein Authenticator möchte möglicherweise mehrere Requests senden, bevor er eine Failure-Antwort sendet, um menschliche Eingabefehler zuzulassen. Success- und Failure-Pakete DÜRFEN KEINE zusätzlichen Daten enthalten.

Success- und Failure-Pakete DÜRFEN von einem Authenticator EAP nicht gesendet werden, wenn die Spezifikation der jeweiligen Methode das Beenden der Methode an dieser Stelle nicht ausdrücklich erlaubt. Eine Peer-EAP-Implementierung, die ein Success- oder Failure-Paket empfängt, dessen Senden nicht ausdrücklich erlaubt ist, MUSS es stillschweigend verwerfen. Standardmäßig MUSS ein Peer EAP ein „canned" Success-Paket (ein unmittelbar beim Öffnen der Verbindung gesendetes Success-Paket) stillschweigend verwerfen. Dies stellt sicher, dass ein böswilliger Authenticator nicht in der Lage ist, die gegenseitige Authentifizierung zu umgehen, indem er ein Success-Paket vor Abschluss des EAP-Methoden-Gesprächs sendet.

Implementierungshinweis: Da Success- und Failure-Pakete nicht bestätigt werden, werden sie vom Authenticator nicht erneut gesendet und könnten möglicherweise verloren gehen. Ein Peer MUSS diese Umstände berücksichtigen, wie in diesem Hinweis beschrieben. Siehe auch Abschnitt 3.4 für Richtlinien zur Verarbeitung von Erfolgs- und Fehleranzeigen der unteren Schicht.

Wie in Abschnitt 2.1 beschrieben, ist innerhalb eines EAP-Gesprächs nur eine EAP-Authentifizierungsmethode zulässig. EAP-Methoden können Ergebnisanzeigen implementieren. Nachdem der Authenticator dem Peer eine Fehlerergebnis-Anzeige gesendet hat, MUSS er unabhängig von der Antwort des Peers anschließend ein Failure-Paket senden. Nachdem der Authenticator dem Peer eine Erfolgsergebnis-Anzeige gesendet und eine Erfolgsergebnis-Anzeige vom Peer empfangen hat, MUSS er anschließend ein Success-Paket senden.

Auf Peer-Seite MUSS der Peer, sobald die Methode nicht erfolgreich abgeschlossen wurde (d. h. der Authenticator sendet eine Fehlerergebnis-Anzeige, oder der Peer beschließt, das Gespräch nicht fortzusetzen, wahrscheinlich nachdem er eine Fehlerergebnis-Anzeige gesendet hat), das Gespräch beenden und den Fehler an die untere Schicht melden. Der Peer MUSS Success-Pakete stillschweigend verwerfen und DARF Failure-Pakete stillschweigend verwerfen. Folglich muss der Verlust eines Failure-Pakets nicht notwendigerweise einen Timeout verursachen.

Auf Peer-Seite MUSS, nachdem Ergebnisanzeigen für Erfolg von beiden Seiten ausgetauscht wurden, ein Failure-Paket stillschweigend verworfen werden. Der Peer DARF, falls kein EAP Success empfangen wurde, schlussfolgern, dass das EAP Success-Paket verloren ging und die Authentifizierung erfolgreich abgeschlossen wurde.

Wenn der Authenticator keine Ergebnisanzeige gesendet hat und der Peer bereit ist, das Gespräch fortzusetzen, wartet der Peer nach Abschluss der Methode auf ein Success- oder Failure-Paket und DARF sie nicht stillschweigend verwerfen. Falls weder ein Success-Paket noch ein Failure-Paket empfangen wurde, SOLLTE der Peer das Gespräch beenden, um lange Timeouts im Fall zu vermeiden, dass das verlorene Paket ein EAP Failure war.

Wenn der Peer versucht, sich beim Authenticator zu authentifizieren, und dies nicht gelingt, MUSS der Authenticator ein Failure-Paket senden und DARF den Zugriff nicht gewähren, indem er ein Success-Paket sendet. Ein Authenticator KANN jedoch die Authentifizierung des Peers bei sich in Situationen auslassen, in denen eingeschränkter Zugriff (z. B. Gastzugriff) angeboten wird. In diesem Fall MUSS der Authenticator ein Success-Paket senden.

Wo sich der Peer erfolgreich beim Authenticator authentifiziert, der Authenticator jedoch keine Ergebnisanzeige sendet, KANN der Authenticator den Zugriff verweigern, indem er ein Failure-Paket sendet, in den Fällen, in denen der Peer derzeit nicht für den Netzwerkzugriff autorisiert ist.

Eine Zusammenfassung des Formats der Success- und Failure-Pakete ist nachstehend dargestellt. Die Felder werden von links nach rechts übertragen.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   3 for Success
   4 for Failure

Identifier

Das Identifier-Feld ist ein Oktett und hilft, Antworten mit Responses abzugleichen. Das Identifier-Feld MUSS mit dem Identifier-Feld des Response-Pakets übereinstimmen, auf das es als Antwort gesendet wird.

Length

4.3. Retransmissionsverhalten

Da der Authentifizierungsprozess oft eine Benutzereingabe beinhaltet, muss bei der Entscheidung über Retransmissionsstrategien und Authentifizierungs-Timeouts Sorgfalt waltengelassen werden. Standardmäßig SOLLTE, wenn EAP über eine unzuverlässige untere Schicht ausgeführt wird, der EAP-Retransmissions-Timer dynamisch geschätzt werden. Eine maximale Anzahl von 3-5 Retransmissionen wird vorgeschlagen.

Wenn es über eine zuverlässige untere Schicht ausgeführt wird (z. B. EAP über ISAKMP/TCP, wie in [PIC]), SOLLTE der Retransmissions-Timer des Authenticators auf einen unendlichen Wert gesetzt werden, sodass auf der EAP-Schicht keine Retransmissionen stattfinden. Der Peer kann weiterhin einen Timeout-Wert beibehalten, um das unbegrenzte Warten auf eine Request zu vermeiden.

Wenn der Authentifizierungsprozess eine Benutzereingabe erfordert, können die gemessenen Round-Trip-Zeiten eher durch die Reaktionsfähigkeit des Benutzers als durch Netzwerkeigenschaften bestimmt sein, sodass die dynamische Schätzung des RTO möglicherweise nicht nützlich ist. Stattdessen SOLLTE der Retransmissions-Timer so eingestellt werden, dass er dem Benutzer ausreichend Zeit zur Antwort gibt, wobei in einigen Fällen (z. B. wenn Token-Karten beteiligt sind, siehe Abschnitt 5.6) längere Timeouts erforderlich sind.

Um dem Authenticator EAP eine Anleitung bezüglich des angemessenen Timeout-Werts zu geben, kann dem Authenticator vom Backend-Authentifizierungsserver ein Vorschlag mitgeteilt werden (z. B. über das RADIUS-Attribut Session-Timeout).

Um den EAP-Retransmissions-Timer dynamisch zu schätzen, werden die in [RFC2988] beschriebenen Algorithmen zur Schätzung von SRTT, RTTVAR und RTO, einschließlich der Verwendung des Karn-Algorithmus, mit den folgenden potenziellen Änderungen empfohlen:

[a] Um Synchronisationsverhalten zu vermeiden, das bei festen Timern zwischen verteilten Systemen auftreten kann, wird der Retransmissions-Timer mit Jitter berechnet, indem der RTO-Wert verwendet und zufällig ein Wert zwischen -RTOmin/2 und RTOmin/2 addiert wird. Es können alternative Berechnungen zur Erzeugung von Jitter verwendet werden. Diese MÜSSEN pseudo-zufällig sein. Für eine Diskussion zur Erzeugung von Pseudo-Zufallszahlen siehe [RFC1750].

[b] Wenn EAP über ein einzelnes Link (statt über das Internet) transportiert wird, können kleinere Werte von RTOinitial, RTOmin und RTOmax verwendet werden. Empfohlene Werte sind RTOinitial=1 Sekunde, RTOmin=200ms und RTOmax=20 Sekunden.

[c] Wenn EAP über ein einzelnes Link (statt über das Internet) transportiert wird, können die Schätzungen pro Authenticator statt pro Sitzung durchgeführt werden. Dies ermöglicht der Retransmissions-Schätzung, die Informationen über das Verhalten der unteren Schicht maximal zu nutzen.

[d] Eine EAP-Implementierung KANN SRTT und RTTVAR löschen, nachdem der Timer mehrmals verringert wurde, da es in dieser Situation wahrscheinlich ist, dass die aktuellen SRTT und RTTVAR falsch sind. Nachdem SRTT und RTTVAR gelöscht wurden, sollten sie mit dem als nächstes entnommenen RTT-Beispiel initialisiert werden, wie in Gleichung 2.2 von [RFC2988] beschrieben.