X-Git-Url: https://git.rohieb.name/seminar-bachelor.git/blobdiff_plain/7e67a16caa25e6d125f560df8802ab3b27470631..e7e145726ad4de7e2ebbe9bdc2671cc61230a463:/authn.tex?ds=sidebyside

diff --git a/authn.tex b/authn.tex
index 44414be..25dcdfb 100644
--- a/authn.tex
+++ b/authn.tex
@@ -1,7 +1,7 @@
 \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:
 
@@ -17,7 +17,7 @@ Typischerweise beginnt nun der Authenticator die Authentifizierung Ã¼ber \acr{EA
   \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.
 
