[Seminarthemen WS08/09] [ < ] [ > ] [Übersicht]

3 Kerberos

Protokoll

Für das Kerberos-Protokoll werden drei Pakete benötigt. Das vierte ist optional für den Fall, dass auch der Server sich gegenüber den Client authenti&64257;zieren soll. Da das dritte Paket schon einen Teil hat der durch Ks verschlüsselt ist und eine Sequenznummer enthält. Da Ks nur A und B bekannt ist kann nur B die Sequenznummer um eins erhöhen.

  1. KRB_AS_REQ: A → AS : A, B, time, NA
  2. KRB_AS_REP: AS → A : {Ks, time, NA}KA, {Ks, A, time}KB
  3. KRB_AP_REQ: A → B : {time, seqnumber}Ks, {Ks, A, time}KB
  4. KRB_AP_REP: B → A : {time, seqnumber + 1}Ks (optional)

PIC

Abbildung 3: Einfache Authenti&64257;zierung im Kerberos-Protokoll (Nach [NT94, S. 35])

In Abbildung 3 ist eine vereinfachte Form von Kerberos dargestellt. Der Client möchte mit B ein Verbindung aufbauen und sendet dies mit einer Nouce und einem Zeitstempel an AS.

AS erstellt den zufälligen, temporären Schlüssel Ks. Der Schlüssel wird zusammen mit der Zeichenkette „A“ und einen Zeitstempel mit dem Schlüssel von B verschlüsselt. Dieser Teil der Nachricht ist das sogenannte Ticket für B. A kann dieses Ticket nicht entschlüsseln, da nur B und AS im besitzt von KB, mit dem das Ticket verschlüsselt ist, sind. Zusätzlich wird mit dem Schlüssel von A die Nouce von A, ein Zeitstempel und Ks verschlüsselt.

A kann nun sicher sein, dass die Nachricht von AS ist da nur AS seinen Schlüssel KA kennt. Außerdem kann es sich nicht um eine aufgezeichnete Nachricht handeln, da A Zeitstempel und Nouce überprüft. Im Gegensatz zu dem Needham-Schroeder-Protokoll ist das Ticket nicht mit dem geheimen Schlüssel von A geschützt. Da aber in dem Ticket das „A“ enthalten ist, kann nur A damit zu B eine Verbindung aufbauen. Dadurch müssen weniger Daten verschlüsselt werden.

Nun baut A die Verbindung zu B auf. Hierfür sendet er das Ticket, welches er von AS erhalten hat unverändert an B weiter. Außerdem wird ein Teil der Nachricht mit dem Schlüssel Ks verschlüsselt. Dieser Teil enthält eine zufällige Startsequenznummer und ein Zeitstempel.

Wenn B dieses Paket erhält entschlüsselt er das Ticket mit seinem Schlüssel KB und überprüft den Zeitstempel. Wenn das Paket zu alt ist wird es verworfen. So ist sichergestellt das es sich nicht um ein Replay handelt. Da nur AS das Ticket erstellt haben kann und es „A“ enthält, ist sicher, dass das Ticket von AS für A ausgestellt wurde. Außerdem kann Ks außer B nur A und AS bekannt sein.

Falls A sichergehen muss, dass die Verbindung erfolgreich aufgebaut wurde und die Identität von Büberprüfen muss, wird eine 4 Nachricht von B versendet. In dieser wird die Sequenznummer um eins erhöht verschlüsselt mit Ks an A zurück geschickt. Dies ist vergleichbar mit der Funktion f(x) bei dem Needham-Schroeder-Protokoll in der Nachricht 5.

Alle Pakete enthalten Zeitstempel um Replay-Angri&64256;e zu erschweren. Dies ist in den entschlüsselten Mittschnitten in Abbildung 4 und 5 zu sehen.

PIC

Abbildung 4: Wireshark-Analyse des KRB-AS-REQ Paketes

