7. Sicherheitsüberlegungen

7. Sicherheitsüberlegungen

Dieser Abschnitt definiert ein generisches Bedrohungsmodell sowie die EAP-Methoden-Sicherheitsansprüche, die diese Bedrohungen mindern.

Es wird erwartet, dass das generische Bedrohungsmodell und die entsprechenden Sicherheitsansprüche verwendet werden, um EAP-Methodenanforderungen für die Verwendung in bestimmten Umgebungen zu definieren. Ein Beispiel für eine solche Anforderungsanalyse ist in [IEEE-802.11i-req] enthalten. In EAP-Methodenspezifikationen ist ein Abschnitt über Sicherheitsansprüche erforderlich, damit EAP-Methoden anhand von Anforderungen bewertet werden können.

7.1. Bedrohungsmodell (Threat Model)

EAP wurde ursprünglich für die Verwendung mit PPP [RFC1661] entwickelt und später in [IEEE-802.1X] für die Verwendung in kabelgebundenen IEEE 802-Netzwerken [IEEE-802] angepasst. Anschließend wurde EAP für die Verwendung in drahtlosen LAN-Netzwerken und im Internet vorgeschlagen. In all diesen Situationen ist es für einen Angreifer möglich, Zugriff auf die Verbindungen zu erhalten, über die EAP-Pakete übertragen werden. Beispielsweise sind Angriffe auf die Telefoninfrastruktur in [DECEPTION] dokumentiert.

Ein Angreifer mit Zugriff auf die Verbindung kann eine Reihe von Angriffen durchführen, einschließlich:

[1] Entdeckung von Benutzeridentitäten durch Abhören des Authentifizierungsverkehrs. [2] Modifizieren oder Fälschen von EAP-Paketen. [3] Denial-of-Service-Angriffe. [4] Offline-Wörterbuchangriffe. [5] Man-in-the-Middle-Angriffe. [6] Störung der EAP-Verhandlung. [7] Schlüsselwiederherstellung durch schwache Schlüsselableitungstechniken. [8] Ausnutzung schwacher Ciphersuites. [9] Downgrading-Angriffe auf Ciphersuite-Verhandlungen der unteren Schicht. [10] Ein Angreifer, der als Authentifikator fungiert, kann über Out-of-Band-Mechanismen (wie über ein AAA- oder Verbindungsschichtprotokoll) falsche Informationen an den EAP-Peer und/oder Server liefern. Dies umfasst das Vortäuschen eines anderen Authentifikators oder die Bereitstellung inkonsistenter Informationen an Peer und EAP-Server.

Je nach Verbindungsschicht können diese Angriffe durchgeführt werden, ohne dass physische Nähe erforderlich ist. Wenn EAP über drahtlose Netzwerke verwendet wird, können EAP-Pakete von Authentifikatoren weitergeleitet werden (z. B. Prä-Authentifizierung), sodass der Angreifer sich nicht im Abdeckungsbereich eines Authentifikators befinden muss, um einen Angriff gegen ihn oder seine Peers durchzuführen. Wenn EAP über das Internet verwendet wird, können Angriffe aus noch größerer Entfernung durchgeführt werden.

7.2. Sicherheitsansprüche (Security Claims)

Um die von einer EAP-Methode bereitgestellte Sicherheit klar zu artikulieren, MÜSSEN EAP-Methodenspezifikationen einen Abschnitt über Sicherheitsansprüche enthalten, der folgende Aussagen umfasst:

[a] Mechanismus. Dies ist eine Aussage über die Authentifizierungstechnologie: Zertifikate, vorab geteilte Schlüssel, Passwörter, Token-Karten usw.

[b] Sicherheitsansprüche. Dies ist eine Aussage über die von der Methode beanspruchten Sicherheitseigenschaften unter Verwendung der in Abschnitt 7.2.1 definierten Begriffe: gegenseitige Authentifizierung, Integritätsschutz, Replay-Schutz, Vertraulichkeit, Schlüsselableitung, Wörterbuch-Angriffsresistenz, schnelle Wiederverbindung, kryptografische Bindung. Der Abschnitt Sicherheitsansprüche einer EAP-Methodenspezifikation SOLLTE eine Begründung für die gemachten Ansprüche liefern. Dies kann durch Einbeziehung eines Beweises in einem Anhang oder durch Einbeziehung eines Verweises auf einen Beweis erreicht werden.

[c] Schlüsselstärke. Wenn die Methode Schlüssel ableitet, MUSS die effektive Schlüsselstärke geschätzt werden. Diese Schätzung ist für potenzielle Nutzer der Methode gedacht, um festzustellen, ob die erzeugten Schlüssel für die beabsichtigte Anwendung stark genug sind.

Die effektive Schlüsselstärke SOLLTE als Anzahl von Bits angegeben werden, definiert wie folgt: Wenn die effektive Schlüsselstärke N Bits beträgt, erfordern die derzeit bekannten besten Methoden zur Wiederherstellung des Schlüssels (mit nicht zu vernachlässigender Wahrscheinlichkeit) im Durchschnitt einen Aufwand, der 2^(N-1) Operationen einer typischen Blockchiffre entspricht. Die Aussage SOLLTE von einer kurzen Begründung begleitet werden, die erklärt, wie diese Zahl abgeleitet wurde. Diese Erklärung SOLLTE die erforderlichen Parameter enthalten, um die angegebene Schlüsselstärke basierend auf dem aktuellen Wissen über Algorithmen zu erreichen.

(Hinweis: Obwohl es schwierig ist, genau zu definieren, was "vergleichbarer Aufwand" und "typische Blockchiffre" bedeuten, sind vernünftige Näherungen hier ausreichend. Siehe beispielsweise [SILVERMAN] für weitere Diskussionen.)

Die Schlüsselstärke hängt von den zur Ableitung der Schlüssel verwendeten Methoden ab. Wenn Schlüssel beispielsweise aus einem gemeinsamen Geheimnis (wie einem Passwort oder langfristigen Geheimnis) und möglicherweise öffentlichen Informationen wie Nonces abgeleitet werden, ist die effektive Schlüsselstärke durch die Stärke des langfristigen Geheimnisses begrenzt (unter der Annahme, dass das Ableitungsverfahren rechnerisch einfach ist). Als weiteres Beispiel hängt bei der Verwendung von Public-Key-Algorithmen die Stärke des symmetrischen Schlüssels von der Stärke der verwendeten öffentlichen Schlüssel ab.

