Effizienter Einsatz der Kerberos V5 Authentifizierung in heterogenen Netzwerken

Inhaltsverzeichnis

1 Einleitung
1.1 Konventionen
1.2 Terminologie

2 Kryptografie in Netzwerken
2.1 Kryptoanalyse
2.2 Übermittlung vertraulicher Informationen
2.2.1 Public Key Encryption
2.2.2 Secret Key Encryption
2.2.3 Klassen von symmetrischen Chiffren
2.2.4 Betriebsarten
2.2.5 Data Encryption Standard
2.2.6 Triple Data Encryption Algorithm
2.2.7 Advanced Encryption Standard
2.2.8 Rivest Cipher
2.3 Integrität von Daten
2.3.1 Kryptografische Prüfsummen
2.3.2 Message Authentication Codes
2.4 Zusammenfassung

3 Kerberos im Überblick
3.1 Kerberos – ein Trusted Third Party System
3.1.1 Abstract Syntax Notation One
3.1.2 Principals, Instances und Realms
3.1.3 Passwords, Keys und Salts
3.1.4 Key Distribution Center
3.1.5 Tickets
3.1.6 Kerberised Services
3.1.7 Keytab Files
3.2 Einsatzgebiete für Kerberos
3.2.1 Single Sign-On
3.2.2 End-to-End Security
3.3 Das Funktionsprinzip von Kerberos
3.3.1 Authentication Service Exchange
3.3.2 Client/Server Authentication Exchange
3.3.3 Ticket Granting Service Exchange
3.4 Kerberos Delegation
3.4.1 Ticket Forwarding
3.4.2 Ticket Proxying
3.4.3 User-to-User-Authentisierung
3.4.4 Cross-Realm-Authentisierung
3.5 Encryption Types
3.6 Zusammenfassung

4 Evolution und umgebende Technologien
4.1 Evolution des Kerberos-Protokolls
4.1.1 V4-Limitierungen und -Schwächen
4.1.2 Änderungen von Kerberos V4 zu V
4.1.3 Neue V5-Protokoll-Eigenschaften
4.1.4 Authentisierung mittels Zertifikaten
4.1.5 Interfaces und Frameworks
4.2 Microsoft Implementierungen
4.2.1 Constrained Delegation
4.2.2 Protocol Transition
4.3 Umgebende Technologien
4.3.1 Domain Name System
4.3.2 Active Directory Domain Services
4.3.3 Lightweight Directory Access Protocol
4.3.4 NT LAN Manager Protocol
4.3.5 Network Time Protocol
4.3.6 Winbind
4.3.7 Pluggable Authentication Module
4.3.8 Name Service Switch
4.3.9 Secure Shell
4.4 Zusammenfassung

5 Linux/Unix-Systeme im heterogenen Umfeld
5.1 Ausgangssituation und Zieldefinition
5.2 Implementierungskonzept und praktische Umsetzung
5.2.1 Administrative Voraussetzungen für die Einbindung:
5.2.2 Technische Voraussetzungen und verwendete Komponenten
5.3 Anbindung eines Linux/Unix Host an ein Active Directory
5.3.1 Netzwerkeinstellungen des Clients
5.3.2 Konfiguration der Zeitsynchronisation
5.3.3 Kerberos-Konfiguration
5.3.4 Winbind als Schnittstelle zum Active Directory
5.3.5 Das Computer-Konto
5.3.6 Nutzung des Active Directory als Datenquelle
5.3.7 Festlegung von Zugriffsbeschränkungen
5.3.8 Test der Implementierung
5.4 Service Principals im Active Directory
5.4.1 Authentisierung mittels Keytab Files
5.4.2 Problematik der Übertragung von Keytab Files
5.5 Publikation eines Webservices
5.5.1 Kanonisierung von Host-Namen
5.5.2 Kerberos und der Apache Webserver
5.5.3 Einsatz von Kerberos bei einer Webanwendung
5.6 Kommerzielle Alternativen

6 Zusammenfassung.

ANHANG A - Liste der Konfigurationsdateien

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Listings

Literaturverzeichnis

1 Einleitung

Sicherheit gilt als wichtiges Gut in Zusammenhang mit IT-Umgebungen. Der geschlossene Bereich einer Workstation oder eines Server wird mit den technologisch neuesten Entwicklungen gegenüber Angriffen, Spionage und Manipulation abgesichert. Werden diese Geräte innerhalb eines Netzwerkes betrieben, muss der Sicherheitsaspekt auf die Integrität der Daten, die ein solches transportiert, erweitert werden. Insbesondere die Art und Weise, wie einzelne Benutzer und Services innerhalb eines Netzwerkes authentifiziert werden und vor allem wie Authentifizierungsinformationen im Netzwerk übertragen werden, ist dabei von Relevanz.

Gerade in größeren Organisationen mit historisch gewachsenen Netzwerkarchitekturen stellt eine einheitliche und sichere Authentifizierung der Benutzer eine große Herausforderung dar. Unterschiedliche Implementierungen und Individuallösungen verkomplizieren den Betrieb und verhindern für den operativen Bereich eine effiziente und zentral verwaltbare Benutzeradministration. Hier ist der Einsatz einer breit eingesetzten und erprobten Lösung wie dem Kerberos-Protokoll von Vorteil. Kerberos wurde als ein Internetstandard (RFC) spezifiziert und stellt damit einen universell einsetzbaren Lösungsansatz dar. Die vorliegende Arbeit beschäftigt sich mit der Realisierbarkeit einer solchen Authentifizierungsmethode für einen professionellen Einsatz innerhalb heterogener Netzwerke.

Der Fokus der folgenden Kapitel liegt neben den Begriffsbestimmungen zum Kerberos-Protokoll, dessen umgebende Technologien und der notwendigen Infrastruktur vor allem in der Beantwortung folgender Forschungsfrage: Welche Voraussetzungen sind zu schaffen, um in heterogenen Netzwerken eine einheitliche, effiziente und sichere Authentifizierung gegenüber einem Active Directory Verzeichnis realisieren zu können? Ziele dabei sind einerseits eine Authentifizierung der berechtigten Benutzer zur Verwaltung und Konfiguration der einzelnen Hosts, andererseits ein Single Sign-On für den Zugang zu unterschiedlichsten Services mittels des Kerberos V5-Protokolls auf Linux- beziehungsweise Unix-Systemen zu implementieren. Die Bereitstellung eines sicheren und vor allem effizienten Authentifizierungssystem sollte zu einer Vereinfachung und Vereinheitlichung des Vorgehens für unterschiedliche Administrationsbereiche (Client-, Server-, Benutzeradministration) beitragen, dabei aber bestehende Prozesse und vorhandene Authentifizierungsvarianten nicht beeinträchtigen.

1.1 Konventionen

Englische Bezeichnungen werden in dieser Arbeit für eine bessere Lesbarkeit mit führenden Großbuchstaben angeführt (beispielsweise das Key Distribution Center oder ein Active Directory). Listings, Auszüge aus Listings oder Ausgabewerte einer Konsole werden als grau hinterlegter Text dargestellt. Code oder Befehle werden in der nichtproportionalen Schriftart Courier dargestellt. Da der praktische Teil dieser Arbeit innerhalb eines Corporate Networks eines realen Unternehmens durchgeführt wurde, sind sämtliche angegebenen Namen, Adressen oder Teile daraus aus Sicherheitsgründen anonymisiert beziehungsweise abgeändert.

1.2 Terminologie

