X-Git-Url: https://git.rohieb.name/seminar-bachelor.git/blobdiff_plain/02c65dfb07669e7fa48a82ce37f4b3227c2b2dd8..13f23d6edf83308c9158e7757b255cb1fa93dedf:/architektur.tex

diff --git a/architektur.tex b/architektur.tex
index 95af883..10950fb 100644
--- a/architektur.tex
+++ b/architektur.tex
@@ -7,11 +7,11 @@ Beispielsweise ist ein Benutzer, der ein Benutzerkonto an der \acr{TU} Braunschw
 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 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.
 
-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.
+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.
 
 \begin{figure}
   \centering
@@ -19,4 +19,16 @@ Der Authenticator wird vom Service Provider bereitgestellt und ist in dessen Net
   \caption{Netzzugang durch \acr{IEEE 802.1X} (\cite{commons8021X}, Lizenz: \acr{CC-BY-SA 3.0})}
 \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.
+
+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.
+
+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.
+%% 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.
+
+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.
