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.
+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.
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.
\section{Benutzerauthentifizierung im Detail}
+Dieses Kapitel erklärt die Vorgehensweise bei der Benutzerauthentifizierung im Detail.
+Sobald der Benutzer eine Einwahl in das eduroam-Netz anfordert, wird vom \acr{IEEE 802.1X}-Supplicant eine Verbindung zum Authenticator aufgebaut. Zu diesem Zeitpunkt befinden sich auf der Supplicant- und auf der Authenticator-Seite beide kontrollierten Ports im nicht authorisierten Status.
+
+Typischerweise beginnt nun der Authenticator die Authentifizierung über \acr{EAPOL}, aber auch der Supplicant kann die Authentifizierung starten, indem er ein \acr{EAPOL}-Start-Paket sendet. Alle nachfolgenden \acr{EAP}-Pakete werden durch \acr{EAPOL-EAP}-Pakete gekapselt, der Ablauf ist wie folgt:
+
+\begin{enumerate}
+ \item Der Authenticator sendet eine \acr{EAP}-\emph{Identity}-Anfrage, um die Identität des Supplicants festzustellen.
+ \item Der Supplicant antwortet mit der vom Benutzer angegebenen (bzw. anonymen) Identität.
+ \item Der Supplicant fährt fort, indem er dem Authenticator mitteilt, welche (vom Benutzer gewählte) EAP-Authentifizierungs-Methode er anfordert. Falls der Server diese Auswahl bestätigt, folgt nun der für diese Methode spezifische Teil der Authentifizierung:
+ \begin{itemize}
+ \item Bei \acr{EAP-TLS} handeln der Authenticator und der Supplicant eine gesicherte Verbindung nach dem \acr{TLS}-Protokoll \cite{rfc-tls} aus, wobei der Authenticator sein Serverzertifikat sendet, das vom Supplicant geprüft wird. Der Supplicant sendet wiederum das vom Benutzer konfigurierte persönliche Benutzerzertifikat.
+ \item Bei \acr{EAP-TTLS} handeln der Authenticator und der Supplicant eine gesicherte Verbindung nach dem \acr{TLS}-Protokoll wie im obigen Fall aus. Allerdings weist der Supplicant sich in diesem Fall nicht durch ein Benutzerzertifikat aus, sondern sendet die Login-Daten des Benutzers über diese gesicherte Verbindung. Der Authenticator prüft diese. Zu beachten ist hier, dass im dritten Schritt der Supplicant nicht den eigentlichen Login-Namen des Benutzers sendet, sondern einen Platzhalter wie "`anonymous"'. So wird nicht nur das Login-Passwort gegen Abhören geschützt.
+ %% TODO: PEAP?!?
+ \end{itemize}
+ \item \label{eap-auth} In jedem Fall prüft der Authenticator die Login-Daten und sendet ein \acr{EAP}-Success-Paket, falls der Vorgang erfolgreich war (in diesem Fall ist der Benutzer authentifiziert), oder ein \acr{EAP}-Failure-Paket andernfalls (der Benutzer wurde nicht authentifiziert).
+
+Zu diesem Zeitpunkt wird der kontrollierte Port des Supplicants und des Authenticators auf den authorisierten bzw. nicht authorisierten Status gesetzt und der Supplicant kann auf die entsprechenden Dienste zugreifen.
+
+Interessant ist die Umsetzung bei der Prüfung der Authentifizierungsinformationen in Schritt \ref{eap-auth}. Hier setzt in eduroam die \acr{RADIUS}-Authentifizierung ein.
+
+
+
+\end{enumerate}
-\subsection{Feststellung der Identität der kommunizierenden Systeme untereinander}
-\subsection{Aufbau einer sicheren Verbindung zur Benutzerauthentifizierung}
\subsubsection{\acr{EAP-TTLS} -- \acr{EAP} over Tunneled \acr{TLS}}
\subsubsection{\acr{EAP-TLS} -- \acr{EAP} over \acr{TLS}}
\subsubsection{\acr{EAP-PEAP}}
+
+\subsection{Feststellung der Identität der kommunizierenden Systeme untereinander}
+
+
+\subsection{Aufbau einer sicheren Verbindung zur Benutzerauthentifizierung}
+
\subsection{Authentifizierung des Benutzers}
\subsection{Zugriff auf Heimatnetzwerk}
year = "2002"
}
+@Misc{rfc-tls,
+author = "T. Dierks and E. Rescorla",
+title = "{RFC} 4346: The Transport Layer Security ({TLS}) Protocol, Version 1.1",
+year = "2006"
+}
+
@Misc{ieee802.1X,
author = "{IEEE Computer Society}",
year = 2004,
projects / seminar-bachelor.git / commitdiff