Authentisierung sowie Authentifizierung sind zwei häufig verwendete Begriffe in der vorliegenden Arbeit. Während im englischen Kontext lediglich der Begriff Authentication verwendet wird, gibt es im deutschen Sprachgebrauch einen wesentlichen Unterschied in der Bedeutung dieser beiden Ausdrücke: Als Authentisierung ist der Vorgang einer Identitätsbekundung zu bezeichnen. Zum Beispiel authentisiert sich ein Benutzer gegenüber einem Server durch die Eingabe eines Usernamens in Kombination mit einem geheimen Passwort. Eine Authentifizierung erfolgt in einem nächsten Schritt: Der Server validiert die Eingabe dieses Benutzers und stellt die Richtigkeit der Daten fest – der Benutzer wird in diesem Fall am Server erfolgreich authentifiziert.

2 Kryptografie in Netzwerken

Als Kryptografie bezeichnet man die Wissenschaft zur Erforschung und Realisierung von Methoden, die eine Verschlüsselung und anschließende Entschlüsselung von Daten ermöglicht. Die Kryptoanalyse beschäftigt sich hingegen damit, aus verschlüsselten Texten den ursprünglichen Klartext zu generieren, ohne dabei die verwendeten Schlüssel zu kennen. Innerhalb von Netzwerken versucht man für den Bereich der Informationstechnologie Kryptografie dafür zu verwenden, vertrauliche Informationen von geschützten Hosts über unsichere Netzwerke zu übermitteln oder die Authentizität einer Nachricht sowie die Integrität einer Datei sicherstellen zu können. Dabei werden Methoden eingesetzt, die es erlauben, Vorgänge der Ver- und Entschlüsselung ohne allzu großen Zeitaufwand durchzuführen. Der Vorgang der Kryptoanalyse ist hingegen mit sehr hohem Aufwand verbunden.

Dieses Kapitel zeigt nach einer kurzen Definition des Begriffs Kryptoanalyse Verfahren zur Übermittlung vertraulicher Informationen, erläutert die beiden Klassen von symmetrischen Chiffren und gibt einen Überblick über unterschiedliche Betriebsarten. Nach der Darstellung von Beispielen für symmetrische Verschlüsselungsalgorithmen werden Einwegfunktionen zur Prüfung der Integrität von Daten erläutert.

2.1 Kryptoanalyse

Gemäß Ertl (2007, S. 24ff) geht es bei einer Kryptoanalyse um die Rekonstruktion des Klartextes aus einem Geheimtext ohne Kenntnis des Schlüssels, um Aussagen über den Klartext (beispielsweise die Sprache), aber auch um Informationen über die verwendeten Schlüssel. Das ungewollte Aufbrechen eines Kryptosystems lässt sich folgendermaßen einteilen:

- Globale Deduktion: In diesem Fall wird der Schlüssel [Abbildung in dieser Leseprobe nicht enthalten] der ein äquivalenter Algorithmus gefunden und es ist möglich, alle auf dieser Basis verschlüsselten Nachrichten [Abbildung in dieser Leseprobe nicht enthalten] mittels [Abbildung in dieser Leseprobe nicht enthalten] zu dechiffrieren und so den ursprünglichen Klartext darzustellen
- Lokale Deduktion: Die lokale Deduktion beschreibt das Ableiten eines Klartextes aus einem einzelnen Geheimtext
- Informationsdeduktion: Dabei werden lediglich eingeschränkte Informationen über die verwendeten Schlüssel oder über den Klartext ermittelt.

Untersuchungen haben gezeigt, dass Einsatzfähigkeit und Stärke eines kryptografischen Verfahrens allein auf Basis der Geheimhaltung eines Schlüssels beruhen müssen und nicht auf der Geheimhaltung des Algorithmus. Nach Bless et al. (2005, S. 41) ist es somit sicherer, den Algorithmus durch Veröffentlichung möglichst vielen Fachleuten zur Verfügung zu stellen und diesen auf Schwächen zu prüfen. Die meisten der eingesetzten Verschlüsselungsalgorithmen sind bereits veröffentlicht und fordern Kryptoanalytiker heraus, Rückschlüsse auf die verwendeten Schlüssel zu ziehen.

2.2 Übermittlung vertraulicher Informationen

Zur vertraulichen Übermittlung von Informationen wird der Klartext einer Nachricht mittels Verschlüsselung in einen Geheimtext umgewandelt. Grundsätzlich werden zwei Arten der Verschlüsselung eingesetzt: die Public Key Encryption (asymmetrische Verschlüsselung) und die Secret Key Encryption (symmetrische Verschlüsselung).

2.2.1 Public Key Encryption

Bei der Public Key Encryption existiert ein Schlüsselpaar: ein Private Key und ein Public Key. Nachrichten werden mit dem Private Key verschlüsselt und mit dem Public Key entschlüsselt. Die beiden Schlüssel sind dabei unterschiedlich (siehe Abbildung 2-1). Das bekannteste Verfahren ist RSA, benannt nach seinen Erfindern Rivest, Shamir, & Adleman (1977).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Ver- und Entschlüsselung

2.2.2 Secret Key Encryption

Beim Verfahren der Secret Key Encryption besitzt sowohl der Sender als auch der Empfänger einen geheimen Schlüssel. Der Sender verschlüsselt seinen Klartext mit diesem Schlüssel und generiert daraus den Ciphertext. Dieser Vorgang wird als Verschlüsselung (Encryption) bezeichnet. Dabei wird eine Funktion angewendet, die zwei Parameter enthält: den Klartext und einen Schlüssel . Als Ergebnis der Funktion wird der Geheimtext (Chiffretext) ausgegeben:

Abbildung in dieser Leseprobe nicht enthalten

Für eine Entschlüsselung (Decryption) muss eine Umkehrfunktion existieren, die durch Eingabe des Geheimtextes und des Schlüssels wiederum den Klartext ergibt:

Abbildung in dieser Leseprobe nicht enthalten

Wie bereits in Abschnitt 2.1 erwähnt, sollte bei der Betrachtung der Algorithmen davon ausgegangen werden, dass beide Funktionen – sowohl Ver- als auch Entschlüsselungsfunktion – bekannt sind (Bless, et al., 2005, S. 33ff).

Übliche Verfahren für eine symmetrische Verschlüsselung sind der Data Encryption Standard (DES), der Triple Data Encryption Standard (3DES), der Advanced Encryption Standard (AES) oder Rivest Cipher 4 (RC4).

2.2.3 Klassen von symmetrischen Chiffren

Zusätzlich zur Art der Verschlüsselung wird bei der vertraulichen Übermittlung von Informationen zwischen zwei Klassen von symmetrischen Chiffren unterschieden: Blockchiffren (Block Mode Encryption) und Stromchiffren (Stream Mode Encryption). Sie differieren durch die Art der Eingabe. Blockchiffren teilen die zu verschlüsselnde Nachricht in Blöcke gleicher Länge, die unabhängig voneinander verschlüsselt werden. Da die Länge des Klartextes meist nicht dem Vielfachen der Blockgröße entspricht, wird der letzte Block des Klartextes durch ein sogenanntes Padding aufgefüllt (Bless, et al., 2005, S. 33ff).