[d] Beschreibung der Schlüsselhierarchie. EAP-Methoden, die Schlüssel ableiten, MÜSSEN entweder einen Verweis auf eine Spezifikation der Schlüsselhierarchie bereitstellen oder beschreiben, wie die Master Session Keys (MSK) und Extended Master Session Keys (EMSK) abgeleitet werden sollen.

[e] Hinweis auf Schwachstellen. Zusätzlich zu den gemachten Sicherheitsansprüchen MUSS die Spezifikation angeben, welche der in Abschnitt 7.2.1 detaillierten Sicherheitsansprüche NICHT gemacht werden.

7.2.1. Terminologie der Sicherheitsansprüche für EAP-Methoden

Diese Begriffe beschreiben die Sicherheitseigenschaften von EAP-Methoden:

Geschützte Ciphersuite-Verhandlung (Protected ciphersuite negotiation)

Dies bezieht sich auf die Fähigkeit einer EAP-Methode, die zur Sicherung der EAP-Konversation verwendete Ciphersuite zu verhandeln sowie die Verhandlung integritätsgeschützt durchzuführen. Dies bezieht sich nicht auf die Fähigkeit, die zur Sicherung der Daten verwendete Ciphersuite zu verhandeln.

Gegenseitige Authentifizierung (Mutual authentication)

Dies bezieht sich auf eine EAP-Methode, bei der in einem verriegelten Austausch der Authentifikator den Peer authentifiziert und der Peer den Authentifikator authentifiziert. Zwei unabhängige unidirektionale Methoden, die in entgegengesetzte Richtungen laufen, bieten keine gegenseitige Authentifizierung wie hier definiert.

Integritätsschutz (Integrity protection)

Dies bezieht sich auf die Bereitstellung von Datenursprungsauthentifizierung und Schutz vor unbefugter Änderung von Informationen für EAP-Pakete (einschließlich EAP-Requests und -Responses). Bei diesem Anspruch MUSS eine Methodenspezifikation die EAP-Pakete und Felder im EAP-Paket beschreiben, die geschützt sind.

Replay-Schutz (Replay protection)

Dies bezieht sich auf den Schutz vor Wiederholung einer EAP-Methode oder ihrer Nachrichten, einschließlich Erfolgs- und Fehleranzeigen.

Vertraulichkeit (Confidentiality)

Dies bezieht sich auf die Verschlüsselung von EAP-Nachrichten, einschließlich EAP-Requests und -Responses sowie Erfolgs- und Fehleranzeigen. Eine Methode, die diesen Anspruch erhebt, MUSS Identitätsschutz unterstützen (siehe Abschnitt 7.3).

Schlüsselableitung (Key derivation)

Dies bezieht sich auf die Fähigkeit der EAP-Methode, exportierbares Schlüsselmaterial wie den Master Session Key (MSK) und den Extended Master Session Key (EMSK) abzuleiten. Der MSK wird nur für eine weitere Schlüsselableitung verwendet, nicht direkt für den Schutz der EAP-Konversation oder nachfolgender Daten. Die Verwendung des EMSK ist reserviert.

Schlüsselstärke (Key strength)

Wenn die effektive Schlüsselstärke N Bits beträgt, erfordern die derzeit bekannten besten Methoden zur Wiederherstellung des Schlüssels (mit nicht zu vernachlässigender Wahrscheinlichkeit) im Durchschnitt einen Aufwand, der 2^(N-1) Operationen einer typischen Blockchiffre entspricht.

Wörterbuch-Angriffsresistenz (Dictionary attack resistance)

Wenn Passwort-Authentifizierung verwendet wird, werden Passwörter üblicherweise aus einer kleinen Menge ausgewählt (im Vergleich zu einem Satz von N-Bit-Schlüsseln), was Bedenken hinsichtlich Wörterbuchangriffen aufwirft. Eine Methode kann als Schutz vor Wörterbuchangriffen bietend bezeichnet werden, wenn sie bei Verwendung eines Passworts als Geheimnis keinen Offline-Angriff zulässt, der einen Arbeitsfaktor basierend auf der Anzahl der Passwörter im Wörterbuch eines Angreifers hat.

Schnelle Wiederverbindung (Fast reconnect)

Die Fähigkeit, in dem Fall, dass zuvor eine Sicherheitsassoziation hergestellt wurde, eine neue oder aufgefrischte Sicherheitsassoziation effizienter oder in einer reduzierten Anzahl von Roundtrips zu erstellen.

Kryptografische Bindung (Cryptographic binding)

Der Nachweis des EAP-Peers gegenüber dem EAP-Server, dass eine einzelne Entität als EAP-Peer für alle Methoden fungiert hat, die innerhalb einer Tunnelmethode ausgeführt wurden. Die Bindung KANN auch beinhalten, dass der EAP-Server dem Peer nachweist, dass eine einzelne Entität als EAP-Server für alle Methoden fungiert hat, die innerhalb einer Tunnelmethode ausgeführt wurden. Bei korrekter Ausführung dient die Bindung zur Minderung von Man-in-the-Middle-Schwachstellen.

Sitzungsunabhängigkeit (Session independence)

Der Nachweis, dass passive Angriffe (wie das Erfassen der EAP-Konversation) oder aktive Angriffe (einschließlich der Kompromittierung des MSK oder EMSK) nicht die Kompromittierung nachfolgender oder früherer MSKs oder EMSKs ermöglichen.

Fragmentierung (Fragmentation)

Dies bezieht sich darauf, ob eine EAP-Methode Fragmentierung und Reassemblierung unterstützt. Wie in Abschnitt 3.1 angegeben, SOLLTEN EAP-Methoden Fragmentierung und Reassemblierung unterstützen, wenn EAP-Pakete das Minimum-MTU von 1020 Oktetten überschreiten können.

Kanalbindung (Channel binding)

Die Kommunikation von integritätsgeschützten Kanaleigenschaften wie Endpunktidentifikatoren innerhalb einer EAP-Methode, die mit Werten verglichen werden können, die über Out-of-Band-Mechanismen kommuniziert werden (wie über ein AAA- oder Verbindungsschichtprotokoll).

