Was uns Magic Kingdom in Sachen Authentifizierung lehrt – Kerberos aus der Nähe betrachtet, Teil II

Schon im letzten Blogpost ging es darum, Kerberos anhand von Parallelen des Authentifizierungsprozesses im Magic Kingdom zu erläutern. Natürlich ist dieser Vergleich nicht 1:1 übertragbar, aber er eignet sich wesentlich besser, als sich durch die Standard-Kerberos-Protokoll-Diagramme zu schlagen. Glauben Sie mir.

Wir sind zurück in Disney World: Sie sind nun im Themenpark, haben Ihre Eintrittskarte gelöst und wollen jetzt eines der Fahrgeschäfte ausprobieren. Handelt es sich beispielsweise um den „Space Mountain“ werden Sie kein valides Ticket auf ihrer Standardeintrittskarte vorfinden. Sie gehen also zu einem der Parkwächter, der ihre Karte überprüft und Ihnen dann gegen Bezahlung ein Space Mountain-Ticket aushändigt.

Das zeigen Sie zusammen mit der Standardeintrittskarte am Eingang des Fahrgeschäftes vor und stellen sich in die Warteschlange.

Sie möchten Zugriff auf den Server?

Im Modell Disney World gehen Sie nicht direkt zum Fahrgeschäft, wenn Sie diese Fahrt nicht vorher bezahlt haben sollten. Stattdessen dient das Standardticket nur als Nachweis für den berechtigten Zugang zum Park und ist für einige kleine Fahrgeschäfte gültig. Für die begehrten unter ihnen müssen Sie in einem weiteren Schritt gesonderte Tickets lösen. So wird verhindert, dass Zaungäste sich unrechtmäßig Zutritt zum Park verschaffen und ohne zu bezahlen in den Genuss aller Fahrgeschäfte kommen.

Ähnlich wie bei Disney (allerdings nicht wie bei NTLM) besitzt Kerberos eine spezielle Interaktion, die man in der Client-Anwendung als Ticket Granting Ticket (TGT) findet. Das ist sozusagen die Version des Disney-Passes, um Zugang zum Ticket Granting Server (TGS) zu bekommen. Der TGS ist allerdings nicht der tatsächliche Server, auf den der Benutzer bei seiner Anfrage zugreifen soll. Er ist vielmehr ein hocheffizienter Wächter, der sämtliche der virtuellen Schreibarbeiten untersucht.

Um mit dem TGS zu interagieren nutzt die Client-Anwendung zunächst den Hashwert des Benutzerpasswortes, um die vom Server zurück gesendete Session-ID entschlüsseln zu können (siehe Teil I). Der Client sendet dann seine Identität in Form eines verschlüsselten Benutzernamens und der IP-Adresse zusammen mit der Session-ID und dem Namen des Dienstes, auf den er zugreifen will sowie das TGT an den Ticket Granting Server.

Die Verschlüsselungs-Entschlüsselungs-Technik funktioniert wie folgt: Der TGS verwendet einen speziellen Schlüssel von Kerberos um das TGT zu entschlüsseln. Vom TGT ruft er die Session-ID ab, die dann benutzt wird, um die Benutzeridentitätsdaten zu entschlüsseln. Die Informationen im TGT müssen strikt die Identitätsdaten des Clients sein. Anderenfalls lehnt der TGS die Anforderung ab und stuft den Client als nicht authentifiziert ein.

Ab diesem Zeitpunkt weiß der TGS, wer den Zugriff auf den Server angefordert hat. An dieser Stelle können Organisationen auch eigene Berechtigungsprüfungen hinzufügen. Denn nicht jeder, der auf einen Server (Sharepoint, CRM, etc.) zugreifen möchte, ist auch immer dazu berechtigt. Kerberos ist glücklicherweise flexibel genug, um diese Art von Erweiterungen zu ermöglichen.

Zugriff auf den Server erlangen

Der TGS reagiert nun mit einem weiteren verschlüsselten Ticket. Dieses Mal speziell für den Server, auf den der Nutzer zugreifen möchte. Sie können das mit dem eigentlichen Ticket für eine Fahrt im Disney Land vergleichen.

