7. Security Considerations

Dieser Abschnitt definiert ein allgemeines Bedrohungsmodell sowie die Sicherheitsanforderungen (Security Claims) von EAP-Methoden, die diese Bedrohungen mindern.

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

7.1. Bedrohungsmodell

EAP wurde für die Verwendung mit PPP [RFC1661] entwickelt und später in [IEEE-802.1X] für drahtgebundene IEEE-802-Netzwerke [IEEE-802] adaptiert. Anschließend wurde EAP für den Einsatz in Wireless-LAN-Netzwerken und im Internet vorgeschlagen. In all diesen Fällen hat ein Angreifer die Möglichkeit, auf den Link zuzugreifen, über den die EAP-Pakete übertragen werden. Beispielsweise dokumentiert [DECEPTION] Angriffe auf die Telefoninfrastruktur.

Ein Angreifer mit Zugriff auf den Link kann verschiedene Angriffe durchführen, darunter:

[1] Der Angreifer kann versuchen, die Benutzeridentität durch Abhören des Authentifizierungsverkehrs zu entdecken.

[2] Der Angreifer kann versuchen, EAP-Pakete zu ändern oder zu fälschen.

[3] Der Angreifer kann einen Denial-of-Service-Angriff durch Fälschen von Anzeigen der unteren Schicht oder von Success/Failure-Paketen, durch Wiedergabe von EAP-Paketen oder durch Generierung von Paketen mit sich überschneidenden Identifiern starten.

[4] Der Angreifer kann versuchen, durch einen Offline-Wörterbuchangriff eine Passphrase wiederherzustellen.

[5] Der Angreifer kann versuchen, den Peer zu überzeugen, sich mit einem nicht vertrauenswürdigen Netzwerk zu verbinden, indem er einen Man-in-the-Middle-Angriff startet.

[6] Der Angreifer kann versuchen, die EAP-Aushandlung zu kompromittieren, um die Auswahl einer schwächeren Authentifizierungsmethode zu bewirken.

[7] Der Angreifer kann versuchen, schwache Schlüsselableitungsverfahren, die innerhalb der EAP-Methode verwendet werden, auszunutzen, um Schlüssel wiederherzustellen.

[8] Der Angreifer kann versuchen, schwache Verschlüsselungssammlungen auszunutzen, die nach Abschluss der EAP-Sitzung anschließend verwendet werden.

[9] Der Angreifer kann versuchen, einen Downgrade-Angriff auf die Aushandlung der Verschlüsselungssammlung der unteren Schicht durchzuführen, um sicherzustellen, dass nach der EAP-Authentifizierung eine schwächere Verschlüsselungssammlung verwendet wird.

[10] Ein Angreifer, der als Authenticator auftritt, kann über einen Out-of-Band-Mechanismus (z. B. über AAA oder ein Protokoll der unteren Schicht) falsche Informationen an den EAP-Peer und/oder den Server bereitstellen. Dies umfasst das Vorgeben eines anderen Authenticators oder das Bereitstellen widersprüchlicher Informationen an Peer und EAP-Server.

Je nach unterer Schicht können diese Angriffe ohne physische Nähe durchgeführt werden. Wenn EAP für Wireless-Netzwerke verwendet wird, können EAP-Pakete von einem Authenticator (z. B. bei einer Vorauthentifizierung) weitergeleitet werden, sodass ein Angreifer nicht im Funkbereich des Authenticators sein muss, um ihn oder seinen Peer anzugreifen. Wenn EAP im Internet verwendet wird, können Angriffe aus größerer Entfernung gestartet werden.

7.2. Sicherheitsanforderungen

Um die von einer EAP-Methode bereitgestellte Sicherheit klar darzulegen, MUSS die Spezifikation der EAP-Methode einen Abschnitt über Sicherheitsanforderungen enthalten, der folgende Erklärungen umfasst:

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

[b] Sicherheitsanforderungen. Dies ist eine Aussage über die von der Methode beanspruchten Sicherheitseigenschaften, unter Verwendung der in Abschnitt 7.2.1 definierten Terminologie: gegenseitige Authentifizierung, Integritätsschutz, Wiedergabeschutz, Vertraulichkeit, Schlüsselableitung, Wörterbuchangriffswiderstand, schnelle Wiederverbindung, kryptografische Bindung. Der Abschnitt über Sicherheitsanforderungen der EAP-Methoden-Spezifikation SOLLTE eine Begründung für die getroffenen Erklärungen liefern. Dies kann durch Aufnahme eines Beweises in einem Anhang oder durch Verweis auf einen Beweis erfolgen.

[c] Schlüsselstärke. Wenn die Methode Schlüssel ableitet, MUSS die effektive Schlüsselstärke abgeschätzt werden. Diese Schätzung dient potenziellen Nutzern der Methode, um zu bestimmen, ob die resultierenden Schlüssel stark genug für die beabsichtigte Anwendung sind.

Die effektive Schlüsselstärke sollte in Bit angegeben werden und ist wie folgt definiert: Wenn die effektive Schlüsselstärke N Bit beträgt, benötigt die bestbekannte Methode zur Schlüsselwiederherstellung (mit nicht vernachlässigbarer Wahrscheinlichkeit) im Durchschnitt einen Aufwand, der 2^(N-1) typischen Blockchiffre-Operationen entspricht. Diese Aussage sollte von einer kurzen Begründung begleitet sein, die erklärt, wie diese Zahl ermittelt wurde. Diese Erklärung sollte die Parameter enthalten, die basierend auf dem aktuellen Algorithmuswissen erforderlich sind, um die angegebene Schlüsselstärke zu erreichen.

(Hinweis: Obwohl es schwierig ist, die Bedeutung von „vergleichbarer Aufwand“ und „typische Blockchiffre“ genau zu definieren, ist hier eine angemessene Näherung ausreichend. Für weitere Diskussion siehe beispielsweise [SILVERMAN].)

