Bachelor-Thesis - Studium an der Hochschule Ulm · In dieser Arbeit wird ein Konzept entwickelt,...

Bachelor-Thesis

Technisches Sicherheitskonzept für das

WLAN-Funknetz der Hochschule Ulm

Bachelorarbeit an der

Hochschule Ulm

Fakultät Informatik

Studiengang Technische Informatik

vorgelegt von

Raphael Heinlein

Mai 2011

1. Gutachter: Prof. Dr. Markus Schäffter

2. Gutachter: Prof. Dr. Stefan Traub

Eigenständigkeitserklärung ii

Eigenständigkeitserklärung

Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfeverfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.Insbesondere versichere ich, dass ich alle wörtlichen und sinngemäßen Zitate als solchekenntlich gemacht und mit genauer Quellenangabe dargelegt habe.

Ulm, 31. Mai 2011Unterschrift

Raphael Heinlein Hochschule Ulm

Zusammenfassung iii

Zusammenfassung

Die Hochschule Ulm betreibt zurzeit ein offenes WLAN, bei welchem keine direkten Sicher-heitsmerkmale des WLAN-Standards IEEE 802.11 angewendet werden. Das WLAN dienteinzig dem Zugang zum VPN-Gateway der Hochschule. Über diesen ist ein sicherer Zugangzum Intranet und Internet nur für Angehörige der Hochschule Ulm möglich.Um den Komfort und die Kompatibilität zu verbessern und auch Gästen einen Zugang zumInternet über das WLAN zu ermöglichen, soll die WLAN-Infrastruktur der Hochschule Ulm aneinen Roaming-Dienst angebunden werden. Als Roaming-Dienst kommt eduroam zusammenmit dem DFNRoaming in Frage. Dafür muss eine WLAN-Infrastruktur auf Basis der 802.1XAuthentifizierung aufgebaut werden.In dieser Arbeit wird ein Konzept entwickelt, welches alle Schritte, die zur Umstellung derWLAN-Infrastruktur auf die 802.1X Authentifizierung und die Anbindung an das DFNRo-aming/eduroam notwendig sind, aufzeigt.


Danksagung iv

Danksagung

An dieser Stelle möchte ich Herrn Prof. Dr. Markus Schäffter für seine professionelle Betreuungund das entgegengebrachte Vertrauen danken.

Dank gebührt auch Herrn Prof. Dr. Stefan Traub, Herrn Peter Nachtmann sowie Herrn DietmarRahlfs für die Zusammenarbeit und Bereitstellung der technischen Mittel.

Meiner Familie und meinen Freunden danke ich für die Unterstützung.


Inhaltsverzeichnis v

Inhaltsverzeichnis

1. Einleitung 1

1.1. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Grundlagen 3

2.1. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2. IEEE 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.3. WPA und WPA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1. EAP-TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2. EAP-TTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.3. EAP-PEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.4. MS-CHAPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4. EAPOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5.1. RADIUS-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.2. RADIUS-Geräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6. RadSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7. Ablauf der 802.1X Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 23

2.7.1. Schlüsselmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.7.2. Roaming und 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.8. eduroam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.9. Das Deutsche Forschungsnetz . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.9.1. DFN-Verein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.9.2. Wissenschaftsnetz X-WiN . . . . . . . . . . . . . . . . . . . . . . . . . 312.9.3. DFNRoaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31


Inhaltsverzeichnis vi

3. Anforderungsanalyse 32

3.1. Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2. Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1. Angehöriger der Hochschule Ulm meldet sich am WLAN der HSU an 333.2.2. Angehöriger der Hochschule Ulm meldet sich am WLAN einer anderen

Institution an . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.3. Gast meldet sich am WLAN der Hochschule Ulm an . . . . . . . . . . 353.2.4. Weitere Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2. Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 373.3.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4. Konzeption 40

4.1. Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2. Grobkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1. Benötigte Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2. Ablauf der Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 41

4.3. Feinkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.1. Varianten im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.2. Varianten im Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3.3. Verwendete Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 494.3.4. Verwendete Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.5. Ablauf der Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 54

4.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5. Performancemessung 61

5.1. Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2. Komponenten im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.1. Iperf / JPerf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.2. Iperf-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.3. Iperf-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.4. Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3. Durchführung und Auswertung der Messung . . . . . . . . . . . . . . . . . . . 665.3.1. Datenrate Iperf-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3.2. Datenrate einzelner WLAN-Clients . . . . . . . . . . . . . . . . . . . . 675.3.3. Datenrate mehrerer WLAN-Clients zusammen . . . . . . . . . . . . . 705.3.4. Access Point Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


Inhaltsverzeichnis vii

5.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6. Umsetzung 77

6.1. DFN-Anmeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2. VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.3. Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.4. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.5. RADIUS-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.5.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.5.2. Zertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.5.3. Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.6. RadSecProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.6.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.6.2. Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.6.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.7. Client-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.7.1. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.7.2. Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.7.3. Beispiel-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.8. Fehleranalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7. Bewertung 98

7.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.2. Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 98

8. Zusammenfassung und Ausblick 101

Abbildungsverzeichnis viii

Tabellenverzeichnis ix

Literaturverzeichnis x

Abkürzungsverzeichnis xv

A. radsecproxy Konfigurationsvorlage xviii


1. Einleitung 1

1. Einleitung

1.1. Einführung

WLAN-Infrastrukturen sind weit verbreitet und bieten dem Nutzer einen einfachen undkomfortablen Netzzugang. Dabei spielt die Sicherheit eine wichtige Rolle, da ein WLAN fürjeden, der in dessen Reichweite ist, zu empfangen ist. Anforderungen wie Vertraulichkeit,Integrität und Authentifizierung müssen erfüllt werden. Zur Lösung gibt es unterschiedlicheAnsätze, die alle ihre Vor- und Nachteile haben.

1.2. Problemstellung

Die Hochschule Ulm betreibt zurzeit ein offenes WLAN, bei welchem keine direkten Sicher-heitsmerkmale des WLAN-Standards IEEE 802.11 angewendet werden. Das WLAN dienteinzig dem Zugang zum VPN-Gateway der Hochschule. Über diesen ist ein sicherer Zugangzum Intranet und Internet möglich.Der VPN-Tunnel bietet zwar ein hohes Maß an Sicherheit und erfüllt die Anforderungen fürVertraulichkeit, Integrität und Authentifizierung, jedoch ist er nicht sehr komfortabel. Es mussjedes Mal vor der Nutzung des WLANs der VPN-Tunnel vom Benutzer aufgebaut werden. Fürdie meisten Endgeräte (Laptops, Tablet-PCs, Smartphones) wird dazu eine spezielle Zusatz-software in Form eines VPN-Clients benötigt. Diese existiert aber nicht für jede Plattformund stellt einen gewissen Aufwand bei der Konfiguration dar. Für den Benutzer bietet diesdaher nur wenig Komfort.Um den Komfort und die Kompatibilität zu verbessern, muss eine Alternative gesucht werden.Durch die Erweiterung IEEE 802.11i des WLAN-Standards um weitere und verbesserte Sicher-heitsmaßnahmen ist eine komfortablere Lösung auf Basis der IEEE 802.1X Authentifizierungzusammen mit der WPA2-Verschlüsselung möglich. Neben Steigerung des Komforts und derKompatibilität, sollen auch Gäste einen einfach Zugriff auf das Internet über das WLANder Hochschule Ulm erhalten. Die 802.1X Authentifizierung stellt dabei auch den Standardfür Roaming-Dienste wie z. B. DFNRoaming/eduroam dar. Dabei handelt es sich um einen


1. Einleitung 2

Roaming-Dienst, welcher allen Teilnehmern dieses Verbundes einen einfachen und komfortablenZugriff auf das Internet über das WLAN der jeweiligen Institution bietet.

1.3. Zielstellung

Ziel dieser Arbeit ist die Erstellung eines Sicherheitskonzepts für das WLAN der HochschuleUlm, welches dem Nutzer einen sicheren, vertraulichen und komfortablen Zugang zum WLANund der darüber angebotenen Dienste bietet. Zudem sollen alle gängigen mobilen Geräte(Laptops, Tablet-PCs, Smartphones) mit allen gängigen Betriebssystemen (Windows, Linux,iOS, Android, Windows Mobile, BlackBerry OS, Symbian) unterstützt werden. Dabei solldarauf geachtet werden, dass auf den Geräten möglichst keine Zusatzsoftware benötigt wirdund dass sich der Konfigurationsaufwand für den Anwender in Grenzen hält.Durch Anbindung an den Roaming-Dienst des Deutschen Forschungsnetzes, soll auch Gästenein sicherer und vertraulicher Zugang zum WLAN und somit zum Internet geboten werden.

1.4. Aufbau der Arbeit

Die Arbeit behandelt zunächst alle Grundlagen, die im Zusammenhang mit der 802.1X Authen-tifizierung stehen und für die Anbindung an den Roaming-Dienst des DFNs benötigt werden.Danach wird auf die Anforderungen der neu zu entwickelnden WLAN-Infrastruktur eingegan-gen. Anhand der Anforderungen wird dann ein Konzept entwickelt, welches die Umstellung aufdie 802.1X Authentifizierung und die dafür notwendigen Komponenten beschreibt. In Kapitel5 wird die Leistungsfähigkeit der benötigten Access Points durch Performancemessungen unterLaborbedingungen bestimmt. Anhand der gewonnen Erkenntnisse in den Kapiteln „Konzep-tion“ und „Performancemessung“ wird im Kapitel „Umsetzung“ auf die Konfiguration allernotwendigen Komponenten eingegangen, um die neu entwickelte WLAN-Struktur aufzubauen.Die Arbeit endet im Kapitel 7 mit einer Bewertung der neuen WLAN-Infrastruktur anhandder Anforderungen.


2. Grundlagen 3

2. Grundlagen

2.1. Wireless LAN

Wireless LAN gewinnt mit der steigenden Verbreitung von mobilen Geräten (Laptops, Tablet-PCs, Smartphones) immer mehr an Bedeutung. Um die Mobilität der Geräte zu gewährleisten,sind diese auf drahtlose Datenverbindungen zwingend angewiesen.Im Gegensatz zur Anbindung über Mobilfunknetze sind IEEE 802.11 Funknetze (WLAN)vergleichsweise performant und preiswert. Es liegt daher gerade für eine Hochschule für Techniknahe, ihren Angehörigen und Gästen einen schnellen und komfortablen WLAN-Zugang zuermöglichen.

2.1.1. IEEE 802.11

IEEE 802.11 ist der Standard, auf welchem heute die meisten WLAN-Geräte basieren. [Rec08,S. 3]Beim 802.11-Standard handelt es sich um eine Familie von technischen Standards. Der 802.11-Grundstandard wurde 1997 vom IEEE (Institute of Electrical and Electronics Engineers)verabschiedet. Er ermöglicht Datenraten von bis zu 2 MBit/s. Die Funkübertragung arbeitetmit Infrarotverbindungen bzw. mit elektromagnetischen Wellen im 2,4-GHz-Band. DieserFrequenzbereich liegt im so genannten ISM-Band (Industrial, Scientific, Medical), welchesweltweit lizenz- und genehmigungsfrei genutzt werden darf. Dadurch ergibt sich der Vorteil, dassfür den Betrieb eines WLANs keine Genehmigung erforderlich ist und keine Lizenzgebührenanfallen. [Rec08, S. 6]

Um höhere Datenraten zu erreichen, wurde der 802.11-Grundzustand erweitert und modifiziert.Im Jahre 1999 wurde die Standarderweiterung IEEE 802.11b verabschiedet, welche eineDatenrate von bis zu 11MBit/s im 2,4-GHz-Band ermöglicht. [Rec08, S. 6]

Zeitgleich wurde 1999 die Standarderweiterung IEEE 802.11a verabschiedet. Diese ermöglichtDatenraten von bis zu 54 MBit/s und arbeitet im 5-GHz-Band. Da 802.11a mit einer Sendeleis-tung arbeitet, die in Europa nicht erlaubt ist, darf der Standard nur mit einer eingeschränkten


2. Grundlagen 4

Sendeleistung und einer geringeren Anzahl von Kanälen in Europa betrieben werden. [Rec08,S. 7]Erst mit der Standarderweiterung 802.11h, welche 2003 verabschiedet wurde, können Gerätenach dem Standard 802.11a mit vollem Leistungsumfang in Europa genutzt werden. DerStandard 802.11h erweitert den Standard 802.11a um zwei wesentliche Merkmale wie einerdynamischen Kanal- bzw. Frequenzwahl (Dynamic Frequency Selection (DFS)) und einerautomatischen Leistungsreduzierung (Transmit Power Control (TPC)). [Rec08, S. 7]Wegen der Einschränkungen im Betrieb und der späten Einführung von 802.11h ist dieVerbreitung von Geräten nach dem Standard 802.11a in Europa gering. [Rec08, S. 7]

Mit IEEE 802.11g erfolgte 2003 eine weitere Standarderweiterung, welche eine Datenratevon bis zu 54MBit/s im 2,4-GHz-Band ermöglicht. Geräte nach 802.11g sind dabei auch mitGeräten nach 802.11b grundsätzlich kompatibel. [Rec08, S. 7]; [Hof05, S. 9]

Ende 2009 wurde die Standarderweiterung IEEE 802.11n verabschiedet, welche eine Datenratevon bis zu 600MBit/s ermöglicht und dabei wahlweise auf das 2,4-GHz-Band und das 5-GHz-Band zurückgreift. Geräte nach 802.11n sind mit Geräten zu den Standards 802.11a/b/gkompatibel. [Ele11n]

Eine weitere Standarderweiterung ist IEEE 802.11i, welche die Sicherheit von WLAN deutlichverbessert. Weitere Informationen können im Abschnitt 2.1.2 auf der nächsten Seite entnommenwerden.

Neben den bereits erwähnten Standarderweiterungen gibt es noch weitere, die z. B. die Imple-mentierung von QoS (Quality of Service) oder die Kommunikation zwischen Access Pointsbehandeln. [Rec08, S. 8 ff.]Diese werden hier aber nicht weiter betrachtet.

In Tabelle 2.1 sind die Standarderweiterungen mit zugehörigen Datenraten aufgelistet.

Standard Datenrate (brutto) Datenrate (netto) FrequenzbandIEEE 802.11 2 MBit/s 1 MBit/s 2,4 GHzIEEE 802.11a 54 MBit/s 22 MBit/s 5 GHzIEEE 802.11b 11 MBit/s 5 MBit/s 2,4 GHzIEEE 802.11g 54 MBit/s 22 MBit/s 2,4 GHzIEEE 802.11n 600 MBit/s 240 MBit/s 2,4 GHz / 5 GHz

Tabelle 2.1.: WLAN Standards Überblick [Ele11b]

Das 2,4-GHz-Band stellt für WLAN in Deutschland 13 Kanäle zur Verfügung, welche jeweilseinen Abstand von 5 MHz aufweisen. Der Standard 802.11b arbeitet jedoch mit einer Bandbreitevon 22 MHz pro Kanal. Dies führt dazu, dass sich benachbarte Kanäle wegen ihrer zu geringen


2. Grundlagen 5

Breite überlappen. Um einen störungsfreien Betrieb zu ermöglichen, sollte zwischen zweiWLAN-Geräten mindestens ein Kanalabstand von 25 MHz eingehalten werden. Dadurchergeben sich die drei Kanäle 1, 6 und 11, auf welchen ein störungsfreier Betrieb möglichist. Noch besser ist es, einen Kanalabstand von 30 MHz und somit die Kanäle 1, 7 und 13zu verwenden. Es können daher immer nur 3 WLAN-Geräte nach dem Standard 802.11bgleichzeitig innerhalb eines Empfangsbereichs störungsfrei betrieben werden. [WikWLAN];[Rec08, S. 400 ff.]Geräte nach dem Standard 802.11g arbeiten mit einer Bandbreite von 20 MHz pro Kanal. Diesermöglicht jetzt 4 Geräte störungsfrei auf den Kanälen 1, 5, 9 und 13 zu betreiben, allerdingsnur, wenn kein Mischbetrieb aus 802.11b/g verwendet wird. [WikWLAN]Im Gegensatz dazu können Geräte nach dem Standard 802.11n sowohl im 2,4-GHz- als auch im5-GHz-Band arbeiten. Das 5-GHz-Band stellt insgesamt 19 Kanäle mit einer Bandbreite vonjeweils 20 MHz zur Verfügung. Insgesamt können so 19 WLAN-Geräte gleichzeitig innerhalbeines Empfangsbereichs störungsfrei mit einer Bandbreite von 20 MHz betrieben werden.Um die Datenrate zu erhöhen, können Geräte nach dem Standard 802.11n auch mit einererweiterten Bandbreite von 40 MHz betrieben werden. Im 2,4-GHz-Band wird dies nichtempfohlen, da dann nur noch zwei störungsfreie Kanäle vorhanden sind und weitere 2,4-GHz-Geräte ggf. gestört werden und sich ihre Performance somit deutlich verschlechtert. Im5-GHz-Band hingegen ist ein Betrieb mit einer Kanalbreite von 40 MHz problemlos möglich.Es stehen dann statt 19 noch 8 störungsfreie Kanäle zur Verfügung. [WikWLAN]; [Rec08, S.264 f.]

Das WLAN der Hochschule Ulm arbeitet derzeit nach dem Standard 802.11b/g im 2,4-GHz-Band. Dieser ist heute in Europa am meisten verbreitet. Mit der Zeit nimmt aber auch dieVerbreitung von Geräten nach dem Standard 802.11n zu. Daher ist eine Erweiterung desWLANs der Hochschule Ulm auf 802.11n und das 5-GHz-Band in naher Zukunft unbedingt zuempfehlen.

2.1.2. IEEE 802.11i

Im WLAN Grundstandard 802.11 sind bereits Sicherheitsmechanismen integriert, um denunautorisierten Zugriff auf das WLAN und das Mitlauschen und Manipulieren von Daten zuverhindern. Die Sicherheitsmechnismen werden unter dem Begriff WEP (Wired EquivalentPrivacy) zusammengefasst. WEP soll den Zugang zum WLAN kontrollieren und dabei dieVertraulichkeit und Integrität der Daten sicherstellen. Wesentlicher Bestandteil von WEPist die Authentifizierung durch einen Pre-Shared Key und die WEP-Datenverschlüsselung,welche auf RC4 basiert. Es wurde aber schnell festgestellt, dass die WEP-VerschlüsselungSchwachstellen aufweist und keinen ausreichenden Schutz bietet. Durch gezielte Angriffe und


2. Grundlagen 6

die Ausnutzung der Schwachstellen kann die WEP-Verschlüsselung gebrochen werden. [Rec08,S. 435 ff.]; [Hof05, S. 49 ff.]; [Oss10];[Kle06]

Daher wurde im Jahr 2004 der IEEE 802.11i-Standard verabschiedet, welcher erweiterteSicherheitsmechanismen bietet. IEEE 802.11i definiert einheitliche und herstellerübergreifendeSicherheitsmechanismen, welchen den heutigen Sicherheitsansprüchen gerecht werden. Umdie Kompatibilität von älteren WLAN-Geräten weiter zu gewährleisten, wurden zwei neueSicherheitsverfahren eingeführt, die die Vertraulichkeit und Datenintegrität sicherstellen sollen.Das erste Verfahren ist eine optionale Übergangslösung und basiert wie auch schon dieWEP-Verschlüsselung auf RC4. Durch einen häufigen Schlüsselwechsel weist es aber nichtmehr deren Sicherheitsprobleme auf und wird als Temporary Key Integrity Protocol (TKIP)bezeichnet. TKIP stellt eine Übergangslösung für ältere WLAN-Geräte dar. Diese könnenTKIP durch Firmware- bzw. Treiberupdates mit der herkömmlichen Hardware nutzen. Umdie Datenintegrität sicher zu stellen, verwendet TKIP einen Message Integrity Check (MIC).[Rec08, S. 449]; [BSI09, S. A-20 ff.]Das zweite und endgültige in 802.11i festgelegte Verfahren basiert auf dem symmetrischenVerschlüsselungsverfahren Advanced Encryption Standard (AES) und arbeitet im ModusCCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol).Das Verfahren wird daher als AES-CCMP bezeichnet. AES stellt heute ein sehr sicheresVerschlüsselungsverfahren dar und wird vom National Institute of Standards and Technology(NIST) empfohlen. Um AES-CCMP zu nutzen, muss dies von der WLAN Hardware auchunterstützt werden, da AES-CCMP für bessere Performance in Hardware realisiert wird.[Rec08, S. 450]; [BSI09, S. A-20 ff.]

Mit 802.11i wurde auch ein erweitertes Authentifizierungsverfahren zusammen mit einemautomatischen, dynamischen Schlüsselmanagement eingeführt. Dies wird als Authentication andKey Management (AKM) bezeichnet. AKM verwendet entweder Authentifizierungsverfahren,die nach dem IEEE 802.1X-Standard spezifiziert sind und auf dem Extensible AuthenticationProtocol (EAP) basieren oder einen Pre-Shared Key (PSK). Wobei der PSK für kleinereWLAN Installationen ohne Authentifizierungsserver gedacht ist.WLAN Installationen, die die neuen Sicherheitsmechanismen (TKIP oder AES-CCMP) nach802.11i einsetzen, werden vom IEEE als Robust Security Network (RSN) bezeichnet. [Rec08,S. 450 f.]

WLAN-Geräte, die dem 802.11i-Standard entsprechen, müssen zwingend AES-CCMP und die802.1X Authentifizierung unterstützten. TKIP ist nur eine optionale Übergangslösung undreicht allein nicht aus. [Rec08, S. 450]


2. Grundlagen 7

2.1.3. WPA und WPA2

WPA steht für Wi-Fi Protected Access und ist eine Definition der Wi-Fi Alliance. WPA wurdeim Jahr 2003 veröffentlicht und stellt eine Teilmenge des IEEE 802.11i-Standards dar, welcherdamals noch in der Entwicklung war. WPA stützt sich dabei auf die TKIP-Verschlüsselungund die Integritätsprüfung MIC. WPA wurde als ein quasi vorzeitiger Standard von der Wi-FiAlliance eingeführt, da sich die Verabschiedung des regulären IEEE 802.11i Standards verzöger-te. Im Jahr 2004 wurde dann WPA2 veröffentlicht, welches dem finalen IEEE 802.11i-Standardim Wesentlichen entspricht und für die Verschlüsselung und Integritätsprüfung AES-CCMPnutzt. [Rec08, S. 451 f.]Für die Authentifizierung stehen sowohl bei WPA als auch bei WPA2 die zwei Möglichkei-ten vom IEEE 802.11i-Standard zur Verfügung, welche als WPA-Personal und als WPA-Enterprise bezeichnet werden. WPA-Enterprise benötigt einen Authentifizierungsserver fürdie Authentifizierung der Clients und für den dynamischen Schlüsselaustausch. Dabei werdenAuthentifizierungsverfahren, die nach dem IEEE 802.1X-Standard spezifiziert sind und aufdem Extensible Authentication Protocol (EAP) basieren, genutzt. Bei WPA-Personal dagegen,wird ein Pre-Shared Key (PSK) für die Authentifizierung und die dynamische Schlüsselgene-rierung verwendet. WPA-Personal eignet sich daher für kleinere WLAN-Installationen ohneAuthentifizierungsserver. [Rec08, S. 451 f.]

In Tabelle 2.2 sind die unterschiedlichen Verschlüsselungsvarianten nochmals dargestellt.

Verschlüsselungsvariante WEP WPA WPA2Personal-Mode Authentifizierung PSK PSK PSK

Verschlüsselung WEP(RC4) TKIP(RC4) CCMP(AES)Enterprise-Mode Authentifizierung - 802.1X/EAP 802.1X/EAP

Verschlüsselung - TKIP(RC4) CCMP(AES)

Tabelle 2.2.: WLAN-Verschlüsselungsvarianten

2.2. IEEE 802.1X

Der IEEE 802.1X-Standard wurde ursprünglich für drahtgebundene Netzwerke (z. B. Ethernet)entwickelt. Er ermöglicht eine Port-basierte Zugangskontrolle zu einem Netzwerk (Port BasedNetwork Access Control). Ein Rechner erhält erst Zugang auf das Netzwerk, wenn er sicherfolgreich bei einem Authentifizierungsserver authentifiziert hat.Mittlerweile wird 802.1X auch für die Authentifizierung von Clients im WLAN eingesetzt.Die 802.1X Authentifizierung besteht im Wesentlichen aus drei verschiedenen Instanzen: dem


2. Grundlagen 8

Supplicant, dem Authenticator und dem Authentifizierungsserver. [Rec08, S. 453 ff.]; [Hof05,S. 82 f.]

SupplicantDer Supplicant (Bittsteller) stellt den Client dar, der auf das Netzwerk zugreifen möchte undum Zugang bittet. Im Fall von WLAN handelt es sich um den entsprechenden WLAN-Client(z. B. ein Laptop oder ein Smartphone).

AuthenticatorDer Authenticator verwaltet den Zugriff auf das Netzwerk. Er fungiert dabei als Vermittlerzwischen Supplicant und Authentifizierungsserver. Authentifizierungsanfragen des Supplicantswerden vom Authenticator entgegen genommen und an den Authentifizierungsserver weitergeleitet. Wenn ein Supplicant erfolgreich authentifiziert wird, dann gibt der Authenticator denZugriff auf das Netzwerk frei. Ohne erfolgreiche Authentifizierung blockt der Authenticatorden Zugriff auf das Netzwerk und akzeptiert nur Authentifizierungsanfragen. Im Falle vonEthernet ist der Authenticator ein Switch, im Falle von WLAN ein Access Point.

AuthentifizierungsserverDer Authentifizierungsserver nimmt die Authentifizierungsanfrage des Supplicants über denAuthenticator entgegen und entscheidet, ob der Supplicant Zugriff auf das Netz erhält oder nicht.Die entsprechende Bestätigung oder Ablehnung wird über den Authenticator an den Supplicantgeschickt. Als Authentifizierungsserver wird häufig ein RADIUS-Server eingesetzt (RemoteAuthentication Dial-In User Service). Im Falle von WLAN ist der Authentifizierungsserverneben der Authentifizierung der Clients auch für die Verteilung der dynamischen Schlüssel fürdie Verschlüsselung verantwortlich.

Das Zusammenspiel der drei Instanzen kann Abbildung 2.1 entnommen werden.

Abbildung 2.1.: 802.1X-Modell

Der Supplicant leitet den Authentifizierungsvorgang ein und bittet den Authenticator um Zugriffauf das Netzwerk. Der Authenticator leitet die Anfrage an den Authentifizierungsserver weiter.Bei einer erfolgreichen Authentifizierung des Supplicants sendet der Authentifizierungsservereine Bestätigung über den Authenticator an den Supplicant. Der Authenticator autorisiert jetztden Supplicant und gewährt ihm Zugriff auf das Netzwerk. Ohne bzw. bei keiner erfolgreichen


2. Grundlagen 9

Authentifizierung blockt der Authenticator den Zugriff auf das Netzwerk und akzeptiert nurAuthentifizierungsanfragen vom Supplicant.Der Authenticator stellt dazu die Zugangsports (802.1X-Ports) zum Netzwerk bereit. Bei einemEthernet Switch handelt es sich um die physikalischen Ports, bei einem WLAN Access Pointhingegen um virtuelle Ports. Über den Port wird festgelegt, ob ein Datentransfer zugelassenwird oder nicht.Jeder Port hat zwei logische Einheiten von Ports, einen kontrollierten und einen unkontrolliertenPort. Der unkontrollierte Port ist immer offen, akzeptiert aber nur Authentifizierungsanfragen.Alle anderen Anfragen und Pakete werden verworfen. Der kontrollierte Port ist standardmäßigblockiert (nicht autorisiert) und wird erst nach erfolgreicher Authentifizierung des Supplicantsgeöffnet (autorisiert). Über den kontrollierten Port erhält der Supplicant dann Zugriff auf dasNetzwerk. [Rec08, S. 453 ff.]; [Hof05, S. 82 f.]; [Str04]

In Abbildung 2.2 sind die Ports schematisch dargestellt.

Abbildung 2.2.: 802.1X-Ports [Str04]

Als Kommunikationsprotokoll von 802.1X wird das Extensible Authentication Protocol (EAP)eingesetzt. Dabei werden die EAP-Pakete vom Supplicant zum Authenticator mit EAPOL(EAP over LAN) übertragen. Der Supplicant fungiert als EAP-Proxy. Er nimmt die EAP-Pakete vom Supplicant entgegen und leitet diese an den Authentifizierungsserver weiter. DieKommunikation zwischen Authenticator und Authentifizierungsserver findet in der Regel überdas RADIUS-Protokoll statt. Je nach Übertragungsrichtung muss der Authenticator die EAPPakete von EAPOL in RADIUS oder von RADIUS in EAPOL umpacken . [Rec08, S. 454 f.]


2. Grundlagen 10

Damit ein Client als Supplicant fungieren kann, benötigt er eine Authentifizierungssoftware(Supplicant). Ab Windows XP Service Pack 2 gehört ein Supplicant zum Lieferumfang vonWindows. Für andere Betriebssysteme wie Linux und Mac OS X steht auch entsprechendeSoftware zur Verfügung, oder ist teilweise schon im System integriert. [Rec08, S. 455]

2.3. EAP

Das Extensible Authentication Protocol (EAP) wird im IEEE 802.1X-Standard für die Authen-tifizierung des Supplicants verwendet. EAP ist im RFC 3748 [RFC3748] spezifiziert und wurdeursprünglich für das Point-to-Point Protocol (PPP) entwickelt. EAP ist modular aufgebaut undgibt keine Authentifizierungsmethode vor, daher wird es auch als Authentifzierungs-Frameworkbezeichnet. Je nach Sicherheitsbedarf können unterschiedliche Authentifizierungsmethoden(z. B. EAP-TLS, EAP-TTLS, EAP-PEAP) gewählt werden. [Rec08, S. 457 ff.]; [Hof05, S. 83ff.]

Die EAP-Kommunikation ist einfach gehalten und basiert auf vier verschiedenen EAP-Paketen,mit denen ein Request-Response-Verfahren zwischen Supplicant (bei EAP auch als Peerbezeichnet) und Authenticator bzw. Authentifizierungsserver umgesetzt wird. [Rec08, S. 457ff.]

EAP-Request (Code 1)Das EAP-Request-Paket wird verwendet, um Nachrichten vom Authenticator zum Supplicantzu übertragen. Es enthält die Daten der entsprechend gewählten Authentifizierungsmethode.

EAP-Response (Code 2)Das EAP-Response-Paket wird verwendet, um Nachrichten vom Supplicant zum Authenticatorzu übertragen. Auch dieses enthält die Daten der entsprechend gewählten Authentifizierungs-methode.

EAP-Success (Code 3)Die EAP-Success Nachricht teilt dem Supplicant mit, dass die Authentifizierung erfolgreichverlaufen ist.

EAP-Failure (Code 4)Die EAP-Failure Nachricht teilt dem Supplicant mit, dass die Authentifizierung nicht erfolgreichwar und der Supplicant abgelehnt wurde.

Ein EAP-Paket, dargestellt in Abbildung 2.3 auf der nächsten Seite, besteht aus den folgendenFeldern:


2. Grundlagen 11

Abbildung 2.3.: EAP-Paket [Hof05, S. 85]; [RFC3748, S. 22]

