architektur.tex

   1 \section{Architektur}
   2 \subsection{Identity Provider und Service Provider}
   3 Um das Roaming von Endbenutzern so einfach wie möglich zu machen, wird in der Architektur von eduroam zwischen dem \emph{Identity Provider} (\acr{IdP}) und dem \emph{Service Provider} (\acr{SP}) unterschieden. Der Identity Provider ist für die Authentifizierung des sich einwählenden Benutzers zuständig, wobei der Service Provider den Netzzugang stellt, und mit dem Identity Provider kommuniziert, um den Benutzer zu authentifizieren.
   4
   5 Beispielsweise ist ein Benutzer, der ein Benutzerkonto an der \acr{TU} Braunschweig besitzt, zu Gast an der \acr{TU} Berlin, und will das dort vorhandene \acr{WLAN} benutzen. Beide Universitäten nehmen am eduroam-Programm teil. Bei der Einwahl in Berlin kommuniziert der zuständige Server dort mit dem Server in Braunschweig, der für die Benutzerauthentifizierung zuständig ist, und gestattet (oder verwehrt) aufgrund dessen Antwort dem Benutzer den Netzzugriff.
   6
   7 Andernfalls ist es natürlich auch möglich, dass Service Provider und Identity Provider die selbe Institution sind. Dies ist insbesondere der Fall, wenn Benutzer sich auf dem lokalen Campus einwählen.
   8
   9 \subsection{Sicherer Netzzugang durch \acr{IEEE 802.1X}}
  10 Der sichere Netzzugang wird in eduroam durch den Standard \acr{IEEE 802.1X} \cite{ieee802.1X} auf \acr{ISO/OSI}-Layer 2b (Logical Link Control) realisiert. Dabei muss sich der Rechner, der Zugriff auf das physikalische Netz erlangen will (der sogenannte \emph{Supplicant}) bei einem Server (dem \emph{Authenticator}) authentifizieren, bevor er Zugriff auf weitere Netzressourcen erhält.
  11
  12 Die Authentifizierung erfolgt dabei über das \acr{EAP}-Protokoll \cite{rfc-eap}, das verschiedene Mechanismen unterstützt (ursprünglich wurde \acr{EAP} über das Point-to-Point Protocol (\acr{PPP}) eingesetzt, die Implementierung in \acr{IEEE 802}-Netzen wird deshalb zur Unterscheidung auch \acr{EAPOL} -- \acr{EAP} over \acr{LAN} -- genannt). Diese Authentifizierungsmechanismen können prinzipiell frei gewählt werden, innerhalb des eduroam-Verbundes werden allerdings aus Gründen der Sicherheit die Abwandlungen \acr{EAP-TLS} \cite{rfc-eap-tls}, \acr{EAP-TTLS} \cite{rfc-eap-ttls}, oder \acr{PEAP} \cite{draft-peap} eingesetzt, die die Authentifizierung zur Erhöhung der Sicherheit über eine verschlüsselte Verbindung abwickeln.
  13
  14 Der Authenticator wird vom Service Provider bereitgestellt und ist in dessen Netz eingebunden, es kann sich dabei je nach Zugangsmedium um einen Access Point oder einen Router handeln. Er hat die Aufgabe, den Benutzer zu authentifizieren, indem er mit einen \emph{Authentication Server} (\acr{AS}) kommuniziert. Dieser wiederum kann mit dem Authenticator zusammenfallen, kann aber prinzipiell in der Netzwerktopologie auch beliebig weit entfernt sein.
  15
  16 \begin{figure}
  17   \centering
  18   \includegraphics[width=0.6\textwidth]{8021X-Overview.pdf}
  19   \caption{Netzzugang durch \acr{IEEE 802.1X} (\cite{commons8021X}, Lizenz: \acr{CC-BY-SA 3.0})}
  20 \end{figure}
  21
  22 Beide Seiten, Supplicant und Authenticator, sind als State Machines realisiert, die über den Zustand des ihnen zugeordneten Netzwerkports Buch führen (es wird vorausgesetzt, dass zwischen ihnen eine Punkt-zu-Punkt-Verbindung aufgebaut werden kann, beispielsweise über Ethernet). Zu jedem physikalischen Port gibt es einen nicht verwalteten Port und einen verwalteten Port, über die -- unabhängig voneinander -- Daten mit höheren Protokollschichten ausgetauscht werden können. Weiterhin wird für den kontrollierten Port gepseichert, ob er sich im authorisierten oder im nicht authorisierten Status befindet. Im nicht authorisierten Status wird der entsprechende Port gesperrt, sodass darüber liegende Protokollschichten keine Daten über ihn austauschen können; im authorisierten Status ist dies möglich. Beim Aufbau der Verbindung befinden sich die kontrollierten Ports beider Seiten im unauthorisierten Status.
  23
  24 Standardmäßig kann der Supplicant nur mit dem Authenticator und mit Systemen kommunizieren, für die keine weiteren Zugriffsregeln definiert sind, und die somit am nicht kontrollierten Port des Authenticators anliegen (welche Dienste dies sind ist eine Frage der spezifischen Systemkonfiguration). Falls er mit Systemen kommunizieren möchte, die am kontrollierten Port des Authenticators anliegen, kann dies nur geschehen, sofern sich beide kontrollierten Ports -- der des Supplicants sowohl der des Authenticators -- im authorisierten Status befindet. Meist tritt dieser Fall ein, nachdem sich der Supplicant authentifiziert und kein (optionales) Logoff angefordert hat.
  25
  26 Es ist aber auch für den Supplicant möglich, seinen kontrollierten Port in den nicht authorisierten Modus zu schalten und somit die Kommunikation mit den vom Authenticator angebotenen Diesten zu verweigern. Dies kann nützlich sein, falls der Authenticator seine Identität nicht bestätigen konnte und so nicht sichergestellt ist, ob der Kommunikation mit ihm vertraut werden kann oder ob ein Angreifer im Spiel ist.
  27 %% TODO: hier vielleicht noch Grafik hin mit kontrolliert/unkontrollierten Ports?
  28
  29 Weiterhin hängt es vom verwendeten Authentifizierungsmechanismus ab, ob die Kommunikation nach der Authentifizierung bidirektional oder unidirektional stattfinden kann. Falls ein Mechanismus verwendet wurde, der nur die Identität des Supplicants sicherstellt (wie z.~B. \acr{EAP MD5-CHALLENGE}), ist nur ein unidirektionaler Zugriff des Supplicants auf die Dienste des Authenticators möglich. Für einen bidirektionalen Zugriff müssen sich beide Seiten durch einen geeigneten Mechanismus (wie die oben genannten \acr{EAP-TLS}, \acr{EAP-TTLS} oder \acr{PEAP}) ausweisen. In eduroam ist dies immer der Fall, sodass auch der Benutzer sicher sein kann, dass er seine Login-Daten an das richtige System sendet.
  30
  31 \subsection{Benutzerauthentifizierung und -authorisierung (IEEE 802.1X, RADIUS)}
  32 Die Kommunikation zwischen Authenticator und Authentication Server erfolgt in eduroam über das \acr{RADIUS}-Protokoll \cite{rfc-radius}. Anhand der bei der Einwahl angegebenen Benutzer-\acr{ID} in der Form "`benutzername@domain.tld"' kann der Identity Provider festgestellt werden (dies ist der Teil nach dem @-Zeichen). Der zuständige Authentication Server (also \acr{RADIUS}-Server) leitet die Authentifizierungs-Anfrage zum \acr{RADIUS}-Server des Identity Providers weiter, indem er prüft, ob der Identity Provider möglicherweise er selbst ist (in dem Fall ist kein Routing nötig), und wenn nicht, die Anfrage an einen \emph{nationalen \acr{RADIUS}-Server} weiterleitet, der von einer nationalen Forschungsnetzorganisation betrieben wird. Dieser wiederum leitet die Anfrage entweder an sein Ziel weiter, falls dieses in seinem Zugehörigkeitsbereich liegt, oder an den \emph{Root-\acr{RADIUS}-Server}, der von \acr{TENERA} betrieben wird und die Anfrage zum richtigen nationalen nationalen \acr{RADIUS}-Server weiterleitet, der die Anfrage an ihr Ziel weiterleiten kann.
  33
  34 Die Prüfung der Login-Daten wird so effektiv beim Identity Provider vorgenommen, der seine Antwort über Erfolg oder Fehlschlag zurück an den Authenticator des Service Providers schickt, der wiederum den sich einwählenden Benutzer authentifizieren kann.