Bachelor-Thesis Technisches Sicherheitskonzept Für Das WLAN-Funknetz Der Hochschule Ulm

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 Hilfe
verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Insbesondere versichere ich, dass ich alle wörtlichen und sinngemäßen Zitate als solche
kenntlich gemacht und mit genauer Quellenangabe dargelegt habe.
Ulm, 31. Mai 2011

Unterschrift
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 dient
einzig dem Zugang zum VPN-Gateway der Hochschule. Über diesen ist ein sicherer Zugang
zum 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 zum
Internet über das WLAN zu ermöglichen, soll die WLAN-Infrastruktur der Hochschule Ulm an
einen Roaming-Dienst angebunden werden. Als Roaming-Dienst kommt eduroam zusammen
mit dem DFNRoaming in Frage. Dafür muss eine WLAN-Infrastruktur auf Basis der 802.1X
Authentifizierung aufgebaut werden.
In dieser Arbeit wird ein Konzept entwickelt, welches alle Schritte, die zur Umstellung der
WLAN-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 Betreuung
und das entgegengebrachte Vertrauen danken.
Dank gebührt auch Herrn Prof. Dr. Stefan Traub, Herrn Peter Nachtmann sowie Herrn Dietmar
Rahlfs 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Grundlagen 3
2.1. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. IEEE 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. WPA und WPA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. EAP-TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. EAP-TTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3. EAP-PEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.4. MS-CHAPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4. EAPOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.1. RADIUS-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2. RADIUS-Geräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6. RadSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7. Ablauf der 802.1X Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 23
2.7.1. Schlüsselmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7.2. Roaming und 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8. eduroam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.9. Das Deutsche Forschungsnetz . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9.1. DFN-Verein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9.2. Wissenschaftsnetz X-WiN . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.9.3. DFNRoaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Inhaltsverzeichnis vi
3. Anforderungsanalyse 32
3.1. Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2. Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1. Angehöriger der Hochschule Ulm meldet sich am WLAN der HSU an 33
3.2.2. Angehöriger der Hochschule Ulm meldet sich am WLAN einer anderen
Institution an . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.3. Gast meldet sich am WLAN der Hochschule Ulm an . . . . . . . . . . 35
3.2.4. Weitere Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2. Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 37
3.3.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4. Konzeption 40
4.1. Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Grobkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1. Benötigte Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.2. Ablauf der Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 41
4.3. Feinkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1. Varianten im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2. Varianten im Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.3. Verwendete Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.4. Verwendete Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.5. Ablauf der Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 54
4.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5. Performancemessung 61
5.1. Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2. Komponenten im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.1. Iperf / JPerf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.2. Iperf-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.3. Iperf-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.4. Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3. Durchführung und Auswertung der Messung . . . . . . . . . . . . . . . . . . . 66
5.3.1. Datenrate Iperf-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.2. Datenrate einzelner WLAN-Clients . . . . . . . . . . . . . . . . . . . . 67
5.3.3. Datenrate mehrerer WLAN-Clients zusammen . . . . . . . . . . . . . 70
5.3.4. Access Point Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Inhaltsverzeichnis vii
5.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6. Umsetzung 77
6.1. DFN-Anmeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2. VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3. Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.5. RADIUS-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.5.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.5.2. Zertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.5.3. Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.6. RadSecProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6.2. Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.7. Client-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.7.1. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.7.2. Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.7.3. Beispiel-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.8. Fehleranalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7. Bewertung 98
7.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.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 und
komfortablen Netzzugang. Dabei spielt die Sicherheit eine wichtige Rolle, da ein WLAN für
jeden, 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 unterschiedliche
Ansä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 dient
einzig dem Zugang zum VPN-Gateway der Hochschule. Über diesen ist ein sicherer Zugang
zum Intranet und Internet möglich.
Der VPN-Tunnel bietet zwar ein hohes Maß an Sicherheit und erfüllt die Anforderungen für
Vertraulichkeit, Integrität und Authentifizierung, jedoch ist er nicht sehr komfortabel. Es muss
jedes Mal vor der Nutzung des WLANs der VPN-Tunnel vom Benutzer aufgebaut werden. Für
die 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 Plattform
und stellt einen gewissen Aufwand bei der Konfiguration dar. Für den Benutzer bietet dies
daher 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 Authentifizierung
zusammen mit der WPA2-Verschlüsselung möglich. Neben Steigerung des Komforts und der
Kompatibilität, sollen auch Gäste einen einfach Zugriff auf das Internet über das WLAN
der Hochschule Ulm erhalten. Die 802.1X Authentifizierung stellt dabei auch den Standard
fü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 komfortablen
Zugriff 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 Hochschule
Ulm, welches dem Nutzer einen sicheren, vertraulichen und komfortablen Zugang zum WLAN
und 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 soll
darauf geachtet werden, dass auf den Geräten möglichst keine Zusatzsoftware benötigt wird
und dass sich der Konfigurationsaufwand für den Anwender in Grenzen hält.
Durch Anbindung an den Roaming-Dienst des Deutschen Forschungsnetzes, soll auch Gästen
ein 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 auf
die 802.1X Authentifizierung und die dafür notwendigen Komponenten beschreibt. In Kapitel
5 wird die Leistungsfähigkeit der benötigten Access Points durch Performancemessungen unter
Laborbedingungen bestimmt. Anhand der gewonnen Erkenntnisse in den Kapiteln „Konzep-
tion“ und „Performancemessung“ wird im Kapitel „Umsetzung“ auf die Konfiguration aller
notwendigen Komponenten eingegangen, um die neu entwickelte WLAN-Struktur aufzubauen.
Die Arbeit endet im Kapitel 7 mit einer Bewertung der neuen WLAN-Infrastruktur anhand
der 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 Technik
nahe, ihren Angehörigen und Gästen einen schnellen und komfortablen WLAN-Zugang zu
ermö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 arbeitet
mit Infrarotverbindungen bzw. mit elektromagnetischen Wellen im 2,4-GHz-Band. Dieser
Frequenzbereich liegt im so genannten ISM-Band (Industrial, Scientific, Medical), welches
weltweit lizenz- und genehmigungsfrei genutzt werden darf. Dadurch ergibt sich der Vorteil, dass
für den Betrieb eines WLANs keine Genehmigung erforderlich ist und keine Lizenzgebühren
anfallen. [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 eine
Datenrate 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öglicht
Datenraten 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äte
nach dem Standard 802.11a mit vollem Leistungsumfang in Europa genutzt werden. Der
Standard 802.11h erweitert den Standard 802.11a um zwei wesentliche Merkmale wie einer
dynamischen Kanal- bzw. Frequenzwahl (Dynamic Frequency Selection (DFS)) und einer
automatischen Leistungsreduzierung (Transmit Power Control (TPC)). [Rec08, S. 7]
Wegen der Einschränkungen im Betrieb und der späten Einführung von 802.11h ist die
Verbreitung 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 Datenrate
von bis zu 54MBit/s im 2,4-GHz-Band ermöglicht. Geräte nach 802.11g sind dabei auch mit
Geräten nach 802.11b grundsätzlich kompatibel. [Rec08, S. 7]; [Hof05, S. 9]
Ende 2009 wurde die Standarderweiterung IEEE 802.11n verabschiedet, welche eine Datenrate
von 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/g
kompatibel. [Ele11n]
Eine weitere Standarderweiterung ist IEEE 802.11i, welche die Sicherheit von WLAN deutlich
verbessert. Weitere Informationen können im Abschnitt 2.1.2 auf der nächsten Seite entnommen
werden.
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 Points
behandeln. [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) Frequenzband

IEEE 802.11 2 MBit/s 1 MBit/s 2,4 GHz
IEEE 802.11a 54 MBit/s 22 MBit/s 5 GHz
IEEE 802.11b 11 MBit/s 5 MBit/s 2,4 GHz
IEEE 802.11g 54 MBit/s 22 MBit/s 2,4 GHz
IEEE 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 jeweils
einen Abstand von 5 MHz aufweisen. Der Standard 802.11b arbeitet jedoch mit einer Bandbreite
von 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 zwei

WLAN-Geräten mindestens ein Kanalabstand von 25 MHz eingehalten werden. Dadurch
ergeben sich die drei Kanäle 1, 6 und 11, auf welchen ein störungsfreier Betrieb möglich
ist. Noch besser ist es, einen Kanalabstand von 30 MHz und somit die Kanäle 1, 7 und 13
zu verwenden. Es können daher immer nur 3 WLAN-Geräte nach dem Standard 802.11b
gleichzeitig 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. Dies
ermöglicht jetzt 4 Geräte störungsfrei auf den Kanälen 1, 5, 9 und 13 zu betreiben, allerdings
nur, 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 im
5-GHz-Band arbeiten. Das 5-GHz-Band stellt insgesamt 19 Kanäle mit einer Bandbreite von
jeweils 20 MHz zur Verfügung. Insgesamt können so 19 WLAN-Geräte gleichzeitig innerhalb
eines 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 einer
erweiterten Bandbreite von 40 MHz betrieben werden. Im 2,4-GHz-Band wird dies nicht
empfohlen, 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. Im
5-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 die
Verbreitung von Geräten nach dem Standard 802.11n zu. Daher ist eine Erweiterung des
WLANs der Hochschule Ulm auf 802.11n und das 5-GHz-Band in naher Zukunft unbedingt zu
empfehlen.
2.1.2. IEEE 802.11i
Im WLAN Grundstandard 802.11 sind bereits Sicherheitsmechanismen integriert, um den

unautorisierten Zugriff auf das WLAN und das Mitlauschen und Manipulieren von Daten zu
verhindern. Die Sicherheitsmechnismen werden unter dem Begriff WEP (Wired Equivalent
Privacy) zusammengefasst. WEP soll den Zugang zum WLAN kontrollieren und dabei die
Vertraulichkeit und Integrität der Daten sicherstellen. Wesentlicher Bestandteil von WEP
ist 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üsselung
Schwachstellen 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 erweiterte
Sicherheitsmechanismen bietet. IEEE 802.11i definiert einheitliche und herstellerübergreifende
Sicherheitsmechanismen, welchen den heutigen Sicherheitsansprüchen gerecht werden. Um
die Kompatibilität von älteren WLAN-Geräten weiter zu gewährleisten, wurden zwei neue
Sicherheitsverfahren eingeführt, die die Vertraulichkeit und Datenintegrität sicherstellen sollen.
Das erste Verfahren ist eine optionale Übergangslösung und basiert wie auch schon die
WEP-Verschlüsselung auf RC4. Durch einen häufigen Schlüsselwechsel weist es aber nicht
mehr 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önnen
TKIP durch Firmware- bzw. Treiberupdates mit der herkömmlichen Hardware nutzen. Um
die 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 symmetrischen
Verschlüsselungsverfahren Advanced Encryption Standard (AES) und arbeitet im Modus
CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol).
Das Verfahren wird daher als AES-CCMP bezeichnet. AES stellt heute ein sehr sicheres
Verschlüsselungsverfahren dar und wird vom National Institute of Standards and Technology
(NIST) empfohlen. Um AES-CCMP zu nutzen, muss dies von der WLAN Hardware auch
unterstü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 einem
automatischen, dynamischen Schlüsselmanagement eingeführt. Dies wird als Authentication and
Key Management (AKM) bezeichnet. AKM verwendet entweder Authentifizierungsverfahren,
die nach dem IEEE 802.1X-Standard spezifiziert sind und auf dem Extensible Authentication
Protocol (EAP) basieren oder einen Pre-Shared Key (PSK). Wobei der PSK für kleinere
WLAN Installationen ohne Authentifizierungsserver gedacht ist.
WLAN Installationen, die die neuen Sicherheitsmechanismen (TKIP oder AES-CCMP) nach
802.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 die
802.1X Authentifizierung unterstützten. TKIP ist nur eine optionale Übergangslösung und
reicht 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 wurde
im Jahr 2003 veröffentlicht und stellt eine Teilmenge des IEEE 802.11i-Standards dar, welcher
damals noch in der Entwicklung war. WPA stützt sich dabei auf die TKIP-Verschlüsselung
und die Integritätsprüfung MIC. WPA wurde als ein quasi vorzeitiger Standard von der Wi-Fi
Alliance 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-Standard
im Wesentlichen entspricht und für die Verschlüsselung und Integritätsprüfung AES-CCMP
nutzt. [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ür
die Authentifizierung der Clients und für den dynamischen Schlüsselaustausch. Dabei werden
Authentifizierungsverfahren, die nach dem IEEE 802.1X-Standard spezifiziert sind und auf
dem 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 ohne
Authentifizierungsserver. [Rec08, S. 451 f.]
In Tabelle 2.2 sind die unterschiedlichen Verschlüsselungsvarianten nochmals dargestellt.
Verschlüsselungsvariante WEP WPA WPA2

Personal-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 Based
Network Access Control). Ein Rechner erhält erst Zugang auf das Netzwerk, wenn er sich
erfolgreich 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.]
Supplicant
Der Supplicant (Bittsteller) stellt den Client dar, der auf das Netzwerk zugreifen möchte und
um Zugang bittet. Im Fall von WLAN handelt es sich um den entsprechenden WLAN-Client
(z. B. ein Laptop oder ein Smartphone).
Authenticator
Der Authenticator verwaltet den Zugriff auf das Netzwerk. Er fungiert dabei als Vermittler
zwischen Supplicant und Authentifizierungsserver. Authentifizierungsanfragen des Supplicants
werden vom Authenticator entgegen genommen und an den Authentifizierungsserver weiter
geleitet. Wenn ein Supplicant erfolgreich authentifiziert wird, dann gibt der Authenticator den
Zugriff auf das Netzwerk frei. Ohne erfolgreiche Authentifizierung blockt der Authenticator
den Zugriff auf das Netzwerk und akzeptiert nur Authentifizierungsanfragen. Im Falle von
Ethernet ist der Authenticator ein Switch, im Falle von WLAN ein Access Point.
Authentifizierungsserver
Der Authentifizierungsserver nimmt die Authentifizierungsanfrage des Supplicants über den
Authenticator 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 Supplicant
geschickt. Als Authentifizierungsserver wird häufig ein RADIUS-Server eingesetzt (Remote
Authentication Dial-In User Service). Im Falle von WLAN ist der Authentifizierungsserver
neben der Authentifizierung der Clients auch für die Verteilung der dynamischen Schlüssel für
die 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 Zugriff
auf das Netzwerk. Der Authenticator leitet die Anfrage an den Authentifizierungsserver weiter.
Bei einer erfolgreichen Authentifizierung des Supplicants sendet der Authentifizierungsserver
eine Bestätigung über den Authenticator an den Supplicant. Der Authenticator autorisiert jetzt
den 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 nur
Authentifizierungsanfragen vom Supplicant.
Der Authenticator stellt dazu die Zugangsports (802.1X-Ports) zum Netzwerk bereit. Bei einem
Ethernet Switch handelt es sich um die physikalischen Ports, bei einem WLAN Access Point
hingegen um virtuelle Ports. Über den Port wird festgelegt, ob ein Datentransfer zugelassen
wird oder nicht.
Jeder Port hat zwei logische Einheiten von Ports, einen kontrollierten und einen unkontrollierten
Port. Der unkontrollierte Port ist immer offen, akzeptiert aber nur Authentifizierungsanfragen.
Alle anderen Anfragen und Pakete werden verworfen. Der kontrollierte Port ist standardmäßig
blockiert (nicht autorisiert) und wird erst nach erfolgreicher Authentifizierung des Supplicants
geöffnet (autorisiert). Über den kontrollierten Port erhält der Supplicant dann Zugriff auf das
Netzwerk. [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. Die
Kommunikation zwischen Authenticator und Authentifizierungsserver findet in der Regel über
das RADIUS-Protokoll statt. Je nach Übertragungsrichtung muss der Authenticator die EAP
Pakete 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 von
Windows. Für andere Betriebssysteme wie Linux und Mac OS X steht auch entsprechende
Software 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 wurde
ursprünglich für das Point-to-Point Protocol (PPP) entwickelt. EAP ist modular aufgebaut und
gibt keine Authentifizierungsmethode vor, daher wird es auch als Authentifzierungs-Framework
bezeichnet. Je nach Sicherheitsbedarf können unterschiedliche Authentifizierungsmethoden
(z. B. EAP-TLS, EAP-TTLS, EAP-PEAP) gewählt werden. [Rec08, S. 457 ff.]; [Hof05, S. 83
ff.]
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 Peer
bezeichnet) und Authenticator bzw. Authentifizierungsserver umgesetzt wird. [Rec08, S. 457
ff.]
EAP-Request (Code 1)
Das EAP-Request-Paket wird verwendet, um Nachrichten vom Authenticator zum Supplicant
zu ü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 Authenticator
zu ü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 erfolgreich
verlaufen ist.
EAP-Failure (Code 4)
Die EAP-Failure Nachricht teilt dem Supplicant mit, dass die Authentifizierung nicht erfolgreich
war und der Supplicant abgelehnt wurde.
Ein EAP-Paket, dargestellt in Abbildung 2.3 auf der nächsten Seite, besteht aus den folgenden
Feldern:

2. Grundlagen 11
Abbildung 2.3.: EAP-Paket [Hof05, S. 85]; [RFC3748, S. 22]
Code
Das Code-Feld ist 1 Byte lang und legt den Typ bzw. die Funktion des EAP-Pakets fest.
(Request, Response, Success, Failure)
Identifier
Das 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.
Length
Das Length-Feld ist 2 Byte lang und gibt die Länge des EAP-Pakets, inklusiv Header und
Datenteil, an.
Datenfeld (nur bei EAP-Request- und EAP-Response-Paketen)

EAP-Request- und EAP-Response-Pakete enthalten noch ein zusätzliches Datenfeld mit
einem 1 Byte langem Type-Feld und einem darauffolgenden Datenteil (Type Data) variabler
Länge, je nach gewähltem Type. Das Type-Feld legt fest, welche Information bzw. welche
Authentifizierungsmethode über ein EAP-Request- oder ein EAP-Response-Paket transportiert
wird.
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ät
des Supplicants durch den Authenticator. Die Identität kann hierbei in der Form „name@realm“
übermittelt werden. Die Übermittelung findet allerdings im Klartext statt. Daher sollte
hier, wenn möglich, eine anonyme Identität in der Form „anonymous@realm“ verwendet
werden. Diese dient nur für Routing-Zwecke, um die nachfolgenden EAP-Pakete an den
richtigen Authentifizierungsserver weiterzuleiten. Erst in den nachfolgenden EAP-Paketen mit
enthaltener Authentifizierungsmethode wird die vollständige Identität übermittelt. Je nach

2. Grundlagen 12
Type-Wert Beschreibung
1 Identity
2 Notification
3 Nak (Not acknowledged)
4 MD5-Challenge
5 One-Time Password (OTP)
6 Generic Token Card (GTC)
13 EAP-TLS
17 LEAP
21 EAP-TTLS
25 EAP-PEAP
29 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 an
den 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 nicht
unterstützt, kann er ein EAP-Response/Nak-Paket (Not acknowledged) an den Authenticator
schicken und die Authentifizierungsmethode somit ablehnen. Der Authenticator muss daraufhin
eine andere Methode wählen. Ist das nicht möglich, wird der Supplicant abgelehnt.[RFC3748,
S. 31 ff.]; [Rec08, S. 458]
Type 4 – 253
Die Typen 4 -253 stellen die unterschiedlichen Authentifizierungsmethoden dar, die für ein
EAP-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 am
besten 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 auf
die Methoden näher eingegangen, die für eine WLAN Authentifizierung nach IEEE 802.1X
eine 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 Secure
Socket Layer (SSL) bekannt und im RFC5246 [RFC5246] spezifiziert. EAP-TLS ist im RFC5216
[RFC5216] definiert. EAP-TLS führt eine gegenseitige Authentifizierung zwischen Supplicant
und 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 die
gegenseitige Authentifizierung sowohl ein Server-Zertifikat als auch jeweils ein Client-Zertifikat
auf den einzelnen Supplicants. Um die Client-Zertifikate auszustellen und zu verwalten, wird
eine 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 sowohl
das Server- als auch das Client-Zertifikat unverschlüsselt übertragen, was einem Angreifer
ermöglicht, die Identität des Nutzers zu ermitteln. Dies kann umgangen werden, indem zunächst
eine TLS Verbindung zwischen Supplicant und Authentifizierungsserver aufgebaut wird, bei
welcher sich zuerst nur der Server authentifiziert. Die Authentifizierung des Clients über das
Client-Zertifikat findet dann anschließend verschlüsselt innerhalb des TLS-Tunnels statt. Diese
Variante 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 Variante
von EAP-TLS und ist im RFC 5281 [RFC5281] spezifiziert. EAP-TTLS besitzt den Wert 21
im Type-Feld eines EAP-Pakets. Ein Authentifizierungsvorgang mittels EAP-TTLS besteht
aus zwei Phasen. In der ersten Phase wird ein verschlüsselter TLS-Tunnel zwischen Supplicant
und 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 der
zweiten Phase sicher und verschlüsselt durch den TLS-Tunnel statt. Für die Authentifizierung
innerhalb 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ähltem
Verfahren ü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ät
nicht ausgespäht werden. In der ersten Phase wird lediglich eine anonymisierte Identität
(anonymous@realm) des Nutzers übertragen, um die Authentifizierungsanfrage zum richtigen
Authentifizierungsserver leiten zu können. EAP-TTLS setzt im Gegensatz zu EAP-TLS kein
Client-Zertifikat voraus, da die Authentifizierung des Supplicants über Benutzername und
Password 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 nativ
von Windows unterstützt und kann nur durch die Installation zusätzlicher Software unter
Windows 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 ein
Carrier 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 die
Datenpakete 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ür
EAP-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 auch
hier 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 der
zweiten Phase findet dann die Authentifizierung des Supplicants innerhalb des verschlüsselten
TLS-Tunnels statt. Als Authentifizierungsverfahren innerhalb des Tunnels setzt EAP-PEAP
wiederum 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 mit
Type-Wert 29 (EAP-MS-CHAPv2) verwendet. Für EAP-PEAP/EAP-MS-CHAPv2 werden
auch keine Client-Zertifikate benötigt, da hier die Authentifizierung innerhalb des Tunnels
mittels Benutzername und Password stattfindet. Die Identität des Nutzers wird auch wie
bei EAP-TTLS erst in der zweiten Phase verschlüsselt über den Tunnel übertragen, dadurch
kann 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-Betriebssysteme
unterstü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 ein
Carrier Protocol (Trägerprotokoll), welches ein EAP-Paket enthält. Das EAP-Paket beinhaltet
den EAP-PEAP Datenteil, welcher einen TLS-Tunnel aufbaut, indem wiederum EAP-Pakete
(„inneres“ EAP) verschlüsselt übertragen werden. Die „inneren“ EAP-Pakete enthalten dann
die 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 eine

Authentifizierungsmethode von Microsoft, die im RFC 2759 [RFC2759] spezifiziert ist. Im
Gegensatz zu PAP (Password Authentication Protocol), wo Benutzername und Passwort im
Klartext ü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 Hashwert
und sendet diesen an den Server (Response). Der Server bildet ebenfalls den Hashwert aus der
Zufallszahl und dem hinterlegten Passwort. Wenn beide Hashwerte übereinstimmen, wird die
Authentifizierung 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 Kennwort
des Benutzers zu kennen. Bei CHAP hingegen wird nur der Client authentifiziert.
1. Der Server fordert den Client zur Authentifizierung auf und schickt eine Challenge
bestehend aus einer Session-ID (Session Identifier) und einem zufälligen Wert (Challenge
String) an den Client.
2. Der Client erzeugt ebenfalls einen zufälligen Wert (Peer Challenge String) und bildet
aus diesem, dem Challenge String, der Session-ID und seinem Passwort einen Hashwert.
Den Hashwert schickt er zusammen mit seinem Benutzernamen und dem Peer Challenge
String 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 empfangen
Hash. Wenn beide Hashwerte übereinstimmen, sendet der Server eine Annahmebestäti-
gung (Accept), ansonsten eine Ablehnung (Reject) an den Client. Die Annahme enthält
einen Hashwert, gebildet aus dem Challenge String, dem Peer Challenge String, dem
vom Client geschickten Hashwert und dem Benutzerpasswort.
4. Der Client überprüft jetzt den vom Server erhaltenen Hashwert. Stimmt dieser mit
seinem selber berechneten Hashwert überein, wird die Verbindung akzeptiert, andernfalls
bricht 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 in
Kombination mit EAP-PEAP eingesetzt. Hier fungiert EAP-MS-CHAPv2 dann als inneres
Authentifizierungsverfahren innerhalb eines verschlüsselten TLS-Tunnels.
2.4. EAPOL
Um EAP-Pakete zwischen dem Supplicant und dem Authenticator über LAN bzw. WLAN zu
transportieren, 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 und
Authenticator ausgetauscht werden, werden in einen EAPOL-Frame gepackt, welcher dann
über LAN oder WLAN auf „Layer 2 Ebene“ (eingebettet in ein Ethernet-Frame) übertragen
wird. 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 Supplicant
muss zunächst die MAC-Adresse des Authenticators ermitteln. Dazu sendet der Supplicant
ein EAPOL-Start-Frame an die Multicast-Adresse 00:80:C2:00:00:03, welche speziell für den
Authenticator reserviert ist und nicht über Bridges weitergeleitet wird. Auf diesem Weg teilt
der Supplicant dem Authenticator mit, dass er sich authentifizieren möchte. Der Authenticator
reagiert 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 die
Kommunikation 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 und
Authenticator verwendet.
EAPOL-Encapsulated-ASF-Alert (Type 4)
Über EAPOL-Encapsulated-ASF-Alert-Frames können Fehler- und Warnmeldungen über nicht
autorisierte (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 Version
Das Protocol-Version-Feld ist 1 Byte lang und legt die Version des Protokolls fest. Im Moment
hat das Feld immer den Wert 1.
Packet Type
Das 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 Length

Das 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 Body
Nur 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. Zum
Beispiel ist bei Typ 0 ein EAP-Paket im Body-Feld enthalten und bei Typ 3 handelt es sich
um Informationen zum Aushandeln der Schlüssel.
2.5. RADIUS
RADIUS (Remote Authentication Dial-In User Service) ist ein Server-Dienst mit zugehörigem
Kommunikationsprotokoll und ist im RFC 2865 [RFC2865] spezifiziert. Dabei wird das RADIUS-
Protokoll eingesetzt, um EAP-Pakete zwischen dem Authenticator, welcher bei RADIUS auch
als Network Access Server (NAS) bezeichnet wird, und dem Authentifizierungsserver über
LAN zu transportieren. Dies setzt natürlich voraus, dass auf dem Authentifizierungsserver
ein RADIUS-Server läuft, der die Aufgaben Authentifizierung, Autorisierung und Accounting
(AAA-Server) übernimmt. Alle EAP-Pakete, die zwischen Authenticator und RADIUS-Server
ausgetauscht werden, werden in ein RADIUS-Paket gepackt, welches dann über UDP übertragen
wird. Die Default-RADIUS-Ports sind UDP-Port 1812 für Authentifizierungsanfragen und
UDP-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 Authentifizierung
mittels 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 und
Passwort direkt innerhalb des RADIUS-Pakets als RADIUS-Attribut oder auch gekapselt
innerhalb eines EAP-Response-Pakets mit Authentifizierungsmethode, welches wiederum in
das 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 dem
Supplicant Zugriff auf das Netz gewähren. Falls die Authentifizierung auf EAP basiert, befindet
sich innerhalb des Access-Accept-Pakets ein EAP-Success-Paket.
Access-Reject (Code 3)
Das Access-Reject-Paket wird vom RADIUS-Server zum Authenticator übertragen, wenn
die Authentifizierung des Supplicants fehlgeschlagen ist. Falls die Authentifizierung auf EAP
basiert, 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 zum
Authenticator zu übertragen. Das Paket übermittelt dabei Informationen direkt innerhalb des
RADIUS-Pakets als RADIUS-Attribut oder auch gekapselt innerhalb eins EAP-Request-Pakets
mit 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]
Code
Das Code-Feld ist 1 Byte lang und legt den Typ bzw. die Funktion des RADIUS-Pakets fest.
(Request, Accept, Reject, Challenge)
Identifier
Das Identifier-Feld ist 1 Byte lang und enthält eine laufende Nummer, an der zusammengehö-
rende Access-Request- und Access-Challenge-Pakete erkannt werden.
Length
Das Length-Feld ist 2 Byte lang und gibt die Länge des RADIUS-Pakets an.