Die Stromchiffre-Algorithmen unterscheiden sich von den Blockchiffren dadurch, dass sie nicht darauf angewiesen sind, eine gewisse Datenmenge zu kumulieren bis eine bestimmte Blockgröße erreicht wird, sondern sie setzen jedes Klartextzeichen sofort in ein kodiertes Ausgabezeichen um. Dabei wird ein Klartextbit mit einem Schlüsselbit XOR (eXclusive OR) verknüpft. Ein zweifaches XOR mit dem gleichen Bit-Wert stellt den ursprünglichen Wert wieder her, da aufgrund der Tatsache, dass [Abbildung in dieser Leseprobe nicht enthalten] ist, das Entschlüsseln mit dem gleichen Schlüssel und der gleichen Funktion wie das Verschlüsseln erfolgen kann. Diese Operationen sind sehr gut parallelisierbar und eignen sich deshalb für Echtzeitanwendungen wie zum Beispiel den Mobilfunk (Ertel, 2007, S. 51).

Abbildung 2-2 zeigt eine stark vereinfachte Darstellung dieser Encryption Modes.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Encryption Modes (in Anlehnung an Anzur, 2008)

2.2.4 Betriebsarten

Ein Problem bei der Verwendung von Blockchiffren ist, dass bei der Verwendung von gleichem Klartext und gleichem Schlüssel auch der Chiffretext gleich ausgegeben wird. Ein Angreifer wäre somit in der Lage, eine Wiederholung von Blöcken zu erkennen und daraus Rückschlüsse auf die ursprüngliche Nachricht zu ziehen. Um diesen Umstand zu vermeiden, kommen unterschiedliche Betriebsarten zum Einsatz:

- Der Electronic Codebook Mode (ECB) ist ein simpler Algorithmus und lässt relative einfach Blockstrukturen (als Beispiel Wiederholungen von 64-Bit-Blöcken) erkennen, da identische Klartextblöcke auch zu einem identischen Geheimtextblock führen und so die Kryptoanalyse vereinfachen
- Der Cipher Block Chaining Mode (CBC) unterteilt den Klartext ebenfalls in einzelne Blöcke. Wie Abbildung 2-3 zeigt, wird im Algorithmus der Geheimtextblock des vorangegangenen Klartextes mit dem aktuellen Klartextblock XOR verknüpft und anschließend verschlüsselt. So hängt die Verschlüsselung des aktuellen Blocks vom Ergebnis der vorangegangenen Blöcke ab. Anhand einer simplen Formel stellt sich der CBC-Modus nach Ertl (2007, S. 75) folgendermaßen dar:

Abbildung in dieser Leseprobe nicht enthalten

Bei Verwendung eines statischen Schlüssels werden jedoch auch im CBC-Modus identische Klartexte gleich verschlüsselt. Diese Einschränkung wird dadurch verhindert, dass für den ersten Block ein zufällig generierter Initialisierungsvektor (IV) verwendet wird. So wird sichergestellt, dass identische Klartexte keinerlei Analogien im Geheimtext zeigen (Ertel, 2007, S. 75ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: CBC-Modus Verschlüsselungssequenz

(in Anlehnung an RSA Laboratories, 2012)

- Eine dem CBC ähnliche Methode namens Cipher Text Stealing (CTS) unterscheidet sich dadurch, dass der letzte Textblock in seiner Länge nicht mittels Padding an die Blockgröße angepasst werden muss, wenn dieser kürzer als die vorhergegangenen sind, also der Klartext nicht genau an einer Blockgrenze endet
- Die Vertreter der Stream Mode Encryption sind nach Ertel (2007) Output Feedback Mode (OFB), Cipher Feedback Mode (CFB) und Counter Mode (CTR). Diese Varianten sind für die vorliegende Arbeit nicht weiter relevant und werden daher nicht näher betrachtet.

2.2.5 Data Encryption Standard

Der Data Encryption Standard (DES)-Algorithmus ist ein Vertreter der Blockalgorithmen. Seine Funktion soll an dieser Stelle zum besseren Verständnis der erweiterten Variante (Triple-DES) in Abschnitt 2.2.6 veranschaulicht werden. DES ist aufgrund zahlreicher erfolgreicher Angriffe umstritten und gilt als nicht sicher. Beim DES-Algorithmus werden 64-Bit-Klartext mit einem 64-Bit-Schlüssel in 64-Bit-Schlüsseltext umgewandelt. Der Schlüssel bei DES besteht aus 56 Bit relevantem Schlüsselcode. Acht Bit werden als sogenannte Paritätsbits verwendet. Der Klartext wird einigen Substitutionen und Permutationen unterzogen und anschließend mit dem Klartext XOR verknüpft. Diese Sequenz wird, wie in Abbildung 2-4 dargestellt, mit unterschiedlichen Anordnungen der Schlüsselbits 16-mal wiederholt (National Institute of Standards and Technology, 1999).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4: DES-Funktionsschema

(in Anlehnung an National Institute of Standards and Technology, 1999)

2.2.6 Triple Data Encryption Algorithm

Triple Data Encryption Algorithm (Triple-DES, auch als TDEA, Triple-DEA oder 3DES bezeichnet) als ein Vertreter der Blockchiffren ist eine Verbesserung der ursprünglichen DES-Version. Dabei wird die in Abschnitt 2.2.5 beschriebene Methode dreimal hintereinander mit zwei weiteren Schlüsseln angewendet. Nach dem National Institute of Standards and Technology (1999) gilt für die Verschlüsselung das Schema

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-5 zeigt eine vereinfachte Darstellung des Triple-DES-Verschlüsselungsverfahrens.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-5: Triple-DES-Funktionsweise

2.2.7 Advanced Encryption Standard

Im Zuge der Verbesserung vorhandener Standards initiierte laut Bless et al. (2005, S. 51ff) die amerikanische Normungsbehörde (National Institute of Standards and Technology, 2013) im Jahr 1997 eine offene Ausschreibung zur Entwicklung eines neuen Blockchiffre-Standards. Von diesem neuen Standard wurde eine Verarbeitungsmöglichkeit von symmetrischen Blockchiffren mit 128-Bit-Blockgrößen und Schlüssellängen von 128 Bit, 192 Bit und 256 Bit gefordert. Zusätzlich sollten aber auch andere Blockgrößen und Schlüssellängen möglich sein, sowie ein einfaches Design und eine einfache Implementierung in Hard- und Software ermöglicht werden. In einem mehrstufigen Verfahren wurde vom National Institute of Standards and Technology im Jahr 2000 letztlich der Advanced Encryption Standard (AES) ausgewählt. Der Algorithmus für AES ist auch als Rijndael-Algorithmus bekannt – abgeleitet von seinen belgischen Entwicklern Vincent Rijmen und Joan Daemen.

Abbildung 2-6 zeigt einen schematischen Ablauf des Rijndael-Algorithmus bei einer angenommenen Blockgröße von 128 Bit und einer Schlüssellänge von 192 Bit.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-6: Schematischer Ablauf von Rijndael

(in Anlehnung an Ertel, 2007)

Der Advanced Encryption Standard spezifiziert drei unterschiedliche Schlüssellängen mit 128, 192 und 256 Bit. Ein 128 Bit langer Schlüssel würde somit [Abbildung in dieser Leseprobe nicht enthalten] Schlüsselvarianten ermöglichen. Mit einer Schlüssellänge von 192 Bit ergeben sich [Abbildung in dieser Leseprobe nicht enthalten] Varianten und mit 256 Bit [Abbildung in dieser Leseprobe nicht enthalten]. Im Vergleich dazu bietet DES [Abbildung in dieser Leseprobe nicht enthalten] Möglichkeiten (Anzur, 2008, S. 67).

2.2.8 Rivest Cipher 4

Rivest Cipher 4 (RC4) als ein symmetrisches Verschlüsselungsverfahren ist eine Entwicklung von Ron Rivest, einem der Erfinder des RSA Public Key Kryptografie-Algorithmus und Mitbegründer der RSA Security Inc., einem amerikanischen auf IT-Sicherheit spezialisierten Unternehmen. Ursprünglich geheim gehalten, entstand durch eine anonyme Veröffentlichung des Quellcodes 1994 die Open Source Variante Arcfour (ARC4, Alleged RC4). RC4 (auch als Ron’s Code 4, RC2, RC5 oder RC6 bezeichnet) ist im Gegensatz zu den zuvor angeführten Blockchiffren ein Stromchiffre-Algorithmus. Das bedeutet, dass Klartext nicht in Blöcken, sondern jedes einzelne Zeichen byteweise verschlüsselt wird. Das in Abbildung 2-7 vereinfacht dargestellte Verfahren verwendet einen geheimen Schlüssel zur Chiffrierung und Dechiffrierung, der dem Sender und dem Empfänger bekannt ist. Bei der Chiffrierung wird durch den RC4-Algorithmus aus dem geheimen Schlüssel und einem Initialisierungsvektor ein Schlüsselstrom (Keystream) erzeugt, der mit dem Klartext (Messagestream) XOR verknüpft wird und daraus den chiffrierten Nachrichtenstrom (Cipherstream) erzeugt. Die variable Schlüssellänge kann bis 2048 Bit lang sein. RC4 ist vom Design her relativ einfach und wird, bedingt durch hohe Verarbeitungsgeschwindigkeiten, in vielen populären Standards und Protokollen wie Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA), Secure Socket Layer (SSL) oder Transport Layer Security (TLS) verwendet (Kaufman, Perlman, & Speciner, 2002, S. 92).