Hinweis: Diese Liste von Sicherheitsansprüchen ist nicht erschöpfend. Zusätzliche Eigenschaften wie zusätzlicher Schutz vor Denial-of-Service können ebenfalls relevant sein.

7.3. Identitätsschutz (Identity Protection)

Ein Identitätsaustausch ist innerhalb der EAP-Konversation optional. Daher ist es möglich, den Identitätsaustausch vollständig auszulassen oder einen methodenspezifischen Identitätsaustausch zu verwenden, sobald ein geschützter Kanal hergestellt wurde.

Wenn jedoch Roaming unterstützt wird, wie in [RFC2607] beschrieben, kann es erforderlich sein, den entsprechenden Backend-Authentifizierungsserver zu lokalisieren, bevor die Authentifizierungskonversation fortgesetzt werden kann. Der Domänenteil des Network Access Identifier (NAI) [RFC2486] ist typischerweise in der EAP-Response/Identity enthalten, um den Authentifizierungsaustausch an den entsprechenden Backend-Authentifizierungsserver weiterleiten zu können. Daher kann der Domänenteil erforderlich sein, obwohl der Peer-Namensteil des NAI in der EAP-Response/Identity weggelassen werden kann, wenn Proxies oder Relays vorhanden sind.

Es ist möglich, dass die Identität in der Identity-Response von der durch die EAP-Methode authentifizierten Identität abweicht. Dies kann im Fall von Identitätsprivatsphäre beabsichtigt sein. Eine EAP-Methode SOLLTE die authentifizierte Identität bei Zugriffssteuerungsentscheidungen verwenden.

7.4. Man-in-the-Middle-Angriffe

Wenn EAP innerhalb eines anderen Protokolls getunnelt wird, das die Peer-Authentifizierung auslässt, besteht eine potenzielle Schwachstelle für Man-in-the-Middle-Angriffe. Weitere Details finden Sie in [BINDING] und [MITM].

Wie in Abschnitt 2.1 angegeben, erlaubt EAP keine nicht getunnelten Sequenzen von Authentifizierungsmethoden. Wenn eine Sequenz von EAP-Authentifizierungsmethoden erlaubt wäre, hätte der Peer möglicherweise keinen Beweis dafür, dass eine einzelne Entität als Authentifikator für alle EAP-Methoden in der Sequenz fungiert hat. Beispielsweise könnte ein Authentifikator eine EAP-Methode beenden und dann die nächste Methode in der Sequenz ohne Wissen oder Zustimmung des Peers an eine andere Partei weiterleiten. In ähnlicher Weise hätte der Authentifikator möglicherweise keinen Beweis dafür, dass eine einzelne Entität als Peer für alle EAP-Methoden in der Sequenz fungiert hat.

Das Tunneln von EAP innerhalb eines anderen Protokolls ermöglicht einen Angriff durch einen böswilligen EAP-Authentifikator, der EAP zu einem legitimen Server tunnelt. Wenn das Tunnelprotokoll für die Schlüsseleinrichtung verwendet wird, aber keine Peer-Authentifizierung erfordert, kann ein Angreifer, der einen legitimen Peer überzeugt, sich mit ihm zu verbinden, EAP-Pakete zu einem legitimen Server tunneln, sich erfolgreich authentifizieren und den Schlüssel erhalten. Dies ermöglicht es dem Angreifer, sich erfolgreich als Man-in-the-Middle zu etablieren, Zugang zum Netzwerk zu erhalten sowie die Fähigkeit, den Datenverkehr zwischen dem legitimen Peer und dem Server zu entschlüsseln.

Dieser Angriff kann durch folgende Maßnahmen gemildert werden:

[a] Erfordernis der gegenseitigen Authentifizierung innerhalb von EAP-Tunnelmechanismen.

[b] Erfordernis der kryptografischen Bindung zwischen dem EAP-Tunnelprotokoll und den getunnelten EAP-Methoden. Wenn die kryptografische Bindung unterstützt wird, ist auch ein Mechanismus erforderlich, um Downgrade-Angriffe zu verhindern, die sie umgehen würden. Weitere Details zur kryptografischen Bindung finden Sie in [BINDING].

[c] Beschränkung der EAP-Methoden, die ohne Schutz verwendet werden dürfen, basierend auf Peer- und Authentifikatorrichtlinien.

[d] Vermeidung der Verwendung von Tunneln, wenn eine einzelne starke Methode verfügbar ist.

7.5. Paketmodifikationsangriffe

Obwohl EAP-Methoden paketweise Datenursprungsauthentifizierung, Integrität und Replay-Schutz unterstützen können, wird keine Unterstützung innerhalb der EAP-Schicht bereitgestellt.

Da der Identifier nur ein einzelnes Oktett ist, ist er leicht zu erraten, was es einem Angreifer ermöglicht, EAP-Pakete erfolgreich zu injizieren oder wiederzugeben. Ein Angreifer kann auch die EAP-Header (Code, Identifier, Length, Type) in EAP-Paketen modifizieren, bei denen der Header nicht geschützt ist. Dies könnte dazu führen, dass Pakete unangemessen verworfen oder falsch interpretiert werden.

Um EAP-Pakete vor Modifikation, Spoofing oder Replay zu schützen, werden Methoden empfohlen, die geschützte Ciphersuite-Verhandlung, gegenseitige Authentifizierung und Schlüsselableitung sowie Integrität und Replay-Schutz unterstützen. Siehe Abschnitt 7.2.1 für die Definitionen dieser Sicherheitsansprüche.

Methodenspezifische MICs können verwendet werden, um Schutz zu bieten. Wenn ein paketweiser MIC in einer EAP-Methode verwendet wird, MÜSSEN die Peers, Authentifizierungsserver und Authentifikatoren, die nicht im Pass-Through-Modus arbeiten, den MIC validieren. MIC-Validierungsfehler SOLLTEN protokolliert werden. Ob ein MIC-Validierungsfehler als fataler Fehler angesehen wird, wird durch die EAP-Methodenspezifikation bestimmt.

Es wird EMPFOHLEN, dass Methoden, die EAP-Paket-Integritätsschutz bieten, die Abdeckung aller EAP-Header-Felder einschließen, darunter die Felder Code, Identifier, Length, Type und Type-Data.

