Authentication

Authentication befasst sich mit der Bestätigung einer Identität und der Überprüfung dieser Bestätigung auf Korrektheit.
Authentication ist ein zentraler Bestandteil des Anmeldevorgangs in einem (P2P-)Netzwerk.

Allgemein

Die Authentifizierung, gegenüber eines Systems, kann auf verschiedene Weise erfolgen:

Methode	Beispiel
man hat etwas	Schlüssel
man weiß etwas	Passwort
man ist etwas	Biometrische Merkmale
man ist an einem Ort	ein bestimmter Rechner
man kann etwas	Unterschrift

Die Verwendung von mehr als einer Methode wird als n-Factor-Authentication bezeichnet, wobei n für die Anzahl der verwendeten Methoden steht.

Allgemein unterscheidet man zwei grundlegende Typen der Authentication. Zum Einen die Standard Authentication gegenüber eines einzelnen Systems, wie zum Beispiel die Anmeldung an dem Heimrechner. Zum Anderen das Single Sign On (SSO). Hierbei authentifiziert sich der Nutzer gegenbüber einer Menge von Systemen, was eine Reduzierung der administrativen Last zur Folge hat und außerdem die verlinkung von Applikationen untereinander ermöglicht. Beispielsweise könnte es eine Datenbank für Bilder von Mitarbeitern einer Organisation, sowie eine Datenbank für Mitarbeiter und deren Adresse auf verschiedenen Systemen geben. Dabei würde die Verlinkung ermöglichen, auf beide Datenbanken zuzugreifen, ohne sich jeweils neu anmelden zu müssen. Ein populäres Beispiel für SSO ist das Microsoft Passport Netzwerk.

Der Begriff Authorization wird häufig mit Authentication gleichgesetzt, bezeichnet allerdings die Zuweisung und Überprüfung von Zugriffsrechten auf Daten und Dienste an Nutzer nach einer erfolgreichen Authentication.

Kerberos

In einem offenen Netzwerk kann das Problem auftreten, dass eine Workstation, bzw. ein Server (Service), nicht eindeutig identifizieren kann. Dieses Problem versucht Kerberos zu beheben, indem es eine sichere und einheitliche Authentifizierung im ungesicherten TCP/IP-Netzwerk bietet. Kerberos setzt auf der Idee des SSO auf.

Geschichte von Kerberos

[wegen Streitigkeiten unter den Autoren noch nicht bearbeitet :)]

Funktionsweise

Zentraler Server

Das Kerberos-System besitzt einen zentralen Server mit optionalen Spares. Dieser Server führt eine Datenbank über alle Clients und deren Private Keys (z.B. ein verschlüsseltes Passwort). Weiterhin generiert der zentrale Server, als initialen Schritt bei der Authentifizierung, Tickets sowie Session Keys für den Ticket Granting Server(TGS).
Er bietet außerdem drei Sicherheitsstufen an:

• einmalige Authentifizierung nur bei Anmeldung
• Authentifizierung jeder Nachricht
• Authentifizierung jeder Nachricht mit zusätzlicher Verschlüsselung

Ticket Granting Server

Der TGS ist dafür zuständig, dem Client, Tickets für Dienste, die er in Anspruch nehmen möchte, auszustellen. Um den TGS in Anspruch nehmen zu können, benötigt der Client vom zentralen Server ein Initialticket.
Zusätlich kennt der TGS die Private Keys aller Server.

Session Keys

Session Keys werden für die Verschlüsselung von Nachrichten zwischen zwei konkreten Parteien genutzt.

Ticket

Ein Ticket wird benötigt, um sich gegenüber eines Serices auszuweisen und seinen Dienst in Anspruch nehmen zu dürfen. Mit Hilfe des Tickets wird sichergestellt, dass der Client berechtigt ist, den geforderten Service zu nutzen. Jedes Ticket ist nur für einen begrenzten Zeitraum gültig und wie folgt aufgebaut:

• Name des Service der in Anspruch genommen werden soll
• Name des Clients
• Adresse des Clients
• einen Zeitstempel (timestamp)
• Lebenszeit des Tickets
• Session Key für Server (mit gefordertem Service) und Client

Das Ticket ist mit dem Privaten Schlüssel des Servers (mit gefordertem Service) kodiert.

Authenticator

