5. Initiale EAP Request/Response Typen

Dieser Abschnitt definiert die initiale Menge von EAP-Typen, die in Request/Response-Austauschen verwendet werden. Weitere Typen können in zukünftigen Dokumenten definiert werden. Das Type-Feld ist ein Oktett und identifiziert die Struktur eines EAP-Request- oder Response-Pakets. Die ersten 3 Typen werden als Sonderfalltypen betrachtet.

Die verbleibenden Typen definieren Authentifizierungsaustausche. Nak (Typ 3) oder Expanded Nak (Typ 254) sind nur für Response-Pakete gültig, sie DÜRFEN NICHT in einer Anforderung gesendet werden.

Alle EAP-Implementierungen MÜSSEN die Typen 1-4 unterstützen, die in diesem Dokument definiert sind, und SOLLTEN Typ 254 unterstützen. Implementierungen KÖNNEN andere hier oder in zukünftigen RFCs definierte Typen unterstützen.

1 Identity 2 Notification 3 Nak (nur Response) 4 MD5-Challenge 5 One Time Password (OTP) 6 Generic Token Card (GTC) 254 Expanded Types 255 Experimentelle Verwendung

EAP-Methoden KÖNNEN Authentifizierung basierend auf gemeinsamen Geheimnissen unterstützen. Wenn das gemeinsame Geheimnis eine vom Benutzer eingegebene Passphrase ist, KÖNNEN Implementierungen die Eingabe von Passphrases mit Nicht-ASCII-Zeichen unterstützen. In diesem Fall sollte die Eingabe mit einem geeigneten stringprep [RFC3454] Profil verarbeitet und mit UTF-8-Kodierung [RFC2279] in Oktette kodiert werden. Eine vorläufige Version eines möglichen stringprep-Profils wird in [SASLPREP] beschrieben.

5.1. Identity

Beschreibung

Der Identity-Typ wird verwendet, um die Identität des Peers abzufragen. Im Allgemeinen gibt der Authentifikator dies als anfängliche Anforderung aus. Eine optionale anzeigbare Nachricht KANN enthalten sein, um den Peer aufzufordern, wenn eine Interaktion mit einem Benutzer erwartet wird. Eine Response vom Typ 1 (Identity) SOLLTE als Antwort auf eine Request mit Typ 1 (Identity) gesendet werden.

Einige EAP-Implementierungen fügen verschiedene Optionen nach einem NUL-Zeichen in die Identity Request ein. Standardmäßig SOLLTE eine EAP-Implementierung NICHT davon ausgehen, dass eine Identity Request oder Response größer als 1020 Oktette sein kann.

Es wird EMPFOHLEN, dass die Identity Response hauptsächlich für Routing-Zwecke und zur Auswahl der zu verwendenden EAP-Methode verwendet wird. EAP-Methoden SOLLTEN einen methodenspezifischen Mechanismus zum Abrufen der Identität enthalten, damit sie sich nicht auf die Identity Response verlassen müssen. Identity Requests und Responses werden im Klartext gesendet, sodass ein Angreifer die Identität ausspähen oder sogar Identitätsaustausche ändern oder fälschen kann. Um diese Bedrohungen anzugehen, ist es vorzuziehen, dass eine EAP-Methode einen Identitätsaustausch enthält, der Authentifizierung, Integrität und Replay-Schutz pro Paket sowie Vertraulichkeit unterstützt. Die Identity Response ist möglicherweise nicht die geeignete Identität für die Methode; sie wurde möglicherweise gekürzt oder verschleiert, um Privatsphäre zu bieten, oder sie wurde für Routing-Zwecke dekoriert. Wenn der Peer so konfiguriert ist, dass er nur Authentifizierungsmethoden akzeptiert, die geschützte Identitätsaustausche unterstützen, KANN der Peer eine abgekürzte Identity Response bereitstellen (z. B. durch Weglassen des Peer-Namensabschnitts des NAI [RFC2486]). Für weitere Diskussionen zum Identitätsschutz siehe Abschnitt 7.3.

Implementierungshinweis: Der Peer KANN die Identität über Benutzereingabe erhalten. Es wird vorgeschlagen, dass der Authentifikator die Identity Request bei ungültiger Identität oder Authentifizierungsfehler wiederholt, um potenzielle Tippfehler seitens des Benutzers zu ermöglichen. Es wird vorgeschlagen, die Identity Request mindestens dreimal zu wiederholen, bevor die Authentifizierung beendet wird. Die Notification Request KANN verwendet werden, um vor der Übertragung einer neuen Identity Request einen ungültigen Authentifizierungsversuch anzuzeigen (optional KANN der Fehler innerhalb der Nachricht der neuen Identity Request selbst angezeigt werden).