Da EAP-Nachrichten der Typen Identity, Notification und Nak keinen eigenen MIC enthalten, kann es wünschenswert sein, dass der EAP-Methoden-MIC die in diesen Nachrichten enthaltenen Informationen sowie den Header jeder EAP-Nachricht abdeckt.

Um Schutz zu bieten, kann EAP auch in einem geschützten Kanal gekapselt werden, der von Protokollen wie ISAKMP [RFC2408] erstellt wurde, wie in [IKEv2] oder in TLS [RFC2246] getan. Wie jedoch in Abschnitt 7.4 angegeben, kann EAP-Tunneling zu einer Man-in-the-Middle-Schwachstelle führen.

Bestehende EAP-Methoden definieren Message Integrity Checks (MIC), die mehr als ein EAP-Paket abdecken. Zum Beispiel definiert EAP-TLS [RFC2716] einen MIC auf einem TLS-Record, der in mehrere Fragmente aufgeteilt werden könnte; in der FINISHED-Nachricht wird der MIC über die vorherigen Nachrichten berechnet. Wenn der MIC mehr als ein EAP-Paket abdeckt, wird ein MIC-Validierungsfehler typischerweise als fataler Fehler betrachtet.

7.6. Wörterbuchangriffe (Dictionary Attacks)

Passwort-Authentifizierungsalgorithmen wie EAP-MD5, MS-CHAPv1 [RFC2433] und Kerberos V [RFC1510] sind bekanntermaßen anfällig für Wörterbuchangriffe. MS-CHAPv1-Schwachstellen sind in [PPTPv1] dokumentiert; MS-CHAPv2-Schwachstellen sind in [PPTPv2] dokumentiert; Kerberos-Schwachstellen werden in [KRBATTACK], [KRBLIM] und [KERB4WEAK] beschrieben.

Um sich vor Wörterbuchangriffen zu schützen, werden Authentifizierungsmethoden empfohlen, die resistent gegen Wörterbuchangriffe sind (wie in Abschnitt 7.2.1 definiert).

Wenn ein Authentifizierungsalgorithmus verwendet wird, der bekanntermaßen anfällig für Wörterbuchangriffe ist, kann die Konversation in einem geschützten Kanal getunnelt werden, um zusätzlichen Schutz zu bieten. Wie jedoch in Abschnitt 7.4 angegeben, kann EAP-Tunneling zu einer Man-in-the-Middle-Schwachstelle führen, und daher sind Methoden, die resistent gegen Wörterbuchangriffe sind, vorzuziehen.

7.7. Verbindung zu einem nicht vertrauenswürdigen Netzwerk (Connection to an Untrusted Network)

Bei EAP-Methoden, die unidirektionale Authentifizierung unterstützen, wie EAP-MD5, authentifiziert der Peer den Authentifikator nicht, wodurch der Peer anfällig für Angriffe durch einen böswilligen Authentifikator wird. Methoden, die gegenseitige Authentifizierung unterstützen (wie in Abschnitt 7.2.1 definiert), adressieren diese Schwachstelle.

In EAP besteht keine Anforderung, dass die Authentifizierung vollduplex ist oder dass dasselbe Protokoll in beiden Richtungen verwendet wird. Es ist vollkommen akzeptabel, dass verschiedene Protokolle in jeder Richtung verwendet werden. Dies hängt natürlich von den spezifischen verhandelten Protokollen ab. Im Allgemeinen ist jedoch die Durchführung einer einzigen einheitlichen gegenseitigen Authentifizierung besser als zwei unidirektionale Authentifizierungen, eine in jeder Richtung. Dies liegt daran, dass separate Authentifizierungen, die nicht kryptografisch gebunden sind, um nachzuweisen, dass sie Teil derselben Sitzung sind, anfällig für Man-in-the-Middle-Angriffe sind, wie in Abschnitt 7.4 diskutiert.

7.8. Verhandlungsangriffe (Negotiation Attacks)

Bei einem Verhandlungsangriff versucht der Angreifer, den Peer und den Authentifikator davon zu überzeugen, eine weniger sichere EAP-Methode auszuhandeln. EAP bietet keinen Schutz für Nak-Response-Pakete, obwohl es für eine Methode möglich ist, die Abdeckung von Nak-Responses in einem methodenspezifischen MIC einzuschließen.

In oder in Verbindung mit jedem Authentifikator wird nicht erwartet, dass ein bestimmter benannter Peer eine Auswahl von Methoden unterstützt. Dies würde den Peer anfällig für Angriffe machen, die die am wenigsten sichere Methode innerhalb eines Satzes aushandeln. Stattdessen SOLLTE für jeden benannten Peer eine Angabe von genau einer Methode vorhanden sein, die zur Authentifizierung dieses Peer-Namens verwendet wird. Wenn ein Peer verschiedene Authentifizierungsmethoden unter verschiedenen Umständen verwenden muss, SOLLTEN unterschiedliche Identitäten verwendet werden, von denen jede genau eine Authentifizierungsmethode identifiziert.

7.9. Implementierungsbesonderheiten (Implementation Idiosyncrasies)

Die Interaktion von EAP mit unteren Schichten wie PPP und IEEE 802 ist stark implementierungsabhängig.

Zum Beispiel beenden einige PPP-Implementierungen bei Authentifizierungsfehlern nicht die Verbindung, sondern beschränken den Verkehr in den Netzwerkschichtprotokollen auf eine gefilterte Teilmenge, was wiederum dem Peer die Möglichkeit gibt, Geheimnisse zu aktualisieren oder eine E-Mail an den Netzwerkadministrator zu senden, die auf ein Problem hinweist. In ähnlicher Weise führt ein Authentifizierungsfehler in [IEEE-802.1X] dazu, dass der Zugriff auf den kontrollierten Port verweigert wird, aber begrenzter Verkehr kann auf dem unkontrollierten Port erlaubt sein.

