zurück zum Artikel

Starke kryptographische Verfahren sind ein Muss für die Generation Drahtlos. Um Datenspione, Netzvandalen und Schnorrsurfer aus dem WLAN fernzuhalten, reicht auch die sichere WPA-Verschlüsselung aber auf Dauer nicht aus. Irgendwann hat sich das gemeinsame Passwort herumgesprochen. Individuelle Authentifizierung und Autorisierung sind also gefragt.

Schon lange ist bekannt, dass der bei den ersten WLAN-Hardware-Generationen eingesetzte WEP-Mechanismus unbrauchbar [1] ist. Deshalb wurde die WLAN-Verschlüsselung schnell verbessert: Die von der Herstellervereinigung Wi-Fi Alliance [2] propagierten Verfahren WPA und WPA2 (Wi-Fi Protected Access) stellen eine Untermenge des verbesserten Sicherheitsstandards IEEE 802.11i dar, der in die WLAN-Norm 802.11-2007 [3] übernommen wurde.

Allerdings hat inzwischen auch die bei WPA verwendete Verschlüsselungsmethode TKIP Schwächen [4] offenbart. Selbst bei WPA2, das auf den als sicher geltenden AES-Algorithmus setzt, ist ein Wörterbuchangriff erfolgversprechend, wenn man das von allen WLAN-Nutzern gemeinsam verwendete WPA-Passwort zu simpel wählt.

Derlei Probleme kann man bei einer WLAN-Anmeldung mit individuellen Zugangsdaten [5] (Username/Passwort-Kombination) oder per Zertifikat elegant umschiffen, was WPA2 praktischerweise unterstützt. Die Funktion heißt meist WPA2-Enterprise, WPA2-1x oder WPA2-802.1x. Sie erledigt sichere Authentifizierung beispielsweise gegen einen Radius-Server. Statt WPA2 heißt es bisweilen auch 802.11i. Dieser Beitrag gibt einen Überblick über die verschiedenen, damit möglichen Authentifizierungsmethoden.

Wozu 802.1X?

Ziel von 802.1X [6] (IEEE Standard for Local and Metropolitan Area Networks – Port-Based Network Access Control) ist, ein sicheres Authentifizierungsverfahren für Geräte in einem Netzwerk zu implementieren. Seinen Kern bildet das ursprünglich für PPP-Verbindungen entwickelte Protokoll EAP (Extensible Authentication Protocol). Ferner wird die Zuordnung von Geräten zu einem VLAN ermöglicht, um beispielsweise unterschiedliche Dienste bereitzustellen. Derzeit entsteht eine Erweiterung [7] des 2004 abgeschlossenen Standards.

Abhängig von der erfolgreichen Authentifizierung wird der Netzwerk-Zugang über einen bestimmten Port freigeschaltet. Dabei kann ein Port für den Standard ebenso gut der konkrete Anschluss an einem LAN-Switch wie auch die rein logische Assoziation eines mobilen Clients mit einem WLAN-Access-Point sein. Mitspieler eines solchen Authentifizierungssystems bei einem WLAN sind:

• der Supplicant (Antragsteller) oder Peer, ein mobiles Gerät, das Teilnehmer in einem Funknetz werden will,
• der Authenticator (Beglaubiger), ein Access Point, der als Mittelsmann zwischen Supplicant und Authentication Server agiert und
• ein Authentication Server als Dienst, der den Antrag eines Supplicants überprüft und seine Entscheidung dem Authenticator mitteilt.

Die Kommunikation zwischen Supplicant und Authenticator findet mit dem in 802.1X spezifizierten Extensible Authentication Protocol Over LAN (EAPOL) statt, die zwischen Authenticator und Authentication Server mit in Radius-Paketen gekapselten EAP-Paketen.

Extensible Authentication Protocol

Das in RFC 3748 [8] und RFC 5247 [9] beschriebene EAP stellt eine Erweiterung zum Point-to-Point-Protokoll (PPP, RFC 1661 [10]) dar, das bei Analogmodem-, ISDN- , GPRS-, UMTS- und DSL-Verbindungen zum Einsatz kommt. EAP ist aber nicht auf den Einsatz im LAN oder WAN (Internet-Zugang) beschränkt, man kann es genauso gut auch im WLAN einsetzen. EAP soll sicherstellen, dass die Nutzung einer PPP-Verbindung erst nach einer erfolgreich abgeschlossenen Authentifizierung möglich ist.

