IEEE 802.1X - Authentifizierung

Transkript

1 IEEE 802.1X - Authentifizierung Marco Francke 02INF

2 Inhalt 1 Einleitung 4 2 Probleme der bisherigen Ansätze 6 3 IEEE 802.1X Standard Was ist Authentisierung Warum Authentisierung auf dem Link-Layer Begriffserklärung PAE des Authenticators Überblicke des Standards 14 4 Extensible Authentication Protocol (EAP) Abläufe Spezifikation EAP over LAN (EAPOL) EAP-Transport Level Security (EAP-TLS) 21 5 IEEE 802.1x im WLAN Probleme des IEEE 802.1x Standards

3 6 Sicherheit 25 7 Zusammenfassung 27 Quellenangabe

4 1 Einleitung In der Praxis stellt sich häufiger die Aufgabe, in einem gemeinsam genutzten Netzwerk eine Trennung verschiedener Benutzergruppen, die unterschiedlichen Sicherheitsniveaus zugeordnet sind, vorzunehmen (Beispiele: Gastzugang, Trennung Industrie-/Bürobereich). Es muss also an einem geeigneten Punkt im Netz (z.b. direkt am Netzwerk-Port des Access-Switches) geprüft werden, welche Rechte mit dem Zugang verbunden sein sollen. Je nach Ergebnis der Authentifizierung wird ein genau definierter Zugang gewährt. Damit ein Netzzugang gewährt werden kann, muss sich der Nutzer authentifizieren. Damit sich ein Nutzer authentifizieren kann, benötigt er einen Netzzugang. Diese Doppelfunktion leistet der Standard IEEE 802.1X basierend auf dem EAP Extensible Authentication Protocol. IEEE 802.1X entwickelt sich in vielen Bereichen zu einem unverzichtbaren Design-Element, typisch ist sein Einsatz im Bereich WLAN/WPA. Ursprünglich sollte IEEE 802.1x eine Erweiterung der Bridging- Specification IEEE802.1D sein, doch nach dem andere Anwendungsmöglichkeiten aufgetaucht sind, wurde es eine eigene Spezifikation. Der Entwurf stammt von 3Com, HP und Microsoft und wurde im Juni 2001 als IEEE Standard anerkannt. Immer wo Rechner miteinander verbunden sind (zuhause, im Büro, oder öffentlichen Gebäuden) findet immer ein Netzwerkprotokoll der Protokollfamilie IEEE 802 Verwendung. In größeren Einrichtungen spielen noch Sicherheitsaspekte eine große Rolle, wie zum Beispiel: wer darf welche Dienste nutzen, welche Dienste - 4 -

5 sollte man mit Passwörtern versehen oder welche Rechner dürfen bestimmte Dienste nutzen. IEEE 802.1X bietet Lösungen für diese Probleme und stellt ein grundlegendes Framework (Architektur) zur Verfügung, um verlässliche AAA-Dienste (Authentifizierung, Autorisierung und Accounting) zu ermöglichen

6 2 Probleme der bisherigen Ansätze - man versucht die Probleme oder Sicherheitsrisiken auf der Anwendungsebene zu lösen wie z.b. die Abfrage von Passwörtern auf Webservern, oder man versucht es über die Transportebene via VPN Tunnel, zudem ist das VPN zu sehr herstellerspezifisch was wiederum Schwierigkeiten birgt - eine andere Möglichkeit wäre IPSec, hat aber den Nachteil das es genauso wie VPN arbeitet, nämlich mit IP Protokollen - PPPOE hat zuviel Overhead - DHCP ist nur für die Adressierung und Konfiguration verantwortlich - um von vorneherein Angriffe ausschließen zu können benötigt man ein Sicherheitssystem, welches sich auf dem Link-Layer ansetzen lässt, um den Angreifer den Zugriff auf den Link-Layer zu verwähren, denn ohne Netzwerkverbindung hat ein unautorisierter Nutzer keinen Zugriff auf das Netz und stellt keine Gefahr dar. - Möglichkeiten für kleinere Netzwerke, die eingesetzt werden, sind beispielsweise Software, mit der man eine Netzwerkdose ausschalten kann, um keinen Netzzugriff zu bieten. Problem hierbei ist es jedoch, dass möglicherweise Benutzer mobil mit Notebooks zugreifen wollen und von daher wäre der Netzwerkadministrator nur damit beschäftigt die Netzwerkanschlüsse zu rekonfigurieren, zudem kann der Angreifer einfach den Port eines anderen verbundenen Rechners nutzen. - Besseren Schutz verspricht die Kontrolle aufgrund von MAC-Adressen, die jede Netzwerkkarte besitzt, d.h. Jede Netzwerkkarte wird mit ihrer - 6 -