Die Schlüsselstärke hängt von der für die Schlüsselableitung verwendeten Methode ab. Wenn der Schlüssel beispielsweise aus einem gemeinsamen Geheimnis (wie einem Passwort oder einem langfristigen Schlüssel) und möglicherweise einigen öffentlichen Informationen (wie einem Nonce) abgeleitet wird, ist die effektive Schlüsselstärke durch die Stärke des langfristigen Schlüssels begrenzt (vorausgesetzt, der Ableitungsprozess ist rechnerisch einfach). Ein weiteres Beispiel: Bei Verwendung von Public-Key-Algorithmen hängt die Stärke des symmetrischen Schlüssels von der Stärke des verwendeten öffentlichen Schlüssels ab.

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

[e] Schwachstellenanzeige. Zusätzlich zu den getroffenen Sicherheitsanforderungen MUSS die Spezifikation angeben, welche in Abschnitt 7.2.1 dargelegten Sicherheitsanforderungen nicht getroffen werden.

7.2.1. Terminologie der Sicherheitsanforderungen für EAP-Methoden

Diese Begriffe werden verwendet, um die Sicherheitseigenschaften von EAP-Methoden zu beschreiben:

Geschützte Verschlüsselungssammlungs-Aushandlung (Protected ciphersuite negotiation)

Dies bezieht sich auf die Fähigkeit einer EAP-Methode, die zum Schutz der EAP-Sitzung verwendete Verschlüsselungssammlung auszuhandeln und die Aushandlung durch Integrität zu schützen. Es bezieht sich nicht auf die Fähigkeit, die zum Schutz der Daten verwendete Verschlüsselungssammlung auszuhandeln.

Gegenseitige Authentifizierung (Mutual authentication)

Dies ist eine EAP-Methode, bei der der Authenticator den Peer authentifiziert und der Peer den Authenticator innerhalb eines verriegelten Austauschs authentifiziert. Zwei unabhängig voneinander in entgegengesetzten Richtungen ausgeführte unidirektionale Methoden bieten nicht die hier definierte gegenseitige Authentifizierung.

Integritätsschutz (Integrity protection)

Dies bezieht sich auf die Bereitstellung der Datenursprungsauthentifizierung sowie des Schutzes vor unbefugter Änderung der Informationen in EAP-Paketen (einschließlich EAP-Request und -Response). Wenn diese Anforderung erhoben wird, MUSS die Methodenspezifikation die geschützten EAP-Pakete und die Felder innerhalb der EAP-Pakete beschreiben.

Wiedergabeschutz (Replay protection)

Dies bezieht sich auf den Schutz vor der Wiedergabe der EAP-Methode oder ihrer Nachrichten (einschließlich Ergebnisanzeigen für Erfolg und Fehler).

Vertraulichkeit (Confidentiality)

Dies bezieht sich auf die Verschlüsselung von EAP-Nachrichten (einschließlich EAP-Request und -Response sowie Ergebnisanzeigen für Erfolg und Fehler). Methoden, die diese Anforderung erheben, MÜSSEN den Identitätsschutz unterstützen (siehe Abschnitt 7.3).

Schlüsselableitung (Key derivation)

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

Schlüsselstärke (Key strength)

Wenn die effektive Schlüsselstärke N Bit beträgt, benötigt die bestbekannte Methode zur Schlüsselwiederherstellung (mit nicht vernachlässigbarer Wahrscheinlichkeit) im Durchschnitt einen Aufwand, der 2^(N-1) typischen Blockchiffre-Operationen entspricht.

Wörterbuchangriffswiderstand (Dictionary attack resistance)

Bei der Verwendung der Passwortauthentifizierung werden Passwörter typischerweise aus einer kleinen Menge (im Vergleich zum N-Bit-Schlüsselraum) ausgewählt, was Bedenken hinsichtlich Wörterbuchangriffen aufwirft. Eine Methode kann als Schutz gegen Wörterbuchangriffe bietend bezeichnet werden, wenn sie bei Verwendung des Passworts als Schlüssel keinen Offline-Angriff mit einem Arbeitsfaktor zulässt, der auf der Anzahl der Passwörter im Wörterbuch des Angreifers basiert.

Schnelle Wiederverbindung (Fast reconnect)

Die Fähigkeit, eine neue oder aktualisierte Sicherheitszuordnung effizienter oder mit weniger Hin- und Rückläufen zu erstellen, wenn zuvor eine Sicherheitszuordnung etabliert wurde.

Kryptografische Bindung (Cryptographic binding)

Die Fähigkeit des EAP-Peers, dem EAP-Server nachzuweisen, dass eine einzelne Entität als Peer für alle innerhalb der Tunnelmethode ausgeführten Methoden fungiert hat. Die Bindung kann auch implizieren, dass der EAP-Server dem Peer nachweist, dass eine einzelne Entität als EAP-Server für alle innerhalb der Tunnelmethode ausgeführten Methoden fungiert hat. Wenn sie korrekt ausgeführt wird, hilft die Bindung, die Man-in-the-Middle-Schwachstelle zu mindern.

Sitzungsunabhängigkeit (Session independence)

Der Nachweis, dass ein passiver Angriff (z. B. das Abfangen einer EAP-Sitzung) oder ein aktiver Angriff (einschließlich der Offenlegung von MSK oder EMSK) nachfolgende oder vorherige MSK oder EMSK nicht kompromittiert.

Fragmentierung (Fragmentation)

Dies bezieht sich darauf, ob die EAP-Methode Fragmentierung und Reassemblierung unterstützt. Wie in Abschnitt 3.1 beschrieben, SOLLTE eine EAP-Methode Fragmentierung und Reassemblierung unterstützen, wenn ein EAP-Paket das minimale MTU von 1020 Oktetten überschreiten kann.

Kanalbindung (Channel binding)

Die Kommunikation von innerhalb der EAP-Methode integritätsgeschützter Kanalattribute (z. B. Endpunktkennungen), die mit Werten verglichen werden können, die über einen Out-of-Band-Mechanismus (z. B. über AAA oder ein Protokoll der unteren Schicht) kommuniziert werden.

