mehr

diff --git a/architektur.tex b/architektur.tex
index 10950fb..426cd33 100644 (file)
--- a/architektur.tex
+++ b/architektur.tex
@@ -7,28 +7,42 @@ Beispielsweise ist ein Benutzer, der ein Benutzerkonto an der \acr{TU} Braunschw
 Andernfalls ist es natürlich auch möglich, dass Service Provider und Identity Provider die selbe Institution sind. Dies ist insbesondere der Fall, wenn Benutzer sich auf dem lokalen Campus einwählen.
 
 \subsection{Sicherer Netzzugang durch \acr{IEEE 802.1X}}
 Andernfalls ist es natürlich auch möglich, dass Service Provider und Identity Provider die selbe Institution sind. Dies ist insbesondere der Fall, wenn Benutzer sich auf dem lokalen Campus einwählen.
 
 \subsection{Sicherer Netzzugang durch \acr{IEEE 802.1X}}

-Der sichere Netzzugang wird in eduroam durch den Standard \acr{IEEE 802.1X} \cite{ieee802.1X} auf \acr{ISO/OSI}-Layer 2b (Logical Link Control) realisiert. Dabei muss sich der Rechner, der Zugriff auf das physikalische Netz erlangen will (der sogenannte \emph{Supplicant}) bei einem Server (dem \emph{Authenticator}) authentifizieren, bevor er Zugriff auf weitere Netzressourcen erhält.
-
-Die Authentifizierung erfolgt dabei über das \acr{EAP}-Protokoll \cite{rfc-eap}, das verschiedene Mechanismen unterstützt (ursprünglich wurde \acr{EAP} über das Point-to-Point Protocol (\acr{PPP}) eingesetzt, die Implementierung in \acr{IEEE 802}-Netzen wird deshalb zur Unterscheidung auch \acr{EAPOL} -- \acr{EAP} over \acr{LAN} -- genannt). Diese Authentifizierungsmechanismen können prinzipiell frei gewählt werden, 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.
-
-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.
-

 \begin{figure}
   \centering
   \includegraphics[width=0.6\textwidth]{8021X-Overview.pdf}
   \caption{Netzzugang durch \acr{IEEE 802.1X} (\cite{commons8021X}, Lizenz: \acr{CC-BY-SA 3.0})}
 \begin{figure}
   \centering
   \includegraphics[width=0.6\textwidth]{8021X-Overview.pdf}
   \caption{Netzzugang durch \acr{IEEE 802.1X} (\cite{commons8021X}, Lizenz: \acr{CC-BY-SA 3.0})}

+  \label{fig:8021X}

 \end{figure}
 
 \end{figure}
 

-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 gibt es einen nicht verwalteten Port und einen verwalteten Port, über die -- unabhängig voneinander -- Daten mit höheren Protokollschichten ausgetauscht werden können. Weiterhin wird für den kontrollierten Port gepseichert, 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.
+Der sichere Netzzugang wird in eduroam durch den Standard \acr{IEEE 802.1X} \cite{ieee802.1X} auf \acr{ISO/OSI}-Layer 2b (Logical Link Control) realisiert, hat also die Aufgabe, den logischen Zugriff auf das Netzwerk zu regeln und zwei Endpunkte (Computer, Router\ldots) miteinander zu verbinden. Insbesondere muss sich der Rechner, der Zugriff auf das physikalische Netz erlangen will (der sogenannte \emph{Supplicant}) bei einem Server (dem \emph{Authenticator}) authentifizieren, bevor er Zugriff auf weitere Netzressourcen erhält (siehe Abbildung \ref{fig:8021X}).
+% TODO: In \acr{WLAN}-Netzen wird \acr{IEEE 802.1X} deshalb auch als Alternative zu \acr{WEP} und \acr{WPA(2)} eingesetzt.
+% TODO: verschlüsselte Kommunikation oder nur verbindungsaufbau?
+
+Die Authentifizierung erfolgt dabei über \acr{EAP} (Extensible Authentication Protocol) \cite{rfc-eap}, das verschiedene Authentifizierungsmechanismen unterstützt. Ursprünglich wurde \acr{EAP} über das Point-to-Point Protocol (\acr{PPP}) eingesetzt, die Implementierung in \acr{IEEE 802}-Netzen wurde geringfügig erweitert und zur Unterscheidung \acr{EAPOL} -- \acr{EAP} over \acr{LAN} -- genannt. Generell erfolgt die Authentifizierung über \acr{EAP} nach dem Challenge-Response-Prinzip, d.~h. die authentifizierende Seite gibt eine "`Aufgabe"' vor (beispielsweise eine Passwortabfrage), die vom Supplicant richtig beantwortet werden muss, damit seine Identität festgestellt werden kann. Dazu definiert \acr{EAP} vier Nachrichtentypen:
+
+\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}

 
 

