Zur Webansicht Zur Webansicht
0/1 Rechenzentrum der Universität Regensburg
Home Uni  Pfeil  Rechenzentrum  Pfeil  
Deko-Banner
Zur Lese-/Druckansicht  


Frequently Used Links:
Hauptnavigation:

Netzwerkzugangskontrolle mittels 802.1x

Dieses Dokument beschreibt, wie eine 802.1x Authentisierung in einem 802.11i WLAN realisiert werden kann.

Der IEEE Standard 802.1x bietet die Möglichkeit, den Zugang zum Datennetz (egal ob kabelgebunden oder per WLAN) zu kontrollieren: bevor ein Benutzer über einen Rechner Zugang zum Datennetz bekommt, muß er sich am Netzwerk authentisieren. Der Authentisierung kann dabei benutzer- oder maschinenbezogen erfolgen. Erst nach erfolgreicher Authentisierung wird der Zugang zum Netzwerk vom Authenticator freigegeben. Mit der Authentisierung können dem Benutzer bzw. Rechner (falls die Netzhardware dies unterstützt) auch bestimmte Netzwerkresourcen wie z.B. Bandbreite, Filterregeln, VLAN Zugehörigkeiten, etc. zugeordnet werden (user personalized network, policy based network).


Der Detailablauf ist wie folgt:
  • Wenn ein Client (Supplicant) sich mit dem Netzwerk verbindet (Link up oder Verbindungsaufbau zum Accesspoint) frägt der Switch bzw. Accesspoint (Authenticator) nach der Identität des Clients. Zu diesem Zeitpunkt ist nur eine Kommunikation zwischen Client und Switch bzw. Accesspoint möglich. Der Zugang zum eigentlichen Netzwerk ist noch gesperrt. Die Kommunikation zwischen Client und Switch erfolgt über das EAPoL (EAP over LAN) Protokoll, das auf der LLC Ebene (der Client hat zu diesem Zeitpunkt ja noch keine IP Adresse) erfolgt.
  • Der Authentisierung zugrunde liegt das EAP (extensible authentication protocol) Protokoll. EAP ist ein universelles Protokoll für viele verschiedene Authentisierungsverfahren. Das EAP Protokoll selbst führt keinerlei Authentisierung durch; es dient nur dazu, einen standardisierten Authentisierungsvorgang zwischen dem Client und einem Radius Authentisierungsserver zu ermöglichen: welches Authentisierungsverfahren verwendet werden soll (PAP, CHAP, msCHAP-v2, TLS, PEAP, TTLS mit Subvarianten etc.), können der Client und der Authentisierungsserver vor der Durchführung der eigentlichen Authentisierung aushandeln. Der Authenticator (Switch oder Accesspoint) ist nur soweit an diesem Vorgang beteiligt, daß er die EAPoL Nachrichten des Clients in Radiusanfragen (Radius Attribut/Value Paare mit Hashberechnungen für Passwörter und Paketidentifikatoren) an die Radius Authentisierungsserver weiterleitet und umgekehrt.
  • Nach erfolgreicher Authentisierung öffnet der Authenticator dann den Netzzugang und der Client kann seinen normalen Netzstart (DHCP Anfragen, Netzwerklogins etc.) ausführen. Zudem können über Radius Replyattribute - falls der Authenticator das unterstützt - dem Benutzer bzw. Client bestimmte Netzwerkresourcen (Bandbreite, VLAN, Filter etc.) zugeteilt werden. Verwendet man TLS, TTLS oder PEAP als Authentisierungsverfahren, fällt für den WLAN Zugang unter 802.11i als Nebenprodukt der Masterkey für den dynamischen Schlüsselaustausch zwischen dem Client und dem Accesspoint ab.

Vergleich der wichtigsten Authentisierungsverfahren

  • EAP-TLS (Transport Layer Security): Es wird eine verschlüsselte TLS Verbindung innerhalb EAP zwischen Client und Radiusserver aufgebaut. Sowohl Radiusserver als auch Client benötigen ein gültiges digitales von einer CA unterschriebenes Zertifikat, das sie gegenseitig überprüfen müssen. Ist die beidseitige Authentisierung erfolgreich, wird der Zugang freigegeben. Da jeder Client ein Zertifikat benötigt, muß eine PKI Struktur vorhanden sein. User Passwörter sind in diesem Fall nicht erforderlich.
  • EAP-TTLS (Tunneled Transport Layer Security): Hier wird zunächst ein verschlüsselter TLS Kanal zwischen Client und Radiusserver aufgebaut. Dazu identifiert sich nur der Radiusserver mit einem von einer CA unterschriebenen Zertifikat beim Client. In diesem sicheren Tunnel kann sich nun ein Benutzer über verschiedene andere Verfahren authentisieren. Möglichkeiten sind PAP (Passwort im Klartext), CHAP (Hashbildung aus Challenge, Sessionkey und Klartextpasswort) bzw. MSCHAPv1/v2 (Hashbildung aus Challenge, Sessionkey und MD4 Hash des Passworts). Vorteil dieses Verfahrens ist, daß nur der Radiusserver ein Zertifikat benötigt. Es muß somit keine PKI Struktur vorhanden sein. Außerdem unterstützt dieses Verfahren die meisten Authentisierungsprotokolle. Nachteil ist, dass das Verfahren nicht von Windows unterstützt wird. Es sind dort additive Clients nötig.
  • EAP-PEAP (Protected EAP)Wie bei EAP-TTLS wird zunächst ein verschlüsselter TLS Kanal zwischen Client und Radiusserver aufgebaut. Auch hier identifiert sich nur der Radiusserver mit einem von einer CA unterschriebenen Zertifikat beim Client. Dieser TLS Tunnel wird nun benutzt, um eine weitere EAP Verbindung mit den möglichen EAP Authentisierungstypen aufzubauen, wobei zur Zeit eigentlich nur MSCHAPv2 zur Verfügung steht. Vorteil dieses Verfahrens ist auch hier, daß nur der Radiusserver ein Zertifikat benötigt. Es muß somit keine PKI Struktur vorhanden sein. Zusätzlich wird das Verfahren von Windows XP, Vista und 7 sowie MacOS und Linux unterstützt.

An der Universität war lange Zeit EAP-TTLS/PAP im Einsatz. Allerdings wird das Verfahren nicht von Windows nativ unterstützt. Es sind additive EAP-TTLS Clientprogramme für Windows erforderlich, z.B. SecureW2 (open source, verfügbar für Windows 2000 und XP, Windows Pocket PC 2003 und Windows Mobile 2003 SE) oder Odyssey (kostenpflichtiger Client von Funk Software) bzw. AEGIS (kostenpflichtiger Client von Meetinghouse). Für Linux steht Open1x/XSupplicant als open source Client kostenlos zur Verfügung. Da nun auch Clients wie SecureW2 kostenpflichtig sind, hat sich das Rechenzentrum dazu entschieden, zusätzlich zu EAP-TTLS/PAP auch EAP-PEAP mit MSCHAPv2 zu unterstützen. Dieses Verfahren wird von allen gängigen modernen Betriebssystemen nativ unterstützt.

Letzte Änderung: 24.11.2017 von Dr. Ulrich Werling