2. Grundlagen 21
Authenticator
Das Authenticator-Feld ist 16 Byte lang und hat die Aufgabe, Antwort-Pakete vom RADIUS-
Server zum Authenticator zu authentifizieren. Damit kann sichergestellt werden, dass ein
Antwort-Paket auch wirklich von dem RADIUS-Server stammt, an den die Anfrage gestellt
wurde, und dass es unterwegs nicht verändert wurde. Dazu schickt der Authenticator in einem
Access-Request einen Zufallswert (Nonce) im Authenticator-Feld mit (Request Authenticator).
In einem Antwort-Paket (Access-Accept /-Reject /-Challenge) berechnet der RADIUS-Server
einen 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 Response
Authenticator bezeichnet. Eine weitere Aufgabe des Authenticator-Feld ist es, Passwörter,
die sich direkt in Access-Request-Paketen befinden und an den RADIUS-Server übermittelt
werden, zu verschlüsseln. Dies geschieht mit Hilfe des zufälligen Request Authenticators und
dem Secret-Key.
Attributes
Das Attributes-Feld beinhaltet RADIUS-Attribute, in welchen die relevanten Informationen
innerhalb eines RADIUS-Pakets übertragen werden. Jedes RADIUS-Paket kann mehrere
Attribute transportieren. Ein Attribut besteht aus folgenden drei Feldern: Type, Length (Länge
des 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) und
Passwort (Type 2) direkt über RADIUS zu übertragen (PAP). Auch für das CHAP-Verfahren
stehen Attribute bereit. Ein RADIUS-Paket lässt sich daher beliebig erweitern, indem neue
Attribute definiert werden. Um EAP-Pakete über RADIUS zu transportieren, gibt es ein
Attribut mit Type-Wert 79. Dieses Attribut kapselt ein EAP-Paket und überträgt es somit
gekapselt ü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 auch
möglich, dass ein RADIUS-Gerät mehrere Zustände annehmen kann.
RADIUS-Client
Ein RADIUS-Client schickt RADIUS-Anfragen (Access-Request-Pakete) an einen RADIUS-
Server. Bei der 802.1X Authentifizierung fungiert der Authenticator als RADIUS-Client.
RADIUS-Server
Ein 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-Proxy
Ein RADIUS-Proxy nimmt RADIUS-Anfragen entgegen und leitet diese an einen weiteren
RADIUS-Proxy oder an einen RADIUS-Server weiter. Dabei können RADIUS-Server auch als
RADIUS-Proxy arbeiten. Falls Anfragen nicht intern authentifiziert werden können, werden
diese an einen anderen RADIUS-Server weitergeleitet.
2.6. RadSec
RadSec (RADIUS Security) ist ein sicheres RADIUS-Protokoll, für welches es noch keinen
RFC-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 das
TCP-Protokoll. Der Standardport für RadSec ist TCP-Port 2083, über den alle RadSec-Pakete
laufen.
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-Paketen
teilweise 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 nur
eine schwache Verschlüsselung darstellt. Solange die RADIUS-Pakete innerhalb eines sicheren
internen Netzwerks (Intranet) ausgetauscht werden, stellt das eigentlich kein Problem dar.
Sobald aber RADIUS-Pakete über das Internet verschickt werden, wobei viele unbekannte
und auch potentiell unsichere Netze durchlaufen werden, besteht eine gewisse Gefahr, dass
RADIUS-Pakete mitgelesen werden. Weiterhin authentifizieren sich ein RADIUS-Client und
ein RADIUS-Server nur über den hinterlegten Secret-Key und ihre IP-Adressen. RadSec
hingegen nutzt das TCP-Protokoll und baut einen TLS-Tunnel auf, bei dem sich sowohl der
RADIUS-Client als auch der RADIUS-Server gegenseitig mittels eines gültigen Zertifikats
authentifizieren. 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 im
Gegensatz 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 der
Fall. 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 wie
der frei verfügbare „radsecproxy“ von UNINETT (http://software.uninett.no/ radsecproxy)
eingesetzt werden. RADIUS-Pakete werden dabei vom RADIUS-Proxy entgegen genommen

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 Ablauf
kann Abbildung 2.11 auf Seite 25 entnommen werden.
Zu Beginn meldet sich der Client am Access Point über eine Open-System-Authentifizierung an
und führt anschließend eine Assoziierung durch, in der die gegenseitig technischen Fähigkeiten
und unterstützten Sicherheitsmethoden ausgetauscht werden. Der Client ist jetzt mit dem
Access Point verbunden, hat aber noch keinen Zugriff auf das dahinterliegende Netzwerk.
Im nächsten Schritt folgt die Authentifizierung nach 802.1X. Die Authentifizierung über das
WLAN erfolgt nicht verschlüsselt. Die WLAN-Verschlüsselung wird erst nach erfolgreicher
Authentifizierung 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-Paket
an 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 richtigen
Authentifizierungsserver weiterzuleiten. Dies geschieht anhand des Realm. Der Access Point
leitet 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-Server
kö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-Paket
vom 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 ein
Austausch mehrerer EAP-Request- und EAP-Response-Pakete, in denen das Handshake für
den Tunnelaufbau vollzogen wird. Nach Aufbau des Tunnels, wird innerhalb des Tunnels mit
der eigentlichen Authentifizierung nach der Authentifizierungsmethode EAP-MS-CHAPv2
begonnen. 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 übertragen
werden. 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-Paketen
wird das Handshake durchgeführt. Nach erfolgreichem Abschluss der Authentifizierung, sendet
der Server ein RADIUS-Access-Accept-Paket an den Access Point. In diesem Paket ist eine
EAP-Success-Nachricht enthalten, welche an den Client weitergeleitet wird. Zusätzlich ist auch
noch ein Schlüssel enthalten (Pairwise Master Key (PMK)), welcher bei der Authentifizierung
zwischen 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 Point
ausgehandelt. Hierzu wird der vorhin erzeugte PMK benötigt. Dies erfolgt wie unter 2.7.1
auf der nächsten Seite beschrieben. Nach erfolgreichem Aushandeln der Schlüssel wird der
kontrollierte Port vom Access Point für den Client geöffnet und der Client erhält vollen
Zugriff auf das Netzwerk. Der Datenverkehr zwischen Access Point und Client erfolgt ab jetzt
verschlüsselt durch WPA- oder WPA2-Verschlüsselung. [Rec08, S. 469 ff.]; [Edn03]
Abbildung 2.10 zeigt die beteiligten Protokolle anhand eines Schichtenmodells. Die Pakete
einer 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-Paketen
verschlüsselt übertragen (in rot dargestellt). Die im Tunnel übertragenen Pakete können nur
vom Client und vom RADIUS-Server gelesen werden. Der Access Point und ggf. weitere
RADIUS-Proxys zwischen Access Point und RADIUS-Server haben darauf keinen Zugriff. Der
Access 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) und