PIC

Abbildung 5: Wirshark-Analyse des KRB-AS-REP Paketes

A benötigt so für jeden Verbindungsaufbau zu einem Server KA. So müsste man entweder KA auf dem Rechner zwischenspeichern oder der Benutzer müsste jedes mal sein Passwort eingeben, damit KA berechnet werden kann. Um dies zum umgehen wird eine Zwischenschicht eingezogen. Der Client fordert erstmal nur ein sogenanntes Ticket Granting Ticket (TGT) bei dem AS an. Mit diesem TGT kann der Client ein Ticket bei dem Ticket Granting Server (TGS) ein Ticket für einen konkreten Server anfordern.

  1. KRB_AS_REQ: A → AS : A, TGS, time, NA
  2. KRB_AS_REP: AS → A : {Ks1, time, NA}KA, {Ks1, A, time}KTGS
  3. KRB_TGS_REQ: A → TGS : {time, seqnumber}Ks1, {Ks1, A, time}KTGS
  4. KRB_TGS_REP: TGS → A : {time, seqnumber + 1, Ks2}Ks1, {Ks2, A, time}KB
  5. KRB_AP_REQ: A → B : {time, seqnumber}Ks2, {Ks2, A, time}KB
  6. KRB_AP_REQ: B → A : {time, seqnumber + 1}Ks2 (optional)

So werden weniger Pakete welche mit KA verschlüsselt sind übertragen. Da bei vielen Angri&64256;en auf kryptographische Verfahren viele Pakete benötigt werden, erschwert dies potentielle Angri&64256;e.

PIC

Abbildung 6: Authenti&64257;zierung im Kerberos-Protokoll (Nach [NT94, S. 37])

PIC

Abbildung 7: Aufbau zu einem Server, wenn ein TGT bereits vorhanden ist.

In Normalfall sind AS und TGS auf dem gleichen Server und wird als Key Distribution Center (KDC) bezeichnet. Die Netzwerkteilnehmer werden als Principal bezeichnet. Jeder Principal gehört zu einem Realm. Ein Realm ist ein Kerberosnetz. Es ist aber auch möglich Kerberos über Realmgrenzen hinweg als authenti&64257;zierungs Protokoll zu verwenden. Um dies Schlüssel von Server für Dienste von denen der Nutzer zu unterscheiden haben die normalerweise die Form host/<servername>@<realm>. Um Administratorenkonten von Benutzerkonten zu trennen, gibt es die Konvention diese in der Form <name>/admin@<realm> zu benennen.

Schlüsselgenerierung

Im Normalfall geben Benutzer ein Passwort ein um sich an einem PC anzumelden. Für Kerberos werden, aber Schlüssel benötigt. Dafür werden kryptographische Hashfunktionen benutzt um einen Schlüssel für das gewählte Verschlüsselungsverfahren. Zum Teil wird noch ein Funktion n-fold benutzt um die Schlüssel besser über den Schlüsselraum zu verteilen.

Alle Kerberos StringToKey Funktionen haben nach [RFC3961, S. 5] drei Parameter. Ein Password-String, ein Salt-String und weitere Parameter als String. Für Triple-DES, sollten die Parameter leer sein. Der Salt ist eine Zeichenfolge um aus gleichen Passwörtern verschiedenen Schlüssel zu generieren. Dies ist im Normalfall der Name des Realm gefolgt vom Benutzernamen. So ist es nicht möglich eine vorberechnete Liste von Schlüsseln zu erzeugen. Der Salt wird einfach hinten an das Passwort angehängt.

Im nochfolgen Codelisting ist die Kerberos String-To-Key-Funktion in Python zu sehen.

1def krb5int_dk_string_to_key(password, salt, params): 
2    if (params != ~~): 
3        raise Exception, ~invalid params~ 
4    keybytes = 21 
5    keylength = 24 
6    foldkey = k5_des3_make_key(krb5_nfold(password + salt, keybytes) 
7                               , keylength) 
8    key = krb5_derive_key(foldkey,’kerberos’) 
9    return key