In EAP gibt es keine Vorkehrung für erneute Versuche nach fehlgeschlagener Authentifizierung. In PPP kann die LCP-Zustandsmaschine jedoch jederzeit das Authentifizierungsprotokoll neu verhandeln, wodurch ein neuer Versuch ermöglicht wird. In ähnlicher Weise können in IEEE 802.1X der Supplicant oder der Authentifikator jederzeit erneut authentifizieren. Es wird empfohlen, dass alle für Authentifizierungsfehler verwendeten Zähler nicht zurückgesetzt werden, bevor eine erfolgreiche Authentifizierung oder eine anschließende Beendigung der fehlgeschlagenen Verbindung erfolgt.

7.10. Schlüsselableitung (Key Derivation)

Der Peer und der EAP-Server können sich gegenseitig authentifizieren und Schlüssel ableiten. Um Schlüsselmaterial für die Verwendung in einer anschließend ausgehandelten Ciphersuite bereitzustellen, MUSS eine EAP-Methode, die Schlüsselableitung unterstützt, einen Master Session Key (MSK) von mindestens 64 Oktetten und einen Extended Master Session Key (EMSK) von mindestens 64 Oktetten exportieren. EAP-Methoden, die Schlüssel ableiten, MÜSSEN gegenseitige Authentifizierung zwischen dem EAP-Peer und dem EAP-Server bereitstellen.

Der MSK und EMSK DÜRFEN NICHT direkt zum Schutz von Daten verwendet werden; sie sind jedoch ausreichend groß, um die Ableitung eines AAA-Key zu ermöglichen, der anschließend zur Ableitung von Transient Session Keys (TSK) für die Verwendung mit der ausgewählten Ciphersuite verwendet wird. Jede Ciphersuite ist dafür verantwortlich, anzugeben, wie die TSK vom AAA-Key abgeleitet werden.

Der AAA-Key wird vom Schlüsselmaterial abgeleitet, das von der EAP-Methode exportiert wurde (MSK und EMSK). Diese Ableitung erfolgt auf dem AAA-Server. In vielen bestehenden Protokollen, die EAP verwenden, sind der AAA-Key und der MSK äquivalent, aber kompliziertere Mechanismen sind möglich (siehe [KEYFRAME] für Details).

EAP-Methoden SOLLTEN die Frische des MSK und EMSK sicherstellen, selbst in Fällen, in denen eine Partei möglicherweise keinen hochwertigen Zufallszahlengenerator hat. Eine EMPFOHLENE Methode ist, dass jede Partei eine Nonce von mindestens 128 Bits bereitstellt, die bei der Ableitung des MSK und EMSK verwendet wird.

EAP-Methoden exportieren MSK und EMSK, aber nicht die Transient Session Keys, um EAP-Methoden unabhängig von der Ciphersuite und dem Medium zu ermöglichen. Das von EAP-Methoden exportierte Schlüsselmaterial MUSS unabhängig von der ausgehandelten Ciphersuite zum Schutz der Daten sein.

Abhängig von der unteren Schicht können EAP-Methoden vor oder nach der Ciphersuite-Verhandlung ausgeführt werden, sodass die ausgewählte Ciphersuite der EAP-Methode möglicherweise nicht bekannt ist. Durch Bereitstellung von Schlüsselmaterial, das mit jeder Ciphersuite verwendet werden kann, können EAP-Methoden mit einer Vielzahl von Ciphersuites und Medien verwendet werden.

Um die Algorithmusunabhängigkeit zu bewahren, SOLLTEN EAP-Methoden, die Schlüssel ableiten, die geschützte Verhandlung der zur Sicherung der EAP-Konversation zwischen Peer und Server verwendeten Ciphersuite unterstützen (und dokumentieren). Dies ist getrennt von der zwischen Peer und Authentifikator ausgehandelten Ciphersuite, die zum Schutz der Daten verwendet wird.

Die Stärke der zur Sicherung der Daten verwendeten Transient Session Keys (TSK) hängt letztendlich von der Stärke der von der EAP-Methode generierten Schlüssel ab. Wenn eine EAP-Methode kein Schlüsselmaterial mit ausreichender Stärke erzeugen kann, können die TSK anfällig für Brute-Force-Angriffe sein. Um Bereitstellungen zu ermöglichen, die starke Schlüssel erfordern, SOLLTEN EAP-Methoden, die Schlüsselableitung unterstützen, in der Lage sein, MSK und EMSK zu generieren, jeweils mit einer effektiven Schlüsselstärke von mindestens 128 Bits.

Methoden, die Schlüsselableitung unterstützen, MÜSSEN die kryptografische Trennung zwischen den MSK- und EMSK-Zweigen der EAP-Schlüsselhierarchie demonstrieren. Ohne Verletzung einer grundlegenden kryptografischen Annahme (wie der Nichtumkehrbarkeit einer Einwegfunktion) DARF ein Angreifer, der den MSK oder EMSK wiederherstellt, NICHT in der Lage sein, die andere Größe mit einem Aufwand unterhalb von Brute Force wiederherzustellen.

Nicht überlappende Teilstrings des MSK MÜSSEN kryptografisch voneinander getrennt sein, wie in Abschnitt 7.2.1 definiert. Das heißt, die Kenntnis eines Teilstrings DARF NICHT helfen, einen anderen Teilstring wiederherzustellen, ohne eine harte kryptografische Annahme zu brechen. Dies ist erforderlich, da einige bestehende Ciphersuites TSKs bilden, indem sie einfach den AAA-Key in Teile geeigneter Länge aufteilen. In ähnlicher Weise MÜSSEN nicht überlappende Teilstrings des EMSK kryptografisch voneinander und von Teilstrings des MSK getrennt sein.

Der EMSK ist für zukünftige Verwendung reserviert und MUSS auf dem EAP-Peer und dem EAP-Server verbleiben, wo er abgeleitet wurde; er DARF NICHT an zusätzliche Parteien transportiert oder mit diesen geteilt werden, noch darf er zur Ableitung anderer Schlüssel verwendet werden. (Diese Einschränkung wird in einem zukünftigen Dokument gelockert, das spezifiziert, wie der EMSK verwendet werden kann.)

Da EAP keine explizite Schlüssellebensdauer-Verhandlung bietet, MÜSSEN EAP-Peers, Authentifikatoren und Authentifizierungsserver auf Situationen vorbereitet sein, in denen eine Partei den Schlüsselstatus verwirft, der auf einer anderen Partei gültig bleibt.

