X-Git-Url: https://git.rohieb.name/seminar-bachelor.git/blobdiff_plain/f4cd49add2aaf18f921016931a2bfd553af7d612..HEAD:/authn.tex

diff --git a/authn.tex b/authn.tex
index 602c9ce..25dcdfb 100644
--- a/authn.tex
+++ b/authn.tex
@@ -1,11 +1,58 @@
 \section{Benutzerauthentifizierung im Detail}
-\subsection{Feststellung der IdentitÃ¤t der kommunizierenden Systeme untereinander}
+Dieses Kapitel erklÃ¤rt die Vorgehensweise bei der Benutzerauthentifizierung im Detail.
 
-\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}}
+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 autorisierten Status.
 
-\subsection{Authentifizierung des Benutzers}
-\subsection{Zugriff auf Heimatnetzwerk}
+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).
+\end{enumerate}
+
+Zu diesem Zeitpunkt wird der kontrollierte Port des Supplicants und des Authenticators auf den autorisierten bzw. nicht autorisierten Status gesetzt und dem Supplicant wird der Zugriff auf die entsprechenden Dienste gewÃ¤hrt oder verweigert.
+
+Interessant ist die Umsetzung bei der PrÃ¼fung der Authentifizierungsinformationen in Schritt~\ref{eap-auth}. Hier setzt in eduroam die \acr{RADIUS}-Authentifizierung ein. Der Authenticator kommuniziert mit seinem nÃ¤chstgelegenen \acr{RADIUS}-Server (auf Institutionsebene), indem er eine \acr{RADIUS}-\emph{Access-Request}-Nachricht an ihn schickt, das die Login-Daten des Benutzers enthÃ¤lt. Der \acr{RADIUS}-Server antwortet entweder direkt oder fragt nach dem selben Prinzip beim \acr{RADIUS}-Server der nÃ¤chsthÃ¶heren Ebene an, und antwortet schlieÃlich entweder mit einer \emph{Access-Accept}-Nachricht (der Benutzer wurde authentifiziert), oder mit einer \emph{Access-Reject}-Nachricht (der Benutzer wurde nicht authentifiziert), oder mit einer \emph{Access-Challenge}-Nachricht, die die andere Seite auffordert, eine neue \emph{Access-Request}-Nachricht mit mehr Informationen zu schicken, um die Authentifizierung zu behandeln.
+
+Dabei ist zu beachten, dass die Login-Daten als \acr{EAP}-Paket in \acr{RADIUS}-Pakete eingekapselt werden. Somit wird auch hier die verschlÃ¼sselte Ãbertragung von sicherheitsrelevanten Daten gewÃ¤hrleistet.
+
+\subsection{Authentifizierung anhand weiterer Benutzerattribute}
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=0.6\textwidth]{tnc-arch.png}
+  \caption{TNC-Architektur~\cite{10.1109/NSS.2009.47}}
+  \label{fig:tnc}
+\end{figure}
+
+Bernal, SÃ¡nchez et~al. stellen einen Ansatz vor, um den Autorisierung des Benutzers auch aufgrund anderer Attribute zu erlauben~\cite{10.1109/NSS.2009.47}. Beispielsweise soll nur Benutzern der Netzzugriff erlaubt werden, die einen funktionierenden Virenscanner installiert haben. Zu diesem Zweck stellen sie eine Architektur vor, die auf dem Modell der Trusted Network Group basiert (siehe Abb.~\ref{fig:tnc}). Diese Architektur basiert im Wesentlichen auf folgenden Elementen:
+\begin{itemize}
+  \item \emph{Integrity Management Collector (\acr{IMC})}: sammelt Attributdaten auf dem Client-System (z.~B. ob ein Virenscanner installiert ist)
+  \item \emph{Integrity Management Verifier (\acr{IMV})}: prÃ¼ft die Ã¼bertragenen Attributdaten auf ValiditÃ¤t und ob diese mit den vom Systemadministrator vergebenen Richtlinien Ã¼bereinstimmen
+  \item \emph{Network Access Requestor (\acr{NAR})}: ist auf der Client-Seite fÃ¼r den Aufbau einer Netzwerkverbindung zustÃ¤ndig. In den meisten FÃ¤llen ist dies ein \acr{IEEE~802.1X} Supplicant.
+  \item \emph{Network Access Authority (\acr{NAA})}: regelt auf der Server-Seite den Zugriff der anfragenden Clients. Im Endeffekt ist dies eine erweitere Komponente im \acr{RADIUS}-Server, die mit diesem zusammenarbeitet, um Autorisierungsentscheidungen zu treffen.
+\end{itemize}
+
+Weiterhin ist ein \emph{Policy Enforcement Point} vorhanden, der die Aufgabe hat, die Richtlinien umzusetzen. StandardmÃ¤Ãig ist dies ein Access Point oder Router.
+
+Nachdem die \acr{IEEE~802.1X}-Authentifizierung abgelaufen ist, sammelt der Integrity Management Collector Attributdaten, die er dann an den Integrity Management Verifier Ã¼bertrÃ¤gt. Dies geschieht Ã¼ber eine weitere \acr{EAP}-Methode, die \acr{EAP-TNC} genannt wird und verschlÃ¼sselt zwischen dem Endbenutzer und dem \acr{RADIUS}-Server aufgebaut wird. Der Integrity Management Verifier prÃ¼ft die Attribute und teilt seine Autorisierungsentscheidung Ã¼ber die Network Access Authority an den Policy Enforcement Point mit, der sie umsetzt.
+
+% \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}
 