Hinweis: Diese Liste der Sicherheitsanforderungen ist nicht erschöpfend. Andere Eigenschaften (z. B. zusätzlicher Denial-of-Service-Schutz) können ebenfalls relevant sein.

7.3. Identitätsschutz

Der Identitätsaustausch ist in der EAP-Sitzung optional. Daher kann der Identitätsaustausch vollständig weggelassen werden, oder es kann ein methodenspezifischer Identitätsaustausch nach Einrichtung eines geschützten Kanals verwendet werden.

In Fällen, in denen Roaming wie in [RFC2607] beschrieben unterstützt wird, kann es jedoch erforderlich sein, den geeigneten Backend-Authentifizierungsserver zu lokalisieren, bevor die Authentifizierungssitzung fortgesetzt werden kann. Der Domain-Teil des Network Access Identifier (NAI) [RFC2486] ist normalerweise in EAP-Response/Identity enthalten, damit der Authentifizierungsaustausch an den geeigneten Backend-Authentifizierungsserver geroutet werden kann. Daher kann der Peer-Namens-Teil des NAI in EAP-Response/Identity bei Vorhandensein von Proxys oder Relays weggelassen werden, der Domain-Teil kann jedoch erforderlich sein.

Die Identität in der Identitätsantwort kann von der durch die EAP-Methode authentifizierten Identität abweichen. Im Falle des Identitätsschutzes kann dies beabsichtigt sein. EAP-Methoden SOLLTEN die authentifizierte Identität bei Zugriffskontrollentscheidungen verwenden.

7.4. Man-in-the-Middle-Angriffe

Wenn EAP in einem anderen Protokoll getunnelt wird, das die Peer-Authentifizierung weglässt, besteht eine potenzielle Schwachstelle gegen Man-in-the-Middle-Angriffe. Einzelheiten siehe [BINDING] und [MITM].

Wie in Abschnitt 2.1 beschrieben, lässt EAP keine Sequenzen von nicht getunnelten Authentifizierungsmethoden zu. Wenn eine Sequenz von EAP-Authentifizierungsmethoden zugelassen würde, hätte der Peer möglicherweise keinen Nachweis, dass eine einzelne Entität als Authenticator für alle EAP-Methoden der Sequenz fungiert hat. Beispielsweise könnte ein Authenticator eine EAP-Methode beenden und die nächste Methode der Sequenz dann an eine andere Partei weiterleiten, ohne dass der Peer dies weiß oder genehmigt. Ebenso könnte der Authenticator keinen Nachweis haben, dass eine einzelne Entität als Peer für alle EAP-Methoden der Sequenz fungiert hat.

Das Tunneln von EAP in einem anderen Protokoll ermöglicht einen Angriff, bei dem ein bösartiger EAP-Authenticator EAP zu einem legitimen Server tunneln kann. Wenn das Tunnelprotokoll zur Schlüsselvereinbarung verwendet wird, aber keine Peer-Authentifizierung verlangt, kann ein Angreifer, der einen legitimen Peer überzeugt, sich mit ihm zu verbinden, die EAP-Pakete zum legitimen Server tunneln, sich erfolgreich authentifizieren und Schlüssel erhalten. Dies ermöglicht es dem Angreifer, sich erfolgreich als Man-in-the-Middle zu etablieren, Zugriff auf das Netzwerk zu erlangen und die Fähigkeit zu erhalten, den Datenverkehr zwischen legitimen Peer und Server zu entschlüsseln.

Dieser Angriff kann wie folgt abgemildert werden:

[a] Anforderung einer gegenseitigen Authentifizierung innerhalb des EAP-Tunnelmechanismus.

[b] Anforderung einer kryptografischen Bindung zwischen dem EAP-Tunnelprotokoll und der getunnelten EAP-Methode. Wenn die kryptografische Bindung unterstützt wird, ist zusätzlich ein Mechanismus erforderlich, um Downgrade-Angriffe zu verhindern, die sie umgehen würden. Weitere Einzelheiten zur kryptografischen Bindung siehe [BINDING].

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

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

7.5. Paketänderungsangriffe

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

Da der Identifier nur ein einzelnes Oktett ist, ist er leicht zu erraten, was einem Angreifer ermöglicht, EAP-Pakete erfolgreich einzuspeisen oder wiederzugeben. Ein Angreifer kann auch die ungeschützten EAP-Header (Code, Identifier, Length, Type) in EAP-Paketen ändern. Dies kann dazu führen, dass Pakete unangemessen verworfen oder falsch interpretiert werden.

Um EAP-Pakete vor Änderung, Fälschung oder Wiedergabe zu schützen, wird die Verwendung von Methoden empfohlen, die geschützte Verschlüsselungssammlungs-Aushandlung, gegenseitige Authentifizierung, Schlüsselableitung sowie Integritäts- und Wiedergabeschutz unterstützen. Definitionen dieser Sicherheitsanforderungen siehe Abschnitt 7.2.1.

Ein Schutz kann durch Verwendung eines methodenspezifischen MIC bereitgestellt werden. Wenn innerhalb der EAP-Methode ein paketweiser MIC übernommen wird, MÜSSEN der Peer, der Authentifizierungsserver und der Authenticator, die nicht im Pass-Through-Modus betrieben werden, den MIC validieren. Ein MIC-Validierungsfehler SOLLTE protokolliert werden. Ob ein MIC-Validierungsfehler als fataler Fehler angesehen wird, wird durch die EAP-Methoden-Spezifikation entschieden.

Es wird empfohlen, dass Methoden, die EAP-Paket-Integritätsschutz bereitstellen, eine Abdeckung aller EAP-Headerfelder (einschließlich Code-, Identifier-, Length-, Type- und Type-Data-Felder) umfassen.

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

Zum Schutz kann EAP auch in einen durch Protokolle wie ISAKMP [RFC2408] erstellten geschützten Kanal gekapselt werden, wie in [IKEv2] geschehen, oder innerhalb von TLS [RFC2246]. Wie in Abschnitt 7.4 beschrieben, kann das EAP-Tunneln jedoch Man-in-the-Middle-Schwachstellen verursachen.

