authn.tex

   1 \section{Benutzerauthentifizierung im Detail}
   2 Dieses Kapitel erklärt die Vorgehensweise bei der Benutzerauthentifizierung im Detail.
   3
   4 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.
   5
   6 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:
   7
   8 \begin{enumerate}
   9   \item Der Authenticator sendet eine \acr{EAP}-\emph{Identity}-Anfrage, um die Identität des Supplicants festzustellen.
  10   \item Der Supplicant antwortet mit der vom Benutzer angegebenen (bzw. anonymen) Identität.
  11   \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:
  12   \begin{itemize}
  13     \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.
  14     \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.
  15     %% TODO: PEAP?!?
  16   \end{itemize}
  17   \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).
  18
  19 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.
  20
  21 Interessant ist die Umsetzung bei der Prüfung der Authentifizierungsinformationen in Schritt \ref{eap-auth}. Hier setzt in eduroam die \acr{RADIUS}-Authentifizierung ein.
  22
  23
  24
  25 \end{enumerate}
  26
  27
  28
  29 \subsubsection{\acr{EAP-TTLS} -- \acr{EAP} over Tunneled \acr{TLS}}
  30 \subsubsection{\acr{EAP-TLS} -- \acr{EAP} over \acr{TLS}}
  31 \subsubsection{\acr{EAP-PEAP}}
  32
  33
  34 \subsection{Feststellung der Identität der kommunizierenden Systeme untereinander}
  35
  36
  37 \subsection{Aufbau einer sicheren Verbindung zur Benutzerauthentifizierung}
  38
  39 \subsection{Authentifizierung des Benutzers}
  40 \subsection{Zugriff auf Heimatnetzwerk}
  41