5. Initial EAP Request/Response Types

Um die zu verwendende Authentifizierungsmethode zu bestimmen, werden zu Beginn der Authentifizierung EAP Request/Response-Pakete gesendet. Dieses Dokument definiert die für alle EAP-Implementierungen gemeinsamen Anfangstypen: Identity, Notification, Nak, MD5-Challenge, One-Time Password, Generic Token Card und Expanded Nak. Die übrigen EAP-Typen sind in den EAP-Methodendokumenten definiert. Alle EAP-Implementierungen MÜSSEN Identity, Nak, MD5-Challenge, One-Time Password, Generic Token Card und Expanded Nak unterstützen.

EAP-Methodendokumente SOLLTEN angeben, ob die Methode Fragmentierung, Schlüsselableitung, gegenseitige Authentifizierung und Ergebnisanzeige unterstützt. Diese Eigenschaften werden in Abschnitt 7.5 ausführlicher beschrieben.

5.1. Identity

5.1.1. Überblick

Description

Zu Beginn der Authentifizierung KANN der Authenticator ein EAP-Request-Paket vom Typ Identity an den Peer senden, um eine Response auf die EAP-Request Identity anzufordern. Sofern der Peer seine Kennung nicht bereits auf andere Weise kennt (z. B. Anrufer-ID für einen Einwahlbenutzer), SOLLTE der Peer mit einem EAP-Response Identity-Paket antworten, das seinen Network Access Identifier (NAI) [RFC2486] enthält. In einigen Umgebungen KANN der Authenticator den Domänenteil des NAI verwenden, um die Authentifizierungsanfrage zu routen (z. B. in einem RADIUS-Proxy [RFC2865]). Weitere Verwendungen von NAI werden in [RFC2486] erörtert.

Wenn der Authenticator die Authentifizierung nicht mit dem Senden einer EAP-Request Identity beginnt, KANN der Peer nach Erhalt der ersten EAP-Request ein EAP-Response Identity-Paket senden, das seine Antwort auf den NAI enthält. Wenn zu Beginn der Authentifizierung eine sofortige Authentifizierung des Peers erforderlich ist und die Identität des Peers nicht wichtig ist, KANN der Authenticator die EAP-Request Identity umgehen und direkt einen anderen EAP-Request-Typ (z. B. MD5-Challenge) senden.

Type

Type-Data

Das Type-Data-Feld KANN einen Datenblock enthalten, der aus Text besteht, der dem Benutzer angezeigt und zur Eingabeaufforderung verwendet wird. Dieser Text MUSS in UTF-8-kodierten ISO-10646-Zeichen [ISO.10646] dargestellt werden. Der Authenticator SOLLTE die nächste EAP-Request unmittelbar nach Erhalt der EAP-Response des Peers senden; ein EAP-Response-Paket vom Typ 1 SOLLTE keine erneute Sendung einer EAP-Request Identity auslösen.

In Implementierungen SOLLTEN Peer und Authenticator die Identity Request/Response für Authentifizierungsmethoden zugänglich machen, damit Methoden bei Bedarf auf die Identität zugreifen können (z. B. für tunnelierte Methoden).

5.1.2. Identitätsverwaltung

In einigen Umgebungen kann das Fehlen oder die falsche Darstellung von Identitätsinformationen des Peers (z. B. Verwendung des NAI-Formats, aber ohne ausreichende Informationen zur eindeutigen Identifizierung des Benutzers zwischen zwei Peers) zu einem Authentifizierungsfehler führen. Probleme der Identitätsverwaltung in EAP-Bereitstellungen umfassen die Identitätsauswahl und den Identitätsschutz.

Identitätsauswahl

Beim Verbindungsaufbau kennt der Peer die Fähigkeiten des Authenticators nicht und KANN bei der Initiierung der Authentifizierung eine Standardidentität verwenden. Bei zertifikatbasierten Methoden offenbart das verwendete Zertifikat normalerweise die Identität des Peers. In Methoden wie EAP-TLS [RFC2716], EAP-TTLS [EAP-TTLS] und PEAP [PEAP] KANN das verwendete Zertifikat, der Benutzername oder die anonyme Identität bei jeder Authentifizierungsattempt unterschiedlich sein. Sobald der Authenticator den Peer authentifiziert hat, KANN er Hinweise zum vom Peer zu verwendenden Benutzernamen oder Zertifikat geben (z. B. im Tunnel). Dies kann als Identität für einen zweiten Authentifizierungsversuch nach fehlgeschlagener anfänglicher Identitätsaushandlung verwendet werden.

Identitätsschutz

