\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}}
-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.
-
-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.
-
-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.
-
+\subsection{Sicherer Netzzugang durch \acr{IEEE~802.1X}}
\begin{figure}
\centering
\includegraphics[width=0.6\textwidth]{8021X-Overview.pdf}
\caption{Netzzugang durch \acr{IEEE 802.1X} (\cite{commons8021X}, Lizenz: \acr{CC-BY-SA 3.0})}
+ \label{fig:8021X}
\end{figure}
-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.
+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:
+
+\begin{itemize}
+ \item \emph{Request} zum Stellen der Anfrage durch den Authenticator,
+ \item \emph{Response} zur Beantwortung der Anfrage durch den Supplicant,
+ \item \emph{Success} zum Signalisieren, dass die Authentifizierung erfolgreich war, und
+ \item \emph{Failure} zum Signalisieren einer fehlgeschlagenen Authentifizierung.
+\end{itemize}
-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.
+Die Authentifizierungsmechanismen können prinzipiell frei gewählt werden, der Standard erlaubt auch die Verwendung eines Backend-Servers wie z.~B. Kerberos. 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, und auch die Feststellung der Identität des Authenticators erlauben. Bei EAP-TLS wird dabei vor dem Authentifizierungsschritt eine verschlüsselte Verbindung nach dem etablierten TSL-Verfahren aufgebaut, bei EAP-TTLS wird zuerst ein verschlüsselter TLS-Tunnel aufgebaut, sodass die gesamte EAP-Kommunikation geschützt ist (und nicht nur der Authentifizierungsschritt). Bei beiden Verfahren handelt es sich um Internet-Standards, die auf offenen Standards aufbauen. PEAP ähnelt EAP-TTLS sehr stark, es handelt sich hierbei aber um eine Entwicklung der Firmen Microsoft, RSA Security und Cisco.
-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.
+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.
+
+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 werden zwei virtuelle Ports definiert, der nicht verwaltete Port und der verwaltete Port, über die -- unabhängig voneinander -- Daten mit höheren Protokollschichten ausgetauscht werden können und die die essenzielle Zugriffskontrolle implementieren. Weiterhin wird für den kontrollierten Port gespeichert, ob er sich im autorisierten oder im nicht autorisierten Status befindet. Im nicht autorisierten Status wird der entsprechende Port gesperrt, sodass darüber liegende Protokollschichten keine Daten über ihn austauschen können; im autorisierten Status ist dies möglich. Beim Aufbau der Verbindung befinden sich die kontrollierten Ports beider Seiten im unautorisierten Status.
+
+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 autorisierten 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 autorisierten 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 -authorisierung (IEEE 802.1X, RADIUS)}
-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.
+\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.
+
+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}).
-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.
+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 sendet, der wiederum den sich einwählenden Benutzer authentifizieren kann und ihm dies über ein \acr{EAP}-\emph{Success}- oder \emph{Failure}-Paket mitteilt.
projects / seminar-bachelor.git / blobdiff