-Standardmäßig kann der Supplicant nur mit dem Authenticator und mit Systemen kommunizieren, 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 er mit Systemen kommunizieren möchte, die am kontrollierten Port des Authenticators anliegen, kann dies nur geschehen, sofern sich beide kontrollierten Ports -- der des Supplicants sowohl der des Authenticators -- im authorisierten Status befindet. Meist tritt dieser Fall ein, nachdem sich der Supplicant authentifiziert und kein (optionales) Logoff angefordert hat.
+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.

 
 

-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 Diesten 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.
+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.
+
+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.
+
+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).

 %% 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.
 
 %% 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.
 

-\subsection{Benutzerauthentifizierung und -authorisierung (IEEE 802.1X, RADIUS)}
-Die Kommunikation zwischen Authenticator und Authentication Server erfolgt in eduroam über das \acr{RADIUS}-Protokoll \cite{rfc-radius}. Anhand der bei der Einwahl angegebenen Benutzer-\acr{ID} in der Form "`benutzername@domain.tld"' kann der Identity Provider festgestellt werden (dies ist der Teil nach dem @-Zeichen). Der zuständige Authentication Server (also \acr{RADIUS}-Server) leitet die Authentifizierungs-Anfrage zum \acr{RADIUS}-Server des Identity Providers weiter, indem er prüft, ob der Identity Provider möglicherweise er selbst ist (in dem Fall ist kein Routing nötig), und wenn nicht, die Anfrage an einen \emph{nationalen \acr{RADIUS}-Server} weiterleitet, der von einer nationalen Forschungsnetzorganisation betrieben wird. Dieser wiederum leitet die Anfrage entweder an sein Ziel weiter, falls dieses in seinem Zugehörigkeitsbereich liegt, oder an den \emph{Root-\acr{RADIUS}-Server}, der von \acr{TENERA} betrieben wird und die Anfrage zum richtigen nationalen nationalen \acr{RADIUS}-Server weiterleitet, der die Anfrage an ihr Ziel weiterleiten kann.
+\subsection{Benutzerauthentifizierung und -autorisierung}
+Die Kommunikation zwischen Authenticator und Authentication Server erfolgt in eduroam über das \acr{RADIUS}-Protokoll \cite{rfc-radius} (kurz für \emph{Remote Authentication Dial-In User Service}), das allgemein für Authentifizierung, Autorisierung und Accounting (Abrechnung von Leistungen) verwendet wird. Ein \acr{RADIUS}-Server beantwortet Authentifizierungsanfragen, indem er die erforderlichen Daten entweder selbst in seiner Datenbank nachschlägt, oder die Anfrage an einen weiteren \acr{RADIUS}-Server weiterleitet und somit als \emph{Proxy} zwischen dem anfragenden und dem authentifizierenden System vermittelt. Zu beachten ist hier, dass in jedem Fall Passwörter nicht im Klartext übertragen werden, sondern durch \acr{MD5} kodiert werden. Ein \acr{RADIUS}-Server dient somit als Authentication Server im \acr{IEEE 802.1X}-Modell.
+
+Der Authenticator kann nun anhand der bei der Einwahl angegebenen Benutzer-\acr{ID} in der Form "`benutzername@domain.tld"' den Identity Provider festgestellt werden (dies ist der Teil nach dem @-Zeichen). Der zuständige Authentication Server (also \acr{RADIUS}-Server) beantwortet die Anfrage entweder selbst, falls er selbst der Identity Provider ist, oder er leitet die Anfrage an einen \emph{nationalen \acr{RADIUS}-Server} weiterleitet, der von einer nationalen Forschungsnetzorganisation (z.~B. dem Deutschen Forschungsnetz) betrieben wird. Dieser wiederum leitet die Anfrage entweder an sein Ziel weiter, falls dieses in seinem Zugehörigkeitsbereich liegt, oder an den obersten \acr{RADIUS}-Server für dieses Gebiet (Europa, Asien, Kanada), der von \acr{TERENA} betrieben wird. Er leitet die Anfrage zum passenden nationalen \acr{RADIUS}-Server weiter, der die Anfrage an ihr Ziel weiterleiten kann. So entsteht eine Hierarchie von \acr{RADIUS}-Servern auf Institutionsebene, nationaler Ebene (\emph{Federation Level}) und kontinentaler Ebene (\emph{Confederation Level}).

 
 

