eduroam aus Sicht des Instituts-Admins

Eine in eduroam teilnehmende Einrichtung kann in der Regel 2 Rollen einnehmen:

• Die des eduroam Identity-Provider (IdP), der seine Nutzer für eduroam registriert, verwaltet und die Authentifizierung durchführt,
• Die des eduroam Service-Provider (SP), der registrierten eduroam Nutzern den Netzzugang über ein WLAN (SSID:edurom) oder LAN emöglicht

Der Netzzugang für den eduroam Nutzer 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 DFN eduroam 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 breit installierten Basis ist.

(folgt in Kürze)