Ticket based Authorization Methods

Ticketbasierte Systeme

Überblick: Was sind Ticketbasierte Systeme?

Idee

In einer unsicheren Netzwerkumgebung sollen Nutzern bestimmte Rechte eingeräumt werden. Diese Rechte sollen nur dem jeweiligen User eingeräumt werden, und mögliche Angriffe (Identifikationsdiebstahl von anderen, unberechtigten Usern) verhindern. Dabei soll aber nicht jeder Dienst, den der User nutzen darf, eine Datenbank mit z.B. den Userpasswörtern führen, da dann ein Passwortwechsel durch den User sehr aufwändig wäre. Auch soll nicht jeder Dienst eine Datenbank darüber führen, was der einzelne User darf, diese Datenbank sollte auch besser zentral gepflegt werden (kann dadurch leichter gewartet und angepasst werden).

Authentifikationsserver

ist in der Lage, User zu Authentifizieren, z.B. per User-Passwort. Dieser Server ist der einzige, der die User-Passwörter o.ä. kennt, folglich auch der einzige, auf dem diese Daten aktualisiert werden müssen, wenn sie sich ändern.

Service-Granting Server

weiß, welcher User welche Dienste nutzen darf (steht in seiner Datenbank), kann den User aber nicht direkt Authentifizieren. Allerdings traut dieser Server einer Authentifkationsbestätigung des Authentifikationsservers, die an diesen speziellen User gebunden ist.

Application Server

kann weder den User authentifizieren, noch weiß er, welche Rechte der User hat. Allerdings traut er dem Service-Granting Server, wenn dieser bestätigt, dass der spezielle anfragende User den Dienst nutzen darf.

Verwendete Begriffe / Abkürzungen:

AuS

Authentification Server (der Server, der die anfängliche Authentifikation vornimmt, es gibt nur einen AuS)

TGT

"Ticket granting Ticket (vom AuS dem User zugestellt, mit diesem Ticket kann der User mit dem SGS kommunizieren, um sich Tickets für bestimmte Dienste ausstellen zu lassen)

SGS

"Server granting Service" (der Server, der den durch den AuS authentifizierten Usern nach Abgleich der Rechte der User in seiner Datenbank dem User ein Ticket (TGS) zum Nutzen bestimmter Dienste bzw. ApS bekommt, falls er dazu berechtigt ist. Es gibt nur einen SGS)

TGS

"Ticket granting Service" (vom SGS ausgestelltes Ticket, mit dem der User sich gegenüber einem Dienst bzw. ApS als Berechtigt ausweisen kann, um diesen Dienst zu nutzen)

ApS

Applikation Server (der Server, der den Dienst zur Verfügung stellt, es gibt mehrere ApS)

Allgemeines Vorgehen:

(bisher: auf Grund der Idee von Kerberos, muss noch mit den anderen Systemen gegengecheckt werden)

Gererelle Annahmen:

• Wenn vom "Passwort" die Rede ist, sind natürlich auch andere Authentikikationsmöglichkeiten, wie z.B. eine public-/private Key-Infrastruktur möglich, bei denen anstelle von einem Passwort die entsprechenden Schlüssel zum Verschlüsseln der Kommunikation verwendet werden. Der Einfachheit halber rede ich hier aber nur von Passwörtern.
• Natürlich schickt in der Regel nicht der User die Tickets/Anfragen los, sondern Programme (Clients) im Auftrag des Users. Da aber der User die Kommunikation veranlasst (und sei es, in dem er den Client automatisch zu einem bestimmten Zeitpunkt starten lässt), spreche ich davon, dass der User mit den Servern oder Diensten kommuniziert.
• Natürlich kann es theoretisch auch mehrere AuS und SGS geben, um z.B. die Serverlast besser zu verteilen, dann müssen diese natürlich alle jeweils auf dem aktuellen Stand gehalten werden. Der Einfachheit halber (und weil man nur einen braucht), spreche ich im Folgenden jeweils davon, dass es nur einen dieser Server gibt. Bei mehreren müssen diese Server ihre Passwörter / Keys natürlich teilen.

