sicherheit.tex

   1 \section{Sicherheitsaspekte}\label{chap:sicherheit}
   2
   3 \subsection{Gefälschte Zertifikate}
   4 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.
   5
   6 \subsection{Denial of Service durch gefälschte EAPOL-Logoff-Pakete}
   7 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.
   8
   9 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.
  10
  11 \subsection{Sicherheit zwischen \acr{RADIUS}-Servern}
  12 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.
  13
  14 \subsection{Hierarchisches System und Single Point of Failure}
  15 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.