[ Main | Local ]

Kerberos Basics

Authentifizierung
Authorisierung
Auditing

Kerberos Symm. Verschlüsselung (Private Key) vs. Public Key Infrastruktur
Beschreibung als Identity-Verifying Proxy oder als Trusted Third-Party Authentication System.
Kerberos macht ausschließlich Authentifizierung!

Terminologie:
Realm
Prinzipale
Instanzen
Tickets

KDC - Key Distribution Center. Der zentralisierte authentifizierungs Dienst. Dieser Server
vergibt die Kerberos Tickets und kennt von allen beteiligten Prinzipalen (User-Instanzen,
Maschinen, Services etc.) die geheimen Schlüssel. Diesem Server vertrauen alle Prinzipale
einer Realm vollständig, blind.

AS
TGS


Tickets
Ticket Forwarding

Protokoll

Client -> AS um ein Ticket Granting Ticket zu erhalten:
Client: Client Prinzipal, Client Zeitstempel, krbgt Prinzipal Name, Gewünschte Lifetime
AS: Generiert Session Key 
Sendet: Mit User Key verschlüsselt: [Session Key für User, krbtgt Prinzipal Name, Lifetime;
Mit TGS Key verschlüsselt: [Session Key für TGS, Client Prinzipal, Lifetime, KDC Zeitstempel,
Client IP]].
Die Innenklammer ist das TGT.

 
Kerberos
Principal: 

User: loginname, 0 oder Attribut (root), Authentifizierungsdomäne
Service: servicename, Maschinenname, Authentifizierungsdomäne
==> kshell.this_host

Bsp. 
Immer:
Principalname.Instance@REALM

Benutzerprincipal:
root.admin@ORM.ORG

Serviceprincipal:
rcmd.no5@ORM.ORG

Wichtige Files:

/etc/krb.conf       ordnet Knoten einem Kerberos-Server zu.
/etc/krb.realm      welcher Rechner gehört zu welcher Realm.
/tmp/tkt0           Keyfile für User 0. Ticket Cache File.
/etc/krb-svrtab     Passwörter für Dienste.
.klogin             wie die .rhosts, nur für Kerberos.

K5MUTE              unterdrückt Fehlermeldungen.

Verteilen der Service-Keys erfolgt über die serielle Leitung
bei AIX PSSP (/spdata/sys1/k4srvtabs/.srvtab).

k4list -srvtab      zeigt die Schlüssel für die Services

hmacls  /spdata/sys1/spmon     hier findet sich der Admin + Rechte

Funktion:
Der Principal holt sich Tickets für Services vom TGS (weiter unten)
Das Ticket ist Information über den Principal, verschlüsselt
mit dem privaten Schlüssel des Service.

{Tc,s}Ks = {s, c, addr, timestamp, lifetime, Kc,s}Ks
{Client Ticket für Service} verschlüsselt mit Schlüssel Ks
(der private Schlüssel des Service).

Im Ticket sind:

Triple Service, Triple Client, IP Client, Zeitstempel, TTL, Session Key

Mit dem Ticket wird ein Authentikator geschickt:

Authentikator: Ein Zeitstempel, der mit der Systemzeit abgeglichen
wird.

Triple Client, IP Client, Zeitstempel (verschlüsselt mit Session-Key).

{Ac}Kc,s = {c, addr, timestamp}Kc,s

Den privaten Schlüssel des Services (Ks) kennen nur der Service
und der Kerberos-Server.
Den Session-Key (Kc,s) kennen Client, Server und Kerberos.
Dieser Schlüssel wird auf dem Kerberos-Server neu erzeugt.

KDC (Kerberos Distribution Center) == TGS (Ticket Granting Server)
und AS (Authentication Server) - meist auf einer Maschine.

USer hat Key in AS Aus Passwort generiert.
Service hat Key in AS.

User will Service nutzen -----> AS (Authentication Server)
Meldet Service an AS            generiert neuen Session Key (2 mal)
                                Kennt Keys Ks, Ku. Sendet:
                         <----- I: [Service Kse] Ku
User decryptet I         <----- II: [User Kse] Ks 
und erhält so den
Session Key Kse.
Speichert Paket II.

Sendet Authenticator
und Ticket:
III: [User Zeit]Kse      -----> Service decryptet Paket II mit
II: [User Kse]Ks         -----> eigenem Schlüssel Ks, erhält 
                                Session Key Kse.
                                Der muß ok sein, da es sein eigener
                                geheimer Schlüssel beweist.
                                Server kennt jetzt den Session Key
                                und den Namen des User.
                                Decryptet Paket III und prüft die 
                                Zeit.
                                Dann wird der Service gewährt.

Soll der Service sich auch gegenüber dem Client authentifizieren,
dann wird vor der Gewährung des Service noch ein viertes Paket
vom Server an den Client geschickt:

User                     <----- Service sendet:
                                IV: [Servername, Timestamp aus III]Kse

