all:
pdflatex ausarbeitung.tex
+ bibtex ausarbeitung.aux
+ pdflatex ausarbeitung.tex
+ evince ausarbeitung.pdf
clean:
rm -f *.bbl *.blg *.pdf *.log *.aux
\section{Architektur}
\subsection{Identity Provider und Service Provider}
-Um das Roaming von Endbenutzern so einfach wie möglich zu machen, wird in der Architektur von eduroam zwischen dem \emph{Identity Provider} (\acr{IdP}) und dem \emph{Service Provider} (\acr{SP}) unterschieden. Der Identity Provider ist für die Authentifizierung des sich einwählenden Benutzers zuständig, wobei der Service Provider den Netzzugang stellt, und mit dem Identity Provider kommuniziert, um den Benutzer zu authentifizieren. Beispielsweise ist ein Benutzer, der ein Benutzerkonto an der \acr{TU} Braunschweig besitzt, zu Gast an der \acr{TU} Berlin, und will das dort vorhandene \acr{WLAN} benutzen. Beide Universitäten nehmen am eduroam-Programm teil. Bei der Einwahl in Berlin kommuniziert der zuständige Server dort mit dem Server in Braunschweig, der für die Benutzerauthentifizierung zuständig ist, und gestattet (oder verwehrt) aufgrund dessen Antwort dem Benutzer den Netzzugriff.
+Um das Roaming von Endbenutzern so einfach wie möglich zu machen, wird in der Architektur von eduroam zwischen dem \emph{Identity Provider} (\acr{IdP}) und dem \emph{Service Provider} (\acr{SP}) unterschieden. Der Identity Provider ist für die Authentifizierung des sich einwählenden Benutzers zuständig, wobei der Service Provider den Netzzugang stellt, und mit dem Identity Provider kommuniziert, um den Benutzer zu authentifizieren.
+
+Beispielsweise ist ein Benutzer, der ein Benutzerkonto an der \acr{TU} Braunschweig besitzt, zu Gast an der \acr{TU} Berlin, und will das dort vorhandene \acr{WLAN} benutzen. Beide Universitäten nehmen am eduroam-Programm teil. Bei der Einwahl in Berlin kommuniziert der zuständige Server dort mit dem Server in Braunschweig, der für die Benutzerauthentifizierung zuständig ist, und gestattet (oder verwehrt) aufgrund dessen Antwort dem Benutzer den Netzzugriff.
+
+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 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 Methode der Authentifizierung kann dabei prinzipiell frei gewählt werden, innerhalb des eduroam-Verbundes werden allerdings aus Gründen der Sicherheit die Protokolle \acr{EAP-TLS}, \acr{EAP-TTLS}, oder \acr{EAP-PEAP} (weiteres dazu später) eingesetzt, die die Authentifizierung über eine gesicherte Verbindung abwickeln.
+\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.
-Der Authenticator wird vom Service Provider bereitgestellt und ist in dessen Netz eingebunden, es kann sich dabei je nach Integrationsgrad und 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 sich im selben Netzwerk befinden, kann aber in der Netzwerktopologie auch beliebig weit entfernt sein.
\begin{figure}
\centering
\input{zusammenfassung}
%% Bibliografie
-\nocite{RFC2865}
+% \nocite{rfc-radius}
\nocite{cookbook}
\nocite{10.1109/NSS.2009.47}
\nocite{Lopez2008418}
\section{Benutzerauthentifizierung im Detail}
+
+
\subsection{Feststellung der Identität der kommunizierenden Systeme untereinander}
+
\subsection{Aufbau einer sicheren Verbindung zur Benutzerauthentifizierung}
\subsubsection{\acr{EAP-TTLS} -- \acr{EAP} over Tunneled \acr{TLS}}
\subsubsection{\acr{EAP-TLS} -- \acr{EAP} over \acr{TLS}}
howpublished = {http://www.eduroam.org/downloads/docs/GN2-08-230-DJ5.1.5.3-eduroamCookbook.pdf},
}
-@Misc{RFC2865,
+@Misc{rfc-radius,
author = "C. Rigney and S. Willens and A. Rubens and W. Simpson",
year = 2000,
title = "{RFC 2865: Remote Authentication Dial In User Service (RADIUS)}"
}
-@Misc{RFC1994,
+@Misc{rfc-chap,
author = "W. Simpson",
year = 1996,
title = "{RFC 1994: PPP Challenge Handshake Authentication Protocol (CHAP)}"
}
-@Misc{RFC1334,
+@Misc{rfc-ppp-auth,
author = "B. Loyd and W. Simpson",
year = 1993,
title = "{RFC 1334: PPP Authentication Protocols}"
}
-@Misc{RFC3748,
+@Misc{rfc-eap,
author = "B. Aboba and L. Blunk and J. Vollbrecht and J. Carlson and H.
Levkowetz",
year = 2004,
title = "{RFC 3748: Extensible Authentication Protocol (EAP)}"
}
-@Misc{RFC5216,
-author = "D. Simon and B. Aboba and R. Hurst"
-title = "{RFC 5216: The EAP-TLS Authentication Protocol}"
+@Misc{rfc-eap-tls,
+author = "D. Simon and B. Aboba and R. Hurst",
+title = "{RFC 5216: The EAP-TLS Authentication Protocol}",
year = "2008"
}
-@Misc{RFC5218,
-author = "P. Funk and S. Blake-Wilson"
+@Misc{rfc-eap-ttls,
+author = "P. Funk and S. Blake-Wilson",
title = "{RFC 5218: Extensible Authentication Protocol Tunneled Transport Layer
- Security, Authenticated Protocol Version 0 (EAP-TTLSv0)}"
+ Security, Authenticated Protocol Version 0 (EAP-TTLSv0)}",
year = 2008
}
@MISC{draft-peap,
author = "H. Andersson and S. Josefsson and Glen Zorn and Dan Simon and Ashwin
- Palekar"
-title = "{draft-josefsson-pppext-eap-tls-eap-05.txt: Protected EAP Protocol
- (PEAP)}"
+ Palekar",
+title = "{Internet Draft draft-josefsson-pppext-eap-tls-eap-05.txt: Protected
+ EAP Protocol (PEAP)}",
year = "2002"
}
-@Misc{IEEE802.1X,
+@Misc{ieee802.1X,
author = "{IEEE Computer Society}",
year = 2004,
title= "{802.1X IEEE Standard for Local and metropolitan area networks,
\section{Zusammenfassung}
-- Single-Sign-On
\ No newline at end of file
+- Single-Sign-On
+- AAA
\ No newline at end of file