EAP ist ein recht schlichtes Protokoll: Es kennt lediglich Authentifizierungs-Requests respektive -Replies und arbeitet üblicherweise im Layer 2, auch wenn es nicht an eine bestimmte Schicht des OSI-Modells gebunden ist. Ein Authenticator fordert die Authentifizierung durch Versenden einer Anfrage an das mobile Gerät, das bei EAP Peer statt Supplicant heißt. Der Peer antwortet gemäß dem gewünschten Authentifizierungsverfahren (etwa MD5-Challenge oder One-Time Password) und wird gegebenenfalls als echt anerkannt.

Für die Verwendung im WLAN hat EAP allerdings gravierende Nachteile: Es überträgt den Nutzernamen im Klartext, was ungünstig ist, weil der Authentifizierungsprozess ja noch ohne Verschlüsselung abläuft. Außerdem muss sich der Authenticator nicht gegenüber dem Peer authentifizieren, was ein Einfallstor für Man-in-the-Middle-Angriffe öffnet. Schließlich unterstützt EAP keine dynamischen Schlüssel. Deshalb kann das ursprüngliche EAP im WLAN nicht zu mehr Sicherheit beitragen. Folglich haben sich andere, mehr oder weniger sichere Varianten durchgesetzt.

EAP-Varianten

Lightweight EAP

LEAP ist eine von Cisco Systems entworfene EAP-Variante. Zwar legt Cisco keine Details offen, aber eine ausführliche Beschreibung des Protokolls auf Basis von Netzwerkanalysen wurde in einer Mailingliste veröffentlicht [11].

Das Prinzip ist simpel: Der Peer authentifiziert sich durch einen Challenge auf Basis eines Shared Secret, das sowohl der Peer als auch der Radius-Server kennen. Umgekehrt kann der Peer die Echtheit seines Authenticators über ein digitales Zertifikat überprüfen. LEAP ist aber anfällig für Wörterbuch-Attacken, wie Cisco selbst zugibt [12].

Der von Cisco vorangetriebene LEAP-Nachfolger EAP-FAST (Flexible Authentication via Secure Tunneling, RFC 4851 [13]) adressiert die bekannten Schwachstellen, schafft aber neue Angriffsmöglichkeiten [14].

EAP mit Transport Layer Security

Gegenseitige Authentifizierung von Peer und Authenticator mit digitalen Zertifikaten und Schlüsselmanagement bringt die EAP-Erweiterung TLS (RFC 5246 [15]). TLS nutzt ein asymmetrisches Chiffrierverfahren zum Ermitteln der Sitzungsschlüssel. Zu Beginn schickt der Authenticator sein Zertifikat zusammen mit seinem öffentlichen Schlüssel (Public Key) und fordert den Peer auf, das gleiche zu tun. Der Peer antwortet entsprechend und generiert anschließend ein Premaster Secret, das er mit dem Public Key des Authenticators verschlüsselt und abschickt. Aus dem Premaster Secret leitet der Authenticator dann ein Master Secret ab, mit dem er neue Schlüssel erzeugt, die beispielsweise als dynamische Sitzungsschlüssel dienen können.

Hat der Peer das Zertifikat des Authenticators über einen sicheren Kanal erhalten oder kann er dessen Gültigkeit über ein Stammzertifikat einer Certification Authority (CA) überprüfen, dann ist diese EAP-Variante die sicherste von allen. EAP-TLS wird in RFC 5216 [16] beschrieben.

EAP mit Tunneled TLS

EAP-TTLS stellt eine Variante zu EAP-TLS dar, die bei der Überprüfung des Peers anders vorgeht. Zunächst authentifiziert sich der Authenticator durch Versenden seines Zertifikats gegenüber dem Peer. Bei erfolgreicher Authentifizierung baut Letzterer einen sicheren TLS-Tunnel zum Authenticator auf und authentifiziert sich seinerseits. Diese Authentifizierung kann sowohl mit einem Zertifikat als auch mit anderen EAP-Mechanismen (MD5-Challenge, One-Time Password) stattfinden. Wie EAP-TLS unterstützt auch EAP-TTLS das dynamische Generieren von Sitzungsschlüsseln.

Derzeit gängig ist EAP-TTLSv0 (RFC 5281 [17]). Die Variante EAP-TTLSv1 liegt bislang nur als Entwurf [18] vor. Sie verwendet die TLS-Erweiterung TLS/IA (Inner Application), mit der Authentifizierung und Parameterübergabe zwischen Client und Server innerhalb des TLS-Steuerungskanals laufen können. Bei EAP-TTLSv0 geschehen diese Dinge im Datenkanal. TLS/IA soll unter anderem die Sicherheit gegen Man-in-the-Middle-Angriffe auf Tunneled Authentication [19] verbessern.

Protected EAP

