Rechnernetze

Sicherheit durch IEEE 802.1X

Aufgrund der Schwächen der in IEEE 802.11 eingeführten Authentifizierung, war es nötig eine Alternative zu finden.

Der ursprünglich für drahtgebundene Netze entwickelte Standard IEEE 802.1X wurde hierfür herangezogen. Er spezifiziert das Grundgerüst für die eigentliche Authentifizierung. Es wird unterschieden zwischen dem Client (Supplicant), der sich in einem Netzwerk authentifizieren möchte, dem Authentifizierer (Authenticator), welcher als Kommunikationspartner für den Client fungiert und dem Authentifizierungsserver (Authentication Server), der die eigentliche Authentifizierung durchführt. In der Regel übernimmt ein RADIUS-Server (Remote Access Dial-Up User Service) die Rolle des Authentifizierungsservers und ein Access Point die des Authentifizierers.

Die verwendete Authentifizierungsmethode wird durch IEEE 802.1X nicht festgelegt. IEEE 802.1X basiert auf dem Extensible Authentication Protocol (EAP), welches ursprünglich für die Verwendung im Point-to-Point Protocol (PPP) entwickelt wurde und eine Vielzahl von Authentifizierungsmethoden unterstützt. Die Implementierung von EAP-MD5 ist für jede Umsetzung von EAP vorgeschrieben.

Abbildung 6

Die Autorisation findet bei IEEE 802.1X auf der Grundlage von Ports statt. Ein Port wird in zwei logische Ports unterteilt, einen kontrollierten und einen unkontrollierten. Der kontrollierte Port kann nur zur Kommunikation benutzt werden, wenn er sich in einem autorisierten Zustand befindet. Eine Kommunikation über den unkontrollierten Port ist zwar stets möglich, jedoch ist diese eingeschränkt. Die Unterteilung eines Port wird in Abbildung 6 gezeigt.

Abbildung 7

Das Format eines EAP Paketes ist in Abbildung 7 zu sehen. Es sind diese Felder vorhanden:

	Code Hierdurch wird der Typ des EAP Paketes gekennzeichnet. Folgende Werte sind möglich: 1) Anfrage 2) Antwort 3) Erfolg 4) Fehlschlag
	ID Die ID wird benutzt, um zusammengehörige Anfragen und Antworten zu kennzeichnen.
	Länge Die Längenangabe wird über das gesamte Paket gebildet.
	Daten Die Interpretation dieses Feldes ist abhängig vom Code. EAP Pakete, welche entweder den Code 3 (Erfolg) oder den Code 4 (Fehlschlag) besitzen, haben hier ein Feld der Länge Null. Entspricht der Code entweder 1 (Anfrage) oder 2 (Antwort), so enthält das erste Byte einen Typ. Normalerweise enthalten Antworten stets den gleichen Typ wie die zugehörige Anfrage. Eine Ausnahme bildet nur der Typ NAK, welcher in einer Antwort benutzt wird, um zu signalisieren, dass die Anfrage nicht akzeptabel war. Typen mit einem Wert größer oder gleich vier werden für Authentifizierungsmethoden genutzt. Im Einzelnen hat der Wert des Typ-Feldes diese Bedeutung:

Identität: Dieser Typ wird in der Regel vom Authentifizierer in der ersten Anfrage verwendet, um die Identität des Clients zu ermitteln. Das Datenfeld kann in diesem Fall Text für die Abfrage der Identität enthalten.

Benachrichtigung: Der Authentifizierer kann mit diesem Typ Nachrichten an den Client senden, die als Information für den Benutzer gedacht sind. Dies geschieht als Anfrage, wobei eine Antwort als Bestätigung erwartet wird. Diese enthält jedoch außer dem Typ keine Daten.

NAK: EAP Pakete des Typs NAK sind dazu gedacht eine Authentifizierungsmethode abzulehnen und eine Alternative vorzuschlagen. Diese wird in Form eines Byte direkt nach dem Typ angegeben.

MD5-Challenge: Diese Authentifizierungsmethode muss von jeder EAP Implementierung unterstützt werden. Sie stellt das Pendant zum CHAP Protokoll [SD96] dar.

Abbildung 8

Für das Versenden von EAP Paketen zwischen Client und Authentifizierer in einer LAN Umgebung findet eine Einkapselung statt, die EAP over LAN (EAPOL) genannt wird. Abbildung 8 zeigt den Aufbau. Die Felder sind:

	Version: Bisher ist nur Version 1 standardisiert.
	Paket-Typ: Neben der einfachen Kapselung von EAP Paketen fügt EAPOL auch neue Nachrichten hinzu, um die Anpassung von EAP von der PPP-Umgebung zu ermöglichen:

0) EAP-Paket: dient der Kapselung von EAP Paketen

1) EAPOL-Start: ermöglicht dem Client die Initiierung eines Authentifizierungsvorgangs

2) EAPOL-Logo: ermöglicht dem Client die Abmeldung und versetzt den Port zurück in den unautorisierten Zustand

3) EAPOL-Key: ermöglicht den Austausch von Schlüsselinformationen

4) EAPOL-Encapsulated-ASF-Alert: hierdurch können Alarme (z.B. für SNMP) an einen unautorisierten Port geschickt werden

	Rumpflänge: Dieses Feld umfasst die Länge des Paketrumpfes.
	Paketrumpf: Für Pakete des Typs EAPOL-Start und EAPOL-Logo ist dieses Feld nicht vorhanden. Ansonsten enthält es je nach Typ ein EAP Paket, einen Alarm oder eine Schlüsselinformationen.

Für die Kommunikation zwischen Authentifizierer und Authentifizierungsserver wird in der Regel RADIUS als Protokoll verwendet, welches auch unter dem Namen EAP over RADIUS bekannt ist.

Es soll nun die Authentifizierung mittels EAP-MD5 etwas genauer vorgestellt werden. Zunächst einmal wird vom Authentifizierer die Identität des Client erfragt. Diese wird an den Authentifizierungsserver weitergeleitet, welcher daraufhin dem Client über den Authentifizierer eine Challenge zukommen läßt. Der Client antwortet hierauf mit einem 16 Byte langen MD5-Hash über der Konkatenation aus der EAP-ID, seinem Passwort und dem empfangenen Challenge-Text. Kann der Authentifizierungsserver die Richtigkeit des verwendeten Passwortes im Bezug auf die anfangs übermittelte Identität feststellen, so bestätigt er die erfolgreiche Authentifizierung. Andernfalls wird der Fehlschlag mitgeteilt. Der Client hat die Möglichkeit diesen Authentifizierungsprozess anzustoßen, indem er einen EAPOL-Start Rahmen sendet. Weiterhin kann er sich durch einen EAP-Logo Rahmen wieder abzumelden, um zu verhindern, dass der autorisierte Port von anderen weiterverwendet wird. Abbildung 9 verdeutlicht diesen Ablauf nochmals.

Abbildung 9