CodeDas Code-Feld ist 1 Byte lang und legt den Typ bzw. die Funktion des EAP-Pakets fest.(Request, Response, Success, Failure)

IdentifierDas Identifier-Feld ist 1 Byte lang und enthält eine laufende Nummer, an der zusammengehö-rende EAP-Request- und EAP-Response-Pakete erkannt werden, die zu einem Authentifizie-rungsvorgang gehören.

LengthDas Length-Feld ist 2 Byte lang und gibt die Länge des EAP-Pakets, inklusiv Header undDatenteil, an.

Datenfeld (nur bei EAP-Request- und EAP-Response-Paketen)EAP-Request- und EAP-Response-Pakete enthalten noch ein zusätzliches Datenfeld miteinem 1 Byte langem Type-Feld und einem darauffolgenden Datenteil (Type Data) variablerLänge, je nach gewähltem Type. Das Type-Feld legt fest, welche Information bzw. welcheAuthentifizierungsmethode über ein EAP-Request- oder ein EAP-Response-Paket transportiertwird.

Tabelle 2.3 auf der nächsten Seite gibt einen Überblick über die wichtigsten EAP-Typen.

Type 1 (Identity):EAP-Request/Identity- und EAP-Response/Identity-Pakete dienen zum Abfragen der Identitätdes Supplicants durch den Authenticator. Die Identität kann hierbei in der Form „name@realm“übermittelt werden. Die Übermittelung findet allerdings im Klartext statt. Daher solltehier, wenn möglich, eine anonyme Identität in der Form „anonymous@realm“ verwendetwerden. Diese dient nur für Routing-Zwecke, um die nachfolgenden EAP-Pakete an denrichtigen Authentifizierungsserver weiterzuleiten. Erst in den nachfolgenden EAP-Paketen mitenthaltener Authentifizierungsmethode wird die vollständige Identität übermittelt. Je nach


2. Grundlagen 12

Type-Wert Beschreibung1 Identity2 Notification3 Nak (Not acknowledged)4 MD5-Challenge5 One-Time Password (OTP)6 Generic Token Card (GTC)13 EAP-TLS17 LEAP21 EAP-TTLS25 EAP-PEAP29 EAP-MS-CHAPv2

Tabelle 2.3.: EAP-Typen [RFC3748, S. 27]; [Rec08, S. 459]; [Hof05, S. 85]

gewählter Methode kann die Übermittlung der Identität dann auf einem sicheren Weg, z. B.durch einen verschlüsselten Tunnel erfolgen. [RFC3748, S. 28 f.]; [Rec08, S. 458]

Type 2 (Notification)Über ein EAP-Request/Notification-Paket kann der Authenticator eine Nachricht in Klartext anden Supplicant schicken. Der Supplicant antwortet darauf mit einem EAP-Response/Notification-Paket. [RFC3748, S. 29 f.]; [Rec08, S. 458]

Type 3 (Nak)Falls der Supplicant eine vom Authenticator angeforderte Authentifizierungsmethode nichtunterstützt, kann er ein EAP-Response/Nak-Paket (Not acknowledged) an den Authenticatorschicken und die Authentifizierungsmethode somit ablehnen. Der Authenticator muss daraufhineine andere Methode wählen. Ist das nicht möglich, wird der Supplicant abgelehnt.[RFC3748,S. 31 ff.]; [Rec08, S. 458]

Type 4 – 253Die Typen 4 -253 stellen die unterschiedlichen Authentifizierungsmethoden dar, die für einEAP-Request/Response-Paket zur Authentifizierung verwendet werden können. Die Authenti-fizierungsmethoden unterscheiden sich zum Teil stark in ihrer Funktionsweise und Sicherheit.Daher muss man je nach Anwendungsfall genau abwägen, welche Methode für einen Fall ambesten geeignet ist. [Rec08, S. 461 ff.]; [Hof05, S. 87 ff.]; [RFC3748, S. 35 ff.]

In Tabelle 2.3, sind die wichtigsten Methoden aufgelistet. Im Nachfolgenden wird aber nur aufdie Methoden näher eingegangen, die für eine WLAN Authentifizierung nach IEEE 802.1Xeine wichtige Rolle spielen.


2. Grundlagen 13

2.3.1. EAP-TLS

EAP-TLS steht für EAP-Transport Layer Security Protocol und ist eine Authentifizierungsme-thode, die auf EAP und TLS basiert. TLS ist auch unter der Vorgängerbezeichnung SecureSocket Layer (SSL) bekannt und im RFC5246 [RFC5246] spezifiziert. EAP-TLS ist im RFC5216[RFC5216] definiert. EAP-TLS führt eine gegenseitige Authentifizierung zwischen Supplicantund Authentifizierungsserver auf Basis von TLS durch. Der TLS-Handshake läuft dabei gekap-selt in EAP-Paketen ab, die den Wert 13 im Type-Feld besitzen. EAP-TLS benötigt für diegegenseitige Authentifizierung sowohl ein Server-Zertifikat als auch jeweils ein Client-Zertifikatauf den einzelnen Supplicants. Um die Client-Zertifikate auszustellen und zu verwalten, wirdeine eigene Public Key Infrastructure (PKI) benötigt. Dies macht die Einrichtung und Verwal-tung recht aufwändig.EAP-TLS wird im WLAN-Bereich nur zur Authentifizierung und zum Aushandeln der dy-namischen Schlüssel für die WLAN-Verschlüsselung verwendet. Dabei werden aber sowohldas Server- als auch das Client-Zertifikat unverschlüsselt übertragen, was einem Angreiferermöglicht, die Identität des Nutzers zu ermitteln. Dies kann umgangen werden, indem zunächsteine TLS Verbindung zwischen Supplicant und Authentifizierungsserver aufgebaut wird, beiwelcher sich zuerst nur der Server authentifiziert. Die Authentifizierung des Clients über dasClient-Zertifikat findet dann anschließend verschlüsselt innerhalb des TLS-Tunnels statt. DieseVariante muss jedoch vom Supplicant als auch vom Server unterstützt werden. Das kann z. B.durch Kombination von EAP-PEAP mit EAP-TLS erreicht werden. [Hof05, S. 88 ff.]; [Rec08,S. 462 f.]; [RFC5216]

2.3.2. EAP-TTLS

EAP-TTLS (EAP-Tunneled Transport Layer Security Protocol) ist eine erweiterte Variantevon EAP-TLS und ist im RFC 5281 [RFC5281] spezifiziert. EAP-TTLS besitzt den Wert 21im Type-Feld eines EAP-Pakets. Ein Authentifizierungsvorgang mittels EAP-TTLS bestehtaus zwei Phasen. In der ersten Phase wird ein verschlüsselter TLS-Tunnel zwischen Supplicantund Authentifizierungsserver aufgebaut. Dazu muss sich nur der Server gegenüber dem Sup-plicant authentifizieren. Dafür wird nur ein Server-Zertifikat benötigt. Ein Client-Zertifikat,wie bei EAP-TLS, ist nicht nötig. Die Authentifizierung des Supplicants findet dann in derzweiten Phase sicher und verschlüsselt durch den TLS-Tunnel statt. Für die Authentifizierunginnerhalb des Tunnels ermöglicht EAP-TTLS ein beliebiges Authentifizierungsverfahren (z. B.PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP) zu wählen, welches dann die komplette Authenti-fizierung innerhalb des Tunnels abwickelt. Die Authentifizierung läuft dann je nach gewähltemVerfahren über Benutzername und Password. Die Identität des Nutzers wird bei EAP-TTLS


2. Grundlagen 14

erst in der zweiten Phase verschlüsselt über den Tunnel übertragen. Dadurch kann die Identitätnicht ausgespäht werden. In der ersten Phase wird lediglich eine anonymisierte Identität(anonymous@realm) des Nutzers übertragen, um die Authentifizierungsanfrage zum richtigenAuthentifizierungsserver leiten zu können. EAP-TTLS setzt im Gegensatz zu EAP-TLS keinClient-Zertifikat voraus, da die Authentifizierung des Supplicants über Benutzername undPassword innerhalb des Tunnels verläuft. Aus diesem Grund wird EAP-TTLS häufig eingesetzt,da auf den Aufbau einer PKI verzichtet werden kann. Allerdings wird EAP-TTLS nicht nativvon Windows unterstützt und kann nur durch die Installation zusätzlicher Software unterWindows genutzt werden. [Hof05, S. 92 f.]; [Rec08, S. 463]; [RFC5281]

Abbildung 2.4 zeigt die Hierarchie der einzelnen Protokolle und Pakete zusammen mit EAP-TTLS. Dabei wird jede Schicht durch die darunterliegende eingekapselt. Zunächst hat man einCarrier Protocol (Trägerprotokoll), welches ein EAP-Paket enthält. Das EAP-Paket wieder-um beinhaltet den EAP-TTLS Datenteil, welcher einen TLS-Tunnel aufbaut und darin dieDatenpakete des gewählten Authentifizierungsverfahrens verschlüsselt überträgt.

Abbildung 2.4.: EAP-TTLS Aufbau [RFC5281, S. 12]

2.3.3. EAP-PEAP

EAP-PEAP (EAP-Protected Extensible Authentication Protocol) entspricht auch einer erwei-terten Variante von EAP-TLS und besitzt den Wert 25 im Type-Feld eines EAP-Pakets. FürEAP-PEAP existiert aktuell noch kein RFC Standard, sondern nur ein Draft [PEAPDraft].Die Authentifizierung läuft ähnlich ab wie bei EAP-TTLS. In der ersten Phase wird auchhier ein sicherer, verschlüsselter TLS-Tunnel zwischen Supplicant und Authentifizierungsserver


2. Grundlagen 15

aufgebaut, wobei sich nur der Server mittels eines Zertifikats authentifizieren muss. In derzweiten Phase findet dann die Authentifizierung des Supplicants innerhalb des verschlüsseltenTLS-Tunnels statt. Als Authentifizierungsverfahren innerhalb des Tunnels setzt EAP-PEAPwiederum EAP ein („inneres“ EAP). Durch das „innere“ EAP können wiederum alle EAP-Methoden zum Authentifizieren verwendet werden. Häufig wird hier aber die EAP-Methode mitType-Wert 29 (EAP-MS-CHAPv2) verwendet. Für EAP-PEAP/EAP-MS-CHAPv2 werdenauch keine Client-Zertifikate benötigt, da hier die Authentifizierung innerhalb des Tunnelsmittels Benutzername und Password stattfindet. Die Identität des Nutzers wird auch wiebei EAP-TTLS erst in der zweiten Phase verschlüsselt über den Tunnel übertragen, dadurchkann die Identität nicht ausgespäht werden. Die Kombination von EAP-PEAP mit EAP-MS-CHAPv2 ist weit verbreitet und wird ab Windows XP SP1 nativ von Windows unterstütz.Auch andere Plattformen, wie z. B. Mac OS X oder auch gängige Smartphone-Betriebssystemeunterstützen EAP-PEAP/EAP-MS-CHAPv2. [Hof05, S. 92 f.]; [Rec08, S. 463]; [PEAPDraft]

Abbildung 2.5 zeigt die Hierarchie der einzelnen Protokolle und Pakete zusammen mit EAP-PEAP. Dabei wird jede Schicht durch die darunterliegende eingekapselt. Zunächst hat man einCarrier Protocol (Trägerprotokoll), welches ein EAP-Paket enthält. Das EAP-Paket beinhaltetden EAP-PEAP Datenteil, welcher einen TLS-Tunnel aufbaut, indem wiederum EAP-Pakete(„inneres“ EAP) verschlüsselt übertragen werden. Die „inneren“ EAP-Pakete enthalten danndie gewählte EAP-Authentifizierungsmethode.

Abbildung 2.5.: EAP-PEAP Aufbau [PEAPDraft, S. 27]


2. Grundlagen 16

2.3.4. MS-CHAPv2

MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) ist eineAuthentifizierungsmethode von Microsoft, die im RFC 2759 [RFC2759] spezifiziert ist. ImGegensatz zu PAP (Password Authentication Protocol), wo Benutzername und Passwort imKlartext übertragen werden, basiert MS-CHAP v2 auf dem Challenge-Handshake Authentica-tion Protocol (CHAP).Bei CHAP handelt es sich um ein 3-Wege-Handshake Request/Response Protokoll. Nach er-folgreichem Verbindungsaufbau und Identifikation beim Server erhält der Client eine Challenge(Zufallszahl) vom Server. Der Client bildet aus der Challenge und dem Passwort einen Hashwertund sendet diesen an den Server (Response). Der Server bildet ebenfalls den Hashwert aus derZufallszahl und dem hinterlegten Passwort. Wenn beide Hashwerte übereinstimmen, wird dieAuthentifizierung des Clients akzeptiert (Accept), andernfalls wird diese abgelehnt (Reject).[EleCHAP]

Der Ablauf von CHAP kann Abbildung 2.6 entnommen werden.

Abbildung 2.6.: CHAP Authentifizierung [EleCHAP]

MS-CHAP v2 setzt im Gegensatz zu CHAP auf gegenseitige Authentifizierung. Das bedeutet,dass sich sowohl Client als auch Server gegenseitig authentifizieren und bestätigen, das Kennwortdes Benutzers zu kennen. Bei CHAP hingegen wird nur der Client authentifiziert.

1. Der Server fordert den Client zur Authentifizierung auf und schickt eine Challengebestehend aus einer Session-ID (Session Identifier) und einem zufälligen Wert (ChallengeString) an den Client.

2. Der Client erzeugt ebenfalls einen zufälligen Wert (Peer Challenge String) und bildetaus diesem, dem Challenge String, der Session-ID und seinem Passwort einen Hashwert.Den Hashwert schickt er zusammen mit seinem Benutzernamen und dem Peer ChallengeString an den Server zurück (Response).


2. Grundlagen 17

3. Der Server bildet ebenfalls den Hashwert aus Peer Challenge String, Challenge String,Session-ID und Benutzerpasswort und vergleicht diesen mit dem vom Client empfangenHash. Wenn beide Hashwerte übereinstimmen, sendet der Server eine Annahmebestäti-gung (Accept), ansonsten eine Ablehnung (Reject) an den Client. Die Annahme enthälteinen Hashwert, gebildet aus dem Challenge String, dem Peer Challenge String, demvom Client geschickten Hashwert und dem Benutzerpasswort.

4. Der Client überprüft jetzt den vom Server erhaltenen Hashwert. Stimmt dieser mitseinem selber berechneten Hashwert überein, wird die Verbindung akzeptiert, andernfallsbricht der Client die Verbindung ab. [EleCHAPv2]; [TecCHAPv2]

Der Ablauf von MS-CHAP v2 ist in Abbildung 2.7 dargestellt.

Abbildung 2.7.: MS-CHAPv2 Authentifizierung [EleCHAPv2; TecCHAPv2]

In EAP-Paketen kann MS-CHAPv2 als EAP-Authentifizierungsmethode eingesetzt werden(EAP-MS-CHAPV2 mit dem Wert 29 im Type-Feld). Die Authentifizierung mittels EAP-MS-CHAPv2 erfolgt aber nicht verschlüsselt. Daher wird EAP-MS-CHAPv2 meistens inKombination mit EAP-PEAP eingesetzt. Hier fungiert EAP-MS-CHAPv2 dann als inneresAuthentifizierungsverfahren innerhalb eines verschlüsselten TLS-Tunnels.

2.4. EAPOL

Um EAP-Pakete zwischen dem Supplicant und dem Authenticator über LAN bzw. WLAN zutransportieren, wird ein Carrier Protocol (Trägerprotokoll) benötigt. Dafür ist im IEEE 802.1X-Standard EAPOL (EAP over LAN) spezifiziert. Alle EAP-Pakete, die zwischen Supplicant undAuthenticator ausgetauscht werden, werden in einen EAPOL-Frame gepackt, welcher dannüber LAN oder WLAN auf „Layer 2 Ebene“ (eingebettet in ein Ethernet-Frame) übertragenwird. Dazu gibt es fünf verschieden EAPOL-Frames. [Rec08, S. 459 f.]


2. Grundlagen 18

EAPOL-Packet (Type 0)Mit Hilfe von EAPOL-Packet-Frames werden EAP-Pakete über LAN bzw. WLAN transportiert.Dazu wird ein EAP-Paket in den Packet-Body eines EAPOL-Packet-Frames gepackt.

EAPOL-Start (Type 1)Ein EAPOL-Start-Frame wird zur Eröffnung der Kommunikation verwendet. Der Supplicantmuss zunächst die MAC-Adresse des Authenticators ermitteln. Dazu sendet der Supplicantein EAPOL-Start-Frame an die Multicast-Adresse 00:80:C2:00:00:03, welche speziell für denAuthenticator reserviert ist und nicht über Bridges weitergeleitet wird. Auf diesem Weg teiltder Supplicant dem Authenticator mit, dass er sich authentifizieren möchte. Der Authenticatorreagiert dann darauf mit einem EAP-Request/Identity-Paket innerhalb eines EAPOL-Packet-Frames.

EAPOL-Logoff (Type 2)Mit dem EAPOL-Logoff-Frame kann der Supplicant dem Authenticator mitteilen, dass er dieKommunikation beenden und das Netzwerk verlassen möchte.

EAPOL-Key (Type 3)EAPOL-Key-Frames werden nach erfolgreicher Authentifizierung zum Aushandeln der tem-porären und geheimen Schlüssel für die WLAN-Verschlüsselung zwischen Supplicant undAuthenticator verwendet.

EAPOL-Encapsulated-ASF-Alert (Type 4)Über EAPOL-Encapsulated-ASF-Alert-Frames können Fehler- und Warnmeldungen über nichtautorisierte (geschlossene) Ports übertragen werden.

Ein EAPOL-Frame, wie in Abbildung 2.8 dargestellt, besteht aus den folgenden Feldern:

Abbildung 2.8.: EAPOL-Frame [Rec08, S. 460]

Protocol VersionDas Protocol-Version-Feld ist 1 Byte lang und legt die Version des Protokolls fest. Im Momenthat das Feld immer den Wert 1.

Packet TypeDas Packet-Type-Feld ist 1 Byte lang und legt den Typ das EAPOL-Frames fest. (Packet,Start, Logoff, Key, Encapsulated-ASF-Alert)


2. Grundlagen 19

Packet Body LengthDas Packet-Body-Length-Feld ist 2 Byte lang und gibt die Länge des EAPOL-Packet-Body-Feldes an. Ist der Wert auf 0 gesetzt, dann ist kein Packet-Body-Feld vorhanden.

Packet BodyNur EAPOL-Frames von Typ 0 (EAPOL-Packet), 3 (EAPOL-Key) und 4 (EAPOL-Encapsulated-ASF-Alert) enthalten ein Packet-Body-Feld, welches die eigentlichen Daten beinhaltet. ZumBeispiel ist bei Typ 0 ein EAP-Paket im Body-Feld enthalten und bei Typ 3 handelt es sichum Informationen zum Aushandeln der Schlüssel.

2.5. RADIUS

RADIUS (Remote Authentication Dial-In User Service) ist ein Server-Dienst mit zugehörigemKommunikationsprotokoll und ist im RFC 2865 [RFC2865] spezifiziert. Dabei wird das RADIUS-Protokoll eingesetzt, um EAP-Pakete zwischen dem Authenticator, welcher bei RADIUS auchals Network Access Server (NAS) bezeichnet wird, und dem Authentifizierungsserver überLAN zu transportieren. Dies setzt natürlich voraus, dass auf dem Authentifizierungsserverein RADIUS-Server läuft, der die Aufgaben Authentifizierung, Autorisierung und Accounting(AAA-Server) übernimmt. Alle EAP-Pakete, die zwischen Authenticator und RADIUS-Serverausgetauscht werden, werden in ein RADIUS-Paket gepackt, welches dann über UDP übertragenwird. Die Default-RADIUS-Ports sind UDP-Port 1812 für Authentifizierungsanfragen undUDP-Port 1813 für Accounting-Anfragen. Diese Ports müssen für eine erfolgreiche RADIUS-Kommunikation freigeschaltet sein. [Hof05, S. 95 ff.]; [Rec08, S.454]; [Edn03]

2.5.1. RADIUS-Protokoll

Das RADIUS-Protokoll unterstützt neun verschiedene Pakete, wobei bei einer Authentifizierungmittels 802.1X nur vier Pakete eine wichtige Rolle spielen.

Access-Request (Code 1)Das Access-Request-Paket wird verwendet, um Nachrichten vom Authenticator zum RADIUS-Server zu übertragen. Das Paket übermittelt dabei Informationen wie Benutzername undPasswort direkt innerhalb des RADIUS-Pakets als RADIUS-Attribut oder auch gekapseltinnerhalb eines EAP-Response-Pakets mit Authentifizierungsmethode, welches wiederum indas RADIUS-Paket gepackt ist.

Access-Accept (Code 2)Das Access-Accept-Paket wird vom RADIUS-Server zum Authenticator übertragen, sobald


2. Grundlagen 20

die Authentifizierung des Supplicants erfolgreich war. Der Authenticator kann daraufhin demSupplicant Zugriff auf das Netz gewähren. Falls die Authentifizierung auf EAP basiert, befindetsich innerhalb des Access-Accept-Pakets ein EAP-Success-Paket.

Access-Reject (Code 3)Das Access-Reject-Paket wird vom RADIUS-Server zum Authenticator übertragen, wenndie Authentifizierung des Supplicants fehlgeschlagen ist. Falls die Authentifizierung auf EAPbasiert, befindet sich innerhalb des Access-Reject-Pakets ein EAP-Failure-Paket.

Access-Challenge(Code 11)Das Access-Challenge-Paket wird verwendet, um Nachrichten vom RADIUS-Server zumAuthenticator zu übertragen. Das Paket übermittelt dabei Informationen direkt innerhalb desRADIUS-Pakets als RADIUS-Attribut oder auch gekapselt innerhalb eins EAP-Request-Paketsmit Authentifizierungsmethode, welches wiederum in das RADIUS-Paket gepackt ist.

Ein RADIUS-Paket, welches in Abbildung 2.9 zu sehen ist, hat folgenden Aufbau:

Abbildung 2.9.: RADIUS-Paket [Hof05, S. 96]

CodeDas Code-Feld ist 1 Byte lang und legt den Typ bzw. die Funktion des RADIUS-Pakets fest.(Request, Accept, Reject, Challenge)

IdentifierDas Identifier-Feld ist 1 Byte lang und enthält eine laufende Nummer, an der zusammengehö-rende Access-Request- und Access-Challenge-Pakete erkannt werden.

LengthDas Length-Feld ist 2 Byte lang und gibt die Länge des RADIUS-Pakets an.


2. Grundlagen 21

AuthenticatorDas Authenticator-Feld ist 16 Byte lang und hat die Aufgabe, Antwort-Pakete vom RADIUS-Server zum Authenticator zu authentifizieren. Damit kann sichergestellt werden, dass einAntwort-Paket auch wirklich von dem RADIUS-Server stammt, an den die Anfrage gestelltwurde, und dass es unterwegs nicht verändert wurde. Dazu schickt der Authenticator in einemAccess-Request einen Zufallswert (Nonce) im Authenticator-Feld mit (Request Authenticator).In einem Antwort-Paket (Access-Accept /-Reject /-Challenge) berechnet der RADIUS-Servereinen Hashwert über das Antwort-Paket mit dem Request Authenticator und einem Secret-Key (shared secret), welcher zuvor auf Authenticator und RADIUS-Server hinterlegt wurde.Der Hashwert wird im Authenticator-Feld des Antwort-Pakets übermittelt und als ResponseAuthenticator bezeichnet. Eine weitere Aufgabe des Authenticator-Feld ist es, Passwörter,die sich direkt in Access-Request-Paketen befinden und an den RADIUS-Server übermitteltwerden, zu verschlüsseln. Dies geschieht mit Hilfe des zufälligen Request Authenticators unddem Secret-Key.

AttributesDas Attributes-Feld beinhaltet RADIUS-Attribute, in welchen die relevanten Informationeninnerhalb eines RADIUS-Pakets übertragen werden. Jedes RADIUS-Paket kann mehrereAttribute transportieren. Ein Attribut besteht aus folgenden drei Feldern: Type, Length (Längedes Attributs), Value (Datenteil des Attributs). Das Type-Feld gibt den Typ des Attributs an.Es gibt Attribute für unterschiedliche Zwecke, beispielsweise um Benutzername (Type 1) undPasswort (Type 2) direkt über RADIUS zu übertragen (PAP). Auch für das CHAP-Verfahrenstehen Attribute bereit. Ein RADIUS-Paket lässt sich daher beliebig erweitern, indem neueAttribute definiert werden. Um EAP-Pakete über RADIUS zu transportieren, gibt es einAttribut mit Type-Wert 79. Dieses Attribut kapselt ein EAP-Paket und überträgt es somitgekapselt über RADIUS. Dies ist im RFC3579 [RFC3579] spezifiziert.

2.5.2. RADIUS-Geräte

Es gibt drei unterschiedliche Zustände, die ein RADIUS-Gerät annehmen kann. Es ist auchmöglich, dass ein RADIUS-Gerät mehrere Zustände annehmen kann.

RADIUS-ClientEin RADIUS-Client schickt RADIUS-Anfragen (Access-Request-Pakete) an einen RADIUS-Server. Bei der 802.1X Authentifizierung fungiert der Authenticator als RADIUS-Client.

RADIUS-ServerEin RADIUS-Server nimmt RADIUS-Anfragen entgegen (Access-Request-Pakete) und bear-beitet diese. Er führt die Authentifizierung des Supplicants durch. Anschließend antwortet er


2. Grundlagen 22

dem RADIUS-Client mit einem Access-Accept- oder Access-Reject-Paket.

RADIUS-ProxyEin RADIUS-Proxy nimmt RADIUS-Anfragen entgegen und leitet diese an einen weiterenRADIUS-Proxy oder an einen RADIUS-Server weiter. Dabei können RADIUS-Server auch alsRADIUS-Proxy arbeiten. Falls Anfragen nicht intern authentifiziert werden können, werdendiese an einen anderen RADIUS-Server weitergeleitet.

2.6. RadSec