Das von Microsoft gemeinsam mit Cisco und RSA Security entwickelte PEAP existiert in mehreren Versionen, die alle noch IETF-Entwurfsstatus haben, zuletzt PEAPv2 [20]. Es kam erstmals mit Windows XP zu breitem Einsatz. Protected EAP ähnelt EAP-TTLS sehr stark: Es baut nach der Authentifizierung des Authenticators zunächst einen sicheren Kanal via TLS auf, über den sich dann der Peer gegenüber dem Authenticator authentifiziert.

Im Unterschied zu EAP-TTLS findet zur Authentifizierung des Peers jetzt eine eigene EAP-Sitzung statt, bei der die jeweils unterstützten Authentifizierungsmechanismen benutzt werden können. Auch PEAP kann dynamische Sitzungsschlüssel erzeugen.

EAP-IKEv2

Als jüngste Variante ist EAP-IKEv2 (RFC 5106 [21]) erschienen. Es nutzt das von IPsec bekannte Internet-Key-Exchange-Protokoll v2 [22] zur gegenseitigen Authentifizierung. Bisher ist nur eine prototypische Implementierung [23] bekannt.

AAA-Modell

EAPOL und AAA

EAP selbst ist ein medienunabhängiges Protokoll, es kann über beliebige Trägerprotokolle laufen. 802.1X definiert für Verwendung in verkabelten Netzwerken EAPOL (EAP over LAN), das die EAP-Pakete kapselt. Neben der Art des verwendeten Netzwerks, beispielsweise Ethernet oder Token Ring, können EAPOL-Pakete Informationen bezüglich dynamischer Sitzungsschlüssel, Initialisierungs-Vektoren für den bei WEP verwendeten RC4-Algorithmus und einen Replay Counter transportieren. Der Replay Counter verhindert durch schlichtes Hochzählen Replay-Attacken, also das Wiedereinspeisen mitgeschnittener Übertragungen. Konkrete Vorgaben zur Erzeugung und Verteilung von Schlüsseln macht EAPOL nicht, es empfiehlt lediglich, Schlüssel zu verwenden, die während der EAP-Authentifizierung generiert werden.

Obwohl Radius (Remote Access Dialin User Service) zeitlich vor dem AAA-Modell ("Triple-A") entwickelt wurde, ist es das erste AAA-basierte Protokoll. Bei AAA handelt es sich um Konzepte, die von der Authentication, Authorization and Accounting Working Group [24] der IETF entwickelt wurden. Früchte dieser Arbeit sind mehrere allgemeine und spezielle RFCs zum Thema, beispielsweise der RFC 2904 [25] (AAA Authorization Framework).

Die Aufgaben von AAA sind die Authentifizierung von Nutzern, die Autorisierung zur Nutzung bestimmter Dienste und das Accounting, also die Messung und Dokumention der Nutzung. Die üblichen Komponenten eines AAA-Systems sind:

• ein Nutzer (Client), der Dienste in Anspruch nehmen möchte,
• ein Network Access Server (NAS), der spezielle Dienste oder den Zugang zum Netz anbietet, etwa in Form eines Access Points und
• ein AAA-Server, der Informationen über die Berechtigung zur Nutzung der vom NAS bereitgestellten Dienste vorhält.

Remote Access Dialin User Service

Als letzte Komponente tritt Radius auf den Plan. Obwohl 802.1X die Verwendung eines Radius-Servers als Authentication Server nicht explizit vorschreibt, äußert der Anhang D der Spezifikation die Vermutung, dass die meisten Authenticatoren als Radius-Clients agieren – und so ist es in der Praxis auch.

Das Radius-Protokoll und seine Funktionsweise definiert der RFC 2865 [26]. Radius-Nachrichten werden auf IP-Ebene in UDP-Pakete gekapselt, die relevanten Informationen stecken in Attribute Value Pairs (AVP). Die wichtigsten Pakettypen sind Access-Request, Access-Accept und Access-Reject, sie heißen wie ihre Funktion.

Die Authentifizierung des Radius-Clients gegenüber dem Server geschieht mit einem MD5-Hashwert. Diesen errechnet der NAS aus dem Paketinhalt, einer vom Radius-Server vorgegebenen Zufallszahl und einem Shared Secret. Nutzer- und Autorisierungsinformationen kann der Radius-Server in nahezu beliebigen Formaten speichern, Textdateien, SQL-Datenbanken oder LDAP-Verzeichnissen. Dabei ermöglicht Radius die Implementierung und Verwendung beliebiger Authentifizierungsmechanismen. Der RFC geht zwar nur auf die Verwendung von PAP oder CHAP ein, aber genauso gut kann man die oben besprochenen EAP-Varianten einsetzen.

