fertig, erstmal

diff --git a/ausarbeitung.tex b/ausarbeitung.tex
index c9d5232..5794b5b 100644 (file)
--- a/ausarbeitung.tex
+++ b/ausarbeitung.tex
@@ -3,6 +3,7 @@
 \usepackage[utf8]{inputenc}
 \usepackage{ngerman}
 \usepackage{graphicx}
 \usepackage[utf8]{inputenc}
 \usepackage{ngerman}
 \usepackage{graphicx}

+\usepackage{url}

 
 \title{Sicherheit in eduroam}
 \subtitle{Seminar Kommunikation und Multimedia, Sommersemester 2010}
 
 \title{Sicherheit in eduroam}
 \subtitle{Seminar Kommunikation und Multimedia, Sommersemester 2010}


@@ -28,10 +29,10 @@ Diese Arbeit gibt einen Überblick über die Architektur von eduroam. Im Anschlu
 
 %% Bibliografie
 % \nocite{rfc-radius}
 
 %% Bibliografie
 % \nocite{rfc-radius}

-\nocite{cookbook}
-\nocite{10.1109/NSS.2009.47}
-\nocite{Lopez2008418}
-\nocite{Lopez2007900}
+\nocite{inter-nren-arch}
+% \nocite{10.1109/NSS.2009.47}
+% \nocite{Lopez2008418}
+% \nocite{Lopez2007900}

 \bibliographystyle{plain}
 \bibliography{lit}
 
 \bibliographystyle{plain}
 \bibliography{lit}
 

diff --git a/authn.tex b/authn.tex
index dbcd14a..eb68d9b 100644 (file)
--- a/authn.tex
+++ b/authn.tex
@@ -15,27 +15,37 @@ Typischerweise beginnt nun der Authenticator die Authentifizierung über \acr{EA
     %% TODO: PEAP?!?
   \end{itemize}
   \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).
     %% TODO: PEAP?!?
   \end{itemize}
   \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).

-
-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.
-
-Interessant ist die Umsetzung bei der Prüfung der Authentifizierungsinformationen in Schritt \ref{eap-auth}. Hier setzt in eduroam die \acr{RADIUS}-Authentifizierung ein.
-
-
-

 \end{enumerate}
 
 \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.

 
 

-
-\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{Aufbau einer sicheren Verbindung zur Benutzerauthentifizierung}
-
-\subsection{Authentifizierung des Benutzers}
-\subsection{Zugriff auf Heimatnetzwerk}
+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.
+
+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:
+\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.
+\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.
+
+% \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{Aufbau einer sicheren Verbindung zur Benutzerauthentifizierung}
+% 
+% \subsection{Authentifizierung des Benutzers}
+% \subsection{Zugriff auf Heimatnetzwerk}

 
 

diff --git a/authz.tex b/authz.tex
index 12fdce4..6238718 100644 (file)
--- a/authz.tex
+++ b/authz.tex
@@ -1,3 +1,11 @@
-\section{Benutzerauthorisierung im Detail (eduGAIN)}
-eduGAIN
-\subsection{Benutzerattribute, XACML, SAML}
+\section{Weitergehende Benutzerauthorisierung}
+
+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:
+\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
+\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 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/lit.bib b/lit.bib
index 605f35c..386024b 100644 (file)
--- a/lit.bib
+++ b/lit.bib
@@ -9,7 +9,7 @@ year = "2007",
 note = "",
 issn = "1084-8045",
 doi = "DOI: 10.1016/j.jnca.2005.07.010",
 note = "",
 issn = "1084-8045",
 doi = "DOI: 10.1016/j.jnca.2005.07.010",

-howpublished = "http://www.sciencedirect.com/science/article/B6WKB-4H3Y8R1-2/2/88b43ba7f229ab0fb00316f6032a1e4a",
+howpublished = "\url{http://www.sciencedirect.com/science/article/B6WKB-4H3Y8R1-2/2/88b43ba7f229ab0fb00316f6032a1e4a}",

 author = "Gabriel López and Oscar Cánovas and Antonio F. Gómez and Jesús D. Jiménez and Rafael Marín",
 keywords = "Authorization",
 keywords = "Access control",
 author = "Gabriel López and Oscar Cánovas and Antonio F. Gómez and Jesús D. Jiménez and Rafael Marín",
 keywords = "Authorization",
 keywords = "Access control",