Bestehende EAP-Methoden definieren einen message integrity check (MIC), der mehrere EAP-Pakete abdeckt. Beispielsweise definiert EAP-TLS [RFC2716] einen MIC für TLS-Datensätze, die möglicherweise in mehrere Fragmente aufgeteilt werden; innerhalb der FINISHED-Nachricht wird der MIC über die vorherigen Nachrichten berechnet. Wenn der MIC mehrere EAP-Pakete abdeckt, wird ein MIC-Validierungsfehler normalerweise als fataler Fehler angesehen.

In EAP-TLS [RFC2716] wird ein MIC-Validierungsfehler als fataler Fehler behandelt, da dies in TLS [RFC2246] vorgeschrieben ist. Es ist jedoch auch möglich, EAP-Methoden zu entwickeln, die einen paketweisen MIC unterstützen und auf einen Validierungsfehler mit stillschweigendem Verwerfen des betreffenden Pakets reagieren.

In diesem Dokument geht die Beschreibung der EAP-Nachrichtenverarbeitung davon aus, dass, wo eine paketweise MIC-Validierung stattfindet, sie effektiv so ausgeführt wird, als ob sie ausgeführt würde, bevor eine Antwort gesendet oder der Zustand des Hosts, der das Paket empfängt, geändert wird.

7.6. Wörterbuchangriffe

Es ist bekannt, dass Passwortauthentifizierungsalgorithmen wie EAP-MD5, MS-CHAPv1 [RFC2433] und Kerberos V [RFC1510] anfällig für Wörterbuchangriffe sind. MS-CHAPv1-Schwachstellen sind in [PPTPv1] dokumentiert; MS-CHAPv2-Schwachstellen in [PPTPv2]; Kerberos-Schwachstellen in [KRBATTACK], [KRBLIM] und [KERB4WEAK].

Um Wörterbuchangriffe zu verhindern, wird die Verwendung von Authentifizierungsmethoden empfohlen, die Widerstand gegen Wörterbuchangriffe bieten (wie in Abschnitt 7.2.1 definiert).

Wenn ein als anfällig für Wörterbuchangriffe bekanntes Authentifizierungsverfahren verwendet wird, kann die Sitzung in einem geschützten Kanal getunnelt werden, um zusätzlichen Schutz zu bieten. Wie in Abschnitt 7.4 beschrieben, kann das EAP-Tunneln jedoch Man-in-the-Middle-Schwachstellen verursachen, daher ist eine Widerstand gegen Wörterbuchangriffe bietende Methode vorzuziehen.

7.7. Verbindung mit einem nicht vertrauenswürdigen Netzwerk

Für EAP-Methoden, die unidirektionale Authentifizierung unterstützen (z. B. EAP-MD5), authentifiziert der Peer den Authenticator nicht, was den Peer anfällig für Angriffe eines bösartigen Authenticators macht. Methoden, die gegenseitige Authentifizierung unterstützen (wie in Abschnitt 7.2.1 definiert), beheben diese Schwachstelle.

In EAP ist nicht gefordert, dass die Authentifizierung Vollduplex ist oder in beiden Richtungen dasselbe Protokoll verwendet wird. Die Verwendung unterschiedlicher Protokolle in jeder Richtung ist völlig akzeptabel. Dies hängt natürlich von den spezifisch ausgehandelten Protokollen ab. Allgemein ist jedoch der Abschluss einer einzigen einheitlichen gegenseitigen Authentifizierung zwei unidirektionalen Authentifizierungen (eine in jede Richtung) vorzuziehen. Dies liegt daran, dass separate Authentifizierungen, die nicht kryptografisch gebunden sind, um zu beweisen, dass sie Teil derselben Sitzung sind, anfällig für die in Abschnitt 7.4 besprochenen Man-in-the-Middle-Angriffe sind.

7.8. Aushandlungsangriffe

Bei einem Aushandlungsangriff versucht ein Angreifer, Peer und Authenticator zu überzeugen, eine weniger sichere EAP-Methode auszuhandeln. EAP bietet keinen Schutz für Nak-Response-Pakete, obwohl Methoden eine Abdeckung der Nak-Response innerhalb eines methodenspezifischen MIC aufnehmen können.

Innerhalb oder im Zusammenhang mit jedem Authenticator ist nicht vorgesehen, dass ein spezifisch benannter Peer die Auswahl mehrerer Methoden unterstützt. Dies würde den Peer anfällig für einen Angriff machen, bei dem die unsicherste Methode aus einer Gruppe ausgehandelt wird. Stattdessen SOLLTE es für jeden benannten Peer einen Hinweis geben, der genau die einzelne Methode angibt, die zur Authentifizierung dieses Peer-Namens verwendet wird. Wenn der Peer unterschiedliche Authentifizierungsmethoden in verschiedenen Situationen verwenden muss, SOLLTE er unterschiedliche Identitäten annehmen, von denen jede genau eine Authentifizierungsmethode identifiziert.

7.9. Implementierungseigenheiten

Die Interaktion von EAP mit unteren Schichten wie PPP und IEEE 802 hängt stark von der Implementierung ab.

Beispielsweise beenden einige PPP-Implementierungen bei einem Authentifizierungsfehler die Verbindung nicht, sondern beschränken den Verkehr in Netzwerkschichtprotokollen auf ein gefiltertes Teilmenge, was dem Peer die Möglichkeit gibt, Schlüssel zu aktualisieren oder eine E-Mail an den Netzwerkadministrator zu senden, um auf das Problem hinzuweisen. Ebenso führt in [IEEE-802.1X] ein Authentifizierungsfehler zur Verweigerung des Zugriffs auf den kontrollierten Port, auf dem unkontrollierten Port kann jedoch begrenzter Verkehr zulässig sein.

