4. EAP-Paketformat

Eine Zusammenfassung des EAP-Paketformats ist unten 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

Das Code-Feld ist ein Oktett und identifiziert den Typ des EAP-Pakets. EAP-Codes werden wie folgt zugewiesen:

1 Request 2 Response 3 Success 4 Failure

Da EAP nur Codes 1-4 definiert, MÜSSEN EAP-Pakete mit anderen Codes sowohl von Authentifikatoren als auch von Peers stillschweigend verworfen werden.

Identifier

Das Identifier-Feld ist ein Oktett und hilft beim Abgleich von Responses mit Requests.

Length (Länge)

Das Length-Feld besteht aus zwei Oktetten und gibt die Länge in Oktetten des EAP-Pakets an, einschließlich der Felder Code, Identifier, Length und Data. Oktette außerhalb des Bereichs des Length-Feldes sollten als Datenlink-Layer-Padding behandelt werden und MÜSSEN bei Empfang ignoriert werden. Eine Nachricht, bei der das Length-Feld auf einen Wert größer als die Anzahl der empfangenen Oktette gesetzt ist, MUSS stillschweigend verworfen werden.

Data (Daten)

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

4.1. Request und Response

Beschreibung

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

Erneut übertragene Requests MÜSSEN mit demselben Identifier-Wert gesendet werden, um sie von neuen Requests zu unterscheiden. Der Inhalt des Datenfeldes hängt vom Request-Type ab. Der Peer MUSS ein Response-Paket als Antwort auf ein gültiges Request-Paket senden. Responses MÜSSEN nur als Antwort auf eine gültige Anforderung gesendet werden und dürfen niemals auf einen Timer hin erneut übertragen werden.

Wenn ein Peer eine gültige doppelte Anforderung erhält, für die er bereits eine Antwort gesendet hat, MUSS er seine ursprüngliche Antwort erneut senden, ohne die Anforderung erneut zu verarbeiten. Requests MÜSSEN in der Reihenfolge verarbeitet werden, in der sie empfangen werden, und MÜSSEN bis zu ihrem Abschluss verarbeitet werden, bevor die nächste Anforderung inspiziert wird.

Eine Zusammenfassung des Request- und Response-Paketformats 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

1 für Request 2 für Response

Identifier

Das Identifier-Feld ist ein Oktett. Das Identifier-Feld MUSS gleich sein, wenn ein Request-Paket aufgrund eines Timeouts beim Warten auf eine Response erneut übertragen wird. Alle neuen (Nicht-Neuübertragung) Requests MÜSSEN das Identifier-Feld ändern.

Das Identifier-Feld der Response MUSS mit dem der aktuell ausstehenden Anforderung übereinstimmen. Ein Authentifikator, der eine Response erhält, deren Identifier-Wert nicht mit dem der aktuell ausstehenden Anforderung übereinstimmt, MUSS die Response stillschweigend verwerfen.

Um Verwirrung zwischen neuen Requests und Neuübertragungen zu vermeiden, muss der für jede neue Anforderung gewählte Identifier-Wert nur von der vorherigen Anforderung unterschiedlich sein, muss aber nicht innerhalb der Konversation eindeutig sein. Eine Möglichkeit, dies zu erreichen, besteht darin, den Identifier mit einem Anfangswert zu beginnen und ihn für jede neue Anforderung zu inkrementieren. Die Initialisierung des ersten Identifiers mit einer Zufallszahl anstatt bei Null zu beginnen wird empfohlen, da dies Sequenzangriffe etwas schwieriger macht.

Da der Identifier-Raum für jede Sitzung eindeutig ist, sind Authentifikatoren nicht auf nur 256 gleichzeitige Authentifizierungskonversationen beschränkt. Ebenso kann eine EAP-Konversation bei einer erneuten Authentifizierung über einen langen Zeitraum fortgesetzt werden und ist nicht auf nur 256 Rundfahrten beschränkt.