Die Sicherheit von RC4 ist bei richtiger Anwendung hoch, es sind aber Angriffspunkte bekannt. So existieren viele schwache Schlüssel, bei denen wenige Schlüsselbits einen großen Teil der initialen Permutation bestimmen, wodurch die ersten Bits der Ausgabe sehr stark von diesen Schlüsseln beeinflusst werden. Infolge dessen können Rückschlüsse auf Teile des Schlüssels gezogen werden. Eine weitere Schwäche ermöglicht es dem Angreifer, den gesamten Schlüssel durch Kenntnis einzelner Teile zu bestimmen. Die Sicherheitsmängel von WEP sind das Ergebnis eines falsch angewendeten RC4 (Bless, et al., 2005, S. 54ff).

Einer Publikation der Royal Holloway, University of London (2013), zufolge konnten bei Angriffen auf die angegebenen Einsatzszenarien, insbesondere im Bereich der TLS, begrenzte Mengen des zuvor per RC4 verschlüsselten Klartextes wiederhergestellt werden. Die Angriffe ergeben sich aus statistischen Mängeln im RC4-Algorithmus, wenn derselbe Klartext wiederholt verschlüsselt wird.

Seitens der Firma Microsoft wird explizit von der Verwendung des RC4-Protokolls bei TLS-Implementierungen abgeraten und eine Empfehlung zum Umstieg auf TLS 1.2 in Kombination mit AES als eine sicherere Alternative empfohlen (Microsoft Corporation, 2013).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-7: Rivest Cipher 4

(in Anlehnung an Anzur, 2008)

2.3 Integrität von Daten

Neben den bereits beschriebenen Verfahren zur Wahrung der Geheimhaltung von Informationen über ungesicherte Netzwerke sind auch die kryptografischen Funktionen zur Integrität sowie zur Authentizität relevant. Bei der Prüfung, ob eine Nachricht authentisch ist, sie also tatsächlich vom angegebenen Absender stammt und ob deren Inhalt während der Übertragung nicht verändert wurde, werden kryptografische Prüfsummen und als Message Authentication Codes (MAC) bezeichnete Verfahren eingesetzt.

2.3.1 Kryptografische Prüfsummen

Bless et al. (2005) zufolge sind kryptografische Prüfsummen oder auch kryptografische Hash-Funktionen kollisionsfreie Einwegfunktionen, die meist dazu eingesetzt werden, einen Fingerabdruck von Nachrichten zu erstellen. Sie sind im Gegensatz zu den in Abschnitt 2.2 angeführten Methoden nicht umkehrbar (siehe Abbildung 2-8). Aus einem sogenannten Hash-Wert (einer kryptografischen Prüfsumme) kann nicht die ursprüngliche Zeichenkette berechnet werden. In diesem Zusammenhang wird von einer Urbildresistenz gesprochen. Eine weitere grundlegende Funktion bei der Generierung eines Hash-Wertes ist die Verhinderung von Kollisionen. Eine derartige Kollision würde auftreten, wenn ein geänderter Klartext denselben Hash-Wert wie der ursprüngliche Text hätte.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-8: Kryptografische Hash-Funktion

Zusammengefasst sollten Hash-Funktionen folgende Eigenschaften aufweisen:

- Überaus geringe Wahrscheinlichkeit, dass eine Nachricht zu einem Hash-Wert passt (Urbildresistenz)
- Ebenso geringe Wahrscheinlichkeit, dass unterschiedliche Nachrichten denselben Hash-Wert besitzen (Kollisionsresistenz)
- Hash-Werte haben immer eine festgelegte Länge, unabhängig vom Umfang der Nachricht.

Der in der Literatur oft verwendete Begriff Checksum bezieht sich in diesem Zusammenhang immer auf kryptografische Hash-Funktionen und ist nicht mit einer Prüfsummenfunktion gleichzusetzen. Bei Prüfsummen (beispielsweise einer Quersumme) ist es möglich, die Nachricht derart zu verändern, dass eine vorgegebene Prüfsumme wieder korrekt ist (Bless, et al., 2005, S. 57ff).

2.3.2 Message Authentication Codes

Die Kombination aus Hash-Funktionen und geheimen Schlüsseln bietet die Möglichkeit, Nachrichten auf deren Integrität als auch auf deren Authentizität zu prüfen. Bei diesem in der symmetrischen Kryptografie eingesetzten Message Authentication Code (MAC)- oder auch Message Integrity Check (MIC)-Verfahren wird die Hash-Funktion über die zu sichernden Daten und einen eingebundenen Schlüssel berechnet. Dadurch wird verhindert, dass ein Angreifer in der Lage ist, eine Nachricht abzufangen, diese zu manipulieren und einen Hash-Wert neu zu berechnen, da er nicht im Besitz des eingebundenen Schlüssels ist (Bless, et al., 2005, S. 103ff).

Eine MAC-Implementierung im Kerberos-Protokoll ist HMAC (Keyed Hash Message Authentication Code). Dieser zweistufige Algorithmus erzeugt einen MAC durch eine Hash-Funktion in Verbindung mit einem symmetrischen Schlüssel. Nach Swoboda, Spitz, & Pramateftakis (2008) berechnet sich der HMAC einer Nachricht wie folgt:

Abbildung in dieser Leseprobe nicht enthalten