Der Authenticator stellt sicher, dass der Client auch der ursprüngliche Empfänger des Tickets ist. Im Unterschied zum Ticket kann der Authenticator nur einmal verwendet werden. Dieser wird jedesmal vom Client erstellt, sobald er einen Service nutzen möchte.
Der Authenticator hat folgenden Aufbau:

• Name des Clients
• Adresse des Clients
• einen Zeitstempel (timestamp)

Der Authenticator wird mit dem Session Key vom Client und dem jeweiligen Server verschlüsselt. Da der Authenticator vom Client erstellt wird und nur dieser, sowie der angesprochene Server, den Session Key besitzen, ist sichergestellt, dass der Client authorisiert ist.

Protokolle

Kerberos verwendet die folgenden drei Protokolle während der Authentifizierung.

Initial Ticket

Zunächst muss der Nutzer seinen User-Namen eingeben, danach wird im Hintergrund automatisch eine Anfrage an den Zentralen Server(ZS) geschickt. Diese enthält den User-Namen und den den Service der in Anspruch genommen werden soll. In diesem ist das der Ticket Granting Service. Nach Erhalt dieser Anfrage wird geprüft ob der User-Name in der Datenbank vorkommt.

Wenn das der FAll ist, schickt der ZS dem Client ein Session Key für ihn und den TGS, sowie ein Ticket für den TGS. Das ganze wird mit dem privaten Schlüssel des Clients kodiert. Der Client wird nun aufgefordert sein Passwort einzugeben. Mit Hilfe dieses Passwortes wird die Nachricht vom ZS dekodiert und gespeichert. Somit hat der Client die Möglichkeit mit dem TGS zu kommunizieren.

Server Ticket

Um einen Service nutzen zu können, benötigt der Client ein Ticket vom TGS. Um dies zu erhalten, sendet der Client, wie in der Abbildung gezeigt, eine Anfrage an den TGS. Die Anfrage enthält:

• den Namen des Servic, den der Client nutzen möchte
• das Ticket
• den Authenticator

Der TGS entschlüsselt das Ticket mit seinem Private Key und erhält den Session Key. Mit Hilfe dieses Session Key kann er nun, den Authenticator entschlüsseln, die User-Daten mit denen im Ticket vergleichen und somit den Client verifizieren.
Wenn kein Fehler aufgetreten ist, sendet der TGS eine mit dem Session Key verschlüsselte Nachricht an den Client:

Die Nachricht enthält das angeforderte Ticket für den Service und einen Session Key für den entsprechenden Server und den Client. Wobei die Ticket-Lebenszeit das Minimum zwischen der verbleibenden TGS-Ticket-Lebenszeit und der Standard-Lebenszeit des Tickets für einen Service ist.
Der User ist nun in der Lage einen Service anzufordern.

Request Service

Um einen Service nutzen zu können, stellt der Client eine Anfrage an den entsprechenden Server:

Die Anfrage besteht aus dem Authenticator und dem Ticket. Der Server entschlüsselt das Ticket mit seinem Private Key. Anschließend verifiziert er den Client mit Hilfe des Authenticator. Der Server vergleicht zusätzlich den Zeitstempel im Authenticator mit seiner aktuellen Zeit. Ist die Differenz zu groß, wird die Anfrage verworfen. Erfolgreiche Anfragen können außerdem gespeichert werden um Replay-Attacken zu verhindern. Damit der Server sich gegenüber dem Client authentifizieren kann, schickt dieser ebenfalls eine Nachricht.

Diese Nachricht enthält den um eins erhöhten Zeitstempel des Authenticator, welcher mit dem Session Key verschlüsselt ist. Nun ist der Client in der Lage, die beiden Zeitstemple zu vergleichen. Ist der Empfangene um eins höher, ist der Server der Gewünschte.

Gesamtüberblick

Diese Abbildung beschreibt die komplette Kommunikation zwischen den einzelnen Parteien, die für die Nutzung eines Service nötig ist.

1	Anfrage für TGS-Ticket
2	Ticket für TGS
3	Anfrage für Server-Ticket
4	Ticket für Server
5	Anfrage nach Service
6	Verifizierung des Servers

Vorteile und Nachteile

