+\begin{itemize}
+ \item \emph{Request} zum Stellen der Anfrage durch den Authenticator,
+ \item \emph{Response} zur Beantwortung der Anfrage durch den Supplicant,
+ \item \emph{Success} zum Signalisieren, dass die Authentifizierung erfolgreich war, und
+ \item \emph{Failure} zum Signalisieren einer fehlgeschlagenen Authentifizierung.
+\end{itemize}
+
+Die Authentifizierungsmechanismen können prinzipiell frei gewählt werden, der Standard erlaubt auch die Verwendung eines Backend-Servers wie z.~B. Kerberos. Innerhalb des eduroam-Verbundes werden allerdings aus Gründen der Sicherheit die Abwandlungen \acr{EAP-TLS} \cite{rfc-eap-tls}, \acr{EAP-TTLS} \cite{rfc-eap-ttls}, oder \acr{PEAP} \cite{draft-peap} eingesetzt, die die Authentifizierung zur Erhöhung der Sicherheit über eine verschlüsselte Verbindung abwickeln, und auch die Feststellung der Identität des Authenticators erlauben. Bei EAP-TLS wird dabei vor dem Authentifizierungsschritt eine verschlüsselte Verbindung nach dem etablierten TSL-Verfahren aufgebaut, bei EAP-TTLS wird zuerst ein verschlüsselter TLS-Tunnel aufgebaut, sodass die gesamte EAP-Kommunikation geschützt ist (und nicht nur der Authentifizierungsschritt). Bei beiden Verfahren handelt es sich um Internet-Standards, die auf offenen Standards aufbauen. PEAP ähnelt EAP-TTLS sehr stark, es handelt sich hierbei aber um eine Entwicklung der Firmen Microsoft, RSA Security und Cisco.
+
+Der Authenticator wird vom Service Provider bereitgestellt und ist in dessen Netz eingebunden, es kann sich dabei je nach Zugangsmedium um einen Access Point oder einen Router handeln. Er hat die Aufgabe, den Benutzer zu authentifizieren, indem er mit einen \emph{Authentication Server} (\acr{AS}) kommuniziert. Dieser wiederum kann mit dem Authenticator zusammenfallen, kann aber prinzipiell in der Netzwerktopologie auch beliebig weit entfernt sein.
+
+Beide Seiten, Supplicant und Authenticator, sind als State Machines realisiert, die über den Zustand des ihnen zugeordneten Netzwerkports Buch führen (es wird vorausgesetzt, dass zwischen ihnen eine Punkt-zu-Punkt-Verbindung aufgebaut werden kann, beispielsweise über Ethernet). Zu jedem physikalischen Port werden zwei virtuelle Ports definiert, der nicht verwaltete Port und der verwaltete Port, über die -- unabhängig voneinander -- Daten mit höheren Protokollschichten ausgetauscht werden können und die die essenzielle Zugriffskontrolle implementieren. Weiterhin wird für den kontrollierten Port gespeichert, ob er sich im autorisierten oder im nicht autorisierten Status befindet. Im nicht autorisierten Status wird der entsprechende Port gesperrt, sodass darüber liegende Protokollschichten keine Daten über ihn austauschen können; im autorisierten Status ist dies möglich. Beim Aufbau der Verbindung befinden sich die kontrollierten Ports beider Seiten im unautorisierten Status.
+
+Standardmäßig kann der Supplicant nur mit dem Authenticator kommunizieren und mit Systemen, für die keine weiteren Zugriffsregeln definiert sind, und die somit am nicht kontrollierten Port des Authenticators anliegen (welche Dienste dies sind ist eine Frage der spezifischen Systemkonfiguration). Falls der Supplicant mit Systemen kommunizieren möchte, die am kontrollierten Port des Authenticators anliegen, kann dies nur geschehen, sofern sich beide kontrollierten Ports -- sowohl der des Supplicants als auch der des Authenticators -- im autorisierten Status befindet. Dieser Fall tritt ein, nachdem sich der Supplicant authentifiziert und kein (optionales) Logoff angefordert hat.
+
+Es ist aber auch für den Supplicant möglich, seinen kontrollierten Port in den nicht autorisierten Modus zu schalten und somit die Kommunikation mit den vom Authenticator angebotenen Diensten zu verweigern. Dies kann nützlich sein, falls der Authenticator seine Identität nicht bestätigen konnte und so nicht sichergestellt ist, ob der Kommunikation mit ihm vertraut werden kann oder ob ein Angreifer im Spiel ist (siehe dazu Kapitel~\ref{chap:sicherheit} für Angriffsszenarien).
projects / seminar-bachelor.git / blobdiff