So bekommt der User ein Session Ticket vom Server AS.          
Dieses TGT nutzt er dann für Anfragen an den TGS.
Es wird dann dieser Key benutzt.

Ticket Granting Protokoll

User will TGS nutzen -----> Kerberos
                     ---- c,tgs --->   
                                generiert neuen Session Key (2 mal)
                                Kennt Keys Ktgs, Ku. Sendet:
                         <----- I: [TGS Kse] Ku
User decryptet I         <----- II: [User Kse] Ktgs 
und erhält so den
Session Key Kse.
Speichert Paket II.
                    <--- S(s,tgs)Kc T(c,tgs)Ktgs
Sendet Authenticator
und Ticket:
III: [User Zeit]Kse      -----> TGS decryptet Paket II mit
II: [User Kse]Ktgs       -----> eigenem Schlüssel Ktgs, erhält 
                                Session Key Kse.
                    ---- s, A(c) S(c,tgs) T(c,tgs)Ktgs 

                  <--- S(c,s) S(c,tgs), T(c,s) Ks      TGS
                  ----> A(c) S(c,s), T(c,s) K(s)       Server

K(x)  privater Key von x
S(x,y) Session Key für x und y
T(c,s) Ticket von c für s = {c,s,S(c,s),Zeit,Lebensdauer, ...}
A(c) Authenticator von c = {c,Zeit}

 
Netzwerk Ports, die Kerberos braucht:
Kerberos V5
Server Server-Port Client-Port Service
KDC 88/udp/tcp  1024+ Kerberos V5 Ticket Service
KDC 749/tcp 1024+ Kerberos V5 kpasswd (Passwort Änderung durch CLient)
KDC 749/udp 1024+ Kerberos V5 Administrations Service
KDC 4444/udp 1024+ Kerberos V5/V4 Ticket Konversion
Master-KDC 464/udp 1024+ Kerberos V5, altes Passwort Änderungs Tool

Eigentlich braucht man nur den Port 88. Die anderen Ports geben 
zusätzliche Services, und können auch nur bei Bedarf geöffnet werden.

Kerberos V4
Server Server-Port Client-Port Service
KDC 750/udp/tcp  1024+ Kerberos V4 Ticket Service
KDC 751/udp/tcp 1024+ Kerberos V4 Administrations Service
KDC 761/tcp 1024+ Kerberos V4 kpasswd (Passwort Änderung durch CLient)

Im Fall von Kerberos V4 ist es generell keine gute Idee, den Realm über
eine Firewall zu öffnen.

FreeBSD - Heimdal Kerberos

In FreeBSD ab der Version 5 ist eine Kerberos V5 Installation in den Basis-Paketen enthalten. Um eine einfache Kerberos Domain aufzubauen, sind also nur wenige Handgriffe erforderlich:

Zuerst ist die Datei /etc/rc.conf anzupassen. Hier werden die nötigen Kerberos Dämonen gestartet (der Kerberos Server und der kadmin Dienst).

kerberos5_server_enable="YES"
kadmind5_server_enable="YES"

[libdefaults]
    default_realm = ORM.ORG
[realms]
    ORM.ORG = {
        kdc = kerberos.orm.org
        admin_server = kerberos.orm.org
        }
[domain_realm]
       .orm.org = ORM.ORG

[libdefaults]
    default_realm = ORM.ORG

_kerberos._udp    IN SRV 01 00 88 kerberos.orm.org.
_kerberos._tcp    IN SRV 01 00 88 kerberos.orm.org.
_kpasswd._udp    IN SRV 01 00 464 kerberos.orm.org.
_kerberos-adm._tcp    IN SRV 01 00 749 kerberos.orm.org.
_kerberos    IN TXT ORM.ORG

Dann ist die Kerberos Database anzulegen. Hier sind alle Prinzipale (User, User-Instanzen, Maschinen, Dienste ...) und deren Daten (Namen, Ip-Adressen, Keys...) gespeichert. Die Datenbank wird mit einem Master-Keyword gesichert. Dieses Passwort generiert den Master-Key, der in der Datei /var/heimdal/m-key abgelegt wird. Das geschieht mit dem kstash-Kommando. Es fragt das Passwort ab, erzeugt den Key und die Datenbank-Strukturen.

# kstash
Master Key:
Verifying Password - Master Key:

Auf die Master-Datenbank kann man als root-User von der lokalen Maschine immer zugreifen. Startet man den kadmind, so ist auch ein Remote-Zugriff mit anderen Usern möglich. Zugriff erfolgt mit dem Kommando kadmin -l. Beim ersten starten wird die Realm definiert; man legt den Namen und einige generelle Parameter wie Ticket Lebensdauer etc. an. Danach kann man mit dem add-Kommando die gewünschten Prinzipale anlegen; und dabei weitere Parameter einstellen.