Vor Abschluss der EAP-Authentifizierung KANN die Identität des Peers Dritten preisgegeben werden. Um dies zu verhindern, KÖNNEN EAP-Methoden Identitätsschutz unterstützen (z. B. durch Verschlüsselung oder anonyme Kennungen). In EAP-TLS [RFC2716] kann die Identität im Tunnel bereitgestellt werden, wodurch sie vor passivem Abhören geschützt ist. In EAP-TTLS [EAP-TTLS] und PEAP [PEAP] wird für den anfänglichen Handshake eine anonyme Identität verwendet, und die tatsächliche Identität wird im Tunnel bereitgestellt.

5.2. Notification

Description

Ein EAP-Request- oder EAP-Response-Paket mit dem Wert Notification als Typ wird verwendet, um eine für Menschen lesbare Nachricht zu übermitteln. Der Peer KANN diese Nachricht dem Benutzer anzeigen oder sie protokollieren und/oder einem Administrator vorlegen. Der Authenticator KANN eine Benachrichtigung senden, um den Benutzer über etwas zu informieren (z. B. "Sie werden gleich getrennt"). Der Peer SOLLTE mit einem EAP-Response-Paket mit dem Wert Notification antworten und KANN wählen, die Nachricht nicht anzuzeigen (oder nur einen Teil davon). Die Nachricht SOLLTE jedoch in UTF-8-kodierten ISO-10646-Zeichen [ISO.10646] bereitgestellt werden.

Wenn eine Notification-Anfrage vor Abschluss der Authentifizierung gesendet wird, SOLLTE der Peer mit einer Notification-Antwort antworten, selbst wenn er die Nachricht nicht anzeigen möchte. Eine nach Abschluss des EAP-Authentifizierungsprozesses gesendete Benachrichtigung KANN vom Peer ignoriert werden und DARF NICHT verwendet werden, um Daten zu transportieren, die für eine andere EAP-Methode bestimmt sind.

Type

Type-Data

Textnachricht, die dem Benutzer angezeigt wird, in UTF-8-kodierten ISO-10646-Zeichen [ISO.10646].

5.3. Nak

5.3.1. Legacy Nak

Description

Der Peer sendet ein EAP-Response-Paket mit dem Wert Nak, um dem Authenticator seine Ablehnung der anfänglichen EAP-Request mitzuteilen. Ein NAK wird nur als Antwort auf eine EAP-Request gesendet, wenn die gesendete anfängliche Antwort kein Nak war, und SOLLTE nur nahe dem Beginn der Authentifizierung auftreten. Im Allgemeinen wird ein Nak nur gesendet, wenn der Authenticator einen Authentifizierungstyp anfordert, den der Peer nicht unterstützt, kann aber auch gesendet werden, wenn der Authenticator einen Authentifizierungstyp anfordert, den der Peer unterstützt, aber einige Konfigurationsdetails nicht akzeptabel sind (z. B. der Peer unterstützt die Methode, aber der NAS kann die von der Methode benötigte Dienstqualität nicht bieten). Bei Empfang eines Nak KANN der Authenticator antworten, indem er den vom Peer im Nak vorgeschlagenen Authentifizierungstyp sendet oder eine andere EAP-Request sendet. EAP-Methodendokumente KÖNNEN angeben, ob eine Methode ausgehandelt werden kann (über Nak) oder ob sie obligatorisch ist (d. h. zu Beginn der Authentifizierung implementiert werden muss).

Beachten Sie, dass Nak eine Legacy-Funktion von EAP mit begrenzter Erweiterbarkeit ist. Neue Authentifizierungsmethoden SOLLTEN Expanded Nak (Abschnitt 5.3.2) verwenden, da Nak nicht verwendet werden kann, um Ablehnung eines Expanded Type (Abschnitt 5.3.2) anzuzeigen. Darüber hinaus sind einige EAP-Methoden so konzipiert, dass sie ausgehandelt werden, anstatt Nak zu verwenden (z. B. innerhalb tunnelierter Methoden). Daher wird die Verwendung von Expanded Nak nach Möglichkeit empfohlen.

Type

Type-Data

Im Legacy-Nak ist das Type-Data-Feld aus einem oder mehreren Oktetten zusammengesetzt, die den Authentifizierungstyp angeben, den der Peer in seiner anfänglichen Response verwenden möchte. Wenn der Peer beispielsweise eine MD5-Challenge-Anfrage (Typ 4) erhält, aber One-Time Password (Typ 5) und Generic Token Card (Typ 6) unterstützt, antwortet er mit einem Nak, dessen Type-Data-Feld die Werte 5 und 6 enthält.

5.3.2. Expanded Nak

Description

