802.1X-Authentifizierungsverfahren und EAP-Typen im Überblick

Wie 802.1X und EAP funktionieren

Das 802.1X-Protokoll nutzt die folgenden drei Komponenten zur Authentifizierung:

1. Supplicant oder Peer, zum Beispiel ein Wireless-Client, der versucht, auf das Netzwerk zuzugreifen.
2. Authenticator, etwa ein Wireless Access Point (AP), der eine Anfrage initiiert, um den Supplicant zu authentifizieren.
3. Authentifizierungsserver, beispielsweise ein RADIUS-Server, der als Datenbank dient und Geräten die Verbindung mit dem Netzwerk erlaubt.

802.1X verwendet EAP für verschlüsselte Punkt-zu-Punkt-Netzwerke, um Informationen zwischen einem Supplicant und dem Authentifizierungsserver zu übertragen. Im Gegensatz zu anderen Authentifizierungsprotokollen, bei denen ein Client die Authentifizierung anfordert, ist EAP so konzipiert, dass der Authenticator die Anfrage initiiert, um einem Client Zugang zu gewähren. Der Authenticator fungiert während des gesamten Authentifizierungsvorgangs als Vermittler zwischen dem Supplicant und dem Server.

Wenn ein Authenticator eine Anfrage initiiert, gibt der Supplicant seine Identifikationsdaten an und wartet auf die Genehmigung des Authentifizierungsservers. Der Server antwortet dann dem Supplicant mit einer EAP-Anfrage und bestimmt, welche EAP-Methode das Gerät verwenden soll. Antwortet der Authentifizierungsserver mit einer erfolgreichen Authentifizierung, kann der Supplicant auf den Netzwerkport zugreifen.

EAP arbeitet normalerweise auf Layer 2 (Sicherungsschicht) des OSI-Modells und erfordert keine IP-Konnektivität über Layer 3. Wireless-Sicherheitsprotokolle, wie Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA), WPA2 und WPA3, unterstützen ebenfalls EAP.

Unternehmen können je nach Sicherheitsanforderungen, gewünschten Funktionen und Know-how der Mitarbeiter entscheiden, welchen EAP-Typ die Geräte verwenden sollen.

Nachfolgend finden Sie einige EAP-Typen, die für die Authentifizierung verwendet werden:

• EAP-Message Digest 5 (EAP-MD5).
• Lightweight EAP (LEAP).
• Protected EAP (PEAP).
• EAP-Subscriber Identity Module (EAP-SIM).
• EAP-Authentication and Key Agreement (EAP-AKA).
• EAP-Transport Layer Security (EAP-TLS).
• EAP-Microsoft Challenge Handshake Authentication Protocol (EAP-MS-CHAPv2).
• EAP-Tunneled TLS (EAP-TTLS).
• EAP-Flexible Authentication via Secure Tunneling (EAP-FAST).
• EAP-Generic Token Card (EAP-GTC).

EAP-MD5

MD5 Challenge war eines der ersten EAP-Authentifizierungsverfahren, das im Entwurf der Internet Engineering Task Force (IETF) von 1995 erwähnt und schließlich als RFC 2284 veröffentlicht wurde. EAP-MD5 ermöglicht eine Einweg-Client-Authentifizierung. Der Server sendet dem Client eine zufällige Challenge, und der Client weist seine Identität nach, indem er die Challenge und sein Passwort mit MD5 hasht.

EAP-MD5 bietet wenig Sicherheit und ist anfällig für viele Arten von Angriffen. Da jemand per Man-in-the-Middle-Angriff sowohl die Challenge als auch die Antwort sehen könnte, ist EAP-MD5 anfällig für einen Wörterbuchangriff, wenn es über ein offenes Medium genutzt wird. Aufgrund einer fehlenden Serverauthentifizierung ist das Protokoll zudem anfällig für Spoofing. Darüber hinaus kann EAP-MD5 keine Schlüssel bereitstellen. Infolgedessen ist der Einsatz von EAP-MD5 über kabelgebundene Verbindungen kein Problem. Man sollte es aber nicht über ein Wireless LAN (WLAN) nutzen.

Angesichts der Schwachstellen bei EAP-MD5 hat Microsoft die Unterstützung für diesen EAP-Typ nach der Veröffentlichung von Windows Vista eingestellt.

LEAP

Lightweight EAP, auch als EAP-Cisco Wireless bezeichnet, ermöglicht die gegenseitige Authentifizierung von Client und Server in Cisco-WLANs. Wie bei EAP-MD5 schickt ein LEAP-Server dem Client eine zufällige Challenge, die der Client nutzt, um ein gehashtes Passwort zurückzusenden. Nun verlangt der authentifizierte Client ein Passwort vom Server, woraufhin ein Schlüsselaustausch mithilfe von dynamischen WEP-Schlüsseln folgt.

