\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 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:
\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-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}
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.
-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.
+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 im Endeffekt als gesamtes \acr{EAP}-Paket in \acr{RADIUS}-Pakete eingekapselt werden. Somit wird auch hier die verschlüsselte Übertragung von sicherheitsrelevanten Daten gewährleistet.
+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}
-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 der Architektur der Trusted Network Group basiert. Diese Architektur basiert im Wesentlichen auf folgenden Elementen:
+\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 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 Acces Point oder Router.
+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.
+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}}
projects / seminar-bachelor.git / blobdiff