In EAP gibt es keine Bestimmungen für Wiederholungsversuche bei fehlgeschlagener Authentifizierung. In PPP kann jedoch die LCP-Zustandsmaschine das Authentifizierungsprotokoll jederzeit neu aushandeln, was neue Versuche ermöglicht. Ebenso können in IEEE 802.1X der Supplicant oder der Authenticator jederzeit neu authentifizieren. Es wird empfohlen, dass alle für fehlgeschlagene Authentifizierung verwendeten Zähler nicht zurückgesetzt werden, bis eine Authentifizierung erfolgreich ist oder die fehlgeschlagene Verbindung nachfolgend beendet wird.

7.10. Schlüsselableitung

Es ist möglich, dass sich Peer und EAP-Server gegenseitig authentifizieren und Schlüssel ableiten. Um Schlüsselmaterial für die anschließend ausgehandelten Verschlüsselungssammlungen bereitzustellen, MÜSSEN EAP-Methoden, die die Schlüsselableitung unterstützen, mindestens einen 64 Oktette umfassenden Master Session Key (MSK) und mindestens einen 64 Oktette umfassenden Extended Master Session Key (EMSK) exportieren. EAP-Methoden, die Schlüssel ableiten, MÜSSEN eine gegenseitige Authentifizierung zwischen EAP-Peer und EAP-Server bereitstellen.

Der MSK und der EMSK DÜRFEN NICHT direkt zum Schutz von Daten verwendet werden; sie sind jedoch groß genug, um den AAA-Key abzuleiten, der anschließend zur Ableitung der temporären Sitzungsschlüssel (TSK) aus der ausgewählten Verschlüsselungssammlung verwendet wird. Jede Verschlüsselungssammlung ist dafür verantwortlich, festzulegen, wie die TSK aus dem AAA-Key abgeleitet wird.

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

EAP-Methoden, die Schlüssel ableiten, SOLLTEN die Frische von MSK und EMSK sicherstellen, selbst wenn eine der Parteien keinen qualitativ hochwertigen Zufallszahlengenerator haben könnte. Die empfohlene Methode besteht darin, dass jede Partei ein Nonce von mindestens 128 Bit bereitstellt, das in der Ableitung von MSK und EMSK verwendet wird.

EAP-Methoden, die Schlüssel ableiten, exportieren diesen (MSK und EMSK), leiten jedoch keine temporären Sitzungsschlüssel ab, um die EAP-Methode unabhängig von Verschlüsselungssammlungen und Medien zu halten. Das von EAP-Methoden exportierte Schlüsselmaterial MUSS unabhängig von der zum Schutz der Daten ausgehandelten Verschlüsselungssammlung sein.

Je nach unterer Schicht kann die EAP-Methode vor oder nach der Aushandlung der Verschlüsselungssammlung ausgeführt werden, sodass die ausgewählte Verschlüsselungssammlung der EAP-Methode möglicherweise unbekannt ist. Durch Bereitstellung von Schlüsselmaterial, das mit jeder Verschlüsselungssammlung verwendet werden kann, kann die EAP-Methode mit einer Vielzahl von Verschlüsselungssammlungen und Medien verwendet werden.

Um Algorithmenunabhängigkeit aufrechtzuerhalten, SOLLTEN EAP-Methoden, die Schlüssel ableiten, die geschützte Aushandlung der Verschlüsselungssammlung unterstützen (und dokumentieren), die zwischen Peer und Server zum Schutz der EAP-Sitzung verwendet wird. Dies unterscheidet sich von der zwischen Peer und Authenticator ausgehandelten Verschlüsselungssammlung zum Schutz der Daten.

Die Stärke der zum Schutz der Daten verwendeten temporären Sitzungsschlüssel (TSK) hängt letztlich von der Stärke der von der EAP-Methode generierten Schlüssel ab. Wenn die EAP-Methode kein Schlüsselmaterial ausreichender Stärke erzeugen kann, können die TSK einem Brute-Force-Angriff unterliegen. Um Bereitstellungen zu unterstützen, die starke Schlüssel benötigen, SOLLTEN EAP-Methoden, die die Schlüsselableitung unterstützen, in der Lage sein, MSK und EMSK zu generieren, von denen jede eine effektive Schlüsselstärke von mindestens 128 Bit aufweist.

Methoden, die die Schlüsselableitung unterstützen, MÜSSEN die kryptografische Trennung zwischen den MSK- und EMSK-Verzweigungen der EAP-Schlüsselhierarchie nachweisen. Ohne Verletzung grundlegender kryptografischer Annahmen (wie der Irreversibilität von Einwegfunktionen) DARF ein Angreifer, der MSK oder EMSK wiederherstellt, die andere Menge nicht mit geringerem Aufwand als einem Brute-Force-Angriff wiederherstellen.

Wie in Abschnitt 7.2.1 definiert, MÜSSEN sich nicht überlappende Teilzeichenfolgen des MSK kryptografisch voneinander getrennt sein. Das heißt, ohne das Brechen einiger schwieriger kryptografischer Annahmen DARF die Kenntnis einer Teilzeichenfolge nicht helfen, eine andere Teilzeichenfolge wiederherzustellen. Dies ist erforderlich, da einige bestehende Verschlüsselungssammlungen die TSK bilden, indem sie den AAA-Key einfach in Fragmente angemessener Länge aufteilen. Ebenso MÜSSEN sich nicht überlappende Teilzeichenfolgen des EMSK kryptografisch voneinander und relativ zu den Teilzeichenfolgen des MSK getrennt sein.

Der EMSK ist für zukünftige Verwendung reserviert, MUSS auf dem EAP-Peer und dem EAP-Server, die ihn abgeleitet haben, verbleiben; DARF NICHT an zusätzliche Parteien übertragen oder mit ihnen geteilt oder zur Ableitung anderer Schlüssel verwendet werden. (In zukünftigen Dokumenten, die die Verwendung des EMSK festlegen, wird diese Einschränkung aufgehoben.)

Da EAP keine explizite Aushandlung der Schlüssellebensdauer bietet, MÜSSEN EAP-Peer, Authenticator und Authentifizierungsserver auf den Fall vorbereitet sein, dass eine Partei den Schlüsselzustand verwirft, der bei einer anderen Partei noch gültig ist.