Da es sich bei LEAP um ein proprietäres Protokoll handelt, kann es nur in Unternehmens-WLANs mit Cisco-APs und Cisco-kompatibler Hardware eingesetzt werden. Wie EAP-MD5 ist auch LEAP anfällig für Wörterbuchattacken. Angreifer können zahlreiche Tools verwenden, um per LEAP authentifizierte Passwörter zu knacken. Neue WLANs sollten deshalb auf LEAP verzichten. Unternehmen, die LEAP nutzen, sollten sicherstellen, dass alle Clients und Server lange, zufällige Passwörter verwenden, und sobald wie möglich auf einen robusteren EAP-Typ umsteigen.

PEAP

Protected EAP bietet gegenseitige Authentifizierung mit Serverzertifikaten, einem TLS-Tunnel und Client-Authentifizierung über diesen verschlüsselten Tunnel. Im Wesentlichen kapselt PEAP EAP mit einem TLS-Tunnel, um für eine bessere Verschlüsselung und mehr Sicherheit zu sorgen.

Cisco, Microsoft und RSA Security haben gemeinsam PEAP entwickelt, das in zwei Hauptversionen vorliegt: PEAPv0 und PEAPv1. Microsoft-Produkte unterstützen PEAPv0, Cisco-Produkte hingegen PEAPv0 und PEAPv1. Die IETF hat zwar einen PEAPv2-Entwurf veröffentlicht, aber diese PEAP-Version hat sich nicht durchgesetzt.

PEAP bietet eine äußere Authentifizierung mit dem TLS-Tunnel während des Informationsaustauschs zwischen Client und Server. Dazu muss der Client einen anderen EAP-Typ, etwa EAP-MS-CHAPv2, EAP-TLS oder EAP-GTC, für die innere Authentifizierung nutzen. Beispielsweise wird PEAPv0 im Allgemeinen mit EAP-MS-CHAPv2 kombiniert, während PEAPv1 üblicherweise mit EAP-GTC funktioniert.

Ein PEAP-Authentifizierungsserver muss sowohl EAP als auch die enthaltenen Authentifizierungsprotokolle parsen. Es ist wichtig, dass auf Clients und Servern dieselbe PEAP-Version zum Einsatz kommt.

EAP-SIM

Das 3rd Generation Partnership Project (3GPP) hat EAP-SIM entwickelt und in RFC 4186 definiert. EAP-SIM bietet eine gegenseitige Authentifizierung auf Grundlage der SIM-Karte, die in Geräten von Carriern mit GSM-Netzen (Global System for Mobile Communications) zu finden ist. Eine SIM kann ein kleiner Chip sein, der in ein Mobiltelefon, eine Mobilfunk-Datenkarte oder einen USB-Stick eingesetzt wird. Diese Smartcard implementiert den Authentifizierungsalgorithmus, der normalerweise von Mobilfunkgeräten zur Authentifizierung bei GSM-Netzen verwendet wird.

802.1X-Anfragen mit EAP-SIM werden über das Roaming Gateway des Carriers an einen GSM-Authentifizierungsserver weitergeleitet. Dieser EAP-Typ lässt sich nutzen, um Geräte wie Smartphones zu authentifizieren, die zwischen kommerziellen 802.11-Hotspots und GSM-Netzen wechseln.

EAP-AKA

Das 3GPP hat das EAP-AKA-Protokoll im Rahmen von IETF RFC 4187 entwickelt. Das Protokoll wird für die Kommunikation zwischen einem Identitätsmodul, zum Beispiel USIM (Zusammensetzung aus Universal Mobile Telecommunications System (UMTS) und SIM), in einem mobilen Gerät oder einer Smartcard und der Netzwerkinfrastruktur eines Betreibers verwendet. Die beiden Entitäten nutzen festgelegte geheime Schlüssel, um Verifikationsinformationen auszutauschen und die Authentifizierung zu bestätigen.

Mit der Weiterentwicklung der Mobilfunknetze verwenden die Betreiber in der Regel verschiedene Generationen von Standards, um ihre Netzwerkinfrastruktur aufzubauen. Ein Mobilfunkbetreiber kann beispielsweise über ein Netzwerk der zweiten Generation verfügen, das auf dem GSM-Standard basiert. Ein anderer Betreiber verwendet vielleicht ein UMTS-Netz der dritten Generation oder ein LTE-Netz der vierten Generation.