-Die Prüfung der Login-Daten wird so effektiv beim Identity Provider vorgenommen, der seine Antwort über Erfolg oder Fehlschlag zurück an den Authenticator des Service Providers schickt, der wiederum den sich einwählenden Benutzer authentifizieren kann.
+Die Prüfung der Login-Daten wird so effektiv beim Identity Provider vorgenommen, der seine Antwort über Erfolg oder Fehlschlag zurück an den Authenticator des Service Providers sendet, der wiederum den sich einwählenden Benutzer authentifizieren kann und ihm dies über ein \acr{EAP}-\emph{Success}- oder \emph{Failure}-Paket mitteilt.

diff --git a/ausarbeitung.tex b/ausarbeitung.tex
index 5794b5b..eb8a6ff 100644 (file)
--- a/ausarbeitung.tex
+++ b/ausarbeitung.tex
@@ -18,13 +18,15 @@
 \maketitle
 
 \begin{abstract}
 \maketitle
 
 \begin{abstract}

-Diese Arbeit gibt einen Überblick über die Architektur von eduroam. Im Anschluss wird die Vorgehensweise bei der Benutzerauthentifizierung und -authorisierung dargelegt, wobei der Schwerpunkt insbesondere auf der Betrachtung der Sicherheit liegt.
+Diese Arbeit gibt einen Überblick über die Architektur von eduroam. Im Anschluss wird die Vorgehensweise bei der Benutzerauthentifizierung und -autorisierung dargelegt, wobei der Schwerpunkt insbesondere auf der Betrachtung der Sicherheit liegt.

 \end{abstract}
 
 \input{einfuehrung}
 \input{architektur}
 \input{authn}
 \input{authz}
 \end{abstract}
 
 \input{einfuehrung}
 \input{architektur}
 \input{authn}
 \input{authz}

+\input{sicherheit}
+\input{ausblick}

 \input{zusammenfassung}
 
 %% Bibliografie
 \input{zusammenfassung}
 
 %% Bibliografie