Implementierungshinweis: Der Authentifikator ist für die erneute Übertragung von Request-Nachrichten verantwortlich. Wenn die Request-Nachricht von anderswo bezogen wird (z. B. von einem Backend-Authentifizierungsserver), muss der Authentifikator eine Kopie der Anforderung speichern, um dies zu erreichen. 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 eine externe Partei. Der Authentifikator ist auch dafür verantwortlich, Response-Nachrichten mit einem nicht übereinstimmenden Identifier-Wert zu verwerfen, bevor er in irgendeiner Weise auf sie reagiert, einschließlich ihrer Weitergabe an den Backend-Authentifizierungsserver zur Überprüfung. Da der Authentifikator vor dem Empfang einer Response vom Peer erneut übertragen kann, kann der Authentifikator mehrere Responses empfangen, jede mit einem übereinstimmenden Identifier. Bis eine neue Anforderung vom Authentifikator empfangen wird, wird der Identifier-Wert nicht aktualisiert, sodass der Authentifikator Responses einzeln an den Backend-Authentifizierungsserver weiterleitet.

Length (Länge)

Das Length-Feld besteht aus zwei Oktetten und gibt die Länge des EAP-Pakets an, einschließlich der Felder Code, Identifier, Length, Type und Type-Data. Oktette außerhalb des Bereichs des Length-Feldes sollten als Datenlink-Layer-Padding behandelt werden und MÜSSEN bei Empfang ignoriert werden. Eine Nachricht, bei der das Length-Feld auf einen Wert größer als die Anzahl der empfangenen Oktette gesetzt ist, MUSS stillschweigend verworfen werden.

Type (Typ)

Das Type-Feld ist ein Oktett. Dieses Feld gibt den Typ der Anforderung oder Antwort an. Für jede EAP-Anforderung oder -Antwort MUSS ein einzelner Type angegeben werden. Eine anfängliche Spezifikation der Typen folgt in Abschnitt 5 dieses Dokuments.

Das Type-Feld einer Response MUSS entweder mit dem der Anforderung übereinstimmen oder einem Legacy- oder Expanded Nak (siehe Abschnitt 5.3) entsprechen, das anzeigt, dass ein Request-Type für den Peer nicht akzeptabel ist. Ein Peer DARF KEINE Nak (Legacy oder Expanded) als Antwort auf eine Anforderung senden, nachdem eine anfängliche Nicht-Nak-Response gesendet wurde. Ein EAP-Server, der eine Response erhält, die diese Anforderungen nicht erfüllt, MUSS sie stillschweigend verwerfen.

Type-Data

Das Type-Data-Feld variiert mit dem Type der Anforderung und der zugehörigen Response.

4.2. Success und Failure

Das Success-Paket wird vom Authentifikator nach Abschluss einer EAP-Authentifizierungsmethode (Typ 4 oder größer) an den Peer gesendet, um anzuzeigen, dass der Peer sich erfolgreich beim Authentifikator authentifiziert hat. Der Authentifikator MUSS ein EAP-Paket mit dem auf 3 (Success) gesetzten Code-Feld übertragen. Wenn der Authentifikator den Peer nicht authentifizieren kann (inakzeptable Responses auf eine oder mehrere Requests), dann MUSS die Implementierung nach erfolglosem Abschluss der laufenden EAP-Methode ein EAP-Paket mit dem auf 4 (Failure) gesetzten Code-Feld übertragen. Ein Authentifikator KANN mehrere Requests ausgeben, bevor er eine Failure-Response sendet, um menschliche Tippfehler zu ermöglichen. Success- und Failure-Pakete DÜRFEN KEINE zusätzlichen Daten enthalten.