Diese Spezifikation bietet keine detaillierte Anleitung dazu, wie EAP-Methoden MSK und EMSK ableiten, wie der AAA-Key vom MSK und/oder EMSK abgeleitet wird oder wie TSKs vom AAA-Key abgeleitet werden.

Die Entwicklung und Validierung von Schlüsselableitungsalgorithmen ist schwierig, und daher SOLLTEN EAP-Methoden etablierte und analysierte Mechanismen zur Schlüsselableitung wiederverwenden (wie sie in IKE [RFC2409] oder TLS [RFC2246] spezifiziert sind), anstatt neue zu erfinden. EAP-Methoden SOLLTEN auch etablierte und analysierte Mechanismen zur MSK- und EMSK-Ableitung nutzen. Weitere Details zur EAP-Schlüsselableitung finden Sie in [KEYFRAME].

7.11. Schwache Ciphersuites (Weak Ciphersuites)

Wenn nach der anfänglichen EAP-Authentifizierung Datenpakete ohne paketweise Authentifizierung, Integrität und Replay-Schutz gesendet werden, kann ein Angreifer mit Zugriff auf das Medium Pakete injizieren, "Bits umdrehen" in bestehenden Paketen, Pakete wiederholen oder sogar die Sitzung vollständig übernehmen. Ohne paketweise Vertraulichkeit ist es möglich, Datenpakete auszuspionieren.

Um sich vor Datenmodifikation, Spoofing oder Ausspionierung zu schützen, wird empfohlen, EAP-Methoden zu verwenden, die gegenseitige Authentifizierung und Schlüsselableitung unterstützen (wie in Abschnitt 7.2.1 definiert), zusammen mit unteren Schichten, die paketweise Vertraulichkeit, Authentifizierung, Integrität und Replay-Schutz bieten.

Darüber hinaus sollte verstanden werden, dass EAP selbst keinen Integritätsschutz für diese Verhandlung bietet, wenn die untere Schicht eine Ciphersuite-Verhandlung durchführt. Um Downgrade-Angriffe zu vermeiden, die zur Verwendung schwächerer Ciphersuites führen würden, SOLLTEN Clients, die Ciphersuite-Verhandlung der unteren Schicht implementieren, sich vor Verhandlungs-Downgrade schützen.

Dies kann erreicht werden, indem Benutzer konfigurieren können, welche Ciphersuites als Sicherheitsrichtlinie akzeptabel sind, oder die Ciphersuite-Verhandlung KANN unter Verwendung von Schlüsselmaterial, das aus der EAP-Authentifizierung abgeleitet wurde, und eines im Voraus von den Peers der unteren Schicht vereinbarten MIC-Algorithmus authentifiziert werden.

7.12. Verbindungsschicht (Link Layer)

Es gibt Zuverlässigkeits- und Sicherheitsprobleme mit Verbindungsschicht-Indikationen in PPP, IEEE 802 LANs und IEEE 802.11 drahtlosen LANs:

[a] PPP. In PPP sind Verbindungsschicht-Indikationen wie LCP-Terminate (Verbindungsausfall-Indikation) und NCP (Verbindungserfolg-Indikation) weder authentifiziert noch integritätsgeschützt. Sie können daher von einem Angreifer mit Zugriff auf die Verbindung gefälscht werden.

[b] IEEE 802. Die EAPOL-Start- und EAPOL-Logoff-Frames von IEEE 802.1X sind weder authentifiziert noch integritätsgeschützt. Sie können daher von einem Angreifer mit Zugriff auf die Verbindung gefälscht werden.

[c] IEEE 802.11. In IEEE 802.11 umfassen Verbindungsschicht-Indikationen Disassociate- und Deauthenticate-Frames (Verbindungsausfall-Indikationen) und die erste Nachricht des 4-Wege-Handshakes (Verbindungserfolg-Indikation). Diese Nachrichten sind weder authentifiziert noch integritätsgeschützt, und obwohl sie nicht weiterleitbar sind, können sie von einem Angreifer in Reichweite gefälscht werden.

In IEEE 802.11 können IEEE 802.1X-Datenframes als Class 3-Unicast-Datenframes gesendet werden und sind daher weiterleitbar. Dies bedeutet, dass EAPOL-Start- und EAPOL-Logoff-Nachrichten zwar authentifiziert und integritätsgeschützt werden können, aber von einem authentifizierten Angreifer remote vom Ziel gefälscht werden können, wenn "Prä-Authentifizierung" aktiviert ist.

In IEEE 802.11 ist eine "Link Down"-Indikation eine unzuverlässige Indikation für einen Verbindungsausfall, da die drahtlose Signalstärke kommen und gehen kann und durch von einem Angreifer erzeugte Funkfrequenzinterferenzen beeinflusst werden kann. Um unnötige Zurücksetzungen zu vermeiden, wird empfohlen, diese Indikationen zu dämpfen, anstatt sie direkt an EAP weiterzuleiten. Da EAP Wiederübertragung unterstützt, ist es robust gegenüber vorübergehenden Verbindungsverlusten.

7.13. Trennung von Authentifikator und Backend-Authentifizierungsserver

Der EAP-Peer und der EAP-Server können sich gegenseitig authentifizieren und einen AAA-Key für eine Ciphersuite ableiten, die zum Schutz des nachfolgenden Datenverkehrs verwendet wird. Dies stellt kein Problem auf dem Peer dar, da Peer und EAP-Client auf derselben Maschine residieren; alles, was erforderlich ist, ist, dass der Client den AAA-Key vom MSK und EMSK ableitet, die von der EAP-Methode exportiert wurden, und dann einen Transient Session Key (TSK) an das Ciphersuite-Modul übergibt.

In dem Fall jedoch, in dem Authentifikator und Authentifizierungsserver auf verschiedenen Maschinen residieren, gibt es mehrere Sicherheitsimplikationen.

[a] Die Authentifizierung erfolgt zwischen Peer und Authentifizierungsserver, nicht zwischen Peer und Authentifikator. Dies bedeutet, dass es für den Peer nicht möglich ist, die Identität des Authentifikators, mit dem er spricht, allein mit EAP zu validieren.