Die Vorteile des Kerberos-Systems sind zum Einen, die schon vorher erwähnten Vorteile eines SSO. Außerdem bietet Kerberos zusätzliche Sicherheit durch die Verwendung von Verschlüsselungsverfahren in der Datenübertragung. Kerberos ist des Weitern einfach zu implementieren, da es auf dem TCP/IP-Stack aufsetzt. Kerberos hat sich als Standard durchgesetzt und wird daher in gängigen Microsoft (NT-basierten) und Unix Netzwerken verwendet.
Der offensichtlichste Nachteil eines Kerberos-Systems ist sein hoher Traffic, wie man in der Gesamtübersicht sehen kann. Ein weiteres Problem ist, dass ein Ticket nur eine begrenzte Zeit gültig ist und demnach nach einer gewissen Zeit ein erneutes Einloggen des Users vorausgesetzt wird. Das Abschätzen der Lebensdauer eines Tickets ist schwierig, je länger sie ist, desto länger könnte ein Dritter mit einem abgefangenen Ticket Schaden anrichten. Ist sie zu kurz, ist ein häufiges Neuanmelden erforderlich, was die Vorteile des SSO schmälert. Als letzter Nachteil ergibt sich das sogenannte Proxy-Problem. Ein User kann einem Server, der evtl. Dienste auf anderen Servern für ihn ausführt nicht trauen oder hat zumindest keine Gewissheit über die Absichten des Servers.

CorSSO

CorSSO steht fur Cornell Single Sign On. Der Name leitet sich vom italienischen corso ab, was soviel bedeutet wie rennen. Im Übertragenden Sinne steht CorSSO also für Vortschritt oder Entwicklung. Im Unterschied zu Kerberos ist CorSSO ein verteilter Authentication Service, d.h es gibt nicht nur einen zentralen Server. Auf den verschiedenen Servern können verschiedene Regeln zur Anmeldung zum Tragen kommen (Policies) und diese Server können von verschiedenen Administratoren verwaltet werden. Weiterhin gibt es bei CorSSO keine begrenzte Laufzeit der Anmeldung, wie das durch die Lebenszeit des Tickets bei Kerberos der Fall ist.

Funktionsweise

Ein Nutzer, der einen Service in Anspruch nehmen möchte, muss sich gegenüber einem Subset von Authentication Servern authentifizieren, die in der Policy des Application Servers festgelegt sind. Hat der User sich gegenüber einer (Teil-)Menge dieser als vertrauenswürdig erwiesen, kann er den Service nutzen.

Policies

Eine Policie ist, grob gesagt, eine Vorschrift, die erfüllt sein muss, um sich authentifizieren zu können. Sie besteht aus mehreren Supolicies, so dass dem User die Wahl bleibt, wie er sich authentifizieren möchte: Eine Policy P ist eine Disjunktion von Subpolicies:

 
   $N_{1}$ v $N_{2}$ v ... v $N_{n}$
 

Die Policy ist erfüllt, wenn eine Subpolicy $N_{j}$ erfüllt ist.
Jede Subpolicie spezifiziert eine Menge an Authentication Servern:

 
   $N'_{i}$ = {$A_{i}^{1}$, $A_{i}^{2}$, ..., $A_{i}^{m}$}
 

Sowie einen Grenzwert t, welcher aussagt, wieviele "A" genügen, damit die Subpolicy erfüllt ist, Dabei legt jeder Authentication Server seine Authentifizierungsmethode selbst fest.
Die Verwendung von t ermöglicht somit die Authentifizierung auf mehreren Wegen und erschwert die ungewollte Authentifizierung, da mindestens t Server unter fremder Kontrolle sein müssten um eine Authentifizierung gewährleisten. Des Weiteren ist dieses System relativ fehlertollerant gegenüber Ausfällen von Authentication Servern.

Protokolle

Im Unterschied zu Kerberos werden bei CorSSO nur zwei Protokolle zur Authentifizierung verwendet und eines für die Einrichtung der Application Server.

Application Server Setup Protocol

Zunächst bestimmt der Application Server seine Policy und damit auch seine Subpolicies. Anschließend nimmt er die entsprechenden Authentication Server A in seine Subpolicies $N_{i}$ auf. Diese Authentication Server kreieren einen Private Key $k_{i}$ und teilen diesen mittels threshold cryptography untereinander auf. D.h. dass der Private Key in n unterschiedliche Teile zerlegt wird, wobei nur t Teile benötigt werden um den gessamten Schlüssel zu rekonstruieren. Daraus folgt, dass man sich nur gegenüber t Authentication Servern ausweisen muss, um den kompletten Schlüssel zu erhalten. Anschließend wird noch der Public Key $K_{i}$ an den Application Server gesendet. Nun sind die Application Server vorbereitet und die User können die erste Anfrage stellen.