Success- und Failure-Pakete DÜRFEN NICHT von einem EAP-Authentifikator gesendet werden, wenn die Spezifikation der gegebenen Methode nicht ausdrücklich erlaubt, dass die Methode an diesem Punkt endet. Eine Peer-EAP-Implementierung, die ein Success- oder Failure-Paket erhält, wenn das Senden nicht ausdrücklich erlaubt ist, MUSS es stillschweigend verwerfen. Standardmäßig MUSS ein EAP-Peer ein "konserviertes" Success-Paket (ein Success-Paket, das sofort nach der Verbindung gesendet wird) stillschweigend verwerfen. Dies stellt sicher, dass ein böswilliger Authentifikator die gegenseitige Authentifizierung nicht umgehen kann, indem er ein Success-Paket vor Abschluss der EAP-Methodenkonversation sendet.

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

Wie in Abschnitt 2.1 beschrieben, ist nur eine einzige EAP-Authentifizierungsmethode innerhalb einer EAP-Konversation zulässig. EAP-Methoden können Ergebnisanzeigen implementieren. Nachdem der Authentifikator eine Fehlergebnisanzeige an den Peer gesendet hat, MUSS er unabhängig von der Response des Peers anschließend ein Failure-Paket senden. Nachdem der Authentifikator eine Erfolgsgebnisanzeige an den Peer gesendet und eine Erfolgsgebnisanzeige vom Peer erhalten hat, MUSS er anschließend ein Success-Paket senden.

Auf dem Peer, sobald die Methode erfolglos abgeschlossen ist (d. h. entweder der Authentifikator sendet eine Fehlergebnisanzeige, oder der Peer entscheidet, dass er die Konversation nicht fortsetzen möchte, möglicherweise nach dem Senden einer Fehlergebnisanzeige), MUSS der Peer die Konversation beenden und der unteren Schicht einen Fehler anzeigen. Der Peer MUSS Success-Pakete stillschweigend verwerfen und KANN Failure-Pakete stillschweigend verwerfen. Infolgedessen muss der Verlust eines Failure-Pakets nicht zu einem Timeout führen.

Auf dem Peer, nachdem Erfolgsgebnisanzeigen von beiden Seiten ausgetauscht wurden, MUSS ein Failure-Paket stillschweigend verworfen werden. Der Peer KANN, falls ein EAP Success nicht empfangen wird, schlussfolgern, dass das EAP Success-Paket verloren gegangen ist und die Authentifizierung erfolgreich abgeschlossen wurde.

Wenn der Authentifikator keine Ergebnisanzeige gesendet hat und der Peer bereit ist, die Konversation fortzusetzen, wartet der Peer auf ein Success- oder Failure-Paket, sobald die Methode abgeschlossen ist, und DARF KEINES von beiden stillschweigend verwerfen. Falls weder ein Success- noch ein Failure-Paket empfangen wird, SOLLTE der Peer die Konversation beenden, um langwierige Timeouts zu vermeiden, falls das verlorene Paket ein EAP Failure war.

Wenn der Peer versucht, sich beim Authentifikator zu authentifizieren und dies nicht gelingt, MUSS der Authentifikator ein Failure-Paket senden und DARF KEINEN Zugriff durch Senden eines Success-Pakets gewähren. Ein Authentifikator KANN jedoch in Situationen, in denen begrenzter Zugriff angeboten wird (z. B. Gastzugriff), darauf verzichten, dass der Peer sich bei ihm authentifiziert. In diesem Fall MUSS der Authentifikator ein Success-Paket senden.

Wenn der Peer sich erfolgreich beim Authentifikator authentifiziert, der Authentifikator jedoch keine Ergebnisanzeige sendet, KANN der Authentifikator den Zugriff durch Senden eines Failure-Pakets verweigern, wenn der Peer derzeit nicht für den Netzwerkzugriff autorisiert ist.

Eine Zusammenfassung des Success- und Failure-Paketformats ist unten 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

3 für Success 4 für Failure

Identifier

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

Length (Länge)