Der TGS erzeugt noch eine weitere Zufallszahl, beispielsweise die Server-Session-ID und leitet dann ein verschlüsseltes Server-Ticket an den Client weiter. Dieses enthält die Server-Session-ID zusammen mit einem Zeitstempel und anderen Identitätsdaten. Wie beim TGT ist das Server-Ticket (ST) mit einem weiteren geheimen Schlüssel von Kerberos verschlüsselt. Der TGS sendet ebenfalls die Server-Session-ID zurück, allerdings verschlüsselt mittels der Session-ID aus der ersten Interaktion. Wenn Sie meiner Erklärung noch folgen: die Verwendung von zufälligen Session-IDs und speziellen geheimen Schlüsseln ist eine Erinnerung an den Login-Prozess in meinem ersten Artikel – unter der Haube verbirgt sich auch hier dasselbe Protokoll.

Wenn all das funktioniert, wäre eine einfache Interaktion mit dem eigentlichen Dienst (der Disney-Fahrt) nun wünschenswert. Auch dafür steht Kerberos bereit. Die Client-App entschlüsselt zuerst die Server-Session-ID, die der TGS wieder mithilfe der gespeicherten Session-ID versendet hat. Wieder sendet er Identifizierungsdaten, dieses Mal mit der Server-Session-ID verschlüsselt, die er gerade zuvor erhalten hat, und er sendet auch das vom TGS generierte Server-Ticket. Der eigentliche Server interagiert mit Kerberos, um den geheimen Schlüssel zu erhalten. Damit kann dann die Entschlüsselung stattfinden und Client-Anforderung wie Server-Ticket validiert werden.

Und hier endet der Prozess! Wenn Sie meine Erklärung dennoch unbefriedigend finden, schauen sie sich hier eine Alternative an. Sie erklärt Ihnen Kerberos so verständlich, dass ihr auch ein (smarter) Fünfjähriger folgen kann.

Kurze Wiederholung: Unterscheidungsmerkmale und Vorteile von Kerberos

Zusammenfassend lässt sich festhalten: Kerberos ist ein System, das eine starke Authentifizierung unterstützt. Die Authentifizierungsprüfungen erfolgen mit jedem Schritt. Dabei Tickets mit kryptisch gesicherten Zeitstempeln zu verwenden ist eine effektive Idee. So wird es beispielsweise erschwert Replay-Attacken durchzuführen.

Sowohl TGT als auch ST werden mit geheimen Schlüsseln, welche nur Kerberos kennt, verschlüsselt. So kann der Client selbst die einzelnen Tickets niemals entschlüsseln. Der Nachweis über den rechtmäßigen Besitz des Tickets erfolgt lediglich über die jeweiligen Session-IDs.

Kerberos basiert also auf einer sehr cleveren Idee. Es ist das virtuelle Äquivalent eines validierten Reisepasses oder Dokuments, das eine Identität beweist und folglich überaus schwer zu fälschen ist.

Kerberos wurde ursprünglich in der Zeit vor dem Internet entwickelt und häufig als zu mächtig eingeschätzt. In großen und unsicheren Umgebungen zeigt sich aber wie zuverlässig Kerberos ist und sozusagen ein Erzfeind aller Hacker. Die Wissenschaftler des MIT hatten mit Kerberos eine Art Vorzeit-Internet geschaffen – das mit vielen Servern kommunizieren konnte und prinzipiell gar nicht so verschieden von unserem heutigen Internet ist. Der Austausch mit dem Server ist nur ein Ein-Schritt-Verfahren, im Vergleich zu dreien bei NTLM. Ein Client kann so seine Server-Tickets auf einen Schlag einsammeln und benötigt dann bei jeder Server-Anfrage nur eine einzige Nachricht.

Was Microsoft von Kerberos hält? Microsoft hat eine eigene, erweiterte Version von Kerberos erstellt und es zum Standard-Authentifikations-Protokoll seit der Veröffentlichung von Windows 2000 gemacht.

The post Was uns Magic Kingdom in Sachen Authentifizierung lehrt – Kerberos aus der Nähe betrachtet, Teil II appeared first on Varonis Deutsch.