@@ -31,8 +31,7 @@ area",
 issn = "0920-5489",
 doi = "DOI: 10.1016/j.csi.2008.03.010",
 howpublished =
 issn = "0920-5489",
 doi = "DOI: 10.1016/j.csi.2008.03.010",
 howpublished =

-"http://www.sciencedirect.com/science/article/B6TYV-4S0YXPG-B/2/0c98447f805fc208
-08a35c3d64804eb4",
+"\url{http://www.sciencedirect.com/science/article/B6TYV-4S0YXPG-B/2/0c98447f805fc20808a35c3d64804eb4}",

 author = "Gabriel López and Óscar Cánovas and Antonio F. Gómez-Skarmeta and
 Manuel Sánchez",
 keywords = "NAS-SAML",
 author = "Gabriel López and Óscar Cánovas and Antonio F. Gómez-Skarmeta and
 Manuel Sánchez",
 keywords = "NAS-SAML",


@@ -51,22 +50,16 @@ volume = {0},
 isbn = {978-0-7695-3838-9},
 year = {2009},
 pages = {170-175},
 isbn = {978-0-7695-3838-9},
 year = {2009},
 pages = {170-175},

-howpublished = {http://doi.ieeecomputersociety.org/10.1109/NSS.2009.47},
+howpublished = {\url{http://doi.ieeecomputersociety.org/10.1109/NSS.2009.47}},

 publisher = {IEEE Computer Society},
 address = {Los Alamitos, CA, USA},
 }
 
 publisher = {IEEE Computer Society},
 address = {Los Alamitos, CA, USA},
 }
 

-@Misc{cookbook,
-title = {{Deliverable DJ5.1.5,3: Inter-NREN Roaming Infrastructure and Service
-  Support Cookbook}},
-author = {S. Winter and T. Kersting and P. Dekkers and L. Guido and S.
-  Papageorgiou and Janos Mohacsi and R. Papez and M. Milinovic and D. Penezic
-  and J. Rauschenbach and J. Tomasek and K. Wierenga and T. Wolniewicz and
-  José-Manuel Macias-Luna and I. Thomson and {JRA5 group}},
-edition = {Third},
-month = {Oct},
-year = {2008},
-howpublished = {http://www.eduroam.org/downloads/docs/GN2-08-230-DJ5.1.5.3-eduroamCookbook.pdf},
+@Misc{inter-nren-arch,
+title = {Deliverable DJ5.1.4, Inter-{NREN} Roaming Architecture},
+author = {K. Wierenga et al.},
+year = {2006},
+howpublished = "\url{http://www.eduroam.org/downloads/docs/GN2-06-137v5-Deliverable_DJ5-1-4_Inter-NREN_Roaming_Technical_Specification_20060908164149.pdf}",

 }
 
 @Misc{rfc-radius,
 }
 
 @Misc{rfc-radius,


@@ -131,11 +124,18 @@ title= "{802.1X IEEE Standard for Local and metropolitan area networks,
 @Misc{eduroam.org,
 author = "eduroam {SA}",
 title = "eduroam Website",
 @Misc{eduroam.org,
 author = "eduroam {SA}",
 title = "eduroam Website",

-howpublished = "http://www.eduroam.org"
+howpublished = "\url{http://www.eduroam.org}"

 }
 
 @Misc{commons8021X,
 author = "Benutzer Rohieb",
 title = "{Wikimedia Commons: File:8021X-Overview.svg}",
 }
 
 @Misc{commons8021X,
 author = "Benutzer Rohieb",
 title = "{Wikimedia Commons: File:8021X-Overview.svg}",

-howpublished = "http://commons.wikimedia.org/wiki/File:8021X-Overview.svg"
+howpublished = "\url{http://commons.wikimedia.org/wiki/File:8021X-Overview.svg}"
+}
+
+@Misc{tnc,
+author = "{Trusted Computing Group}",
+title = "{TCG Trusted Network Connect: TNC Architecture for Interoperability}",
+version = "1.3",
+year = "2008"

 }
 }

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

-- Single-Sign-On
-- AAA
\ No newline at end of file
+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.