\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.
+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.
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:
\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 authorisierten bzw. nicht authorisierten Status gesetzt und dem Supplicant wird der Zugriff auf die entsprechenden Dienste gewährt oder verweigert.
+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.
projects / seminar-bachelor.git / blobdiff