Type

Type-Data

Dieses Feld KANN in der Request eine anzeigbare Nachricht enthalten, die UTF-8-kodierte ISO 10646-Zeichen [RFC2279] enthält. Wenn die Request ein Null enthält, wird nur der Teil des Feldes vor dem Null angezeigt. Wenn die Identität unbekannt ist, sollte das Identity Response-Feld null Bytes lang sein. Das Identity Response-Feld DARF NICHT null-terminiert sein. In allen Fällen wird die Länge des Type-Data-Feldes vom Length-Feld des Request/Response-Pakets abgeleitet.

Sicherheitsansprüche (siehe Abschnitt 7.2):

Auth.-Mechanismus: Keine Ciphersuite-Verhandlung: Nein Gegenseitige Authentifizierung: Nein Integritätsschutz: Nein Replay-Schutz: Nein Vertraulichkeit: Nein Schlüsselableitung: Nein Schlüsselstärke: N/V Wörterbuch-Angriffsschutz: N/V Schnelle Wiederverbindung: Nein Krypt. Bindung: N/V Sitzungsunabhängigkeit: N/V Fragmentierung: Nein Kanalbindung: Nein

5.2. Notification

Beschreibung

Der Notification-Typ wird optional verwendet, um eine anzeigbare Nachricht vom Authentifikator an den Peer zu übermitteln. Ein Authentifikator KANN jederzeit eine Notification Request an den Peer senden, wenn keine ausstehende Request vorliegt, vor Abschluss einer EAP-Authentifizierungsmethode. Der Peer MUSS auf eine Notification Request mit einer Notification Response antworten, es sei denn, die EAP-Authentifizierungsmethodenspezifikation verbietet die Verwendung von Notification-Nachrichten. In jedem Fall DARF KEINE Nak Response als Antwort auf eine Notification Request gesendet werden. Beachten Sie, dass die Standardmaxilänge einer Notification Request 1020 Oktette beträgt. Standardmäßig bleiben damit höchstens 1015 Oktette für die menschlich lesbare Nachricht.

Eine EAP-Methode KANN in ihrer Spezifikation angeben, dass Notification-Nachrichten während dieser Methode nicht gesendet werden dürfen. In diesem Fall MUSS der Peer Notification Requests ab dem Punkt stillschweigend verwerfen, an dem eine anfängliche Request für diesen Typ mit einer Response desselben Typs beantwortet wird.

Der Peer SOLLTE diese Nachricht dem Benutzer anzeigen oder sie protokollieren, wenn sie nicht angezeigt werden kann. Der Notification-Typ soll eine bestätigte Benachrichtigung imperativer Natur bereitstellen, ist jedoch keine Fehleranzeige und ändert daher nicht den Zustand des Peers. Beispiele sind ein Passwort mit bald ablaufender Ablaufzeit, eine OTP-Sequenzzahl, die sich 0 nähert, eine Warnung vor Authentifizierungsfehlern usw. In den meisten Fällen sollte Notification nicht erforderlich sein.

Type

Type-Data

Das Type-Data-Feld in der Request enthält eine anzeigbare Nachricht mit mehr als null Oktetten Länge, die UTF-8-kodierte ISO 10646-Zeichen [RFC2279] enthält. Die Länge der Nachricht wird durch das Length-Feld des Request-Pakets bestimmt. Die Nachricht DARF NICHT null-terminiert sein. Eine Response MUSS als Antwort auf die Request mit einem Type-Feld von 2 (Notification) gesendet werden. Das Type-Data-Feld der Response ist null Oktette lang. Die Response sollte sofort gesendet werden (unabhängig davon, wie die Nachricht angezeigt oder protokolliert wird).

Sicherheitsansprüche (siehe Abschnitt 7.2):

5.3. Nak

5.3.1. Legacy Nak

Beschreibung

Der Legacy Nak-Typ ist nur in Response-Nachrichten gültig. Er wird als Antwort auf eine Request gesendet, bei der der gewünschte Authentifizierungstyp inakzeptabel ist. Authentifizierungstypen sind ab 4 nummeriert. Die Response enthält einen oder mehrere vom Peer gewünschte Authentifizierungstypen. Typ Null (0) wird verwendet, um anzuzeigen, dass der Absender keine praktikablen Alternativen hat, und daher SOLLTE der Authentifikator nach Erhalt einer Nak Response mit einem Nullwert keine weitere Request senden.