diff --git a/ausblick.tex b/ausblick.tex
new file mode 100644 (file)
index 0000000..093a3d8
--- /dev/null
+++ b/ausblick.tex
@@ -0,0 +1,9 @@
+\section{Ausblick: eduroam-ng}\label{chap:ausblick}
+Unter dem Stichwort \emph{eduroam-ng} (eduroam-next generation) werden Verbesserungen der aktuellen eduroam-Infrastruktur entwickelt. Es sollen hier einige mögliche Sicherheitslücken und Performanceprobleme addressiert werden. \cite{inter-nren-arch}
+
+\subsection{RadSec}
+Es ist geplant, die aktuelle \acr{RADIUS}-Infrastruktur sukzessive durch RadSec zu ergänzen. Dieses Protokoll stellt eine Erweiterung des herkömmlichen \acr{RADIUS}-Protokolls dar, sodass es abwärtskompatibel dazu ist. Die grundlegendste Erweiterung dabei ist die Umstellung von \acr{UDP}-basiertem Datenverkehr auf \acr{TCP}. Dadurch werden einige Mechanismen (beispielsweise negative Authentifizierungsantworten) in \acr{RADIUS} überflüssig, die durch die verbindungslose Natur von \acr{UDP} eingeführt wurden, und die im verbindungsorientierten \acr{TCP} besser abgebildet werden können.
+
+Zudem ist es mit RadSec möglich, die Kommunikation verschlüsselt über \acr{TLS} abzuwickeln. Dies stellt zum einen die Abhörsicherheit der Verbindung fest, zum anderen erlaubt es auch, die Identität beider Kommunikationspartner über Zertifikate festzustellen -- dies ist insbesondere wichtig, da die Identität vorher anhand der IP-Adresse des \acr{RADIUS}-Servers festgestellt wurde, die sich leicht fälschen lässt. Außerdem wird dadurch die unsichere MD5-Verschlüsselung der Benutzerdaten hinfällig.
+
+\subsection{DNSSec}

diff --git a/authn.tex b/authn.tex
index eb68d9b..fbbb5ce 100644 (file)
--- 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.
 
 \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:
 
 
 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,35 +17,35 @@ 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}
 
   \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 der Supplicant kann auf die entsprechenden Dienste zugreifen.
+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 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.
+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.
 
 \subsection{Authentifizierung anhand weiterer Benutzerattribute}
 
 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:
+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{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.
 \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.
+  \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.
 
 \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.
+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}}
 % \subsubsection{\acr{EAP-PEAP}}
 
 % \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{Feststellung der Identität der kommunizierenden Systeme untereinander}

-% 
-% 
+%
+%

 % \subsection{Aufbau einer sicheren Verbindung zur Benutzerauthentifizierung}
 % \subsection{Aufbau einer sicheren Verbindung zur Benutzerauthentifizierung}

-% 
+%

 % \subsection{Authentifizierung des Benutzers}
 % \subsection{Zugriff auf Heimatnetzwerk}
 
 % \subsection{Authentifizierung des Benutzers}
 % \subsection{Zugriff auf Heimatnetzwerk}
 

diff --git a/authz.tex b/authz.tex
index 6238718..c95c7da 100644 (file)
--- a/authz.tex
+++ b/authz.tex
@@ -1,11 +1,13 @@
-\section{Weitergehende Benutzerauthorisierung}
+\section{Weitergehende Benutzerautorisierung}

 
 

-Um erweiterte Benutzerauthorisierung zu implementieren, führen López et al. \cite{Lopez2008418}\cite{Lopez2007900} ein weiteres Modell namens \emph{\acr{NAS-SAML}} ein, das zur Verwaltung und Abfrage von Authorisierungsattributen genutzt werden kann. Es kennt folgende Entitäten:
+Um erweiterte Benutzerautorisierung zu implementieren, führen López et al. \cite{Lopez2008418}\cite{Lopez2007900} ein weiteres Modell namens \emph{\acr{NAS-SAML}} ein, das zur Verwaltung und Abfrage von Autorisierungsattributen genutzt werden kann. Auch hier hat jeder Benutzer eine Heiminstitution, die seine Autorisierungsattribute speichert.
+
+Es kennt folgende Entitäten:

 \begin{itemize}
   \item einen \emph{Policy Decision Point} in der besuchten Institution, der den Zugriff auf bestimmte Netzwerkressourcen regelt
 \begin{itemize}
   \item einen \emph{Policy Decision Point} in der besuchten Institution, der den Zugriff auf bestimmte Netzwerkressourcen regelt

-  \item ein \emph{edu\acr{GAIN} Bridged Element}, das die Kommunikation zwischen Institutionen regelt sowie Authentifizierungs- und Authorisierungsinformationen bereitstellt
+  \item ein \emph{edu\acr{GAIN} Bridged Element}, das die Kommunikation zwischen Institutionen regelt sowie Authentifizierungs- und Autorisierungsinformationen bereitstellt

 \end{itemize}
 
 \end{itemize}
 