4.3. Neuübertragungsverhalten (Retransmission Behavior)

Da der Authentifizierungsprozess häufig Benutzereingaben erfordert, muss bei der Entscheidung über Neuübertragungsstrategien und Authentifizierungs-Timeouts Vorsicht walten. Standardmäßig SOLLTE der EAP-Neuübertragungstimer dynamisch geschätzt werden, wenn EAP über eine unzuverlässige untere Schicht ausgeführt wird. Maximal 3-5 Neuübertragungen werden vorgeschlagen.

Wenn über eine zuverlässige untere Schicht ausgeführt (z. B. EAP über ISAKMP/TCP, wie in [PIC]), SOLLTE der Authentifikator-Neuübertragungstimer auf einen unendlichen Wert gesetzt werden, sodass Neuübertragungen nicht auf der EAP-Schicht auftreten. Der Peer kann dennoch einen Timeout-Wert beibehalten, um nicht unbegrenzt auf eine Anforderung zu warten.

Wenn der Authentifizierungsprozess Benutzereingaben erfordert, können die gemessenen Round-Trip-Zeiten durch Benutzerreaktionsfähigkeit und nicht durch Netzwerkeigenschaften bestimmt werden, sodass eine dynamische RTO-Schätzung möglicherweise nicht hilfreich ist. Stattdessen SOLLTE der Neuübertragungstimer so eingestellt werden, dass dem Benutzer ausreichend Zeit zum Antworten zur Verfügung steht, wobei in bestimmten Fällen längere Timeouts erforderlich sind, beispielsweise wenn Token-Karten (siehe Abschnitt 5.6) beteiligt sind.

Um dem EAP-Authentifikator Hinweise zum geeigneten Timeout-Wert zu geben, kann ein Hinweis vom Backend-Authentifizierungsserver an den Authentifikator übermittelt werden (z. B. über das RADIUS Session-Timeout-Attribut).

Um den EAP-Neuübertragungstimer dynamisch zu schätzen, werden die in [RFC2988] beschriebenen Algorithmen zur Schätzung von SRTT, RTTVAR und RTO EMPFOHLEN, einschließlich der Verwendung von Karns Algorithmus, mit den folgenden möglichen Modifikationen:

[a] Um Synchronisationsverhalten zu vermeiden, das bei festen Timern unter verteilten Systemen auftreten kann, wird der Neuübertragungstimer mit einem Jitter berechnet, indem der RTO-Wert verwendet und ein Wert zwischen -RTOmin/2 und RTOmin/2 zufällig hinzugefügt wird. Alternative Berechnungen zur Erzeugung von Jitter KÖNNEN verwendet werden. Diese MÜSSEN pseudozufällig sein. Für eine Diskussion der Pseudozufallszahlengenerierung siehe [RFC1750].

[b] Wenn EAP über eine einzelne Verbindung transportiert wird (im Gegensatz zum Internet), KÖNNEN kleinere Werte für RTOinitial, RTOmin und RTOmax verwendet werden. Empfohlene Werte sind RTOinitial=1 Sekunde, RTOmin=200ms und RTOmax=20 Sekunden.

[c] Wenn EAP über eine einzelne Verbindung transportiert wird (im Gegensatz zum Internet), KÖNNEN Schätzungen pro Authentifikator und nicht pro Sitzung durchgeführt werden. Dies ermöglicht es der Neuübertragungsschätzung, die Informationen über das Verhalten der Verbindungsschicht am besten zu nutzen.

[d] Eine EAP-Implementierung KANN SRTT und RTTVAR löschen, nachdem der Timer mehrmals zurückgesetzt wurde, da SRTT und RTTVAR in dieser Situation wahrscheinlich falsch sind. Sobald SRTT und RTTVAR gelöscht sind, sollten sie mit der nächsten RTT-Probe initialisiert werden, die wie in [RFC2988] Gleichung 2.2 beschrieben genommen wird.