Keine News in dieser Ansicht.

1. Was muss ich tun, damit mein WLAN dienstkonform ist?
2. Was ist die Migrationslösung?
3. Was bedeutet CASG?
4. Was ist der Unterschied zwischen DFNRoaming und eduroam?
5. Wie sieht das Betriebskonzept aus?
6. Was ist 802.1X?
7. Was ist EAP?
8. Was ist ein Nutzerverzeichnis?
9. Was ist das DFN-Toplevel-Verzeichnis?
10. Wie wird ein Nutzerverzeichnis in den Dienst integriert?
11. Welche Bedingungen muss ein Endgerät erfüllen, um DFNRoaming benutzen zu können?
12. Wie authentifiziert man einen Zugangspunkt eines Nutzers?
13. Wie ist der Vorgang der Authentifizierung technisch realisiert?
14. Wie muss ein RADIUS-Server als Nutzerverzeichnis konfiguriert sein?
15. Kann ein vorhandenes LDAP-Verzeichnis in das Authentifizierungsmodell integriert werden?
16. Sind Änderungen an der Firewall nötig?
17. Welche Art von Kennungen sollen vergeben werden?
18. Was müssen DFNRoaming Nutzer eingeben, um sich zu authentifizieren?
19. Können Kennungen während des Authentifizierungsvorgangs abgehört werden?
20. Ist die Datenübertragung auf der Funkverbindung abhörsicher?
21. Wie kann verschiedenen Nutzergruppen unterschiedliche Zugangsberechtigungen zum Netzwerk gegeben werden?
22. Wie wird der Supplikant SecureW2 für 802.1X EAP/TTLS konfiguriert?

Die Zugangspunkte müssen so konfiguriert werden, dass sie Kennungen von Nutzern durch Nutzerverzeichnisse prüfen lassen. Um die Prüfung von Nutzerkennungen zu ermöglichen, ist im Rahmen der Migrationslösung (s. u.) eine Web-basierte Authentifizierung und zum Ende der Migration, eine 802.1X-basierte Authentifizierung zu gewährleisten. Die heute vielfach durchgeführte Prüfung anhand von Tabellen, die im Zugangspunkt selbst geführt werden, entfällt. 

Im Rahmen des Piloten hat sich gezeigt, dass vielerorts die Endgeräte bzw. die Accesspoints den IEEE 802.1X Standard nicht unterstützen oder in der Einrichtung eine VPN-basierte Authentifizierung eingesetzt wird. Daher ist im Pilotbetrieb eine Migrationslösung entwickelt worden. Die Einrichtung ist in der Lage mithilfe der Migrationslösung, parallel zu einer bereits bestehenden Lösung, eine Web-basierte Authentifizierung zu ermöglichen. Für den Nutzer muss die Authentifizierung transparent sein und darf nicht die Installation (außer einem WWW Standardbrowser) von neuer Soft- bzw. Hardware nach sich ziehen. Die Migrationslösung ist von Vorteil, weil:

• die "vorhandene" Radiusinfrastruktur weiterhin genutzt werden kann,
• VPN-basierte Lösungen parallel zum bestehendem Betrieb verwendet werden können,
• die Accesspoints parallel zum Betrieb und sukzessive durch 802.1X-fähige Accesspoints ausgetauscht werden können.

Als brauchbar hat sich die freie, web-basierte Zugangssoftware von der University of Technology in Tampere, Finnland erwiesen. Diese Software ist unter folgendem Link zu beziehen:

Tino

Für das VPN-basierte Roaming ist der Zugang zum VPN-Gateway im Heimatnetz Voraussetzung. Als Lösung ist ein Vorschlag namens CASG (Controlled Address Space for Gateways) in der Diskussion, der das Skalierungsproblem entschärfen soll. Er ermöglicht, aus einem besuchten Zugangsnetz heraus transparent auf die Gateways der anderen Institutionen und damit auch auf jene auf dem eigenen Campus zuzugreifen, ohne die Gateways einzeln in die Zugangs-Listen aufnehmen zu müssen. Im Rahmen von DFNRoaming ist man diesem Ansatz gefolgt und hat zusätzlich einen Adressraum (193.174.167.0/24) für VPN-Gateways definiert.

