802.1X

Ein WLAN-Client muss authentifiziert werden, bevor er auf weitere LAN-Ressourcen zugreifen darf.

Gliederung des Standards im IEEE Modell

IEEE 802.1X ist ein Standard zur Authentifizierung in Rechnernetzen.

Der Standard IEEE 802.1X stellt eine generelle Methode für die Authentifizierung und Autorisierung in IEEE 802-Netzen zur Verfügung. Am Netzwerkzugang, einem physikalischen Port im LAN, einem logischen IEEE 802.1Q VLAN oder einem WLAN, erfolgt die Authentifizierung eines Teilnehmers durch den Authenticator, der mittels eines Authentifizierungsservers (RADIUS-Server) die durch den Teilnehmer (Supplikant) übermittelten Authentifizierungsinformationen prüft und gegebenenfalls den Zugriff auf die durch den Authenticator angebotenen Dienste (LAN, VLAN oder WLAN) zulässt oder abweist. Bei der Schreibweise ist laut IEEE ein Großbuchstabe zu verwenden, da IEEE 802.1X ein allein stehender Standard ist und keine Ergänzung eines bestehenden Standards.

Durch diese Möglichkeit der Nutzung eines Authentifizierungsservers kann auch lokal unbekannten Teilnehmern der Netzzugang ermöglicht werden. Zum Beispiel können Angehörige vieler Hochschulen mittels eduroam an anderen Hochschulen WLAN nutzen, ohne dass dort ein für jedermann offener Gastzugang oder ähnliches eingerichtet werden muss.

Der Standard empfiehlt das Extensible Authentication Protocol (EAP) oder das PPP-EAP-TLS Authentication Protocol zur Authentifizierung, da keine eigenen Authentisierungsprotokolle definiert werden.

Supplicant

Supplicants (deutsch Bittsteller) sind alle IEEE 802.1X-authentifizierfähigen Geräte (s. IEEE 802.1X Artikel 5.1 „Requirements“), die sich gemäß Netzwerkpolitik am Netzwerk authentifizieren müssen, bevor dem Netzwerkgerät der Zugriff auf die Ressourcen des Netzwerks erlaubt wird. In der Praxis wird der Supplicant in Form einer Softwareimplementierung umgesetzt. Beispielsweise unterstützt Windows XP (inkl. SP2) eine Supplicantimplementierung nativ. Weiterhin kann man sich auch der freien Supplicantimplementierungen aus den Projekten von Open1x oder SecureW2 bedienen um eine IEEE 802.1X Infrastruktur aufzubauen. Nicht alle Netzwerkkomponenten (wie z. B. Netzwerkdrucker) sind jedoch in der Lage, sich über IEEE 802.1X am Netzwerk zu authentifizieren. Oft fehlt alter und sogar neuerer Hardware die IEEE 802.1X Supplicantimplementierung. Diese Tatsache stellt bei der Einführung von IEEE 802.1X in Produktivsystemen den größten Kritikpunkt an IEEE 802.1X dar. Einige Switches stellen für dieses Problem z. B. die „MAC-Bypass“-Funktion bereit. Damit ist es möglich, das Netzwerkgerät anhand der MAC-Adresse zu authentifizieren. Somit können auch Geräte authentifiziert werden, die keine IEEE 802.1X Supplicantimplementierung besitzen.

Authenticator

Zwischen dem Supplicant und dem zu schützenden Netzwerk existiert der Authenticator. Die Rolle des Authenticators ist es, die Authentizität des Supplicants zu überprüfen, ähnlich der Rolle eines Türstehers im Rahmen einer Ausweiskontrolle. Kann sich der Supplicant gegenüber dem Authenticator erfolgreich mit gültigen Credentials (zu dt. „Berechtigungsnachweis“ oder „Legitimation“) ausweisen, wird dem Supplicant der Zugriff auf das Netzwerk durch den Authenticator gewährt. Schlägt die Authentifizierung fehl, wird der Zugriff verweigert. Der Authenticator kann in der Praxis ein IEEE 802.1X fähiger Switch, Router oder IEEE 802.11 WLAN Access Point sein. Die Credentials werden i.d.R. von dem Authenticator bei einem „Authentication Server“ angefragt. Der Authentication-Server findet sich im IEEE 802.1X Modell in einem vertrauenswürdigem Netzwerk wieder.