[Abbildung in dieser Leseprobe nicht enthalten] stellt hier eine kryptografische Funktion dar, eine Nachricht als Klartext. Im ersten Schritt werden zwei Zeichenketten generiert ([Abbildung in dieser Leseprobe nicht enthalten],[Abbildung in dieser Leseprobe nicht enthalten]), die der Länge des Eingangsblocks der Hash-Funktion entsprechen. Im zweiten Schritt werden der Schlüssel [Abbildung in dieser Leseprobe nicht enthalten] und [Abbildung in dieser Leseprobe nicht enthalten] XOR verknüpft. Der Schlüssel wird dabei mit 0x00 ergänzt, bis dieser ebenfalls die Länge des Eingangsblocks erreicht. Im nächsten Schritt wird die Nachricht daran angehängt (konkateniert) und darüber der Hashwert gebildet. Davor wird das Ergebnis einer XOR-Verknüpfung aus dem Schlüssel [Abbildung in dieser Leseprobe nicht enthalten] und [Abbildung in dieser Leseprobe nicht enthalten] erstellt. [Abbildung in dieser Leseprobe nicht enthalten] sollte dabei mindestens die Länge der Ausgabe der Hash-Funktion und maximal die Länge des Eingangsblocks haben. Ist [Abbildung in dieser Leseprobe nicht enthalten] zu kurz, wird der Schlüssel mit 0x00 aufgefüllt, ist er zu lang, wird [Abbildung in dieser Leseprobe nicht enthalten] verwendet. Abbildung 2-9 visualisiert den Vorgang der Ver- und Entschlüsselung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-9: Message Authentication Codes

(in Anlehnung an Kaufman, Perlman, & Speciner, 2002)

2.4 Zusammenfassung

Im Bereich der Kryptografie in Netzwerken werden zwei Arten der Verschlüsselung eingesetzt: asymmetrische Verschlüsselungsverfahren, gekennzeichnet durch den Einsatz von Schlüsselpaaren, und symmetrische Verfahren, die für Ver- und Entschlüsselung dieselben Schlüssel verwenden. Bei den symmetrischen Chiffren werden Block- und Stromchiffren unterschieden. Blockchiffren generieren aus der Eingabe Blöcke von definierten Größen, die anschließend unabhängig voneinander verschlüsselt werden. Stromchiffren verschlüsseln Nachrichten auf Basis einzelner Zeichen durch eine XOR-Verknüpfung mit einem Schlüsselstrom. Betriebsarten werden eingesetzt, um mögliche Muster innerhalb eines Chiffretexts zu verhindern. Vertreter der Blockchiffren sind der Data Encryption Standard, dessen erweiterte Variante des Triple Data Encryption Algorithm und der Advanced Encryption Standard (AES). DES sollte wegen sicherheitsrelevanter Schwächen nicht mehr eingesetzt werden. Die verbesserte Variante des Triple DES ist sicherer, aber weniger leistungsfähig als AES.

Ein Vertreter der Stromchiffren ist RC4, das wegen seiner hohen Verarbeitungsgeschwindigkeiten vermehrt Einsatz bei verschiedenen Standards und Protokollen (WEP, WPA, SSL oder TLS) gefunden hat, aktuellen Studien zufolge aber ebenfalls als angreifbar gilt.

Im Abschnitt zur Integrität von Daten wurden kryptografische Prüfsummen und Message Authentication Codes (MAC) beschrieben. Derartige Einwegfunktionen repräsentieren eine Art Fingerabdruck von zu übermittelnden Nachrichten. Ein Rückschluss auf den ursprünglichen Klartextinhalt ist als Folge der Eigenschaft einer Urbildresistenz nicht möglich. Ebenso müssen derartige Funktionen kollisionsresident ausgelegt sein, um sicherzustellen, dass unterschiedliche Nachrichteninhalte niemals gleiche Hash-Werte liefern.

Dieses Kapitel bildet die Basis für die im Folgenden angewendeten Verfahren zur Übermittlung vertraulicher Informationen und den dabei verwendeten Verschlüsselungsvarianten. Die Einwegfunktionen zur Wahrung der Integrität von Daten werden speziell im Abschnitt der Encryption Types behandelt. Die angeführten Verschlüsselungsalgorithmen werden dabei mit Betriebsarten kombiniert und bilden so die Grundlage zur Sicherung der Vertraulichkeit und Integrität von Daten.

3 Kerberos im Überblick

Kerberos beziehungsweise das Kerberos-Protokoll wurde am Massachusetts Institute of Technology (MIT) von Steve Miller und Clifford Neuman entwickelt. Das Protokoll entstand aus der Notwendigkeit heraus, dass für ein Forschungsprojekt eine verteilte Umgebung von mehreren Arbeitsplatzrechnern installiert wurde und dafür die bestehenden Sicherheitskonzepte nicht mehr genügten. Dieses als Athena-Projekt bekannte Forschungsprojekt bestand von 1983 bis 1991. Aus dem Projekt gingen mehr als 100 Softwareanwendungen hervor, die teilweise nachfolgende Entwicklungen wie das X-Window System, Thin-Computing, das Lightweight Directory Access Protocol (LDAP), Entwicklungen im Active Directory, das Domain Name System (DNS) sowie Instant-Messaging maßgeblich beeinflussten. Eines der Teilprojekte von Athena war Kerberos, das aktuell in der Version 5 vorliegt. Kerberos-Implementierungen basieren auf dem Request for Change RFC 1510 (1993), einem Internetstandard des Institute of Electrical and Electronics Engineers (IEEE) aus dem Jahr 1993. 2005 wurde der RFC 4120 (2005) veröffentlicht, der den RFC 1510 ablöste. Die Definition des Kerberos-Protokolls V5 erfolgt mittels einer allgemeinen Syntax-Beschreibungssprache, der Abstract Syntax Notation One (ASN.1). Innerhalb des Open System Interconnection (OSI)-Modells ist Kerberos in der sechsten Schicht (Presentation Layer) angesiedelt und kommuniziert über Port 88 mittels dem Transmission Control Protocol (TCP) und dem User Datagram Protocol (UDP) (Pröhl, 2011, S. 5ff).

3.1 Kerberos – ein Trusted Third Party System

Das Kerberos-Protokoll ermöglicht eine zuverlässige Authentifizierung über offene und unsichere Netze, innerhalb derer eine Kommunikation unterschiedlicher Benutzer, Client- sowie Server-Anwendungen, den sogenannten Principals (siehe Abschnitt 3.1.2), stattfindet. Das Protokoll selbst ist in der Lage, die Kommunikation zwischen diesen abzusichern, um die Echtheit der anfordernden Benutzer und Dienstanbieter garantieren zu können. Dazu sind durch geeignete weiterführende Maßnahmen die Absicherung der beteiligen Endpunkte sowie regelmäßige Aktualisierungen sämtlicher angreifbarer Komponenten eines Netzwerks sicherzustellen.

Nach dem MIT Kerberos Consortium (2007) ist Kerberos „[…] an authentication protocol for trusted hosts on untrusted networks.“ Hier ist besonderes Augenmerk auf die Trusted Hosts zu richten. Jegliche Kerberos-Strategien werden nutzlos, wenn Unberechtigte privilegierten Zugang zu Servern erlangen und die Möglichkeit haben, Dateien mit geheimen Schlüsseln zu kopieren. Kerberos als ein sogenanntes Trusted Third Party System nimmt eine Authentifizierung der Principals vor, eine Autorisierung muss von anderen Systemen erfolgen. Kerberos übernimmt auch keine Aufgaben eines Verzeichnissystems wie zum Beispiel die eines Active Directory- oder LDAP-Verzeichnisses.

Die beteiligten Principals authentisieren sich gegenseitig gegenüber einem Key Distribution Center (KDC, siehe Abschnitt 3.1.4), das als einzig vertrauenswürdige Komponente in der Lage ist, einen Nachweis der Identität zu erstellen. Dieses Schema wird dadurch ermöglicht, dass jeder Principal einen eindeutigen Secret Cryptographic Key (siehe Abschnitt 3.1.3) mit dem KDC teilt (Hughes, 1995, S. 92ff).

