X-Git-Url: http://git.rohieb.name/seminar-bachelor.git/blobdiff_plain/02c65dfb07669e7fa48a82ce37f4b3227c2b2dd8..HEAD:/architektur.tex

diff --git a/architektur.tex b/architektur.tex
index 95af883..05ea450 100644
--- a/architektur.tex
+++ b/architektur.tex
@@ -2,21 +2,47 @@
 \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 2 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} (weiteres dazu spÃ¤ter) 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 sich im selben Netzwerk befinden, kann aber 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}
 
-\subsection{Benutzerauthentifizierung und -authorisierung (IEEE 802.1X, RADIUS)}
+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}
+
+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.
+
+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 -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 sendet, der wiederum den sich einwÃ¤hlenden Benutzer authentifizieren kann und ihm dies Ã¼ber ein \acr{EAP}-\emph{Success}- oder \emph{Failure}-Paket mitteilt.