-Die Authentifizierungsphase über \acr{RADIUS} wird dahingehend erweitert, dass das Bridged Element der Heiminstitution des Benutzers als Interface zwischen dem \acr{RADIUS}-Server der Heiminstitution und dem Identity Provider arbeitet, und zusätzlich dem \acr{RADIUS}-Server der besuchten Institution eine Zugriffsnummer mitgibt, mit der weitere Benutzerattribute abgerufen werden können. Das Bridged Element der besuchten Organisation ist dafür zuständig, Authorisierungsanfragen des \acr{RADIUS}-Server seiner Institution zu beantworten, indem er die Anfrage an die Heiminstitution des Benutzers weiterleitet, wobei die vorher erhaltene Zugriffsnummer als Schlüssel dient, um dem Bridged Element der Heiminstitution die Berechtigung nachzuweisen. Aufgrund dieser abgefragten Attribute ist der Policy Decision point in der besuchten Institution imstande, Authorisierungsentscheidungen zu treffen und den Zugriff auf Netzwerkressourcen zuzulassen oder zu verweigern.
+Die Authentifizierungsphase über \acr{RADIUS} wird dahingehend erweitert, dass das Bridged Element der Heiminstitution des Benutzers als Interface zwischen dem \acr{RADIUS}-Server der Heiminstitution und dem Identity Provider arbeitet, und zusätzlich dem \acr{RADIUS}-Server der besuchten Institution eine Zugriffsnummer mitgibt, mit der weitere Benutzerattribute abgerufen werden können. Das Bridged Element der besuchten Organisation ist dafür zuständig, Autorisierungsanfragen des \acr{RADIUS}-Server seiner Institution zu beantworten, indem er die Anfrage an die Heiminstitution des Benutzers weiterleitet, wobei die vorher erhaltene Zugriffsnummer als Schlüssel dient, um dem Bridged Element der Heiminstitution die Berechtigung nachzuweisen. Aufgrund dieser abgefragten Attribute ist der Policy Decision point in der besuchten Institution imstande, Autorisierungsentscheidungen zu treffen und den Zugriff auf Netzwerkressourcen zuzulassen oder zu verweigern.

 
 Die Kommunikation zwischen \acr{RADIUS}-Server und Bridged Element findet bevorzugt über \acr{LDAP} statt; die Bridged Elements verständigen sich über das in der edu\acr{GAIN}-Architektur spezifizierte, XML-basierte Protokoll \acr{SAML}, das in \acr{SOAP} gekapselt wird.
 
 Die Kommunikation zwischen \acr{RADIUS}-Server und Bridged Element findet bevorzugt über \acr{LDAP} statt; die Bridged Elements verständigen sich über das in der edu\acr{GAIN}-Architektur spezifizierte, XML-basierte Protokoll \acr{SAML}, das in \acr{SOAP} gekapselt wird.

diff --git a/einfuehrung.tex b/einfuehrung.tex
index e9c60e3..5512ba3 100644 (file)
--- a/einfuehrung.tex
+++ b/einfuehrung.tex
@@ -1,9 +1,9 @@
 \section{Einführung}
 \section{Einführung}

