Einführung leicht gekürzt, um auf eine Seite zu bringen; Architektur von IEEE 802...

diff --git a/architektur.tex b/architektur.tex
index 95af883..9ae916c 100644 (file)
--- a/architektur.tex
+++ b/architektur.tex
@@ -8,10 +8,10 @@ Andernfalls ist es natürlich auch möglich, dass Service Provider und Identity
 
 \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 2 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} (weiteres dazu später) eingesetzt, die die Authentifizierung zur Erhöhung der Sicherheit über eine verschlüsselte Verbindung abwickeln.
+\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 sich im selben Netzwerk befinden, kann aber in der Netzwerktopologie auch beliebig weit entfernt sein.
+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
@@ -19,4 +19,13 @@ Der Authenticator wird vom Service Provider bereitgestellt und ist in dessen Net
   \caption{Netzzugang durch \acr{IEEE 802.1X} (\cite{commons8021X}, Lizenz: \acr{CC-BY-SA 3.0})}
 \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.
+
+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.
+
+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.
+%% 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)}

diff --git a/einfuehrung.tex b/einfuehrung.tex
index 2fa8a5d..969b95e 100644 (file)
--- a/einfuehrung.tex
+++ b/einfuehrung.tex
@@ -1,10 +1,9 @@
 \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.
 
-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. Beispielsweise sind Szenarien denkbar, wo bestimmte Ressourcen (z.~B. Drucker) nur von berechtigten Personen (beispielsweise wissenschaftlichen Mitarbeitern und Professoren) 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.
+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, und ihren Sitz in Amsterdam hat, 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 nordamerikanischen Ländern (insbesondere in den Vereinigten Staaten und Japan) 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 nordamerikanischen Ländern (insbesondere in den Vereinigten Staaten und Japan) zur Verfügung steht.
 
 \begin{figure}[h]
   \centering