RadSec (RADIUS Security) ist ein sicheres RADIUS-Protokoll, für welches es noch keinenRFC-Standard gibt, sondern nur einen Draft [RadSecDraft]. RadSec setzt dabei auf die Über-tragung von RADIUS-Paketen innerhalb eines sicheren, verschlüsselten TLS-Tunnels über dasTCP-Protokoll. Der Standardport für RadSec ist TCP-Port 2083, über den alle RadSec-Paketelaufen.RadSec wurde entwickelt, um einige Nachteile von RADIUS zu verbessern. Das RADIUS-Protokoll arbeitet über das UDP-Protokoll und überträgt die Daten in RADIUS-Paketenteilweise im Klartext, wie z. B. den Benutzernamen. Das Benutzerpasswort wird zwar ver-schlüsselt übertragen, allerdings nur mit Hilfe des Secret-Keys und einem MD5-Hash, was nureine schwache Verschlüsselung darstellt. Solange die RADIUS-Pakete innerhalb eines sichereninternen Netzwerks (Intranet) ausgetauscht werden, stellt das eigentlich kein Problem dar.Sobald aber RADIUS-Pakete über das Internet verschickt werden, wobei viele unbekannteund auch potentiell unsichere Netze durchlaufen werden, besteht eine gewisse Gefahr, dassRADIUS-Pakete mitgelesen werden. Weiterhin authentifizieren sich ein RADIUS-Client undein RADIUS-Server nur über den hinterlegten Secret-Key und ihre IP-Adressen. RadSechingegen nutzt das TCP-Protokoll und baut einen TLS-Tunnel auf, bei dem sich sowohl derRADIUS-Client als auch der RADIUS-Server gegenseitig mittels eines gültigen Zertifikatsauthentifizieren. Die RADIUS-Pakete werden dann verschlüsselt über den Tunnel übertragen.TCP sorgt zudem für eine hohe Stabilität der Verbindung, da der Status der Verbindung imGegensatz zu UDP bekannt ist.Es biete sich an, RadSec zu nutzen, sobald RADIUS-Pakete in unsicheren Netzen (Internet /WAN) übertragen werden. Dies ist z. B. bei Roaming-Diensten wie DFNRoaming/eduroam derFall. Im Intranet wird weiterhin ein normaler RADIUS-Server betrieben. Um RADIUS-Paketeüber einen TLS-Tunnel zu übertragen, wird ein RADIUS-Server benötigt, der RadSec unter-stützt (z. B. Radiator http://www.open.com.au). Alternativ kann auch ein RADIUS-Proxy wieder frei verfügbare „radsecproxy“ von UNINETT (http://software.uninett.no/ radsecproxy)eingesetzt werden. RADIUS-Pakete werden dabei vom RADIUS-Proxy entgegen genommen


http://www.open.com.au

http://software.uninett.no/radsecproxy

2. Grundlagen 23

und dann über einen TLS-Tunnel zu einem weiteren RADIUS-Server /-Proxy weitergeleitet.[RadSecDraft; RadSec05]

2.7. Ablauf der 802.1X Authentifizierung

Im Folgenden wird der komplette Ablauf einer Authentifizierung nach dem IEEE 802.1X-Standard am Beispiel von WLAN zusammen mit einem RADIUS-Server gezeigt. Als Authenti-fizierungsverfahren wird EAP-PEAP/EAP-MS-CHAPv2 verwendet. Der detaillierte Ablaufkann Abbildung 2.11 auf Seite 25 entnommen werden.

Zu Beginn meldet sich der Client am Access Point über eine Open-System-Authentifizierung anund führt anschließend eine Assoziierung durch, in der die gegenseitig technischen Fähigkeitenund unterstützten Sicherheitsmethoden ausgetauscht werden. Der Client ist jetzt mit demAccess Point verbunden, hat aber noch keinen Zugriff auf das dahinterliegende Netzwerk.Im nächsten Schritt folgt die Authentifizierung nach 802.1X. Die Authentifizierung über dasWLAN erfolgt nicht verschlüsselt. Die WLAN-Verschlüsselung wird erst nach erfolgreicherAuthentifizierung aktiviert.Der Client schickt zunächst ein EAPOL-Start-Frame an den Access Point, um die Authen-tifizierung einzuleiten. Daraufhin schickt der Access Point ein EAP-Request/Identity-Paketan den Client, um die Identität des Clients abzufragen. Da die Identität im Klartext über-tragen wird, antwortet der Client zunächst nur mit seiner „äußeren“ (anonymen) Identität(anonymous@realm). Die äußere Identität wird benötigt, um die EAP-Pakete an den richtigenAuthentifizierungsserver weiterzuleiten. Dies geschieht anhand des Realm. Der Access Pointleitet die Antwort vom Client über einen unkontrollierten Port an den RADIUS-Server, inner-halb eines RADIUS-Access-Request-Paket, weiter. Zwischen Access Point und RADIUS-Serverkönnen sich mehrere RADIUS-Proxys befinden, die die Pakete anhand des Realm an den rich-tigen RADIUS-Server weiterleiten. Der RADIUS-Server schickt darauf ein EAP-Request-Paketvom Typ PEAP an den Client, um eine Authentifizierung nach der EAP-PEAP Authentifizie-rungsmethode einzuleiten.Zuerst wird der TLS-Tunnel zwischen Client und RADIUS-Server aufgebaut. Dazu folgt einAustausch mehrerer EAP-Request- und EAP-Response-Pakete, in denen das Handshake fürden Tunnelaufbau vollzogen wird. Nach Aufbau des Tunnels, wird innerhalb des Tunnels mitder eigentlichen Authentifizierung nach der Authentifizierungsmethode EAP-MS-CHAPv2begonnen. Dies geschieht mittels der „inneren“ EAP-Pakete (im Bild 2.11 auf Seite 25, rot in ge-schweiften Klammern dargestellt), welche verschlüsselt innerhalb des TLS-Tunnels übertragenwerden. Zunächst wird auch wieder ein EAP-Response/Identity-Paket zum Server übertragen.Da dies jetzt allerdings verschlüsselt verläuft, wird hier die vollständige Identität des Clients


2. Grundlagen 24

übertragen. Im nächsten Schritt beginnt die eigentliche Authentifizierung mittels der Authenti-fizierungsmethode EAP-MS-CHAPv2. In mehreren EAP-Request- und EAP-Response-Paketenwird das Handshake durchgeführt. Nach erfolgreichem Abschluss der Authentifizierung, sendetder Server ein RADIUS-Access-Accept-Paket an den Access Point. In diesem Paket ist eineEAP-Success-Nachricht enthalten, welche an den Client weitergeleitet wird. Zusätzlich ist auchnoch ein Schlüssel enthalten (Pairwise Master Key (PMK)), welcher bei der Authentifizierungzwischen Client und Server ausgehandelt wurde.Der Client ist jetzt erfolgreich authentifiziert. Bevor er allerdings Zugriff auf das Netz erhält,werden die Schlüssel für die WLAN-Datenverschlüsselung zwischen Client und Access Pointausgehandelt. Hierzu wird der vorhin erzeugte PMK benötigt. Dies erfolgt wie unter 2.7.1auf der nächsten Seite beschrieben. Nach erfolgreichem Aushandeln der Schlüssel wird derkontrollierte Port vom Access Point für den Client geöffnet und der Client erhält vollenZugriff auf das Netzwerk. Der Datenverkehr zwischen Access Point und Client erfolgt ab jetztverschlüsselt durch WPA- oder WPA2-Verschlüsselung. [Rec08, S. 469 ff.]; [Edn03]

Abbildung 2.10 zeigt die beteiligten Protokolle anhand eines Schichtenmodells. Die Paketeeiner Schicht sind dabei in den Paketen der jeweils darunter liegenden Schicht gekapselt.Wie zu erkennen ist, wird der TLS-Tunnel zwischen Client und RADIUS-Server aufgebaut.Innerhalb des Tunnels werden die „inneren“ EAP-Pakete mit gekapselten MS-CHAPv2-Paketenverschlüsselt übertragen (in rot dargestellt). Die im Tunnel übertragenen Pakete können nurvom Client und vom RADIUS-Server gelesen werden. Der Access Point und ggf. weitereRADIUS-Proxys zwischen Access Point und RADIUS-Server haben darauf keinen Zugriff. DerAccess Point sieht nur die „äußeren“ EAP-Pakete, welche er von EAPOL in RADIUS umpackt.

Abbildung 2.10.: Schichtenmodell der Protokolle bei der 802.1X Authentifizierung


2. Grundlagen 25

Abbildung 2.11.: Ablauf der 802.1X Authentifizierung

2.7.1. Schlüsselmanagement

Für die Verschlüsselung der WLAN-Verbindung zwischen WLAN-Client (Supplicant) undAccess Point (Authenticator) wird nach dem IEEE 802.11i-Standard eine Schlüsselhierarchieverwendet, aus der die Schlüssel für die Verschlüsselung der Datenpakete abgeleitet werden. ImFolgenden wird die Schlüsselhierarchie bezogen auf das AES-CCMP Verschlüsselungsverfahrenmit Authentifizierung nach dem IEEE 802.1X-Standard (WPA2-Enterprise) beschrieben.Es gibt zwei „Arten“ von Schlüsselhierarchien. Einmal die paarweise Schlüsselhierarchie, diedie Schlüssel für die Unicast-Frames verwaltet und die gruppenweise Schlüsselhierarchie, die


2. Grundlagen 26

die Schlüssel für die Multicast- bzw. Broadcast-Frames verwaltet. Für die verschlüsselteÜbertragung der Unicast-Frames wird ein individueller paarweiser Schlüssel verwendet, der nurdem entsprechenden Client und dem Access Point bekannt ist. Jeder Client hat dabei seineneigenen Schlüssel, um mit dem Access Point verschlüsselt zu kommunizieren. Die Übertragungder Multicast- und Broadcast-Frames erfolgt verschlüsselt über einen Gruppenschlüssel, derallen WLAN-Stationen bekannt ist und vom Access Point an diese verteilt wird. [Rec08, S.467]; [Edn03]

Als erstes wird ein Schlüssel für die Unicast-Frames ausgehandelt. Dazu wird während der802.1X Authentifizierungsphase beim Client und beim Authentifizierungsserver (RADIUS-Server) ein paarweiser Schlüssel erzeugt, der als Master Key bezeichnet wird. Von diesemKey wird der sogenannte Pairwise Maser Key (PMK) abgeleitet. Der PMK wird dann vomAuthentifizierungsserver, nach erfolgreicher Authentifizierung des Clients, über das RADIUS-Accept-Paket (innerhalb eines RADIUS-Attributs) zum Access Point transportiert.Client und Access Point verfügen jetzt beide über den selben PMK. Dieser Zustand wird alsPairwise Master Key Security Association (PMSKA) bezeichnet. Der PMK hat eine Längevon 256 Bits und entspricht quasi dem Pre-Shared Key, welcher aus einem Passphrase beiWPA2-Personal abgeleitet wird. Im Gegensatz zu WPA2-Enterprise ist der Pre-Shared Key beiWPA2-Personal auf allen WLAN Stationen der gleiche. Bei WPA2-Enterprise hingegen besitztjeder Client seinen eigenen PMK. Aus dem PMK wird dann mittels eines 4-Wege-HandshakeVerfahrens über EAPOL-Key-Frames, der Pairwise Transient Key (PTK) erzeugt. Der PTKhat eine Länge von 384 Bits und wird in drei Schlüssel eingeteilt: [Rec08, S. 468 f.]; [Edn03]

EAPOL-Key Confirmation Key (KCK)Schlüssel wird für die Integritätskontrolle (MIC) der EAPOL-Key-Frames verwendet.

EAPOL-Key Encryption Key (KEK)Schlüssel wird für Verschlüsselung des Datenfelds von EAPOL-Key-Frames, um Gruppen-schlüssel (GTK) auszutauschen, verwendet.

Temporal Key (TK)Temporärer Schlüssel wird für Datenverschlüsselung und Integritätsprüfung mittels AES-CCMPVerfahren verwendet.

Die Schlüsselhierarchie ist in Abbildung 2.12 auf der nächsten Seite dargestellt.

Beim 4-Wege-Handshake zur Erzeugung des PTK wird zunächst ein EAPOL-Key-Framevom Access Point zum Client gesendet, in dem ein Zufallswert (ANonce) enthalten ist. DerClient erzeugt darauf einen eigenen Zufallswert (SNonce) und bildet aus ANonce und SNoncezusammen mit dem PMK den PTK. Der Client schickt jetzt ein EAPOL-Key-Frame an denAccess Point, in dem die SNonce enthalten ist. Der Access Point kann jetzt auch den PTK ausder SNonce, der ANonce und dem PMK berechnen. Anschließend sendet der Access Point ein


2. Grundlagen 27

Abbildung 2.12.: Schlüsselhierarchie der paarweisen Schlüssel [Rec08, S. 469]

EAPOL-Key-Frame an den Client, in welchem dem Client mitgeteilt wird, dass der PTK jetztinstalliert werden soll. Daraufhin bestätigt der Client dem Access Point die Installation desSchlüssels mittels eines weiteren EAPOL-Key-Frames. Sowohl Client als auch Access Pointverfügen jetzt über den selben PTK bestehend aus KCK, KEK und TK. [Rec08, S. 471 f.];[Edn03]

Abbildung 2.14 auf der nächsten Seite zeigt den Ablauf der Schlüsselaushandlung.

Im nächsten Schritt wird der Group Temporal Key (GTK) über ein 2-Wege-Handshakeausgetauscht, welcher für die Übertragung der Multicast- und Broadcast-Frames dient. Dazuerstellt der Access Point einen Group Master Key (GMK), von welchem dann der GroupTemporal Key (GTK) mit Hilfe einer Zufallszahl (Nonce) abgeleitet wird. Der GTK hateine Länge von 128 Bit und wird an alle angemeldeten Clients über EAPOL-Key-Framesverschlüsselt übertragen. Dies läuft über ein 2-Wege-Handshake. Der Access Point sendetein EAPOL-Key-Frame an den Client, in welchem der GTK verschlüsselt durch den KEKenthalten ist und fordert den Client auf, den GTK zu installieren. Der Client antwortet daraufmit einem EAPOL-Key-Frame und bestätigt die Installation des GTK. [Rec08, S. 473]; [Edn03]

Die Schlüsselhierarchie der Gruppenschlüssel kann Abbildung 2.13 auf der nächsten Seiteentnommen werden.


2. Grundlagen 28

Abbildung 2.13.: Schlüsselhierarchie der Gruppenschlüssel [Rec08, S. 469]

Abbildung 2.14.: Schlüsselaushandlung (Handshake) [Rec08, S. 472]

Sowohl Client als auch Access Point verfügen jetzt über den selben PTK und GTK und könnennun mit einer verschlüsselten Kommunikation über das AES-CCMP Verfahren beginnen. DasAushandeln der Schlüssel stellt den Abschluss der 802.1X Authentifizierung dar. Jetzt kannder Access Point (Authenticator) seinen Port öffnen und dem Client (Supplicant) Zugriff aufdas Netz gewähren.


2. Grundlagen 29

2.7.2. Roaming und 802.1X

Bei WLAN-Roaming und einer Authentifizierung nach IEEE 802.1X kann es beim Wechselnin eine andere Funkzelle zu Verzögerungen kommen. Beim Wechseln in eine andere Funkzelle,wird der Access Point und somit der Authenticator gewechselt. Dies führt dazu, dass ein Clienterst neu authentifiziert werden muss, bevor er wieder Zugriff auf das Netz hat. Da bei derAuthentifizierung, je nach gewähltem Verfahren (EAP-Methode), erst größere Frames mit demAuthenticator ausgetauscht werden müssen, kann es zu merkbaren Verzögerungen kommen.Deshalb bietet der IEEE 802.11i-Standard zwei Verfahren an, um die Roaming-Verzögerungzu minimieren. [Rec08, S. 475]

PMKSA-CachingBeim PMKSA-Caching speichern Client und Access Point den bei der Authentifizierung ausge-handelten PMK für ein bestimmte Zeit zwischen, auch wenn der Client die Verbindung zumAccess Point verliert. Möchte sich der Client erneut mit diesem Access Point verbinden, wirdüberprüft, ob der Access Point den PMK des Clients noch kennt. Ist dies der Fall, kann dieAuthentifizierung übersprungen werden und es wird gleich das 4-Wege-Handshake zum Aus-handeln des PTK begonnen. Da der PTK neu ausgehandelt wird, wird beim Wiederverbindenauch ein neuer Schlüssel für die Verschlüsselung verwendet. [Rec08, S. 476]

Pre-AuthenticationBeim Pre-Authentication-Verfahren führt ein Client, sobald er feststellt, dass die Verbindungschlechter wird, bereits eine Authentifizierung über den „neuen“ Access Point durch, mitwelchem als nächstes eine Verbindung aufgebaut werden soll. Die Authentifizierung erfolgtdabei noch mit Hilfe des „alten“ Access Point, mit welchem der Client noch verbunden ist, unddem dahinter liegenden Distributionssystem (z. B. drahtgebundenes LAN). Sobald der Clientsich dann mit dem „neuen“ Access Point verbindet, kann gleich mit dem 4-Wege-Handshakezum Aushandeln des PTK begonnen werden. [Rec08, S. 476 f.]; [Edn03]

2.8. eduroam

Eduroam steht für „education roaming“ und ist ein sicherer, weltweiter Roaming-Service fürinternationale Forschungs- und Bildungseinrichtungen.Eduroam ist ein regionales Bündnis von nationalen Forschungs- und Wissenschaftsnetzen.Im Moment gibt es vier Bündnisse auf regionaler Ebene (eduroam Canada, eduroam USA,eduroam APAN (Asia-Pacific), eduroam Europe).Eduroam bietet Studenten, Forschern und Mitarbeitern von einer an eduroam teilnehmendenInstitution, die Möglichkeit, an allen anderen Institutionen, welche auch an eduroam teilnehmen,


2. Grundlagen 30

sicheren Zugang über das dortige WLAN auf das Internet zu erhalten. [edu11]

Das Prinzip dabei ist, dass die Benutzerauthentifizierung bei der Heimatinstitution erfolgt. DieAutorisierung für den Zugriff auf das WLAN erfolgt hingegen bei der jeweiligen Einrichtungselber. [edu10]

Die eduroam Technologie basiert auf dem 802.1X Standard und einer Hierarchie von RADIUS-Proxy-Servern. Die RADIUS-Proxy-Server leiten dabei die Benutzerauthentifizierung zurjeweiligen Heimateinrichtung des Nutzers weiter, wo diese geprüft und bestätigt wird. Beierfolgreicher Authentifizierung erhält der Nutzer Zugang auf das WLAN der entsprechendenEinrichtung. [edu11]

Um an eduroam teilnehmen zu können, benötigt eine Einrichtung einen internen RADIUS-Server, welcher für die Authentifizierung der eigenen Nutzer dient. Dieser RADIUS-Servermuss wiederum an den nationalen Top-Level RADIUS-Proxy angebunden werden, an wel-chen Authentifizierungsanfragen von externen Nutzern weitergeleitet werden. Der nationaleTop-Level RADIUS-Proxy wird in Deutschland durch das Deutsche Forschungsnetz gestellt(DFN-Roaming (2.9.3)). Der Top-Level RADIUS-Proxy des DFN ist wiederum mit dem euro-päischen Top-Level RADIUS-Proxy von eduroam verbunden, welcher von SURFnet in denNiederlanden und UNI-C in Dänemark betrieben wird. [edu11]Diese Hierarchie von RADIUS-Proxy-Servern ermöglicht das Weiterleiten der Authentifi-zierungsanfragen an die jeweiligen Institutionen nicht nur innerhalb eines Landes, sondernländerübergreifend innerhalb des kompletten eduroam Verbundes.

2.9. Das Deutsche Forschungsnetz

Das Deutsche Forschungsnetz (DFN) ist das von der Wissenschaft selbst organisierte Kom-munikationsnetz für Wissenschaft und Forschung in Deutschland. Es verbindet Hochschulenund Forschungseinrichtungen miteinander und ist nahtlos in den europäischen und weltweitenVerbund der Forschungs- und Wissenschaftsnetze integriert. Über mehrere leistungsstarkeAustauschpunkte ist das DFN ebenfalls mit dem allgemeinen Internet verbunden. Zudembietet das DFN seinen Anwendern eine Vielzahl maßgeschneiderter Kommunikationsdienste(z. B. DFNRoaming/eduroam). [DFN11c]

2.9.1. DFN-Verein

Träger des Deutschen Forschungsnetzes ist der DFN-Verein mit Sitz in Berlin. Er wurde 1984gegründet und verfolgt ausschließlich gemeinnützige Zwecke. Der-Verein besteht aus über 300


2. Grundlagen 31

institutionellen Mitgliedern von Hochschulen, Forschungseinrichtungen sowie forschungsnaherUnternehmen der gewerblichen Wirtschaft. [DFN11b]

2.9.2. Wissenschaftsnetz X-WiN

Das Wissenschaftsnetz X-WiN ist die technische Plattform des Deutschen Forschungsnetzes.Über das X-WiN sind Hochschulen, Forschungseinrichtungen und forschungsnahe Unternehmenin Deutschland untereinander mit den Wissenschaftsnetzen in Europa und auf anderen Konti-nenten verbunden. Darüber hinaus verfügt das X-WiN über leistungsstarke Austauschpunktemit dem allgemeinen Internet.Mit Anschlusskapazitäten bis zu 10 Gigabit/s und einem Terabit-Kernnetz zählt das X-WiNzu den leistungsfähigsten Kommunikationsnetzen weltweit. [DFN10]

2.9.3. DFNRoaming

DFNRoaming ist ein Dienst des Deutschen Forschungsnetzes, der Nutzern einen einfachenZugang, ohne zusätzliche Anmeldung, zum Wissenschaftsnetz und zum Internet bietet. Dabeiist es gleichgültig, ob der Nutzer sich an seiner eigenen Einrichtung oder bei einer anderenam DFNRoaming teilhabenden Einrichtung befindet. Das DFNRoaming ist dabei in dasentsprechende europäische Vorhaben eingebettet (eduroam (2.8)), welches auch eine grenz-übergreifende Nutzung der Wissenschaftsnetze ermöglicht. [DFN11a]

Das DFN ist ein Bündnispartner von eduroam auf nationaler Ebene und stellt mit demDFNRoaming den nationalen Top-Level RADIUS-Proxy von Deutschland, an welchen alleRADIUS-Server, der am DFNRoaming/eduroam teilhabenden Institutionen, angebunden sind.Der Top-Level RADIUS-Proxy vom DFN ist wiederum mit dem europäischen Top-LevelRADIUS-Proxy von eduroam verbunden.



3. Anforderungsanalyse

3.1. Zielstellung

Das WLAN der Hochschule Ulm soll sowohl Angehörigen der Hochschule Ulm (Studenten,Professoren, Mitarbeitern) als auch Gästen (Angehörige anderer Hochschulen und Forschungs-einrichtungen) einen sicheren und komfortablen Zugang zum Internet bieten. Zudem sollenAngehörige der HSU zusätzlich Zugang zum Intranet erhalten, um auf Server und Druckerzugreifen zu können. Weiterhin soll es Angehörigen der HSU möglich sein, an anderen Institutio-nen Zugriff auf das dortige WLAN und somit auch auf das Internet zu erhalten, ohne zusätzlicheinen Gastzugang beantragen zu müssen. Für diesen Zweck soll das WLAN der HochschuleUlm an einen Roaming-Dienst angebunden werden, welcher die gewünschten Möglichkeitenbietet.

3.2. Anwendungsfälle

Im Wesentlichen gibt es nur einen grundlegenden Anwendungsfall, welcher in Abbildung 3.1zu sehen ist. Dieser Anwendungsfall beschreibt, dass sich ein Nutzer mit dem WLAN übereinen Access Point verbindet und über einen Authentifizierungsdienst authentifiziert wird.

Abbildung 3.1.: Anwendungsfalldiagramm „Mit WLAN verbinden“

Hierbei müssen allerdings drei Varianten unterschieden werden.



3.2.1. Angehöriger der Hochschule Ulm meldet sich am WLAN

der HSU an

Beschreibung: Angehöriger der Hochschule Ulm meldet sich am WLAN der HSU anund wird über den Authentifizierungsserver der HSU authentifiziert

Akteur: Angehöriger der HSU mit WLAN-Client

Auslösendes Ereignis: Angehöriger möchte sich am WLAN der HSU anmelden

Vorbedingung: • Angehöriger hat WLAN Verbindung bereits eingerichtet undkonfiguriert

• Angehöriger besitzt gültigen Benutzeraccount an der HSU

Ziel: Angehöriger ist am WLAN angemeldet

Nachbedingungen: Angehöriger hat Zugriff auf das Internet und Intranet der HSU

Fehlschlag: Angehöriger ist nicht am WLAN angemeldet und kann nicht auf dasInternet und Intranet zugreifen

Standardablauf:

1. Angehöriger verbindet seinen Client über einen Access Point mit dem WLAN der HSU

2. Angehöriger wird nach Benutzername und Passwort zur Authentifizierung gefragt (kannje nach Konfiguration des Clients nur einmal bei der Einrichtung nötig sein)

3. Angehöriger gibt Benutzername und Passwort ein

4. Bei erfolgreicher Authentifizierung wird der Client vom Access Point autorisiert underhält Zugriff auf das WLAN

5. Client wird eine IP-Adresse aus dem Adresspool der HSU zugewiesen

6. Angehöriger ist jetzt am WLAN angemeldet und hat Zugriff auf das Internet undIntranet der HSU

Alternativen:

4. Bei fehlgeschlagener Authentifizierung erhält der Client keinen Zugriff auf das WLAN

5. Client erhält keine IP-Adresse

6. Angehöriger ist nicht am WLAN angemeldet und kann nicht auf das Internet undIntranet zugreifen



3.2.2. Angehöriger der Hochschule Ulm meldet sich am WLAN

einer anderen Institution an

Beschreibung: Angehöriger der Hochschule Ulm meldet sich am WLAN einer anderenInstitution an und wird über die HSU authentifiziert

Akteur: Angehöriger der HSU mit WLAN-Client

Auslösendes Ereignis: Angehöriger möchte sich am WLAN einer anderen Institution anmel-den

Vorbedingung: • andere Institution nimmt am gleichen Roaming-Dienst teil, wiedie HSU

• Angehöriger hat WLAN Verbindung an der HSU bereits einge-richtet und konfiguriert

• Angehöriger besitzt gültigen Benutzeraccount an der HSU

Ziel: Angehöriger ist am WLAN der anderen Institution angemeldet

Nachbedingungen: Angehöriger hat Zugriff auf das Internet

Fehlschlag: Angehöriger ist nicht am WLAN angemeldet und kann nicht auf dasInternet zugreifen

Standardablauf:

1. Angehöriger verbindet seinen Client über einen Access Point mit dem WLAN derInstitution

2. Angehöriger wird nach Benutzername und Passwort zur Authentifizierung gefragt (kannje nach Konfiguration des Clients nur einmal bei der Einrichtung nötig sein)

3. Angehöriger gibt Benutzername und Passwort ein


5. Client wird eine IP-Adresse aus dem Adresspool der Institution zugewiesen

6. Angehöriger ist jetzt am WLAN angemeldet und hat Zugriff auf das Internet

Alternativen:



6. Angehöriger ist nicht am WLAN angemeldet und kann nicht auf das Internet zugreifen



3.2.3. Gast meldet sich am WLAN der Hochschule Ulm an

Beschreibung: Gast von einer anderen Institution meldet sich am WLAN der HSUan und wird über seine Institution authentifiziert

Akteur: Gast mit WLAN-Client

Auslösendes Ereignis: Gast möchte sich am WLAN der HSU anmelden

Vorbedingung: • Institution des Gastes nimmt am gleichen Roaming-Dienst teil,wie die HSU

• Gast hat WLAN Verbindung an seiner Institution bereits ein-gerichtet und konfiguriert

• Gast besitzt gültigen Benutzeraccount an seiner Institution

Ziel: Gast ist am WLAN der HSU angemeldet

Nachbedingungen: Gast hat Zugriff auf das Internet

Fehlschlag: Gast ist nicht am WLAN angemeldet und kann nicht auf das Internetzugreifen

Standardablauf:

1. Gast verbindet seinen Client über einen Access Point mit dem WLAN der HSU

2. Gast wird nach Benutzername und Passwort zur Authentifizierung gefragt (kann je nachKonfiguration des Clients nur einmal bei der Einrichtung nötig sein)

3. Gast gibt Benutzername und Passwort ein


5. Client wird eine IP-Adresse aus dem Adresspool der HSU zugewiesen

6. Gast ist jetzt am WLAN angemeldet und hat Zugriff auf das Internet

Alternativen:



6. Gast ist nicht am WLAN angemeldet und kann nicht auf das Internet zugreifen



3.2.4. Weitere Anwendungsfälle

Die unter 3.2.1, 3.2.2 und 3.2.3 erwähnten Anwendungsfälle stellen die am häufigsten vorkom-menden Varianten dar. Neben diesen kann es noch zu weiteren Anwendungsfällen kommen, diejedoch für die vorliegende Arbeit nicht von Bedeutung sind und daher nicht weiter beachtetwerden.

Ein Beispiel hierfür ist, dass sich ein Gast am WLAN der HSU anmelden möchte, dessenInstitution aber nicht an einem Roaming-Dienst teilnimmt. Solch ein Gast kann sich dannnicht ohne weiteres am WLAN der HSU anmelden, da in diesem Fall keine Authentifizierungmöglich ist. Der Gast muss sich dann zunächst einen „Gast-Account“ von der HSU gebenlassen. Erst jetzt ist es für ihn möglich, sich am WLAN der HSU anzumelden. Der Ablauferfolgt dann wie unter 3.2.1 auf Seite 33 beschrieben, allerdings darf der Gast keinen Zugriffauf das Intranet erhalten.

3.3. Anforderungen

Aus den unter 3.2 auf Seite 32 beschriebenen Anwendungsfällen ergeben sich folgende Anfor-derungen.

Alle Anforderungen sind mit Prioritäten versehen. Es gibt dabei drei Klassen von Prioritäten:

hoch: muss unbedingt erfüllt werden

mittel: sollte erfüllt werden

gering: nicht notwendig, aber praktisch

3.3.1. Funktionale Anforderungen

FA1 Zugang für Angehörige der HSU zum Internet (hoch)Das WLAN der HSU muss Angehörigen der Hochschule Ulm (Studenten, Professoren,Mitarbeitern) einen sicheren Zugang zum Internet bieten.Diese Anforderung muss unbedingt umgesetzt werden. Daher ergibt sich eine hohePriorität.

FA2 Zugang für Angehörige der HSU zum hochschulinternen Netzwerk (hoch)Das WLAN der HSU muss Angehörigen der Hochschule Ulm auch einen sicheren Zugangzum hochschulinternen Netzwerk (Intranet) bieten. Dadurch können Angehörige aufServer und Drucker der HSU zugreifen.



Auch diese Anforderung muss unbedingt umgesetzt werden. Daher ergibt sich eine hohePriorität.

FA3 Zugang für Gäste zum Internet über das WLAN (mittel)Das WLAN der HSU soll Gästen (Angehörige anderer Hochschulen und Forschungsein-richtungen) einen sicheren Zugang zum Internet bieten.Diese Anforderung muss nicht unbedingt erfüllt werden. Daher ergibt sich eine mittlerePriorität.

FA4 Kein Zugriff für Gäste auf das Intranet (hoch)Es muss sichergestellt werden, dass Gäste keinen Zugriff auf das Intranet der HSUhaben. Gäste dürfen nur einen Zugang zum Internet bekommen.Diese Anforderung wiederum muss unbedingt umgesetzt werden. Daher ergibt sich einehohe Priorität.

FA5 Anbindung der WLAN-Infrastruktur an einen Roaming-Dienst (mittel)Die WLAN-Infrastruktur der HSU soll an einen Roaming-Dienst angebunden werden,um die oben genannten Anforderungen für Gäste zu erreichen.Auch diese Anforderung muss nicht unbedingt erfüllt werden. Daher ergibt sich einemittlere Priorität.

3.3.2. Nichtfunktionale Anforderungen

NF1 Kompatibilität (hoch)Der WLAN Zugang muss für alle gängigen WLAN-Geräte möglich sein. Darunter fallenGeräte wie Laptops, Tablet-PCs, Smartphones. Diese Geräte arbeiten mit unterschied-lichen Betriebssystemen wie z. B. Windows, Linux, Mac OS X, iOS, Android, WindowsMobile, Symbian. Daher ist es auch wichtig, all diese Betriebssysteme zu unterstützen.Eine hohe Kompatibilität ist für den Anwender sehr wichtig ist. Diese Anforderungerhält daher eine hohe Priorität.

NF2 Bedienung (hoch)Die Anmeldung am WLAN muss so einfach wie möglich für den Anwender sein. Dahermuss sich der Konfigurationsaufwand bei der Ersteinrichtung für den Anwender aufein Minimum beschränken, so dass dies von jedem Anwender ohne spezielle Kenntnissevorgenommen werden kann. Auch muss darauf geachtet werden, dass ein Standardverwendet wird, der von den oben genannten Betriebssystemen von Haus aus unterstütztwird, ohne dass Zusatzsoftware auf den Geräten installiert werden muss.Eine einfache Bedienung ist für den Anwender von großer Bedeutung. Dieser Anforde-rung wird daher eine hohe Priorität zugeteilt.



NF3 Sicherheit (hoch)Der Zugriff auf das WLAN muss den gängigen Sicherheitsstandards unterliegen und füralle Nutzer ein gewisses Maß an Sicherheit bieten. Die über Funk übertragenen Datenmüssen in jedem Fall verschlüsselt sein, um einen Zugriff durch andere Personen daraufzu verhindern. Die Verschlüsselung kann auf unterschiedlichen Wegen erfolgen, mussaber den gängigen Sicherheitsstandards entsprechen.Auch die Sicherheit spielt eine sehr wichtige Rolle und bekommt daher eine hohePriorität zugeteilt.

NF4 Datenschutz (mittel)Die bei der Anmeldung zur Authentifizierung ausgetauschten Informationen (Benutzer-name mit Realm) dürfen nur von den für die Authentifizierung notwendigen Instanzenverarbeitet und protokolliert werden. Hierzu zählen die HSU, der Roaming-Dienst unddie entsprechende Institution, welche am Authentifizierungsvorgang mit beteiligt ist.Die Protokolle dürfen dabei nur zur Fehleranalyse, und um den Nutzer bei verbotenenAktivitäten ausfindig zu machen, verwendet werden.Der Datenschutz ist wichtig, allerdings sollten die Anforderungen NF1, NF2 und NF3vorrangig behandelt werden. Daher bekommt diese Anforderung eine mittlere Priorität.

NF5 Performance (mittel)Die Access Points sollen so skaliert werden, dass die Nutzer einen guten und schnellenZugriff auf das WLAN und die angebotenen Dienste wie Internet und Intranet haben.Auch mehrere gleichzeitige Verbindungen über einen Access Point dürfen den Zugriffnicht spürbar bremsen.Eine hohe Performance ist nicht unbedingt notwendig, sollte aber erreicht werden.Daher erhält diese Anforderung eine mittlere Priorität.

NF6 Zuverlässigkeit (mittel)Die Access Points sollen eine hohe Zuverlässigkeit haben. Im Falle eines Ausfallssollen umliegende Access Points die Arbeit des ausgefallen Access Point übernehmen(Roaming).Auch eine hohe Zuverlässigkeit ist nicht unbedingt notwendig. Daher bekommt dieseAnforderung eine mittlere Priorität.



3.3.3. Zusammenfassung

Im Folgenden werden die Anforderungen in einer tabellarischen Übersicht nochmals dargestellt.

Funktionale Anforderungen

Nummer Anforderung PrioritätFA1 Zugang für Angehörige der HSU zum Internet hochFA2 Zugang für Angehörige der HSU zum Intranet hochFA3 Zugang für Gäste zum Internet über das WLAN mittelFA4 Kein Zugriff für Gäste auf das Intranet hochFA5 Anbindung des WLANs an einen Roaming-Dienst mittel

Tabelle 3.1.: Funktionale Anforderungen

Nichtfunktionale Anforderungen

Nummer Anforderung PrioritätNF1 Kompatibilität hochNF2 Bedienung hochNF3 Sicherheit hochNF4 Datenschutz mittelNF5 Performance mittelNF6 Zuverlässigkeit mittel

Tabelle 3.2.: Nichtfunktionale Anforderungen


4. Konzeption 40

4. Konzeption

Anhand der Anforderungen wird ein Konzept für die WLAN-Infrastruktur der HochschuleUlm entwickelt. Die Einteilung erfolgt dabei in ein Grob- und Feinkonzept.

4.1. Stand der Technik

Die Hochschule Ulm betreibt zurzeit ein offenes nicht verschlüsseltes WLAN (SSID „ZKI“).Das WLAN dient einzig dem Zugang zum VPN-Gateway der Hochschule. Über diesen istein sicherer Zugang zum Intranet und Internet möglich. Das VPN-Gateway authentifiziertden Nutzer am Active Directory der HSU. Alle über das WLAN übertragenen Daten werdeninnerhalb eines VPN-Tunnels verschlüsselt zum VPN-Gateway übertragen. Daher ist eineVerschlüsselung auf der Funkschnittstelle nicht nötig. Zum Aufbau des VPN-Tunnels wird einCISCO VPN-Client auf dem WLAN-Client und ein Hochschul-Account an der HSU benötigt.Es erhalten daher nur Angehörige der HSU Zugriff auf das Internet und Intranet über dasWLAN.Mit diesem bereits bestehenden Ansatz können die geforderten Anforderungen nur teilweiseerfüllt werden. Es ist für Gäste nicht ohne weiteres möglich, sich am WLAN anzumelden undZugriff auf das Internet zu erhalten. Dafür muss zunächst ein Gast-Account beim Rechen-zentrum beantragt werden, was für beide Seiten ein aufwändiger Vorgang ist. Zudem ist dieEinrichtung des CISCO VPN-Clients nicht immer einfach und führt des Öfteren zu Problemen.Darüberhinaus wird dieser auch nicht auf allen Plattformen zur Verfügung gestellt, was dieKompatibilität von Geräten einschränkt. Um den Anforderungen weiter gerecht zu werden,muss daher die WLAN-Infrastruktur erweitert werden.

4.2. Grobkonzept

Zur Erfüllung der Anforderungen muss ein Ansatz gefunden werden, welcher die WLAN-Infrastruktur der HSU an einen Roaming-Dienst anbindet. Als Roaming-Dienst wird eduroamzusammen mit dem DFN-Roaming eingesetzt. DFN-Roaming/eduroam ist im Moment der


4. Konzeption 41

einzig verfügbare Roaming-Dienst, der eine hochschulübergreifende Nutzung der WLANs allerteilnehmenden Institutionen ermöglicht.Für die Teilnahme am DFN-Roaming/eduroam müssen einige Vorbereitungen an der WLAN-und IT-Infrastruktur getroffen werden. Da eduroam auf der 802.1X Authentifizierung basiert,muss die Authentifizierung am WLAN der HSU auf die 802.1X Authentifizierung umgestelltwerden. Im Folgenden werden die dafür benötigten Komponenten aufgeführt. Anschließend wirdder Ablauf des Authentifizierungsvorgangs anhand der benötigten Komponenten dargestellt.

4.2.1. Benötigte Komponenten

Access PointEs wird ein Access Point benötigt, der eine 802.1X Authentifizierung zusammen mit derWPA2-Enterprise Verschlüsselung unterstützt.

RADIUS-ServerZur Authentifizierung von Angehörigen der HSU wird ein RADIUS-Server benötigt, wel-cher Authentifizierungsanfragen entgegennimmt und eine Authentifizierung durchführt. DerRADIUS-Server muss dazu Zugriff auf einen Verzeichnisdienst (z. B. Active Directory) ha-ben, in welchem die Benutzer hinterlegt sind. Als RADIUS-Server kann z.B. FreeRADIUS(http://freeradius.org/) oder auch ein RADIUS-Server auf Basis von Windows Sever 2008(Network Policy Server (NPS)) verwendet werden.

RADIUS-ProxyFür die Weiterleitung von Authentifizierungsanfragen von Gästen wird ein RADIUS-Proxybenötigt. Alle Anfragen, die der RADIUS-Server nicht bearbeiten kann, werden an den RADIUS-Proxy weitergeleitet, welcher diese wiederum an den Top-Level RADIUS-Proxy vom DFNweiterleitet. Als RADIUS-Proxy kann auch der FreeRADIUS eingesetzt werden. Um RADIUS-Pakete aber sicher und verschlüsselt über TCP zu übertragen, muss das RadSec-Protokollverwendet werden. Dieses wird vom radsecproxy unterstützt, der von UNINETT bereitgestelltwird (http://software.uninett.no/radsecproxy). Der radsecproxy wird als RADIUS-Proxy vomDFN für die Anbindung an den Top-Level RADIUS-Proxy empfohlen.

4.2.2. Ablauf der Authentifizierung

Clients, die sich am WLAN anmelden möchten, schicken eine Authentifizierungsanfrage überEAPOL an den Access Point. Dieser nimmt die Anfrage entgegen und leitet sie innerhalbeines RADIUS-Pakets (Access-Request) an den RADIUS-Server weiter. Der RADIUS-Serverentscheidet anhand des Realm, ob die Anfrage intern authentifiziert werden kann, oder an


http://freeradius.org/


4. Konzeption 42

den RADIUS-Proxy weitergeleitet werden muss. Anfragen, die intern authentifiziert werdenkönnen, werden an einen Verzeichnisdienst weitergeleitet (z. B. über das LDAP-Protokoll anein Active Directory), welcher die Authentifizierung durchführt. Anfragen, die nicht internauthentifiziert werden können, werden an den RADIUS-Proxy weitergeleitet, welcher diesewiederum an den Top-Level RADIUS-Proxy des DFN weiterleitet. Der Top-Level RADIUS-Proxy leitet die Anfragen dann (ggf. über weitere RADIUS-Proxys) an den RADIUS-Server derjeweiligen Institution, von der der Gast stammt, weiter. Dieser führt dann die Authentifizierungdes Gastes durch. Dazu muss die Institution auch am DFNRoaming/eduroam teilnehmen.Bei erfolgreicher Authentifizierung sendet der RADIUS-Server, welcher die Authentifizierungdurchgeführt hat, ein Access-Accept-Paket an den Access Point, der dann den Client autorisiertund ihm Zugang zum WLAN gewährt. Andernfalls wird der Client abgelehnt und der Zugangblockiert.

Der genaue Ablauf und Paketaustausch einer 802.1X Authentifizierung zwischen einem Clientund einem RADIUS-Server ist unter 2.7 auf Seite 23 detailliert beschrieben.

In der Abbildung 4.1 ist die Architektur der WLAN-Infrastruktur dargestellt.

Abbildung 4.1.: Architektur der WLAN-Infrastruktur

4.3. Feinkonzept

In diesem Teil wird das Grobkonzept weiter verfeinert und näher auf die erforderliche Hardwareund Software eingegangen.


4. Konzeption 43

Für die Anbindung des WLANs der HSU an das DFNRoaming/eduroam haben sich zwei unter-schiedliche Varianten (Variante A und B) ergeben, deren Unterschiede und Gemeinsamkeitenim Folgenden näher erläutert werden.

4.3.1. Varianten im Überblick

Wie in den Anforderungen beschrieben, müssen Angehörige der HSU und Gäste unterschied-liche Rechte im Netzwerk der HSU besitzen. Gäste sollen nur einen reinen Zugriff auf dasInternet bekommen und dürfen keinen weiteren Zugriff auf das Intranet der HSU haben.Angehörige dagegen müssen neben dem Zugriff auf das Internet auch einen Zugriff auf dasIntranet bekommen, um bestimmte Server und Drucker nutzen zu können.Um das zu ermöglichen, muss eine Unterscheidung zwischen den beiden Gruppen vorgenommenwerden. Dies kann durch zwei getrennte VLANs erreicht werden. Jeder Gruppe wird dabei eineigenes VLAN zugewiesen. Jedem VLAN wird wiederum ein eigener IP-Adressbereich durcheinen DHCP-Server zugeteilt. Anhand von Firewall-Regeln können dann die entsprechendenBerechtigungen für die beiden Gruppen gesetzt werden.Für die Anbindung an das DFNRoaming/eduroam und die Zuweisung der VLANs haben sichzwei unterschiedliche Varianten ergeben, die beide ihre Vor- und Nachteile haben. Variante Aarbeitet nur mit einer SSID und dynamischem VLAN-Tagging. Variante B hingegen arbeitetmit zwei SSIDs und fest zugewiesenen VLANs.Bei beiden Varianten bleibt die bereits vorhandene SSID „ZKI“ vorerst bestehen, um eine all-mähliche Umstellung auf das 802.1X Authentifizierungsverfahren zu ermöglichen. Angehörigender HSU ist es somit weiterhin möglich, sich über den CISCO VPN-Client am WLAN derHSU anzumelden. In diesem Fall erfolgt die Authentifizierung nicht über den RADIUS-Server,sondern über das VPN-Gateway der Hochschule.

Variante A

Bei Variante A kommt neben der bereits bestehenden SSID „ZKI“ eine weitere SSID mit demNamen „eduroam“ hinzu. Diese SSID muss in allen WLAN-Installationen vorkommen, die aneduroam angebunden sind. Nur durch eine gleiche SSID kann das Roaming an allen Standorteninnerhalb des eduroam-Verbundes funktionieren.Im WLAN der HSU wird die SSID „eduroam“ sowohl von Angehörigen der HSU als auch vonGästen verwendet. Alle Nutzer verbinden sich über diese SSID mit dem WLAN. Da nur miteiner SSID gearbeitet wird, kann dieser im Access Point nur ein VLAN zugewiesen werden.Dafür wird die VLAN-ID der Gastgruppe verwendet. Alle Benutzer, die sich über die SSID„eduroam“ mit dem WLAN verbinden, befinden sich dann im VLAN der Gastgruppe und


4. Konzeption 44

haben nur einen Zugriff auf das Internet.Um Angehörigen der HSU ein eigenes VLAN zuzuweisen, muss mit dynamischem VLAN-Tagging gearbeitet werden. Die VLAN-ID wird dabei durch den RADIUS-Server dem AccessPoint mitgeteilt. Sobald sich ein Angehöriger der HSU am WLAN über die SSID „eduroam“anmeldet, wird dieser vom RADIUS-Server der HSU authentifiziert. Den RADIUS-Paketenwerden dann vom RADIUS-Server Attribute zur Übermittlung der entsprechenden VLAN-IDangehängt. Anhand dieser RADIUS-Attribute erkennt der Access Point, dass er nicht dieVLAN-ID für die Gastgruppe verwenden soll, sondern die im Attribut angegebene. Angehörigender HSU wird so ein anderes VLAN, in welchem sie erweiterte Rechte besitzen und auchZugriff auf das Intranet der HSU haben, zugewiesen.

Variante B

Bei Variante B kommen neben der bereits bestehenden SSID „ZKI“ zwei weitere SSIDs mitdem Namen „IMZ“ und „eduroam“ hinzu. Die SSID „IMZ“ ist für Angehörige der HSU gedachtund „eduroam“ für Gäste. Dabei kann der Name der SSID „IMZ“ frei gewählt werden. Nur diezweite SSID muss unbedingt „eduroam“ heißen, damit das Roaming auch funktioniert undGäste sich am WLAN anmelden können.Jeder SSID ist ein eigenes VLAN im Access Point zugeordnet. Gäste und Angehörige der HSUwerden in diesem Ansatz anhand der SSID unterschieden, welche ihnen wiederum ein VLANzuteilt. Es muss hier kein dynamisches VLAN-Tagging durch den RAIUS-Server konfiguriertwerden, da die zwei VLANs den SSIDs über den Access Point fest zugeordnet sind. Je nachdem über welche SSID ein Nutzer im WLAN angemeldet ist, befindet er sich automatisch indem VLAN, welches der SSID zugeordneten ist. Meldet sich eine angehörige Person der HSUan der SSID „IMZ“ an, befindet sie sich automatisch im VLAN für Angehörige und erhältZugriff auf das Internet und Intranet. Meldet sich die Person dagegen bei der SSID „eduroam“an, befindet sie sich im VLAN für Gäste und erhält auch nur Zugriff auf das Internet. EinZugriff auf das Intranet ist über die SSID „eduroam“ nicht möglich.

4.3.2. Varianten im Vergleich

Nachfolgend werden die beiden Varianten verglichen. Anhand der Vor- und Nachteile sollgezeigt werden, welche Variante am besten für eine Umsetzung geeignet ist.

Bedienung und Komfort

Ziel von eduroam ist, dass alle Nutzer einen möglichst einfachen Zugang zum Internet überein eduroam-WLAN erhalten. Im besten Fall muss ein WLAN-Client, nach erfolgreicher


4. Konzeption 45

Konfiguration, nur noch aktiviert werden und dieser verbindet sich dann automatisch miteinem vorhandenen WLAN mit dem Namen „eduroam“.

Da bei Variante A nur die SSID „eduroam“ zur Verfügung steht, melden sich alle Nutzer, Gästewie Angehörige der HSU, an der gleichen SSID an. Das ist für die Nutzer sehr einfach, da nureine SSID zu Auswahl steht und nur ein WLAN auf den Clients eingerichtet werden muss.Sobald das WLAN auf dem Client eingerichtet ist, können sich Personen der HSU mit alleneduroam-WLANs an allen teilnehmenden Institutionen verbinden und Zugang zum Interneterhalten. Sobald sich ein Angehöriger der HSU aber an der Hochschule Ulm mit der SSID„eduroam“ verbindet, wird ihm automatisch ein bestimmtes VLAN zugeteilt, in welchem erZugang zum Internet und Intranet der HSU erhält.

Falls, wie bei Varianten B, zwei SSIDs existieren, muss ein Angehöriger der HSU zwei WLAN-Konfigurationen auf seinem Client vornehmen (einmal für „IMZ“ und einmal für „eduroam“).Zudem muss der Nutzer darauf achten, dass sein WLAN-Client sich immer mit der SSID„IMZ“ an der HSU verbindet, um Zugriff auf das Intranet zu erhalten. Sobald nämlich mehrereWLAN-Konfigurationen auf einem Client konfiguriert und auch in Reichweite sind, kann esvorkommen, dass sich der Client an der Hochschule auch mit der SSID „eduroam“ verbindetund der Nutzer dann keinen Zugriff auf das Intranet hat. Das kann bei Variante A nichtpassieren, da ja nur eine SSID existiert und einem Angehörigen der HSU automatisch dasrichtige VLAN zugewiesen wird.

Weiterhin werden einige Nutzer bei Variante B nur die SSID „IMZ“ auf ihrem Client konfigu-rieren, da das ja für die interne Nutzung vollkommen ausreicht. Sobald sie sich dann aber aneiner anderen Einrichtung befinden und doch plötzlich ein eduroam-WLAN nutzen möchten,ist dies nicht konfiguriert und muss erst noch konfiguriert werden. Wenn hierbei Problemeauftreten, ist es deutlich schwerer diese zu lösen, da man ja nicht an seiner Heimateinrichtungvor Ort ist. Daher empfiehlt es sich, bereits an seiner Heimateinrichtung das WLAN „eduroam“zu konfigurieren und zu testen. Bei Verwendung von nur einer SSID (Variante A) kann dasnicht passieren, da jeder Nutzer standardmäßig die SSID „eduroam“ auf seinem WLAN-Clienteinrichten muss, um Zugriff auf das WLAN der HSU zu haben.

Bei Variante B wird es also dem Nutzer überlassen, mit welcher SSID er sich verbindet und inwelchem VLAN er sich schließlich befindet. Variante A hingegen verlagert die Auswahl desVLANs weg vom Nutzer auf den RADIUS-Server. Dieser entscheidet automatisch, welchesVLAN einem Nutzer zugewiesen wird. Für den Nutzer bietet also Variante A deutlich mehrKomfort, da er sich keine Gedanken mehr über die richtige Auswahl der SSID machen mussund automatisch mit dem richtigen VLAN verbunden wird.


4. Konzeption 46

Erweiterbarkeit

Variante A ist relativ einfach erweiterbar. Durch weitere Realms wie z. B. „@student.hs-ulm.de“oder „@dozent.hs-ulm.de“ oder dem Einteilen von Angehörigen der HSU in Benutzergruppenim Acitive Directory kann eine weitere Separierung der Angehörigen stattfinden. Dabei kannjeder Nutzergruppe wieder ein eigenes VLAN zugewiesen werden. Die entsprechende VLAN-IDwird dann je nach Realm oder Benutzergruppe im AD vom RADIUS-Server bestimmt. AlleNutzergruppen melden sich aber weiterhin über die SSID „eduroam“ am WLAN an. Ihnenwird dann automatisch das richtige VLAN zugewiesen.Um bei Variante B eine weitere Separierung durchführen zu können, müsste für jede weitereGruppe mit eigenem VLAN auch eine neue SSID eingeführt werden, da jeder SSID ja einVLAN fest zugewiesen ist. Dadurch würde die Anzahl der SSIDs weiter zunehmen und dieWLAN-Konfiguration für den Anwender noch komplizierter werden.

Konfiguration

Die Konfiguration beider Varianten benötigt einen ähnlichen Aufwand. Bei beiden Variantenmüssen mindestens zwei VLANs eingerichtet werden und ähnliche Konfigurationen am RADIUS-Server und RADIUS-Proxy vorgenommen werden. Bei Variante A muss zusätzlich noch dasdynamische VLAN-Tagging am RADIUS-Server konfiguriert werden. Wie aber im Kapitel 6.5.3auf Seite 85 zu sehen ist, ist das nicht aufwendig.Bei Variante B hingegen muss eine zweite SSID mit festzugewiesenem VLAN am Access Pointerstellt werden.

Zusammenfassung

Variante A

Vorteile:

• nur eine SSID mit dem Namen „eduroam“

• SSID für alle gleich, sowohl bei Angehörigen der HSU als auch bei Gästen

• Nutzer muss nicht über zu wählende SSID entscheiden

• einfache Konfiguration und Bedienung von Seite des Anwenders

• leicht durch weitere Benutzergruppen mit eigenem VLAN erweiterbar

Nachteile:

• einmalige Konfiguration von dynamischem VLAN-Tagging auf dem RADIUS-Server


4. Konzeption 47

Variante B

Vorteile:

• dynamisches VLAN-Tagging muss nicht konfiguriert werden

Nachteile:

• mehrere SSIDs („IMZ“ und „eduroam“)

• Nutzer muss SSID wählen

• Konfiguration und Bedienung ist kompliziert für den Anwender

• Erweiterung durch weitere Benutzergruppen mit eigenem VLAN ist aufwendig

Erfüllung der Anforderungen

Dieser Abschnitt soll zeigen, inwieweit sich die Varianten A und B auf die Erfüllung derAnforderungen auswirken. Dabei werden die Anforderungen anhand der bereits getroffenenEntscheidungen von Variante A und B bewertet. Es handelt sich hier aber um keine abschließen-de Bewertung. Diese wird erst in Kapitel 7 auf Seite 98 durchgeführt. Bei allen Erfüllungsgradenhandelt es sich um theoretisch maximal mögliche Werte. Die tatsächlichen Werte ergeben sicherst durch die Beachtung weiterer Randbedingungen (z. B. gewählte Verschlüsselung), welcheerst in den kommenden Kapiteln festgelegt werden.

Funktionale AnforderungenDie Wahl einer Variante hat keine Auswirkung auf den Erfüllungsgrad der funktionalenAnforderungen. Alle Anforderungen können bei beiden Varianten vollständig erfüllt werden.In Tabelle 4.1 ist der Erfüllungsgrad und die Bewertung anhand einer Pugh-Matrix dargestellt.Aus der Bewertung geht hervor, dass bei beiden Varianten je 44 Punkte erreicht werdenkönnen.

Anforderung Priorität Erfüllungsgrad BewertungA B A B

FA1 hoch (10) 100% 100% 10 10FA2 hoch (10) 100% 100% 10 10FA3 mittel (7) 100% 100% 7 7FA4 hoch (10) 100% 100% 10 10FA5 mittel (7) 100% 100% 7 7

Summe 44 44

Tabelle 4.1.: Pugh-Matrix Funktionale Anforderungen


4. Konzeption 48

Nichtfunktionale AnforderungenBei den nichtfunktionalen Anforderungen wirkt sich die Wahl der Variante nur auf die nicht-funktionale Anforderung „Bedienung“ aus. Bei Variante A ist die Konfiguration und Bedienungfür den Anwender deutlich einfacher als bei Variante B. Dies führt daher zu einem Erfül-lungsgrad von 90% bei der Wahl von Variante A für NF2. 100% sind nicht möglich, da auchbei Variante A eine einmalige Konfiguration des Clients vorgenommen werden muss und daseinen einmaligen Aufwand für den Anwender bedeutet. Je nach verwendetem System kann dieKonfiguration mit mehr oder weniger Aufwand verbunden sein.

Auf die Anforderungen NF1 und NF3 bis NF6 hat die Wahl der Variante keinen Einfluss. DieAnforderungen NF3 bis NF5 können dabei einen Erfüllungsgrad von bis zu 100% erreichen.NF1 hingegen kann maximal 95% erreichen, da ein WLAN-Gerät die 802.1X-Authentifizierungunterstützen muss, um kompatibel zu sein. Es befinden sich aber wenige WLAN-Geräte imUmlauf, die das nicht tun.

Für NF6 erfolgt keine Bewertung, da über die Zuverlässigkeit noch keine Aussage gemachtwerden kann.

In Tabelle 4.2 ist der Erfüllungsgrad und die Bewertung anhand einer Pugh-Matrix dargestellt.Aus der Bewertung geht hervor, dass Variante A aufgrund der besseren Bedienung mit 42,5Punkten über Variante B mit 37,5 Punkten liegt.

Anforderung Priorität Erfüllungsgrad BewertungA B A B

NF1 Kompatibilität hoch (10) 95% 95% 9,5 9,5NF2 Bedienung hoch (10) 90% 40% 9 4NF3 Sicherheit hoch (10) 100% 100% 10 10NF4 Datenschutz mittel (7) 100% 100% 7 7NF5 Performance mittel (7) 100% 100% 7 7NF6 Zuverlässigkeit mittel (7) - - - -

Summe 42,5 37,5

Tabelle 4.2.: Pugh-Matrix Nichtfunktionale Anforderungen

Fazit

Wie dem Vergleich beider Varianten entnommen werden kann, hat Variante B im Vergleichzu A eigentlich keine Vorteile. Variante A hingegen überwiegt deutlich in den Vorteilen.Ein wichtiger Punkt bei Variante A ist, dass die Konfiguration und die Bedienung für denAnwender deutlich einfacher ist. Der Anwender wird dadurch entlastet. Generell sollte darauf


4. Konzeption 49

geachtet werden, dem Anwender Entscheidungen abzunehmen und somit auch die Fehlerquellenmöglichst gering zu halten. Diese Anforderung kann nur durch Umsetzung der Variante Amit einer SSID erreicht werden. Aufgrund der Vorteile bei der Bedienung mit Variante A fälltauch die Bewertung der nichtfunktionalen Anforderungen mit 42,5 Punkten besser aus als beiVariante B mit 37,5 Punkten.

Im Artikel „Use of eduroam as the Single Primary SSID“ von der Swansea University [Ayr]sind die oben genannten und noch weitere Vorteile, die für Variante A sprechen, dargestellt.

Im Folgenden wird Variante A gewählt und die Umsetzung anhand dieser erläutert.

4.3.3. Verwendete Komponenten

Access Point

Für die Umsetzung wird ein Access Point benötigt, welcher eine 802.1X Authentifizierungzusammen mit einer WPA2-Enterprise Verschlüsselung unterstützt. Weiterhin muss der AccessPoint mehrere SSIDs gleichzeitig aussenden können und jeder SSID ein festes VLAN zuweisenkönnen. Auch dynamisches VLAN-Tagging anhand von RADIUS-Attributen muss der AccessPoint beherrschen.Dafür wurden Access Points vom Typ D-Link DWL-8600AP angeschafft. Dieser Access Pointunterstützt die WLAN-Standards 802.11a/b/g/n und besitzt zwei Funkmodule (Dualband für2,4 GHz und 5 GHz). Für jedes Frequenzband stehen jeweils zwei externe Antennen zur Verfü-gung. Der Access Point unterstützt im Standard 802.11n zwei Datenströme in eine Richtunggleichzeitig (Multiple In Multiple Out (MIMO)). Zusammen mit einer Kanalbandbreite von40 MHz ermöglicht der Access Point Datenraten von bis zu 300 MBit/s (brutto) im 802.11n-Standard unter 5 GHz. Der Access Point ermöglicht bis zu 16 SSIDs pro Frequenzband. JederSSID kann ein VLAN zugewiesen werden. Auch dynamisches VLAN-Tagging wird unterstützt.Der Access Point besitzt somit pro Frequenzband 16 virtuelle Access Points (VAP). [DWL8600]Die Access Points werden zusammen mit einem Wireless Switch (D-Link DWS4062) eingesetzt[DWS4026]. Durch den Wireless Switch wird die Konfiguration zentral vorgenommen und aufdie einzelnen Geräte verteilt. Der Wireless Switch kümmert sich zudem um die automatischeKanalwahl und eine optimale Lastverteilung der Access Points.

RADIUS-Server

Für die 802.1X Authentifizierung wird ein RADIUS-Server benötigt. Da die HSU mit einemfast ausschließlich unter Windows betriebenem Netzwerk arbeitet und der Domänencontrollermit Active Directory ein Windows Server 2008 R2 ist, wird ein RADIUS-Server auf WindowsBasis gewählt. Als RADIUS-Server kommt ein Windows Server 2008 R2 mit aktiviertemNetwork Policy Server (NPS) zum Einsatz.


4. Konzeption 50

RADIUS-Proxy

Als RADIUS-Proxy kommt, wie vom DFN empfohlen, der radsecproxy von UNINETT zumEinsatz. Dieser unterstützt neben dem RADIUS-Protokoll auch das RadSec-Protokoll. DieKommunikation mit dem RADIUS-Server erfolgt dabei über das RADIUS-Protokoll. Zu denTop-Level RADIUS-Proxys vom DFN erfolgt die Kommunikation allerdings mittels RadSec.Die RADIUS-Pakete werden somit über das WAN zum DFN-Proxy verschlüsselt innerhalbeines TLS-Tunnels übertragen und können daher nicht von außen mitgelesen werden. Diesist ein wichtiger Schritt für den Datenschutz, da der Anmeldename in einem RADIUS-Paketim Klartext vorliegt und somit Rückschlüsse auf den Nutzer möglich sind, falls die Paketeabgefangen werden. Durch die Übertragung per RadSec ist das nicht mehr möglich.

4.3.4. Verwendete Einstellungen

WLAN-Verschlüsselung

Um die per WLAN übertragenen Daten zu schützen, müssen diese verschlüsselt werden.Zusammen mit der 802.1X Authentifizierung kann eine Verschlüsselung nach WPA- oder WPA2-Enterprise eingesetzt werden. WPA2-Enterprise zusammen mit einer AES-Verschlüsselung(CCMP) ist dabei die sicherste Methode.Um die bestmögliche Sicherheit zu erreichen, wie es in den Anforderungen gefordert ist,muss WPA2-Enterprise gewählt werden. Allerdings können sich dann nur noch WLAN-Geräteverbinden, welche auch WPA2-Enterprise mit CCMP-Verschlüsselung unterstützen. Die meistenGeräte, die heute verwendet werden, sollten CCMP aber unterstützen.Um die Kompatibilität dennoch zu erhöhen, kann auch zusätzlich WPA-Enterprise mit TKIP-Verschlüsselung verwendet werden. Es müssen dann aber geringe Abstriche bei der Sicherheitgemacht werden, da TKIP auf dem unsicheren Verschlüsselungsverfahren RC4 basiert [Kle06].

WLAN-Client Isolation

Die Funktion Client Isolation für WLAN-Clients (auch als Station Isolation bezeichnet) verhin-dert die Kommunikation von WLAN-Clients untereinander. Jeglicher Datenverkehr zwischenden WLAN-Clients wird vom Access Point blockiert. Ein WLAN-Client kann dann nur nochmit Geräten kommunizieren, welche an den Access Point über LAN angebunden sind. DieWLAN-Clients sind somit voneinander isoliert.Durch das Aktivieren von Client Isolation kann die Sicherheit unter den WLAN-Clients weitererhöht werden. Andere WLAN-Clients sind für einen Nutzer dann nicht mehr sichtbar. Esist nicht mehr möglich, von einem WLAN-Client aus, auf andere WLAN-Clients im Netz zu


4. Konzeption 51

zugreifen und ggf. Schaden anzurichten. Auch das automatische Verbreiten von Viren undbösartiger Software unter den WLAN-Clients wird hiermit unterbunden. Allerdings könnenauch keine Daten mehr direkt zwischen zwei WLAN-Clients (z. B. über Netzwerkfreigaben)ausgetauscht werden. Jeglicher Datenaustausch muss über ein am LAN angebundenes Geräterfolgen.Falls ein direkter Datenaustausch zwischen den WLAN-Clients nicht benötigt wird, ist esratsam die Funktion Client Isolation auf den Access Points zu aktivieren, um die Sicherheitder WLAN-Clients untereinander zu erhöhen.Der Access Point D-Link DWL-8600AP bietet diese Funktion (bezeichnet als „Station Isolati-on“).

Authentifizierungsmethode

Für die Authentifizierung nach dem 802.1X-Standard muss eine Authentifizierungsmethodegewählt werden. Mit dieser wird die Authentifizierung zwischen Client und RADIUS-Serverdurchgeführt. Da nach den Anforderungen die Authentifizierung bei den meisten Geräten ohneInstallation einer Zusatzsoftware unterstützt werden soll, muss eine Authentifizierungsmethodegewählt werden, die die meisten Clients von Haus aus unterstützen. Hierfür stehen unterWindows nur die Authentifizierungsmethoden EAP-PEAP zusammen mit EAP-MS-CHAPv2oder EAP-TLS zur Verfügung.EAP-TLS setzt allerdings Client-Zertifikate zur Authentifizierung voraus. Wegen des hohenAufwands beim Verteilen von Client-Zertifikaten kommt diese Methode nicht in Frage. Daherwird als Authentifizierungsmethode EAP-PEAP mit EAP-MS-CHAPv2 gewählt. Bei dieserMethode findet die Authentifizierung mittels Benutzername und Passwort über einen ver-schlüsselten TLS-Tunnel zwischen Client und RADIUS-Server statt. Diese Methode ist zudemweit verbreitet und wird ab Windows XP SP2 nativ von Windows unterstützt. Auch anderePlattformen wie z.B. Mac OS X oder auch gängige Smartphone-Betriebssysteme unterstützenEAP-PEAP/EAP-MS-CHAPv2.Weitere Informationen zu dieser Authentifizierungsmethode und noch weiteren Alternativenkönnen im Kapitel 2.3.1 auf Seite 13 nachgelesen werden.

Identitätsschutz

Bei der Authentifizierung nach dem 802.1X-Standard mit der Authentifizierungsmethode EAP-PEAP wird die Identität des Nutzers (name@realm) zweimal übertragen. In der ersten Phasewird die Identität im Klartext für Routing-Zwecke übertragen (äußere Identität). Anhanddes Realm wird entschieden, an welchen RADIUS-Server die Access-Request-Pakete geleitet


4. Konzeption 52

werden. Der Nutzername in der Identität spielt dabei noch keine Rolle. Nach dem Aufbau einesTLS-Tunnels zwischen Client und RADIUS-Server wird die Identität im Tunnel verschlüsseltein zweites Mal übertragen, um den Nutzer am Server zu authentifizieren (innere Identität).Abbildung 4.2 zeigt ein Access-Request-Paket mit äußerer Identität im Klartext.

Abbildung 4.2.: RADIUS-Access-Request-Paket ohne Identitätsschutz

Die Übertragung der äußeren Identität im Klartext stellt ein Problem für den Datenschutz dar.Jeder, der die EAP-Request/Identity- oder RADIUS-Access-Request-Pakete abfängt, kann dieIdentität des Nutzers mitlesen. Weiterhin führen auch alle Access Points und auf der Strecke lie-genden RADIUS-Proxys ein Log-File und speichern Authentifizierungsanfragen zusammen mitder äußeren Identität. Solange sich ein Nutzer am WLAN seiner Heimateinrichtung anmeldet,stellt das kein all zu großes Problem dar, da die Authentifizierungsanfragen die Einrichtungnicht verlassen und somit auch nur in den Log-Files der Einrichtung selber gespeichert werden.Sobald sich der Nutzer allerdings an einer anderen Institution über eduroam anmeldet, werdendie Authentifizierungsanfragen über die RADIUS-Proxys von eduroam bzw. dem DFN zurHeimateinrichtung geleitet. Dabei können jetzt alle Instanzen, über welche die Access-Request-Pakete geleitet werden, die Identität mitlesen. Anhand der Identität können Rückschlüsse aufden Nutzer gezogen werden. Auch kann die Identität für Angriffe missbraucht werden.Um dem entgegen zu wirken, bieten viele RADIUS-Server und Clients einen Identitätsschutz.Da in der ersten Phase der Nutzername keine Rolle spielt und nur der Realm benötigtwird, wird bei aktiviertem Identitätsschutz eine anonymisierte Identität übertragen (anony-


4. Konzeption 53

mous@realm). Erst in der zweiten Phase wird die wirkliche Identität (name@realm) innerhalbeines verschlüsselten Tunnels zwischen Client und RADIUS-Server übertragen, welche nur vomRADIUS-Server wieder entschlüsselt und gelesen werden kann. Anhand der anonymisiertenäußeren Identität können keine Rückschlüsse mehr auf den Nutzer gezogen werden, lediglichdie Zuordnung zu einer Institution kann anhand des Realm noch erfolgen.Es wird daher dringend empfohlen, den Identitätsschutz zu aktivieren, um den Datenschutzan-forderungen gerecht zu werden. Der Identitätsschutz wird von FreeRadius und ab WindowsServer 2008 unterstützt. Auch die meisten Clients unterstützten diesen. Windows allerdingserst ab Windows 7.Weitere Informationen zum detaillierten Ablauf der Authentifizierung können Abschnitt 2.7auf Seite 23 entnommen werden.

VLAN

Für die Trennung der beiden Gruppen (Gäste und Angehörige der HSU) werden mindestenszwei eigene VLANs benötigt. Dazu kommt noch ein weiteres VLAN für die Verwaltung derAccess Points, über welches auch die Authentifizierung der Clients durchgeführt wird. Einviertes VLAN wird dann noch für die bereits bestehende SSID „ZKI“ benötigt.Im Nachfolgenden sind die vier mindestens benötigten VLANs aufgeführt. Bei den angegebenenVLAN-IDs handelt es sich nur um Beispiele.

• VLAN-ID<10> (Management-VLAN)Dieses VLAN dient zur Administration der Access Points. Auch die Authentifizierungder Clients findet darüber statt.

• VLAN-ID<20> (ZKI-VLAN)Dieses VLAN ist der SSID „ZKI“ im Access Point fest zugewiesen. Angehörigen derHSU, die sich mit der SSID „ZKI“ verbinden, wird dieses VLAN zugeteilt.

• VLAN-ID<30> (Gast-VLAN)Dieses VLAN ist der SSID „eduroam“ im Access Point fest zugewiesen. Gästen, diesich mit der SSID „eduroam“ verbinden, wird dieses VLAN zugeteilt. Innerhalb diesesVLANs darf ein Zugriff nur auf das Internet möglich sein.

• VLAN-ID<40> (VLAN für Angehörige der HSU)Dieses VLAN wird dem Access Point über RADIUS-Attribute vom RADIUS-Servermitgeteilt (dynamisches VLAN-Tagging). Angehörigen der HSU, die sich mit der SSID„eduroam“ verbinden, wird dann dieses VLAN statt VLAN<30> zugeteilt. Innerhalbdieses VLANs muss ein Zugriff auf das Internet und Intranet möglich sein.


4. Konzeption 54

Jedem VLAN wird ein eigener IP-Adressbereich zugeteilt. Die Zuweisung der IP-Adressen fürdie Clients erfolgt durch einen DHCP-Server innerhalb jedes VLANs. Anhand von Firewall-Regeln können dann die entsprechenden Berechtigungen für die beiden Gruppen gesetztwerden.

4.3.5. Ablauf der Authentifizierung

Allgemein

In der Abbildung 4.3 auf der nächsten Seite ist eine Übersicht über die Architektur der WLAN-Infrastruktur dargestellt. Die Access Points sind mit dem Wireless Switch verbunden. AlleAuthentifizierungsanfragen von Clients werden per EAPOL an den Access Point übertragen,welcher diese an den Wireless Switch weiterleitet. Die Übertragung der EAPOL-Paketezwischen Client und Access Point über das WLAN erfolgt dabei unverschlüsselt. Eine WLAN-Verschlüsselung wird erst nach erfolgreicher Authentifizierung aktiviert. EAPOL-Pakete mitAuthentifizierungsanfragen können daher leicht abgefangen werden und die äußere Identitätkann mitgelesen werden. Um das zu verhindern, sollte der Identitätsschutz aktiviert werden(4.3.4).Der Wireless Switch fungiert als RADIUS-Client und leitet die Authentifizierungsanfrageninnerhalb eines RADIUS-Pakets (Access-Request) an den RADIUS-Server (NPS) weiter. DerRADIUS-Server nimmt die Authentifizierungsanfragen vom Wireless Switch entgegen undentscheidet anhand des Realm, ob eine Anfrage intern authentifiziert werden kann, oder anden RADIUS-Proxy weitergeleitet werden muss. Enthält die Anfrage keinen Realm bzw. denRealm „@hs-ulm.de“, wird diese intern vom RADIUS-Server authentifiziert.Für die interne Authentifizierung greift der RADIUS-Server über das LDAP Protokoll auf dasActive Directory zu und gleicht die angegebenen Benutzerinformationen (Benutzername undPasswort) damit ab. Das AD befindet sich auf dem Domänencontroller, welcher auf einemvom RADIUS-Server (NPS) getrennten Server läuft. Es ist möglich den NPS mit auf demDomänencontroller zu installieren. Aus Sicherheitsgründen sollten RADIUS-Server (NPS)und Domänencontroller aber unbedingt voneinander getrennt werden. Wird beispielsweise einAngriff auf den RADIUS-Server durchgeführt, durch welchen dieser überlastet wird, wirktsich das bei einem eigenständigen RADIUS-Server nicht mit auf den Domänencontroller aus.Andernfalls würde der komplette Domänencontroller überlasten und ggf. ausfallen. Daher wirdvon einer Installation des NPS auf dem Domänencontroller abgeraten. Der NPS sollte ambesten auf einem separaten Server installiert werden.Alle anderen Anfragen, mit anderem Realm, werden an den RadSecProxy weitergeleitet,welcher die RADIUS-Pakete innerhalb eines TLS-Tunnels verschlüsselt an den Top-Level


4. Konzeption 55

RADIUS-Proxy des DFN weiterleitet. Der Top-Level RADIUS-Proxy des DFN leitet dieAnfragen dann (ggf. über weitere RADIUS-Proxys) an den RADIUS- Server der jeweiligenInstitution, von welcher der Gast stammt, weiter. Dieser führt dann die Authentifizierung desGastes durch. Dazu muss die Institution auch am DFNRoaming bzw. bei eduroam teilnehmen.Bei erfolgreicher Authentifizierung sendet der RADIUS-Server, welcher die Authentifizierungdurchgeführt hat, ein Access-Accept-Paket an den Access Point, der dann den Client autorisiertund ihm Zugang zum WLAN gewährt. Andernfalls wird der Client abgelehnt (Access-Reject-Paket) und der Zugang blockiert.

Abbildung 4.3.: Detaillierte Architektur der WLAN-Infrastruktur

Authentifizierungsmethode

Als Authentifizierungsmethode wird EAP-PEAP mit EAP-MSCHAPv2 für Angehörige derHSU eingesetzt. Bei Gästen können auch andere Authentifizierungsmethoden wie EAP-TLSoder EAP-TTLS zum Einsatz kommen. Das gewählte Authentifizierungsverfahren spielt nureine direkte Rolle zwischen Client und dem RADIUS-Server, welcher für die Authentifizierungzuständig ist. Die dafür benötigten Pakete werden gekapselt innerhalb von RADIUS-Paketenübertragen. Für Access Points, Wireless Switches und RADIUS-Proxys spielt die gewählteAuthentifizierungsmethode keine Rolle, da sie nur die RADIUS-Pakete sehen und diese weiter-leiten. Erst der RADIUS-Server, der die Authentifizierungsanfrage entgegen nimmt und dieAuthentifizierung durchführen will, muss die gewählte Authentifizierungsmethode unterstützen.Da der RADIUS-Server der HSU nur Anfragen von Angehörigen der HSU entgegen nimmt undauthentifiziert, muss er auch nur die Authentifizierungsmethode EAP-PEAP/EAP-MSCHAPv2


4. Konzeption 56

unterstützen. Alle anderen Anfragen von Gästen mit ggf. anderen Authentifizierungsmethodenwerden an den jeweiligen RADIUS-Server der Heimateinrichtung des Gastes weitergeleitet,welcher wiederum die gewählte Authentifizierungsmethode des Gastes unterstützen muss.

Der genaue Ablauf und Paketaustausch einer 802.1X Authentifizierung zwischen einemClient und einem RADIUS-Server mit dem Authentifizierungsverfahren EAP-PEAP/EAP-MSCHAPv2 ist unter 2.7 auf Seite 23 detailliert beschrieben.

VLAN Zuweisung

Sobald ein Client erfolgreich authentifiziert wurde, weist der Access Point dem Client jenach Benutzergruppe ein bestimmtes VLAN zu. Der Access Point achtet dabei darauf, obbei einem Access-Accept-Paket die Attribute mit der zu verwenden VLAN-ID gesetzt sindoder nicht. Access-Accept-Pakete für die Clients von Angehörigen der HSU enthalten dieseAttribute, welche bei der internen Authentifizierung vom RADIUS-Server der HSU gesetztwerden. Die Attribute werden vom Access Point ausgewertet und dem Client eines Angehörigender HSU wird das im Attribut angegebene VLAN (VLAN<40>) zugewiesen (dynamischesVLAN-Tagging).Access-Accept-Pakete für die Clients von Gästen enthalten keine Attribute mit einer VLAN-ID.Diesen Clients wird vom Access Point dann automatisch das der SSID „eduroam“ fest zugeteilteVLAN (VLAN<30>) zugewiesen. Bei Access-Accept Paketen, welche für die Clients von Gästenbestimmt sind, sind die Attribute nicht enthalten, da die Gäste durch den RADIUS-Serverihrer Heimateinrichtung authentifiziert werden. Dieser kann zwar auch Attribute mit VLAN-IDsetzen, allerdings müssen diese beim Weiterleiten über RADIUS-Proxys entfernt werden, umdie Access Points von anderen Einrichtungen nicht zu „verwirren“ und dem Gast ggf. ein falschesVLAN zu zuweisen. Um sicher zu gehen, dass keine RADIUS-Pakete mit gesetzten Attributenfür die VLAN-ID das Netzwerk der HSU verlassen oder betreten, prüft der RadSecProxy derHSU alle ein- und ausgehenden RADIUS-Pakete und entfernt ggf. diese Attribute.

Ablauf anhand von Anwendungsfällen

Je nach Anwendungsfall ergeben sich unterschiedliche Abläufe bei der Authentifizierung.Im Folgenden werden anhand der Anwendungsfälle die einzelnen Abläufe bei erfolgreicherAuthentifizierung Schritt für Schritt beschrieben.

Angehöriger der HSU meldet sich am WLAN der HSU an

1. WLAN-Client verbindet sich mit dem Access Point der HSU über die SSID „eduroam“


4. Konzeption 57

2. Client sendet Authentifizierungsanfrage über EAPOL an den Access Point, welcher diesean den Wireless Switch weiterleitet

3. Wireless Switch leitet die Authentifizierungsanfrage als RADIUS-Paket (RADIUS-Request) an den hinterlegten RADIUS-Server der HSU weiter

4. RADIUS-Server prüft die Herkunft des Nutzers anhand des angegebenen Realm

5. Nutzer gehört zur HSU

6. RADIUS-Server führt eine Authentifizierung nach der Methode EAP-PEAP/EAP-MSCHAPv2 durch

7. RADIUS-Server gleicht Benutzerkennung mit dem Active Directory der HSU ab undauthentifiziert den Nutzer

8. RADIUS-Server schickt ein Access-Accept-Paket mit enthaltenen Attributen für dieVLAN-ID an den Access Point und der Client wird vom Access Point autorisiert

9. Access Point weist dem Client ein VLAN anhand der in den RADIUS-Attributenenthaltenen VLAN-ID zu (VLAN<40>)

10. Client bekommt IP-Adresse vom DHCP-Server des VLAN<40> und erhält Zugriff aufdas Internet und Intranet der HSU

Angehöriger der HSU meldet sich am WLAN einer anderen Institution an

1. Institution muss an eduroam teilnehmen

2. WLAN-Client verbindet sich mit dem Access Point einer anderen Institution über dieSSID „eduroam“

3. Client sendet Authentifizierungsanfrage über EAPOL an den Access Point

4. Access Point leitet die Authentifizierungsanfrage als RADIUS-Paket (RADIUS-Request)an den hinterlegten RADIUS-Server der entsprechenden Institution weiter

5. RADIUS-Server prüft die Herkunft des Nutzers anhand des angegebenen Realm

6. Nutzer gehört nicht zur entsprechenden Institution, sondern zur HSU

7. RADIUS-Server leitet die Anfrage an den Top-Level RADIUS-Proxy vom DFN weiter

8. DFN-Top-Level RADIUS-Proxy leitet die Anfrage wiederum an den RadSecProxy derHSU weiter

9. RadSecProxy der HSU leitet die Anfrage an den RADIUS-Server der HSU weiter

10. RADIUS-Server der HSU führt eine Authentifizierung nach der Methode EAP-PEAP/EAP-MSCHAPv2 durch


4. Konzeption 58

11. RADIUS-Server der HSU gleicht Benutzerkennung mit dem Active Directory der HSUab und authentifiziert den Nutzer

12. RADIUS-Server der HSU schickt ein Access-Accept-Paket über den RadSecProxy derHSU, den DFN-Top-Level RADIUS-Proxy und den RADIUS-Server der Institution anden dortigen Access Point

13. Client wird vom dortigen Access Point autorisiert

14. Client bekommt eine IP-Adresse vom DHCP-Server der Institution und erhält Zugriffauf das Internet (zugewiesenes VLAN und IP-Adresse hängt von der Konfiguration derjeweiligen Institution ab)

Gast meldet sich am WLAN der HSU an

1. Gast muss von einer Institution kommen, welche an eduroam teilnimmt

2. WLAN-Client verbindet sich mit dem Access Point der HSU über die SSID „eduroam“

3. Client sendet Authentifizierungsanfrage über EAPOL an den Access Point, welcher diesean den Wireless Switch weiterleitet

4. Wireless Switch leitet die Authentifizierungsanfrage als RADIUS-Paket (RADIUS-Request) an den hinterlegten RADIUS-Server der HSU weiter

5. RADIUS-Server prüft die Herkunft des Gastes anhand des angegebenen Realm

6. Gast gehört nicht zur HSU, sondern zu einer anderen Institution

7. RADIUS-Server der HSU leitet die Anfrage an den RadSecProxy der HSU weiter

8. RadSecProxy leitet die Anfrage per RadSec an den DFN-Top-Level RADIUS-Proxyweiter

9. DFN-Top-Level RADIUS-Proxy leitet die Anfrage wiederum an den RADIUS-Serverder jeweiligen Institution weiter

10. RADIUS-Server der jeweiligen Institution authentifiziert den Nutzer nach der gewähltenAuthentifizierungsmethode

11. RADIUS-Server der Institution schickt ein Access-Accept-Paket über den DFN-Top-Level RADIUS-Proxy, den RadSecProxy der HSU und den RADIUS-Server der HSU anden Access Point der HSU

12. Client wird vom Access Point der HSU autorisiert

13. Access Point weist dem Client das für die SSID „eduroam“ konfigurierte VLAN zu(VLAN<30>)


4. Konzeption 59

14. Client bekommt IP-Adresse vom DHCP-Server des VLAN<30> und erhält Zugriff aufdas Internet

Falls der Gast von einer Institution kommt, die nicht an eduroam teilnimmt, ist eine Anmel-dung am WLAN der HSU nicht ohne weiteres möglich. Der Gast benötigt zunächst einenBenutzeraccount an der HSU. Dieser wird auf Antrag vom Rechenzentrum der HSU ausge-stellt. Der Benutzeraccount muss im Active Directory als Gastbenutzer (Gastgruppe im AD)behandelt werden und darf nicht über die gleichen Rechte wie Angehörige der HSU verfügen.Mit diesem Account kann sich der Gast jetzt an allen eduroam-WLANs innerhalb des eduroamVerbundes anmelden und wird über die HSU authentifiziert. Die Einrichtung des Clients undder Ablauf der Authentifizierung erfolgt dabei wie bei einem Angehörigen der HSU. Allerdingsdarf dem Gast bei der Authentifizierung am WLAN der HSU nicht das VLAN für Angehörige(VLAN<40>) zugewiesen werden. Der Gast darf keinen Zugriff auf das Intranet bekommen.Der RADIUS-Server muss dazu so konfiguriert werden, dass bei Anmeldung des Gastes keineRADIUS-Attribute mit VLAN-ID gesetzt werden. Dann wird dem Gast automatisch dasGast-VLAN (VLAN<30>) vom Access Point zugewiesen.


4. Konzeption 60

4.4. Zusammenfassung

Die Umsetzung wird nach Variante A mit einer SSID und dynamischem VLAN-Taggingdurchgeführt.

Folgende Einstellungen müssen vorgenommen werden:

• SSID: eduroam

• Authentifizierung: 802.1X Authentifizierung

• Verschlüsselung: WPA2-Enterprise (Verschlüsselung durch AES-CCMP-Verfahren)

• Authentifizierungsmethode: EAP-PEAP mit EAP-MSCHAPv2

• Identitätsschutz aktivieren (Seite 51)

• Client / Station Isolation auf Access Point aktivieren (Seite 50)

• VLANs:

– VLAN-ID<10> (Management-VLAN)

– VLAN-ID<20> (ZKI-VLAN)

– VLAN-ID<30> (Gast-VLAN)

– VLAN-ID<40> (VLAN für Angehörige der HSU)

Folgende Komponenten werden für die Umsetzung verwendet:

• Access Point: D-Link DWL-8600AP

• Wireless Switch: D-Link DWS4062

• RADIUS-Server: Windows Server 2008 R2 mit Network Policy Server (NPS)

• RADIUS-Proxy: radsecproxy von UNINETT



5. Performancemessung

Um sicher zu stellen, dass die Nutzer einen schnellen Zugriff auf das WLAN und die angebotenenDienste wie Internet und Intranet haben, wird der Datendurchsatz eines neuen Access Pointsgemessen. Mit dieser Messung soll untersucht werden, wie viele WLAN-Clients gleichzeitig miteinem Access Point verbunden sein können, um die Anforderungen für eine gute Performanceeinzuhalten. Dazu wird in einem Versuchsaufbau mit mehreren WLAN-Clients die möglicheSende- und Empfangsdatenrate gemessen. Hierbei wird auch getestet, inwieweit sich die WPA2-Verschlüsselung auf den Datendurchsatz auswirkt. Im Nachfolgenden wird zunächst auf denVersuchsaufbau und die verwendeten Geräte und Software eingegangen. Anschließend wird derMessablauf beschrieben und die gemessenen Werte erläutert.

5.1. Versuchsaufbau

In der Abbildung 5.1 auf der nächsten Seite ist der Versuchsaufbau dargestellt. Über einenGigabit-Ethernet-Switch (Netgear GS105) sind zwei Computer (netlab-13/14) und der AccessPoint (D-Link DWL-8600AP) mit dem Netzwerk (Subnetz: 141.59.21.0) verbunden. Auf diesenComputern läuft das Netzwerkperformance Messprogramm (Iperf) als Server-Dienst. Überden Access Point verbinden sich die WLAN-Clients mit dem Netzwerk. Auf den Clients läuftIperf als Client-Dienst. Weiterhin ist der RADIUS-Server (netlab-57), welcher für die 802.1XAuthentifizierung dient, über einen Fast-Ethernet-Switch (Cisco Catalyst 3560) mit demNetzwerk verbunden. Um Zugriff auf das Intranet und Internet zu haben, gibt es zusätzlichnoch eine Verbindung mit dem im Labor befindlichen Router. Um die Messungen aber nichtzu verfälschen, wurde diese Verbindung während der Messungen mit Iperf getrennt.



Abbildung 5.1.: Laboraufbau für Performancemessung

5.2. Komponenten im Überblick

5.2.1. Iperf / JPerf

Für die Messung der Netzwerkperformance wird das Programm Iperf zusammen mit dergrafischen Oberfläche JPerf eingesetzt. Iperf ist ein plattformunabhängiges Konsolenprogrammund dient zum Messen der Datenrate einer Netzwerkverbindung. Iperf kann als Server undals Client ausgeführt werden. Für eine Messung wird mindestens ein Server benötigt, mitdem sich ein oder mehrere Iperf-Clients verbinden. Zur Messung kann ein TCP- oder einUDP-Stream erzeugt werden. Dabei erzeugt der Client Daten und schickt diese über dasNetzwerk an den Server, welcher die Daten verwirft. Bei TCP kann zusätzlich ein Datenstromvom Server generiert werden und an den Client zurück gesendet werden. Dadurch ist es möglich,bidirektionale Messungen durchzuführen.JPerf ist eine auf Java basierende grafische Oberfläche für Iperf. JPerf erleichtert die Bedienungund stellt die Messergebnisse grafisch dar. Jperf kann zusammen mit Iperf als bereits fertigkompilierte Windows-Version unter: http://code.google.com/p/xjperf/ heruntergeladen werden.

Für den Laborversuch wird Iperf in der Version 1.7.0 zusammen mit JPerf 2.0.2 eingesetzt.



Alle Messungen werden mit einem TCP-Stream durchgeführt.

Der Iperf-Server wird mit folgenden, von den Standardeinstellungen abweichenden, Einstellun-gen betrieben:

• Transmit: Testzeitdauer unterschiedlich je nach Test

• Output Format: MBits

• TCP Window Size: 256 KBytes

• Testing Mode: Dual oder Trade (je nach gewünschter Testmethode)

• alle anderen Einstellungen bleiben auf Standard

Dies ergibt folgenden Befehl, falls Iperf über die Kommandozeile gestartet werden soll:

iperf -s -P 0 -i 1 -p 5001 -w 256.0K -f m

Der Iperf-Client wird mit folgenden von den Standardeinstellungen abweichenden Einstellungenbetrieben:

• Server address: 141.59.21.23 oder .24

• Transmit: Testzeitdauer unterschiedlich je nach Test

• Output Format: MBits

• TCP Window Size: 256 KBytes

• Testing Mode: Dual oder Trade (je nach gewünschter Testmethode)

• alle anderen Einstellungen bleiben auf Standard

Dies ergibt folgenden Befehl, falls Iperf über die Kommandozeile gestartet werden soll:

iperf -c 141.59.21.23 -P 1 -i 1 -p 5001 -w 256.0K -f m -t 10 -T 1

Für den „Testing Mode“ können zwei unterschiedliche Einstellungen ausgewählt werden: „Dual“und „Trade“. Bei „Trade“ baut der Iperf-Client zunächst eine Verbindung zum Server auf undsendet an diesen eine gewisse Zeit lang Daten (die Zeitdauer wird unter „Transmit“ angegeben).Anschließend baut der Server eine Verbindung zum Client auf und schickt an diesen Datenzurück. Der Client sendet somit zunächst Daten und empfängt dann welche. Senden undEmpfangen erfolgt bei „Trade“ hintereinander. Damit kann die maximale Datenrate für dasSenden und Empfangen unabhängig voneinander gemessen werden. Bei „Dual“ hingegen sendetund empfängt der Client gleichzeitig Daten. Hiermit kann die Datenrate bei gleichzeitigemSenden und Empfangen gemessen werden. Falls weder „Trade“ noch „Dual“ gewählt wird,werden nur vom Client Daten an den Server gesendet (dies ist die Standardeinstellung). AlleMessungen erfolgen aus Sicht des Clients. Beim Senden sendet also der Client Daten an denServer und beim Empfangen empfängt der Client Daten vom Server.



5.2.2. Iperf-Server

Für den Iperf-Server werden die zwei Computer „netlab-13/14“ verwendet. Beide Computer sindüber Gigabit-Ethernet mit dem Netzwerk verbunden und haben eine identische Konfiguration.

Prozessor: Intel Pentium 4 @ 3,0 GHz

Speicher: 1 GB RAM

LAN-Controller: Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller

Treiber: Marvell 10.51.1.9 vom 06.12.2007

Betriebssystem: Windows XP Professional SP3

IP: 141.59.21.23 / .24

5.2.3. Iperf-Client

Als Iperf-Client werden insgesamt drei verschiedene Systeme in unterschiedlicher Anzahlverwendet, um Tests mit unterschiedlichen WLAN-Standards (802.11g/n) durchführen zukönnen. Alle Systeme sind über WLAN mit dem Netzwerk verbunden.

• WLAN-Clients für 802.11g (10 Stück)

Computer: netlab-03/04/05/06/07/08/09/53/54/55

Prozessor: Intel Pentium 4 @ 3,0 GHz

Speicher: 1 GB RAM

WLAN-USB-Stick: ZyXEL G-220F (802.11g Wireless USB Adapter)

Treiber: ZyXEL 3.0.0.0 vom 24.02.2005

Betriebssystem: Windows XP Professional SP3

IP-Adresse: 141.59.21.160 - .169

• WLAN-Client für 802.11n (3 Stück)

Laptop: HP Compaq 6910p (nb-netlab-06/07/10)

Prozessor: Intel Core 2 Duo T7300 @ 2,0 GHz

Speicher: 2 GB RAM

WLAN-Controller: Intel Wireless WiFi Link 4965AGN

Treiber: Intel 12.2.0.11 vom 17.11.2008



Betriebssystem: Windows Vista-Business 32-Bit SP2

IP-Adresse: 141.59.21.170 - .172

• WLAN-Client für 802.11n (1 Stück)

Laptop: Apple MacBook 13“

Prozessor: Intel Core 2 Duo P8600 @ 2,4 GHz

Speicher: 4 GB RAM

WLAN-Controller: Airport Extreme a/b/g/n

Betriebssystem: Mac OS X 10.6.7

IP-Adresse: 141.59.21.154

5.2.4. Access Point

Beim zu testenden Access Point handelt es sich um einen D-Link DWL-8600AP. DieserAccess Point unterstützt die WLAN-Standards 802.11a/b/g/n und besitzt zwei Funkmodule(Dualband für 2,4 GHz und 5 GHz). Für jedes Frequenzband stehen jeweils zwei externeAntennen zur Verfügung. Der Access Point unterstützt im Standard 802.11n zwei Datenströmein eine Richtung gleichzeitig (Multiple In Multiple Out (MIMO)). Zusammen mit einerKanalbandbreite von 40 MHz ermöglicht der Access Point Datenraten von bis zu 300 MBit/s(brutto) im 802.11n-Standard unter 5 GHz. Der Access Point kann sowohl „standalone“ alsauch zusammen mit einem Wireless Switch (D-Link DWS4062) eingesetzt werden [DWL8600].Im Versuch wird der Access Point als „standalone“-Gerät verwendet. Es werden in jedemFrequenzband zwei virtuelle Access Points mit unterschiedlicher SSID konfiguriert:

SSID1: 24bgn-open (2,4 GHz mit 802.11b/g/n ohne Verschlüsselung)

SSID2: 24bgn-radius (2,4 GHz mit 802.11b/g/n mit WPA2-Verschlüsselung über 802.1XAuthentifizierung)

SSID3: 5n-open (5,0 GHz mit 802.11n ohne Verschlüsselung)

SSID4: 5bgn-radius (5,0 GHz mit 802.11n mit WPA2-Verschlüsselung über 802.1X Authen-tifizierung)

Die Kanalwahl ist sowohl im 2,4-GHz- als auch im 5,0-GHz-Band auf „Auto“ gesetzt. Alleweiteren Einstellungen besitzen den Standardwert. Der Access Point ist unter der IP-Adresse141.59.21.150 erreichbar und so konfiguriert, dass er für die 802.1X Authentifizierung mit demRADIUS-Server (netlab-57 unter 141.59.21.57) kommuniziert.



5.3. Durchführung und Auswertung der Messung

5.3.1. Datenrate Iperf-Server

Beschreibung

In der ersten Messung wird die Datenrate der Iperf-Server über den Netgear Gigabit-Ethernet-Switch gemessen. Hiermit soll sichergestellt werden, dass auch eine genügend hohe Datenratemöglich ist, damit sich auch mehrere Iperf-Clients mit dem Iperf-Server über WLAN verbindenkönnen und die volle Datenrate über WLAN erreicht wird. Es soll somit ausgeschlossen werden,dass das Gigabit-Ethernet das WLAN bremst.

Durchführung

Für diese Messung wird einer der beiden Iperf-Server zu einem Client umkonfiguriert. Anschlie-ßend werden zwei Messungen für je zehn Sekunden ausgeführt. Zuerst mit „Testing Mode“,eingestellt auf „Trade“, um die maximale Datenrate von Senden und Empfangen unabhän-gig voneinander zu messen. Anschließend wird der „Testing Mode“ „Dual“ gewählt, um dieDatenrate für eine bidirektionale Übertragung (Full-Duplex) zu messen.

Auswertung

Aus der Messung ergeben sich die in der Tabelle 5.1 dargestellten Werte.

Testing Mode Datenrate Senden[MBit/s] Datenrate Empfangen [MBit/s]Trade 582,0 587,0Dual 307,0 310,0

Tabelle 5.1.: Datenrate Iperf-Server

Aus den Werten geht hervor, dass im Modus „Trade“, beim wechselseitigem Senden undEmpfangen eine Datenrate von über 580 MBit/s (69,14 MByte/s)1möglich ist. Praktischsollten bei Gigabit-Ethernet Datenraten von über 900 MBit/s (107,29 MByte/s) möglich sein.

1Die Umrechnung erfolgt nach folgender Annahme:1Byte � 8Bit1024Byte � 8192Bit1KByte � 8, 192KBit1024KByte � 8388, 608KBit1MByte � 8, 388608MBit



Da die Gigabit-Netzwerkkarte in diesen beiden Computern aber über den PCI-Bus angebundenist, können keine maximalen Datenraten von über 900 MBit/s erreicht werden, da der PCI-Busdafür zu langsam ist. Die Datenrate eines 32 Bit PCI-Bus mit 33 MHz liegt theoretisch bei133 MByte/s. Praktische Datenraten liegen aber deutlich darunter und der PCI-Bus wird nochvon weiteren Geräten verwendet, wodurch die für die Netzwerkkarte zur Verfügung stehendeDatenrate noch weiter gesenkt wird.Im Modus „Dual“ wird bidirektional im Full-Duplex-Verfahren gesendet und empfangen. DieDatenraten fallen hier auf 310 MBit/s ab, da sie auf Senden und Empfangen aufgeteilt werden.In der Summe liegt die Datenrate dann bei 620 MBit/s, was wiederum durch den PCI-Busbegrenzt wird.Die hier gemessenen Werte sind für den Test völlig ausreichend, da der Access Point einetheoretische Datenrate von maximal 300 MBit/s erreicht. Der Access Point wird also nichtdurch das Gigabit-Ethernet gebremst.

5.3.2. Datenrate einzelner WLAN-Clients

Beschreibung

Um zu sehen, welche Datenraten mit einem allein am Access Point angemeldeten WLAN-Clientmaximal möglich sind, werden jeweils die Datenraten von einem WLAN-Client nach 802.11gund einem WLAN-Client nach 802.11n unabhängig voneinander gemessen. Bei den n-Clientskommen zwei unterschiedliche Geräte zum Einsatz, um zu erkennen, ob ein Unterschiedbei Geräten mit unterschiedlicher Hardware auftritt. Alle Messungen von n-Geräten werdensowohl unter 2,4 GHz als auch unter 5 GHz durchgeführt, um einen Vergleich zwischen denDatenraten der beiden Bänder zu haben. Um festzustellen, ob die WPA2-Verschlüsselungsich auf die Datenraten auswirkt, werden alle Messungen einmal mit und einmal ohne WPA2-Verschlüsselung durchgeführt.

WLAN-Client nach 802.11g

Durchführung

Im Folgenden wird die Datenrate eines WLAN-Clients nach dem Standard 802.11g gemessen.Als WLAN-Gerät wird der WLAN-USB-Stick „ZyXEL G-220F“ verwendet, wie unter 5.2.3 aufSeite 64 beschrieben. Der WLAN-Client ist als einziges Geräte am Access Point angemeldetund befindet sich in einem Abstand von ca. drei Metern zum Access Point. Es werden insgesamtvier Messungen durchgeführt. Einmal im „Testing Mode“ „Trade“ und anschließend im Mode



„Dual“. Jede Messung wird jeweils einmal ohne Verschlüsselung und anschließend mit WPA2-Verschlüsselung über 802.1X Authentifizierung ausgeführt.

Auswertung

Aus der Messung ergeben sich die in der Tabelle 5.2 dargestellten Werte.

Testing Mode Verschl. Datenrate 2,4 GHz [MBit/s]Senden Empfangen

Trade - 20,4 20,8Trade WPA2 20,6 20,6Dual - 10,4 10,3Dual WPA2 10,3 10,3

Tabelle 5.2.: Datenrate WLAN-Client (802.11g)

Im Mode „Trade“ erreicht ein WLAN-Client nach dem Standard 802.11g eine maximaleÜbertragungsrate von über 20 MBit/s sowohl beim Senden als auch beim Empfangen. Diesentspricht den Erwartungen, da die maximale Nettodatenrate bei 22 MBit/s liegt (sieheTabelle 2.1 auf Seite 4). Im Mode „Dual“ fällt die Datenrate bei gleichzeitigem Senden undEmpfangen auf über 10 MBit/s ab. Das liegt daran, dass ein WLAN-Gerät entweder Sendenoder Empfangen kann. Beides gleichzeitig (Full-Duplex) ist nicht möglich, da es sich bei WLANum ein „Shared-Medium“ handelt, welches sich jeder Sender und Empfänger teilen muss. Dahermuss das Gerät immer zwischen Senden und Empfangen hin und her wechseln. Im besten Fallteilen sich die Datenraten gleichmäßig auf Senden und Empfangen auf.Zwischen deaktivierter und aktivierter WPA2-Verschlüsselung ist bei den Datenraten keinsignifikanter Unterschied erkennbar. Die WPA2-Verschlüsselung wirkt sich also bei einemWLAN-Gerät allein nicht negativ auf die Datenrate aus.

WLAN-Client nach 802.11n

Durchführung

Bei diesem Versuch wird die Datenrate eines WLAN-Clients nach dem Standard 802.11ngemessen. Als WLAN-Gerät wird einmal ein MacBook und ein HP-Laptop unabhängigvoneinander verwendet, wie unter 5.2.3 auf Seite 64 beschrieben. Der WLAN-Client ist alseinziges Geräte am Access Point angemeldet und befindet sich in einem Abstand von ca.drei Metern zum Access Point. Es werden pro Gerät insgesamt acht Messungen durchgeführt.



Einmal im „Testing Mode“ „Trade“ und anschließen im Mode „Dual“. Jede Messung wirdjeweils einmal ohne Verschlüsselung und anschließend mit WPA2-Verschlüsselung über 802.1XAuthentifizierung ausgeführt. Da der Standard 802.11n auch das 5-GHz-Band unterstützt,wird jede Messung zusätzlich auch unter 5 GHz durchgeführt.

Auswertung

Aus der Messung ergeben sich für das MacBook die in der Tabelle 5.3 dargestellten Werte undfür das HP-Laptop die in der Tabelle 5.4 dargestellten Werte.

Testing Mode Verschl. Datenrate 2,4 GHz [MBit/s] Datenrate 5 GHz [MBit/s]Senden Empfangen Senden Empfangen

Trade - 96,4 79,0 164,0 123,0Trade WPA2 96,8 79,1 160,0 122,0Dual - 74,6 18,7 122,0 31,7Dual WPA2 74,9 18,7 121,0 31,8

Tabelle 5.3.: Datenrate MacBook (802.11n)

Das MacBook erreicht im Mode „Trade“ eine Senderate von über 96 MBit/s im 2,4-GHz-Bandund über 160 MBit/s unter 5 GHz. Die Empfangsdatenraten liegen etwas darunter. Diesentspricht sehr guten Werten und zeigt welche Datenraten nach dem Standard 802.11n möglichsind. Im Mode „Dual“ verteilt sich die Datenrate auf Senden und Empfangen in einem Verhältnisvon ungefähr 4:1. Wie zu erkennen ist, liegen die Datenraten im 5-GHz-Band deutlich überden unter 2,4 GHz gemessenen Werten. Dies liegt daran, dass der Access Point erst unter 5GHz eine Kanalbreite von 40 MHz verwendet und somit seine maximale Bruttodatenrate von300 MBit/s zur Verfügung stellt. Unter 2,4 GHz arbeitet er nur mit einer Kanalbreite von 20MHz und einer Bruttodatenrate von 145 MBit/s. Anhand der Werte ist zu erkennen, dassauch hier die WPA2-Verschlüsselung keinen Einfluss auf die Datenrate hat.

In der Tabelle 5.4 sind die Messwerte des HP-Laptops aufgeführt. Diese liegen etwas unterden Werten vom MacBook, da das HP-Laptop eine andere WLAN-Hardware verwendet.

Testing Mode Verschl. Datenrate 2,4 GHz [MBit/s] Datenrate 5 GHz [MBit/s]Senden Empfangen Senden Empfangen

Trade - 77,6 79,2 140,0 117,0Trade WPA2 76,9 78,8 138,0 119,0Dual - 55,7 12,5 115,0 29,5Dual WPA2 51,6 13,3 113,0 29,6

Tabelle 5.4.: Datenrate HP-Laptop (802.11n)



5.3.3. Datenrate mehrerer WLAN-Clients zusammen

Beschreibung

Nach Messung der Datenrate eines einzelnen WLAN-Clients werden anschließend die Datenra-ten mehrerer WLAN-Clients zusammen gemessen. Diese Messungen sollen zeigen, wie sich dieDatenrate auf mehrere gleichzeitig aktive Clients aufteilt. Dabei wird eine Messung mit biszu zehn aktiven g-Clients und eine Messung mit bis zu drei aktiven n-Clients durchgeführt.In einer weiteren Messung werden die Datenraten im Mischbetrieb von fünf g-Clients unddrei n-Clients gemessen. Dabei wird die Messung der n-Clients einmal im 2,4-GHz-Band undanschließend im 5-GHz-Band durchgeführt, um festzustellen, inwieweit sich die Datenraten inden zwei Bändern unterscheiden und ob sich die beiden Bänder gegenseitig beeinflussen.

WLAN-Clients nach 802.11g

Durchführung

Bei den Clients nach 802.11g wird die Datenrate mit bis zu zehn gleichzeitig aktiven Clientsgemessen. Dabei wird der „Testing Mode“ „Dual“ gewählt, welcher die Clients gleichzeitigsenden und empfangen lässt. Zur Ermittlung des Messwerts werden die einzelnen Messwertefür Senden und Empfangen aufsummiert und durch die Anzahl der jeweils beteiligten Clientsdividiert. Alle Messungen finden mit aktivierter WPA2-Verschlüsselung statt. Der Abstandder Geräte zum Access Point liegt dabei zwischen drei und acht Metern.

Auswertung

In Tabelle 5.5 sind die gemessenen Werte aufgeführt.

Anzahl Verschl. Datenrate 2,4 GHz [MBit/s]Senden Empfangen

1 WPA2 10,3 10,32 WPA2 5,2 5,43 WPA2 3,4 3,34 WPA2 2,5 2,55 WPA2 2,1 2,010 WPA2 1,0 1,010 - 1,0 1,0

Tabelle 5.5.: Datenrate mehrerer WLAN-Clients (802.11g)



Anhand der Werte ist zu erkennen, dass sich die Datenraten auf die Anzahl der aktiven Geräteaufteilen. Bei 10 gleichzeitig aktiven Clients hat jeder Client auch nur noch ein Zehntel dermaximalen Datenrate zur Verfügung. Da es sich bei WLAN um ein „Shared-Medium“ handelt,kann immer nur ein Client gleichzeitig senden oder empfangen. Jeder Client muss sich mit Hilfedes CSMA/CA-Verfahrens mit den anderen Clients abstimmen, damit keine Kollisionen beimgleichzeitigen Senden entstehen. Die letzte Messung mit 10 Clients wurde zudem auch nochohne Verschlüsselung durchgeführt, um zu testen, ob ein Einfluss der WPA2-Verschlüsselungzu erkennen ist. Allerdings ist auch hier kein Unterschied erkennbar.

In der Abbildung 5.2 ist der Zusammenhang zwischen Datenrate und Anzahl der Clients zuerkennen. Der Kurvenverlauf ist die Funktion: max.Datenrate

AnzahlClients . Dies entspricht der Funktion: 1x .

Abbildung 5.2.: Datenrate WLAN-Clients (802.11g)

WLAN-Clients nach 802.11n

Durchführung

Bei den Clients nach 802.11n werden bis zu drei HP-Laptops gleichzeitig verwendet. DieMessung erfolgt hier im 2,4-GHz- und 5-GHz-Band wiederum im „Testing Mode“ „Dual“.



Auswertung

In Tabelle 5.6 sind die Messwerte dargestellt.

Anzahl Verschl. Datenrate 2,4 GHz [MBit/s] Datenrate 5 GHz [MBit/s]Senden Empfangen Senden Empfangen

1 WPA2 51,6 13,3 113,0 29,62 WPA2 23,0 5,9 57,7 14,83 WPA2 14,3 4,2 37,0 9,33 - 15,0 4,2 37,3 9,8

Tabelle 5.6.: Datenrate mehrerer WLAN-Clients (802.11n)

Auch hier ist zu erkennen, dass sich die Datenraten auf die Anzahl der aktiven Geräte aufteilen.Aus der Tabelle 5.6 geht auch deutlich hervor, dass die Datenraten im 5-GHz-Band deutlichdoppelt so hoch wie im 2,4-GHz-Band sind, was wiederum an der Kanalbandbreite von 40MHz im 5-GHz-Band liegt. Die WPA2-Verschlüsselung beeinflusst auch hier die Datenratennicht.

In Abbildung 5.3 ist der Verlauf der Datenrate in Abhängigkeit von der Anzahl der Clientsdargestellt.

Abbildung 5.3.: Datenrate mehrerer WLAN-Clients (802.11n)



Mischbetrieb (802.11g und 802.11n)

Durchführung

In dieser Messung wird die Datenrate bei Mischbetrieb von 802.11g- und 802.11n-Gerätengemessen. Dabei werden fünf g-Geräte und drei n-Geräte verwendet. Die Messung findet einmalmit allen Geräten im 2,4-GHz-Band und anschließend mit den n-Geräten im 5-GHz-Band undden g-Geräten im 2,4-GHz-Band statt. Die Messungen werden einmal mit und einmal ohneWPA2-Verschlüsselung durchgeführt. Alle Messungen werden im „Testing Mode“ „Dual“ beieinem Geräteabstand von drei bis acht Metern zum Access Point durchgeführt.

Auswertung

Bei der Messung ergeben sich die in Tabelle 5.7 aufgeführten Werte.

Konstellation Verschl. Datenrate g-Geräte [MBit/s] Datenrate n-Geräte [MBit/s]Senden Empfangen Senden Empfangen

n in 2,4 GHz WPA2 1,5 1,5 3,6 0,6n in 2,4 GHz - 1,5 1,5 3,8 0,7n in 5 GHz WPA2 2,0 2,1 37,1 10,1n in 5 GHz - 2,0 2,0 33,8 9,6

Tabelle 5.7.: Datenrate Mischbetrieb mit 5 g-Geräten und 3 n-Geräten

Anhand der Messwerte ist zu erkennen, dass die Performance der n-Geräte bei einem Mischbe-trieb im 5-GHz-Band deutlich höher liegt, wie wenn sich die n-Geräte auch im 2,4-GHz-Bandbefinden. Gerade beim Empfangen liegt die Datenrate mit 0,6 MBit/s der n-Geräte im 2,4-GHz-Band sogar unter der der g-Geräte (1,5 MBit/s).Deswegen sollten n-Geräte, wenn möglich, immer im 5-GHz-Band betrieben werden, um dievolle Datenrate erreichen zu können. Weiterhin ist auch keine Beeinflussung zwischen denbeiden Bändern zu erkennen. Die g-Geräte im 2,4-GHz-Band und n-Geräte im 5-GHz-Banderzielen im Mischbetrieb die gleichen Datenraten, wie Geräte, welche nur in einem Band aktivsind. Daraus ergibt sich, dass bei „überlastetem“ 2,4-GHz-Band, im 5-GHz-Band immer nochdie volle Datenrate möglich ist. Auch die WPA2-Verschlüsselung hat wiederum keinen Einflussauf die Datenraten.



5.3.4. Access Point Cluster

Beschreibung

Um die Datenraten mehrerer Geräte zu verbessern, werden im letzten Test zwei Access Pointsim Cluster eingesetzt. Durch den zweiten Access Point soll sich der Datenverkehr verteilenund höhere Datenraten ermöglichen. Weiterhin soll geklärt werden, ob sich die beiden AccessPoints gegenseitig beeinflussen.

Durchführung

Die Access Points sind zu einem Cluster zusammengefasst und besitzen daher die gleicheKonfiguration. Sie strahlen somit beide die gleiche SSID aus. Der zweite Access Point wirdsieben Meter neben dem ersten aufgestellt. Für den Test werden fünf g-Geräte und drein-Geräte sowohl unter 2,4 GHz als auch unter 5 GHz im Mischbetrieb verwendet.

Auswertung

Anstatt bessere Datenraten zu liefern, waren die Datenraten in einem ersten Test im 2,4-GHz-Band deutlich schlechter als bei nur einem Access Point und gingen des Öfteren gegen Null.Dies ist ein Zeichen für auftretende Kollisionen. Eine Überprüfung der Funkkanäle ergab im2,4-GHz-Band den Kanal 5 und 9. Die Kanäle wurden von der Automatik des Access Pointsgewählt. Allerdings ist ein Kanalabstand von nur 4 Kanälen zu gering. Dadurch kommt es zuStörungen zwischen den Access Points. Der Kanalabstand sollte für störungsfreien Betriebim 2,4-GHz-Band mindesten 5 oder besser noch 6 Kanäle betragen. Daraufhin wurden dieKanäle manuell auf Kanal 1 und 13 gesetzt (diese Kanäle waren am wenigsten durch andereAccess Points benutzt). Eine erneute Messung zeigte, dass die zuvor aufgetretenen Problemeverschwunden waren und die Datenraten der einzelnen Geräte jetzt höher lagen, da ein Teilder Geräte jetzt mit dem zweiten Access Point kommunizieren konnte, ohne den Ersten zustören. Im 5-GHz-Band wurde dies nicht beobachtet. Hier wurden vom Access Point Kanälemit ausreichend Abstand gewählt.Aufgrund dieser Erkenntnis ist darauf zu achten, dass benachbarte Access Points mit auto-matischer Kanalwahl keine zu nah liegenden Kanäle wählen. Bei auftretenden Problemensollten die Kanäle am besten von Hand vergeben werden. In Kombination mit einem WirelessSwitch (D-Link DWS4026), mit welchem die Access Points später betrieben werden, werdendie Kanäle von diesem vergeben und nicht mehr vom Access Point selbst [DWS4026]. Ob dasoben beschriebene Problem auch hier auftritt, konnte nicht überprüft werden, da kein WirelessSwitch für Testzwecke zur Verfügung stand.



5.4. Zusammenfassung

Aus den Messungen geht hervor, dass die WPA2-Verschlüsselung keinen negativen Einfluss aufdie Datenraten hat und somit ohne Performanceverluste verwendet werden kann. Der einziglimitierende Faktor ist die Funkübertragung selber, da es sich dabei um ein „Shared-Medium“handelt und die zur Verfügung stehende Datenrate auf die aktiven WLAN-Clients aufgeteiltwird. Mit zunehmender Anzahl von Clients nimmt somit die pro Client zur Verfügung stehendeDatenrate ab.

Weiterhin geht aus den Messungen hervor, dass die Datenraten von Geräten nach demStandard 802.11n im 5-GHz-Band doppelt so hoch sind als wie unter 2,4 GHz. Dies liegt aneiner Kanalbreite von 40 MHz, welche nur im 5-GHz-Band vom Access Point verwendet wird.Ein n-Gerät kann daher nur im 5-GHz-Band seine maximal mögliche Datenrate erreichen.Da das 2,4-GHz-Band und das 5-GHz-Band sich nicht gegenseitig beeinflussen und somit ohnePerformanceeinbußen parallel genutzt werden können, sollten n-Geräte, wenn möglich, immerunter 5 GHz betrieben werden. Dadurch wird zusätzlich auch das 2,4-GHz-Band entlastet.Um sicher zustellen, dass sich n-Geräte nur unter 5 GHz verbinden, sollte die n-Unterstützungunter 2,4 GHz deaktiviert werden. Im 2,4-GHz-Band sollten sich nur Geräte nach 802.11b/gverbinden können.Da b-Geräte mittlerweile recht selten sind und die meisten Geräte mindestens den Standard802.11g unterstützen, kann ggf. die Unterstützung für 802.11b deaktiviert werden und nur eineinheitliches WLAN nach 802.11g im 2,4-GHz-Band betrieben werden. Dies würde weiterhinauch noch zu einer kleinen Erhöhung der Datenraten für g-Geräte führen, da die Management-Frames jetzt nicht mehr nach dem 802.11b-Standard (aufgrund von Kompatibilitätsgründenfür b-Geräte) übertragen werden müssten. Allerdings ist bei den Access Points D-Link DWL-8600AP kein reiner g-Betrieb möglich. Es kann nur ein Mischbetrieb aus b und g eingestelltwerden.Auf den Standard 802.11a im 5-GHz-Band sollte komplett verzichtet werden, da dieser inEuropa recht wenig verbreitet ist und zu einer schlechteren Performance (aufgrund vonKompatibilitätsgründen) für n-Geräte führt.

Die Messungen zeigen auch, dass zehn gleichzeitig aktive Geräte nach dem Standard 802.11gmit einer Sende- und Empfangsauslastung von 100% problemlos mit einem Access Pointbetrieben werden können und noch ausreichend Performance bieten. In der Praxis ist eineAuslastung von 100% bei allen Geräten gleichzeitig eher unwahrscheinlich. Im Mittel kannungefähr mit einer Auslastung um die 30% pro Gerät gerechnet werden. Daher sollte inder Praxis ein problemloser Betrieb mit bis zu 30 oder sogar noch mehr gleichzeitig aktiveng-Clients im 2,4-GHz-Band pro Access Point möglich sein.Aufgrund der höheren Datenraten im 5-GHz-Band sollten hier, bei einer Auslastung der Geräte



von 30%, bis zu 50 Geräte gleichzeitig pro Access Point betrieben werden können.In beiden Bändern zusammen wären das dann 80 Geräte pro Access Point. Hierbei ist allerdingszu beachten, dass es sich nur um Annahmen handelt, da für einen Test nicht genügend WLAN-Clients zur Verfügung standen. Erst in der Praxis wird sich dann zeigen, wie viele Gerätewirklich an einem Access Point betrieben werden können, bis es zu einer schlechten Performancekommt. Falls sich später herausstellen sollte, dass an bestimmten Plätzen die Access Pointsüberlastet sind, kann durch das Anbringen eines weitere Access Point in einem Abstand vonein paar Metern zum Ersten, der andere Access Point entlastet werden. Die Last teilt sichdann auf beide Acces Points auf. Hierbei ist allerdings darauf zu achten, dass die Access Pointseinen ausreichenden Kanalabstand aufweisen und sich somit nicht gegenseitig stören.

Folgende Erkenntnisse werden aus den Messungen gewonnen:

• 802.11n nur im 5-GHz-Band aktivieren!

• Einstellungen Funkmodule:

– 2,4 GHz: 802.11b/g (ggf. nur 802.11g (bei D-Link DWL-8600AP nicht möglich))

– 5 GHz: 802.11n

• Verschlüsselung: WPA2-Enterprise (Verschlüsselung durch AES-CCMP-Verfahren)

• Skalierung: bis zu 80 WLAN-Clients pro Access Point, dabei 30 unter 2,4 GHz und 50unter 5 GHz

• Abstand: ist so zu wählen, dass Funkzellen sich im Randbereich überlappen. Aber aufeinen ausreichenden Kanalabstand achten (mindestens 5 Kanäle unter 2,4 GHz).


6. Umsetzung 77

6. Umsetzung

In diesem Kapitel werden wichtige Schritte und die Konfiguration der verwendeten Kompo-nenten beschrieben, um das WLAN auf die 802.1X Authentifizierung umzustellen und an dasDFNRoaming/eduroam anzubinden. Die dabei getroffenen Entscheidungen und gewähltenEinstellungen gehen aus den vorhergehenden Kapiteln 4 und 5 hervor.

6.1. DFN-Anmeldung

Für die Teilnahme an eduroam über das DFN (DFNRoaming) muss mit dem DFN zunächstKontakt aufgenommen werden. Weitere Infos dazu können folgendem Link entnommen werden:http://www.dfn.de/dienstleistungen/dfnroaming/.Dem DFN müssen dabei folgende Angaben mitgeteilt werden:

• Realmder zu verwendende Realm („@hs-ulm.de“), ggf. auch weitere Realms zur Separierungder hochschulangehörigen Benutzer (z. B. „@student.hs-ulm.de“, „@dozent.hs-ulm.de“)

• Externe IP-Adresse des RadSecProxyUm Authentifizierungsanfragen an den RadSecProxy der HSU weiterleiten zu können,muss dem DFN die externe IP-Adresse des Servers bekannt sein, auf welchem derradsecproxy von UNINETT läuft.

6.2. VLAN

Wie unter 4.3.4 auf Seite 53 beschrieben, müssen folgende VLANs, falls diese noch nichtbestehen, eingerichtet werden:

• VLAN-ID<10> (Management-VLAN)

• VLAN-ID<20> (ZKI-VLAN)

• VLAN-ID<30> (Gast-VLAN)


http://www.dfn.de/dienstleistungen/dfnroaming/

6. Umsetzung 78

• VLAN-ID<40> (VLAN für Angehörige der HSU)

Für das Gast- und Angehörigen-VLAN muss zudem jeweils ein eigener IP-Adressbereichfestgelegt werden und ein DHCP-Server konfiguriert werden. Anschließend müssen in derFirewall Regeln vergeben werden, um den zwei VLANs unterschiedliche Rechte zu zuweisen.Hierbei ist zu beachten, dass aus dem Gast-VLAN ein Zugriff nur auf das Internet erfolgendarf. Ein Zugriff auf das Intranet der Hochschule darf für Gäste nicht möglich sein.

6.3. Access Points

Die Access Points D-Link DWL-8600AP werden zusammen mit dem Wireless Switch D-LinkDWS4062 eingesetzt. Die Konfiguration folgt daher zentral über den Wireless Switch. AlleAccess Points müssen dem Management VLAN (VLAN<10>) zugewiesen werden und miteiner IP-Adresse versehen werden.Aus den Kapiteln 4 und 5 ergibt sich folgende Konfiguration für die Funkschnittstelle.

Einstellungen für die Access Points:

• Einstellungen Funkmodule:

– 2,4 GHz: 802.11b/g

– 5 GHz: 802.11n

• SSID „eduroam“:

– Authentifizierung: 802.1X RADIUS-Authentifizierung

– Sicherheit: WPA2-Enterprise mit AES-CCMP-Verschlüsselung

– RADIUS-Server: IP-Adresse vom RADIUS-Server der HSU

– VLAN: VLAN<30> (Gast-VLAN)

• SSID „ZKI“:

– Verschlüsselung: Keine

– VLAN: VLAN<20> (ZKI-VLAN)

• Client / Station Isolation aktivieren (Seite 50)


6. Umsetzung 79

6.4. Firewall

In der Firewall müssen Regeln so erstellt werden, dass Gäste nur Zugang zum Internet undnicht zum Intranet der HSU bekommen. Das kann anhand der IP-Adressen konfiguriert werden,welche den Gästen vom DHCP-Server zugewiesen werden.

Weiterhin müssen in der Firewall die folgenden Ports für das RADIUS- und RadSec-Protokollfreigegeben werden.

Einstellungen für Firewall:

• RADIUS-Server

RADIUS-Anfragen (Authentifizierung): UDP-Port 1812

RADIUS-Anfragen (Accounting): UDP-Port 1813

• RadSecProxy

RADIUS-Anfragen (Authentifizierung): UDP-Port 1812

RADIUS-Anfragen (Accounting): UDP-Port 1813

RadSec-Anfragen: TCP-Port 2083

6.5. RADIUS-Server

Im Folgenden wird auf die Konfiguration des RADIUS-Server unter Windows Server 2008 mitdem Network Policy Server (NPS) eingegangen. Die Beschreibung der Konfiguration beziehtsich dabei auf Server 2008 und Server 2008 R2.

Für NPS wird Windows Server 2008 Standard, Enterprise oder Datacenter benötigt. Beider Standard-Edition können allerdings nur bis zu 50 RADIUS-Clients und zwei Remote-RADIUS-Server konfiguriert werden. Bei Enterprise und Datacenter hingegen, gibt es keineEinschränkungen. [TecFacts]

6.5.1. Installation

Um den NPS zu installieren, wird ein fertig eingerichteter Windows Server 2008 benötigt,welcher Mitglied der Domäne (hs-ulm.de) ist. Der NPS kann auch direkt auf dem Domänen-controller installiert werden. Aus Sicherheitsgründen ist es jedoch angebracht, einen eigenen


6. Umsetzung 80

Server dafür zu verwenden. Allerdings muss zur Authentifizierung ein Zugriff auf das ActiveDirectory des Domänencontrollers möglich sein.

Der NPS wird im Server-Manager als neue Rolle („Network Policy and Access Services“)hinzugefügt. Anschließend muss der NPS mit dem Active Directory verbunden werden. Dazuden NPS auswählen und unter „Action“ auf „Register server in Active Directory“ klicken. Umsicher zu stellen, dass der NPS läuft, muss „Start NPS“ ausgegraut sein.

6.5.2. Zertifikat

Um später die Authentifizierungsmethode EAP-PEAP verwenden zu können, wird ein gültigesServer-Zertifikat auf dem RADIUS-Server benötigt, welches zur Serveridentifikation dient. DasZertifikat muss von der Zertifizierungsstelle der Hochschule ausgestellt und signiert werden.Anschließend muss das Zertifikat zusammen mit der zur Prüfung benötigten Zertifikatsketteim Zertifikatsspeicher auf dem Server abgelegt werden.Im Fall der HSU wird das Zertifikat von der Zertifizierungsstelle der HSU, welche durch die PKIdes DFN bereitgestellt wird, ausgestellt. Die DFN-PKI wird unter: https://pki.pca.dfn.de/hs-ulm-ca/pub zur Verfügung gestellt. Hier können auch die CA-Zertifikate und das Wurzelzertifi-kat der Zertifikatskette heruntergeladen werden.

Weitere Information zur DFN-PKI stehen unter folgendem Link zur Verfügung(https://www.pki.dfn.de/).

Für die HSU ergibt sich folgende Zertifikatskette:

Deutsche Telekom Root CA 2 (Wurzelzertifikat)

DFN-Verein PCA Global – G01 (CA-Zertifikat DFN)

HSU-CA (CA-Zertifikat der HSU)

rz-console.hs-ulm.de (Zertifikat für RADIUS-Server)

6.5.3. Konfiguration

Nachfolgend wird auf alle wesentlichen Schritte, welche für die Konfiguration des NPS vonBedeutung sind, eingegangen. Die Konfiguration erfolgt über den Server-Manger. Alle nichterwähnten Einstellungen verbleiben auf Standard.

Weitere Informationen zur Konfiguration können im Microsoft TechNet nachgelesen werden[TecNPS].


https://pki.pca.dfn.de/hs-ulm-ca/pub

https://pki.pca.dfn.de/hs-ulm-ca/pub

https://www.pki.dfn.de/

6. Umsetzung 81

RADIUS-Clients

Alle RADUS-Clients, die Authentifizierungsanfragen (Access-Requests) an den RADIUS-Serverschicken dürfen, müssen im NPS als RADIUS-Client eingetragen werden. Als RADIUS-Clientkönnen Access Points, Wireless Switches und RADIUS-Proxys fungieren.Im Netzwerk der HSU werden die Access Points zusammen mit einem Wireless Switch eingesetzt.Daher fungiert der Wireless Switch als RADIUS-Client und nicht die Access Points selber.Auch der RadSecProxy, welcher Authentifizierungsanfragen von extern entgegen nimmt, mussals RADIUS-Client eingetragen werden.

RADIUS-Clients der HSU:

• Wireless Switches D-Link DWS4062

• RadSecProxy

Die RADIUS-Clients werden im NPS unter „RADIUS Clients“ angegeben. Hier müssen alleRADIUS-Clients mit folgenden Angaben eingetragen werden:

Friendly Name: kann beliebig gewählt werden, dient zur Beschreibung des Clients

Adress (IP or DNS): IP-Adresse oder DNS-Name des RADIUS-Clients

Vendor name: RADIUS Standard

Shared Secret: muss im NPS und im Client gleich sein. Für jeden Client sollte eineigenes Shared Secret verwendet werden.

Alle weiteren Einstellungen verbleiben auf Standard.

Remote RADIUS Server Groups

Externe Authentifizierungsanfragen, die nicht vom RADIUS-Server selber authentifiziert werdenkönnen, müssen an den RadSecProxy weitergeleitet werden. Dazu muss der RadSecProxy alsRemote RADIUS-Server im NPS eingetragen werden.

Remote RADIUS-Server der HSU:

• RadSecProxy

Remote RADIUS-Server werden im NPS unter „Remote RADIUS Server Groups“ ange-geben. Hier können mehrere Remote RADIUS-Server auch zu einer Gruppe zusammengefasstwerden. Folgende Angaben müssen hier eingetragen werden:


6. Umsetzung 82

Group name: kann beliebig gewählt werden, dient zur Beschreibung der Server-Gruppe

Server: IP-Adresse oder DNS-Name des Remote RADIUS-Server (RadSecProxy)

Authentication port: 1812

Shared Secret: muss im NPS und im Remote RADIUS-Server (RadSecProxy) einge-tragen werden

Alle weiteren Einstellungen verbleiben auf Standard.

Policies

Um dem NPS mitzuteilen, ob Authentifizierungsanfragen auf dem Server authentifiziertwerden oder weitergeleitet werden, bzw. mit welchem Verfahren die interne Authentifizierungdurchgeführt wird, müssen im NPS Policies angelegt werden.

Dafür gibt es zwei Gruppen von Policies („Connection Request Policies“ und „Network Policies“).Die Gruppe „Health Policies“ wird hier nicht benötigt.

Connection Request PoliciesDie „Connection Request Policies“ geben an, in welchem Fall eine Authentifizierung vom Serverselbst durchgeführt wird, oder an einen anderen RADIUS-Server weitergeleitet wird.

Hier müssen mindestens zwei Policies angelegt werden. Die erste Policy gibt an, dass alleAuthentifizierungsanfragen von Angehörigen der HSU (Realm „@hs-ulm.de“) vom Server lokalauthentifiziert werden. Anfragen von Gästen (mit anderen Realms) werden stattdessen füreine externe Authentifizierung an den RadSecProxy weitergeleitet.Es kann auch noch eine dritte Policy erstellt werden, welche für alle anderen Anfragen (Anfragenohne Realm) in Kraft tritt (Fallback-Policy). Somit können Angehörige der HSU, die ihrenBenutzernamen ohne Realm eingegeben haben, auch ohne authentifiziert werden. Der Zugriffauf eduroam an anderen Institutionen funktioniert allerdings nur mit angegebenem Realm.Nur dann können Authentifizierungsanfragen der richtigen Institution zugeordnet werden. Umeduroam auch an anderen Institutionen nutzen zu können, muss der Benutzername immermit Realm („[email protected]“) angeben werden. Für die Vermeidung von Fehleingaben darfPolicy 3 nicht erstellt werden. Somit werden dann alle Authentifizierungsanfragen ohne Realmgenerell abgelehnt und der Benutzer ist „gezwungen“ einen Realm anzugeben, um erfolgreichauthentifiziert zu werden.


6. Umsetzung 83

Folgende zwei Policies müssen unter „Connection Request Policy“ angelegt wer-den:(Die Policies werden in absteigender Reihenfolge abgearbeitet).

1. Benutzer, welche lokal authentifiziert werden (Angehörige der HSU mit Realm „@hs-ulm.de“)

2. Benutzer, welche extern von einem anderen RADIUS-Server authentifiziert werden(Gäste mit anderen Realms)

Für eine Policy müssen folgende Einstellungen gemacht werden:

• Policy name: kann beliebig gewählt werden, sollte die Policy aber beschreiben

• Conditions: gibt an, unter welcher Bedingung die Policy in Kraft tritt. Hier wird „Username“ gewählt und der Realm als regulärer Ausdruck angegeben.

– .*@hs-ulm\.de – lokale Authentifizierung für Angehörige der HSU (Policy 1)

– .*@.* – alle anderen Realms, deren Anfragen an den RadSecProxy weitergeleitetwerden (Policy 2)

• „Authenticate request on this server“ muss gewählt werden, um die Authentifizie-rung lokal durchzuführen (Policy 1)

• „Forward requests to the following remote RADIUS server group for authen-tication“ muss gewählt werden, um die Authentifizierungsanfrage an den RadSecProxyweiterzuleiten (Policy 2)

• Alle weiteren Einstellungen verbleiben auf Standard.

Network PoliciesDie „Network Policies“ werden für die lokale Authentifizierung benötigt und geben an, welchesAuthentifizierungsverfahren verwendet wird.

Hier muss mindestens eine Policy angelegt werden. Diese Policy gibt an, welches Authen-tifizierungsverfahren für eine lokale Authentifizierung verwendet wird. Jeder Policy könnenbestimmte Bedingungen zugewiesen werden. Wenn eine bestimmte Bedingung erfüllt ist, trittdie jeweilige Policy in Kraft. Als Bedingung kann z. B. „User Groups“ gewählt werden. Hierkönnen dann Benutzergruppen aus dem Active Directory angegeben werden, für die die Policyin Kraft tritt. Es ist somit möglich den Benutzergruppen unterschiedliche Authentifizierungs-verfahren zu ermöglichen bzw. die Authentifizierung auch zu verbieten. Weiterhin ist es möglichmit Hilfe der Policies dynamisches VLAN-Tagging zu nutzen und jeder Benutzergruppe ein


6. Umsetzung 84

eigenes VLAN zu zuteilen.Im WLAN der HSU soll im Moment keine Separierung zwischen den Angehörigen vorgenommenwerden. Daher reicht es aus, nur eine Policy zu erstellen, welche für alle Benutzer der HSU gilt(Gruppe: „Domain Users“ ).

Folgende Policy muss unter „Network Policies“ angelegt werden:

• alle Angehörigen der HSU lokal mittels EAP-PEAP authentifizieren und dem VLAN fürAngehörige zuweisen (VLAN<40>)

Für eine Policy müssen folgenden Einstellungen gemacht werden:

• Policy name: kann beliebig gewählt werden, sollte die Policy aber beschreiben

• Conditions: gibt an, bei welcher Bedingung die Policy in Kraft tritt. Hier wird„User Groups“ gewählt und als Gruppe „Domain Users“ angegeben.

• „Access granted“ muss ausgewählt werden, um allen Nutzern der angegebenen Gruppeden Zugriff auf das WLAN zu ermöglichen

• Als Authentifizierungsmethode wird unter „EAP Types“ „Microsoft: ProtectedEAP (PEAP)“ gewählt. Alle anderen Authentifizierungsmethoden („Less secureauthentication methods“) müssen deaktiviert werden. In den Optionen von PEAP(erreichbar über „Edit...“) muss das auf dem Server hinterlegte Zertifikat ausgewähltwerden. Als interne Authentifizierungsmethode muss „Secured password (EAP-MSCHAP v2)“ ausgewählt werden.Weitere Details können Abbildung 6.1 auf der nächsten Seite entnommen werden.



6. Umsetzung 85

Abbildung 6.1.: Authentifizierungsmethode wählen

Dynamisches VLAN-Tagging

Für das dynamische VLAN-Tagging muss dem RADIUS-Server in einer Policy mitgeteiltwerden, welche RADIUS-Attribute gesetzt werden sollen. Die RADIUS-Attribute werden dannvom RADIUS-Server einem Access-Accept-Paket, welches zum Access Point geschickt wird,angehängt.

Folgende Attribute müssen einem Access-Accept-Paket angehängt werden: [RFC2868]

• Attribut 64 Tunnel-Type (gibt Tunnel-Protokoll an)

• Attribut 65 Tunnel-Medium-Type (gibt Übertragungsmedium an)

• Attribut 81 Tunnel-Private-Group-ID (enthält VLAN-ID)

Im WLAN der Hochschule Ulm soll Angehörigen der HSU ein eigenes VLAN (VLAN<40>)zugewiesen werden. Dazu muss die in den „Network Policies“ erstellte Policy erweitertwerden, damit dem Access-Accept-Paket bei der Authentifizierung von Angehörigen dieentsprechenden RADIUS-Attribute für die VLAN Zuweisung angehängt werden.In den Einstellungen der Policy auf dem Tab „Settings“ müssen unter „RADIUS AttributesStandard“ die angegebenen Attribute hinzugefügt werden.


6. Umsetzung 86

VLAN-Tagging RADIUS-Attribute:

• Tunnel-Medium-TypeWert: 802 (Includes all 802 media plus Ethernet canonical format)

• Tunnel-Pvt-Group-IDAls Wert wird die VLAN-ID für Angehörige der HSU angegeben. (VLAN<40>)

• Tunnel-TypeWert: Virtual LANs (VLAN)

Falls unter „Network Policies“ noch weitere Policies für andere Benutzergruppen existieren,müssen auch in diesen die Attribute hinzugefügt werden, um die Benutzer dem richtigen VLANzu zuweisen. Weitere Details können Abbildung 6.2 entnommen werden.

Abbildung 6.2.: RADIUS-Attribute für VLAN-Tagging


6. Umsetzung 87

Identitätsschutz

Für die Unterstützung des Identitätsschutzes müssen in allen „Connection Request Poli-cies“ , welche für eine lokale Authentifizierung bestimmt sind, Anpassungen vorgenommenwerden. In den Einstellungen der Policy auf dem Tab „Settings“ müssen unter „Authenti-cation Methods“ folgende Einstellungen gemacht werden:

• „Override network policy authentication settings“ aktivieren

• Als Authentifizierungsmethode wird unter „EAP Types“ „Microsoft: ProtectedEAP (PEAP)“ gewählt. Alle anderen Authentifizierungsmethoden („Less secureauthentication methods“) müssen deaktiviert werden. In den Optionen von PEAP(erreichbar über „Edit...“) muss das auf dem Server hinterlegte Zertifikat ausgewähltwerden. Als interne Authentifizierungsmethode muss „Secured password (EAP-MSCHAP v2)“ ausgewählt werden.Weitere Details können Abbildung 6.3 entnommen werden.


Abbildung 6.3.: Authentifizierungsmethode wählen für Identitätsschutz


6. Umsetzung 88

6.6. RadSecProxy

Die Kommunikation mit dem RADIUS-Proxy des DFN findet über das RadSec-Protokollstatt. Hierzu wird ein RADIUS-Proxy benötigt, welcher das RadSec-Protokoll unterstützt.UNINETT bietet dafür den kostenlosen „radsecproxy“ an, welcher RADIUS-Pakete entgegennimmt und über RadSec weiterleitet. Der radsecproxy läuft auf diversen Linux-, BSD-, Solaris-und Mac OS X-Systemen.

6.6.1. Installation

Der radsecproxy kann unter: http://software.uninett.no/radsecproxy in der aktuellen Version(1.4.2) bezogen werden. Vor der Installation muss der radsecproxy erst aus dem Quellcode,auf dem zu installierenden System, gebaut werden. Hierzu wird eine Entwicklungsumgebungmit C-Library und C-Compiler (z. B. libc und GCC) benötigt. GCC und libc sind auf denmeisten UNIX basierten Systemen standardmäßig installiert. Weiterhin muss OpenSSL mitzugehörigen Header-Files installiert sein. Unter Ubuntu 10.10, welches hier als Testplattformverwendet wird, muss dazu die „libssl-dev“ über den Paketmanager installiert werden. Umden Source-Code zu kompilieren und zu installieren, muss der radsecproxy zunächst entpacktwerden. Anschließend in das entpackte Verzeichnis wechseln und folgende Befehle im Terminaleingeben:

./configuremakemake install

Wenn es zu keiner Fehlermeldung kommt, ist der radsecproxy jetzt installiert. Bevor er gestartetwerden kann, muss zuerst eine Konfigurationsdatei erstellt werden.

6.6.2. Konfiguration

Für den radsecproxy muss eine Konfigurationsdatei erstellt werden (/etc/radsecproxy.conf).Eine Konfigurationsvorlage befindet sich im Anhang A. Die Konfigurationsdatei enthält alleEinstellungen und Informationen, welche zur Ausführung benötigt werden. Sie besteht ausmehreren Blöcken.

Basic Block: Enthält Angaben, auf welchen Interfaces und Ports nach RADIUS- und RadSec-Anfragen „gelauscht“ werden soll. Weiterhin wird der Log-Level (1-5) und der Pfad der Logdateifestgelegt. Der Log-Level gibt an, welche Ereignisse alle in die Logdatei geschrieben werden.Dabei werden bei 1 nur schwerwiegende Fehler protokolliert und bei 5 alles.



6. Umsetzung 89

TLS Block: In diesem Block wird der Pfad zu dem auf dem Server hinterlegtem X.509 Zertifikatmit zugehörigem persönlichen Schlüssel angegeben. Beide werden für die TLS-Verschlüsselungbenötigt. Das Zertifikat muss zuvor über die PKI des DFN erstellt werden und an dem in derKonfigurationsdatei angegebenen Pfad hinterlegt werden. Weiterhin wird auch noch der Pfadder zugehörigen Zertifikatskette angeben, welche von der PKI des DFN als *.txt Datei zurVerfügung gestellt wird. Die PKI das DFN ist für die HSU unter: https://pki.pca.dfn.de/hs-ulm-ca/pub/ erreichbar.

Rewrite Block: Dieser Block ist optional. Er kann verwendet werden, um RADIUS-Attributehinzuzufügen, zu entfernen oder zu modifizieren. Wenn dynamisches VLAN-Tagging verwendetwird, muss sicher gestellt werden, dass keine Access-Accept-Pakete mit gesetzten RADIUS-Attributen für das VLAN-Tagging zum DFN weitergeleitet werden. Diese werden nur für dieinterne VLAN-Zuweisung benötigt. Im Rewrite Block kann angegeben werden, dass in allenPaketen, die auf dem radsecproxy eintreffen, die RADIUS-Attribute für das VLAN-Taggingentfernt werden.

Client Block: Hier werden alle Clients angegeben, die RADIUS-Anfragen an den radsecproxyschicken, welcher diese dann weiterleitet. Folgende Clients müssen hier angegeben werden:

• der interne RADIUS-Server der HSU

• die beiden DFN Top-Level RADIUS-Server

Server Block: Hier werden alle Server angegeben, an welche der radsecproxy RADIUS-Anfragen weiterleitet. Folgende Server müssen hier angegeben werden:

• der interne RADIUS-Server der HSU

• die beiden DFN Top-Level RADIUS-Server

Realm Block: In diesem Block wird festgelegt, an welchen Server der radsecproxy Anfragenweiterleiten soll. Dies wird anhand des Realm entschieden. Alle Anfragen, die zur HSU gehören(Realm: @hs-ulm.de), werden an den internen RADIUS-Server der HSU geleitet. Der Realmist in Form eines regulären Ausdrucks angegeben. Alle anderen Anfragen von unbekanntenRealms werden an die DFN Top-Level RADIUS-Server weitergeleitet.

Die erstelle Konfigurationsdatei kann bei der Ausführung des radsecproxy auf syntaktischeKorrektheit geprüft werden. Der radsecproxy muss dazu mit den Parametern –p (Konfigurati-onsdatei überprüfen) und –f (im Vordergrund ausführen) gestartet werden.

./radsecproxy -p -f

Falls keine Fehler ausgegeben werden, kann der radsecproxy anschließend ohne Parametergestartet werden und seine Arbeit aufnehmen.


https://pki.pca.dfn.de/hs-ulm-ca/pub/


6. Umsetzung 90

Weitere Informationen können der Dokumentation vom radsecproxy entnommen werden[radsecDoc].

6.6.3. Zusammenfassung

RadSecProxy

• Anforderungen

– UNIX basiertes System (Linux, BSD, Solaris, Mac OS X)

– Entwicklungsumgebung (libc und GCC)

– OpensSSL mit zugehörigen Header-Files

• Installation

1. herunterladen unter: http://software.uninett.no/radsecproxy

2. radsecproxy entpacken

3. folgenden Befehle im Terminal eingeben:

./configuremakemake install

• Konfiguration

– Konfigurationsdatei „/etc/radsecproxy.conf“ nach Vorlage (Anhang A ) anlegen

Weitere Informationen können der Dokumentation entnommen werden.(http://software.uninett.no/radsecproxy/doc1.4.html)

6.7. Client-Konfiguration

Bevor eine Verbindung mit dem WLAN „eduroam“ aufgebaut werden kann, muss ein WLAN-Client einmalig konfiguriert werden. Um Probleme zu vermeiden, sollte die Konfiguration ander Heimateinrichtung vorgenommen werden. Nach der Konfiguration erfolgt die Verbindungautomatisch, sobald sich das WLAN „eduroam“ in Reichweite befindet. Eine Verbindung zumWLAN „eduroam“ kann dann an allen Einrichtungen, die an eduroam teilnehmen, aufgebautwerden, ohne eine weitere Konfiguration durchführen zu müssen.



http://software.uninett.no/radsecproxy/doc1.4.html.http://software.uninett.no/radsecproxy/doc1.4.html

6. Umsetzung 91

Für die Konfiguration muss unterschieden werden, ob sich ein Gast oder ein Angehörigerder HSU mit dem WLAN der HSU verbinden möchte. Bei Gästen muss die Konfigurationimmer nach den Vorgaben der Institution erfolgen, von welcher der Gast stammt, da dieAuthentifizierung auch von dieser vorgenommen wird.

Die folgende Beschreibung bezieht sich auf die Konfiguration von WLAN-Clients von Angehö-rigen der HSU.

6.7.1. Anforderungen

Um die 802.1X Authentifizierung erfolgreich durchführen zu können und Zugriff auf das WLAN„eduroam“ an der HSU zu erhalten, muss ein WLAN-Client Folgendes unterstützen:

• IEEE 802.11b/g/n

• WPA2-Enterprise mit AES-CCMP-Verschlüsselung

• Authentifizierungsmethode EAP-PEAP/EAP-MS-CHAPv2

Zusätzlich muss das Wurzelzertifikat „Deutsche Telekom Root CA 2“ installiert sein. Eswird zur Überprüfung des Zertifikats des RADIUS-Servers benötigt. Auf vielen Systemen(z. B. Windows und Mac OS X) ist das Telekom-Zertifikat bereits installiert. Falls das Zer-tifikat noch nicht installiert ist, muss es vor der Einrichtung der WLAN-Verbindung instal-liert werden. Das Telekom-Zertifikat kann von der PKI des DFN heruntergeladen werden(https://pki.pca.dfn.de/hs-ulm-ca/pub/cacert/rootcert.crt). Alle weiteren Zertifikate (für dieZertifikatskette) werden vom RADIUS-Server geliefert.

Folgende Geräte können sich mit dem WLAN „eduroam“ an der HSU verbinden:

• Computer mit aktueller WLAN-Hardware und folgenden Betriebssystemen:

– Windows XP SP3

– Windows Vista

– Windows 7

– Mac OS X ab Version 10.4 (Tiger)

– aktuelle Linux Distributionen

• Tabletts und Smartphones:

– iPad mit iOS

– iPhone mit iOS


https://pki.pca.dfn.de/hs-ulm-ca/pub/cacert/rootcert.crt

6. Umsetzung 92

– Geräte mit Android

– Nokia Smartphones mit Symbian

– Geräte mit Windows Mobile 6 oder Windows Phone 7

– BlackBerry

6.7.2. Einstellungen

Da es eine Vielzahl unterschiedlicher Geräte gibt, kann keine einheitliche Konfigurationsanlei-tung angegeben werden. Im Folgenden werden die allgemeinen Einstellungen aufgelistet, dieauf den einzelnen Geräten eingestellt werden müssen. Je nach Gerät und Betriebssystem weichtdie Konfiguration ab und die Einstellungen werden teilweise unter anderen Bezeichnungenaufgeführt.

Folgende Einstellungen müssen auf einem WLAN-Client gemacht werden:

IP-Adresse: automatisch beziehen (DHCP)

SSID: eduroam

Sicherheitstyp: WPA2-Enterprise

Verschlüsselung: AES-CCMP

EAP-Methode: EAP-PEAP

Authentifizierungstyp: EAP-MSCHAPv2

Serverzertifikat: Deutsche Telekom Root CA 2

Anonyme Identität: [email protected]

Identität: [email protected]

Passwort: HSU-Account Passwort

6.7.3. Beispiel-Konfiguration

Nachfolgend wird eine Beispielkonfiguration unter Windows 7 und unter Mac OS X 10.6 (SnowLeopard) beschrieben. Hierbei gibt es zwei Möglichkeiten, die automatische und die manuelleKonfiguration.


6. Umsetzung 93

Automatische Konfiguration

Bei Windows 7 und Mac OS X 10.6 reicht es aus, das WLAN „eduroam“ auszuwählen und imanschließend aufgehenden Fenster seinen Benutzernamen ([email protected]) und sein Passworteinzugeben. Danach muss noch das Serverzertifikat bestätigt werden. Der Client wählt dannautomatisch die richtige Authentifizierungsmethode und führt die Authentifizierung durch.Die automatische Konfiguration hat aber den Nachteil, dass die richtige Authentifizierungs-methode nicht immer korrekt erkannt wird und es dann zu Problemen kommt. Auch derIdentitätsschutz wird nicht automatisch aktiviert. Daher ist die manuelle Konfiguration derautomatischen Konfiguration vorzuziehen, um eine stabile Konfiguration mit korrekten Ein-stellungen und aktiviertem Identitätsschutz zu erhalten.

Manuelle Konfiguration

Die manuelle Konfiguration muss einmalig von Hand pro Gerät vorgenommen werden.

Windows 7

1. „Netzwerk- und Freigabecenter“ öffnen

2. „Drahtlosnetzwerke verwalten“ wählen

3. „Hinzufügen“ anklicken und „Ein Netzwerkprofil manuell erstellen“ wählen

4. Folgende Einstellungen eingeben:

Netzwerkname: eduroam

Sicherheitstyp: WPA2-Enterprise

Verschlüsselungstyp: AES

5. Bei „Diese Verbindung automatisch starten“ Haken setzen

6. Nach einem Klick auf „Weiter“ „Verbindungseinstellungen ändern“ auswählen

7. Unter dem Tab „Sicherheit“ „Microsoft: Geschütztes EAP (PEAP)“ als Authen-tifizierungsmethode wählen

8. Auf „Einstellungen“ klicken

9. Haken bei „Serverzertifikat überprüfen“ setzen

10. Bei „Vertrauenswürdige Stammzertifizierungsstellen“ „Deutsche Telekom RootCA 2“ auswählen

11. Als „Authentifizierungsmethode“ „Gesichertes Kennwort (EAP-MSCHAPv2)“ wählen


6. Umsetzung 94

12. Haken bei „Schnelle Wiederherstellung der Verbindung aktivieren“ setzen

13. Haken bei „Identitätsdatenschutz aktivieren“ setzen und „anonymous“ eingeben

14. Auf „Konfigurieren“ klicken

15. Haken bei „Automatisch eigenen Windows Anmeldenamen und Kennwortverwenden“ entfernen

16. Die zwei Fenster durch klicken auf „OK“ schließen

17. Unter dem Tab „Sicherheit“ auf „Erweiterte Einstellungen“ klicken

18. Haken bei „Authentifizierungsmodus angeben“ setzen und „Benutzerauthentifi-zierung“ auswählen

19. Alle Fenster durch klicken auf „OK“ schließen

20. Computer baut jetzt eine Verbindung zum WLAN „eduroam“ auf und fragt nach denAnmeldeinformationen:

Benutzername: [email protected]


Abbildung 6.4.: Windows 7 Einstellungen


6. Umsetzung 95

Um den Prozess zu automatisieren, gibt es Programme, mit denen ein eingerichtetes WLAN-Profil exportiert werden kann und sich dann auf weiteren Clients einspielen lässt. Für WindowsXP, Windows Vista, und Windows 7 kann dazu der „c’t WLAN-Kloner“ oder das „SU1X802.1X Configuration Deployment Tool“ verwendet werden.

Mac OS X 10.6

1. AirPort (WLAN) aktivieren

2. In den „Systemeinstellungen“ „Netzwerk“ auswählen

3. „AirPort“ auswählen

4. „Weitere Optionen“ anklicken und auf „802.1X“ klicken

5. Durch klicken auf das „+“ ein neues Benutzerprofil mit folgenden Einstellungen anlegen:

Titel: eduroam

Benutzername: [email protected]


Identifizierung: PEAP

Drahtloses Netzwerk: eduroam

Sicherheitstyp: Firmenweiter WPA2

6. „PEAP“ markieren und auf „Konfigurieren“ klicken

7. Als „Externe Identität“ „[email protected]“ eingeben

8. Beide Fenster mit „OK“ schließen und auf „Anwenden“ klicken

9. Über das WLAN-Icon oben in der Leiste mit „eduroam“ verbinden

10. Im aufgehenden Fenster, das soeben erstellte 802.1X-Profil „eduroam“ auswählen; alleweiteren Angaben werden dann automatisch ausgefüllt.

11. Haken bei „Dieses Netzwerk merken“ setzen

12. Durch klicken auf „OK“ wird eine Verbindung zum WLAN aufgebaut

13. Aufgehende Zertifikatsmeldung bestätigen

14. Der aktuelle Status der Verbindung kann unter „Systemeinstellungen“ -> „Netz-werk“ -> „AirPort“ eingesehen werden.


6. Umsetzung 96

Abbildung 6.5.: Mac OS X 10.6 Einstellungen

6.8. Fehleranalyse

Nach erfolgreicher Authentifizierung wird jedem Client eine IP-Adresse vom DHCP-Serverzugewiesen. Der IP-Adressbereich hängt davon ab, welchem VLAN ein Client zugeteilt ist.Danach hat ein Client Zugriff auf das Internet und ggf. auf das Intranet. Falls einem Clientkeine IP-Adresse zugewiesen wird, muss überprüft werden, ob der Client richtig konfiguriertist und seine IP-Einstellungen per DHCP bezieht.

Eine nicht erfolgreiche Authentifizierung kann sich unterschiedlich äußern. Im einfachsten Fallerscheint eine Meldung mit entsprechender Information, dass die Authentifizierung fehlgeschla-gen ist. Es ist auch möglich, dass das Fenster zum Eingeben der Benutzerinformationen immerwieder eingeblendet wird, obwohl die richtigen Daten eingegeben wurden. Darüber hinauskann der Eindruck entstehen, als wäre die Authentifizierung erfolgreich verlaufen. Allerdingsbekommt der Client dann keine IP-Adresse zugewiesen, obwohl die IP-Einstellungen korrektsind.


6. Umsetzung 97

Falls es zu Problemen mit der Authentifizierung kommt, können folgende Logdateien auf Fehlerüberprüft werden:

• Logdatei RADIUS-Server (Windows Server 2008 NPS)Event Viewer -> Custom Views -> Server Roles -> Network Policy and Access Services

• Logdatei RadSecProxyWie in der Konfigurationsdatei angegeben (standardmäßig unter: /var/log/radsecproxy.log)

• Logdatei des Wireless Switch und der Access Points

Um den aufgetretenen Fehler weiter einzugrenzen, kann nach folgenden Schritten auf demClient vorgegangen werden:

• Benutzername und Passwort nochmals eingeben

• IP-Adresse per „DHCP beziehen“ muss aktiv sein

• Prüfen, ob WLAN-Hardware und Betriebssystem WPA2-Enterprise mit AES-CCMP-Verschlüsselung unterstützt

• Alle Einstellungen in der WLAN-Konfiguration nochmals überprüfen

• WLAN-Konfiguration manuell von Hand neu anlegen (bei einem Gast nach Vorgabendessen Heimateinrichtung)

• Zertifikatsprüfung testweise deaktivieren

• Prüfen, ob Wurzelzertifikat „Deutsche Telekom Root CA 2“ installiert ist und ggf.installieren

• Komplette Zertifikatskette von Hand installieren (diese kann von der PKI des DFNbezogen werden (https://pki.pca.dfn.de/hs-ulm-ca/pub/))

• Identitätsschutz testweise deaktivieren

Bei einem Gast einer anderen Institution muss der WLAN-Client nach den Vorgaben dieserEinrichtung konfiguriert werden, da die Authentifizierung über deren RADIUS-Server stattfin-det. Allerdings ist darauf zu achten, dass das WLAN-Gerät auch mit WPA2-Enterprise undAES-CCMP-Verschlüsselung zurecht kommt.



7. Bewertung 98

7. Bewertung

Die Umstellung der WLAN-Infrastruktur auf die 802.1X Authentifizierung und die Anbindungan das DFNRoaming/eduroam erfüllt im Wesentlichen alle unter Kapitel 3 auf Seite 32aufgeführten Anforderungen.

7.1. Funktionale Anforderungen

Alle funktionalen Anforderungen FA1 bis FA5 werden komplett erfüllt. Angehörige der HSUerhalten Zugang zum Internet und Intranet über das WLAN. Mit der Anbindung an dasDFNRoaming/eduroam bekommen auch Gäste Zugriff auf das Internet über das WLAN derHSU. Durch ein eigenes VLAN mit eingeschränkten Rechten, ist sichergestellt, dass ein Gastkeinen Zugriff auf das Intranet der HSU erhält. Weiterhin ist es für Angehörige der HSU auchmöglich, an anderen Institution, die am DFNRoaming/eduroam teilnehmen, Zugang zumeduroam-WLAN und somit zum Internet zu erhalten.Durch den Erfüllungsgrad von 100% aller funktionalen Anforderungen, ergibt sich für dieBewertung die maximale Punktzahl von 44 Punkten.

Anforderung Priorität Erfüllungsgrad BewertungFA1 hoch (10) 100% 10FA2 hoch (10) 100% 10FA3 mittel (7) 100% 7FA4 hoch (10) 100% 10FA5 mittel (7) 100% 7

Summe 44

Tabelle 7.1.: Pugh-Matrix Funktionale Anforderungen

7.2. Nichtfunktionale Anforderungen

NF1 KompatibilitätDiese Anforderung ist grundlegend erfüllt, da die meisten aktuellen WLAN-Geräte


7. Bewertung 99

die 802.1X Authentifizierung mit der Authentifizierungsmethode EAP-PEAP/EAP-MS-CHAPv2 unterstützen. Der Erfüllungsgrad beträgt aber nur 85%, da die Gerätezusätzlich WPA2-Enterprise mit AES-CCMP-Verschlüsselung unterstützen müssen, umsich mit dem eduroam-WLAN an der Hochschule Ulm verbinden zu können. Andernfallsist keine Verbindung möglich.Durch Aktivieren von WPA-Enterprise mit TKIP-Verschlüsselung auf den AccessPoints kann die Kompatibilität auf 95% erhöht werden. Allerdings müssen dann geringeAbstriche bei der Sicherheit gemacht werden, da TKIP auf dem unsicheren RC4-Verschlüsselungsverfahren basiert. Ein Erfüllungsgrad von 100% ist nicht erreichbar, daauch WLAN-Geräte existieren, die die 802.1X Authentifizierung nur mit WEP bzw.gar nicht unterstützen. Solche Geräte müssen sich dann mit dem offenen WLAN „ZKI“verbinden und einen VPN-Tunnel aufbauen, um Zugriff auf das Internet zu erhalten.

NF2 BedienungWenn die Umsetzung wie beschrieben nach Variante A (nur eine SSID „eduroam“) erfolgt,ist die Bedienung für den Anwender sehr einfach. Die einzige Hürde stellt die einmaligvorzunehmende Konfiguration dar. Diese muss je nach Gerät vom Anwender selbstvorgenommen werden. Hierfür wird auf den meisten Geräten aber keine Zusatzsoftwarebenötigt, da die 802.1X Authentifizierung mittels EAP-PEAP/EAP-MS-CHAPv2 imNormalfall standardmäßig unterstützt wird. Nach eimaliger Konfiguration verbindetsich ein WLAN-Client immer automatisch mit dem WLAN „eduroam“, sobald es inReichweite ist, ohne dass der Nutzer weitere Konfigurationsschritte vornehmen muss.Da die einmalige Konfiguration auf jedem Gerät mit unterschiedlichem Aufwand ver-bunden ist, erreicht NF2 nur einen Erfüllungsgrad von 90%.

NF3 SicherheitDiese Anforderung ist komplett erfüllt und erreicht einen Erfüllungsgrad von 100%.Die per Funk übertragenen Daten werden durch WPA2-Enterprise mittels AES-CCMPverschlüsselt. Auch können durch die 802.1X Authentifizierung nur berechtigte Personenauf das WLAN zugreifen. Das entspricht den gängigen Sicherheitsstandards voll undganz.Durch das Aktivieren der Funktion Client Isolation auf den Access Points kann dieSicherheit unter den WLAN-Clients noch weiter erhöht werden ( 4.3.4 auf Seite 50).

NF4 DatenschutzDurch den Einsatz des RadSec-Protokolls auf WAN-Strecken und der Aktivierung desIdentitätsschutzes wird auch der Datenschutz erfüllt. Die Identität des Nutzers kannso nicht mehr von anderen mitgelesen werden. Nur bei dem RADIUS-Server, welchereinen Nutzer authentifiziert, steht die Identität in der Logdatei. Diese Einträge dürfendabei nur zur Fehleranalyse, und um den Nutzer bei verbotenen Aktivitäten ausfindig


7. Bewertung 100

zu machen, verwendet werden.Der Erfüllungsgrad von NF4 beträgt aber nur 90%, da es WLAN-Clients (z. B. WindowsXP und Windows Vista) gibt, welche den Identitätsschutz nicht unterstützen. BeimEinsatz eines solchen Clients wird die Identität des Nutzers weiterhin im Klartext ineinem RADIUS-Paket übertragen und kann von allen beteiligten Instanzen mitgelesenwerden. Das Abfangen von RADIUS-Pakten ist auf WAN-Strecken aber nicht möglich, dahier das RadSec-Protokoll eingesetzt wird und RADIUS-Pakete verschlüsselt innerhalbeines TLS-Tunnels übertragen werden.

NF5 PerformanceDurch die Performancemessung unter Laborbedingungen konnte gezeigt werden, dasssich an einem Access Point bis zu 80 WLAN-Clients bei einer mittleren Auslastung von30% anmelden können und dabei noch ausreichende Datenraten erhalten. Das führt zueinem Erfüllungsgrad von 100% für NF5.Zu beachten ist allerdings, dass es sich hierbei nur um theoretische Annahmen handelt.Erst in der Praxis wird sich dann zeigen, wie viele Geräte wirklich an einem AccessPoint betrieben werden können, bis sich die Performance verschlechtert.

NF6 ZuverlässigkeitÜber die Zuverlässigkeit kann noch keine Aussage gemacht werden, da sich bis jetzt erstein paar Access Points im Testbetrieb befinden. Erst später, im praktischen Einsatzwird sich zeigen, wie zuverlässig die einzelnen Access Points sind und inwieweit andereAccess Points einen ausgefallenen Access Point ersetzen können.

Anforderung Priorität Erfüllungsgrad BewertungNF1 Kompatibilität hoch (10) 85% 8,5NF2 Bedienung hoch (10) 90% 9NF3 Sicherheit hoch (10) 100% 10NF4 Datenschutz mittel (7) 90% 6,3NF5 Performance mittel (7) 100% 7NF6 Zuverlässigkeit mittel (7) - -

Summe 40,8

Tabelle 7.2.: Pugh-Matrix Nichtfunktionale Anforderungen

Für die Bewertung der nichtfunktionalen Anforderungen ergeben sich 40,8 Punkte von 44maximal möglichen Punkten. Das entspricht einem Erfüllungsgrad von 93% in der Summeund stellt einen sehr guten Wert dar.



8. Zusammenfassung und Ausblick

Mit der Umstellung auf die 802.1X Authentifizierung und die Anbindung an das DFNRo-aming/eduroam erhält die Hochschule Ulm eine moderne WLAN-Infrastruktur mit hohemSicherheitsstandard. Den Nutzern wird ein sicherer und bedienungsfreundlicher WLAN-Zuganggeboten. Durch das DFNRoaming/eduroam sind die Nutzer nicht nur an einen WLAN-Standortgebunden, sondern können weltweit alle WLANs nutzen, die an eduroam angebunden sind.Weiterhin können Gäste von anderen Institutionen, die auch an eduroam teilnehmen, dasWLAN an der HSU nutzen, ohne erst einen Gastaccount beantragen zu müssen.Mit der neuen WLAN-Infrastruktur ist es jetzt möglich, Angehörige der HSU in Gruppen mitunterschiedlichen Rechten im WLAN einzuteilen. Durch den RADIUS-Server wird jeder Grup-pe jeweils ein eigenes VLAN zugewiesen. Anhand des VLANs können dann unterschiedlicheRechte im Intranet vergeben werden. Es wäre denkbar, für Mitarbeiter und Studenten jeweilseine eigene Gruppe mit eigenem VLAN einzuführen. Mitarbeiter können dann weitere Rechteim Intranet der HSU bekommen und auf spezielle Server und Dienste zugreifen.

Sobald die neue WLAN-Infrastruktur in den Produktivbetrieb gegangen ist, wäre es angebracht,ein Sicherheitsaudit duchrzuführen, um ggf. noch bestehende Schwachstellen zu erkennen undzu beheben.

Als nächster Schritt kann auch das vorhandene LAN mit an die 802.1X Authentifizierungangebunden werden. Dadurch sind alle Ethernet-Ports geschützt und erst nach erfolgreicherAuthentifizierung nutzbar. Im Moment wird der Zugang noch anhand der MAC-Adresse geräte-basiert verwaltet. Das ist aber nicht flexibel und bietet nur wenig Sicherheit, da MAC-Adressenleicht manipuliert werden können. Durch die Umstellung auf die 802.1X Authentifizierungkönnen die Ethernet-Ports ähnlich flexibel genutzt werden wie das WLAN. Auch hier ist eineAnbindung an das DFNRoaming/eduroam möglich.

In Zukunft ist auch eine Umstellung der LAN- und WLAN-Infrastrukturen in Wohnheimen aufdie 802.1X Authentifizierung und die Anbindung an das DFNRoaming/eduroam denkbar. Dashat den Vorteil, dass sich Studenten auch in den Wohnheimen mit ihren Hochschul-Accountsam Netzwerk authentifizieren können, ohne erst einen Zugang beantragen zu müssen.

Mit der Zeit werden immer weitere Institutionen auf die 802.1X Authentifizierung umstellen



und sich an das DFNRoaming/eduroam anbinden. Ziel von eduroam ist es, dass irgendwannalle Hochschulen und wissenschaftlichen Einrichtungen weltweit an eduroam angebunden sind.


Abbildungsverzeichnis viii

Abbildungsverzeichnis

2.1. 802.1X-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. 802.1X-Ports [Str04] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. EAP-Paket [Hof05, S. 85]; [RFC3748, S. 22] . . . . . . . . . . . . . . . . . . . 112.4. EAP-TTLS Aufbau [RFC5281, S. 12] . . . . . . . . . . . . . . . . . . . . . . . 142.5. EAP-PEAP Aufbau [PEAPDraft, S. 27] . . . . . . . . . . . . . . . . . . . . . 152.6. CHAP Authentifizierung [EleCHAP] . . . . . . . . . . . . . . . . . . . . . . . 162.7. MS-CHAPv2 Authentifizierung [EleCHAPv2; TecCHAPv2] . . . . . . . . . . 172.8. EAPOL-Frame [Rec08, S. 460] . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9. RADIUS-Paket [Hof05, S. 96] . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.10. Schichtenmodell der Protokolle bei der 802.1X Authentifizierung . . . . . . . 242.11. Ablauf der 802.1X Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 252.12. Schlüsselhierarchie der paarweisen Schlüssel [Rec08, S. 469] . . . . . . . . . . 272.13. Schlüsselhierarchie der Gruppenschlüssel [Rec08, S. 469] . . . . . . . . . . . . 282.14. Schlüsselaushandlung (Handshake) [Rec08, S. 472] . . . . . . . . . . . . . . . 28

3.1. Anwendungsfalldiagramm „Mit WLAN verbinden“ . . . . . . . . . . . . . . . 32

4.1. Architektur der WLAN-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . 424.2. RADIUS-Access-Request-Paket ohne Identitätsschutz . . . . . . . . . . . . . . 524.3. Detaillierte Architektur der WLAN-Infrastruktur . . . . . . . . . . . . . . . . 55

5.1. Laboraufbau für Performancemessung . . . . . . . . . . . . . . . . . . . . . . 625.2. Datenrate WLAN-Clients (802.11g) . . . . . . . . . . . . . . . . . . . . . . . . 715.3. Datenrate mehrerer WLAN-Clients (802.11n) . . . . . . . . . . . . . . . . . . 72

6.1. Authentifizierungsmethode wählen . . . . . . . . . . . . . . . . . . . . . . . . 856.2. RADIUS-Attribute für VLAN-Tagging . . . . . . . . . . . . . . . . . . . . . . 866.3. Authentifizierungsmethode wählen für Identitätsschutz . . . . . . . . . . . . 876.4. Windows 7 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.5. Mac OS X 10.6 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 96


Tabellenverzeichnis ix

Tabellenverzeichnis

2.1. WLAN Standards Überblick [Ele11b] . . . . . . . . . . . . . . . . . . . . . . . 42.2. WLAN-Verschlüsselungsvarianten . . . . . . . . . . . . . . . . . . . . . . . . . 72.3. EAP-Typen [RFC3748, S. 27]; [Rec08, S. 459]; [Hof05, S. 85] . . . . . . . . . . 12

3.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2. Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1. Pugh-Matrix Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 474.2. Pugh-Matrix Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . 48

5.1. Datenrate Iperf-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2. Datenrate WLAN-Client (802.11g) . . . . . . . . . . . . . . . . . . . . . . . . 685.3. Datenrate MacBook (802.11n) . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.4. Datenrate HP-Laptop (802.11n) . . . . . . . . . . . . . . . . . . . . . . . . . . 695.5. Datenrate mehrerer WLAN-Clients (802.11g) . . . . . . . . . . . . . . . . . . 705.6. Datenrate mehrerer WLAN-Clients (802.11n) . . . . . . . . . . . . . . . . . . 725.7. Datenrate Mischbetrieb mit 5 g-Geräten und 3 n-Geräten . . . . . . . . . . . 73

7.1. Pugh-Matrix Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 987.2. Pugh-Matrix Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . 100


Literaturverzeichnis x

Literaturverzeichnis

Bücher und Fachbeiträge

[Edn03] JON EDNEY und WILLIAM A. ARBAUGH: Real 802.11 Security:Wi-Fi Protected Access and 802.11i. Addison-Wesley, Juli 2003. isbn:0321136209.

[Hof05] MATTHIAS HOFHERR: WLAN-Sicherheit. 1. Auflage. Hannover:Heise Zeitschriften Verlag, 2005. isbn: 9783936931259.

[Kel09] DANIEL KELSCH: “Sicheres Authentifizieren von WLAN-Nutzernüber 802.1x und Teilnahme der Hochschule Ulm am DFN-Roaming”.Bachelorarbeit. Hochschule Ulm, 2009.

[Rec08] JÖRG RECH: Wireless LANs. 3. Auflage. Hannover: Heise ZeitschriftenVerlag, 2008. isbn: 9783936931518.

RFCs

[RFC3748] BERNARD ABOBA u. a.: Extensible Authentication Protocol (EAP).RFC 3748. Internet Engineering Task Force, Juni 2004. url: http://datatracker.ietf.org/doc/rfc3748/ (letzter Abruf: 24. 05. 2011).

[RFC3579] BERNARD ABOBA und PAT R. CALHOUN: RADIUS Support ForExtensible Authentication Protocol (EAP). RFC 3579. Internet Engi-neering Task Force, Sep. 2003. url: http://datatracker.ietf.org/doc/rfc3579/ (letzter Abruf: 24. 05. 2011).

[RFC5246] TIM DIERKS und ERIC RESCORLA: The Transport Layer Security(TLS) Protocol. RFC 5246. Internet Engineering Task Force, Aug. 2008.url: http://datatracker.ietf.org/doc/rfc5246/ (letzter Abruf:24. 05. 2011).


http://datatracker.ietf.org/doc/rfc3748/





Literaturverzeichnis xi

[RFC5281] PAUL FUNK und SIMON BLAKE-WILSON: Extensible Authenticati-on Protocol Tunneled Transport Layer Security Authenticated ProtocolVersion 0 (EAP-TTLSv0). RFC 5281. Internet Engineering Task For-ce, Aug. 2008. url: http://datatracker.ietf.org/doc/rfc5281/(letzter Abruf: 24. 05. 2011).

[RFC2865] CARL RIGNEY u. a.: Remote Authentication Dial In User Service(RADIUS). RFC 2865. Internet Engineering Task Force, Juni 2000.url: http://datatracker.ietf.org/doc/rfc2865/ (letzter Abruf:24. 05. 2011).

[RFC5216] DAN SIMON, BERNARD ABOBA und RYAN HURST: The EAP-TLSAuthentication Protocol. RFC 5216. Internet Engineering Task Force,März 2008. url: http://datatracker.ietf.org/doc/rfc5216/(letzter Abruf: 24. 05. 2011).

[RFC2868] GLEN ZORN u. a.: RADIUS Attributes for Tunnel Protocol Support.RFC 2868. Internet Engineering Task Force, Juni 2000. url: http://datatracker.ietf.org/doc/rfc2868/ (letzter Abruf: 24. 05. 2011).

[RFC2759] GLEN ZORN: Microsoft PPP CHAP Extensions, Version 2. RFC 2759.Internet Engineering Task Force, Jan. 2000. url: http://datatracker.ietf.org/doc/rfc2759/ (letzter Abruf: 24. 05. 2011).

Elektronisch verfügbare Dokumente

[DWS4026] Datenblatt D-Link DWS-4026. D-Link, 2010. url: ftp://ftp.dlink.de/dws/dws-4026/documentation/DWS-4026_db_de_Datenblatt.pdf (letzter Abruf: 24. 05. 2011).

[DWL8600] Datenblatt D-Link DWL-8600AP. D-Link, Jan. 2011. url: ftp://ftp.dlink.de/dwl/dwl-8600ap/documentation/DWL-8600AP_db_de_Datenblatt.pdf (letzter Abruf: 24. 05. 2011).

[802.11-07] IEEE Std 802.11-2007. IEEE, Juni 2007. url: http://standards.ieee.org/about/get/802/802.11.html (letzter Abruf: 24. 05. 2011).

[802.1X-10] IEEE Std 802.1X-2010. IEEE, Feb. 2010. url: http://standards.ieee.org/about/get/802/802.1.html (letzter Abruf: 24. 05. 2011).









ftp://ftp.dlink.de/dws/dws-4026/documentation/DWS-4026_db_de_Datenblatt.pdf



ftp://ftp.dlink.de/dwl/dwl-8600ap/documentation/DWL-8600AP_db_de_Datenblatt.pdf



http://standards.ieee.org/about/get/802/802.11.html




Literaturverzeichnis xii

[Ayr] GARETH AYRES: Use of eduroam as the Single Primary SSID atSwansea University. janet. url: http://www.ja.net/documents/services/janet-roaming/swansea-eduroam-single-ssid.pdf (letzterAbruf: 24. 05. 2011).

[BSI09] Drahtlose Kommunikationssysteme und ihre Sicherheitsaspekte. Bun-desamt für Sicherheit und Informationstechnik, Sep. 2009. url: https://www.bsi.bund.de/ContentBSI/Publikationen/Broschueren/drahtloskom/index_htm.html (letzter Abruf: 25. 05. 2011).

[eduCoo08] S. WINTER, T. KERSTING und P. DEKKERS: Inter-NREN RoamingInfrastructure and Service Support Cookbook. RESTENA, Oktober 2008.url: http://www.eduroam.org/downloads/docs/GN2-08-230-DJ5.1.5.3-eduroamCookbook.pdf (letzter Abruf: 24. 05. 2011).

[Kle06] ANDREAS KLEIN: Attacks on the RC4 stream cipher. Feb. 2006. url:http://cage.ugent.be/~klein/RC4/RC4-en.ps (letzter Abruf:26. 05. 2011).

[Oss10] MICHAEL OSSMANN: WEP: Dead Again, Part 2. Nov. 2010. url:http://www.symantec.com/connect/articles/wep-dead-again-part-2 (letzter Abruf: 26. 05. 2011).

[PEAPDraft] ASHWIN PALEKAR u. a.: Protected EAP Protocol (PEAP) Version 2.Internet-Draft. Internet Engineering Task Force, Oktober 2004. url:http://tools.ietf.org/id/draft-josefsson-pppext-eap-tls-eap-10.txt (letzter Abruf: 24. 05. 2011).

[RadSec05] RadSec a secure, reliable RADIUS Protocol. Open System ConsultantsPty. Ltd., Mai 2005. url: www.open.com.au/radiator/radsec-whitepaper.pdf (letzter Abruf: 24. 05. 2011).

[radsecDoc] Documentation for radsecproxy 1.4. UNINETT. url: http : / / software . uninett . no / radsecproxy / doc1 . 4 . html (letzter Abruf:24. 05. 2011).

[RadSecDraft] STEFAN WINTER u. a.: TLS encryption for RADIUS. Internet-Draft.Internet Engineering Task Force, März 2011. url: http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ (letzter Abruf:24. 05. 2011).


http://www.ja.net/documents/services/janet-roaming/swansea-eduroam-single-ssid.pdf

http://www.ja.net/documents/services/janet-roaming/swansea-eduroam-single-ssid.pdf

https://www.bsi.bund.de/ContentBSI/Publikationen/Broschueren/drahtloskom/index_htm.html



http://www.eduroam.org/downloads/docs/GN2-08-230-DJ5.1.5.3-eduroamCookbook.pdf

http://www.eduroam.org/downloads/docs/GN2-08-230-DJ5.1.5.3-eduroamCookbook.pdf

http://cage.ugent.be/~klein/RC4/RC4-en.ps

http://www.symantec.com/connect/articles/wep-dead-again-part-2

http://www.symantec.com/connect/articles/wep-dead-again-part-2

http://tools.ietf.org/id/draft-josefsson-pppext-eap-tls-eap-10.txt

http://tools.ietf.org/id/draft-josefsson-pppext-eap-tls-eap-10.txt

www.open.com.au/radiator/radsec-whitepaper.pdf

www.open.com.au/radiator/radsec-whitepaper.pdf

http://software.uninett.no/radsecproxy/doc1.4.html

http://software.uninett.no/radsecproxy/doc1.4.html

http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/

http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/

Literaturverzeichnis xiii

Webseiten

[TecCHAPv2] MS-CHAP v2. Microsoft TechNet. url: http://technet.microsoft.com/de-de/library/cc731462(WS.10).aspx (letzter Abruf:24. 05. 2011).

[TecNPS] Network Policy Server (NPS). Microsoft TechNet, Dezember 2008. url:http://technet.microsoft.com/de-de/library/dd346691(WS.10).aspx (letzter Abruf: 24. 05. 2011).

[TecFacts] NPS Fast Facts. Microsoft TechNet, Feb. 2009. url: http://technet.microsoft.com/de-de/library/cc753255(WS.10).aspx (letzterAbruf: 24. 05. 2011).

[DFN10] JOCHEM PATTLOCH: Das Wissenschaftsnetz X-WiN. DeutschesForschungsnetz, Oktober 2010. url: http://www.dfn.de/xwin/(letzter Abruf: 24. 05. 2011).

[DFN11a] JOCHEM PATTLOCH: DFNRoaming/eduroam. Deutsches Forschungs-netz, Jan. 2011. url: http://www.dfn.de/dienstleistungen/dfnroaming/ (letzter Abruf: 24. 05. 2011).

[DFN11b] JOCHEM PATTLOCH: DFN-Verein. Deutsches Forschungsnetz, März2011. url: http://www.dfn.de/verein/ (letzter Abruf: 24. 05. 2011).

[DFN11c] JOCHEM PATTLOCH: Willkommen im Deutschen Forschungsnetz.Deutsches Forschungsnetz, Mai 2011. url: http://www.dfn.de/(letzter Abruf: 24. 05. 2011).

[edu10] eduroam FAQ. eduroam, März 2010. url: http://www.eduroam.org/index.php?p=faq (letzter Abruf: 24. 05. 2011).

[edu11] What is eduroam? eduroam, Feb. 2011. url: http://www.eduroam.org/ (letzter Abruf: 24. 05. 2011).

[Ele11b] PATRICK SCHNABEL: IEEE 802.11b / WLAN mit 11 MBit. Elek-tronik Kompendium. url: http://www.elektronik-kompendium.de/sites/net/0907031.htm (letzter Abruf: 24. 05. 2011).

[Ele11n] PATRICK SCHNABEL: IEEE 802.11n / WLAN mit 100 MBit/s.Elektronik Kompendium. url: http://www.elektronik-kompendium.de/sites/net/1102071.htm (letzter Abruf: 24. 05. 2011).


http://technet.microsoft.com/de-de/library/cc731462(WS.10).aspx


http://technet.microsoft.com/de-de/library/dd346691(WS.10).aspx

http://technet.microsoft.com/de-de/library/dd346691(WS.10).aspx



http://www.dfn.de/xwin/



http://www.dfn.de/verein/

http://www.dfn.de/

http://www.eduroam.org/index.php?p=faq

http://www.eduroam.org/index.php?p=faq

http://www.eduroam.org/

http://www.eduroam.org/

http://www.elektronik-kompendium.de/sites/net/0907031.htm




Literaturverzeichnis xiv

[EleCHAP] PATRICK SCHNABEL: CHAP - Challenge Handshake AuthenticationProtocol. Elektronik Kompendium. url: http://www.elektronik-kompendium.de/sites/net/0906171.htm (letzter Abruf: 24. 05. 2011).

[EleCHAPv2] PATRICK SCHNABEL: MS-CHAP - Microsoft CHAP. ElektronikKompendium. url: http://www.elektronik-kompendium.de/sites/net/0906181.htm (letzter Abruf: 24. 05. 2011).

[Str04] LARS STRAND: 802.1X Port-Based Authentication HOWTO. LinuxDocumentation Project, Oktober 2004. url: http://tldp.org/HOWTO/8021X-HOWTO/intro.html (letzter Abruf: 24. 05. 2011).

[WikWLAN] Wireless Local Area Network. Wikipedia. url: http://de.wikipedia.org/wiki/Wlan (letzter Abruf: 24. 05. 2011).






http://tldp.org/HOWTO/8021X-HOWTO/intro.html

http://tldp.org/HOWTO/8021X-HOWTO/intro.html

http://de.wikipedia.org/wiki/Wlan

http://de.wikipedia.org/wiki/Wlan

Abkürzungsverzeichnis xv

Abkürzungsverzeichnis

AD Active Directory

AES Advanced Encryption Standard

AKM Authentication and Key Management

CCMP Counter Mode with Cipher Block Chaining Message Authentication CodeProtocol

CHAP Challenge Handshake Authentication Protocol

CSMA/CA Carrier Sense Multiple Access/Collision Avoidance

DFN Deutsches Forschungsnetz

DFS Dynamic Frequency Selection

DHCP Dynamic Host Configuration Protocol

EAP Extensible Authentication Protocol

EAPOL EAP over LAN

GMK Group Master Key

GTK Group Temporal Key

HSU Hochschule Ulm

IEEE Institute of Electrical and Electronics Engineers

ISM Industrial, Scientific, Medical

KCK Key Confirmation Key

KEK Key Encryption Key


Abkürzungsverzeichnis xvi

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

MIC Message Integrity Check

MIMO Multiple In Multiple Out

MS-CHAPv2 Microsoft Challenge Handshake Authentication Protocol version 2

Nak Not acknowledged

NAS Network Access Server

NIST National Institute of Standards and Technology

NPS Network Policy Server

PAP Password Authentication Protocol

PEAP Protected Extensible Authentication Protocol

PKI Public Key Infrastructure

PMK Pairwise Maser Key

PMSKA Pairwise Master Key Security Association

PPP Point-to-Point Protocol

PSK Pre-Shared Key

PTK Pairwise Transient Key

QoS Quality of Service

RADIUS Remote Authentication Dial-In User Service

RFC Request for Comments

RSN Robust Security Network

SSL Secure Socket Layer

TCP Transmission Control Protocol


Abkürzungsverzeichnis xvii

TK Temporal Key

TKIP Temporary Key Integrity Protocol

TLS Transport Layer Security

TPC Transmit Power Control

TTLS Tunneled Transport Layer Security

UDP User Datagram Protocol

VAP Virtual Access Point

VLAN Virtual Local Area Network

VPN Virtual Private Network

WAN Wide Area Network

WEP Wired Equivalent Privacy

WLAN Wireless Local Area Network

WPA Wi-Fi Protected Access


A. radsecproxy Konfigurationsvorlage xviii

A. radsecproxyKonfigurationsvorlage

Listing A.1: radsecproy configuration template1 ######2 # Configuration template for radsecproxy version 1.4.23 # This configuration template can be used to connect

radsecproxy to DFNRoaming/eduroam.4 # Save the configuration file in path: /etc/radsecproxy.

conf5 # File is based on examples of DFN:6 # http ://www.dfn.de/fileadmin /1 Dienstleistungen/Roaming/

Einrichtung_von_radsecproxy.pdf7 #8 # radsecproxy documentation:9 # http :// software.uninett.no/radsecproxy/index.php?page=

documentation10 #11 # Date: May 201112 # Author: Raphael Heinlein13 ######1415 ######16 # Basic Block17 #18 # Listen on ports 1812 and 1813 for RADIUS -Packets of

internal RADIUS -Server.19 # Port 1812 for RADIUS -Requests20 # Port 1813 for RADIUS -Accounting21 #


A. radsecproxy Konfigurationsvorlage xix

22 # Enter IP adress of network interface which isconnected to internal RADIUS -Server.

2324 listenUDP 127.0.0.1:181225 listenUDP 127.0.0.1:18132627 # Listen on port 2083 for RadSec -Packets.28 # Port 2083 for RadSec -Requests of DFN Top -Level RADIUS -

Proxy.29 # RadSec -Requests use TCP and are transmitted in an

encrypted TLS tunnel.30 #31 # Enter IP adress of network interface which is

connected to DFN Top -Level RADIUS -Proxy.3233 listenTLS 192.168.0.1:20833435 # Log file settings:36 # - set LogLevel (1-5)37 # - set LogDestination (path of log file)3839 LogLevel 340 LogDestination file :/// var/log/radsecproxy.log4142 # To prevent loops by forwarding RADIUS -Packets activate

this option.43 # A Packet will never be sent to a server named the same

as the client it was received from.44 #45 # LoopPrevention On46 #47 ######4849 ######50 # TLS Block51 # For all TLS encrypted connections the following

certificates will be used.


A. radsecproxy Konfigurationsvorlage xx

5253 tls default {54 # Path for the certificate chain stored on the

server.55 # You can get the certificate chain from your

PKI (DFN PKI).5657 CACertificateFile /etc/radsec/certs/dfn -pki -

chain.txt5859 # Path for the X.509 certificate stored on the

server.60 # Path for the private key of the certificate.6162 CertificateFile /etc/radsec/certs/cert.pem63 CertificateKeyFile /etc/radsec/certs/key.pem6465 # In case of an encrypted private key , enter

passwort here.66 #CertificateKeyPassword "passwort"67 }68 #69 ######7071 ######72 # Rewrite Block73 # Optional part , to rewrite RADIUS -Attributes.74 # By each received RADIUS -Packet the following

attributes will be removed.75 # That ’s important for dynamic VLAN -Tagging by the

RADIUS -Server.76 # VLAN attributes are only used for internal function.77 # VLAN attributes are not allowed to be forwarded.78 # They have to be removed.7980 rewrite default {81


A. radsecproxy Konfigurationsvorlage xxi

82 #remove attribute for Tunnel -Type83 removeAttribute 648485 # remove attribute for Tunnel -Medium -Type86 removeAttribute 658788 # remove attribute for Tunnel -Private -Group -ID89 removeAttribute 8190 }91 #92 ######9394 ######95 # Client Block96 # All clients which send requests to the radsecproxy:97 # - internal RADIUS -Server98 # - the two DFN Top -Level RADIUS -Proxys99

100 # internal RADIUS -Server101 client radius -server {102 host #enter IP of RADIUS -Server103 type udp104 secret #enter secret here105 }106107 # DFN Top -Level RADIUS -Proxys108 client radius1.dfn.de {109 host radius1.dfn.de110 type TLS111112 # CN-value of certificate won ’t be compared with

hostname (in default case it will).113 # Instead CN-value ist compared with the regular

expression.114 certificateNameCheck off115 matchCertificateAttribute CN:/^ radius1 \.dfn\.de$

/


A. radsecproxy Konfigurationsvorlage xxii

116117 }118 client radius2.dfn.de {119 host radius2.dfn.de120 type TLS121122 certificateNameCheck off123 matchCertificateAttribute CN:/^ radius2 \.dfn\.de$

/124 }125 #126 ######127128 ######129 # Server Block130 # All servers to which radsecproxy forwards requests:131 # - internal RADIUS -Server132 # - the two DFN Top -Level RADIUS -Proxys133134 # internal RADIUS -Server135 # RADIUS -Requests136 server radius -server {137 host #enter IP of RADIUS -Server138 port 1812139 type udp140 secret #enter secret here141 }142 # RADIUS -Accounting143 server radius -server -accounting {144 host #enter IP of RADIUS -Server145 port 1813146 type udp147 secret #enter secret here148 }149150 # DFN Top -Level RADIUS -Proxy


A. radsecproxy Konfigurationsvorlage xxiii

151 # With "statusServer on" the radsecproxy proofs theconnection to the DFN -RADIUS -Proxy during idle.

152153 server radius1.dfn.de {154 host radius1.dfn.de155 type tls156 statusServer on157158 certificateNameCheck off159 matchCertificateAttribute CN:/^ radius1 \.dfn\.de$

/160161 }162163 server radius2.dfn.de {164 host radius2.dfn.de165 type tls166 statusServer on167168 certificateNameCheck off169 matchCertificateAttribute CN:/^ radius2 \.dfn\.de$

/170171 }172 #173 ######174175 ######176 # Realm Block177 # Requests are forwarded to the listed server based on

the realm.178 # Requests with the realm "@institution.de" will be

forwarded to the internal RADIUS -Server.179 # All other requests with different realms will be

forwarded to DFN Top -Level RADIUS -Proxys.180 # Realms are entered by a regular expression.181


A. radsecproxy Konfigurationsvorlage xxiv

182 realm /@institution \.de$/ {183 server radius -server184 accountingServer radius -server -accounting185 }186187 realm * {188 server radius1.dfn.de189 server radius2.dfn.de190 accountingServer radius1.dfn.de191 accountingServer radius2.dfn.de192 }193194 #195 ######


Bachelor-Thesis - Studium an der Hochschule Ulm · In dieser Arbeit wird ein Konzept entwickelt,...

Documents

Transcript of Bachelor-Thesis - Studium an der Hochschule Ulm · In dieser Arbeit wird ein Konzept entwickelt,...