Diese Generationen erfordern auch unterschiedliche EAP-Typen. GSM-Netze, die auf SIM- statt auf USIM-Karten basieren, nutzen typischerweise EAP-SIM zur Authentifizierung. Andere Carrier mit UMTS- oder LTE-Netzen können dagegen EAP-AKA einsetzen, da es USIMs unterstützt, die von Geräten in diesen Netzwerken genutzt werden. Obwohl das Netzwerk des Carriers bestimmt, welchen EAP-Typ ein Smartphone verwenden muss, gelten die von EAP-AKA genutzten permanenten Authentifizierungsschlüssel als stärker als die abgeleiteten Authentifizierungsschlüssel von EAP-SIM.

Die IETF hat in RFC 5448 eine aktualisierte Version von EAP-AKA definiert, die als EAP-AKA' bezeichnet wird, um die Interoperabilität zwischen Mobilfunknetzen mit und ohne 3GPP zu unterstützen. EAP-AKA' sorgt für eine zusätzliche Sicherheitsebene, indem es die Art und Weise, wie Sitzungsschlüssel generiert werden, verbessert und den Secure Hash Algorithm-256 anstelle von SHA-1 verwendet.

Im Zuge der Entwicklung von 5G hat sich die IETF auf eine Erweiterung von EAP-AKA' konzentriert. Diese ist unter der Bezeichnung EAP-AKA-Perfect Forward Secrecy (EAP-AKA'-PFS) bekannt und wurde in RFC 9048 (Entwurfsstatus) definiert. EAP-AKA'-PFS soll eine bessere Unterstützung für 5G-Netze bieten und gleichzeitig Perfect Forward Secrecy ermöglichen, um Angreifer daran zu hindern, auf Pre-Shared Keys zuzugreifen und alte Daten zu entschlüsseln.

EAP-TLS

Das EAP-TLS-Protokoll ist in RFC 5216 definiert. Es bietet eine gegenseitige digitale Zertifikatsauthentifizierung zwischen Client und Server unter Verwendung des TLS-Protokolls, um die Daten zu schützen. Ein digitales Zertifikat verifiziert die Identität einer Entität und weist nach, dass es im Besitz eines öffentlichen Schlüssels ist. Die meisten Unternehmen erhalten digitale Zertifikate für ihre Clients und Server von einer Zertifizierungsstelle. Hierbei handelt es sich um einen unabhängigen Dritten, der für die Ausstellung und Verwaltung von Zertifikaten zuständig ist.

Der EAP-Server weist per TLS nach, dass er im Besitz eines digitalen Zertifikats ist, und verlangt dasselbe vom Client. Der Client beweist nun anhand seines Zertifikats seine Identität, und dann tauschen die beiden Entitäten Schlüssel aus. Der TLS-Tunnel endet nach Abschluss der Authentifizierung. Doch die über EAP-TLS ausgetauschten Schlüssel lassen sich nutzen, um Daten per Advanced Encryption Standard (AES), Temporal Key Integrity Protocol oder WEP zu verschlüsseln.

EAP-TLS gilt gemeinhin als der robusteste EAP-Typ, ist aber am teuersten in der Bereitstellung, da es für die Authentifizierung keine Anmeldedaten, sondern Zertifikate benötigt. Das Protokoll eignet sich gut für WLANs, in denen Clients bereits über digitale Zertifikate verfügen oder in denen hohe Sicherheitsanforderungen die Investition in eine Public-Key-Infrastruktur (PKI) zur Verwaltung dieser Zertifikate rechtfertigt.

EAP-MS-CHAPv2

EAP-MS-CHAPv2 verpackt Microsoft-CHAP in EAP. Dieser EAP-Typ lässt sich auch innerhalb des von PEAP erzeugten TLS-Tunnels verwenden, der PEAP-MS-CHAPv2 genannt wird.

EAP-MS-CHAPv2 nutzt gegenseitige Authentifizierung und Schlüsselableitung entsprechend dem traditionellen Challenge-, Response- und Authentifizierungsprozess zwischen Client, Authenticator und Authentifizierungsserver. Es verlangt ein Zertifikat des Authentifizierungsservers, aber nur ein Passwort für Clients. Daher ist das Protokoll anfälliger für Schwachstellen wie Wörterbuch-, Evil-Twin- und Man-in-the-Middle-Angriffe.

Das Protokoll eignet sich gut für Unternehmen, die Microsoft-Anmeldedaten und -Server, wie Active Directory, für die Wireless-Authentifizierung wiederverwenden möchten. Fachleute empfehlen jedoch den Wechsel zu einem sichereren EAP-Typ, zum Beispiel EAP-TLS.

