X-Git-Url: https://git.rohieb.name/seminar-bachelor.git/blobdiff_plain/362d18677add9edf4432a239ad8a7d7e532c2949..3c06b3635dcffc04153c0c5de47ee40670228b12:/authn.tex

diff --git a/authn.tex b/authn.tex
index 2bcaeee..dbcd14a 100644
--- a/authn.tex
+++ b/authn.tex
@@ -1,14 +1,41 @@
 \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}