Sobald der CASG (Adressbereich:193.174.167.0/24) auf den Routern bzw. Firewalls der am DFNRoaming teilnehmenden gastgebenden Einrichtungen freigegeben wird, ist ein VPN-Client in der Lage eine transparente Verbindung zu seinem VPN-Gateway (in der Heimateinrichtung), welches sich im CASG befindet muss, aufzubauen. Der VPN-Client bekommt bei erfolgreicher Authentifizierung eine IP-Adresse aus seiner Heimateinrichtung und ist mit dieser, ihm zugeteilten Adresse, auch im X-WiN sichtbar.

CASG-Adressen gibt es auf Anfrage von der DFN-Geschäftstelle in Berlin

Im Rahmen von DFNRoaming werden zur Zeit 3 Authentisierungsmethoden angeboten:

1. Die Web-basierte Authentisierung, die in der Regel über ein Captive Portal realisiert wird.
2. Die VPN-baisierte Authentisierung, die im Zusammenhang mit CASG (s. FAQ 3.) realisiert wird.
3. Die 802.1X-basierte Authentisierung.

eduroam ist ein Bestandteil von DFNRoaming. In eduroam kommt ausschließlich die 802.1X-basierte  Authentisierung zum Einsatz, die auch im Rahmen einer Internationalisierung des Roaming-Dienstes Verwendung findet. Bitte achten Sie bei der Erstellung von etwaigen Anleitungen darauf, dass der Begriff eduroam ausschließlich im Zusammenhang mit einer 802.1X-basierten Authentisierung verwendet wird.

Erläuterung zur Abbildung: Jeder Anwender pflegt ein Nutzerverzeichnis seiner registrierten Nutzer. Die registrierten Nutzer werden in der Regel eine Teilmenge der Nutzer sein, denen der Anwender Zugang zu seinem eigenen WLAN gewährt.

Ein registrierter Nutzer bekomt Zugang zum X-WiN (gestrichelter Pfeil), wenn er am Zugangspunkt (ZP) eines dienstkonformen WLAN authentifiziert wird. Dies geschieht anhand seiner Kennung, die in der Regel eine Kombination aus Username/Passwort ist, aber auch ein digitales Zertifikat sein kann. 

Zur Prüfung der Kennung verwendet der Zugangpunkt das Nutzerverzeichnis des Anwenders (durchgezogener Pfeil), bei dem der Nutzer beschäftigt oder immatrikuliert ist (Heimat). Dort und nur dort ist festgelegt, ob ein Nutzer zugangsberechtigt ist oder nicht. Um das lokale Verzeichnis der Heimat des Nutzers zu finden, wird das vom DFN-Verein betriebene Verzeichnis aller Nutzerverzeichnisse (DFN-Toplevel-Verzeichnis) verwendet.

Vergleichbare Betriebskonzepte sind auch für kabelgebundene LAN denkbar und können in weiteren Ausbaustufen von DFNRoaming umgesetzt werden.

Ein Konzept für eine end-to-end Vertraulichkeit der Datenübermittlung kann unabhängig von diesem Betriebskonzept umgesetzt werden und liegt z.B. mit dem Kochrezept für Nutzung der SecureShell vor:

Anleitung zur Nutzung der SecureShell

Der Standard 802.1X definiert, wie Nutzer an einem Netzwerk authentifiziert werden können und wie Vertraulichkeit zwischen dem Endgerät eines Nutzers und dem Zugangspunkt eines Netzwerks gewährt wird.

EAP ist die Abkürzung für Extensible Authentication Protocol und ist Bestandteil des Standards 802.1X. EAP kennt verschiedene Typen zur Authentifizierung wie: TLS, TTLS, PEAP, MS-CHAPv2, MD5, CHAP oder PAP.

In einem Nutzerverzeichnis legt ein Anwender die Kennungen der registrierten Nutzer ab. Ein Nutzerverzeichnis verwendet den Standard 802.1X zur Prüfung von Kennungen und muss das RADIUS-Protokoll beherrschen. Die meisten am Markt befindlichen RADIUS-Server unterstützen 802.1X und die genannten Authentifizierungstypen des EAP.

Das DFN-Toplevel Verzeichnis ist ein Verzeichnis aller Nutzerverzeichnisse. Es leitet Anfragen nach Kennungen von Zugangspunkten an Nutzerverzeichnisse weiter. Es verwendet dazu eine Information, die aus der Kennung abzuleiten ist. Das DFN-Toplevel Verzeichnis wird technisch als RADIUS-Server realisiert.