[b] Wie in [RFC3579] diskutiert, verlässt sich der Authentifikator auf das AAA-Protokoll, um das Ergebnis einer Authentifizierungskonversation zu erfahren, und prüft nicht das gekapselte EAP-Paket (falls vorhanden), um das Ergebnis zu bestimmen. In der Praxis bedeutet dies, dass das zwischen Authentifikator und Authentifizierungsserver gesprochene AAA-Protokoll paketweise Authentifizierung, Integrität und Replay-Schutz unterstützen MUSS.

[c] Nach Abschluss der EAP-Konversation, bei der Sicherheitsdienste der unteren Schicht wie paketweise Vertraulichkeit, Authentifizierung, Integrität und Replay-Schutz aktiviert werden, SOLLTE ein Secure Association Protocol zwischen Peer und Authentifikator ausgeführt werden, um gegenseitige Authentifizierung zwischen Peer und Authentifikator bereitzustellen, die Lebendigkeit der Transient Session Keys zu garantieren, geschützte Ciphersuite- und Fähigkeitsverhandlung für nachfolgende Daten bereitzustellen und die Schlüsselverwendung zu synchronisieren.

[d] Ein AAA-Key, der vom MSK und/oder EMSK abgeleitet wurde, der zwischen Peer und Authentifizierungsserver ausgehandelt wurde, KANN an den Authentifikator übertragen werden. Daher muss ein Mechanismus bereitgestellt werden, um den AAA-Key vom Authentifizierungsserver an den Authentifikator zu übertragen, der ihn benötigt. Die Spezifikation der AAA-Key-Ableitungs-, Transport- und Wrapping-Mechanismen liegt außerhalb des Geltungsbereichs dieses Dokuments. Weitere Details zur AAA-Key-Ableitung finden Sie in [KEYFRAME].

7.14. Klartext-Passwörter (Cleartext Passwords)

Diese Spezifikation definiert keinen Mechanismus für Klartext-Passwort-Authentifizierung. Die Auslassung ist beabsichtigt. Die Verwendung von Klartext-Passwörtern würde es einem Angreifer mit Zugriff auf eine Verbindung, über die EAP-Pakete übertragen werden, ermöglichen, das Passwort zu erfassen.

Da Protokolle, die EAP kapseln, wie RADIUS [RFC3579], möglicherweise keine Vertraulichkeit bieten, können EAP-Pakete anschließend für den Transport über das Internet gekapselt werden, wo sie von einem Angreifer erfasst werden können.

Folglich können Klartext-Passwörter nicht sicher innerhalb von EAP verwendet werden, es sei denn, sie werden in einem geschützten Tunnel mit Serverauthentifizierung gekapselt. Einige der gleichen Risiken gelten für EAP-Methoden ohne Wörterbuch-Angriffsresistenz, wie in Abschnitt 7.2.1 definiert. Siehe Abschnitt 7.6 für Details.

7.15. Kanalbindung (Channel Binding)

Ein kompromittierter oder schlecht implementierter EAP-Authentifikator kann falsche Informationen an den EAP-Peer und/oder Server kommunizieren. Dies kann es einem Authentifikator ermöglichen, sich als ein anderer Authentifikator auszugeben oder falsche Informationen über Out-of-Band-Mechanismen zu kommunizieren (wie über ein AAA- oder Verbindungsschichtprotokoll).

Wenn EAP im Pass-Through-Modus verwendet wird, validiert der EAP-Peer normalerweise nicht die Identität des Pass-Through-Authentifikators, sondern prüft nur, ob der Pass-Through-Authentifikator vom EAP-Server vertraut wird. Dies schafft eine potenzielle Sicherheitsschwachstelle.

Abschnitt 4.3.7 von [RFC3579] beschreibt, wie ein EAP-Pass-Through-Authentifikator, der als AAA-Client fungiert, erkannt werden kann, wenn er versucht, sich als ein anderer Authentifikator auszugeben (z. B. durch Senden falscher NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] oder NAS-IPv6-Address [RFC3162] Attribute über das AAA-Protokoll). Es ist jedoch möglich, dass ein Pass-Through-Authentifikator, der als AAA-Client fungiert, korrekte Informationen an den AAA-Server liefert, während er irreführende Informationen an den EAP-Peer über ein Verbindungsschichtprotokoll kommuniziert.

Beispielsweise ist es für einen kompromittierten Authentifikator möglich, die Called-Station-Id oder den NAS-Identifier eines anderen Authentifikators zu verwenden, wenn er über ein Verbindungsschichtprotokoll mit dem EAP-Peer kommuniziert, oder für einen Pass-Through-Authentifikator, der als AAA-Client fungiert, eine falsche Peer-Calling-Station-Id [RFC2865][RFC3580] über das AAA-Protokoll an den AAA-Server zu liefern.

Um diese Schwachstelle zu adressieren, können EAP-Methoden einen geschützten Austausch von Kanaleigenschaften wie Endpunktidentifikatoren unterstützen, einschließlich (aber nicht beschränkt auf): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] und NAS-IPv6-Address [RFC3162].

Mit einem solchen geschützten Austausch ist es möglich, die vom Authentifikator über Out-of-Band-Mechanismen bereitgestellten Kanaleigenschaften mit denen abzugleichen, die innerhalb der EAP-Methode ausgetauscht wurden. Wenn Diskrepanzen gefunden werden, SOLLTEN diese protokolliert werden; zusätzliche Maßnahmen KÖNNEN ebenfalls ergriffen werden, wie die Verweigerung des Zugangs.

7.16. Geschützte Ergebnisanzeigen (Protected Result Indications)

In EAP sind Success- und Failure-Pakete weder bestätigt noch integritätsgeschützt. Ergebnisanzeigen verbessern die Widerstandsfähigkeit gegen den Verlust von Success- und Failure-Paketen, wenn EAP über untere Schichten läuft, die keine Wiederübertragung oder Authentifizierungszustands-Synchronisation unterstützen. In Medien wie IEEE 802.11, die Wiederübertragung sowie Authentifizierungszustands-Synchronisation über den in [IEEE-802.11i] definierten 4-Wege-Handshake bieten, ist die zusätzliche Widerstandsfähigkeit in der Regel von marginalem Nutzen.