Client Authentication Protocol

Der Client möchte sich nun gegenüber dem Application Server ausweisen und stellt hierzu eine Anfrage nach einer Policy. Der Application Server sendet seine Policy und der Client sucht sich eine Subpolicy aus. Hat der Client eine Subpolicy gewählt, muss dieser sich gegenüber den, in der Subpolicy spezifizierten, Authentication Servern ausweisen. Dazu sendet der Client die entsprechenden Informationen, welche mit dem Private Key des Clients signiert sind, an die Authentication Server. Diese überprüfen die Informationen auf Korrektheit. Sie senden anschließend ein Teilzertifikat an den Client. Das Teilzertifikat enthält:

• Name des Clients
• Public Key des Clients
• Name der Verwendeten Subpolicy
• Startzeit
• Endzeit

Der Public Key des Clients wird innerhalb des Client Access to Application Protocol benötigt. Über die Startzeit und Endzeit schweigen sich die Erfinder dieses Systems aus. Nach Erhalt von mindestens t Teilzertifikaten, kann der Client aus diesen ein komplettes Token berechenen und besitzt jetzt die Möglichkeit eine Applikation auf dem jeweiligen Server zu starten.

Client Access to Application Protocol

Wenn der Client bereits einen Authentication Token besitzt und eine Application staren möchte, tritt das Client Access to Application Protocol in kraft. Im ersten Schritt des Protokolls möchte der Application Server sicherstellen, dass der Client tatsächlich derjenige ist, der er vorgibt zu sein. Deshalb fordert der Client eine Challenge vom Application Server. In Folge dessen überträgt der Application Server eine beliebige Nachricht, die mit seinem Privaten Schlüssel signiert ist. Der Client, sendet diese signierte Nachricht, die erhaltene Nachricht noch einmal mit seinem Private Key signiert und das Authentication-Token dem Application Server. Der Application Server kennt den Public Key der Authentication Server (siehe Application Server Setup Protocol) und überprüft damit die Korrektheit des Tokens. Aus diesem wiederum, erhält er den Public Key des Clients, mit welchem er die Echtheit der soeben empfangenen, signierten Nachricht überprüft. Somit hat der Application Server Gewissheit, dass es sich um einen authorisierten Client handelt.

Vorteile und Nachteile

Der Hauptvorteil von CorSSO ist, dass die Rechenlast verteilt wird, es gibt nicht nur einen zentralen Server/TGS der die Tickets ausstellt, sondern die Clients, Application Server und Authentication Server übernehmen jeweils einen Teil der Arbeit. Ein weiterer Vorteil ist, dass durch die große Anzahl an Authenticaion Servern die administrative Last verteilt wird und zusätzlich die Stabilität des Systems gewährleistet ist.
Der Größte Nachteil von CorSSO ist, dass der geamte Traffic nicht verschlüsselt, sondern nur signiert ist. Desweiteren setzt CorSSO insgeheim eine universelle Policy für die Application Server voraus, da bei verschiedenen Policies auch verschiedene Token benötigt werden. Abschließend kann man noch erwähnen, dass CorSSO ein theoretisches Modell ist und keine Erfahrungen im praktischen Einsatz gemacht wurden, so dass keine Daten über die Umsetzbarkeit des Modells vorhanden sind.

Links

• Peer-to-Peer Authentication with a Distributed Single Sign-On Service. William Josephson, Emin Gün Sirer, Fred B. Schneider. Department of Computer Science, Cornell University Ithaca, New York 14853. 2004
• An Authentication Service for Open Network Systems. Jennifer G. Steiner, Clifford Neuman, Jeffrey I. Schiller. Massachusetts Institute of Technology Cambridge, MA 02139. 1988
• http://en.wikipedia.org
• http://de.wikipedia.org
• http://www.xml-dev.com/blog/index.php?action=viewtopic&id=21
• http://web.mit.edu/kerberos/www/
• http://www.cs.cornell.edu/People/egs/corsso/