Diese Spezifikation gibt keine detaillierte Anleitung dazu, wie EAP-Methoden MSK und EMSK ableiten, wie der AAA-Key aus MSK und/oder EMSK abgeleitet wird oder wie die TSK aus dem AAA-Key abgeleitet wird.

Die Entwicklung und Validierung von Schlüsselableitungsalgorithmen ist schwierig, daher SOLLTEN EAP-Methoden gut etablierte und analysierte Schlüsselableitungsmechanismen (wie die in IKE [RFC2409] oder TLS [RFC2246] spezifizierten) wiederverwenden, anstatt neue zu erfinden. EAP-Methoden SOLLTEN auch gut etablierte und analysierte MSK- und EMSK-Ableitungsmechanismen nutzen. Weitere Einzelheiten zur EAP-Schlüsselableitung finden sich in [KEYFRAME].

7.11. Schwache Verschlüsselungssammlungen

Wenn nach der anfänglichen EAP-Authentifizierung gesendete Datenpakete keinen paketweisen Authentifizierungs-, Integritäts- und Wiedergabeschutz aufweisen, kann ein Angreifer mit Zugriff auf das Medium Pakete einspeisen, „Bits in bestehenden Paketen umdrehen“, Pakete wiedergeben oder sogar die Sitzung vollständig entführen. Ohne paketweise Vertraulichkeit ist das Abhören von Paketen möglich.

Um Datenänderung, Fälschung oder Abhören zu verhindern, wird die Verwendung von EAP-Methoden empfohlen, die gegenseitige Authentifizierung und Schlüsselableitung (wie in Abschnitt 7.2.1 definiert) sowie eine untere Schicht unterstützen, die paketweise Vertraulichkeit, Authentifizierung, Integrität und Wiedergabeschutz bietet.

Zusätzlich, wenn die untere Schicht eine Verschlüsselungssammlungs-Aushandlung durchführt, sollte verstanden werden, dass EAP selbst keinen Integritätsschutz für diese Aushandlung bietet. Um daher Downgrade-Angriffe zu vermeiden, die zur Verwendung schwächerer Verschlüsselungssammlungen führen, SOLLTEN Clients, die die Aushandlung der unteren Schicht implementieren, eine Herabstufung der Aushandlung verhindern.

Dies kann erreicht werden, indem dem Benutzer ermöglicht wird, welche Verschlüsselungssammlungen als Sicherheitsrichtlinie akzeptabel sind, zu konfigurieren, oder die Verschlüsselungssammlungs-Aushandlung KANN unter Verwendung des aus der EAP-Authentifizierung abgeleiteten Schlüsselmaterials und eines vorab zwischen Peer und unterer Schicht vereinbarten MIC-Algorithmus authentifiziert werden.

7.12. Sicherungsschicht

Die Anzeigen der Sicherungsschicht in PPP, IEEE 802 LAN und IEEE 802.11 Wireless LAN weisen Zuverlässigkeits- und Sicherheitsprobleme auf:

[a] PPP. In PPP sind Anzeigen der Sicherungsschicht wie LCP-Terminate (Link-Fehleranzeige) und NCP (Link-Erfolgsanzeige) weder authentifiziert noch integritätsgeschützt. Ein Angreifer mit Zugriff auf den Link kann sie daher fälschen.

[b] IEEE 802. Die EAPOL-Start- und EAPOL-Logoff-Rahmen von IEEE 802.1X sind weder authentifiziert noch integritätsgeschützt. Ein Angreifer mit Zugriff auf den Link kann sie daher fälschen.

[c] IEEE 802.11. In IEEE 802.11 umfassen die Anzeigen der Sicherungsschicht die Frames Disassociate und Deauthenticate (Link-Fehleranzeige) sowie die erste Nachricht des Vier-Wege-Handschlags (Link-Erfolgsanzeige). Diese Nachrichten sind weder authentifiziert noch integritätsgeschützt und, obwohl nicht weiterleitbar, können sie von einem Angreifer im Funkbereich gefälscht werden.

In IEEE 802.11 können IEEE 802.1X-Datenrahmen als Class-3-Unicast-Datenrahmen gesendet werden und sind daher weiterleitbar. Das bedeutet, dass, obwohl die EAPOL-Start- und EAPOL-Logoff-Nachrichten authentifiziert und integritätsgeschützt sein können, ein authentifizierter Angreifer, der weit von der Zielstation entfernt ist, sie fälschen kann, wenn „Vorauthentifizierung“ aktiviert ist.

In IEEE 802.11 ist die „Link-Down“-Anzeige eine unzuverlässige Anzeige für Link-Fehler, da die drahtlose Signalstärke erscheinen und verschwinden kann und von der von einem Angreifer erzeugten Funkstörung beeinflusst werden kann. Um unnötige Resets zu vermeiden, wird empfohlen, diese Anzeigen zu dämpfen, anstatt sie direkt an EAP weiterzugeben. Da EAP die Wiederübertragung unterstützt, ist es gegen vorübergehende Verbindungsverluste robust.

7.13. Trennung von Authenticator und Backend-Authentifizierungsserver

Es ist möglich, dass sich EAP-Peer und EAP-Server gegenseitig authentifizieren und den AAA-Key für die Verschlüsselungssammlung 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 resideren; alles, was erforderlich ist, ist, dass der Client den AAA-Key aus dem von der EAP-Methode exportierten MSK und EMSK ableitet und dann die temporären Sitzungsschlüssel (TSK) an das Modul der Verschlüsselungssammlung übergibt.

In Fällen, in denen sich Authenticator und Authentifizierungsserver auf verschiedenen Maschinen befinden, ergeben sich jedoch mehrere Auswirkungen auf die Sicherheit:

[a] Die Authentifizierung findet zwischen Peer und Authentifizierungsserver statt, nicht zwischen Peer und Authenticator. Dies bedeutet, dass mit EAP allein es dem Peer unmöglich ist, die Identität des Authenticators, mit dem er kommuniziert, zu überprüfen.