Nach Miller et al. (1988) wurden die originalen Anforderungen an das Kerberos-Design folgendermaßen festgelegt:

- Mutual Authentication (Ein- und Zwei-Wege-Authentisierung). Ein Client authentisiert sich gegenüber einen Server und, falls vom Client angefordert, identifiziert sich auch der Server gegenüber dem Client.
- Die Authentisierung muss ohne Übermittlung von Passwörtern in Klartext innerhalb eines Netzwerkes möglich sein.
- Keine Speicherung von Klartext-Passwörtern am KDC.
- Vom Benutzer eingegebene Klartext-Passwörter sollten so kurz wie möglich ausschließlich im Arbeitsspeicher gehalten und anschließend verworfen werden.
- Mögliche Authentisierungsmissbräuche sollten auf die Dauer der Login-Session beschränkt sein.
- Jede erfolgreiche Authentifizierung besitzt eine bestimmte Lebensdauer, die einer üblichen Login-Session entspricht. Innerhalb dieser Zeitspanne kann die Authentisierung so oft wie notwendig wiederverwendet werden.
- Die Netzwerkauthentisierung sollte vom Benutzer nicht wahrgenommen werden. Die Benutzer sollten eine Authentisierung nur bei der Eingabe eines Passworts zum Zeitpunkt der Anmeldung bewusst wahrnehmen.
- Der Aufwand für die Migration vorhandener Anwendungen mit anderen, weniger sicheren Authentisierungsmechanismen sollte so gering wie möglich gehalten werden.

3.1.1 Abstract Syntax Notation One

Wie in der Einleitung zu diesem Kapitel angeführt, beruht die Definition des Kerberos-Protokolls V5 auf einer allgemeinen Syntax-Beschreibungssprache, der Abstract Syntax Notation One (ASN.1). ASN.1 ist die Bezeichnung für eine Data Representation Language, die von der ISO/IEC (2008) standardisiert wurde. Sie ist eine Notation, die zum Nachrichtenaustausch zwischen kommunizierenden Applikationen über ein Netzwerk dient. ASN.1 ist eine maschinenunabhängige Sprache und ähnlich den Datenstruktur-Definitionen einer Programmiersprache. Sie stellt eine flexible Möglichkeit zur Verfügung, um aus einfachen Datentypen komplexe Datenobjekte zu konstruieren, Datenfelder als optional festzulegen, die Längen solcher Felder zu variieren und ermöglicht für zukünftige Versionen des Kerberos-Protokolls eine Implementierung zusätzlicher Verschlüsselungsverfahren. Jede verschlüsselte Nachricht wird durch Verwendung von ASN.1 in Bezug auf den Verschlüsselungsalgorithmus, die Schlüsselversionsnummer, unter der die Nachricht verschlüsselt wurde, und den aktuellen Schlüsseltext beschrieben. Dadurch wird eine große Flexibilität erreicht, die aber den Nachteil eines großen Overhead besitzt (Dubuisson, 2005, S. 83).

3.1.2 Principals, Instances und Realms

Jede Entität einer Kerberos-Implementierung wird als Principal bezeichnet. Dabei kann es sich um Kerberos-Benutzer oder auch um client- beziehungsweise server-seitige Dienste handeln, die innerhalb eines ungesicherten Netzwerks kommunizieren. Jedem Principal werden ein eindeutiger Namen sowie ein Long Term Key zugeordnet (siehe Abschnitt 3.1.3). Long Term Keys für Benutzer werden als Client Keys, für Services als Master Keys bezeichnet. Die Namenskonventionen sind durch eine hierarchische Struktur festgelegt. Der erste Teil eines Principal Names besteht aus einer (oder mehreren) Komponente(n), die, falls optionale Komponenten angegeben sind, durch einen Slash getrennt werden. So beginnt jeder Principal eines Benutzers mit dem Benutzernamen, gefolgt von einer optionalen Instanz. Diese Instanzen können für die Bezeichnung von speziellen administrativen Aufgaben verwendet werden. Als Beispiel kann ein Benutzer durch zwei Principal Names definiert werden: einer für die tägliche Arbeit am Computer, der zweite für die Funktion als Administrator (Garman, 2003, S. 17ff). Für die Schreibweise eines vollständigen Principal Name eines Benutzers für Kerberos V5 gilt somit:

username[/instance]@REALM

Bei Services wird zur Namensgebung die Bezeichnung des Services herangezogen, gefolgt vom Fully Qualified Domain Name (FQDN). Zusätzlich wird im zweiten Teil des Namens der Realm hinzugefügt, dem ein Benutzer beziehungsweise ein Service zugeordnet wird. Für Kerberos gilt die Konvention, dass eine Domain einem Realm entspricht (Garman, 2003, S. 17ff). Die Notation für einen Service Principal Name (SPN) lautet für Kerberos V5

service/full-qualified-domain-name[/component]@REALM.

Eine Kerberos-Architektur kann in unterschiedliche Domains, den Realms, gegliedert sein. Dadurch wird es möglich, die hierarchische Struktur einer Organisation besser zu repräsentieren. Jeder Realm stellt ein eigenes Kerberos-System mit eigenem Key Distribution Center dar. Zwischen diesen einzelnen Realms besteht eine eingeschränkte Vertrauensstellung (siehe Abschnitt 3.4.4).

3.1.3 Passwords, Keys und Salts

Passwörter sind ein essenzieller Bestandteil einer sicheren Kommunikation innerhalb eines Netzwerks. Da deren Übertragung im Klartext aufgrund der Kerberos-Definitionen nicht erfolgen darf, kommen Verfahren zum Einsatz, die diese alphanummerischen Passwörter in Binary Encryption Keys umzuwandeln. In Kerberos nennt sich eine solche Funktion zur Umwandlung eines Passworts string2key. Derart erzeugte Secret Cryptographic Keys werden als Long Term Keys zwischen zwei Principals ausgetauscht und eignen sich zum Ver- und Entschlüsseln von Nachrichten (Garman, 2003, S. 19ff).

Mit Kerberos V5 wurde die Methode des Salting eingeführt. Sie erweitert das Benutzerpasswort vor dem Hashing um entsprechende Strings. Standardmäßig wird dem Passwort der Realm des entsprechenden Benutzers hinzugefügt. Dadurch wird erreicht, dass identische Passwörter verschiedener Benutzer immer zu unterschiedlichen Schlüsselwerten führen. Ein weiterer Vorteil ergibt sich dadurch, dass, wenn ein Benutzer dasselbe Passwort in unterschiedlichen Realms verwendet und diese in einem dieser Realms kompromittiert werden, der Encrypted Key des anderen Realm nicht betroffen ist. Tabelle 3-1 führt die möglichen Konfigurationswerte für Salts an (Garman, 2003, S. 20).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-1: Konfigurationswerte für Passwort Salt

(MIT, Massachusetts Institute of Technology)

3.1.4 Key Distribution Center

Butler et al. (2006) beschreiben das Key Distribution Center (KDC) als die zentrale Komponente im Kerberos-Verbund, die den eigentlichen Kerberos-Dienst zur Verfügung stellt. Das KDC vermittelt als Trusted Third Party die Authentisierungen zwischen den Clients und den angeforderten Diensten. Innerhalb eines Kerberos Realms befindet sich mindestens ein KDC, der als separate physikalische Einheit ausgeführt sein sollte. Üblicherweise speichert die KDC-Software zusätzliche Informationen über die einzelnen Principals wie zum Beispiel die Lebensdauer der Passwörter, deren letzte Änderung und einiges mehr. Innerhalb einer Windows-Umgebung befinden sich diese Daten im Active Directory (siehe Abschnitt 4.3.2). Da im Bereich eines Kerberos Realm auch mehrere KDCs eingesetzt werden können, ist eine Replikation zwischen den einzelnen Datenbanken sicherzustellen. Der Kerberos-Dienst wird aus drei logischen Komponenten gebildet: einer Datenbank, einem Authentication Service und dem Ticket Granting Service.