User anlegen: For example: jqpublic@USC.EDU jqpublic/secure@USC.EDU jqpublic/admin@USC.EDU Administation: list -l Prinzipal

Der Start der Kerberos Services geht nun automatisch bei jedem Boot des Systems; mit folgenden Aufrufen kann man die Dämonen kontrollieren:

/etc/rc.d/kerberos start
/etc/rc.d/kadmin start

Den Inhalt der Datenbank kann man mit dem dump-Kommando ansehen und sichern; zum direkten Lesen ist es wichtig, die Ausgabe mit dem Master-Key zu entschlüsseln. Das geschieht mit dem Schalter -d:

dump -d /mein_verz/filename

Ein eingerichteter User kann sich nun an der Kerberos Realm anmelden. Dies geschieht mit dem kinit-Kommando:

 
kinit prinzipal_name

Aufnahme einer Client Maschine in die Kerberos Realm

Kopieren des /etc/krb5.conf-File auf den neuen Client.

User Kommandos und Konfiguration

Arten von User-Prinzipalen und Instanzen: For example: jqpublic@USC.EDU jqpublic/secure@USC.EDU jqpublic/admin@USC.EDU

• kinit

• klist

• kdestroy

• kpasswd

User Files: Analog der Funktion von User-Files wie .rhosts und .hosts kann man die Kerberos-User Files .k5login und .k5users einsetzen. Das ermöglicht, einer Reihe Kerberos-Prinzipalen z.B. den Zugang zu einem speziellen User-Account - ohne ein gemeinsames Passwort. Sollen etwa die Prinzipale orm@orm.org, cristina@orm.org und hugo@orm.org gemeinsam auf den lokalen Account support zugreifen können, so legt man im $HOME des Users support das File $HOME/.k5login an:

orm@orm.org
cristina@orm.org
hugo@orm.org

Aufnahme eines Service in die Kerberos Realm

Für die kerberisierten Versionen der Standard Netzwerkdienste (ftp, rch, rcp, rlogin ...) muss der Heimdal-Port installiert werden. In der minimalen Installation ist nur telnet kerberisiert.

Installation auf AIX

Der Kerberos Service wird in der Version 5 für AIX auf den Expansion Pack CDs bereitgestellt. Es gibt eine krb5 Package, die je ein Fileset für die Client und die Server Komponente enthält. Diese Filesets können auch einzeln installiert werden (z.B. auf einem reinen Client).

Besonders ist bei AIX: Die Kerberos-Kommandos liegen, um Kollisionen mit den gleichlautenden Kommandos des DCE Kerberos zu vermeiden, in /usr/krb5/bin (und sbin). Entweder, man ruft sie immer mit Pfad auf, oder man erweitert den Pfad entsprechend.

Generell sollte man Kerberos und DCE nicht auf der gleichen Maschine installieren - da es sonst nötig ist, bei einem der Produkte verschiedene Ports zu verlegen.

Der Master wird durch Aufruf des Skriptes mkkrb5srv konfiguriert. Dieses Skript benötigt den Namen der Realm, den Namen des Servers, die Domäne und den Admin-Account als Angaben. Es legt das Konfigurationsfile /etc/krb5/krb5.conf an und generiert die Pfade zur Datenbank, den Keys etc. Weiterhin wird das File /var/krb5/krb5kdc/kdc.conf angelegt. Hier werden die Parameter für die Ports, ACLs, Ticket TTL sowie die Pfade zu den Datenfiles gesetzt (kdc_ports, kacl, max_life, max_renewable_life, master_key_type, supportede_entypes; Pfade zur Datenbank, der admin_keytab, acl_file, dict_file und key_stash_file). Danach wird das /var/krb5/krb5kdc/kadm5.acl File erzeugt - somit ist der Zugang für die Admin, root und Host-Principals möglich. Abschliessend wird die Datenbank und der Admin Prinzipal generiert. An dieser Stelle muß der KDC Masterkey eingegeben werden und das Admin-Passwort wird gesetzt.

Auf einem Client steht das Skript mkkrb5clnt Kommando zu Verfügung. Auch hier wird aus den Angaben ein krb5.conf generiert und die Pfade werden angepasst. Wenn der Kerberos Client in einer anderen DNS Domäne als der KDC steht, so ist ein [domain realm] Statement in das krb5.conf einzufügen, daß die DNS Domäne der Kerberos Realm zuweist (wie weiter oben beschrieben).

mkkrb5srv -r meine_realm -s mein_server.example.com -d example.com -a admin/admin
mkkrb5clnt -c mein_client.example.com -r meine_realm -s mein_server.example.com -d example.com -A -i user_acces -K -T
-i Voll integriertes Kerberos Login (fügt KRB5 und KRB5files Stanzas in
/usr/lib/security/methods.cfg ein).
-K Kerberos als default Authentifizierung
-A Macht root zum Admin User für Kerberos
-T Holt Server Admin TGT 

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]