Das hier folgend beschriebene Vorgehen beruht auf dem Vorgehen von Kerberos4, sollte aber als allgemeine Illustrierung, wie ein Ticketbasiertes System funktionieren kann, reichen. Abweichungen anderer Ticktesysteme werden bei den jeweiligen Systemen beschrieben. Eine Oberflächliche Beschreibung, wozu Kerberos dient, und welche Anforderungen es weshalb erfüllen muss, kann man auch - sehr einfach und allgemeinveständlich beschrieben - in [5] nachlesen. Das hier dargestellte Verfahren ist etwas vereinfacht, Kerberos4 verwendet z.B. zusätzlich in den Tickets noch Timestamps, die regeln, bis wann das jeweilige Ticket gültig ist.(bisher: auf Grund der Idee von Kerberos, muss noch mit den anderen Systemen gegengecheckt werden)

Szenario: ein User, der dem System bekannt ist, setzt sich an eine allgemein zugängliche Workstation und möchte seine Mails lesen.

1. ein TGT anfordern (am AuS identifizieren)
   1. User schickt sein Usernamen (im Klartext) an den AuS

  User -> {Username} -> AuS

1. 1. AuS überprüft, ob der Username bekannt ist. Wenn ja, kennt der AuS das Passwort des Users, und nutzt dieses, um folgende Dinge an den User zu schicken: ein TGT und ein zufällig erzeugten Session-Key (zur Verschlüsselung der Übertragung an den SGS) - dieser Key wird mit dem Passwort des Users (so, wie es in der Datenbank des AuS vermerkt ist) verschlüsselt. Da dieser mit dem Passwort des Users verschlüsselt ist, kann nur derjenige, der das Passwort kennt, diesen entschlüsseln (was theoretisch nur der AuS und der User selbst sein sollten). Das TGT besteht aus: TGT{Session-Key für SGS,Username,Rechneradresse des Users} und ist mit dem Passwort / geheimen Schlüssel des SGS verschlüsselt, das nur dieser (und der AuS) kennt, nicht jedoch z.B. der User. So ist sicher gestellt, dass nur der AuS und der SGS den Inhalt des TGT lesen oder manipulieren können.

AuS -> {Session-Key für SGS}(Userpasswort), TGT{Session-Key für SGS,Username,Rechneradresse des Users}(SGS-Passwort) -> User

1. ein TGS anfordern (am SGS identifizieren)
   1. User schickt das TGT (so, wie er es bekommen hat) und einen mit dem vom AuS erhaltenen Session-Key für die Kommunikation mit dem SGS verschlüsselten Authentificator, bestehend aus: Authentificator{Username,Rechneradresse des Users,benötigter Dienst} an den SGS.

User -> Authentificator{Username,Rechneradresse des Users,benötigter Dienst}(Session-Key für SGS), TGT -> SGS

1. 1. Der SGS kann zunächst den Authentificator nicht entschlüsseln, der benötigte Session-Key wird ihm jedoch im TGT mitgeteilt. Dieses wird nun zunächst entschlüsselt, und mit Hilfe des dort enthaltenen Session-Keys dann der Authentificator. Wenn Username und Rechneradresse im TGT und im Authentificator übereinstimmen, und beide korrekt entschlüsselt werden konnten, ist der User dejenige, für den er sich ausgibt. Nun überprüft der SGS in seiner Datenbank, ob der User berechtigt ist, den angeforderten Dienst zu nutzen, und schickt ihm ggf. wiederum ein TGS (verschlüsselt mit dem Passwort des entsprechenden ApS). Der User kann dieses TGS wiederum weder lesen, noch manipulieren, da er das benötigte Passwort zum entschlüsseln nicht kennt.

SGS -> {Session-Key für ApS}(Session-Key für SGS), TGS{Session-Key für ApS,Username,Rechneradresse des Users}(ApS-Passwort) -> User

1. Den Dienst nuzten (beim ApS identifizieren)
   1. User schickt das TGS (so, wie er es bekomen hat) und einen Authentificator{Username,Rechneradresse des Users}, letzterer mit dem neuen Session-Key verschlüsselt, an den ApS.

User -> Authentificator{Username,Rechneradresse des Users)(Session-Key für ApS), TGS -> ApS