Port Access Entity: PAE

Die PAE, welche in der Praxis als Port am Switch vorgestellt werden kann, implementiert hierbei einen Zustandsautomaten, indem immer der jeweilige Authentifizierungszustand zwischen Supplicant und Authenticator am kontrollierten Port abgebildet ist. Der IEEE 802.1X sieht für die Zugriffseinstellung im PAE 3 mögliche Zugriffsmodi für Supplicants vor:

• ForceUnauthorized: Der kontrollierte Port ist im Modus „nicht bevollmächtigt“. Dabei wird jeder Zugriff vom Supplicant geblockt. Es ist egal ob sich der Supplicant erfolgreich authentifizieren kann oder nicht, in jedem Fall wird der Zugriff gesperrt.
• ForceAuthorized: Das Gegenteil von ForceUnauthorized. Der kontrollierte Port ist im Modus „autorisiert“. Dabei wird dem Supplicant der Zugriff immer gewährt. Es ist nicht wichtig, ob sich der Supplicant gegenüber dem Authenticator authentifizieren kann, in jedem Fall wird der Zugriff gestattet. Dieser Modus ist für die praktische Einrichtung von IEEE 802.1X Switchen interessant. Mit der Aktivierung der IEEE 802.1X Authentifizierung in Verbindung mit dem ForceAuthorized Modus ist z. B. eine sukzessive Aktivierung von IEEE 802.1X möglich. Im ForceAuthorized Modus können z. B. am Switch interne Tests zur IEEE 802.1X Funktionstauglichkeit vorgenommen werden, bevor anschließend der produktive „Auto“ Modus aktiviert wird, der alle Supplicants zum Authentifizieren zwingt.
• Auto: Verlangt eine erfolgreiche Authentifizierung von dem Supplicant. Wenn sich der Supplicant erfolgreich authentifiziert hat, wird der Zugriff gewährt, andernfalls bleibt er weiterhin gesperrt.

(Definition aus dem IEEE Standard [1], Kapitel 8.2.2.2, Global variables, Seite 46, Definition p) 1 bis 3)

Die PAE kann eine Supplicant- oder Authenticatorfunktionalität annehmen.

Authentication Server (AS)

Der AS stellt dem Authenticator einen Authentifizierungsdienst bereit. Dabei ist der AS in der Regel im geschützten Netz installiert und muss sich nicht authentifizieren. Der AS kann in der Praxis ein RADIUS Serverdienst sein, wie es z. B. das FreeRadius Projekt frei bereitstellt. Werden die Betriebssysteme Windows 2000 oder Windows 2003 genutzt, so kann mit dem Internet Access Service (IAS) ein RADIUS Server betrieben werden. Jeder größere Hersteller von Switchen und Routern stellt auch eine eigene RADIUS Implementierung bereit, hier sei auf das Produktangebot der jeweiligen Hersteller verwiesen.

Die zu überprüfenden Credentials können direkt auf dem AS liegen, in Form einer „Flatfile“ (ASCII Datei), der AS kann aber auch durch Datenbanktreiber auf einen Datenbankdienst zugreifen. Die Backendmöglichkeiten sind in der Theorie für einen AS unbegrenzt. In der Praxis wird einer LDAP Anbindung oft der Vorzug gegeben. Der Vorteil liegt auf der Hand: Bestehende Domänenbenutzerkennungen sind im Active Directory Service (ADS) von Microsoft Betriebssystemen bereits vorhanden. Im Fall von freien LDAP Implementierungen kann es auch der OpenLDAP3 Dienst sein, der sich für einen LDAP Betrieb eignet. Die vielfältigen Backendmöglichkeiten vom RADIUS Server sind somit auch Vorteile für den Einsatz von IEEE 802.1X. An diesem Beispiel ist gut zu erkennen, dass der IEEE 802.1X Standard auf vorhandenen Schnittstellen aufsetzt und somit bemüht ist praxistauglich zu sein.