[b] Wie in [RFC3579] beschrieben, stützt sich der Authenticator auf das AAA-Protokoll, um das Ergebnis der Authentifizierungssitzung zu erfahren, und untersucht nicht die gekapselten EAP-Pakete (falls vorhanden), um das Ergebnis zu bestimmen. In der Praxis bedeutet dies, dass das zwischen Authenticator und Authentifizierungsserver verwendete AAA-Protokoll paketweise Authentifizierung, Integrität und Wiedergabeschutz unterstützen MUSS.

[c] Nach Abschluss der EAP-Sitzung, wenn Sicherheitsdienste der unteren Schicht wie paketweise Vertraulichkeit, Authentifizierung, Integrität und Wiedergabeschutz aktiviert werden, SOLLTE ein Sicherheitszuordnungsprotokoll zwischen Peer und Authenticator ausgeführt werden, das eine gegenseitige Authentifizierung zwischen Peer und Authenticator bereitstellt, die Frische der temporären Sitzungsschlüssel garantiert, eine geschützte Verschlüsselungssammlungs- und Fähigkeitsaushandlung für nachfolgende Daten bereitstellt und die Schlüsselnutzung synchronisiert.

[d] Der aus dem zwischen Peer und Authentifizierungsserver ausgehandelten MSK und/oder EMSK abgeleitete AAA-Key KANN an den Authenticator übertragen werden. Daher ist ein Mechanismus erforderlich, um den AAA-Key vom Authentifizierungsserver an den Authenticator zu übertragen, der ihn benötigt. Die Spezifikation der AAA-Key-Ableitung, -Übertragung und -Kapselung liegt nicht im Anwendungsbereich dieses Dokuments. Weitere Einzelheiten zur AAA-Key-Ableitung finden sich in [KEYFRAME].

7.14. Klartext-Passwörter

Diese Spezifikation definiert keinen Mechanismus für die Klartext-Passwortauthentifizierung. Diese Auslassung ist beabsichtigt. Die Verwendung von Klartext-Passwörtern würde einem Angreifer mit Zugriff auf den Link, über den die EAP-Pakete transportiert werden, das Erfassen des Passworts ermöglichen.

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

Daher können Klartext-Passwörter in EAP nicht sicher verwendet werden, es sei denn, sie werden in einem geschützten Tunnel mit Server-Authentifizierung gekapselt. Einige der gleichen Risiken, die in Abschnitt 7.2.1 definiert sind, gelten auch für EAP-Methoden ohne Widerstand gegen Wörterbuchangriffe. Einzelheiten siehe Abschnitt 7.6.

7.15. Kanalbindung

Ein kompromittierter oder schlecht implementierter EAP-Authenticator hat die Möglichkeit, falsche Informationen an den EAP-Peer und/oder den Server zu kommunizieren. Dies kann es dem Authenticator ermöglichen, einen anderen Authenticator vorzutäuschen, oder über einen Out-of-Band-Mechanismus (wie über AAA oder ein Protokoll der unteren Schicht) falsche Informationen zu kommunizieren.

Bei der Verwendung von EAP im Pass-Through-Modus überprüft der EAP-Peer normalerweise nicht die Identität des Pass-Through-Authenticators, sondern verifiziert nur, dass der Pass-Through-Authenticator vom EAP-Server vertraut wird. Dies schafft eine potenzielle Sicherheitsschwachstelle.

Abschnitt 4.3.7 von [RFC3579] beschreibt, wie ein EAP-Pass-Through-Authenticator, der als AAA-Client agiert, erkannt werden kann, wenn er versucht, einen anderen Authenticator vorzutäuschen (z. B. durch Senden falscher NAS-Identifier [RFC2865]-, NAS-IP-Address [RFC2865]- oder NAS-IPv6-Address [RFC3162]-Attribute über das AAA-Protokoll). Ein Pass-Through-Authenticator, der als AAA-Client agiert, hat jedoch die Möglichkeit, dem AAA-Server korrekte Informationen zu liefern und gleichzeitig dem EAP-Peer über das Protokoll der unteren Schicht irreführende Informationen zu kommunizieren.

Beispielsweise hat ein kompromittierter Authenticator die Möglichkeit, beim Kommunizieren mit dem EAP-Peer über das Protokoll der unteren Schicht die Called-Station-Id oder NAS-Identifier eines anderen Authenticators zu nutzen, oder ein als AAA-Client agierender Pass-Through-Authenticator kann dem AAA-Server über das AAA-Protokoll eine falsche Peer Calling-Station-Id [RFC2865][RFC3580] liefern.

Um diese Schwachstelle zu beheben, KÖNNEN EAP-Methoden den geschützten Austausch von Kanalattributen (wie Endpunktkennungen) 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].

Durch Verwendung eines solchen geschützten Austauschs können die vom Authenticator über einen Out-of-Band-Mechanismus bereitgestellten Kanalattribute mit den innerhalb der EAP-Methode ausgetauschten Attributen abgeglichen werden. Wenn Abweichungen festgestellt werden, SOLLTEN diese protokolliert werden; es KÖNNEN auch andere Maßnahmen ergriffen werden, wie z. B. die Verweigerung des Zugriffs.

7.16. Geschützte Ergebnisanzeigen

In EAP werden Success- und Failure-Pakete weder bestätigt noch integritätsgeschützt. Wenn EAP auf einer unteren Schicht ausgeführt wird, die keine Wiederübertragung oder Authentifizierungszustandssynchronisierung unterstützt, erhöhen Ergebnisanzeigen die Ausfallsicherheit gegenüber dem Verlust von Success- und Failure-Paketen. Auf Medien, die Wiederübertragung sowie eine über den in [IEEE-802.11i] definierten Vier-Wege-Handschlag synchronisierte Authentifizierungszustand bereitstellen (wie IEEE 802.11), ist der zusätzliche Nutzen der Ausfallsicherheit normalerweise begrenzt.

Je nach Methode und Situation können Ergebnisanzeigen von einem Angreifer gefälscht werden. Eine Methode gilt als Bereitstellung geschützter Ergebnisanzeigen, wenn sie Ergebnisanzeigen sowie die Anforderungen „Integritätsschutz“ und „Wiedergabeschutz“ unterstützt. Methoden, die geschützte Ergebnisanzeigen unterstützen, MÜSSEN angeben, welche Ergebnisanzeigen geschützt sind und welche nicht.