Da der Legacy Nak-Typ nur in Responses gültig ist und eine sehr begrenzte Funktionalität hat, DARF er NICHT als allgemeine Fehleranzeige verwendet werden, z. B. für die Kommunikation von Fehlermeldungen oder die Verhandlung von Parametern, die für eine bestimmte EAP-Methode spezifisch sind.

Code

2 für Response.

Identifier

Das Identifier-Feld ist ein Oktett und hilft beim Abgleichen von Responses mit Requests. Das Identifier-Feld einer Legacy Nak Response MUSS mit dem Identifier-Feld des Request-Pakets übereinstimmen, auf das es als Antwort gesendet wird.

Length

=6

Type

Type-Data

Wenn ein Peer eine Request für einen inakzeptablen Authentifizierungstyp (4-253, 255) erhält oder ein Peer ohne Unterstützung für Expanded Types eine Request für Typ 254 erhält, MUSS eine Nak Response (Typ 3) gesendet werden. Das Type-Data-Feld der Nak Response (Typ 3) MUSS ein oder mehrere Oktette enthalten, die den/die gewünschten Authentifizierungstyp(en) angeben, ein Oktett pro Typ, oder den Wert Null (0), um keine vorgeschlagene Alternative anzuzeigen. Ein Peer, der Expanded Types unterstützt und eine Request für einen inakzeptablen Authentifizierungstyp (4-253, 255) erhält, KANN den Wert 254 in die Nak Response (Typ 3) aufnehmen, um den Wunsch nach einem Expanded-Authentifizierungstyp anzuzeigen. Wenn der Authentifikator dieser Präferenz entsprechen kann, wird er mit einer Expanded Type Request (Typ 254) antworten.

Sicherheitsansprüche (siehe Abschnitt 7.2):

5.3.2. Expanded Nak

Beschreibung

Der Expanded Nak-Typ ist nur in Response-Nachrichten gültig. Er MUSS nur als Antwort auf eine Request vom Typ 254 (Expanded Type) gesendet werden, bei der der Authentifizierungstyp inakzeptabel ist. Der Expanded Nak-Typ verwendet selbst das Expanded Type-Format, und die Response enthält einen oder mehrere vom Peer gewünschte Authentifizierungstypen, alle im Expanded Type-Format. Typ Null (0) wird verwendet, um anzuzeigen, dass der Absender keine praktikablen Alternativen hat. Das allgemeine Format des Expanded Type wird in Abschnitt 5.7 beschrieben.

Da der Expanded Nak-Typ nur in Responses gültig ist und eine sehr begrenzte Funktionalität hat, DARF er NICHT als allgemeine Fehleranzeige verwendet werden, z. B. für die Kommunikation von Fehlermeldungen oder die Verhandlung von Parametern, die für eine bestimmte EAP-Methode spezifisch sind.

Code

2 für Response.

Identifier

Das Identifier-Feld ist ein Oktett und hilft beim Abgleichen von Responses mit Requests. Das Identifier-Feld einer Expanded Nak Response MUSS mit dem Identifier-Feld des Request-Pakets übereinstimmen, auf das es als Antwort gesendet wird.

Length

=20

Type

254

Vendor-Id

0 (IETF)

Vendor-Type

3 (Nak)

Vendor-Data

Der Expanded Nak-Typ wird nur gesendet, wenn die Request einen Expanded Type (254) enthält, wie in Abschnitt 5.7 definiert. Das Vendor-Data-Feld der Nak Response MUSS einen oder mehrere Authentifizierungstypen (4 oder größer) enthalten, alle im erweiterten Format, 8 Oktette pro Typ, oder den Wert Null (0), ebenfalls im Expanded Type-Format, um keine vorgeschlagene Alternative anzuzeigen. Die gewünschten Authentifizierungstypen können eine Mischung aus herstellerspezifischen und IETF-Typen enthalten.

Sicherheitsansprüche (siehe Abschnitt 7.2):

5.4. MD5-Challenge

Beschreibung

Der MD5-Challenge-Typ ist analog zum PPP CHAP-Protokoll [RFC1994] (mit MD5 als angegebenem Algorithmus). Die Request enthält eine "Challenge"-Nachricht an den Peer. Eine Response MUSS als Antwort auf die Request gesendet werden. Die Response KANN entweder vom Typ 4 (MD5-Challenge), Nak (Typ 3) oder Expanded Nak (Typ 254) sein. Die Nak-Antwort zeigt die gewünschten Authentifizierungstypen des Peers an. EAP-Peer- und EAP-Server-Implementierungen MÜSSEN den MD5-Challenge-Mechanismus unterstützen.