Als erstes wird eine n-fold Funktion ausgeführt um eine Kette von 21 Byte zu bekommen. Diese Zeichen werden mit 3 Paritätsbits aufgefüllt, um die für einen Triple-DES-Schlüssel benötigen 24 Byte zu bekommen. Dieser Schlüssel wird genommen und damit das Wort „kerberos“ verschlüsselt. Das Ergebnis wird zugleich für die ersten 8 Byte des Schlüssels und als neuer Klartext für den nächsten Block benutzt.

Diese Funktion kann man als kryptographische Hashfunktion bezeichnen. Für die ganze Funktion ist der Quellcode im Anhang A zu sehen.

ASN.1

Die Pakete für Kerberos 5 sind in der Abstract Syntax Notation One (ASN.1) de&64257;niert. (vgl. [BMB+05, S. 417]) ASN.1 ist Teil des 7 Schichten OSI-Modells. Es ist der der Standard für die 6. Schicht (Darstellung). Es de&64257;niert eine Syntax ähnlich wie die Backus-Naur-Form. So kann Kerberos auf allen Protokollen genutzt werden wo ASN.1 de&64257;niert ist. ASN.1 de&64257;niert eine Codierung, so dass Strings ohne Längenbeschränkungen übertragen werden können.

Folgendes Listing zeigt die De&64257;nition des PrincipalName in der [RFC4120].

1PrincipalName   ::= SEQUENCE { 
2        name-type       [0] Int32, 
3        name-string     [1] SEQUENCE OF KerberosString 
4}

In einem Paket, der drunterliegenden Schicht, kann da zu Beispiel folgender Hex String auftreten: „3012a003020101a10b30091b07636c69656e7431“. Wenn man sich die Zeichen in einer ASCII-Representation anschaut erhält man den String: „0........0...client1„ Mit einem ASN.1 decoder (z. B. pyasn1 für Python) lässt sich dies decodieren und lesen.

1SEQUENCE { 
2   [0] { 
3      INTEGER 1 
4   } 
5   [2] { 
6      [0] {KerberosString client1} 
7   } 
8}

So kann bei der Protokollde&64257;nition sich auf den Inhalt konzentriert werden. Auch ist ASN.1 auf vielen Arten von Netzwerken de&64257;niert. So ist Kerberos 5 nicht wie Kerberos 4 auf TCP-Netzwerke beschränkt.

Delegation

In verteilten Systemen besteht oft die Notwendigkeit, dass ein Server Daten andere Server für seine Aufgabe benötigt. Dabei sollte der Zugri&64256; mit der Identität des Endnutzers und nicht der des Frontendservers durchgeführt werden. So werden die Daten des Backend nur an berechtigte Personen übermittelt und in die Logdateien der Endbenutzer eingetragen welcher den Zugri&64256; durchgeführt hat.

In dem Kerberos-Protokoll sind zwei Lösungsmöglichkeiten für das Problem vorgesehen. Zum einen lässt sich ein Ticket als PROXIABLE deklarieren. Wenn der empfangende Server bei KDC als berechtigt eingetragen ist, kann dieser bei dem KDC ein Ticket im Namen des Benutzers für den Backend Server beantragen. Dabei muss der Client die Identität des Backend Systems kenne. (vgl. [RM03, S. 251f])

Eine zweite Möglichkeit ist das Paket als FORWARDABLE zu markieren. Dann kann der Server sich ein TGT bei dem KDC holen und damit im Namen des Benutzers andere Systeme ansprechen. Dabei sollte die Kon&64257;guration so eingeschränkt werden das nur Tickets für benötigte Server geholt werden können. (vgl. [RM03, S. 252])

[Seminarthemen WS08/09] [ < ] [ > ] [Übersicht]