\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.
+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 authorisierten oder im nicht authorisierten Status befindet. Im nicht authorisierten Status wird der entsprechende Port gesperrt, sodass darüber liegende Protokollschichten keine Daten über ihn austauschen können; im authorisierten Status ist dies möglich. Beim Aufbau der Verbindung befinden sich die kontrollierten Ports beider Seiten im unauthorisierten Status.
+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 authorisierten Status befindet. Dieser Fall tritt ein, nachdem sich der Supplicant authentifiziert und kein (optionales) Logoff angefordert hat.
+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 authorisierten 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).
+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).
%% TODO: hier vielleicht noch Grafik hin mit kontrolliert/unkontrollierten Ports?
Weiterhin hängt es vom verwendeten Authentifizierungsmechanismus ab, ob die Kommunikation nach der Authentifizierung bidirektional oder unidirektional stattfinden kann. Falls ein Mechanismus verwendet wurde, der nur die Identität des Supplicants sicherstellt (wie z.~B. \acr{EAP MD5-CHALLENGE}), ist nur ein unidirektionaler Zugriff des Supplicants auf die Dienste des Authenticators möglich. Für einen bidirektionalen Zugriff müssen sich beide Seiten durch einen geeigneten Mechanismus (wie die oben genannten \acr{EAP-TLS}, \acr{EAP-TTLS} oder \acr{PEAP}) ausweisen. In eduroam ist dies immer der Fall, sodass auch der Benutzer sicher sein kann, dass er seine Login-Daten an das richtige System sendet.
projects / seminar-bachelor.git / blobdiff