Expanded Nak wird zur Aushandlung von EAP-Methodentypen verwendet. Es ähnelt Nak, verwendet aber das Expanded-Type-Format (siehe Abschnitt 5.3.2). Expanded Nak kann Ablehnung sowohl traditioneller als auch erweiterter Typen anzeigen.

Type

254

Type-Data

Für Expanded Nak beginnt das Type-Data-Feld mit Vendor-Id und Vendor-Type (siehe Abschnitt 5.3.2). Da Expanded Nak zur Aushandlung verwendet wird, wird das Vendor-Type-Feld verwendet, um den Authentifizierungsmethodentyp anzugeben (traditionell oder erweitert), den der Peer zu verwenden bereit ist. Das Vendor-Id-Feld wird verwendet, um den Anbieter anzugeben. Wenn beispielsweise ein Expanded Type angefordert wurde, der Peer aber eine andere Methode bevorzugt, SOLLTEN die Felder Vendor-Id und Vendor-Type des Expanded Nak die vom Peer bevorzugte Methode angeben.

5.4. MD5-Challenge

5.4.1. Überblick

Description

Der Typ MD5-Challenge entspricht dem PPP-CHAP-Protokoll [RFC1994] und bietet in EAP eine CHAP-ähnliche Authentifizierung. MD5-Challenge verwendet die MD5-Hash-Funktion [MD5] mit einem gemeinsamen Schlüssel zur Authentifizierung. MD5-Challenge ist die am weitesten verbreitete EAP-Methode und in vielen bestehenden Wireless-Access-Points implementiert. MD5-Challenge bietet gegenseitige Authentifizierung über den gemeinsamen Schlüssel, unterstützt jedoch keine Schlüsselableitung oder Tunneling. MD5-Challenge bietet keinen Identitätsschutz. MD5-Challenge ist anfällig für Wörterbuchangriffe.

Die spezifische Implementierung von MD5-Challenge findet sich in [RFC1994] Abschnitt 5. In EAP werden MD5-Challenge-Pakete ähnlich wie CHAP berechnet, wobei der Hauptunterschied in der Kodierung der Felder Value-Size und Response liegt. In EAP wird Value-Size im Value-Feld transportiert, anstatt als separates Feld.

Type

Type-Data

Für EAP MD5-Challenge enthält das Type-Data-Feld die Felder Value-Size, Value und Name, wie folgt formatiert.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value-Size   |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Value-Size

Ein Byte, das die Länge des Value-Felds in Oktetten angibt.

Value

Dieses Feld enthält den Hashwert oder den Challenge-Wert, dessen Länge durch das Value-Size-Feld angegeben wird.

Name

Dieses Feld enthält den Hostnamen oder Benutzernamen des Absenders. Dieses Feld MUSS UTF-8-kodierte ISO-10646-Zeichen [ISO.10646] enthalten.

5.4.2. Implementierungshinweise

Die MD5-Challenge-Pakete werden wie folgt berechnet:

[1] Der Authenticator sendet ein EAP-Request-Paket an den Peer, wobei das Type-Feld auf 4 (MD5-Challenge) gesetzt ist und das Type-Data-Feld einen Challenge-Wert enthält.

[2] Auf dem Peer wird der MD5-Hashwert berechnet, wobei der gemeinsame Schlüssel, der Identifier des Peers, der Challenge-Wert und das Name-Feld als Eingaben verwendet werden. Der Peer antwortet mit einem EAP-Response-Paket, das den Hashwert enthält.

[3] Der Authenticator verifiziert den Hashwert, und wenn er übereinstimmt, hat der Authenticator den Peer erfolgreich authentifiziert.

5.5. One Time Password (OTP)

Description

Der Typ One Time Password entspricht dem in [RFC2289] definierten Einmalpasswortsystem. Der OTP-Typ ermöglicht die Authentifizierung mit Einmalpasswörtern, wobei jedes Passwort nur einmal verwendet wird. Diese Methode bietet Schutz gegen Replay-Angriffe, da bei jedem Authentifizierungsversuch ein anderes Passwort verwendet wird. OTP bietet keine gegenseitige Authentifizierung oder Schlüsselableitung.

Type

Type-Data

Für den OTP-Typ enthält das Type-Data-Feld einen Datenblock, der aus Text besteht, der dem Benutzer angezeigt und zur Eingabeaufforderung verwendet wird, gefolgt von einem Leerzeichen und dann dem Einmalpasswort. Dieser Text SOLLTE in UTF-8-kodierten ISO-10646-Zeichen [ISO.10646] dargestellt werden. Das spezifische Format des Feldes wird in [RFC2289] beschrieben.

5.6. Generic Token Card (GTC)

Description