In einem 802.1X-System mit EAP-TLS baut ein mobiles Gerät, der Supplicant, eine EAP-TLS-Sitzung auf. Die Kommunikation mit dem Authenticator – dem Access Point beziehungsweise dem NAS im AAA-Modell – findet via EAPOL statt, das die EAP-TLS-Pakete kapselt. Access Point und Radius-Server sprechen via Radius miteinander, die EAP-TLS-Pakete liegen dabei in AVPs. Der Access Point fungiert als Proxy für die gekapselten EAP-TLS-Pakete und als NAS.

Dynamische Schlüssel

Ob und wie dynamische Sitzungsschlüssel zum Einsatz kommen, bestimmt der Radius-Server. Der Access Point stößt via EAPOL das Re-Keying, also Austauschen der Sitzungsschlüssel an. Für den Schlüsselwechsel beim Supplicant ist dessen Betriebssystem zuständig, man kann folglich gewöhnliche WLAN-Hardware verwenden.

Während an einem Ethernet-Hub oder in einem WLAN mit gemeinsamem WEP-Schlüssel alle Teilnehmer den Datenverkehr aller anderen Teilnehmer mitlesen können, ist das bei dynamischen Schlüsseln ausgeschlossen. Jeder Client erhält einen individuellen Schlüssel, der den für ihn gedachten oder von ihm kommenden Datenverkehr schützt.

Da aber kein Netz ohne Broadcasts – Nachrichten an alle – funktioniert, gibt es neben dem privaten Unicast-Schlüssel auch einen Broadcast-Schlüssel. Welcher jeweils zum Einsatz kommt, hängt von der Empfänger-Adresse ab. Broad- und Unicast-Schlüssel werden direkt auf der WLAN-Karte vorgehalten, wobei der WLAN-Standard IEEE 802.11 ein Array für vier Schlüssel vorsieht.

Die hier beschriebenen Verfahren sind natürlich nicht nur im WLAN nutzbar, sie lassen sich problemlos auf kabelgebundene Netze übertragen. Ob eine bestimmte EAP-Konstellation verwendet werden kann, hängt von der 802.1X-Unterstützung des Betriebssystems ab. Windows unterstützt dies ab Windows XP, Mac OS ab Version 10.3 und bei halbwegs aktuellen Linux-Distributionen kümmert sich der Gnome-NetworkManager im Zusammenspiel mit dem wpa_supplicant [27] aus dem hostap-Projekt darum. (ea [28])

URL dieses Artikels:
https://www.heise.de/-979513

Links in diesem Artikel:
[1] http://www.heise.de/security/artikel/Dammbruch-bei-WEP-270672.html
[2] http://www.wi-fi.org/
[3] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
[4] http://www.heise.de/security/meldung/Angriff-auf-WPA-verfeinert-753357.html
[5] https://www.heise.de/ratgeber/WLAN-sichern-mit-Radius-1075339.html
[6] http://standards.ieee.org/getieee802/download/802.1X-2004.pdf
[7] http://www.ieee802.org/1/pages/802.1x-2010.html
[8] http://www.heise.de/netze/rfc/rfcs/rfc3748.shtml
[9] http://www.heise.de/netze/rfc/rfcs/rfc5247.shtml
[10] http://www.heise.de/netze/rfc/rfcs/rfc1661.shtml
[11] http://lists.cistron.nl/pipermail/cistron-Radius/2001-September/002042.html
[12] http://www.cisco.com/en/US/tech/tk722/tk809/technologies_security_notice09186a00801aa80f.html
[13] http://www.heise.de/netze/rfc/rfcs/rfc4851.shtml
[14] http://www.securityfocus.com/archive/137/505385/30/30/
[15] http://www.heise.de/netze/rfc/rfcs/rfc5246.shtml
[16] http://www.heise.de/netze/rfc/rfcs/rfc5216.shtml
[17] http://www.heise.de/netze/rfc/rfcs/rfc5281.shtml
[18] http://tools.ietf.org/html/draft-funk-eap-ttls-v1-00
[19] http://www.saunalahti.fi/~asokan/research/mitm.html
[20] http://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-10
[21] http://www.heise.de/netze/rfc/rfcs/rfc5106.shtml
[22] http://www.heise.de/security/artikel/Einfacher-VPN-Tunnelbau-dank-IKEv2-270056.html
[23] http://eap-ikev2.sourceforge.net/
[24] http://www.ietf.org/html.charters/aaa-charter.html
[25] http://www.heise.de/netze/rfc/rfcs/rfc2904.shtml
[26] http://www.heise.de/netze/rfc/rfcs/rfc2865.shtml
[27] http://hostap.epitest.fi/wpa_supplicant/
[28] mailto:ea@ct.de

Copyright © 2010 Heise Medien