Kerberos

Většina textu je převzata z http://www.fi.muni.cz/~kas/p090/referaty/2004-podzim/st/kerberos_pam_xcaha.html

Historie

V roce 1983 vzniká v MIT (Messachusetts Institute of Technology) projekt Athena (prostředí pro distribuované výpočty). V rámci tohoto projektu bylo třeba vytvořit distribuovaný autentizační systém (pro AAA - authentication, autorization, accounting) zvaný Kerberos, jehož první veřejná verze byla dostupná už v roce 1987 pod názvem Kerberos v4. První zkušenosti s tímto systémem odhalily však některé nedostatky, a systém se dočkal redefinice jako Kerberos v5 v roce 1993 v podobě RFC 1510. První kompletní referenční implementace vychází v MIT v roce 1996.

Ve spojených státech však v té době platí silné omezující podmínky pro export kryptografických protokolů mimo území USA. Proto vzniká v roce 1997 zcela volně šiřitelná evropská implementace Heimdal. Heimdal (aktualní verze 0.6.3) se však snaží zachovávat kompatibilitu jak s Kerberem v4 tak s Kerberem v5.

(Z dalších volně šiřitelných implementací Kerbera 5 ještě zmiňme shishi ve verzi 0.0.18)

Základní vlastnosti

Kerberos je od počátku navržen tak, aby autentizace neprobíhala zasíláním hesel, ale pomocí lístku, které pak mohou putovat i přes nezabezpečenou síť. Autentizace je založena na důvěryhodné třetí straně (KDC, Key Distribution Center).

Kerberos v4 využívá(l) symetrické kryptografie (DES) Zatímco Kerberos v5 je založen na kryptografii s veřejným klíčem (PKC, public key cryptogtaphy) - konkrétněji pak na Denning-Soccoove modifikaci Needham-Schroederova tří-stranného autentifikačního protokolu.

Princip

Kerberos používá dva typy důvěryhodných stran (ze kterých se skládá KDC):

1. Autentifikační server (AS, Authentication server)
2. Server poskytující lístky (TGS, Ticket-Granting Server)

Každý uživatel sdílí tajný klíč s AS. Tento tajný klíč není nikdy posílán po síti. Místo něj se ale posílají tzv. lístky. AS slouží k autentizaci uživatele. Komunikace s AS probíhá obvykle jednou za sezení.

Uživatel obdrží od AS TGS ticket pro komunikaci s TGS, u něhož žádá o server ticket pro každou službu kterou využívá v rámci jednoho sezení. Komunikace se serverem (službou) pak probíhá pomocí server ticket, jehož součástí je i symetrický klíč pro zabezpečenou komunikaci client-server.

+---------------+     +--------------+  
| Kerberos      |     | Ticket       |  
| Authentication|     | Granting     |  
| Server  (AS)  |    /| Server (TGS) |        
+---------------+   / +--------------+
      |            /                   (1) request TGT ticket       
      |(1)        /(2)                 (2) request server ticket
      |          /                     (3) request service      
+---------------+ (3) +--------------+  
|   Client      |-----|Server/service|       
+---------------+     +--------------+

Princip komunikace: (1) client:

• Klient se autentifikuje u AS = požádá o TGT lístek.
• Klient tedy pošle AS svůj Client.name.

(1) AS:

• AS vyhledá klienta v databázi sdílených klíčů a podle nalezeného klíče vytvoří (hash sdíleného klíče) tajný klíč key_C-AS.
• Zároveň vygeneruje dočasný klíč tmpkey_C-TGS pro komunikaci Client-TGS, a tento klíč zašifruje pomocí key_C-AS.
• Dále vytvoří TGT lístek: (Client.name, TGS.name, Client.address, tmpkey_C-TGS), který pak zašifruje pomocí tajného klíče TGS key_AS-TGS.
• Zašifrované Ekey_C-AS(tmpkey_C-TGS) a Ekey_AS-TGS(Client.name,TGS.name,Client.address,tmpkey_C-TGS) pak pošle klientovi

(1) client:

• Klient si dokáže vytvořit key_C-AS ze znalosti sdíleného klíče s AS (=autorizace klienta) a rozšifrovat dočasný klíč tmpkey_C-TGS pro komunikaci s TGS.

(1)

• Komunikace Client-AS probíhá jen jednou za sezení. Uživatel tak např. zadává heslo jen jednou, i když využívá několik různých služeb. Vlastní už totiž TGT ticket, díky kterému mu TGS vydává lístky pro jednotlivé servery/služby.

(2) client:

• Chce-li nyní klient použít server, požádá TGS o lístek:
• vytvoří tzv. authenticator= (Client.name, Client.address, timestamp1) a zašifruje jej pro TGS pomocí tmpkey_C-TGS. Zašifrovaný authenticator pošle spolu s TGT lístkem a názvem požadované služby TGS.

(2) TGS:

• TGS dokáže pomocí svého klíče rozšifrovat TGT lístek, tím získá klíč tmpkey_C-TGS, kterým zase rozšifruje authenticator a ověří platnost všech položek (timestamp1, Client.address, ...).
• Vytvoří dočasný klíč tmpkey_C-S pro komunikaci Client-Server.
• Vytvoří server-ticket který obsahuje (Client.name,Server.name, Client.address, ticket.lifetime, timestamp,tmpkey_C-S), a zašifruje tento lístek pomocí klíče key_TGS-S sdíleného spolu se serverem.
• Klientovi pak pošle takto zašifrovaný lístek a klíčem tmpkey_C-TGS zašifrovaný tmpkey_C-S.

(2) client:

• Klient si rozšifruje dočasný klíč tmpkey_C-S pro komunikaci se serverem.
• Zároveň obdržel lístek pro použití serveru (služby).

(3) client:

• Klient nyní vytvoří nový authenticator obsahující (Client.name,Client.address,timestamp2) zašifrovaný pomocí klíče tmpkey_C-S. A pošle jej spolu se server-ticket serveru.

(3) server:

• Dešifruje lístek a authenticator, a ověří platnost všech položek. pošle zpět klientovi zašifrovaný timestamp2+1.

(3)

• I další komunikace Client-Server probíhá šifrovaně pomocí tmpkey_C-S.

Konfigurace

Popsaná konfigurace je pro verzi z MIT na Red Hat Linux 9 Aktualní verze krb5-1.3.5 je možné stáhnout z http://web.mit.edu/kerberos/dist/index.html. Konfigurace KDC Je doporučeno zprovoznit DNS a časovou synchronizaci (ntp). Nainstalovat balíčky krb5-libs,krb5-server,krb5-workstation (pro GUI konfiguraci pak např. gnome-kerberos). Upravit soubor /etc/krb5.conf, např.:

    [logging]
     default = FILE:/var/log/krb5libs.log
     kdc = FILE:/var/log/krb5kdc.log
     admin_server = FILE:/var/log/kadmind.log
    [libdefaults]
     ticket_lifetime = 24000
     default_realm = FI.MUNI.CZ
     dns_lookup_realm = false
     dns_lookup_kdc = false
    [realms]
     FI.MUNI.CZ = {
       kdc = agaue-alpha.fi.muni.cz:88

admin_server = agaue-alpha.fi.muni.cz:749 default_domain = fi.muni.cz

     }
    [domain_realm]
     .fi.muni.cz = FI.MUNI.CZ
     fi.muni.cz = FI.MUNI.CZ
    [kdc]
     profile = /var/kerberos/krb5kdc/kdc.conf
    [appdefaults]
     pam = {
      debug = false
      ticket_lifetime = 36000
      renew_lifetime = 36000
      forwardable = true
      krb4_convert = false
     }

Upravit soubor /var/kerberos/krb5kdc/kdc.conf, např:

  [kdcdefaults]
   acl_file = /var/kerberos/krb5kdc/kadm5.acl
   dict_file = /usr/share/dict/words
   admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
   v4_mode = nopreauth
  [realms]
   FI.MUNI.CZ = {
     master_key_type = des-cbc-crc
     supported_enctypes = arcfour-hmac:normal arcfour-hmac:norealm arcfour-hmac:onlyrealm des3-hmac-sha1:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3
   }

Vytvořit databázi pomocí kdb5_util: /usr/kerberos/sbin/kdb5_util create -s příkaz create vytváří databázi klíčů pro Kerberos realm. Parametr -s vytvoří soubor, ve kterém bude uložen hlavní klíč serveru. Pokud žádný soubor neuvedeme, bude se náš Kerberos server (krb5kdc) při každém spuštění na tento klíč ptát. Upravíme soubor /var/kerberos/krb5kdc/kadm5.acl: tento soubor používá kadmind pro zjištění kteří uživatelé (principals) mají přístup k databázi a s jakou úrovní.

• /admin@FI.MUNI.CZ *

Utilita kadmin komunikuje s kadmin serverem po síti, a k autentifikaci používá Kerbera, proto pokud chceme vytvářet prvního uživatele, musíme jej vytvořit pomocí kadmin.local: /usr/kerberos/sbin/kadmin.local -q "addprinc username/admin" Kerbera spustíme příkazy:

  /sbin/service krb5kdc start
  /sbin/service kadmin  start
  

Uživatele nyní můžeme přidávat příkazem addprinc u kadmin. Pro získání lístku slouží kinit, pro jejich vypsání klist, a zrušení kdestroy. Konfigurace klienta Opět je doporučena synchronizace času. Nainstalované balíčky krb5-libs a krb5-workstation. Upravit soubor /etc/krb5.conf (obvykle může být stejný jako u KDC).

addprinc -randkey host/agaue-alpha.lab.fi.muni.cz

ktadd -k /etc/krb5.keytab host/agaue-alpha.fi.muni.cz