Das Nutzerverzeichnis muss beim DFN-Toplevel Verzeichnis angemeldet werden. Dazu nimmt der Anwender Kontakt zur DFN-Geschäftsstelle auf.

Im Fall der Authentisierung gemäß IEEE 802.1X muss auf den Endgeräten der Nutzer 802.1X implementiert und konfiguriert sein. Eine entsprechende Software (Supplikant) ist häufig im Betriebssystem integriert (z. B. Windows XP/7/Mobile, Linux (Ubuntu)/Android, MacOS X). Ansonsten ist sie auf den Endgeräten zu installieren (z. B. ProSet Wireless bei Onboard Intel WLAN-Adapter). Die Administratoren in den Einrichtungen können so genannte Profile vorbereiten, mit denen die Nutzer ihre Endgeräte im Wesentlichen auf Konpfdruck konfigurieren können.

• Im Falle der 802.1X-basierten Authentifizierung erfolgt die Anmeldung des Nutzer in verschlüsselter Form. Zur Authentifizierung versendet das Endgerät über das EAP eine Anfrage an einen Zugangspunkt, der die Anfrage an ein Nutzerverzeichnis weiterleitet. Das Nutzerverzeichnis stellt die Art der Kennung fest und prüft daraufhin die Kennung des Nutzers. Wird der Nutzer erfolgreich identifiziert, so vereinbart der Zugangspunkt und das Nutzerverzeichnis einen dynamischen Schlüssel, der dann an das Endgerät des Nutzer übersendet wird. Der Funkverkehr zwischen Endgerät und Zugangspunkt ist für die Dauer der Sitzung verschlüsselt.
• Im Falle der Web-basierte Lösung ist die Authentifizierung durch ein Sicherheitsprotokoll, wie z.B. SSL abgesichert. Zur Authentifizierung versendet das Endgerät über das Web-Interface eine Anfrage an ein Nutzerverzeichnis. Das Nutzerverzeichnis überprüft die Kennung des Nutzers. Wird der Nutzer erfolgreich identifiziert so wird er auf der Firewall freigeschaltet. Der Funkverkehr nach der Authentifizierung ist unverschlüsselt, daher ist für die Übertragung sicherheitskritischer Daten (Passwörter usw.) die Verwendung von zusätzlichen Sicherheits-Tools, wie z.B. SSH erforderlich.

Der Vorgang der Authentifizierung hängt von der Art der verwendeten Authentifizierungsmethode (802.1X oder WEB-basiert) ab. Im folgenden ist beispielhaft eine Authentifizierung nach EAP-TTLS beschrieben. Mit EAP-TTLS wird für die Dauer der Authentifizierung ein verschlüsselter Tunnel aufgebaut, über den die Authentifizierung dann in zwei Phasen zwischen Endgerät und RADIUS-Server erfolgt. In der ersten Phase identifiziert sich der RADIUS-Server, indem er dem Endgerät sein Zertifikat zusendet. Das Endgerät kann so erkennen, ob es bezüglich der Identität des Netzwerks, an dem es sich anmelden will, nicht getäuscht wird. Wird das Zertifikat vom Endgerät verifiziert, dann überträgt das Endgerät in der zweiten Phase die Kennung des Nutzers zum RADIUS-Server. Der RADIUS-Server erhält sein für EAP-TTLS notwendiges Zertifikat von der DFN-PCA. Es werden keine Zertifikate vom Endgerät benötigt.

Die Konfigurierung eines RADIUS-Server hängt vom verwendeten Authentifizierungstyp ab. Für EAP-TTLS muss z. B. in den Konfigurationsdateien des RADIUS-Servers der Pfadname des Zertifikats abgelegt sein. Zusätzlich muss auch der DFN-Toplevel RADIUS-Server eingetragen werden. Ferner müssen Informationen abgelegt sein, anhand deren der RADIUS-Server erkennen kann, welche Anfragen er ohne Zugriff auf den DFN-Toplevel RADIUS-Server lokal beantworten kann.

Kennungen können sowohl auf dem RADIUS-Server in einem Verzeichnis als auch an anderer Stelle, z. B. auf einem LDAP-Server abgespeichert werden. Auf diese Weise lassen sich bestehende Strukturen wie z.B. eine bereits aufgebaute PKI in DFNRoaming integrieren.