Geschützte Ergebnisanzeigen erfordern keinen Schutz vor einem bösartigen Authenticator. Innerhalb einer gegenseitigen Authentifizierungsmethode kann das Verlangen, dass der Server den Peer authentifiziert, bevor der Peer ein Success-Paket akzeptiert, verhindern, dass ein Angreifer als bösartiger Authenticator auftritt.

Nachdem der Server den Peer jedoch authentifiziert hat, aber bevor der Peer den Server authentifiziert hat, kann ein Angreifer ein Success-Paket fälschen. Wenn der Peer das gefälschte Success-Paket akzeptiert und versucht, auf das Netzwerk zuzugreifen, während er sich noch nicht erfolgreich beim Server authentifiziert hat, kann ein Denial-of-Service-Angriff gegen den Peer gestartet werden. Nach einem solchen Angriff kann der Authenticator, wenn die untere Schicht eine Fehleranzeige unterstützt, den Zustand mit dem Peer synchronisieren, indem er eine Fehleranzeige der unteren Schicht bereitstellt. Siehe Abschnitt 7.12 für Einzelheiten.

Wenn der Server den Peer authentifiziert und ein Success-Paket sendet, bevor er feststellt, ob der Peer den Authenticator authentifiziert hat, kann ein Leerlauf-Timeout auftreten, wenn der Authenticator nicht vom Peer authentifiziert wird. Wo die untere Schicht dies unterstützt, kann der Authenticator, der das Fehlen des Peers wahrnimmt, Ressourcen freigeben.

In Methoden, die Ergebnisanzeigen unterstützen, betrachtet ein Peer, der den Server authentifiziert hat, die Authentifizierung nicht als erfolgreich, bis er eine Anzeige erhalten hat, dass der Server ihn erfolgreich authentifiziert hat. Ebenso betrachtet ein Server, der den Peer erfolgreich authentifiziert hat, die Authentifizierung nicht als erfolgreich, bis er eine Anzeige erhalten hat, dass der Peer den Server authentifiziert hat.

Um Synchronisierungsprobleme zu vermeiden, ist es ratsam, dass der Sender vor dem Senden einer Erfolgsergebnisanzeige überprüft, ob eine ausreichende Berechtigung zum Gewähren des Zugriffs vorliegt, aber wie unten beschrieben ist dies nicht immer möglich.

Obwohl Ergebnisanzeigen die Synchronisierung der Authentifizierungsergebnisse zwischen Peer und Server ermöglichen, garantiert dies nicht, dass Peer und Authenticator in Bezug auf die Autorisierung synchronisiert werden, noch dass kein Timeout auftritt. Beispielsweise kennt der EAP-Server möglicherweise die von einem AAA-Proxy getroffenen Autorisierungsentscheidungen nicht; der AAA-Server überprüft die Autorisierung möglicherweise erst nach erfolgreichem Abschluss der Authentifizierung und stellt dann fest, dass er die Autorisierung nicht gewähren kann, oder der AAA-Server gewährt möglicherweise den Zugriff, aber der Authenticator kann ihn aufgrund temporärer Ressourcenknappheit nicht bereitstellen. In diesen Fällen kann die Synchronisierung nur über Ergebnisanzeigen der unteren Schicht erreicht werden.

Eine Erfolgsanzeige kann explizit oder implizit sein. Beispielsweise kann in Methoden, die Fehlernachrichten unterstützen, eine implizite Erfolgsanzeige als Empfang einer bestimmten Nachricht ohne vorherige Fehlernachricht definiert werden. Ein Fehler wird normalerweise explizit angezeigt. Wie in Abschnitt 4.2 beschrieben, verwirft der Peer ein Failure-Paket stillschweigend, das zu einem Zeitpunkt empfangen wird, an dem das Senden dieses Pakets durch die Methode nicht ausdrücklich erlaubt ist. Eine Methode, die ihre eigenen Fehlernachrichten bereitstellt, kann beispielsweise verlangen, dass der Peer eine Fehlernachricht empfängt, bevor er ein Failure-Paket akzeptiert.

Die paketweise Authentifizierung, Integrität und Wiedergabeschutz von Ergebnisanzeigen verhindert Fälschung. Da geschützte Ergebnisanzeigen die Verwendung von Schlüsseln für paketweise Authentifizierung und Integritätsschutz erfordern, MÜSSEN Methoden, die geschützte Ergebnisanzeigen unterstützen, auch die Anforderungen „Schlüsselableitung“, „gegenseitige Authentifizierung“, „Integritätsschutz“ und „Wiedergabeschutz“ unterstützen.

Geschützte Ergebnisanzeigen beheben einige Denial-of-Service-Schwachstellen, die durch das Fälschen von Success- und Failure-Paketen entstehen, jedoch nicht alle. EAP-Methoden können normalerweise nur unter bestimmten Umständen geschützte Ergebnisanzeigen bereitstellen. Beispielsweise kann ein Fehler vor der Schlüsselableitung auftreten, sodass möglicherweise nicht alle Fehleranzeigen geschützt werden können. Es ist auch möglich, dass Ergebnisanzeigen in beide Richtungen nicht unterstützt werden oder die Synchronisierung nicht in allen Betriebsmodi erreicht werden kann.

Beispielsweise authentifiziert in EAP-TLS [RFC2716] bei der Client-Authentifizierungs-Aushandlung der Server den Peer, erhält aber keine geschützte Anzeige, dass der Peer ihn authentifiziert hat. Der Peer authentifiziert hingegen den Server und weiß, ob der Server ihn authentifiziert hat. Bei der Sitzungswiederaufnahme-Aushandlung authentifiziert der Peer den Server, erhält aber keine geschützte Anzeige, dass der Server ihn authentifiziert hat. In diesem Modus authentifiziert der Server den Peer und weiß, ob der Peer ihn authentifiziert hat.