-\emph{eduroam} ist ein Verbund von Netzwerken, der es Mitgliedern der teilnehmenden Institutionen (insbesondere Hochschulen und andere Forschungs- und Bildungseinrichtungen) einen unkomplizierten Netzzugang an allen anderen teilnehmenden Institutionen, beispielsweise über \acr{LAN} oder \acr{WLAN}, ermöglicht, wobei der Besucher mit den Login-Daten seiner Heimatinstitution Zugriff auf das Netz erhält. So wird die Kommunikation in Forschung und Lehre auch bei Dienstreisen, Konferenzen oder Auslandssemestern nahtlos ermöglicht, und es entfällt die Notwendigkeit einer Einrichtung von (eventuell ungeschützten oder mit Standardpassworten versehenen) Gastzugängen, die missbraucht werden könnten, oder sonstigen zusätzlichen Benutzerkonten für Besucher. Der Name leitet sich von "`\emph{edu}cational \emph{roam}ing"' ab.
+\emph{eduroam} leitet sich von "`\emph{edu}cational \emph{roam}ing"' ab und ist ein Verbund von Netzwerken, der es Mitgliedern der teilnehmenden Institutionen (insbesondere Hochschulen und andere Forschungs- und Bildungseinrichtungen) einen unkomplizierten Netzzugang an allen anderen teilnehmenden Institutionen, beispielsweise über \acr{LAN} oder \acr{WLAN}, ermöglicht. Dabei erhält der Besucher mit den Login-Daten seiner Heimatinstitution Zugriff auf das Netz. So wird die Kommunikation in Forschung und Lehre auch bei Dienstreisen, Konferenzen oder Auslandssemestern nahtlos ermöglicht, und es entfällt die Notwendigkeit einer Einrichtung von (eventuell ungeschützten oder mit Standardpassworten versehenen) Gastzugängen, die missbraucht werden könnten, oder sonstigen zusätzlichen Benutzerkonten für Besucher.

 
 

-Innerhalb des eduroam-Netzes wird aber nicht nur auf Benutzerauthentifikation Wert gelegt, sondern es besteht auch die Möglichkeit der Benutzerauthorisierung, um den Zugriff auf bestimmte Netzressourcen an Bedingungen zu koppeln. So sind Szenarien denkbar, wo bestimmte Ressourcen (z.~B. Drucker) nur von berechtigten Personen genutzt werden dürfen. Diese Authorisierungsmechanismen werden durch \emph{edu\acr{GAIN}} (\acr{GÉANT} Authorisation Infrastructure, \acr{GÉANT} bezeichnet das gesamte, pan-europäische Forschungsnetz) bereitgestellt.
+Die Organisation \emph{\acr{TERENA}} (Trans-European Research and Education Networking Association), eine Dachorganisation, die sich aus den Organisationen der einzelnen nationalen Forschungsnetzwerke (\acr{NREN}, \emph{National Research and Education Network}) zusammensetzt, startete das eduroam-Programm im Jahr 2003. Sie pflegt auch die grundlegende Server-Infrastruktur. Nahezu alle europäischen \acr{NREN}s nehmen am eduroam-Programm teil; dessen Verbreitung ist aber nicht auf Europa an sich beschränkt, sodass eduroam auch in einigen asiatischen und pazifischen Ländern (insbesondere China, Japan und Australien) und in Kanada zur Verfügung steht.

 
 

-Die Organisation \emph{\acr{TERENA}} (Trans-European Research and Education Networking Association), eine Dachorganisation, die sich aus den Organisationen der einzelnen nationalen Forschungsnetzwerke (\acr{NREN}, \emph{National Research and Education Network}) zusammensetzt, startete das eduroam-Programm im Jahr 2003. Sie pflegt auch die grundlegende Server-Infrastruktur. Nahezu alle europäischen \acr{NREN}s nehmen am eduroam-Programm teil, dessen Verbreitung ist aber nicht auf Europa an sich beschränkt, sodass eduroam auch in einigen asiatischen und pazifischen Ländern (insbesondere China, Japan und Australien) und in Kanada zur Verfügung steht.
+Innerhalb des eduroam-Netzes wird aber nicht nur auf Benutzerauthentifikation Wert gelegt, sondern es besteht auch die Möglichkeit der Benutzerautorisierung, um den Zugriff auf bestimmte Netzressourcen an Bedingungen zu koppeln. So sind Szenarien denkbar, wo bestimmte Ressourcen (z.~B. Drucker) nur von berechtigten Personen genutzt werden dürfen. Diese Autorisierungsmechanismen werden durch \emph{edu\acr{GAIN}} (\acr{GÉANT} Authorisation Infrastructure, \acr{GÉANT} bezeichnet das gesamte, pan-europäische Forschungsnetz) bereitgestellt.

 
 \begin{figure}[h]
   \centering
 
 \begin{figure}[h]
   \centering