Type

Type-Data

Der Inhalt des Type-Data-Feldes ist unten zusammengefasst. Für Referenzen zur Verwendung dieser Felder siehe das PPP Challenge Handshake Authentication Protocol [RFC1994].

Sicherheitsansprüche (siehe Abschnitt 7.2):

Auth.-Mechanismus: Passwort oder vorgeteilter Schlüssel Ciphersuite-Verhandlung: Nein Gegenseitige Authentifizierung: Nein Integritätsschutz: Nein Replay-Schutz: Nein Vertraulichkeit: Nein Schlüsselableitung: Nein Schlüsselstärke: N/V Wörterbuch-Angriffsschutz: Nein Schnelle Wiederverbindung: Nein Krypt. Bindung: N/V Sitzungsunabhängigkeit: N/V Fragmentierung: Nein Kanalbindung: Nein

5.5. One-Time Password (OTP)

Beschreibung

Das One-Time Password-System ist in "A One-Time Password System" [RFC2289] und "OTP Extended Responses" [RFC2243] definiert. Die Request enthält eine OTP-Challenge im in [RFC2289] beschriebenen Format. Eine Response MUSS als Antwort auf die Request gesendet werden. Die Response MUSS vom Typ 5 (OTP), Nak (Typ 3) oder Expanded Nak (Typ 254) sein.

Type

Type-Data

Das Type-Data-Feld enthält die OTP-"Challenge" als anzeigbare Nachricht in der Request. In der Response wird dieses Feld für die 6 Wörter aus dem OTP-Wörterbuch [RFC2289] verwendet.

Sicherheitsansprüche (siehe Abschnitt 7.2):

Auth.-Mechanismus: Einmalpasswort Ciphersuite-Verhandlung: Nein Gegenseitige Authentifizierung: Nein Integritätsschutz: Nein Replay-Schutz: Ja Vertraulichkeit: Nein Schlüsselableitung: Nein Schlüsselstärke: N/V Wörterbuch-Angriffsschutz: Nein Schnelle Wiederverbindung: Nein Krypt. Bindung: N/V Sitzungsunabhängigkeit: N/V Fragmentierung: Nein Kanalbindung: Nein

5.6. Generic Token Card (GTC)

Beschreibung

Der Generic Token Card-Typ ist für die Verwendung mit verschiedenen Token Card-Implementierungen definiert, die Benutzereingaben erfordern. Die Request enthält eine anzeigbare Nachricht und die Response enthält die für die Authentifizierung erforderlichen Token Card-Informationen.

Type

Type-Data

Das Type-Data-Feld in der Request enthält eine anzeigbare Nachricht mit mehr als null Oktetten Länge.

Sicherheitsansprüche (siehe Abschnitt 7.2):

Auth.-Mechanismus: Hardware-Token Ciphersuite-Verhandlung: Nein Gegenseitige Authentifizierung: Nein Integritätsschutz: Nein Replay-Schutz: Nein Vertraulichkeit: Nein Schlüsselableitung: Nein Schlüsselstärke: N/V Wörterbuch-Angriffsschutz: Nein Schnelle Wiederverbindung: Nein Krypt. Bindung: N/V Sitzungsunabhängigkeit: N/V Fragmentierung: Nein Kanalbindung: Nein

5.7. Expanded Types

Beschreibung

Da viele der bestehenden Verwendungen von EAP herstellerspezifisch sind, steht der Expanded-Methodentyp zur Verfügung, damit Hersteller ihre eigenen Expanded Types unterstützen können, die nicht für den allgemeinen Gebrauch geeignet sind.

Type

254 für Expanded Type

Vendor-Id

Die Vendor-Id besteht aus 3 Oktetten und repräsentiert den SMI Network Management Private Enterprise Code des Herstellers in Netzwerk-Byte-Reihenfolge, wie von IANA zugewiesen.

Vendor-Type

Das Vendor-Type-Feld besteht aus vier Oktetten und repräsentiert den herstellerspezifischen Methodentyp.

Vendor-Data

Das Vendor-Data-Feld wird vom Hersteller definiert.

5.8. Experimental

Beschreibung

Der Experimental-Typ hat kein festes Format oder Inhalt. Er ist für die Verwendung beim Experimentieren mit neuen EAP-Typen vorgesehen.

Type

255

Type-Data

Undefiniert