%% 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}
+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.
-
-\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}
+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 Hierarchie 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.
+
+\subsection{Authentifizierung anhand weiterer Benutzerattribute}
+Bernal, Sánchez et~al. stellen einen Ansatz vor, um den Authorisierung 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{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 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 Authorisierungsentscheidungen 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.
+
+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 Authorisierungsentscheidung ü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}}
+% \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}
projects / seminar-bachelor.git / blobdiff