Extensible Authentication Protocol
Abkürzung: EAP
Das ist der Punkt, an dem die meisten Missverständnisse beginnen. Die Frage „ist EAP sicher" lässt sich nicht beantworten — sicher oder unsicher ist das Verfahren, das darin läuft.
Entworfen wurde EAP ursprünglich für Einwahlverbindungen, um das Protokoll von der Prüfmethode zu entkoppeln. Ein neues Verfahren sollte eingeführt werden können, ohne den Transport anzufassen. Dieser Gedanke hat sich bewährt und trägt heute die Anmeldung in Unternehmens-WLANs.
Der Nachrichtenwechsel
EAP kennt nur vier Nachrichtentypen: Request vom Prüfenden, Response vom Gerät, dann Success oder Failure.
Ein Durchlauf beginnt mit der Frage nach der Identität und geht danach in das ausgehandelte Verfahren über — bei zertifikatsbasierten Methoden über ein gutes Dutzend Runden, weil ein ganzer TLS-Handshake durch diese kleinen Nachrichten geschleust wird.
Wo EAP läuft
EAP hat keinen eigenen Transport, sondern wird eingebettet:
| Trägerprotokoll | Zusammenhang |
|---|---|
| EAPOL | EAP über das lokale Netz, bei 802.1X zwischen Gerät und Switch |
| RADIUS | als Attribut EAP-Message zwischen Switch und Server |
| PPP | die ursprüngliche Heimat |
| IKEv2 | zur Teilnehmerauthentifizierung im VPN-Aufbau |
Bemerkenswert daran: Der Switch in der Mitte reicht die Nachrichten durch, ohne das Verfahren zu kennen. Wer EAP-TLS einführen will, muss den Switch nicht anfassen — nur Gerät und Server.
Die wichtigsten Verfahren
| Verfahren | Nachweis des Geräts | Serverzertifikat |
|---|---|---|
| EAP-TLS | Zertifikat | ja |
| PEAP | Kennwort im Tunnel | ja |
| EAP-TTLS | Kennwort oder anderes im Tunnel | ja |
| EAP-PWD | Kennwort, ohne Zertifikate | nein |
| EAP-SIM, EAP-AKA | SIM-Karte | nein |
| EAP-MD5 | Kennwort, ungeschützt | nein |
EAP-TLS ist das stärkste Verfahren: Beide Seiten weisen sich mit Zertifikaten aus, es gibt kein Kennwort, das abgefangen werden könnte. Der Preis ist eine Zertifikatsverwaltung für jedes Endgerät — dasselbe Betriebsproblem wie bei mTLS.
EAP-MD5 sollte nirgends mehr vorkommen. Es prüft nur das Gerät, nicht den Server, überträgt keinen Schlüssel für die weitere Sitzung und ist gegen Wörterbuchangriffe offen.
Der Tunnelgedanke
PEAP und EAP-TTLS lösen dasselbe Problem auf demselben Weg. Sie bauen zunächst einen TLS-Tunnel zum Server auf, bei dem sich nur der Server ausweist — und führen die eigentliche Prüfung des Nutzers erst darin durch.
Das hat zwei Wirkungen. Das Kennwortverfahren im Inneren wird geschützt, auch wenn es für sich genommen schwach wäre. Und die Identität bleibt verborgen: Nach außen steht eine anonyme äußere Identität, der echte Benutzername liegt im Tunnel.
Wer in einer Client-Konfiguration zwei Felder für die Identität sieht, sieht genau diese Trennung.
Die eigentliche Schwachstelle
Sie liegt nicht im Verfahren, sondern in seiner Einrichtung: Prüft der Client das Serverzertifikat nicht, ist der Tunnel wertlos.
Ein Angreifer stellt dann einen eigenen Access Point mit demselben Netznamen auf, nimmt die Anmeldung entgegen und baut den Tunnel zu sich selbst. Der Client meldet sich bereitwillig an und übergibt die Zugangsdaten — bei PEAP mit MSCHAPv2 in einer Form, aus der sich das Kennwort offline zurückrechnen lässt.
Darum gehören zu jeder Einrichtung drei Angaben, und zwar vorgegeben statt vom Nutzer bestätigt: die Zertifizierungsstelle, der erwartete Servername und die Weigerung, bei Abweichung fortzufahren. Fragt ein Gerät beim ersten Verbinden, ob man dem Zertifikat vertrauen möchte, ist die Konfiguration unvollständig — genau an dieser Stelle klicken Nutzer alles weg.
EAP-TLS mit TLS 1.3
RFC 9190 passt EAP-TLS an TLS 1.3 an. Der Gewinn ist derselbe wie dort: weniger Umläufe, keine veralteten Verfahren, und die Identität des Clients wandert in den verschlüsselten Teil des Handshakes — bei EAP-TLS mit älteren Versionen ging das Clientzertifikat im Klartext über die Leitung.