- Kerberos-Datenbank: Die Kerberos-Datenbank (auch Principal-Datenbank) enthält sämtliche Principals des eigenen Realm und deren zugeordnete Keys. KDCs weiterer vorhandener Realms werden ebenfalls als Principals behandelt. Deren als Inter Realm Keys bezeichnete Schlüssel befinden sich ebenfalls in dieser Datenbank (siehe Abschnitt 3.4.4). Zusätzlich werden zu jedem Key die Verschlüsselungsart und eine Versionsnummer sowie weitere Attribute der Principals gespeichert
- Kerberos Authentication Service: Das Kerberos Authentication Service (AS oder teilweise auch KAS) als eine der drei Komponenten eines KDC ist für die Vergabe eines verschlüsselten Ticket Granting Ticket (TGT) an einen Client zuständig. Der Client übermittelt dem KDC dazu definierte Benutzerinformationen, das AS antwortet mit einem verschlüsselten TGT. Anschließend können weitere Prozesse für individuelle Service-Tickets angestoßen werden
- Ticket Granting Service: Die Vergabe der zuvor erwähnten individuellen Service-Tickets ist nun Aufgabe des Ticket Granting Service (TGS) (siehe Abschnitt 3.1.5). Dazu werden zwei Daten des Client verarbeitet: eine Ticketanforderung mit dem Principal Name des gewünschten Services und dem vom Authentication Service übermittelten TGT. Das TGS verifiziert dabei das TGT und retourniert entsprechende Service-Tickets (Garman, 2003, S. 21).

3.1.5 Tickets

Nach Tung (1999, S. 9ff) bilden Tickets die Basis sämtlicher Kerberos-Funktionalitäten. Sie sind verschlüsselte Datenstrukturen und werden vom KDC erzeugt. Tickets sind in etwa mit Lizenzdateien vergleichbar, die festlegen, wer Lizenzinhaber ist, wie lange die ausgestellte Lizenz gültig ist und welche Einschränkungen für die Verwendung gelten. Innerhalb einer Kerberos-Umgebung wird nach dem ersten Login ein initiales Ticket Granting Ticket (TGT) vergeben, das üblicherweise für die Dauer eines Arbeitstages gültig ist. Auf Basis dieses TGT werden kurzlebige Service-Tickets vergeben, die dem Benutzer eine für ihn transparente Authentisierung auf unterschiedlichen Systemen und Services erlauben. Eine vereinfachte Darstellung der Verwendung von Tickets im Kerberos-Verbund zeigt Abbildung 3-1.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1: Vereinfachte Darstellung von Kerberos-Tickets

3.1.6 Kerberised Services

Der Begriff eines Kerberised Service beziehungsweise der eines Kerberised Service Providers ist nicht Teil des RFC 4120 (2005), bezeichnet aber Services und Service Provider – beispielsweise LDAP, Common Internet File System (CIFS), Hyper Text Transport Protocol HTTP) – die durch entsprechende Konfiguration oder Programmierung in der Lage sind, Kerberos-Tickets zu behandeln und zu verarbeiten. Dazu stehen Bibliotheken, Interfaces und Frameworks zur Verfügung, welche die Kerberos-Mechanismen implementieren (siehe Abschnitt 4.1.5).

3.1.7 Keytab Files

Keytab Files sind Passwort- oder Service-Schlüsseldateien eines Netzwerkservices. Sie werden in Kombination mit Kerberised Services oder bei automatisierten Scripts verwendet und dienen der Speicherung des Long Term Keys (siehe Abschnitt 3.1.3) eines Principals. Sie enthalten einen vom Passwort abgeleiteten Hashwert (One Way-Algorithmus zur Umwandlung eines Passwort Strings in einen Schlüssel) der mit dem KDC geteilt wird und ermöglichen auf diese Weise die Ausführung von Anwendungen oder Diensten ohne der Notwendigkeit, Passwörter eingeben oder in Klartext speichern zu müssen. Grundsätzlich sollten Keytab Files, ähnlich wie private Schlüssel von Zertifikaten, äußerst sorgsam behandelt werden und deren Zugriff auf den Root Account eingeschränkt werden. Es wird empfohlen, sie ausschließlich auf dem betroffenen Host zu speichern und sie von Sicherungsmaßnahmen auszunehmen.

3.2 Einsatzgebiete für Kerberos

Garman (2003, S. 11ff) fasst die Grundfunktionalitäten für sichere Netzwerke mittels der drei „A“ zusammen: Authentifikation, Autorisierung und Auditierung.

- Als Authentifikation wird der Prozess zur Prüfung der Identität eines bestimmten Benutzers bezeichnet. Dazu wird der Benutzer nach bestimmten Informationen gefragt, die ausschließlich in dessen Besitz sein sollten und eine Authentisierung ermöglichen. Diese Informationen sind Teil einer oder mehrerer Faktoren: Etwas, das sie wissen (Something You Know – SYK), etwas, das sie haben (Something You Have – SYH), und etwas, das sie sind (Something You Are – SYA). Faktor eins, die gebräuchlichste Form der Authentisierung, ist das Wissen eines Passworts. Beim zweiten Faktor geht es um den Besitz einer geeigneten Hardware. Als Beispiel ist hier der weit verbreitete RSA SecureID Token zu nennen, der einen Embedded Encryption Key und ein kleines Display enthält. Ein Algorithmus liefert jede Minute eine sechsstellige Zahlenkombination, mit deren Hilfe der Authentisierungsprozess durchgeführt werden kann. Vergleichbare Systeme (Smartcards) arbeiten nach einem ähnlichen Prinzip. Der dritte und letzte Faktor betrifft biometrische Eigenschaften, welche die zu authentifizierende Person besitzt. Hierzu gehören Fingerabdrücke, Iris-Scans, Stimmen- oder Gesichtserkennung
- Die Autorisierung regelt den Zugriff oder die Ablehnung der Verwendung von spezifischen Ressourcen basierend auf der Identität des Benutzers. Eine Autorisierung erfolgt mittels Access Control Lists, welche die Identität des Benutzers mit definierten Rechten verknüpfen. Dazu werden Informationen über Gruppenzugehörigkeiten, User Policies und weitere Daten gespeichert. Die Autorisierung ist grundsätzlich von einer erfolgreichen Authentifizierung abhängig
- Auditierung (oft auch als Audit oder Accounting bezeichnet) als drittes „A“ ist als ein reaktives System für die Protokollierung der vorangegangenen Prozesse in Logdateien zuständig. Mithilfe der Audit Logs sind sämtliche Vorgänge von Authentisierungen, Authentifikationen sowie Autorisierungen nachvollziehbar.