Abhängig von der Methode und den Umständen können Ergebnisanzeigen von einem Angreifer gefälscht werden. Eine Methode wird als Bereitstellung geschützter Ergebnisanzeigen bezeichnet, wenn sie Ergebnisanzeigen sowie die Ansprüche "Integritätsschutz" und "Replay-Schutz" unterstützt. Eine Methode, die geschützte Ergebnisanzeigen unterstützt, MUSS angeben, welche Ergebnisanzeigen geschützt sind und welche nicht.

Geschützte Ergebnisanzeigen sind nicht erforderlich, um vor böswilligen Authentifikatoren zu schützen. Bei einer Methode mit gegenseitiger Authentifizierung verhindert die Anforderung, dass der Server sich gegenüber dem Peer authentifiziert, bevor der Peer ein Success-Paket akzeptiert, dass ein Angreifer als böswilliger Authentifikator fungiert.

Es ist jedoch für einen Angreifer möglich, ein Success-Paket zu fälschen, nachdem der Server sich gegenüber dem Peer authentifiziert hat, aber bevor der Peer sich gegenüber dem Server authentifiziert hat. Wenn der Peer das gefälschte Success-Paket akzeptiert und versucht, auf das Netzwerk zuzugreifen, obwohl er sich noch nicht erfolgreich gegenüber dem Server authentifiziert hat, kann ein Denial-of-Service-Angriff gegen den Peer durchgeführt werden. Nach einem solchen Angriff kann der Authentifikator, wenn die untere Schicht Fehlerindikationen unterstützt, den Zustand mit dem Peer durch Bereitstellung einer Fehlerindikation der unteren Schicht synchronisieren. Siehe Abschnitt 7.12 für Details.

Wenn ein Server den Peer authentifiziert und ein Success-Paket sendet, bevor er bestimmt, ob der Peer den Authentifikator authentifiziert hat, kann ein Leerlauf-Timeout auftreten, wenn der Authentifikator nicht vom Peer authentifiziert wird. Wenn von der unteren Schicht unterstützt, kann ein Authentifikator, der die Abwesenheit des Peers erkennt, Ressourcen freigeben.

Bei einer Methode, die Ergebnisanzeigen unterstützt, betrachtet ein Peer, der den Server authentifiziert hat, die Authentifizierung nicht als erfolgreich, bis er eine Anzeige erhält, dass der Server ihn erfolgreich authentifiziert hat. In ähnlicher Weise betrachtet ein Server, der den Peer erfolgreich authentifiziert hat, die Authentifizierung nicht als erfolgreich, bis er eine Anzeige erhält, dass der Peer den Server authentifiziert hat.

Um Synchronisationsprobleme zu vermeiden, ist es wünschenswert, dass der Absender vor dem Senden einer Erfolgs-Ergebnisanzeige überprüft, dass ausreichende Autorisierung vorhanden ist, um Zugang zu gewähren, obwohl dies, wie unten diskutiert, nicht immer möglich ist.

Obwohl Ergebnisanzeigen die Synchronisation des Authentifizierungsergebnisses zwischen Peer und Server ermöglichen können, garantiert dies nicht, dass Peer und Authentifikator in Bezug auf ihre Autorisierung synchronisiert sind oder dass keine Timeouts auftreten. Beispielsweise kann der EAP-Server sich einer von einem AAA-Proxy getroffenen Autorisierungsentscheidung nicht bewusst sein; der AAA-Server kann die Autorisierung erst überprüfen, nachdem die Authentifizierung erfolgreich abgeschlossen wurde, um festzustellen, dass die Autorisierung nicht gewährt werden kann, oder der AAA-Server kann Zugang gewähren, aber der Authentifikator kann ihn aufgrund eines vorübergehenden Ressourcenmangels nicht bereitstellen. In diesen Situationen kann die Synchronisation nur durch Ergebnisanzeigen der unteren Schicht erreicht werden.

Erfolgsanzeigen können explizit oder implizit sein. Wenn eine Methode beispielsweise Fehlernachrichten unterstützt, kann eine implizite Erfolgsanzeige als Empfang einer bestimmten Nachricht ohne vorherige Fehlernachricht definiert werden. Fehler werden normalerweise explizit angezeigt. Wie in Abschnitt 4.2 beschrieben, verwirft ein Peer stillschweigend ein Failure-Paket, das an einem Punkt empfangen wird, an dem die Methode dies nicht explizit erlaubt zu senden. Beispielsweise könnte eine Methode, die ihre eigenen Fehlernachrichten bereitstellt, erfordern, dass der Peer eine Fehlernachricht erhält, bevor er ein Failure-Paket akzeptiert.

Paketweise Authentifizierung, Integrität und Replay-Schutz von Ergebnisanzeigen schützt vor Spoofing. Da geschützte Ergebnisanzeigen die Verwendung eines Schlüssels für paketweise Authentifizierung und Integritätsschutz erfordern, MÜSSEN Methoden, die geschützte Ergebnisanzeigen unterstützen, auch die Ansprüche "Schlüsselableitung", "gegenseitige Authentifizierung", "Integritätsschutz" und "Replay-Schutz" unterstützen.

Geschützte Ergebnisanzeigen adressieren einige, aber nicht alle Denial-of-Service-Schwachstellen aufgrund von Spoofing von Success- und Failure-Paketen. EAP-Methoden können in der Regel nur unter bestimmten Umständen geschützte Ergebnisanzeigen bereitstellen. Beispielsweise können Fehler vor der Schlüsselableitung auftreten, und daher ist es möglicherweise nicht möglich, alle Fehleranzeigen zu schützen. Es ist auch möglich, dass Ergebnisanzeigen nicht in beide Richtungen unterstützt werden oder dass Synchronisation nicht in allen Betriebsmodi erreicht wird.

In EAP-TLS [RFC2716] beispielsweise authentifiziert der Server im Client-Authentifizierungs-Handshake den Peer, erhält aber keine geschützte Anzeige darüber, ob der Peer ihn authentifiziert hat. Im Gegensatz dazu authentifiziert der Peer den Server und ist sich bewusst, ob der Server ihn authentifiziert hat. Im Session-Resumption-Handshake authentifiziert der Peer den Server, erhält aber keine geschützte Anzeige darüber, ob der Server ihn authentifiziert hat. In diesem Modus authentifiziert der Server den Peer und ist sich bewusst, ob der Peer ihn authentifiziert hat.