Damit die Anfrage nach Authentifizierung eines Nutzers vom Endgerät zum betreffenden Nutzerverzeichnis gelangen kann, müssen in der Firewall u.a. die Standard-Ports 1812 (Authentifizierung), 1813 (Accounting) freigeschaltet werden. Dies kann z. B. auch über einen Proxy-Server realisiert werden. Im Rahmen des DFNRoaming Piloten werden Erfahrungen gesammelt, die Aufschluss darüber geben, welche weiteren Ports auf der Firewall geöffnet werden müssen, so dass der DFNRoaming Dienst nicht beeinträchtigt wird.

Ein Anwender von DFNRoaming kann grundsätzlich wählen, welche Art von Kennungen er zur Authentifizierung seiner Nutzer verwenden will. Als Kennung kommt z. B. eine Kombination aus Username/Passwort aber auch ein digitales Zertifikat in Frage. Nutzer können ihre Kennungen z.B. auf einer Chip-Karte, einem USB Token oder in einer Datei speichern. Die Funktionalität von 802.1X und EAP erlaubt es darüber hinaus, in einem Nutzerverzeichnis auch verschiedene Arten von Kennungen zu führen. So kann einem Nutzer als Kennung ein digitales Zertifikat und einem anderen eine Username/Passwort Kombination als Kennung vergeben werden. EAP/MD5 wird aufgrund der Unsicherheit nicht empfohlen.

Der DFNRoaming Nutzer stößt einen Authentifizierung Prozess an, in dem er einen sogenannten "Network Access Identifier" (NAI) eingibt. Der NAI besteht in der Regel aus: <nutzername>@<einrichtung>.de

Im Rahmen des DFNRoaming Dienstes sind nur die in eckigen Klammern stehenden Bezeichnungen frei wählbar, das Trennzeichen "@" und die Endung ".de" sind für den reibungslosen Ablauf, insbesondere bei Verwendung von Tunnel Protokollen wie TTLS oder PEAP, zwingend (s. dazu RCF2486).

Der gesamte Authentifizierungsvorgang ist zwischen Endgerät und RADIUS-Server verschlüsselt. Für potentielle Angreifer wird es somit gegenüber heutigen Verfahren schwieriger, Kennungen abzuhören.

Nach erfolgreicher Authentifizierung gemäß IEEE 802.1X erhalten der Zugangspunkt und das Endgerät des Nutzers vom RADIUS-Server einen temporären WEP Schlüssel, der in der Regel periodisch erneuert wird. Damit ist für die gesamte Dauer der Sitzung die Kommunikation zwischen Endgerät und Zugangspunkt verschlüssel. Die Vertraulichkeit der Datenübertragung verbessert sich damit erheblich gegenüber heutigen Verfahren (z. B. unverschlüsselt oder statische WEP Schlüssel).Im Falle der Web-basierten Authentifizierung (s. Migrationslösung) ist der Authentifizierungsprozess verschlüsselt. Nach erfolgter Authentifizierung ist jedoch die Kommunikation zwischen Endgerät und Zugangspunkt unverschlüsselt! Es wird im Falle der Übertragung von sicherheitskritischen Daten (z.B. Passwort für die E-mail) empfohlen, ein Verschlüsselungsprotokoll, z.B. SSH zu verwenden.

Anhand der Kennung können die Nutzer unterschiedlichen Virtuellen LAN (VLAN) zugeordnet werden. So ist es z. B. möglich, Mitarbeitern der eigenen Einrichtung vollen Zugriff auf das gesamte Netzwerk zu geben und den Nutzern von DFNRoaming nur den Zugang zum X-WIN zu erlauben. Dazu muss in jedem Fall der Zugangspunkt VLANs unterstützen.

Die folgende Anleitung richtet sich ausschließlich an Administratoren, die für die Authentifizierung ihrer Nutzer 802.1X und den Framework EAP/TTLS sowie den Windows 2000/XP/Pocket PC-Supplikanten SecureW2 (www.securew2.com) in ihren Einrichtungen einsetzen.

Die zur Zeit (Stand 2005) verfügbaren Supplikanten für 802.1X variieren, je nachdem welches EAP (TTLS,TLS, PEAP, etc.) verwendet wird, in ihrer Konfiguration erheblich, so dass hier nur beispielhaft die Konfiguration für den SecureW2 auf der Grundlage des EAP/TTLS beschrieben wird.