Kerberos übernimmt in diesem Kontext die Aufgabe der sicheren Prüfung der Identität eines Benutzers (Authentifizierung) über das Netzwerk. Es ist nicht in der Lage, die Autorisierung oder die Protokollierung der durchgeführten Aktionen (Auditierung) vorzunehmen. Werden diese beiden „A“ von anderen Systemen realisiert, so können in Kombination mit Kerberos zwei zentrale Einsatzgebiete innerhalb eines modernen Netzwerkbetriebs ermöglicht werden: Single Sign-On (SSO) und die Möglichkeit einer End-to-End Security. Grundvoraussetzung dafür ist, dass seitens des Benutzers eine korrekte Authentisierung vorgenommen wird. Ein solches Authentisierungsverfahren (nicht zu verwechseln mit Authentifizierungsverfahren) beweist gegenüber einem Prinzipal die Identität des Benutzers.

Grundlegende Intention der informatisch betrachteten Authentifikation ist der eindeutige Nachweis der Identität eines Benutzers (einer Instanz) gegenüber einer anderen Kommunikationsinstanz, und der sich durch diese Verifikation implizit ergebenden Restriktionen für diesen Benutzer in einem betrachteten Nutzungskontext. Durch diese eindeutige Identitätsprüfung soll somit gewährleistet werden, dass zum einem dem Benutzer eine identitätsbezogene Kommunikationsbeziehung zugesichert werden kann und zum anderen nur die dem Benutzer anvertrauten Zugriffsrechte in Anspruch genommen werden können (Hoier, 2003).

Als Beispiel zeigt eine Anmeldung an einem Unix-System ein derartiges Verfahren. Der Benutzer wird im Zuge des Anmeldeprozesses nach einem persönlichen Passwort gefragt. Der Login-Prozess erzeugt aus diesem Passwort einen Hash-Wert, den Crypt-String, und vergleicht diesen mit einem in einer Textdatei (/etc/passwd) gespeicherten String. Stimmen beide überein, hat sich der Benutzer gegenüber dem Unix-System erfolgreich authentisiert. Da auch dieses Verfahren Schwächen hat, werden bei Unix-Systemen ebenso vermehrt geeignete Passwort-Verfahren eingesetzt. Als Beispiel sei hierzu bcrypt, ein plattformübergreifendes, speziell für die Generierung von Hash-Werten von Passwörtern entwickeltes Verfahren, erwähnt.

3.2.1 Single Sign-On

Während rein auf Windows basierende Umgebungen bereits eine durchgängige Authentifizierung ermöglichen, kommen in heterogenen und historisch gewachsenen Systemen oft unterschiedliche Mechanismen zur Benutzerauthentifizierung zum Einsatz. Der Einsatz von Kerberos als ein standardisierter Authentifizierungsmechanismus unterstützt nach Tsolkas & Schmidt (2010) die Möglichkeit des Single Sign-On. Dies bedeutet, dass ein Anwender durch eine einmalige Eingabe eines Passworts Zugriff auf sein System und die ihm zur Verfügung stehenden Services innerhalb des Netzwerks erhält. Seine Zugangsdaten werden auf sichere Art und Weise mittels Tickets an die beteiligten Services weitergegeben. Bis zum Ablauf der Gültigkeit seiner Session gilt der Anwender als authentifiziert – daher rührt auch die Bezeichnung Primärauthentisierung.

Ein SSO-System besteht aus einer Menge an Softwarekomponenten, die normalerweise über ein Netzwerk verteilt sind und die einem einmal an seiner Workstation angemeldeten Benutzer gestatten, ohne weitere Authentisierungsmaßnahmen Anwendungen zu starten oder Netzwerk-Anmeldungen durchzuführen (Tsolkas & Schmidt, 2010, S. 191).

Tsolkas & Schmidt (2010) sehen aber eine Schwierigkeit bei der Modifizierung von Zielsystemen, da diese oftmals nicht mit der Kerberos-Technologie kommunizieren können. Im heterogenen Umfeld müssten Legacy Systeme aufwendig und kostenintensiv angepasst und weitere Komponenten eingesetzt werden. Eine durchgehende Realisierung von SSO würde sich somit unnötig verteuern und für eine Verwaltung des Benutzer Repository müssten zusätzliche Lösungen implementiert oder direkt auf den Zielsystemen durchgeführt werden.

3.2.2 End-to-End Security

Moderne, für eine größere Anzahl an Nutzern erstellte Applikationen werden als mehrschichtige Modelle (Multi-Tier-Anwendungen) konzipiert. Üblicherweise greifen die Anwender über ein webbasiertes Frontend auf einen Anwendungsserver zu, der im Hintergrund als weitere Anwendungsschicht eine Datenbank verwendet. Dazu werden generische Konten auf den einzelnen Hosts eingerichtet, die wiederum Zugriff auf andere Services haben. Dies stellt insofern ein Problem dar, als die Sicherheit der Anwendung direkt am Anwendungsserver liegt und eine Anpassung beziehungsweise Erweiterung dieser Sicherheit letztendlich nur durch die Änderung des Quellcodes möglich ist. Außerdem ist nur schwer nachvollziehbar, wer welche Zugriffsberechtigungen auf Informationen hat (Tec Channel, 2007).

Ein Lösungsansatz ist der Einsatz von Kerberos und die Möglichkeit zur Delegation. Hierbei gibt sich das sogenannte Frontend gegenüber dem Backend als Benutzer aus. Das Service im Backend registriert dann einen Zugriff des am Einstiegspunkt authentifizierten Principal. Dabei werden drei unterschiedliche Methoden angewendet: Ticket Forwarding (siehe Abschnitt 3.4.1), Ticket Proxying (siehe Abschnitt 3.4.2) sowie die Microsoft Variante der Constrained Delegation (siehe Abschnitt 4.2.1).

3.3 Das Funktionsprinzip von Kerberos

Dieser Abschnitt befasst sich mit dem eigentlichen Funktionsprinzip von Kerberos V5. Anhand von schematischen Grafiken werden die Protokollnachrichten illustriert. Für die Beispiele gilt die Annahme, dass alle Principals einen gültigen Long Term Key besitzen, der ebenfalls dem KDC vorliegt. Für den Benutzer wird der Client Principal Name

alice@CAMPUS02.EDU

angenommen, der Service Principal Name (SPN) des aufzurufenden Dienstes lautet

HTTP/web.campus02.edu@CAMPUS02.EDU oder auch

BOB/unixsvr.campus02.edu@CAMPUS02.EDU.

Alle beteiligten Hosts sind in Bezug auf deren Systemzeit mittels Network Time Protocol (NTP) synchronisiert und verwenden denselben Domain Name Service für eine Host-Namensauflösung.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-2: Abkürzungen im Nachrichtenverlauf

Tabelle 3-2 enthält die in den folgenden Abschnitten verwendeten Abkürzungen. Als Beispiel ist

TICKET: {PN_ALICE, IP_ALICE, SK₁, …} K_BOB

folgendermaßen zu interpretieren: Ein Ticket mit der Bezeichnung TICKET enthält den Principal Name von ALICE, die Client IP von ALICE, einen Session Key 1, … verschlüsselt mit dem Master Key von BOB. Diese an Steiner, Neuman, & Schiller (1988) angelehnte Notation wurde zugunsten einer besseren Lesbarkeit in den angeführten Beispielen leicht abgeändert.

Zusätzlich wird bei den angeführten Beispielen vorausgesetzt, dass vor jedem Authentisierungsvorgang seitens eines Clients ein DNS Service entsprechend Abbildung 3-2 zur Lokalisierung des zuständigen KDC kontaktiert wurde. Dazu setzt der Client im Schritt (1) einen DNS Query in Richtung DNS Server ab und erhält in (2) ein Array der verfügbaren KDC innerhalb seines Realm. Der Client versucht die retournierten IPs zu kontaktieren und verwendet jenes KDC, welches als erstes antwortet.

[...]