Der Typ Generic Token Card wird verwendet, um verschiedene Token-Karten-Implementierungen zu unterstützen. Der GTC-Typ ermöglicht es dem Authenticator, eine Challenge an den Peer zu senden, der dann mit seiner Token-Karte die Antwort berechnet. GTC spezifiziert keine Details der Token-Karten-Implementierung; stattdessen unterstützt es die Übergabe von Challenge/Response von einem externen Authentifizierungsserver an den Peer. GTC bietet keine gegenseitige Authentifizierung oder Schlüsselableitung.

Type

Type-Data

Für den GTC-Typ enthält das Type-Data-Feld einen Datenblock, der aus Text besteht, der dem Benutzer angezeigt und zur Eingabeaufforderung verwendet wird, gefolgt von einem Leerzeichen und dann dem von der Token-Karte generierten Wert. Dieser Text SOLLTE in UTF-8-kodierten ISO-10646-Zeichen [ISO.10646] dargestellt werden.

5.7. Erweiterte Typen (Expanded Types)

Beschreibung

Da viele der bestehenden Verwendungen von EAP herstellerspezifisch sind, ist der erweiterte Methodentyp (Expanded Type) verfügbar, um Herstellern die Unterstützung ihrer eigenen, für den allgemeinen Gebrauch ungeeigneten erweiterten Typen zu ermöglichen.

Der erweiterte Typ wird auch verwendet, um den globalen Methodentyp-Raum über die ursprünglichen 255 Werte hinaus zu erweitern. Eine Vendor-Id von 0 bildet die ursprünglichen 255 möglichen Typen auf einen Raum von 2^32-1 möglichen Typen ab. (Typ 0 wird nur in einer Nak-Antwort verwendet, um anzuzeigen, dass keine akzeptable Alternative vorliegt).

Eine Implementierung, die das erweiterte Attribut unterstützt, MUSS EAP-Typen, die kleiner als 256 sind, gleichwertig behandeln, unabhängig davon, ob sie als einzelnes Oktett oder als 32-Bit-Vendor-Type innerhalb eines erweiterten Typs mit Vendor-Id 0 erscheinen. Peers, die nicht in der Lage sind, den erweiterten Typ zu interpretieren, MÜSSEN ein Nak wie in Abschnitt 5.3.1 beschrieben senden und eine geeignetere Authentifizierungsmethode aushandeln.

Eine Zusammenfassung des Formats des erweiterten Typs 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Vendor-Id (cont)            | Vendor-Type...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor-Type (cont)                 |  Vendor-Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

254 für den erweiterten Typ (Expanded Type)

Vendor-Id

Die Vendor-Id besteht aus 3 Oktets und stellt den SMI Network Management Private Enterprise Code des Herstellers in Network Byte Order dar, wie von der IANA zugewiesen. Eine Vendor-Id von Null ist für die Verwendung durch die IETF reserviert, um einen erweiterten globalen EAP-Typ-Raum bereitzustellen.

Vendor-Type

Das Vendor-Type-Feld umfasst vier Oktets und stellt den herstellerspezifischen Methodentyp dar.

Wenn die Vendor-Id Null ist, ist das Vendor-Type-Feld eine Erweiterung und Obermenge des bestehenden Namensraums für EAP-Typen. Die ersten 256 Typen sind für die Kompatibilität mit einoktettigen EAP-Typen reserviert, die bereits zugewiesen wurden oder künftig zugewiesen werden können. Daher sind die EAP-Typen 0 bis 255 semantisch identisch, unabhängig davon, ob sie als einoktettige EAP-Typen oder als Vendor-Type bei Vendor-Id Null erscheinen. Es gibt eine Ausnahme von dieser Regel: Expanded-Nak- und Legacy-Nak-Pakete teilen sich denselben Typ, müssen jedoch unterschiedlich behandelt werden, da sie ein unterschiedliches Format haben.

Vendor-Data

Das Vendor-Data-Feld wird vom Hersteller definiert. Wenn eine Vendor-Id von Null vorhanden ist, wird das Vendor-Data-Feld zum Transport der Inhalte von EAP-Methoden der von der IETF definierten Typen verwendet.

5.8. Experimentell (Experimental)

Beschreibung

Der experimentelle Typ (Experimental Type) hat kein festes Format oder keinen festen Inhalt. Er ist für die Verwendung bei Experimenten mit neuen EAP-Typen vorgesehen. Dieser Typ dient experimentellen und Testzwecken. Es wird keine Interoperabilität zwischen Peers garantiert, die diesen Typ verwenden, wie in [RFC3692] dargelegt.

Type

255

Type-Data

Nicht definiert (Undefined)