\subsection{Identity Provider und Service Provider}
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.
-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.
+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.
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.
-\subsection{Sicherer Netzzugang durch \acr{IEEE 802.1X}}
+\subsection{Sicherer Netzzugang durch \acr{IEEE~802.1X}}
\begin{figure}
\centering
\includegraphics[width=0.6\textwidth]{8021X-Overview.pdf}
\label{fig:8021X}
\end{figure}
-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, hat also die Aufgabe, den logischen Zugriff auf das Netzwerk zu regeln und zwei Endpunkte (Computer, Router\ldots) miteinander zu verbinden. Insbesondere 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 (siehe Abbildung \ref{fig:8021X}).
+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, hat also die Aufgabe, den logischen Zugriff auf das Netzwerk zu regeln und zwei Endpunkte (Computer, Router\ldots) miteinander zu verbinden. Insbesondere 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 (siehe Abbildung~\ref{fig:8021X}).
% TODO: In \acr{WLAN}-Netzen wird \acr{IEEE 802.1X} deshalb auch als Alternative zu \acr{WEP} und \acr{WPA(2)} eingesetzt.
% TODO: verschlüsselte Kommunikation oder nur verbindungsaufbau?
-Die Authentifizierung erfolgt dabei über \acr{EAP} (Extensible Authentication Protocol) \cite{rfc-eap}, das verschiedene Authentifizierungsmechanismen unterstützt. Ursprünglich wurde \acr{EAP} über das Point-to-Point Protocol (\acr{PPP}) eingesetzt, die Implementierung in \acr{IEEE 802}-Netzen wurde geringfügig erweitert und zur Unterscheidung \acr{EAPOL} -- \acr{EAP} over \acr{LAN} -- genannt. Generell erfolgt die Authentifizierung über \acr{EAP} nach dem Challenge-Response-Prinzip, d.~h. die authentifizierende Seite gibt eine "`Aufgabe"' vor (beispielsweise eine Passwortabfrage), die vom Supplicant richtig beantwortet werden muss, damit seine Identität festgestellt werden kann. Dazu definiert \acr{EAP} vier Nachrichtentypen:
+Die Authentifizierung erfolgt dabei über \acr{EAP} (Extensible Authentication Protocol)~\cite{rfc-eap}, das verschiedene Authentifizierungsmechanismen unterstützt. Ursprünglich wurde \acr{EAP} über das Point-to-Point Protocol (\acr{PPP}) eingesetzt, die Implementierung in \acr{IEEE~802}-Netzen wurde geringfügig erweitert und zur Unterscheidung \acr{EAPOL} -- \acr{EAP} over \acr{LAN} -- genannt. Generell erfolgt die Authentifizierung über \acr{EAP} nach dem Challenge-Response-Prinzip, d.~h. die authentifizierende Seite gibt eine "`Aufgabe"' vor (beispielsweise eine Passwortabfrage), die vom Supplicant richtig beantwortet werden muss, damit seine Identität festgestellt werden kann. Dazu definiert \acr{EAP} vier Nachrichtentypen:
\begin{itemize}
\item \emph{Request} zum Stellen der Anfrage durch den Authenticator,
Standardmäßig kann der Supplicant nur mit dem Authenticator kommunizieren und mit Systemen, 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 der Supplicant mit Systemen kommunizieren möchte, die am kontrollierten Port des Authenticators anliegen, kann dies nur geschehen, sofern sich beide kontrollierten Ports -- sowohl der des Supplicants als auch der des Authenticators -- im authorisierten Status befindet. Dieser Fall tritt ein, nachdem sich der Supplicant authentifiziert und kein (optionales) Logoff angefordert hat.
-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 Diensten 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 (siehe dazu Kapitel \ref{chap:sicherheit} für Angriffsszenarien).
+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 Diensten 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 (siehe dazu Kapitel~\ref{chap:sicherheit} für Angriffsszenarien).
%% TODO: hier vielleicht noch Grafik hin mit kontrolliert/unkontrollierten Ports?
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.
\subsection{Benutzerauthentifizierung und -autorisierung}
-Die Kommunikation zwischen Authenticator und Authentication Server erfolgt in eduroam über das \acr{RADIUS}-Protokoll \cite{rfc-radius} (kurz für \emph{Remote Authentication Dial-In User Service}), das allgemein für Authentifizierung, Autorisierung und Accounting (Abrechnung von Leistungen) verwendet wird. Ein \acr{RADIUS}-Server beantwortet Authentifizierungsanfragen, indem er die erforderlichen Daten entweder selbst in seiner Datenbank nachschlägt, oder die Anfrage an einen weiteren \acr{RADIUS}-Server weiterleitet und somit als \emph{Proxy} zwischen dem anfragenden und dem authentifizierenden System vermittelt. Zu beachten ist hier, dass in jedem Fall Passwörter nicht im Klartext übertragen werden, sondern durch \acr{MD5} kodiert werden. Ein \acr{RADIUS}-Server dient somit als Authentication Server im \acr{IEEE 802.1X}-Modell.
+Die Kommunikation zwischen Authenticator und Authentication Server erfolgt in eduroam über das \acr{RADIUS}-Protokoll~\cite{rfc-radius} (kurz für \emph{Remote Authentication Dial-In User Service}), das allgemein für Authentifizierung, Autorisierung und Accounting (Abrechnung von Leistungen) verwendet wird. Ein \acr{RADIUS}-Server beantwortet Authentifizierungsanfragen, indem er die erforderlichen Daten entweder selbst in seiner Datenbank nachschlägt, oder die Anfrage an einen weiteren \acr{RADIUS}-Server weiterleitet und somit als \emph{Proxy} zwischen dem anfragenden und dem authentifizierenden System vermittelt. Zu beachten ist hier, dass in jedem Fall Passwörter nicht im Klartext übertragen werden, sondern durch \acr{MD5} kodiert werden. Ein \acr{RADIUS}-Server dient somit als Authentication Server im \acr{IEEE~802.1X}-Modell.
Der Authenticator kann nun anhand der bei der Einwahl angegebenen Benutzer-\acr{ID} in der Form "`benutzername@domain.tld"' den Identity Provider festgestellt werden (dies ist der Teil nach dem @-Zeichen). Der zuständige Authentication Server (also \acr{RADIUS}-Server) beantwortet die Anfrage entweder selbst, falls er selbst der Identity Provider ist, oder er leitet die Anfrage an einen \emph{nationalen \acr{RADIUS}-Server} weiterleitet, der von einer nationalen Forschungsnetzorganisation (z.~B. dem Deutschen Forschungsnetz) betrieben wird. Dieser wiederum leitet die Anfrage entweder an sein Ziel weiter, falls dieses in seinem Zugehörigkeitsbereich liegt, oder an den obersten \acr{RADIUS}-Server für dieses Gebiet (Europa, Asien, Kanada), der von \acr{TERENA} betrieben wird. Er leitet die Anfrage zum passenden nationalen \acr{RADIUS}-Server weiter, der die Anfrage an ihr Ziel weiterleiten kann. So entsteht eine Hierarchie von \acr{RADIUS}-Servern auf Institutionsebene, nationaler Ebene (\emph{Federation Level}) und kontinentaler Ebene (\emph{Confederation Level}).
projects / seminar-bachelor.git / blobdiff