Im Kontext der RADIUS Terminologie wird statt dem Begriff Authenticator, der Begriff Network Access Server (NAS) verwendet. Einwählende Computer betrachten den NAS als Server. Aus der Sicht des RADIUS-Servers, ist der NAS hingegen ein Client.

Das Dienstspektrum und die Benutzerkennung (Zuordnung des VLANs)

Einen großen Vorteil bei der Nutzung von IEEE 802.1X bilden die RADIUS Access-Accept Nachrichten vom AS zum Authenticator. Das RADIUS Extensions RFC 2869 beschreibt eine große Menge an Attributen, die vom AS an den Authenticator gesendet werden. Drei interessante Attribute heißen hierbei „Tunnel-Type“, „Tunnel-Medium-Type“ und „Tunnel-Private-Group-Id“. Am Ende der RADIUS Authentifizierung sendet der RADIUS Server an den NAS eine Access-Accept Nachricht. Werden diese drei Attribute an die Access-Accept-Nachricht angehangen, wird damit vom NAS gefordert, den Supplicant in das betreffende VLAN zu zuweisen. Die VLAN-ID steht hierbei genau im Attribut „Tunnel-Private-Group-Id“ des Antwortpakets. Der NAS schaltet hierbei den Port vom Gast-VLAN in das für den Supplicant bestimmte VLAN um. Für die Praxis bedeutet es, dass anhand der Benutzerinformationen, die der Authenticator an den AS sendet, im Gegenzug ein angepasstes Dienstspektrum für den Supplicant stattfinden kann. Auf Linux, BSD- oder Windowsservern ist es heute relativ leicht mehrere VLANs umzusetzen und damit je im VLAN eine Auswahl an Diensten bereitzustellen.

Betriebssysteme mit IEEE 802.1X Unterstützung

• Microsoft
  • Windows 2000 mit Patch
  • Windows XP
  • Windows CE/Pocket PC
  • Windows Server 2003
  • Windows Server 2008
  • Windows Vista
• BSD basierte
  • FreeBSD
  • NetBSD
  • Mac OS X Panther (Mac OS X > 10.3)
• Linux

Bei anderen Betriebssystemen sollte eine Third-Party-Software installiert werden, um die Funktion nutzen zu können. Das Open1x-Projekt hat sich zum Ziel gesetzt, mit einer eigenen 802.1X-Implementierung viele Systeme zu unterstützen. Des Weiteren ist es möglich, Netzwerkkomponenten zu verwenden, die eine webbasierte Authentifizierung gestatten.

Siehe auch: Port Based Network Access Control

Weblinks

• IEEE 802.1X-2004.pdf Der IEEE 802.1X Standard in der Version 2004 (PDF)
• IEEE 802.1X Arbeitsgruppe Offizielle Seite der 1X Arbeitsgruppe
• FreeRADIUS Freie und populäre Implementierung eines RADIUS-Servers
• daloRADIUS Freie und webbasierte Software auf der Basis des FreeRADIUS Servers und einer SQL-Datenbankanbindung, die das Ziel verfolgt Benutzerkennungen zu verwalten
• Einrichtung von IEEE 802.1x mit drahtgebundenen Netzen unter Verwendung von Microsoft Windows Deployment of IEEE 802.1X for Wired Networks Using Microsoft Windows
• Einrichtung der VLAN Zuordnung mit der Windows RADIUS Serverimplementierung Internet Authentication Service (IAS) Deploying Windows Server 2003 Internet Authentication Service (IAS) with Virtual Local Area Networks (VLANs)
• 802.1X Port-Based Authentication HOWTO bei The Linux Documentation Project
• Open1X Freie Supplicantimplementierung für Linux, BSD und Windows