7 MAC-Adresse registriert und jeder Port wird so konfiguriert, dass nur die angeschlossene Netzwerkkarte Daten durchlassen kann. Problem hierbei ist, das man Mac-Adressen fälschen kann und sich somit Zugriff verschaffen kann. Zudem ist es ein sehr großer administrativer Aufwand, wenn es um mobile Rechner geht, da die Daten registriert und aufgenommen werden müssen

8 3 Der IEEE 802.1x Standard - ist Teil der 802 Protokollfamilie und daher in allen 802 Netzen einsetzbar - wird eingesetzt, um nur berechtigten Usern die Ports zugänglich zu machen - hierfür bietet der Standard die Möglichkeit zur Authentifizierung und Autorisierung - Spezifiziert ein Protokoll zwischen Geräten, die den Zugang zum LAN suchen und Geräten, die den Zugang zum LAN verwalten - Beschreibt die Anforderungen an ein Protokoll zwischen dem Authenticator (Zugangspunkt zum LAN) und einen Authentisierungs- Server (z.b. RADIUS) - Spezifiziert verschiedene Stufen der Zugangskontrolle und dem Verhalten eines Ports, der kontrollierten Zugang bietet - Beinhaltet auch Network Management Funktionen über SNMP - zudem bietet er die Möglichkeit eines Key Exchanges (wird erfolgreich bei Wireless LAN Verbindungen eingesetzt, um die Schwächen des WEP Schlüssels zu umgehen, die Abwandlung die WEP-Schlüssels nennt sich Dynamic WEP und wird von CISCO in Wireless LAN Geräten unterstützt - 8 -

9 3.1 Was ist überhaupt Authentisierung des Nutzzugangs? Es ist ein Mechanismus, durch den der Zugang zum Netz auf berechtigte Personen bzw. Geräte beschränkt wird. Als Identität wird ein Benutzername verwendet und nach erfolgreicher Authentisierung wird eine Autorisierung fällig, die die Berechtigungen für den Zugang konfiguriert (z.b. Bandbreite, Filter, Tunnels, ). Man benötigt die Authentisierung auch zur Verhinderung von Hijacking, hierbei ist die Authentisierung jedes Paketes notwendig. 3.2 Warum Authentifizierung auf dem Link-Layer? Es ist einfach, billig und schnell: - PPP und IEEE 802, die verbreiterten Link-Layer Techniken unterstützen die Authentisierung. - Niedrige Kosten werden bei der hohen Zahl Ports sehr bedeutsam - Der Client benötigt keinen Netzzugang, um sich zu authentisieren -> Authentisierung funktioniert auch ohne DNS und DHCP - Der Network Access Server (NAS) braucht maximal Layer 3 Funktionalität -> Authentication und AAA Support kann normalerweise mit einem Software-Update in bestehender realisiert werden -> die Link Layer Authentisierung funktioniert identisch für alle Protokolle - 9 -

10 -> im IP Layer wären getrennte Methoden für IPv4, IPv6, AppleTalk, IPX, SNA, NetBEUI, fällig -> Layer Interaktionen resultieren in höheren Delays 3.3 Einige kleine Begriffserklärungen Authenticator: Ist eine Einheit an einem Ende eines point-to-point LAN Segments, dass die Einheit am anderen Ende der Verbindung authentifiziert. Der Authenticator stellt den Netzwerkzugang zur Verfügung. Supplicant: Ist eine Einheit an einem Ende eines point-to-point LAN Segments, das von einem Authenticator am anderen Ende der Verbindung authentifiziert wird. Der Supplicant begehrt den Netzwerkzugang. Authentication Server: Ist eine Einheit, die einem Authenticator einen Authentication Service bereitstellt. Der Authentication Service bestimmt anhand der vom Supplicant zur Verfügung gestellten Credentials, ob dem Supplicant der Zugriff zu gewähren ist

11 Network Access Port: Ist ein Verbindungspunkt zu einem LAN. Es kann sich um einen physischen Port (z.b. RJ45-Buchse) oder einen logischen Port, wie bei der IEEE Assoziierung im WLAN handeln. Remote Authentication Dial-In User Service (RADIUS): Ist ein Client Server Protokoll, das zur Authentifizierung und Autorisierung von Benutzern bei Einwahlverbindungen in ein Computernetzwerk dient. RADIUS ist ein Standard bei der zentralen Authentifizierung von Einwahlverbindungen über Modem, ISDN, VPN, WLAN oder DSL Extensible Authentication Protocol (EAP): Ist ein Internet Standard und wird in der [RFC2284] vorgestellt. ist ein Protokoll zur Authentifizierung von Clients. Es kann zur Nutzerverwaltung auf RADIUS-Server zurückgreifen. EAP wird hauptsächlich innerhalb von WPA für größere WLAN-Installationen eingesetzt. Wi-Fi Protected Access (WPA): Stellt eine Verschlüsselungsart im WLAN Bereich dar. 3.4 Port Access Entity Ist die einem Port zugeordnete Kontrolleinheit. Die PAE kann die Rolle des Supplicant, des Authenticator oder beide übernehmen

12 Die PAE des Authenticator ist zweigeteilt: Sie verfügt über einen Controlled Port (CP) und einen Uncontrolled Port (UCP). CP stellt den allgemeinen Netzzugang zur Verfügung und ist vor der Autorisierung des Supplicant in einem gesperrten Zustand. Der UCP ist ständig geöffnet, bietet dem Supplicant jedoch nur die Möglichkeit sich zu authentifizieren. Pakete, die nicht der Authentifizierung dienen, werden von dem UCP nicht übermittelt. Der Port eines Authenticator kann sich in zwei Zuständen befinden. Entweder ist der Supplicant autorisiert, oder er ist nicht autorisiert. Zunächst ist der Supplicant nicht autorisiert und der CP ist gesperrt, so dass kein Datenaustausch mit dem Netzwerk stattfinden kann. Nach einer Authentifizierung wird der CP geöffnet und ein Datenaustausch kann stattfinden. Ob ein Supplicant autorisiert ist einen Netzzugang zu erhalten, entscheidet der Authentication Server. Der Authenticator steht zwischen Supplicant und Authentication Server und vermittelt zwischen ihnen

13 Ein Supplicant, der sich authentifizieren möchte, um einen Netzzugang zu erhalten, schickt Authentifizierungs-Requests an den Authenticator. Der Authenticator hat eine Netzwerkverbindung zu einem Authentification Server. Der Authentication Server kann etwa ein RADIUS (Remote Authentication Dial In User Service) sein, der zahlreiche Authentifizierungsmethoden unterstützen kann. Bei erfolgreicher Authentifizierung wird dem Authenticator mitgeteilt, das der Nutzer autorisiert ist den Port zu benutzen. Eine weitere Möglichkeit ist, dass zwei Systeme (A und B) beide Rollen (Supplicant und Authenticator) nacheinander übernehmen, um eine gegenseitige Authentifizierung zu erreichen: A sei als erstes Supplicant, der sich gegenüber B authentifiziert. Nach abgeschlossener Authentifizierung kann A nun an B einen Authentifizierungs-Request schicken, damit sich B gegenüber A authentifiziert. Auf diese Weise können etwa zwei Bridges sicherstellen, dass der Peer vertrauenswürdig ist. Die eigentliche Logik hinter der Authentifizierung muss nicht im Authenticator implementiert sein. Der Standard sieht vor, dass der Authenticator nur einen Vermittler zwischen Supplicant und Authentication Server darstellt. Die Kommunikation zwischen Authenticator und Authentication Server findet auf einem Protokoll höherer Ebene statt (etwa RADIUS über TCP/IP), während Authenticator und Supplicant mit EAP over LAN, einem Low-Level-Protokoll kommunizieren. Der Authenticator verarbeitet nur bedingt den Inhalt der Pakete, die Authentication Server und Supplicant austauschen. Sobald der Supplicant und der Authentication Server das Authentifizierungsprotokoll erfolgreich abgearbeitet haben, schickt der Authentication Server ein EAP-Success Paket an den Authenticator, der dann den CP für den Supplicant öffnet und dem Supplicant das EAP-Success Paket übermittelt

14 Nach dem die Authentifizierung erfolgt ist, nutzt der Supplicant das Netz mit den gewohnten Netzwerkprotokollen. Bis auf die eigentliche Authentifizierung erzeugt 802.1X keinen Packet-Overhead. BEMERKUNG: Zwischen dem Supplicant und dem Authentication Server werden Sicherheitsfunktionen realisiert. KONTROLLE des Ports: Wird unterteilt in volle Kontrolle und partielle Kontrolle des Ports. Die Volle Kontrolle verhindert jeden Datenaustausch über den kontrollierten Port solange der Teilnehmer nicht autorisiert ist. Die partielle Kontrolle erlaubt den Datenaustausch über den kontrollierten Port soweit es für Wake-on-LAN benötigt wird. Durch übergeordnete Funktionseinheiten kann die Partielle Kontrolle bei Bedarf auf volle Kontrolle ausgedehnt werden z.b. wenn bridges erkannt werden, um die Bildung von Rückkoppelschleifen beim Spanning-Tree Verfahren zu vermeiden. 3.5 Das 802.1x Protokoll Überblick - es packt das EAP in 802 Frames ein (EAPOL) und stellt einige Erweiterungen speziell für 802-LANs zur Verfügung - EAP ist ein universelles Authentisierungsprotokoll, das die Verwendung verschiedener Authentisierungsverfahren wie z.b. Smart- Cards, Kerberos, Public Key Verfahren, One-time password, statisches Passwort, usw. nutzt - der Authenticator leitet die Authentisierung zwischen Supplicant und Authentisierungs- Server durch - Die PAE im Authenticator erwirkt den kontrollierten Zugang zum LAN anhand der Ergebnisse des Authentisierungsverfahrens

15 4 EAP EAP ist eine Internet Standard und wurde ursprünglich entwickelt, um im PPP-Protokoll einen flexiblen Authentifizierungsmechanismus bereitzustellen. 4.1 Abläufe Nachdem die Verbindung zwischen Supplicant und Authenticator hergestellt wurde, schickt der Authenticator dem Supplicant einen oder mehrere EAP-Requests. Der Authenticator schickt dem Supplicant zunächst einen EAP-ID Request, den der Client mit einer ID-Kennung in einem EAP-Response beantwortet. Nun sendet der Authenticator dem Supplicant EAP-Requests, die vom Supplicant beantwortet werden. EAP wird durch den Authenticator mit einem EAP-Success Paket beendet, unter der Vorraussetzung, dass der Supplicant die EAP-Requests zufrieden stellend beantworten konnte. Ein EAP-Failure-Paket signalisiert den erfolglosen Abbruch des EAP- Protokolls und der Controlled Port bleibt gesperrt

16 4.2 Spezifikation Der Aufbau eines EAP-Paketes ist in der Zeichnung unten dargestellt. Der Code gibt die Art des EAP-Paketes an. Es gibt Request-, Response-, Success- und Failure-Pakete. Aufbau eines EAP-Paketes:

17 Art eines EAP-Paketes (Code): Der Authenticator schickt EAP-Requests an den Supplicant, die dieser dann mit EAP-Responses beantwortet. Nach dem Verlust von Requests wird nach einer festgelegten Zeit der EAP-Request erneut mit demselben Identifier abgeschickt. Ein Response trägt den Identifier des Request, damit eine Zuordnung stattfinden kann. Genauer Informationen über die Art des EAP-Paketes ist im Data Feld vorhanden

18 Der Aufbau von Request und Response Paketen ist in der folgenden Abbildung dargestellt. Das 8bit lange Typefeld gibt an, welches das Authentifizierungsprotokoll näher bestimmt wird. Aufbau eines Request/Response Paketes: EAP- Typen: Jede Implementierung von EAP unterstützt die Typen 1-4, wobei lediglich Typ 4 ein Authentifizierungs-Protokoll ist. Typ 1 ist reserviert, um die Identität des Peers zu erfahren. Typ 2 enthält einen String, der den User über den Ablauf eines Passwortes o.ä. informiert. Typ 3 (NAK) kommt nur in Responses vor und wird geschickt, wenn der Authentifizierende ein Request nicht beantworten kann, weil etwa das Authentifizierungsprotokoll nicht implementiert ist, oder weil er es nicht einsetzen will. In der Type-Data, wird das Protokoll zur Authentifizierung vorgeschlagen (8Bit Wert)

19 4.3 EAP over LAN ->EAPOL Supplicant und Authenticator müssen für die Authentifizierung Daten austauschen. Da das EAP noch vor dem eigentlichen Hochfahren des Ports abläuft, kann nicht auf ein verhältnismäßig komfortables Protokoll wie z.b. IP zurückgegriffen werden. Die EAP-Pakete werden direkt im Payload von Ethernet-, Wireless LAN bzw. Token-Ring-Frames übermittelt. EAPOL stellt neben der Übermittlung von EAP über LAN noch interessante Erweiterungen an. Die Folgende Abbildung zeigt ein Ethernet Frame mit einem EAP-Paket: Destination Address, Source Address und die FCS sind Teil des Ethernet Frames, während der Rest ein EAP-Paket ausmacht. Ein EAP-Paket muss immer komplett in ein Frame passen da keine Fragmentierung vorgesehen ist. Dadurch hat man Beschränkungen bezüglich der Inhalte eines EAP-Paketes. Authentifizierungsprotokolle wie EAP-TLS benötigen größere Pakete, daher wird im EAP-TLS-Protokoll Fragmentierung eingeführt

20 Als Destination Address wird, sofern die MAC der Gegenseite nicht bekannt ist, die reservierte Adresse C verwendet. Da in der Regel über point-to-point Verbindungen die Authentifizierung stattfindet, kann die reservierte Adresse verwendet werden, ohne dass es zu Verwechslungen kommen kann. In Medien, wo die MAC der Gegenseite bekannt ist, muss mit der echten MAC gearbeitet werden, da ansonsten keine Zuordnung getroffen werden könnte. Die Art des Pakets wird Im Packet Type wird die Art des Paketes festgelegt. Die folgende Tabelle gibt Aufschluss über die definierten EAPOL- Typen. Vom Supplicant werden EAPOL-Start und EAPOL-Logoff an den Authenticator versandt, um den Beginn einer Authentifizierung zu erbitten bzw. um nach der Nutzung eines Controlled Ports das Ende der Benutzung bekannt zu geben, um den Controlled Port wieder zu sperren. Ein EAPOL-Paket kann unterschiedliche Key-Deskriptoren transportieren. Derzeit ist nur ein Deskriptor für den Austausch von RC4-Keys definiert. Der RC4-Key-Descriptor geht davon aus, dass ein EAP-Session-Key bei der Authentifizierung erzeugt worden ist. EAP-Session-Keys werden von einigen EAP- Protokollen, wie z.b. dem EAP-TLS erzeugt

21 4.4 EAP-Transport Level Security-EAP-TLS Vorzüge von EAP-TLS gegenüber anderen EAP Protokollen sind: - beidseitige Authentifizierung - integritätsgesicherte Aushandlung von Verschlüsselungsverfahren - sicherer Schlüsselaustausch zwischen zwei Endpunkten Die beidseitige Authentifizierung ist ein wichtiger Vorteil von EAP-TLS um ist z.b. die Man-in-the-Middle Attack (MiM Attack) auszuschließen. EAP-TLS Protokoll sieht vor, das der Server dem Client ein Zertifikat übermittelt, welches vom Client auf Vertrauenswürdigkeit überprüft wird. Der Client übermittelt das Zertifikat wieder dem Server um sich zu authentifizieren. Das Verfahren benötigt eine PKI (Public Key Infrastructur). Mit der erfolgreichen, gegenseitigen Authentifizierung und Aushandlung eines Session Keys, sowie eines Verschlüsselungsverfahrens endet für gewöhnlich eine EAP-TLS Authentifizierung. Ein Mithören des Protokolls gibt keinen Aufschluss über den Session Key. Außerdem ist die Integrität des Session Keys gesichert, da TLS sicherstellt, dass keine Pakete während der Authentifizierung unentdeckt abgeändert oder erzeugt werden können. Bei der Wahl des Protokolls ist jedoch unbedingt darauf zu achten, dass dieses für den Einsatz in der vorhandenen Infrastruktur geeignet ist

22 5 Einsatz von IEEE im WLAN Für den Einsatz vom IEEE802.1x im WLAN sind zwei Kriterien entscheidend: 1. gegenseitige EAP-Authentifizierung 2. sicherer Session Key Die gegenseitige EAP-Authentifizierung ist wichtig, da der Supplicant im WLAN dem Authenticator nicht trauen kann. Es könnte ein gefakter Access Point sein, der die Daten des Supplicant mitlesen möchte. Da bei dem Einsatz von WLAN das faken eines Access Points als MiM Attack verhältnismäßig einfach ist, kann im WLAN auf eine gegenseitige Authentifizierung nicht verzichtet werden. Ein Session Key ermöglicht den EAPOL-Key Exchange, zur Realisierung von Dynamic WEP (Wired Equivalent Privacy). EAP- Authentifizierungsmechanismen wie LEAP, PEAP, EAP-TLS oder EAP- TTLS stellen neben anderen Protokollen die Möglichkeit zur Verfügung, während der Authentifizierung einen sicheren Session Key zu generieren. Schwerwiegende Designfehler, weißt die im WLAN zur Verfügung stehende Verschlüsselung WEP auf, so dass die Verschlüsselung praktisch zu brechen ist. Durch das Abfangen von einigen hunderttausend mit einem WEP-Key verschlüsselten Paketen ermöglicht das Brechen der Chiffre. Dynamic WEP umgeht dieses Problem, indem die WEP-Key entweder nach einer definierten Zeit (gesteuert vom Radiusserver) oder nach einer definierten Anzahl von verschlüsselten Paketen (CISCOs LEAP) ausgetauscht werden

23 Durch Dynamic WEP ist mit Hilfe von EAPOL die Geheimhaltung der Daten weitgehend sichergestellt, dennoch sind nicht alle Probleme, die in Verbindung mit WLAN auftreten gelöst, so ist immer noch eine Dos- Attacke durch das senden von gefakten Signoff-Paketen möglich (ABOBA). Dennoch bietet Dynamic WEP grundlegende Vorteile gegenüber einfachen WEP. 5.1 Probleme des Standards Der Einsatz von Produkten nach IEEE802.1x kann natürlich nicht alle Probleme lösen kann. Im Speziellen sollte darauf geachtet werden, dass die gemachten Annahmen über das Übertragungsmedium beachtet werden. EAP und das Modell des Controlled Ports wurden für point-to-point Verbindungen entwickelt und sind auch nur dort einzusetzen. Probleme im WLAN werden einem schnell klar: Man kann eine Dos-Attacke realisieren, in dem man ein gefaktes EAPOL- Logoff Paket an einen Nutzer eines AP sendet. Im draht gebundenen Netz hat man ähnliche Probleme, da man etwa zwischen Switch (Authenticator) und PC(Supplicant) einfach ein Hub anbringen könnte. Über den Hub können weitere Geräte angeschlossen werden, die den für den PC freigeschalteten Port mitbenutzen. Praktische Implementierungen können dieses spezielle Problem lösen, in dem der Port des Switches nur Pakete mit der MAC des authentifizierten Supplicant durchlassen, dies ist jedoch nicht immer gewünscht. Ein Einsatz von Endgeräten(Supplicant), die IEEE 802.1x unterstützen, in einer Umgebung, die diesen Standard noch nicht vorsieht, sollte keine

24 Probleme bereiten, da im Standard auf Abwärtskompatibilität geachtet wurde. Ein Supplicant, der auf mehrere EAP-Start-Anfragen keine Antwort erhält geht davon aus, dass der Port authentifiziert ist, und wird sich wie eine gewöhnliche NIC ohne IEEE 802.1x verhalten. Umgekehrt kann der Einsatz von Endgeräten, die kein IEEE 802.1x unterstützen, das Sicherheitskonzept einer durch IEEE 802.1x gesicherten Umgebung natürlich minimieren, da für diese (alten) Endgeräte die Sicherheitsmechanismen deaktiviert werden müssen, bevor diese eingesetzt werden können. Es ist also kritisch, dass alle Endgeräte IEEE802.1x unterstützen. Während PC-Systeme, oder Handheldgeräte leicht zu updaten sind, müssen auch Endgeräte wie Drucker und IP- Telephone den neuen Standard unterstützen. Eben dies stellt sich in der Praxis als Problem dar. Features wie Wake-on-LAN (WOL) funktionieren unter normalen Umständen bei einem nicht- autorisierten Controlled Port nicht mehr, da die WOL-Pakete nicht mehr das Endgerät erreichen, d.h. ein abgeschaltetes Endgerät kann sich typischerweise auch nicht authentifizieren. Um WOL zu ermöglichen existiert die Option die Controlled Ports so zu konfigurieren, dass nur eingehende Pakete (also Pakete vom Supplicant) nicht weitergeleitet werden

25 6 Sicherheiten Es gibt bereits erste Sicherheitsanalysen von IEEE Std x, die Problem des Standards identifiziert haben. Zum einen wurden Dos- Attacken, die erst mit dem neuen Standard möglich wurden identifiziert. Zum anderen wurde von Mishra/Arbaugh in zitierter Veröffentlichung ein potentielles Sicherheitsloch im Standard ausgemacht. DOS-Attacke (Denial of Service): Ein Angreifer könnte versuchen einen Authenticator zu blockieren, indem eine riesige Anzahl von EAP-Start Paketen versandt wird. Bei der Implementierung des Authenticator muss deshalb darauf geachtet werden, dass der Empfang von EAP-Start Paketen nicht dazu führt, dass bemerkenswerte Systemressourcen (Speicher) reserviert werden. Andere Dos-Attacken nutzen aus, dass EAPOL Pakete keinen Integritätsschutz besitzen. Ein Angreifer könnte EAP-Logoff oder EAP- Failure Pakete an einen Supplicant schicken, so dass dieser davon ausgeht sich neu authentifizieren zu müssen. Mim-Attacke (Man in Middle): Mishra/Arbaugh habe eine mögliche MiM-Attacke entdeckt. Möglich sind sie, da eine gegenseitige Authentifizierung im EAP zwar möglich, nicht jedoch erzwungen ist. Sofern sich nur der Supplicant gegenüber dem Authenticator auszuweisen hat, kann ein Angreifer als MiM sich gegenüber dem Supplicant als Authenticator ausgeben, um so den Datenstrom des Supplicant mitlesen zu können

26 Die MiM-Attack und das mitlesen des Datenstroms ist natürlich nur in dann ein Problem, wenn der Angreifer durch das Mitlesen des Datenstroms Informationen gewinnt. Eine Verschlüsselung zwischen Access-Point und Supplicant, der ohnehin in Umgebungen angeraten ist, wo MiM Attacken möglich sind, beseitigt das von Mishra/Arbaugh vorgestellte Problem. Premature & Unconditional EAP Success: Eine weitere Sicherheitslücke, auf die von Mishra/Arbaugh hingewiesen wurde, findet sich in der Referenz-Implementierung des Supplicant. In der Referenz-Implementierung wird der Supplicant das EAP abbrechen, sobald er in EAP-Success-Paket erhält. Da das EAP-Success Paket nicht integritätsgesichert ist, ist das Spoofen eines solchen Paketes generell möglich. Durch diesen Defekt ist es möglich die gegenseitige Authentifizierung mittels EAP-TLS, EAP-TTLS oder LEAP zu unterbinden. Ob dieser Angriff beim Einsatz von EAP-TLS oder ähnlichen Protokollen möglich ist, ist fraglich, da neben der gegenseitigen Authentifizierung wird noch ein Session Key generiert wurde, der bei vorzeitigem Abbruch nicht initialisiert wäre. Eine ordnungsgemäße Implementierung sollte diesen Fehler erkennen und eine erneute Authentifizierung beginnen

27 7 Zusammenfassung Ein Netzwerk, mit 802.1x ist nicht automatisch ein sicheres Netzwerk, da z.b. Authentifizierungsmethoden verwendet werden können, die für das Netzwerk ungeeignet sind. Jedoch ist dem Administrator mit 802.1x ein mächtiges Werkzeug an die Hand gegeben, um ein rigoroses Sicherheitskonzept, das schon auf unterster Ebene eingreift, zu realisieren. Es bleibt jedoch darauf hinzuweisen, dass der Standard nur den Zugang zum Netz kontrolliert, nicht jedoch wie authentifizierte Nutzer das Netz nutzen. Firewalls und andere Sicherheitsmethoden soll dieser Standard nicht ersetzen x stellt nur einen Teil einer umfassenden Sicherheitsstrategie dar

28 Quellenangabe Bücher-Quellen: James F. Kurose und Keith W.Ross, Computernetze -Ein Top-Down- Ansatz mit Schwerpunkt Internet-, Addison-Wesley-Verlag, München 2002 Ullenboom, Christian, JAVA ist auch eine Insel, Programmieren für die Java 2- Plattform in der Version 1.4, Galileo Computing, 3.Auflage, Bonn 2003 Internet-Quellen: HThttp://de.wikipedia.org/wiki/HauptseiteTH HThttp:// services/list/win_info/ieee_802.1x_windows_netng_slides.pdfth HThttp:// HThttp://