1. 1. Der ApS kann den Authentificator mit Hilfe des im TGS abgelegten Session-Keys entschlüsseln und die dortigen Angaben mit denen im TGS überprüfen. Wenn diese Überprüfung erfolgreich verlief, ist der User (hoffentlich) derjenige, für den er sich ausgibt und berechtigt, den Dienst zu nutzen. Der ApS gewährt dem User jetzt den Dienst (Zugriff auf seine Mailbox), die Kommunikation zwischen ApS und User erfolgt auch weiterhin verschlüsselt (mit dem Session-Key für den ApS).

Vorstellung einiger Systeme, Stärken und Schwächen

Kerberos

Das Vorgehen von der aktuellen Kerberos-Version (Kerberos5) entspricht im Groben dem oben beschriebenen. Neben dem oben genannten leistet Kerberos5 noch folgendes:

• Tickets sind zeitlich begrenzt (gelöst per Timestamp und Zeitspanne, die jeweils auf dem TGT bzw TGS vermerkt werden) (auch bei Kerberos4)
• um Replay-Attacken zu unterbinden, sind die ApS mit einem Replay-Cache ausgestattet, in dem vermerkt wird, welche Tickets bereits verwendet wurden. (Wenn allerdings der Replay-Chache nicht groß genug ist, kann durch gezielten Überlauf des Caches evtl. doch eine Replay-Attacke durchgeführt werden)
• um zu verhindern, dass jemand einen bekannten (aber nicht seinen) Usernamen überträgt, um dann mit Hilfe des zurückerhaltenen Packages offline das Passwort des Users zu erraten / knacken, wurde bei kerberos5 "Preauthentification" eingeführt. Eine Variante davon ist, dass ein aktueller Zeitstempel, verschlüsselt mit dem User-Passwort, übertragen werden muss, der User also durch Kenntnis seines Passworts nachweist, dass er derjenige ist, für den er das TGT haben möchte.
• bei Kerberos können merere Netze ("Realms": Bereiche, die von einem AuS / SGS gemanaget werden) miteinander verbunden werden, so dass man auch außerhalb seines Netztes Dienste nutzen kann.
• Seit Kerberos5 können neben DES auch noch weitere symmetrische Verschlüsselungsverfahren als extra Module implementiert werden, die Distribution des MIT unterstützt jedoch gegenwärtig nur DES.
• Tickets können vor Ablauf der Gültigkeit Erneuert werden (damit man sie länger nutzen kann)
• die Gültigkeit von Tickets kann widerrufen werden, bevor ihre Lebensdauer abgelaufen ist.
• als Hashing-Algorithmen werden in der MIT-Distribution gegenwärtig CRC-32, MAC, MD4 und MD5 unterstützt
• AuS und SGS sind bei Kerberos im KDC (Key distribution center) vereint
• neben einem Master-KDC sind mehrere Slave-KDC möglich, um die Last zu verteilen und somit die Verfügbarkeit zu erhöhen

Schwächen und Grenzen von Kerberos (vgl. auch [6] (Probleme und Grenzen von Kerberos sind u.a. hier analysiert: http://www.cs.columbia.edu/~smb/papers/kerblimit.usenix.pdf)

• kann gegenwärtig nicht mit Smartcards umgehen (ist in Entwicklung)
• kann gegenwärtig nicht mit asymmetrischen Verschlüsselungsverfahren arbeiten (ist in Entwicklung)
• ist immer noch begrenzt anfällig für Replay-Attacken (allerdings muss dafür der Replay-Cache komplett gefüllt werden, so dass Einträge wieder gelöscht werden müssen)
• Uhrzeiten zumindest vom KDC und den ApS, müssen synchronisiert werden
• wer ein fremdes User-Passwort kennt, kann alles tun, was dieser User auch tun kann
• wer den Key eines ApS kennt, kann diesen Dienst freizügig nutzen (im Namen aller User), da er die TGS manipulieren kann (und damit auch einen Session-Key wählen kann)
• KDC kennt alle Passwörter und Keys, muss daher besonders geschützt werden
• Kerberos kann die Gültigkeitsdauer von Tickets nur zeitlich begrenzen, nicht aber die Häufigkeit der Nutzung