diff --git a/lit.bib b/lit.bib
index 386024b..5863632 100644 (file)
--- a/lit.bib
+++ b/lit.bib
@@ -139,3 +139,10 @@ title = "{TCG Trusted Network Connect: TNC Architecture for Interoperability}",
 version = "1.3",
 year = "2008"
 }
 version = "1.3",
 year = "2008"
 }

+
+@Misc{md5-harmful,
+author = "Alexander Sotirov and Marc Stevens and Jacob Appelbaum and Arjen
+  Lenstra and David Molnar and Dag Arne Osvik and Benne de Weger",
+title = "{MD5 considered harmful today}",
+howpublished = "\url{http://www.win.tue.nl/hashclash/rogue-ca/}"
+}
\ No newline at end of file

diff --git a/sicherheit.tex b/sicherheit.tex
new file mode 100644 (file)
index 0000000..69ccdfa
--- /dev/null
+++ b/sicherheit.tex
@@ -0,0 +1,15 @@
+\section{Sicherheitsaspekte}\label{chap:sicherheit}
+
+\subsection{Gefälschte Zertifikate}
+Falls \acr{EAP-TLS} oder \acr{EAP-TTLS} zur Authentifizierung verwendet werden, ist es die Aufgabe des Benutzers, sicherzustellen, dass der Authenticator sich korrekt ausweist. Dies kann geschehen, indem der Service Provider den Fingerabdruck des genutzten Zertifikats veröffentlicht, der vom Benutzer geprüft werden kann. Alternativ kann der Service Provider sein Zertifikat mit einer digitalen Unterschrift durch eine Zertifizierungsstelle beglaubigen lassen und so seine Identität gegenüber dem Benutzer bezeugen. Ist dies beides nicht der Fall, gibt es für den Benutzer keine sichere Möglichkeit, festzustellen, ob der Authenticator, mit dem er kommuniziert, in irgend einer Form vertrauenwürdig ist.
+
+\subsection{Denial of Service durch gefälschte EAPOL-Logoff-Pakete}
+Falls das Netzwerkmedium von mehreren Teilnehmern gleichzeitig genutzt wird (wie z.~B. über \acr{WLAN} oder von mehreren Rechnern hinter einem Hub), ist es möglich, durch gefälschte \acr{EAPOL}-\emph{Logoff}-Pakete eine Dienstverweigerung hervorzurufen. In diesem Szenario nutzt ein Angreifer, der Zugriff auf das gemeinsam genutzte Medium hat, die Tatsache aus, dass \acr{EAPOL}-\emph{Logoff}-Pakete im Klartext gesendet werden und keinerlei Identitäts- oder Integritätsinformationen beinhalten, und sendet fortlaufend solche Pakete mit der \acr{MAC}-Adresse des Gerätes, das Ziel des Angriffs ist. Dies hat zur Folge, dass der Authenticator für das Zielgerät den Zugriff auf die kontrollierten Netzwerkressourcen sperrt, obwohl dieses kein Logoff angefordert hat.
+
+Abhilfe schafft eine gesicherte Kommunikation auf \acr{MAC}-Layer, beispielsweise über \acr{MACSec} (standardisiert in \acr{IEEE 802.1AE}), das es für den Angreifer nahezu unmöglich macht, gefälschte Pakete mit der MAC-Adresse des Zielsystems zu versenden. Dieser Ansatz wird auch in der aktuellen Auflage des \acr{IEEE 802.1X}-Standards von 2010 verfolgt.
+
+\subsection{Sicherheit zwischen \acr{RADIUS}-Servern}
+Ein Nachteil am Einsatz von \acr{RADIUS} ist, dass die Verbindungen untereinander nicht gesichert sind, sondern die Authentifizierung über ungesichertes \acr{UDP} abgewickelt wird. Zwar wird durch die Verschleierung von Passwörtern durch \acr{MD5} verhindert, dass diese im Klartext mitgelesen werden können, jedoch gilt \acr{MD5} inzwischen nicht mehr als besonders sicher \cite{md5-harmful}. Eine weitere Schwachstelle ist, dass innerhalb der \acr{RADIUS}-Hierarchie keine Überprüfung der Identität stattfindet, es ist also prinzipiell möglich, dass ein Angreifer sich für einen Confederation-Level-Server ausgeben und Authentifizierungsantworten fälschen könnte. Beide dieser Kritikpunkte sollen im Projekt \emph{eduroam-ng} (siehe Kapitel \ref{chap:ausblick}) behoben werden.
+
+\subsection{Hierarchisches System und Single Point of Failure}
+Durch das hierarchische System von \acr{RADIUS}-Servern gibt es nur einen Pfad vom Service Provider zum Identity Provider (Service Provider $\rightarrow$ Federation Level Server [$\rightarrow$ Confederation Level Server $\rightarrow$ Federation Level Server] $\rightarrow$ Identity Provider). Falls ein Knoten auf diesem Pfad ausfällt, ist es nicht mehr möglich, Benutzer zu authentifizieren. Insbesondere ist dies der Fall, wenn ein Federation Level Server oder der Confederation Level Server ausfällt. Im ersten Fall können keine Benutzer eines Landes mehr institutionsübergreifend authentifiziert werden, im zweiten Fall ist sogar überhaupt keine institutionsübergreifende mehr Authentifizierung möglich. Der Confederation Level Server stellt somit den Single Point of Failure in eduroam dar und muss dem entsprechend redundant ausgelegt sein.

