eduroam aus Sicht des Instituts-Admins

Aus Sicht einer Einrichtung besteht eduroam aus 3 Teilen:

• Service-Provider (SP), die das ein WLAN 'eduroam' ausstrahlen
• Identity-Provider (IdP), die User authentifizieren
• und Magie, die alles verbindet.

Der Ablauf ist dabei wie folgt: Ein (durch den User korrekt konfiguriertes) Endgerät, zB ein Handy, ist vor Ort bei einem SP. Es sieht ein WLAN der SSID 'eduroam' und schickt ein EAP-Authentifizierungs-Paket mit seinem ('äußeren') User-Name anna.adler@heimathorst.example an den WLAN-Access-Point. Dieser packt es in ein 'RADIUS'-Paket ein und schickt es weiter an den Top-Level RADIUS-Server des Landes, zB in Deutschland den DFN. Nach etwas Magie endet das EAP-in-RADIUS-Paket beim RADIUS-Server des IdP heimathorst.example dieses Users.

Dieser schickt eine Antwort, erneut als EAP-in-RADIUS durch den Backbone, zum WLAN-Gerät des SP und dieser weiter als EAP-Paket an das Endgerät. Nach einigem Hin-und-Her, schickt der RADIUS-Server des IdP ein Access-Accept (oder Access-Reject), woraufhin die WLAN-Verbindung des Endgeräts final aufgebaut werden kann (oder abgewiesen wird). Was folgt, sind die üblichen DHCP-Pakete bzw. Autokonfiguration des Endgerätes.

Die Internetverbindung des Endgerätes wird vollständig durch den SP gestellt. Mit Ende der Authentifizierung durch das Accept-Paket erfolgt keine Kommunikation mit dem IdP mehr. eduroam enthält keinerlei VPN-artigen Funktionalitäten. Verteilt/föderiert ist nur der Prozess der Authentifizierung. Auch gibt es im eduroam keine weiteren Autorisierungsmechanismen / User-Gruppen. Ein User darf das eduroam nutzen; oder nicht.

Für den Support der Endanwender ist immer der Heimat-IdP zuständig. Stellt sich im Laufe der Fehlersucher heraus, dass eine Unterstützung durch den besuchten SP notwendig ist, muss der Kontakt durch die Admins des IdPs, nicht den Endanwender, aufgenommen werden. Im Zweifel vermittelt der DFN die zugehörigen Kontaktadressen.

Die Authentifizierungs-Infrastruktur der eduroam .de-Föderation darf nur für die Anmeldung an Computer-Netzwerken via 802.1x verwendet werden. Die Terminierung der EAP-Verbindung erfolgt ausschließlich im Endgerät sowie dem Heimat-IdP. Eine Terminierung der EAP-Verbindung im SP oder einem anderen Zwischen-Hop ist untersagt.

Service-Provider im eduroam-Sinne, sind die Einrichtungen, die das WLAN / die SSID 'eduroam' ausstrahlen und somit den reisenden Forscherinen und Forschern Internetzugriff ermöglichen. Jedes Mitglied im eduroam muss immer auch ein Service-Provider sein¹⁾. Es kann Einrichtungen geben, die nur eduroam ausstrahlen, deren User jedoch nicht selbst das eduroam nutzen können. Ein Beispiel hier sind einige Innenstädte, Bahnhöfe, Flughäfen und Bibliotheken, die als eduroam SP, nicht jedoch als IdP, auftreten.

In der eduroam Service Definition (Abs. 6.3.3) sowie knapper formuliert dem eduroam Compliance Statement (Anhang B) werden die Anforderungen und Pflichten eines SP aufgeführt.

Ganz knapp umrissen, muss ein SP folgende Elemente vorhalten:

• WPA2-Enterprise WLAN
  • RADSEC-Verbindung zum DFN (s.u.)
  • Einfügen des 'Calling-Station-Id' RADIUS-Attributs in den Request zum DFN
  • Synchrone System-Uhrzeit (zB via ntp)
• (DHCP-)Autokonfiguration für die Clients im WLAN
• offener Internetzugriff für die Clients
  • mit Firewall-Regeln für die WLAN-Clients, die bevorzugt einen komplett uneingeschränkten Netzzugang ermöglichen, ggf. nur einige Dienste (zB tcp/25) verbieten.
  • Es müssen nach außen mindestens(!) folgende Dienste frei sein:
    • ipsec
    • GRE
    • UDP-Ports: 500,1194,4500
    • TCP-Ports: 21,22,80,110,143,443,465,587,993,995,3128,8080,1723,10000

Jede gängige WLAN-Installation, egal ob selbst-gebaut auf günstiger Hardware und OpenSource-Basis, medium-bepreiste Firmenlösungen oder Enterprise-Campus-WLAN-Controller, erfüllt diese Anforderungen. In vielen Fällen muss derzeit (Stand Anfang 2018) für die Verbindung zum DFN jedoch zusätzlich ein Proxy für die Umsetzung von UDP-RADIUS Paketen auf eine verschlüsselte TLS/TCP-RADSEC-Verbindung installiert werden. Immer mehr Anbieter integrieren aber das RADSEC-Protokoll bereits direkt in die WLAN-Infrastruktur, wodurch dieser Umsetzter in Zukunft entfallen kann.

Die Übertragung der RADIUS-Pakete in der .de-Föderation vom SP zum DFN erfolgt seit Dezember 2017 nur noch verschlüsselt via RADSEC-Protokoll. RADSEC basiert auf dem bekannten TLS-Verfahren, bedarf also X.509-Zertifikaten, genau wie bspw. Web-Browser für HTTPS.

Es werden nur Zertifikate der DFN PKI Generation 1 oder 2 akzeptiert. Einrichtungen, die nicht Teilnehmer der DFN PKI sind, können auf Anfrage für diesen Zweck ein einzelnes Zertifikat ausgestellt bekommen.

Für den Betrieb benötigt der DFN folgende Informationen von zukünftigen SP:

• IPv4-Adresse(n) der RADSEC Clients
• CN der Zertifikate der RADSEC Clients
• Der Domain-Name wird nicht verwendet! Weder für die Herstellung der Verbindung, noch den Zertifikats-Check.
• IPv6 wird momentan noch nicht unterstützt

Die Parameter (IPs, DNS, Zertifikate) der DFN-RADSEC-Server finden Sie hier.

Wir empfehlen eine Überprüfung anhand der IP, des CN des Zertifikats sowie natürlich einer korrekten Signatur des selben durch die DFN CA bzw. ein Telekom Root-Zertifikat. Config-Beispiele für gängige Produkte finden sich bei den Anleitungen.

Noch unterstützen nicht alle WLAN-Geräte dieses Protokoll, weshalb in den meisten Fällen ein Umsetzer / Proxy erforderlich ist. Hierfür eignen sich praktisch alle RADIUS-Server-Programme, die auch RADSEC unterstützen. Darunter sind u.a. Freeradius, Radiator und der radsecproxy. Für SP empfehlen wir den radsecproxy, da es das einfachste Programm mit den geringsten Anforderungen und zudem Open Source mit einer sehr breit installierten Basis ist.

• WLAN-Controler
  • Allgemein
  • Cisco
  • Aruba
  • HP MSM
  • …
• Proxy für RADIUS auf RADSEC
  • radsecproxy
  • …

(folgt in Kürze)

Die Magie, der Backbone, ist ausführlich in technischer Tiefe im RFC 7593 definiert. Wer nur einen SP oder IdP aufsetzen möchte, muss dies nicht komplett verstehen :).