EAP-TTLS

EAP-TTLS, definiert in RFC 5281, kapselt den Datenaustausch zwischen Client und Server mit TLS. Das Protokoll erfordert, dass sich der Server durch ein Zertifikat authentifiziert und einen TLS-Tunnel aufbaut, über den die Challenge an den Client erfolgt. Im Gegensatz zu EAP-TLS, das sowohl digitale Server- als auch Clientzertifikate verwendet, müssen Clients bei EAP-TTLS mit Passwörtern antworten, die durch den TLS-Tunnel verborgen werden.

EAP-TTLS bietet ein ausgewogenes Verhältnis zwischen Sicherheit und Bereitstellungskosten, indem es clientseitige Zertifikate durch ältere Methoden zur Passwortauthentifizierung ersetzt, wie das Password Authentication Protocol (PAP), CHAP und MS-CHAPv2. Obwohl das EAP-Verfahren aufgrund seiner auf Anmeldeinformationen basierenden Clientauthentifizierung immer noch anfällig für Angriffe ist, erhöht die TLS-Verschlüsselung die Sicherheit während die Anmeldeinformationen ausgetauscht werden.

Um den Namen des Clients geheim zu halten, sollte EAP-TTLS so konfiguriert werden, dass beim Start von 802.1X eine anonyme Identität und dann die tatsächliche Identität durch den TLS-Tunnel übermittelt wird. Dieser Tunnel endet, wenn die Authentifizierung abgeschlossen ist und die Schlüssel ausgetauscht wurden.

EAP-TTLS eignet sich für WLANs, die vorhandene Legacy-Datenbanken für die Benutzerauthentifizierung auf sichere Weise verwenden. Das Protokoll ähnelt PEAP, nutzt aber andere Protokolle zur Client-Authentifizierung. Wie PEAP bietet es gegenseitige Authentifizierung und verwendet Serverzertifikate sowie einen TLS-Tunnel, um den Client zu authentifizieren.

EAP-FAST

Cisco hat EAP-FAST, das unter RFC 5422 zu finden ist, als Ersatz für LEAP entwickelt. Wie PEAP und EAP-TTLS bietet auch FAST TLS-Tunnel für die gegenseitige Authentifizierung. Bei EAP-FAST ist es jedoch optional, dass sich Server mit einem digitalen Zertifikat authentifizieren, während Clients Anmeldedaten austauschen. Stattdessen wird bei einem einmaligen Austausch ein gemeinsames Geheimnis, ein sogenannter PAC-Schlüssel (Protected Access Credential), festgelegt. Dieser PAC-Schlüssel kommt für alle nachfolgenden Authentifizierungen zum Einsatz.

EAP-FAST ist für kleinere Clients gedacht, bei denen die Überprüfung digitaler Zertifikatsignaturen viel zu lange dauern würde. Es handelt sich hierbei um ein proprietäres Protokoll von Cisco, aber Unternehmen können ein Cisco-Modul erwerben, um EAP-FAST unter Windows zu nutzen. Auch Apple-Geräte unterstützen EAS-FAST.

EAP-GTC

EAP-GTC, das erstmals in RFC 2284 definiert wurde, ist eine innere Authentifizierungsmethode mit einem Sicherheits-Token. Das Protokoll wird häufig in einem TLS-Tunnel verwendet, der von PEAP (genauer gesagt von PEAPv1/EAP-GTC) erstellt wird. EAP-GTC legt einen EAP-Umschlag für die Übertragung von Einmalpasswörtern fest, die von Token-Karten generiert werden, und verlangt vom Server, sich mit einem Zertifikat zu authentifizieren.

EAP-GTC eignet sich gut für Unternehmen, die eine Zwei-Faktor-Authentifizierung verwenden, um typische Kompromittierungen von Passwörtern zu vermeiden, beispielsweise gemeinsam genutzte Passwörter oder unzureichende Passworthygiene.

Überprüfung der EAP-Kompatibilität

Netzwerkteams sollten sich genauestens informieren, welche EAP-Typen ihre Produkte unterstützen. Wer mit Multivendor-WLANs arbeitet, sollte gewährleisten, dass seine Geräte kompatible EAP-Typen nutzen.

Unternehmen, die sich für die Verwendung von EAP-Typen auf Grundlage von Anmeldedaten entscheiden, sollten sicherstellen, dass ihre Mitarbeiter und Geräte eine angemessene Passworthygiene einhalten. Organisationen hingegen, die sich für digitale Zertifizierungsverfahren entscheiden, sollten die installierten Zertifikate sorgfältig dokumentieren und die Systeme auf dem neuesten Stand halten.