An großen Einrichtungen mit vielen tausend Nutzern macht es wenig Sinn, jeden einzelnen Supplikanten vorzukonfigurieren. Mit sogenannten flexiblen Installer Programmen lässt sich für den Nutzer nachvollziehbar der Supplikant selber konfigurieren.

Anleitung für einen SecureW2 Installer

1. Zunächst werden die benötigten Programme heruntergeladen. Unter nsis.sourceforge.net bekommt man das Installer System, welches man auf seinem Windows Rechner installiert. Anschießend generiert man ein neues Verzeichnis, z.B. SecureW2-Installer, dort legt man die Anwendungssoftware SecureW2 (www.securew2.com) ab, z.B. SecureW2.312.exe. Zusätzlich werden dort die Dateien „SecureW2_example.NSI“, „SecureW2.INF“, „dfnroaming.ico“ und das Root Zertifikat, durch das der Radius Server zertifiziert wurde, z.B. root.der, abgelegt.
2. In der Datei „SecureW2_example.NSI“ passt man nun einige Variablen an, z.B. OutFile, der Name des Installer Programmes, CERT_FILE, die Pfadangabe des Root-Zertifikates etc..
3. Wichtig für das spätere Verhalten des SecureW2 Supplikanten ist das File SecureW2.INF. Hier gibt es eine Reihe von interessanten Voreintellungen, die der Administrator vornehmen kann. SecureW2.INF ist ausführlich in den Dokumentation auf den Webseiten www.securew2.com/uk/resources/index.htm erläutert. Für das DFNRoaming wichtige Einstellungen:
• Paragraph [Certificates]: Mit der Variablen Certificate.1 ist der korrekte Filename des Root-Zertifikates anzugeben.
• Paragraph [SSID.1]: Die Variable Name bezeichnet die SSID:eduroam, die Variable Profile bezeichnet den Namen des Profiles.
• Paragraph [Profile.1]: Die Variable AlternateOuterIdentity ist auf anonymous@<einrichtung.de> zu setzen, die Variable TrustedRootCA.0 ist auf den jeweiligen MD5 Hashwert des Root-Zertifikates zu setzen. Zusätzlich kann man noch die Variable VerifyServerName auf den Common Name (CN) des Home Radius Server Zertifikates setzen, damit wird sichergestellt, dass nur mit dem Home Radius Server ein sicherer Tunnel etabliert wird. Die Varaible UserName ist auf den Wert  PROMPTUSER zu setzen, so dass der Nutzer bei der Installation des SecureW2 Supplikanten nach dem Nutzername und dem Passwort gefragt wird. Die Variable AllowNewConnection sollten auf keinen Fall auf den Wert TRUE gesetzt werden, bei einem Man-in-the-Middle Angriff kann sich ein fremder Radius Server in den Kommunikationsprozess einklinken und dem Nutzer ein fremdes Zertifikat zur Verifizierung anbieten. Bestätigt der Nutzer das fremde Radius Server Zertifikat, besteht die Möglichkeit, dass nicht autorisierte Personen das Passwort des Nutzer einsehen können.
4. Wenn alles wie gewünscht konfiguriert ist, klickt man mit der rechten Maustaste auf die Ikone „SecureW2_example.NSI“ und wählt aus dem Pop-Up Menü „Compile NSIS script“. Das vorkonfigurierte SecureW2 Installer Programm wird nun erstellt. Dieses Installer Programm kann man nun zum Download seinen Nutzern auf den Webseiten seiner Einrichtung zur Verfügung stellen. Damit der Nutzer bei der Installation auch sicher gehen kann, dass er das richtige Root Zertifikat installiert hat, sollte der Administrator vorher ein MD5 Hashwert des Installer Programmes generieren und diesen Wert als
   sogenannten Fingerprint neben dem Download auf den Download Seiten seiner Einrichtung sichtbar ablegen. So kann ausgeschlossen werden, dass der Nutzer beim Downloaden des Programmes ein gefälschtes Installer Programm erhält.
5. Der Nutzer startet nach dem Überprüfen des Fingerprints das Installer Programm und folgt den Installationsanweisungen auf dem Bildschirm seines Rechners. Bei der Aufforderung, den Nutzernamen und das Passwort einzugeben ist darauf zu atchen, dass die Nutzer realer-name@einrichtung.de eingeben, also den kompletten Realm und nicht nur den realen Nutzernamen.