diff --git a/zusammenfassung.tex b/zusammenfassung.tex
index 435402f..e24566d 100644 (file)
--- a/zusammenfassung.tex
+++ b/zusammenfassung.tex
@@ -1,2 +1,4 @@
 \section{Zusammenfassung}
 \section{Zusammenfassung}

-Die Sicherheit in eduroam findet durchgängig äber verschlässelte Protokolle oder Klartextprotokolle mit Hashwerten statt, so bei der Benutzerauthentifizierung über \acr{IEEE 802.1X} sowie dem dahinter geschalteten Verbund von \acr{RADIUS}-Servern in Form von gehashten Passwörtern. Ebenso findet bei der Benutzerauthentifizierung ebenso nicht nur eine Überprüfung des Benutzers, sondern auch des Anbieters statt, sodass Betrugsfälle sehr warscheinlich ausgeschlossen werden können. Die Abfrage von Benutzerattributen zur weitergehenden Authorisierung ist allerdings nur über Zugriffsnummern abgesichert, die ohne viel Aufwand durch Brute-Force-Angriffe gefälscht werden können, daher sind diese Abfragen nur wirklich sicher, sobald sie über anderweitig (z.~B. durch \acr{TLS}) gesicherte Leitungen erfolgen.
+Die Sicherheit in eduroam findet durchgängig äber verschlüsselte Protokolle oder Klartextprotokolle mit Hashwerten statt, so bei der Benutzerauthentifizierung über \acr{IEEE 802.1X} sowie dem dahinter geschalteten Verbund von \acr{RADIUS}-Servern in Form von gehashten Passwörtern. Ebenso findet bei der Benutzerauthentifizierung ebenso nicht nur eine Überprüfung des Benutzers, sondern auch des Anbieters statt, sodass Betrugsfälle ausgeschlossen werden können, falls der Service Provider die entsprechenden Vorkehrungen dazu getroffen hat und sein Zertifikat vertrauenswürdig erscheinen lässt.
+
+Die Abfrage von Benutzerattributen zur weitergehenden Autorisierung ist allerdings nur über Zugriffsnummern abgesichert, die ohne viel Aufwand durch Brute-Force-Angriffe gefälscht werden können, daher sind diese Abfragen nur wirklich sicher, sobald sie über anderweitig (z.~B. durch \acr{TLS}) gesicherte Leitungen erfolgen.