Access Point (Authenticator) wird nach dem IEEE 802.11i-Standard eine Schlüsselhierarchie
verwendet, aus der die Schlüssel für die Verschlüsselung der Datenpakete abgeleitet werden. Im
Folgenden wird die Schlüsselhierarchie bezogen auf das AES-CCMP Verschlüsselungsverfahren
mit Authentifizierung nach dem IEEE 802.1X-Standard (WPA2-Enterprise) beschrieben.
Es gibt zwei „Arten“ von Schlüsselhierarchien. Einmal die paarweise Schlüsselhierarchie, die
die 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 nur
dem entsprechenden Client und dem Access Point bekannt ist. Jeder Client hat dabei seinen
eigenen Schlüssel, um mit dem Access Point verschlüsselt zu kommunizieren. Die Übertragung
der Multicast- und Broadcast-Frames erfolgt verschlüsselt über einen Gruppenschlüssel, der
allen 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 der
802.1X Authentifizierungsphase beim Client und beim Authentifizierungsserver (RADIUS-
Server) ein paarweiser Schlüssel erzeugt, der als Master Key bezeichnet wird. Von diesem
Key wird der sogenannte Pairwise Maser Key (PMK) abgeleitet. Der PMK wird dann vom
Authentifizierungsserver, 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 als
Pairwise Master Key Security Association (PMSKA) bezeichnet. Der PMK hat eine Länge
von 256 Bits und entspricht quasi dem Pre-Shared Key, welcher aus einem Passphrase bei
WPA2-Personal abgeleitet wird. Im Gegensatz zu WPA2-Enterprise ist der Pre-Shared Key bei
WPA2-Personal auf allen WLAN Stationen der gleiche. Bei WPA2-Enterprise hingegen besitzt
jeder Client seinen eigenen PMK. Aus dem PMK wird dann mittels eines 4-Wege-Handshake
Verfahrens über EAPOL-Key-Frames, der Pairwise Transient Key (PTK) erzeugt. Der PTK
hat 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-CCMP
Verfahren 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-Frame
vom Access Point zum Client gesendet, in dem ein Zufallswert (ANonce) enthalten ist. Der
Client erzeugt darauf einen eigenen Zufallswert (SNonce) und bildet aus ANonce und SNonce
zusammen mit dem PMK den PTK. Der Client schickt jetzt ein EAPOL-Key-Frame an den
Access Point, in dem die SNonce enthalten ist. Der Access Point kann jetzt auch den PTK aus
der 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 jetzt
installiert werden soll. Daraufhin bestätigt der Client dem Access Point die Installation des
Schlüssels mittels eines weiteren EAPOL-Key-Frames. Sowohl Client als auch Access Point
verfü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-Handshake
ausgetauscht, welcher für die Übertragung der Multicast- und Broadcast-Frames dient. Dazu
erstellt der Access Point einen Group Master Key (GMK), von welchem dann der Group
Temporal Key (GTK) mit Hilfe einer Zufallszahl (Nonce) abgeleitet wird. Der GTK hat
eine Länge von 128 Bit und wird an alle angemeldeten Clients über EAPOL-Key-Frames
verschlüsselt übertragen. Dies läuft über ein 2-Wege-Handshake. Der Access Point sendet
ein EAPOL-Key-Frame an den Client, in welchem der GTK verschlüsselt durch den KEK
enthalten ist und fordert den Client auf, den GTK zu installieren. Der Client antwortet darauf
mit 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 Seite
entnommen 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önnen
nun mit einer verschlüsselten Kommunikation über das AES-CCMP Verfahren beginnen. Das
Aushandeln der Schlüssel stellt den Abschluss der 802.1X Authentifizierung dar. Jetzt kann
der Access Point (Authenticator) seinen Port öffnen und dem Client (Supplicant) Zugriff auf
das 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 Wechseln
in 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 Client
erst neu authentifiziert werden muss, bevor er wieder Zugriff auf das Netz hat. Da bei der
Authentifizierung, je nach gewähltem Verfahren (EAP-Methode), erst größere Frames mit dem
Authenticator 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ögerung
zu minimieren. [Rec08, S. 475]
PMKSA-Caching
Beim 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 zum
Access 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 die
Authentifizierung übersprungen werden und es wird gleich das 4-Wege-Handshake zum Aus-
handeln des PTK begonnen. Da der PTK neu ausgehandelt wird, wird beim Wiederverbinden
auch ein neuer Schlüssel für die Verschlüsselung verwendet. [Rec08, S. 476]
Pre-Authentication
Beim Pre-Authentication-Verfahren führt ein Client, sobald er feststellt, dass die Verbindung
schlechter wird, bereits eine Authentifizierung über den „neuen“ Access Point durch, mit
welchem als nächstes eine Verbindung aufgebaut werden soll. Die Authentifizierung erfolgt
dabei noch mit Hilfe des „alten“ Access Point, mit welchem der Client noch verbunden ist, und
dem dahinter liegenden Distributionssystem (z. B. drahtgebundenes LAN). Sobald der Client
sich dann mit dem „neuen“ Access Point verbindet, kann gleich mit dem 4-Wege-Handshake
zum 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ür
internationale 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 teilnehmenden
Institution, 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. Die
Autorisierung für den Zugriff auf das WLAN erfolgt hingegen bei der jeweiligen Einrichtung
selber. [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 zur
jeweiligen Heimateinrichtung des Nutzers weiter, wo diese geprüft und bestätigt wird. Bei
erfolgreicher Authentifizierung erhält der Nutzer Zugang auf das WLAN der entsprechenden
Einrichtung. [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-Server
muss wiederum an den nationalen Top-Level RADIUS-Proxy angebunden werden, an wel-
chen Authentifizierungsanfragen von externen Nutzern weitergeleitet werden. Der nationale
Top-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 den
Niederlanden 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, sondern
lä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 Hochschulen
und Forschungseinrichtungen miteinander und ist nahtlos in den europäischen und weltweiten
Verbund der Forschungs- und Wissenschaftsnetze integriert. Über mehrere leistungsstarke
Austauschpunkte ist das DFN ebenfalls mit dem allgemeinen Internet verbunden. Zudem
bietet 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 1984
gegründet und verfolgt ausschließlich gemeinnützige Zwecke. Der-Verein besteht aus über 300

2. Grundlagen 31
institutionellen Mitgliedern von Hochschulen, Forschungseinrichtungen sowie forschungsnaher

Unternehmen 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 Unternehmen
in Deutschland untereinander mit den Wissenschaftsnetzen in Europa und auf anderen Konti-
nenten verbunden. Darüber hinaus verfügt das X-WiN über leistungsstarke Austauschpunkte
mit dem allgemeinen Internet.
Mit Anschlusskapazitäten bis zu 10 Gigabit/s und einem Terabit-Kernnetz zählt das X-WiN
zu den leistungsfähigsten Kommunikationsnetzen weltweit. [DFN10]
2.9.3. DFNRoaming
DFNRoaming ist ein Dienst des Deutschen Forschungsnetzes, der Nutzern einen einfachen
Zugang, ohne zusätzliche Anmeldung, zum Wissenschaftsnetz und zum Internet bietet. Dabei
ist es gleichgültig, ob der Nutzer sich an seiner eigenen Einrichtung oder bei einer anderen
am DFNRoaming teilhabenden Einrichtung befindet. Das DFNRoaming ist dabei in das
entsprechende 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 dem
DFNRoaming den nationalen Top-Level RADIUS-Proxy von Deutschland, an welchen alle
RADIUS-Server, der am DFNRoaming/eduroam teilhabenden Institutionen, angebunden sind.
Der Top-Level RADIUS-Proxy vom DFN ist wiederum mit dem europäischen Top-Level
RADIUS-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 sollen
Angehörige der HSU zusätzlich Zugang zum Intranet erhalten, um auf Server und Drucker
zugreifen 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ätzlich
einen Gastzugang beantragen zu müssen. Für diesen Zweck soll das WLAN der Hochschule
Ulm an einen Roaming-Dienst angebunden werden, welcher die gewünschten Möglichkeiten
bietet.
3.2. Anwendungsfälle
Im Wesentlichen gibt es nur einen grundlegenden Anwendungsfall, welcher in Abbildung 3.1
zu sehen ist. Dieser Anwendungsfall beschreibt, dass sich ein Nutzer mit dem WLAN über
einen 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 an
und 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 und

konfiguriert
• 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 das
Internet 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 (kann
je 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 und
erhä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 und
Intranet 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 und
Intranet 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 anderen
Institution 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, wie

die 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 das
Internet zugreifen
Standardablauf:
1. Angehöriger verbindet seinen Client über einen Access Point mit dem WLAN der
Institution
2. Angehöriger wird nach Benutzername und Passwort zur Authentifizierung gefragt (kann
je 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 HSU
an 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 Internet
zugreifen
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 nach
Konfiguration 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, die
jedoch für die vorliegende Arbeit nicht von Bedeutung sind und daher nicht weiter beachtet
werden.
Ein Beispiel hierfür ist, dass sich ein Gast am WLAN der HSU anmelden möchte, dessen
Institution aber nicht an einem Roaming-Dienst teilnimmt. Solch ein Gast kann sich dann
nicht ohne weiteres am WLAN der HSU anmelden, da in diesem Fall keine Authentifizierung
möglich ist. Der Gast muss sich dann zunächst einen „Gast-Account“ von der HSU geben
lassen. Erst jetzt ist es für ihn möglich, sich am WLAN der HSU anzumelden. Der Ablauf
erfolgt dann wie unter 3.2.1 auf Seite 33 beschrieben, allerdings darf der Gast keinen Zugriff
auf 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 hohe
Prioritä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 Zugang
zum hochschulinternen Netzwerk (Intranet) bieten. Dadurch können Angehörige auf
Server und Drucker der HSU zugreifen.

Auch diese Anforderung muss unbedingt umgesetzt werden. Daher ergibt sich eine hohe
Prioritä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 mittlere
Prioritä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 HSU
haben. Gäste dürfen nur einen Zugang zum Internet bekommen.
Diese Anforderung wiederum muss unbedingt umgesetzt werden. Daher ergibt sich eine
hohe 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 eine
mittlere 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 fallen
Geräte wie Laptops, Tablet-PCs, Smartphones. Diese Geräte arbeiten mit unterschied-
lichen Betriebssystemen wie z. B. Windows, Linux, Mac OS X, iOS, Android, Windows
Mobile, 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 Anforderung
erhält daher eine hohe Priorität.
NF2 Bedienung (hoch)

Die Anmeldung am WLAN muss so einfach wie möglich für den Anwender sein. Daher
muss sich der Konfigurationsaufwand bei der Ersteinrichtung für den Anwender auf
ein Minimum beschränken, so dass dies von jedem Anwender ohne spezielle Kenntnisse
vorgenommen werden kann. Auch muss darauf geachtet werden, dass ein Standard
verwendet wird, der von den oben genannten Betriebssystemen von Haus aus unterstützt
wird, 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ür
alle Nutzer ein gewisses Maß an Sicherheit bieten. Die über Funk übertragenen Daten
müssen in jedem Fall verschlüsselt sein, um einen Zugriff durch andere Personen darauf
zu verhindern. Die Verschlüsselung kann auf unterschiedlichen Wegen erfolgen, muss
aber den gängigen Sicherheitsstandards entsprechen.
Auch die Sicherheit spielt eine sehr wichtige Rolle und bekommt daher eine hohe
Prioritä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 Instanzen
verarbeitet und protokolliert werden. Hierzu zählen die HSU, der Roaming-Dienst und
die entsprechende Institution, welche am Authentifizierungsvorgang mit beteiligt ist.
Die Protokolle dürfen dabei nur zur Fehleranalyse, und um den Nutzer bei verbotenen
Aktivitäten ausfindig zu machen, verwendet werden.
Der Datenschutz ist wichtig, allerdings sollten die Anforderungen NF1, NF2 und NF3
vorrangig 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 schnellen
Zugriff auf das WLAN und die angebotenen Dienste wie Internet und Intranet haben.
Auch mehrere gleichzeitige Verbindungen über einen Access Point dürfen den Zugriff
nicht 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 Ausfalls
sollen umliegende Access Points die Arbeit des ausgefallen Access Point übernehmen
(Roaming).
Auch eine hohe Zuverlässigkeit ist nicht unbedingt notwendig. Daher bekommt diese
Anforderung eine mittlere Priorität.

3.3.3. Zusammenfassung
Im Folgenden werden die Anforderungen in einer tabellarischen Übersicht nochmals dargestellt.
Funktionale Anforderungen
Nummer Anforderung Priorität

FA1 Zugang für Angehörige der HSU zum Internet hoch
FA2 Zugang für Angehörige der HSU zum Intranet hoch
FA3 Zugang für Gäste zum Internet über das WLAN mittel
FA4 Kein Zugriff für Gäste auf das Intranet hoch
FA5 Anbindung des WLANs an einen Roaming-Dienst mittel
Tabelle 3.1.: Funktionale Anforderungen
Nichtfunktionale Anforderungen
Nummer Anforderung Priorität

NF1 Kompatibilität hoch
NF2 Bedienung hoch
NF3 Sicherheit hoch
NF4 Datenschutz mittel
NF5 Performance mittel
NF6 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 Hochschule
Ulm 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 ist
ein sicherer Zugang zum Intranet und Internet möglich. Das VPN-Gateway authentifiziert
den Nutzer am Active Directory der HSU. Alle über das WLAN übertragenen Daten werden
innerhalb eines VPN-Tunnels verschlüsselt zum VPN-Gateway übertragen. Daher ist eine
Verschlüsselung auf der Funkschnittstelle nicht nötig. Zum Aufbau des VPN-Tunnels wird ein
CISCO 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 das
WLAN.
Mit diesem bereits bestehenden Ansatz können die geforderten Anforderungen nur teilweise
erfüllt werden. Es ist für Gäste nicht ohne weiteres möglich, sich am WLAN anzumelden und
Zugriff 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 die
Einrichtung 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 die
Kompatibilitä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 eduroam
zusammen 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 aller
teilnehmenden 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 umgestellt
werden. Im Folgenden werden die dafür benötigten Komponenten aufgeführt. Anschließend wird
der Ablauf des Authentifizierungsvorgangs anhand der benötigten Komponenten dargestellt.
4.2.1. Benötigte Komponenten
Access Point
Es wird ein Access Point benötigt, der eine 802.1X Authentifizierung zusammen mit der
WPA2-Enterprise Verschlüsselung unterstützt.
RADIUS-Server
Zur Authentifizierung von Angehörigen der HSU wird ein RADIUS-Server benötigt, wel-
cher Authentifizierungsanfragen entgegennimmt und eine Authentifizierung durchführt. Der
RADIUS-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-Proxy
Für die Weiterleitung von Authentifizierungsanfragen von Gästen wird ein RADIUS-Proxy
benö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 DFN
weiterleitet. Als RADIUS-Proxy kann auch der FreeRADIUS eingesetzt werden. Um RADIUS-
Pakete aber sicher und verschlüsselt über TCP zu übertragen, muss das RadSec-Protokoll
verwendet werden. Dieses wird vom radsecproxy unterstützt, der von UNINETT bereitgestellt
wird (http://software.uninett.no/radsecproxy). Der radsecproxy wird als RADIUS-Proxy vom
DFN 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 über
EAPOL an den Access Point. Dieser nimmt die Anfrage entgegen und leitet sie innerhalb
eines RADIUS-Pakets (Access-Request) an den RADIUS-Server weiter. Der RADIUS-Server
entscheidet anhand des Realm, ob die Anfrage intern authentifiziert werden kann, oder an

4. Konzeption 42
den RADIUS-Proxy weitergeleitet werden muss. Anfragen, die intern authentifiziert werden
können, werden an einen Verzeichnisdienst weitergeleitet (z. B. über das LDAP-Protokoll an
ein Active Directory), welcher die Authentifizierung durchführt. Anfragen, die nicht intern
authentifiziert werden können, werden an den RADIUS-Proxy weitergeleitet, welcher diese
wiederum 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 der
jeweiligen Institution, von der der Gast stammt, weiter. Dieser führt dann die Authentifizierung
des Gastes durch. Dazu muss die Institution auch am DFNRoaming/eduroam teilnehmen.
Bei erfolgreicher Authentifizierung sendet der RADIUS-Server, welcher die Authentifizierung
durchgeführt hat, ein Access-Accept-Paket an den Access Point, der dann den Client autorisiert
und ihm Zugang zum WLAN gewährt. Andernfalls wird der Client abgelehnt und der Zugang
blockiert.
Der genaue Ablauf und Paketaustausch einer 802.1X Authentifizierung zwischen einem Client
und 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 Hardware
und 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 Gemeinsamkeiten
im 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 das
Internet 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 das
Intranet bekommen, um bestimmte Server und Drucker nutzen zu können.
Um das zu ermöglichen, muss eine Unterscheidung zwischen den beiden Gruppen vorgenommen
werden. Dies kann durch zwei getrennte VLANs erreicht werden. Jeder Gruppe wird dabei ein
eigenes VLAN zugewiesen. Jedem VLAN wird wiederum ein eigener IP-Adressbereich durch
einen DHCP-Server zugeteilt. Anhand von Firewall-Regeln können dann die entsprechenden
Berechtigungen für die beiden Gruppen gesetzt werden.
Für die Anbindung an das DFNRoaming/eduroam und die Zuweisung der VLANs haben sich
zwei unterschiedliche Varianten ergeben, die beide ihre Vor- und Nachteile haben. Variante A
arbeitet nur mit einer SSID und dynamischem VLAN-Tagging. Variante B hingegen arbeitet
mit 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örigen
der HSU ist es somit weiterhin möglich, sich über den CISCO VPN-Client am WLAN der
HSU 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 dem
Namen „eduroam“ hinzu. Diese SSID muss in allen WLAN-Installationen vorkommen, die an
eduroam angebunden sind. Nur durch eine gleiche SSID kann das Roaming an allen Standorten
innerhalb des eduroam-Verbundes funktionieren.
Im WLAN der HSU wird die SSID „eduroam“ sowohl von Angehörigen der HSU als auch von
Gästen verwendet. Alle Nutzer verbinden sich über diese SSID mit dem WLAN. Da nur mit
einer 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 Access
Point 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-Paketen
werden dann vom RADIUS-Server Attribute zur Übermittlung der entsprechenden VLAN-ID
angehängt. Anhand dieser RADIUS-Attribute erkennt der Access Point, dass er nicht die
VLAN-ID für die Gastgruppe verwenden soll, sondern die im Attribut angegebene. Angehörigen
der HSU wird so ein anderes VLAN, in welchem sie erweiterte Rechte besitzen und auch
Zugriff auf das Intranet der HSU haben, zugewiesen.
Variante B
Bei Variante B kommen neben der bereits bestehenden SSID „ZKI“ zwei weitere SSIDs mit
dem Namen „IMZ“ und „eduroam“ hinzu. Die SSID „IMZ“ ist für Angehörige der HSU gedacht
und „eduroam“ für Gäste. Dabei kann der Name der SSID „IMZ“ frei gewählt werden. Nur die
zweite SSID muss unbedingt „eduroam“ heißen, damit das Roaming auch funktioniert und
Gäste sich am WLAN anmelden können.
Jeder SSID ist ein eigenes VLAN im Access Point zugeordnet. Gäste und Angehörige der HSU
werden in diesem Ansatz anhand der SSID unterschieden, welche ihnen wiederum ein VLAN
zuteilt. Es muss hier kein dynamisches VLAN-Tagging durch den RAIUS-Server konfiguriert
werden, da die zwei VLANs den SSIDs über den Access Point fest zugeordnet sind. Je nach
dem über welche SSID ein Nutzer im WLAN angemeldet ist, befindet er sich automatisch in
dem VLAN, welches der SSID zugeordneten ist. Meldet sich eine angehörige Person der HSU
an der SSID „IMZ“ an, befindet sie sich automatisch im VLAN für Angehörige und erhält
Zugriff 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. Ein
Zugriff 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 soll
gezeigt 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 über
ein 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 mit
einem vorhandenen WLAN mit dem Namen „eduroam“.
Da bei Variante A nur die SSID „eduroam“ zur Verfügung steht, melden sich alle Nutzer, Gäste
wie Angehörige der HSU, an der gleichen SSID an. Das ist für die Nutzer sehr einfach, da nur
eine 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 allen
eduroam-WLANs an allen teilnehmenden Institutionen verbinden und Zugang zum Internet
erhalten. 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 er
Zugang 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 mehrere
WLAN-Konfigurationen auf einem Client konfiguriert und auch in Reichweite sind, kann es
vorkommen, dass sich der Client an der Hochschule auch mit der SSID „eduroam“ verbindet
und der Nutzer dann keinen Zugriff auf das Intranet hat. Das kann bei Variante A nicht
passieren, da ja nur eine SSID existiert und einem Angehörigen der HSU automatisch das
richtige 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 an
einer 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 Probleme
auftreten, ist es deutlich schwerer diese zu lösen, da man ja nicht an seiner Heimateinrichtung
vor 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 das
nicht passieren, da jeder Nutzer standardmäßig die SSID „eduroam“ auf seinem WLAN-Client
einrichten 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 in
welchem VLAN er sich schließlich befindet. Variante A hingegen verlagert die Auswahl des
VLANs weg vom Nutzer auf den RADIUS-Server. Dieser entscheidet automatisch, welches
VLAN einem Nutzer zugewiesen wird. Für den Nutzer bietet also Variante A deutlich mehr
Komfort, da er sich keine Gedanken mehr über die richtige Auswahl der SSID machen muss
und 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 Benutzergruppen
im Acitive Directory kann eine weitere Separierung der Angehörigen stattfinden. Dabei kann
jeder Nutzergruppe wieder ein eigenes VLAN zugewiesen werden. Die entsprechende VLAN-ID
wird dann je nach Realm oder Benutzergruppe im AD vom RADIUS-Server bestimmt. Alle
Nutzergruppen melden sich aber weiterhin über die SSID „eduroam“ am WLAN an. Ihnen
wird dann automatisch das richtige VLAN zugewiesen.
Um bei Variante B eine weitere Separierung durchführen zu können, müsste für jede weitere
Gruppe mit eigenem VLAN auch eine neue SSID eingeführt werden, da jeder SSID ja ein
VLAN fest zugewiesen ist. Dadurch würde die Anzahl der SSIDs weiter zunehmen und die
WLAN-Konfiguration für den Anwender noch komplizierter werden.
Konfiguration
Die Konfiguration beider Varianten benötigt einen ähnlichen Aufwand. Bei beiden Varianten
müssen mindestens zwei VLANs eingerichtet werden und ähnliche Konfigurationen am RADIUS-
Server und RADIUS-Proxy vorgenommen werden. Bei Variante A muss zusätzlich noch das
dynamische VLAN-Tagging am RADIUS-Server konfiguriert werden. Wie aber im Kapitel 6.5.3
auf Seite 85 zu sehen ist, ist das nicht aufwendig.
Bei Variante B hingegen muss eine zweite SSID mit festzugewiesenem VLAN am Access Point
erstellt 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 der
Anforderungen auswirken. Dabei werden die Anforderungen anhand der bereits getroffenen
Entscheidungen 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üllungsgraden
handelt es sich um theoretisch maximal mögliche Werte. Die tatsächlichen Werte ergeben sich
erst durch die Beachtung weiterer Randbedingungen (z. B. gewählte Verschlüsselung), welche
erst in den kommenden Kapiteln festgelegt werden.
Funktionale Anforderungen
Die Wahl einer Variante hat keine Auswirkung auf den Erfüllungsgrad der funktionalen
Anforderungen. 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 werden
können.
Erfüllungsgrad Bewertung
Anforderung Priorität
A B A B
FA1 hoch (10) 100% 100% 10 10
FA2 hoch (10) 100% 100% 10 10
FA3 mittel (7) 100% 100% 7 7
FA4 hoch (10) 100% 100% 10 10
FA5 mittel (7) 100% 100% 7 7
Summe 44 44
Tabelle 4.1.: Pugh-Matrix Funktionale Anforderungen

4. Konzeption 48
Nichtfunktionale Anforderungen
Bei den nichtfunktionalen Anforderungen wirkt sich die Wahl der Variante nur auf die nicht-
funktionale Anforderung „Bedienung“ aus. Bei Variante A ist die Konfiguration und Bedienung
fü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 auch
bei Variante A eine einmalige Konfiguration des Clients vorgenommen werden muss und das
einen einmaligen Aufwand für den Anwender bedeutet. Je nach verwendetem System kann die
Konfiguration mit mehr oder weniger Aufwand verbunden sein.
Auf die Anforderungen NF1 und NF3 bis NF6 hat die Wahl der Variante keinen Einfluss. Die
Anforderungen 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-Authentifizierung
unterstützen muss, um kompatibel zu sein. Es befinden sich aber wenige WLAN-Geräte im
Umlauf, die das nicht tun.
Für NF6 erfolgt keine Bewertung, da über die Zuverlässigkeit noch keine Aussage gemacht
werden 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,5
Punkten über Variante B mit 37,5 Punkten liegt.
Erfüllungsgrad Bewertung
Anforderung Priorität
A B A B
NF1 Kompatibilität hoch (10) 95% 95% 9,5 9,5
NF2 Bedienung hoch (10) 90% 40% 9 4
NF3 Sicherheit hoch (10) 100% 100% 10 10
NF4 Datenschutz mittel (7) 100% 100% 7 7
NF5 Performance mittel (7) 100% 100% 7 7
NF6 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 Vergleich
zu 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 den
Anwender deutlich einfacher ist. Der Anwender wird dadurch entlastet. Generell sollte darauf

4. Konzeption 49
geachtet werden, dem Anwender Entscheidungen abzunehmen und somit auch die Fehlerquellen
möglichst gering zu halten. Diese Anforderung kann nur durch Umsetzung der Variante A
mit einer SSID erreicht werden. Aufgrund der Vorteile bei der Bedienung mit Variante A fällt
auch die Bewertung der nichtfunktionalen Anforderungen mit 42,5 Punkten besser aus als bei
Variante 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 Authentifizierung
zusammen mit einer WPA2-Enterprise Verschlüsselung unterstützt. Weiterhin muss der Access
Point mehrere SSIDs gleichzeitig aussenden können und jeder SSID ein festes VLAN zuweisen
können. Auch dynamisches VLAN-Tagging anhand von RADIUS-Attributen muss der Access
Point beherrschen.
Dafür wurden Access Points vom Typ D-Link DWL-8600AP angeschafft. Dieser Access 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 externe Antennen zur Verfü-
gung. Der Access Point unterstützt im Standard 802.11n zwei Datenströme in eine Richtung
gleichzeitig (Multiple In Multiple Out (MIMO)). Zusammen mit einer Kanalbandbreite 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 ermöglicht bis zu 16 SSIDs pro Frequenzband. Jeder
SSID 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 auf
die einzelnen Geräte verteilt. Der Wireless Switch kümmert sich zudem um die automatische
Kanalwahl 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 einem
fast ausschließlich unter Windows betriebenem Netzwerk arbeitet und der Domänencontroller
mit Active Directory ein Windows Server 2008 R2 ist, wird ein RADIUS-Server auf Windows
Basis gewählt. Als RADIUS-Server kommt ein Windows Server 2008 R2 mit aktiviertem
Network Policy Server (NPS) zum Einsatz.

4. Konzeption 50
RADIUS-Proxy
Als RADIUS-Proxy kommt, wie vom DFN empfohlen, der radsecproxy von UNINETT zum
Einsatz. Dieser unterstützt neben dem RADIUS-Protokoll auch das RadSec-Protokoll. Die
Kommunikation mit dem RADIUS-Server erfolgt dabei über das RADIUS-Protokoll. Zu den
Top-Level RADIUS-Proxys vom DFN erfolgt die Kommunikation allerdings mittels RadSec.
Die RADIUS-Pakete werden somit über das WAN zum DFN-Proxy verschlüsselt innerhalb
eines TLS-Tunnels übertragen und können daher nicht von außen mitgelesen werden. Dies
ist ein wichtiger Schritt für den Datenschutz, da der Anmeldename in einem RADIUS-Paket
im Klartext vorliegt und somit Rückschlüsse auf den Nutzer möglich sind, falls die Pakete
abgefangen 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äte
verbinden, welche auch WPA2-Enterprise mit CCMP-Verschlüsselung unterstützen. Die meisten
Gerä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 Sicherheit
gemacht 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 zwischen
den WLAN-Clients wird vom Access Point blockiert. Ein WLAN-Client kann dann nur noch
mit Geräten kommunizieren, welche an den Access Point über LAN angebunden sind. Die
WLAN-Clients sind somit voneinander isoliert.
Durch das Aktivieren von Client Isolation kann die Sicherheit unter den WLAN-Clients weiter
erhöht werden. Andere WLAN-Clients sind für einen Nutzer dann nicht mehr sichtbar. Es
ist 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 und
bösartiger Software unter den WLAN-Clients wird hiermit unterbunden. Allerdings können
auch keine Daten mehr direkt zwischen zwei WLAN-Clients (z. B. über Netzwerkfreigaben)
ausgetauscht werden. Jeglicher Datenaustausch muss über ein am LAN angebundenes Gerät
erfolgen.
Falls ein direkter Datenaustausch zwischen den WLAN-Clients nicht benötigt wird, ist es
ratsam die Funktion Client Isolation auf den Access Points zu aktivieren, um die Sicherheit
der 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 Authentifizierungsmethode

gewählt werden. Mit dieser wird die Authentifizierung zwischen Client und RADIUS-Server
durchgeführt. Da nach den Anforderungen die Authentifizierung bei den meisten Geräten ohne
Installation einer Zusatzsoftware unterstützt werden soll, muss eine Authentifizierungsmethode
gewählt werden, die die meisten Clients von Haus aus unterstützen. Hierfür stehen unter
Windows nur die Authentifizierungsmethoden EAP-PEAP zusammen mit EAP-MS-CHAPv2
oder EAP-TLS zur Verfügung.
EAP-TLS setzt allerdings Client-Zertifikate zur Authentifizierung voraus. Wegen des hohen
Aufwands beim Verteilen von Client-Zertifikaten kommt diese Methode nicht in Frage. Daher
wird als Authentifizierungsmethode EAP-PEAP mit EAP-MS-CHAPv2 gewählt. Bei dieser
Methode findet die Authentifizierung mittels Benutzername und Passwort über einen ver-
schlüsselten TLS-Tunnel zwischen Client und RADIUS-Server statt. Diese Methode ist zudem
weit verbreitet und wird ab Windows XP SP2 nativ von Windows unterstützt. Auch andere
Plattformen wie z.B. Mac OS X oder auch gängige Smartphone-Betriebssysteme unterstützen
EAP-PEAP/EAP-MS-CHAPv2.
Weitere Informationen zu dieser Authentifizierungsmethode und noch weiteren Alternativen
kö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 Phase
wird die Identität im Klartext für Routing-Zwecke übertragen (äußere Identität). Anhand
des 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 eines
TLS-Tunnels zwischen Client und RADIUS-Server wird die Identität im Tunnel verschlüsselt
ein 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 die
Identitä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 mit
der ä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 Einrichtung
nicht 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, werden
die Authentifizierungsanfragen über die RADIUS-Proxys von eduroam bzw. dem DFN zur
Heimateinrichtung 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 auf
den 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ötigt
wird, 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) innerhalb
eines verschlüsselten Tunnels zwischen Client und RADIUS-Server übertragen, welche nur vom
RADIUS-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, lediglich
die 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 Windows
Server 2008 unterstützt. Auch die meisten Clients unterstützten diesen. Windows allerdings
erst ab Windows 7.
Weitere Informationen zum detaillierten Ablauf der Authentifizierung können Abschnitt 2.7
auf Seite 23 entnommen werden.
VLAN
Für die Trennung der beiden Gruppen (Gäste und Angehörige der HSU) werden mindestens
zwei eigene VLANs benötigt. Dazu kommt noch ein weiteres VLAN für die Verwaltung der
Access Points, über welches auch die Authentifizierung der Clients durchgeführt wird. Ein
viertes 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 angegebenen
VLAN-IDs handelt es sich nur um Beispiele.
• VLAN-ID<10> (Management-VLAN)
Dieses VLAN dient zur Administration der Access Points. Auch die Authentifizierung
der Clients findet darüber statt.
• VLAN-ID<20> (ZKI-VLAN)
Dieses VLAN ist der SSID „ZKI“ im Access Point fest zugewiesen. Angehörigen der
HSU, 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, die
sich mit der SSID „eduroam“ verbinden, wird dieses VLAN zugeteilt. Innerhalb dieses
VLANs 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-Server
mitgeteilt (dynamisches VLAN-Tagging). Angehörigen der HSU, die sich mit der SSID
„eduroam“ verbinden, wird dann dieses VLAN statt VLAN<30> zugeteilt. Innerhalb
dieses 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ür
die Clients erfolgt durch einen DHCP-Server innerhalb jedes VLANs. Anhand von Firewall-
Regeln können dann die entsprechenden Berechtigungen für die beiden Gruppen gesetzt
werden.
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. Alle
Authentifizierungsanfragen von Clients werden per EAPOL an den Access Point übertragen,
welcher diese an den Wireless Switch weiterleitet. Die Übertragung der EAPOL-Pakete
zwischen Client und Access Point über das WLAN erfolgt dabei unverschlüsselt. Eine WLAN-
Verschlüsselung wird erst nach erfolgreicher Authentifizierung aktiviert. EAPOL-Pakete mit
Authentifizierungsanfragen können daher leicht abgefangen werden und die äußere Identität
kann 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 Authentifizierungsanfragen
innerhalb eines RADIUS-Pakets (Access-Request) an den RADIUS-Server (NPS) weiter. Der
RADIUS-Server nimmt die Authentifizierungsanfragen vom Wireless Switch entgegen und
entscheidet anhand des Realm, ob eine Anfrage intern authentifiziert werden kann, oder an
den RADIUS-Proxy weitergeleitet werden muss. Enthält die Anfrage keinen Realm bzw. den
Realm „@hs-ulm.de“, wird diese intern vom RADIUS-Server authentifiziert.
Für die interne Authentifizierung greift der RADIUS-Server über das LDAP Protokoll auf das
Active Directory zu und gleicht die angegebenen Benutzerinformationen (Benutzername und
Passwort) damit ab. Das AD befindet sich auf dem Domänencontroller, welcher auf einem
vom RADIUS-Server (NPS) getrennten Server läuft. Es ist möglich den NPS mit auf dem
Domänencontroller zu installieren. Aus Sicherheitsgründen sollten RADIUS-Server (NPS)
und Domänencontroller aber unbedingt voneinander getrennt werden. Wird beispielsweise ein
Angriff auf den RADIUS-Server durchgeführt, durch welchen dieser überlastet wird, wirkt
sich 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 wird
von einer Installation des NPS auf dem Domänencontroller abgeraten. Der NPS sollte am
besten 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 die
Anfragen dann (ggf. über weitere RADIUS-Proxys) an den RADIUS- Server der jeweiligen
Institution, von welcher der Gast stammt, weiter. Dieser führt dann die Authentifizierung des
Gastes durch. Dazu muss die Institution auch am DFNRoaming bzw. bei eduroam teilnehmen.
Bei erfolgreicher Authentifizierung sendet der RADIUS-Server, welcher die Authentifizierung
durchgeführt hat, ein Access-Accept-Paket an den Access Point, der dann den Client autorisiert
und 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
Als Authentifizierungsmethode wird EAP-PEAP mit EAP-MSCHAPv2 für Angehörige der

HSU eingesetzt. Bei Gästen können auch andere Authentifizierungsmethoden wie EAP-TLS
oder EAP-TTLS zum Einsatz kommen. Das gewählte Authentifizierungsverfahren spielt nur
eine direkte Rolle zwischen Client und dem RADIUS-Server, welcher für die Authentifizierung
zustä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ählte
Authentifizierungsmethode keine Rolle, da sie nur die RADIUS-Pakete sehen und diese weiter-
leiten. Erst der RADIUS-Server, der die Authentifizierungsanfrage entgegen nimmt und die
Authentifizierung 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 und
authentifiziert, muss er auch nur die Authentifizierungsmethode EAP-PEAP/EAP-MSCHAPv2

4. Konzeption 56
unterstützen. Alle anderen Anfragen von Gästen mit ggf. anderen Authentifizierungsmethoden
werden 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 einem
Client 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 je
nach Benutzergruppe ein bestimmtes VLAN zu. Der Access Point achtet dabei darauf, ob
bei einem Access-Accept-Paket die Attribute mit der zu verwenden VLAN-ID gesetzt sind
oder nicht. Access-Accept-Pakete für die Clients von Angehörigen der HSU enthalten diese
Attribute, welche bei der internen Authentifizierung vom RADIUS-Server der HSU gesetzt
werden. Die Attribute werden vom Access Point ausgewertet und dem Client eines Angehörigen
der HSU wird das im Attribut angegebene VLAN (VLAN<40>) zugewiesen (dynamisches
VLAN-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 zugeteilte
VLAN (VLAN<30>) zugewiesen. Bei Access-Accept Paketen, welche für die Clients von Gästen
bestimmt sind, sind die Attribute nicht enthalten, da die Gäste durch den RADIUS-Server
ihrer Heimateinrichtung authentifiziert werden. Dieser kann zwar auch Attribute mit VLAN-ID
setzen, allerdings müssen diese beim Weiterleiten über RADIUS-Proxys entfernt werden, um
die Access Points von anderen Einrichtungen nicht zu „verwirren“ und dem Gast ggf. ein falsches
VLAN zu zuweisen. Um sicher zu gehen, dass keine RADIUS-Pakete mit gesetzten Attributen
für die VLAN-ID das Netzwerk der HSU verlassen oder betreten, prüft der RadSecProxy der
HSU 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 erfolgreicher
Authentifizierung 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 diese
an 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 und
authentifiziert den Nutzer
8. RADIUS-Server schickt ein Access-Accept-Paket mit enthaltenen Attributen für die

VLAN-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-Attributen
enthaltenen VLAN-ID zu (VLAN<40>)
10. Client bekommt IP-Adresse vom DHCP-Server des VLAN<40> und erhält Zugriff auf
das 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 die
SSID „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 der

HSU 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 HSU
ab und authentifiziert den Nutzer
12. RADIUS-Server der HSU schickt ein Access-Accept-Paket über den RadSecProxy der
HSU, den DFN-Top-Level RADIUS-Proxy und den RADIUS-Server der Institution an
den 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 Zugriff
auf das Internet (zugewiesenes VLAN und IP-Adresse hängt von der Konfiguration der
jeweiligen 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 diese
an 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-Proxy

weiter
9. DFN-Top-Level RADIUS-Proxy leitet die Anfrage wiederum an den RADIUS-Server

der jeweiligen Institution weiter
10. RADIUS-Server der jeweiligen Institution authentifiziert den Nutzer nach der gewählten
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 an
den 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 auf
das 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 einen
Benutzeraccount 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 eduroam
Verbundes anmelden und wird über die HSU authentifiziert. Die Einrichtung des Clients und
der Ablauf der Authentifizierung erfolgt dabei wie bei einem Angehörigen der HSU. Allerdings
darf 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 keine
RADIUS-Attribute mit VLAN-ID gesetzt werden. Dann wird dem Gast automatisch das
Gast-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-Tagging
durchgefü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 angebotenen
Dienste wie Internet und Intranet haben, wird der Datendurchsatz eines neuen Access Points
gemessen. Mit dieser Messung soll untersucht werden, wie viele WLAN-Clients gleichzeitig mit
einem Access Point verbunden sein können, um die Anforderungen für eine gute Performance
einzuhalten. Dazu wird in einem Versuchsaufbau mit mehreren WLAN-Clients die mögliche
Sende- und Empfangsdatenrate gemessen. Hierbei wird auch getestet, inwieweit sich die WPA2-
Verschlüsselung auf den Datendurchsatz auswirkt. Im Nachfolgenden wird zunächst auf den
Versuchsaufbau und die verwendeten Geräte und Software eingegangen. Anschließend wird der
Messablauf 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 einen
Gigabit-Ethernet-Switch (Netgear GS105) sind zwei Computer (netlab-13/14) und der Access
Point (D-Link DWL-8600AP) mit dem Netzwerk (Subnetz: 141.59.21.0) verbunden. Auf diesen
Computern läuft das Netzwerkperformance Messprogramm (Iperf) als Server-Dienst. Über
den Access Point verbinden sich die WLAN-Clients mit dem Netzwerk. Auf den Clients läuft
Iperf als Client-Dienst. Weiterhin ist der RADIUS-Server (netlab-57), welcher für die 802.1X
Authentifizierung dient, über einen Fast-Ethernet-Switch (Cisco Catalyst 3560) mit dem
Netzwerk verbunden. Um Zugriff auf das Intranet und Internet zu haben, gibt es zusätzlich
noch eine Verbindung mit dem im Labor befindlichen Router. Um die Messungen aber nicht
zu 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 der
grafischen Oberfläche JPerf eingesetzt. Iperf ist ein plattformunabhängiges Konsolenprogramm
und dient zum Messen der Datenrate einer Netzwerkverbindung. Iperf kann als Server und
als Client ausgeführt werden. Für eine Messung wird mindestens ein Server benötigt, mit
dem sich ein oder mehrere Iperf-Clients verbinden. Zur Messung kann ein TCP- oder ein
UDP-Stream erzeugt werden. Dabei erzeugt der Client Daten und schickt diese über das
Netzwerk an den Server, welcher die Daten verwirft. Bei TCP kann zusätzlich ein Datenstrom
vom 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 Bedienung
und stellt die Messergebnisse grafisch dar. Jperf kann zusammen mit Iperf als bereits fertig
kompilierte 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 Einstellungen
betrieben:
• 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 und
sendet 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 Daten
zurück. Der Client sendet somit zunächst Daten und empfängt dann welche. Senden und
Empfangen erfolgt bei „Trade“ hintereinander. Damit kann die maximale Datenrate für das
Senden und Empfangen unabhängig voneinander gemessen werden. Bei „Dual“ hingegen sendet
und empfängt der Client gleichzeitig Daten. Hiermit kann die Datenrate bei gleichzeitigem
Senden 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). Alle
Messungen erfolgen aus Sicht des Clients. Beim Senden sendet also der Client Daten an den
Server 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 Anzahl

verwendet, um Tests mit unterschiedlichen WLAN-Standards (802.11g/n) durchführen zu
kö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. Dieser
Access 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 externe
Antennen zur Verfügung. Der Access Point unterstützt im Standard 802.11n zwei Datenströme
in eine Richtung gleichzeitig (Multiple In Multiple Out (MIMO)). Zusammen mit einer
Kanalbandbreite 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“ als
auch 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 jedem
Frequenzband 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.1X
Authentifizierung)
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. Alle
weiteren Einstellungen besitzen den Standardwert. Der Access Point ist unter der IP-Adresse
141.59.21.150 erreichbar und so konfiguriert, dass er für die 802.1X Authentifizierung mit dem
RADIUS-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 Datenrate
möglich ist, damit sich auch mehrere Iperf-Clients mit dem Iperf-Server über WLAN verbinden
kö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 die
Datenrate 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,0
Dual 307,0 310,0
Tabelle 5.1.: Datenrate Iperf-Server
Aus den Werten geht hervor, dass im Modus „Trade“, beim wechselseitigem Senden und
Empfangen eine Datenrate von über 580 MBit/s (69,14 MByte/s)1 möglich ist. Praktisch
sollten bei Gigabit-Ethernet Datenraten von über 900 MBit/s (107,29 MByte/s) möglich sein.
1
Die Umrechnung erfolgt nach folgender Annahme:
1Byte � 8Bit
1024Byte � 8192Bit
1KByte � 8, 192KBit
1024KByte � 8388, 608KBit
1M Byte � 8, 388608M Bit

Da die Gigabit-Netzwerkkarte in diesen beiden Computern aber über den PCI-Bus angebunden
ist, können keine maximalen Datenraten von über 900 MBit/s erreicht werden, da der PCI-Bus
dafür zu langsam ist. Die Datenrate eines 32 Bit PCI-Bus mit 33 MHz liegt theoretisch bei
133 MByte/s. Praktische Datenraten liegen aber deutlich darunter und der PCI-Bus wird noch
von weiteren Geräten verwendet, wodurch die für die Netzwerkkarte zur Verfügung stehende
Datenrate noch weiter gesenkt wird.
Im Modus „Dual“ wird bidirektional im Full-Duplex-Verfahren gesendet und empfangen. Die
Datenraten 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-Bus
begrenzt wird.
Die hier gemessenen Werte sind für den Test völlig ausreichend, da der Access Point eine
theoretische Datenrate von maximal 300 MBit/s erreicht. Der Access Point wird also nicht
durch 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-Client
maximal möglich sind, werden jeweils die Datenraten von einem WLAN-Client nach 802.11g
und einem WLAN-Client nach 802.11n unabhängig voneinander gemessen. Bei den n-Clients
kommen zwei unterschiedliche Geräte zum Einsatz, um zu erkennen, ob ein Unterschied
bei Geräten mit unterschiedlicher Hardware auftritt. Alle Messungen von n-Geräten werden
sowohl unter 2,4 GHz als auch unter 5 GHz durchgeführt, um einen Vergleich zwischen den
Datenraten der beiden Bänder zu haben. Um festzustellen, ob die WPA2-Verschlüsselung
sich 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 auf
Seite 64 beschrieben. Der WLAN-Client ist als einziges Geräte am Access Point angemeldet
und befindet sich in einem Abstand von ca. drei Metern zum Access Point. Es werden insgesamt
vier 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.
Datenrate 2,4 GHz [MBit/s]

Testing Mode Verschl.
Senden Empfangen
Trade - 20,4 20,8
Trade WPA2 20,6 20,6
Dual - 10,4 10,3
Dual 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. Dies
entspricht den Erwartungen, da die maximale Nettodatenrate bei 22 MBit/s liegt (siehe
Tabelle 2.1 auf Seite 4). Im Mode „Dual“ fällt die Datenrate bei gleichzeitigem Senden und
Empfangen auf über 10 MBit/s ab. Das liegt daran, dass ein WLAN-Gerät entweder Senden
oder Empfangen kann. Beides gleichzeitig (Full-Duplex) ist nicht möglich, da es sich bei WLAN
um ein „Shared-Medium“ handelt, welches sich jeder Sender und Empfänger teilen muss. Daher
muss das Gerät immer zwischen Senden und Empfangen hin und her wechseln. Im besten Fall
teilen sich die Datenraten gleichmäßig auf Senden und Empfangen auf.
Zwischen deaktivierter und aktivierter WPA2-Verschlüsselung ist bei den Datenraten kein
signifikanter Unterschied erkennbar. Die WPA2-Verschlüsselung wirkt sich also bei einem
WLAN-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.11n
gemessen. Als WLAN-Gerät wird einmal ein MacBook und ein HP-Laptop unabhängig
voneinander verwendet, wie unter 5.2.3 auf Seite 64 beschrieben. Der WLAN-Client ist als
einziges 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 wird
jeweils einmal ohne Verschlüsselung und anschließend mit WPA2-Verschlüsselung über 802.1X
Authentifizierung 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 und
für das HP-Laptop die in der Tabelle 5.4 dargestellten Werte.
Datenrate 2,4 GHz [MBit/s] Datenrate 5 GHz [MBit/s]

Senden Empfangen Senden Empfangen
Trade - 96,4 79,0 164,0 123,0
Trade WPA2 96,8 79,1 160,0 122,0
Dual - 74,6 18,7 122,0 31,7
Dual 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-Band
und über 160 MBit/s unter 5 GHz. Die Empfangsdatenraten liegen etwas darunter. Dies
entspricht sehr guten Werten und zeigt welche Datenraten nach dem Standard 802.11n möglich
sind. Im Mode „Dual“ verteilt sich die Datenrate auf Senden und Empfangen in einem Verhältnis
von ungefähr 4:1. Wie zu erkennen ist, liegen die Datenraten im 5-GHz-Band deutlich über
den unter 2,4 GHz gemessenen Werten. Dies liegt daran, dass der Access Point erst unter 5
GHz eine Kanalbreite von 40 MHz verwendet und somit seine maximale Bruttodatenrate von
300 MBit/s zur Verfügung stellt. Unter 2,4 GHz arbeitet er nur mit einer Kanalbreite von 20
MHz und einer Bruttodatenrate von 145 MBit/s. Anhand der Werte ist zu erkennen, dass
auch 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 unter
den Werten vom MacBook, da das HP-Laptop eine andere WLAN-Hardware verwendet.

Trade - 77,6 79,2 140,0 117,0
Trade WPA2 76,9 78,8 138,0 119,0
Dual - 55,7 12,5 115,0 29,5
Dual 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 die
Datenrate auf mehrere gleichzeitig aktive Clients aufteilt. Dabei wird eine Messung mit bis
zu 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 und
drei n-Clients gemessen. Dabei wird die Messung der n-Clients einmal im 2,4-GHz-Band und
anschließend im 5-GHz-Band durchgeführt, um festzustellen, inwieweit sich die Datenraten in
den 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 Clients
gemessen. Dabei wird der „Testing Mode“ „Dual“ gewählt, welcher die Clients gleichzeitig
senden und empfangen lässt. Zur Ermittlung des Messwerts werden die einzelnen Messwerte
für Senden und Empfangen aufsummiert und durch die Anzahl der jeweils beteiligten Clients
dividiert. Alle Messungen finden mit aktivierter WPA2-Verschlüsselung statt. Der Abstand
der Geräte zum Access Point liegt dabei zwischen drei und acht Metern.
Auswertung
In Tabelle 5.5 sind die gemessenen Werte aufgeführt.
Datenrate 2,4 GHz [MBit/s]

Anzahl Verschl.
Senden Empfangen
1 WPA2 10,3 10,3
2 WPA2 5,2 5,4
3 WPA2 3,4 3,3
4 WPA2 2,5 2,5
5 WPA2 2,1 2,0
10 WPA2 1,0 1,0
10 - 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äte
aufteilen. Bei 10 gleichzeitig aktiven Clients hat jeder Client auch nur noch ein Zehntel der
maximalen 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 Hilfe
des CSMA/CA-Verfahrens mit den anderen Clients abstimmen, damit keine Kollisionen beim
gleichzeitigen Senden entstehen. Die letzte Messung mit 10 Clients wurde zudem auch noch
ohne Verschlüsselung durchgeführt, um zu testen, ob ein Einfluss der WPA2-Verschlüsselung
zu erkennen ist. Allerdings ist auch hier kein Unterschied erkennbar.
In der Abbildung 5.2 ist der Zusammenhang zwischen Datenrate und Anzahl der Clients zu
erkennen. Der Kurvenverlauf ist die Funktion: AnzahlClients .
max.Datenrate
Dies entspricht der Funktion: x1 .
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. Die
Messung 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.
1 WPA2 51,6 13,3 113,0 29,6
2 WPA2 23,0 5,9 57,7 14,8
3 WPA2 14,3 4,2 37,0 9,3
3 - 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 deutlich
doppelt so hoch wie im 2,4-GHz-Band sind, was wiederum an der Kanalbandbreite von 40
MHz im 5-GHz-Band liegt. Die WPA2-Verschlüsselung beeinflusst auch hier die Datenraten
nicht.
In Abbildung 5.3 ist der Verlauf der Datenrate in Abhängigkeit von der Anzahl der Clients
dargestellt.
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äten
gemessen. Dabei werden fünf g-Geräte und drei n-Geräte verwendet. Die Messung findet einmal
mit allen Geräten im 2,4-GHz-Band und anschließend mit den n-Geräten im 5-GHz-Band und
den g-Geräten im 2,4-GHz-Band statt. Die Messungen werden einmal mit und einmal ohne
WPA2-Verschlüsselung durchgeführt. Alle Messungen werden im „Testing Mode“ „Dual“ bei
einem 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.
Datenrate g-Geräte [MBit/s] Datenrate n-Geräte [MBit/s]

Konstellation Verschl.
n in 2,4 GHz WPA2 1,5 1,5 3,6 0,6
n in 2,4 GHz - 1,5 1,5 3,8 0,7
n in 5 GHz WPA2 2,0 2,1 37,1 10,1
n 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-Band
befinden. 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 die
volle Datenrate erreichen zu können. Weiterhin ist auch keine Beeinflussung zwischen den
beiden Bändern zu erkennen. Die g-Geräte im 2,4-GHz-Band und n-Geräte im 5-GHz-Band
erzielen im Mischbetrieb die gleichen Datenraten, wie Geräte, welche nur in einem Band aktiv
sind. Daraus ergibt sich, dass bei „überlastetem“ 2,4-GHz-Band, im 5-GHz-Band immer noch
die volle Datenrate möglich ist. Auch die WPA2-Verschlüsselung hat wiederum keinen Einfluss
auf die Datenraten.

5.3.4. Access Point Cluster
Beschreibung
Um die Datenraten mehrerer Geräte zu verbessern, werden im letzten Test zwei Access Points
im Cluster eingesetzt. Durch den zweiten Access Point soll sich der Datenverkehr verteilen
und höhere Datenraten ermöglichen. Weiterhin soll geklärt werden, ob sich die beiden Access
Points gegenseitig beeinflussen.
Durchführung
Die Access Points sind zu einem Cluster zusammengefasst und besitzen daher die gleiche
Konfiguration. Sie strahlen somit beide die gleiche SSID aus. Der zweite Access Point wird
sieben Meter neben dem ersten aufgestellt. Für den Test werden fünf g-Geräte und drei
n-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 im
2,4-GHz-Band den Kanal 5 und 9. Die Kanäle wurden von der Automatik des Access Points
gewählt. Allerdings ist ein Kanalabstand von nur 4 Kanälen zu gering. Dadurch kommt es zu
Störungen zwischen den Access Points. Der Kanalabstand sollte für störungsfreien Betrieb
im 2,4-GHz-Band mindesten 5 oder besser noch 6 Kanäle betragen. Daraufhin wurden die
Kanäle manuell auf Kanal 1 und 13 gesetzt (diese Kanäle waren am wenigsten durch andere
Access Points benutzt). Eine erneute Messung zeigte, dass die zuvor aufgetretenen Probleme
verschwunden waren und die Datenraten der einzelnen Geräte jetzt höher lagen, da ein Teil
der Geräte jetzt mit dem zweiten Access Point kommunizieren konnte, ohne den Ersten zu
stören. Im 5-GHz-Band wurde dies nicht beobachtet. Hier wurden vom Access Point Kanäle
mit 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 Problemen
sollten die Kanäle am besten von Hand vergeben werden. In Kombination mit einem Wireless
Switch (D-Link DWS4026), mit welchem die Access Points später betrieben werden, werden
die Kanäle von diesem vergeben und nicht mehr vom Access Point selbst [DWS4026]. Ob das
oben beschriebene Problem auch hier auftritt, konnte nicht überprüft werden, da kein Wireless
Switch für Testzwecke zur Verfügung stand.

5.4. Zusammenfassung
Aus den Messungen geht hervor, dass die WPA2-Verschlüsselung keinen negativen Einfluss auf
die Datenraten hat und somit ohne Performanceverluste verwendet werden kann. Der einzig
limitierende 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 aufgeteilt
wird. Mit zunehmender Anzahl von Clients nimmt somit die pro Client zur Verfügung stehende
Datenrate ab.
Weiterhin geht aus den Messungen hervor, dass die Datenraten von Geräten nach dem
Standard 802.11n im 5-GHz-Band doppelt so hoch sind als wie unter 2,4 GHz. Dies liegt an
einer 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 ohne
Performanceeinbußen parallel genutzt werden können, sollten n-Geräte, wenn möglich, immer
unter 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ützung
unter 2,4 GHz deaktiviert werden. Im 2,4-GHz-Band sollten sich nur Geräte nach 802.11b/g
verbinden können.
Da b-Geräte mittlerweile recht selten sind und die meisten Geräte mindestens den Standard
802.11g unterstützen, kann ggf. die Unterstützung für 802.11b deaktiviert werden und nur ein
einheitliches WLAN nach 802.11g im 2,4-GHz-Band betrieben werden. Dies würde weiterhin
auch 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ünden
fü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 eingestellt
werden.
Auf den Standard 802.11a im 5-GHz-Band sollte komplett verzichtet werden, da dieser in
Europa recht wenig verbreitet ist und zu einer schlechteren Performance (aufgrund von
Kompatibilitätsgründen) für n-Geräte führt.
Die Messungen zeigen auch, dass zehn gleichzeitig aktive Geräte nach dem Standard 802.11g
mit einer Sende- und Empfangsauslastung von 100% problemlos mit einem Access Point
betrieben werden können und noch ausreichend Performance bieten. In der Praxis ist eine
Auslastung von 100% bei allen Geräten gleichzeitig eher unwahrscheinlich. Im Mittel kann
ungefähr mit einer Auslastung um die 30% pro Gerät gerechnet werden. Daher sollte in
der Praxis ein problemloser Betrieb mit bis zu 30 oder sogar noch mehr gleichzeitig aktiven
g-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 allerdings
zu 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äte
wirklich an einem Access Point betrieben werden können, bis es zu einer schlechten Performance
kommt. 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 von
ein paar Metern zum Ersten, der andere Access Point entlastet werden. Die Last teilt sich
dann auf beide Acces Points auf. Hierbei ist allerdings darauf zu achten, dass die Access Points
einen 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 50
unter 5 GHz
• Abstand: ist so zu wählen, dass Funkzellen sich im Randbereich überlappen. Aber auf
einen 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 das
DFNRoaming/eduroam anzubinden. Die dabei getroffenen Entscheidungen und gewählten
Einstellungen 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ächst
Kontakt 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:
• Realm
der zu verwendende Realm („@hs-ulm.de“), ggf. auch weitere Realms zur Separierung
der hochschulangehörigen Benutzer (z. B. „@student.hs-ulm.de“, „@dozent.hs-ulm.de“)
• Externe IP-Adresse des RadSecProxy

Um Authentifizierungsanfragen an den RadSecProxy der HSU weiterleiten zu können,
muss dem DFN die externe IP-Adresse des Servers bekannt sein, auf welchem der
radsecproxy von UNINETT läuft.
6.2. VLAN
Wie unter 4.3.4 auf Seite 53 beschrieben, müssen folgende VLANs, falls diese noch nicht
bestehen, eingerichtet werden:
• VLAN-ID<10> (Management-VLAN)
• VLAN-ID<20> (ZKI-VLAN)
• VLAN-ID<30> (Gast-VLAN)

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-Adressbereich
festgelegt werden und ein DHCP-Server konfiguriert werden. Anschließend müssen in der
Firewall 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 erfolgen
darf. 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-Link
DWS4062 eingesetzt. Die Konfiguration folgt daher zentral über den Wireless Switch. Alle
Access Points müssen dem Management VLAN (VLAN<10>) zugewiesen werden und mit
einer 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 und
nicht 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-Protokoll
freigegeben 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 mit
dem Network Policy Server (NPS) eingegangen. Die Beschreibung der Konfiguration bezieht
sich dabei auf Server 2008 und Server 2008 R2.
Für NPS wird Windows Server 2008 Standard, Enterprise oder Datacenter benötigt. Bei
der 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 keine
Einschrä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 Active
Directory 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. Dazu
den NPS auswählen und unter „Action“ auf „Register server in Active Directory“ klicken. Um
sicher 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ültiges

Server-Zertifikat auf dem RADIUS-Server benötigt, welches zur Serveridentifikation dient. Das
Zertifikat muss von der Zertifizierungsstelle der Hochschule ausgestellt und signiert werden.
Anschließend muss das Zertifikat zusammen mit der zur Prüfung benötigten Zertifikatskette
im Zertifikatsspeicher auf dem Server abgelegt werden.
Im Fall der HSU wird das Zertifikat von der Zertifizierungsstelle der HSU, welche durch die PKI
des 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 von
Bedeutung sind, eingegangen. Die Konfiguration erfolgt über den Server-Manger. Alle nicht
erwähnten Einstellungen verbleiben auf Standard.
Weitere Informationen zur Konfiguration können im Microsoft TechNet nachgelesen werden

[TecNPS].

6. Umsetzung 81
RADIUS-Clients
Alle RADUS-Clients, die Authentifizierungsanfragen (Access-Requests) an den RADIUS-Server

schicken dürfen, müssen im NPS als RADIUS-Client eingetragen werden. Als RADIUS-Client
kö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, muss
als 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 alle
RADIUS-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 ein
eigenes Shared Secret verwendet werden.
Alle weiteren Einstellungen verbleiben auf Standard.
Remote RADIUS Server Groups
Externe Authentifizierungsanfragen, die nicht vom RADIUS-Server selber authentifiziert werden

können, müssen an den RadSecProxy weitergeleitet werden. Dazu muss der RadSecProxy als
Remote 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 zusammengefasst
werden. 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 authentifiziert

werden oder weitergeleitet werden, bzw. mit welchem Verfahren die interne Authentifizierung
durchgefü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 Policies

Die „Connection Request Policies“ geben an, in welchem Fall eine Authentifizierung vom Server
selbst 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 alle
Authentifizierungsanfragen von Angehörigen der HSU (Realm „@hs-ulm.de“) vom Server lokal
authentifiziert werden. Anfragen von Gästen (mit anderen Realms) werden stattdessen für
eine externe Authentifizierung an den RadSecProxy weitergeleitet.
Es kann auch noch eine dritte Policy erstellt werden, welche für alle anderen Anfragen (Anfragen
ohne Realm) in Kraft tritt (Fallback-Policy). Somit können Angehörige der HSU, die ihren
Benutzernamen ohne Realm eingegeben haben, auch ohne authentifiziert werden. Der Zugriff
auf eduroam an anderen Institutionen funktioniert allerdings nur mit angegebenem Realm.
Nur dann können Authentifizierungsanfragen der richtigen Institution zugeordnet werden. Um
eduroam auch an anderen Institutionen nutzen zu können, muss der Benutzername immer
mit Realm („[email protected]“) angeben werden. Für die Vermeidung von Fehleingaben darf
Policy 3 nicht erstellt werden. Somit werden dann alle Authentifizierungsanfragen ohne Realm
generell abgelehnt und der Benutzer ist „gezwungen“ einen Realm anzugeben, um erfolgreich
authentifiziert 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 „User
name“ 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 weitergeleitet

werden (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 RadSecProxy
weiterzuleiten (Policy 2)
• Alle weiteren Einstellungen verbleiben auf Standard.
Network Policies
Die „Network Policies“ werden für die lokale Authentifizierung benötigt und geben an, welches
Authentifizierungsverfahren 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önnen
bestimmte Bedingungen zugewiesen werden. Wenn eine bestimmte Bedingung erfüllt ist, tritt
die jeweilige Policy in Kraft. Als Bedingung kann z. B. „User Groups“ gewählt werden. Hier
können dann Benutzergruppen aus dem Active Directory angegeben werden, für die die Policy
in 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öglich
mit 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 vorgenommen
werden. 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ür
Angehö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 Gruppe
den Zugriff auf das WLAN zu ermöglichen
• Als Authentifizierungsmethode wird unter „EAP Types“ „Microsoft: Protected

EAP (PEAP)“ gewählt. Alle anderen Authentifizierungsmethoden („Less secure
authentication methods“) müssen deaktiviert werden. In den Optionen von PEAP
(erreichbar über „Edit...“) muss das auf dem Server hinterlegte Zertifikat ausgewählt
werden. 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 mitgeteilt
werden, welche RADIUS-Attribute gesetzt werden sollen. Die RADIUS-Attribute werden dann
vom 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 erweitert
werden, damit dem Access-Accept-Paket bei der Authentifizierung von Angehörigen die
entsprechenden RADIUS-Attribute für die VLAN Zuweisung angehängt werden.
In den Einstellungen der Policy auf dem Tab „Settings“ müssen unter „RADIUS Attributes
Standard“ die angegebenen Attribute hinzugefügt werden.

6. Umsetzung 86
VLAN-Tagging RADIUS-Attribute:
• Tunnel-Medium-Type
Wert: 802 (Includes all 802 media plus Ethernet canonical format)
• Tunnel-Pvt-Group-ID
Als Wert wird die VLAN-ID für Angehörige der HSU angegeben. (VLAN<40>)
• Tunnel-Type
Wert: 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 VLAN
zu 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 vorgenommen
werden. 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: Protected

EAP (PEAP)“ gewählt. Alle anderen Authentifizierungsmethoden („Less secure
authentication methods“) müssen deaktiviert werden. In den Optionen von PEAP
(erreichbar über „Edit...“) muss das auf dem Server hinterlegte Zertifikat ausgewählt
werden. 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-Protokoll
statt. Hierzu wird ein RADIUS-Proxy benötigt, welcher das RadSec-Protokoll unterstützt.
UNINETT bietet dafür den kostenlosen „radsecproxy“ an, welcher RADIUS-Pakete entgegen
nimmt 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 Entwicklungsumgebung
mit C-Library und C-Compiler (z. B. libc und GCC) benötigt. GCC und libc sind auf den
meisten UNIX basierten Systemen standardmäßig installiert. Weiterhin muss OpenSSL mit
zugehörigen Header-Files installiert sein. Unter Ubuntu 10.10, welches hier als Testplattform
verwendet wird, muss dazu die „libssl-dev“ über den Paketmanager installiert werden. Um
den Source-Code zu kompilieren und zu installieren, muss der radsecproxy zunächst entpackt
werden. Anschließend in das entpackte Verzeichnis wechseln und folgende Befehle im Terminal
eingeben:
./configure
make
make install
Wenn es zu keiner Fehlermeldung kommt, ist der radsecproxy jetzt installiert. Bevor er gestartet
werden 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 alle
Einstellungen und Informationen, welche zur Ausführung benötigt werden. Sie besteht aus
mehreren 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 Logdatei
festgelegt. 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 Zertifikat
mit zugehörigem persönlichen Schlüssel angegeben. Beide werden für die TLS-Verschlüsselung
benötigt. Das Zertifikat muss zuvor über die PKI des DFN erstellt werden und an dem in der
Konfigurationsdatei angegebenen Pfad hinterlegt werden. Weiterhin wird auch noch der Pfad
der zugehörigen Zertifikatskette angeben, welche von der PKI des DFN als *.txt Datei zur
Verfü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-Attribute
hinzuzufügen, zu entfernen oder zu modifizieren. Wenn dynamisches VLAN-Tagging verwendet
wird, 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 die
interne VLAN-Zuweisung benötigt. Im Rewrite Block kann angegeben werden, dass in allen
Paketen, die auf dem radsecproxy eintreffen, die RADIUS-Attribute für das VLAN-Tagging
entfernt werden.
Client Block: Hier werden alle Clients angegeben, die RADIUS-Anfragen an den radsecproxy
schicken, 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 Anfragen
weiterleiten 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 Realm
ist in Form eines regulären Ausdrucks angegeben. Alle anderen Anfragen von unbekannten
Realms werden an die DFN Top-Level RADIUS-Server weitergeleitet.
Die erstelle Konfigurationsdatei kann bei der Ausführung des radsecproxy auf syntaktische
Korrektheit 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 Parameter
gestartet werden und seine Arbeit aufnehmen.

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:
./configure
make
make 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 an
der Heimateinrichtung vorgenommen werden. Nach der Konfiguration erfolgt die Verbindung
automatisch, sobald sich das WLAN „eduroam“ in Reichweite befindet. Eine Verbindung zum
WLAN „eduroam“ kann dann an allen Einrichtungen, die an eduroam teilnehmen, aufgebaut
werden, ohne eine weitere Konfiguration durchführen zu müssen.

6. Umsetzung 91
Für die Konfiguration muss unterschieden werden, ob sich ein Gast oder ein Angehöriger
der HSU mit dem WLAN der HSU verbinden möchte. Bei Gästen muss die Konfiguration
immer nach den Vorgaben der Institution erfolgen, von welcher der Gast stammt, da die
Authentifizierung 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. Es

wird 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 die
Zertifikatskette) 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

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, die
auf den einzelnen Geräten eingestellt werden müssen. Je nach Gerät und Betriebssystem weicht
die Konfiguration ab und die Einstellungen werden teilweise unter anderen Bezeichnungen
aufgefü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 (Snow
Leopard) beschrieben. Hierbei gibt es zwei Möglichkeiten, die automatische und die manuelle
Konfiguration.

6. Umsetzung 93
Automatische Konfiguration
Bei Windows 7 und Mac OS X 10.6 reicht es aus, das WLAN „eduroam“ auszuwählen und im
anschließend aufgehenden Fenster seinen Benutzernamen ([email protected]) und sein Passwort
einzugeben. Danach muss noch das Serverzertifikat bestätigt werden. Der Client wählt dann
automatisch 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 der
Identitätsschutz wird nicht automatisch aktiviert. Daher ist die manuelle Konfiguration der
automatischen 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 Root

CA 2“ auswählen
11. Als „Authentifizierungsmethode“ „Gesichertes Kennwort (EAP-MSCHAP

v2)“ 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 Kennwort

verwenden“ 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 den
Anmeldeinformationen:
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 Windows
XP, Windows Vista, und Windows 7 kann dazu der „c’t WLAN-Kloner“ oder das „SU1X
802.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; alle
weiteren 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-Server
zugewiesen. 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 Client
keine IP-Adresse zugewiesen wird, muss überprüft werden, ob der Client richtig konfiguriert
ist und seine IP-Einstellungen per DHCP bezieht.
Eine nicht erfolgreiche Authentifizierung kann sich unterschiedlich äußern. Im einfachsten Fall
erscheint eine Meldung mit entsprechender Information, dass die Authentifizierung fehlgeschla-
gen ist. Es ist auch möglich, dass das Fenster zum Eingeben der Benutzerinformationen immer
wieder eingeblendet wird, obwohl die richtigen Daten eingegeben wurden. Darüber hinaus
kann der Eindruck entstehen, als wäre die Authentifizierung erfolgreich verlaufen. Allerdings
bekommt der Client dann keine IP-Adresse zugewiesen, obwohl die IP-Einstellungen korrekt
sind.

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 RadSecProxy
Wie 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 dem
Client 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 Vorgaben
dessen 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 DFN
bezogen 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 dieser
Einrichtung 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 und
AES-CCMP-Verschlüsselung zurecht kommt.

7. Bewertung 98
7. Bewertung
Die Umstellung der WLAN-Infrastruktur auf die 802.1X Authentifizierung und die Anbindung
an das DFNRoaming/eduroam erfüllt im Wesentlichen alle unter Kapitel 3 auf Seite 32
aufgeführten Anforderungen.
7.1. Funktionale Anforderungen

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

FA1 hoch (10) 100% 10
FA2 hoch (10) 100% 10
FA3 mittel (7) 100% 7
FA4 hoch (10) 100% 10
FA5 mittel (7) 100% 7
Summe 44
Tabelle 7.1.: Pugh-Matrix Funktionale Anforderungen
7.2. Nichtfunktionale Anforderungen

NF1 Kompatibilität
Diese 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äte
zusätzlich WPA2-Enterprise mit AES-CCMP-Verschlüsselung unterstützen müssen, um
sich mit dem eduroam-WLAN an der Hochschule Ulm verbinden zu können. Andernfalls
ist keine Verbindung möglich.
Durch Aktivieren von WPA-Enterprise mit TKIP-Verschlüsselung auf den Access
Points kann die Kompatibilität auf 95% erhöht werden. Allerdings müssen dann geringe
Abstriche bei der Sicherheit gemacht werden, da TKIP auf dem unsicheren RC4-
Verschlüsselungsverfahren basiert. Ein Erfüllungsgrad von 100% ist nicht erreichbar, da
auch 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 Bedienung
Wenn 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 einmalig
vorzunehmende Konfiguration dar. Diese muss je nach Gerät vom Anwender selbst
vorgenommen werden. Hierfür wird auf den meisten Geräten aber keine Zusatzsoftware
benötigt, da die 802.1X Authentifizierung mittels EAP-PEAP/EAP-MS-CHAPv2 im
Normalfall standardmäßig unterstützt wird. Nach eimaliger Konfiguration verbindet
sich ein WLAN-Client immer automatisch mit dem WLAN „eduroam“, sobald es in
Reichweite 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 Sicherheit
Diese Anforderung ist komplett erfüllt und erreicht einen Erfüllungsgrad von 100%.
Die per Funk übertragenen Daten werden durch WPA2-Enterprise mittels AES-CCMP
verschlüsselt. Auch können durch die 802.1X Authentifizierung nur berechtigte Personen
auf das WLAN zugreifen. Das entspricht den gängigen Sicherheitsstandards voll und
ganz.
Durch das Aktivieren der Funktion Client Isolation auf den Access Points kann die
Sicherheit unter den WLAN-Clients noch weiter erhöht werden ( 4.3.4 auf Seite 50).
NF4 Datenschutz
Durch den Einsatz des RadSec-Protokolls auf WAN-Strecken und der Aktivierung des
Identitätsschutzes wird auch der Datenschutz erfüllt. Die Identität des Nutzers kann
so nicht mehr von anderen mitgelesen werden. Nur bei dem RADIUS-Server, welcher
einen Nutzer authentifiziert, steht die Identität in der Logdatei. Diese Einträge dürfen
dabei 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. Windows
XP und Windows Vista) gibt, welche den Identitätsschutz nicht unterstützen. Beim
Einsatz eines solchen Clients wird die Identität des Nutzers weiterhin im Klartext in
einem RADIUS-Paket übertragen und kann von allen beteiligten Instanzen mitgelesen
werden. Das Abfangen von RADIUS-Pakten ist auf WAN-Strecken aber nicht möglich, da
hier das RadSec-Protokoll eingesetzt wird und RADIUS-Pakete verschlüsselt innerhalb
eines TLS-Tunnels übertragen werden.
NF5 Performance
Durch die Performancemessung unter Laborbedingungen konnte gezeigt werden, dass
sich an einem Access Point bis zu 80 WLAN-Clients bei einer mittleren Auslastung von
30% anmelden können und dabei noch ausreichende Datenraten erhalten. Das führt zu
einem 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 Access
Point 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 erst
ein paar Access Points im Testbetrieb befinden. Erst später, im praktischen Einsatz
wird sich zeigen, wie zuverlässig die einzelnen Access Points sind und inwieweit andere
Access Points einen ausgefallenen Access Point ersetzen können.
Anforderung Priorität Erfüllungsgrad Bewertung

NF1 Kompatibilität hoch (10) 85% 8,5
NF2 Bedienung hoch (10) 90% 9
NF3 Sicherheit hoch (10) 100% 10
NF4 Datenschutz mittel (7) 90% 6,3
NF5 Performance mittel (7) 100% 7
NF6 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 44
maximal möglichen Punkten. Das entspricht einem Erfüllungsgrad von 93% in der Summe
und 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 hohem
Sicherheitsstandard. Den Nutzern wird ein sicherer und bedienungsfreundlicher WLAN-Zugang
geboten. Durch das DFNRoaming/eduroam sind die Nutzer nicht nur an einen WLAN-Standort
gebunden, 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, das
WLAN 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 mit
unterschiedlichen Rechten im WLAN einzuteilen. Durch den RADIUS-Server wird jeder Grup-
pe jeweils ein eigenes VLAN zugewiesen. Anhand des VLANs können dann unterschiedliche
Rechte im Intranet vergeben werden. Es wäre denkbar, für Mitarbeiter und Studenten jeweils
eine eigene Gruppe mit eigenem VLAN einzuführen. Mitarbeiter können dann weitere Rechte
im 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 und
zu beheben.
Als nächster Schritt kann auch das vorhandene LAN mit an die 802.1X Authentifizierung
angebunden werden. Dadurch sind alle Ethernet-Ports geschützt und erst nach erfolgreicher
Authentifizierung 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-Adressen
leicht manipuliert werden können. Durch die Umstellung auf die 802.1X Authentifizierung
können die Ethernet-Ports ähnlich flexibel genutzt werden wie das WLAN. Auch hier ist eine
Anbindung an das DFNRoaming/eduroam möglich.
In Zukunft ist auch eine Umstellung der LAN- und WLAN-Infrastrukturen in Wohnheimen auf
die 802.1X Authentifizierung und die Anbindung an das DFNRoaming/eduroam denkbar. Das
hat den Vorteil, dass sich Studenten auch in den Wohnheimen mit ihren Hochschul-Accounts
am 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 irgendwann
alle Hochschulen und wissenschaftlichen Einrichtungen weltweit an eduroam angebunden sind.

Abbildungsverzeichnis viii
Abbildungsverzeichnis
2.1. 802.1X-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. 802.1X-Ports [Str04] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. EAP-Paket [Hof05, S. 85]; [RFC3748, S. 22] . . . . . . . . . . . . . . . . . . . 11
2.4. EAP-TTLS Aufbau [RFC5281, S. 12] . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. EAP-PEAP Aufbau [PEAPDraft, S. 27] . . . . . . . . . . . . . . . . . . . . . 15
2.6. CHAP Authentifizierung [EleCHAP] . . . . . . . . . . . . . . . . . . . . . . . 16
2.7. MS-CHAPv2 Authentifizierung [EleCHAPv2; TecCHAPv2] . . . . . . . . . . 17
2.8. EAPOL-Frame [Rec08, S. 460] . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9. RADIUS-Paket [Hof05, S. 96] . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.10. Schichtenmodell der Protokolle bei der 802.1X Authentifizierung . . . . . . . 24
2.11. Ablauf der 802.1X Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 25
2.12. Schlüsselhierarchie der paarweisen Schlüssel [Rec08, S. 469] . . . . . . . . . . 27
2.13. Schlüsselhierarchie der Gruppenschlüssel [Rec08, S. 469] . . . . . . . . . . . . 28
2.14. Schlüsselaushandlung (Handshake) [Rec08, S. 472] . . . . . . . . . . . . . . . 28
3.1. Anwendungsfalldiagramm „Mit WLAN verbinden“ . . . . . . . . . . . . . . . 32
4.1. Architektur der WLAN-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . 42

4.2. RADIUS-Access-Request-Paket ohne Identitätsschutz . . . . . . . . . . . . . . 52
4.3. Detaillierte Architektur der WLAN-Infrastruktur . . . . . . . . . . . . . . . . 55
5.1. Laboraufbau für Performancemessung . . . . . . . . . . . . . . . . . . . . . . 62

5.2. Datenrate WLAN-Clients (802.11g) . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3. Datenrate mehrerer WLAN-Clients (802.11n) . . . . . . . . . . . . . . . . . . 72
6.1. Authentifizierungsmethode wählen . . . . . . . . . . . . . . . . . . . . . . . . 85

6.2. RADIUS-Attribute für VLAN-Tagging . . . . . . . . . . . . . . . . . . . . . . 86
6.3. Authentifizierungsmethode wählen für Identitätsschutz . . . . . . . . . . . . 87
6.4. Windows 7 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.5. Mac OS X 10.6 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Tabellenverzeichnis ix
Tabellenverzeichnis
2.1. WLAN Standards Überblick [Ele11b] . . . . . . . . . . . . . . . . . . . . . . . 4

2.2. WLAN-Verschlüsselungsvarianten . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. EAP-Typen [RFC3748, S. 27]; [Rec08, S. 459]; [Hof05, S. 85] . . . . . . . . . . 12
3.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2. Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1. Pugh-Matrix Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 47

4.2. Pugh-Matrix Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . 48
5.1. Datenrate Iperf-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2. Datenrate WLAN-Client (802.11g) . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3. Datenrate MacBook (802.11n) . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4. Datenrate HP-Laptop (802.11n) . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5. Datenrate mehrerer WLAN-Clients (802.11g) . . . . . . . . . . . . . . . . . . 70
5.6. Datenrate mehrerer WLAN-Clients (802.11n) . . . . . . . . . . . . . . . . . . 72
5.7. Datenrate Mischbetrieb mit 5 g-Geräten und 3 n-Geräten . . . . . . . . . . . 73
7.1. Pugh-Matrix Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 98

7.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 Zeitschriften
Verlag, 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 For
Extensible 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).

Literaturverzeichnis xi
[RFC5281] PAUL FUNK und SIMON BLAKE-WILSON: Extensible Authenticati-

on Protocol Tunneled Transport Layer Security Authenticated Protocol
Version 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-TLS
Authentication Protocol. RFC 5216. Internet Engineering Task Force,
März 2008. url: http : / / datatracker . ietf . org / doc / rfc5216/
[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://datatracke
r.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.p
df (letzter Abruf: 24. 05. 2011).
[DWL8600] Datenblatt D-Link DWL-8600AP. D-Link, Jan. 2011. url: ftp://ft
p.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.ie
ee.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.ie
ee.org/about/get/802/802.1.html (letzter Abruf: 24. 05. 2011).

Literaturverzeichnis xii
[Ayr] GARETH AYRES: Use of eduroam as the Single Primary SSID at

Swansea University. janet. url: http://www.ja.net/documents/ser
vices/janet-roaming/swansea-eduroam-single-ssid.pdf (letzter
Abruf: 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/dr
ahtloskom/index_htm.html (letzter Abruf: 25. 05. 2011).
[eduCoo08] S. WINTER, T. KERSTING und P. DEKKERS: Inter-NREN Roaming
Infrastructure 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-p
art-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-e
ap-10.txt (letzter Abruf: 24. 05. 2011).
[RadSec05] RadSec a secure, reliable RADIUS Protocol. Open System Consultants
Pty. Ltd., Mai 2005. url: www.open.com.au/radiator/radsec-whit
epaper.pdf (letzter Abruf: 24. 05. 2011).
[radsecDoc] Documentation for radsecproxy 1.4. UNINETT. url: http : / / so
ftware . 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://datatra
cker.ietf.org/doc/draft- ietf- radext- radsec/ (letzter Abruf:
24. 05. 2011).

Literaturverzeichnis xiii
Webseiten
[TecCHAPv2] MS-CHAP v2. Microsoft TechNet. url: http : / / technet . micros
oft . 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.1
0).aspx (letzter Abruf: 24. 05. 2011).
[TecFacts] NPS Fast Facts. Microsoft TechNet, Feb. 2009. url: http://techne
t.microsoft.com/de-de/library/cc753255(WS.10).aspx (letzter
Abruf: 24. 05. 2011).
[DFN10] JOCHEM PATTLOCH: Das Wissenschaftsnetz X-WiN. Deutsches
Forschungsnetz, Oktober 2010. url: http : / / www . dfn . de / xwin/
[DFN11a] JOCHEM PATTLOCH: DFNRoaming/eduroam. Deutsches Forschungs-
netz, Jan. 2011. url: http://www.dfn.de/dienstleistungen/dfnr
oaming/ (letzter Abruf: 24. 05. 2011).
[DFN11b] JOCHEM PATTLOCH: DFN-Verein. Deutsches Forschungsnetz, März
2011. 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/
[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.o
rg/ (letzter Abruf: 24. 05. 2011).
[Ele11b] PATRICK SCHNABEL: IEEE 802.11b / WLAN mit 11 MBit. Elek-
tronik Kompendium. url: http://www.elektronik-kompendium.d
e/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-kompendiu
m.de/sites/net/1102071.htm (letzter Abruf: 24. 05. 2011).

Literaturverzeichnis xiv
[EleCHAP] PATRICK SCHNABEL: CHAP - Challenge Handshake Authentication

Protocol. Elektronik Kompendium. url: http://www.elektronik-ko
mpendium.de/sites/net/0906171.htm (letzter Abruf: 24. 05. 2011).
[EleCHAPv2] PATRICK SCHNABEL: MS-CHAP - Microsoft CHAP. Elektronik
Kompendium. url: http://www.elektronik-kompendium.de/site
s/net/0906181.htm (letzter Abruf: 24. 05. 2011).
[Str04] LARS STRAND: 802.1X Port-Based Authentication HOWTO. Linux
Documentation 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).

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 Code
Protocol
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. radsecproxy
Konfigurationsvorlage
Listing A.1: radsecproy configuration template

1 # #####
2 # Configuration template for radsecproxy version 1.4.2
3 # This configuration template can be used to connect
radsecproxy to DFNRoaming / eduroam .
4 # Save the configuration file in path : / etc / radsecproxy .
conf
5 # File is based on examples of DFN :
6 # http :// www . dfn . de / fileadmin /1 Dienstleistungen / Roaming /
Einrichtung_von_radsecproxy . pdf
7 #
8 # radsecproxy documentation :
9 # http :// software . uninett . no / radsecproxy / index . php ? page =
documentation
10 #
11 # Date : May 2011
12 # Author : Raphael Heinlein
13 # #####
14
15 # #####
16 # Basic Block
17 #
18 # Listen on ports 1812 and 1813 for RADIUS - Packets of
internal RADIUS - Server .
19 # Port 1812 for RADIUS - Requests
20 # Port 1813 for RADIUS - Accounting
21 #

A. radsecproxy Konfigurationsvorlage xix
22 # Enter IP adress of network interface which is

connected to internal RADIUS - Server .
23
24 listenUDP 127.0.0.1:1812
25 listenUDP 127.0.0.1:1813
26
27 # 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 .
32
33 listenTLS 192.168.0.1:2083
34
35 # Log file settings :
36 # - set LogLevel (1 -5)
37 # - set LogDestination ( path of log file )
38
39 LogLevel 3
40 LogDestination file :/// var / log / radsecproxy . log
41
42 # 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 On
46 #
47 # #####
48
49 # #####
50 # TLS Block
51 # For all TLS encrypted connections the following
certificates will be used .

A. radsecproxy Konfigurationsvorlage xx
52
53 tls default {
54 # Path for the certificate chain stored on the
server .
55 # You can get the certificate chain from your
PKI ( DFN PKI ) .
56
57 CACertificateFile / etc / radsec / certs / dfn - pki -
chain . txt
58
59 # Path for the X .509 certificate stored on the
server .
60 # Path for the private key of the certificate .
61
62 CertificateFile / etc / radsec / certs / cert . pem
63 CertificateKeyFile / etc / radsec / certs / key . pem
64
65 # In case of an encrypted private key , enter
passwort here .
66 # CertificateKeyPassword " passwort "
67 }
68 #
69 # #####
70
71 # #####
72 # Rewrite Block
73 # 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 .
79
80 rewrite default {
81

A. radsecproxy Konfigurationsvorlage xxi
82 # remove attribute for Tunnel - Type

83 removeAttribute 64
84
85 # remove attribute for Tunnel - Medium - Type
87
88 # remove attribute for Tunnel - Private - Group - ID
90 }
91 #
92 # #####
93
94 # #####
95 # Client Block
96 # All clients which send requests to the radsecproxy :
97 # - internal RADIUS - Server
98 # - the two DFN Top - Level RADIUS - Proxys
99
100 # internal RADIUS - Server
101 client radius - server {
102 host # enter IP of RADIUS - Server
103 type udp
104 secret # enter secret here
105 }
106
107 # DFN Top - Level RADIUS - Proxys
108 client radius1 . dfn . de {
109 host radius1 . dfn . de
110 type TLS
111
112 # 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 off
115 matchCertificateAttribute CN :/^ radius1 \. dfn \. de$
/

A. radsecproxy Konfigurationsvorlage xxii
116
117 }
118 client radius2 . dfn . de {
120 type TLS
121
/
124 }
125 #
126 # #####
127
128 # #####
129 # Server Block
130 # All servers to which radsecproxy forwards requests :
131 # - internal RADIUS - Server
132 # - the two DFN Top - Level RADIUS - Proxys
133
134 # internal RADIUS - Server
135 # RADIUS - Requests
136 server radius - server {
138 port 1812
139 type udp
141 }
142 # RADIUS - Accounting
143 server radius - server - accounting {
145 port 1813
146 type udp
148 }
149
150 # DFN Top - Level RADIUS - Proxy

A. radsecproxy Konfigurationsvorlage xxiii
151 # With " statusServer on " the radsecproxy proofs the

connection to the DFN - RADIUS - Proxy during idle .
152
153 server radius1 . dfn . de {
155 type tls
156 statusServer on
157
/
160
161 }
162
163 server radius2 . dfn . de {
165 type tls
166 statusServer on
167
/
170
171 }
172 #
173 # #####
174
175 # #####
176 # Realm Block
177 # 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 - server
184 accountingServer radius - server - accounting
185 }
186
187 realm * {
188 server radius1 . dfn . de
189 server radius2 . dfn . de
190 accountingServer radius1 . dfn . de
191 accountingServer radius2 . dfn . de
192 }
193
194 #
195 # #####

Bachelor-Thesis Technisches Sicherheitskonzept Für Das WLAN-Funknetz Der Hochschule Ulm

Hochgeladen von

Copyright:

Verfügbare Formate

Bachelor-Thesis Technisches Sicherheitskonzept Für Das WLAN-Funknetz Der Hochschule Ulm

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Bachelor-Thesis Technisches Sicherheitskonzept Für Das WLAN-Funknetz Der Hochschule Ulm

Hochgeladen von

Copyright:

Verfügbare Formate

Bachelor-Thesis

Technisches Sicherheitskonzept für das

1. Gutachter: Prof. Dr. Markus Schäﬀter

2. Gutachter: Prof. Dr. Stefan Traub

Ulm, 31. Mai 2011

Raphael Heinlein Hochschule Ulm

Raphael Heinlein Hochschule Ulm

Raphael Heinlein Hochschule Ulm

Raphael Heinlein Hochschule Ulm

Raphael Heinlein Hochschule Ulm

8. Zusammenfassung und Ausblick 101

A. radsecproxy Konfigurationsvorlage xviii

Raphael Heinlein Hochschule Ulm

Raphael Heinlein Hochschule Ulm

1.4. Aufbau der Arbeit

Raphael Heinlein Hochschule Ulm

2.1. Wireless LAN

2.1.1. IEEE 802.11

Um höhere Datenraten zu erreichen, wurde der 802.11-Grundzustand erweitert und modifiziert.

Raphael Heinlein Hochschule Ulm

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

Standard Datenrate (brutto) Datenrate (netto) Frequenzband

Tabelle 2.1.: WLAN Standards Überblick [Ele11b]

Raphael Heinlein Hochschule Ulm

Breite überlappen. Um einen störungsfreien Betrieb zu ermöglichen, sollte zwischen zwei

2.1.2. IEEE 802.11i

Im WLAN Grundstandard 802.11 sind bereits Sicherheitsmechanismen integriert, um den

Raphael Heinlein Hochschule Ulm

Raphael Heinlein Hochschule Ulm

2.1.3. WPA und WPA2

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

Verschlüsselungsvariante WEP WPA WPA2

Tabelle 2.2.: WLAN-Verschlüsselungsvarianten

2.2. IEEE 802.1X

Raphael Heinlein Hochschule Ulm

Abbildung 2.1.: 802.1X-Modell

Raphael Heinlein Hochschule Ulm

In Abbildung 2.2 sind die Ports schematisch dargestellt.

Abbildung 2.2.: 802.1X-Ports [Str04]

Raphael Heinlein Hochschule Ulm

Raphael Heinlein Hochschule Ulm

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

Datenfeld (nur bei EAP-Request- und EAP-Response-Paketen)

Raphael Heinlein Hochschule Ulm

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

Raphael Heinlein Hochschule Ulm

Raphael Heinlein Hochschule Ulm

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

EAP-PEAP (EAP-Protected Extensible Authentication Protocol) entspricht auch einer erwei-

Raphael Heinlein Hochschule Ulm

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

Raphael Heinlein Hochschule Ulm

MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) ist eine

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,

Raphael Heinlein Hochschule Ulm

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

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