Autentizační systémy -Kerberos, PAM

Jiří Caha, xcaha@fi.muni.cz

Obsah

• Kerberos
  • Historie
  • Vlastnosti
  • Princip
  • Konfigurace
  • KDC
  • Client
  • Odkazy
• PAM
  • Konfigurace
  • Odkazy

Kerberos

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

• Autentifikační server (AS, Authentication server)
• 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|       
 +---------------+     +--------------+

(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é E_{key_C-AS}(tmpkey_C-TGS) a E_{key_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

Konfigurace KDC

     [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
      }

   [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
    }

*/admin@FI.MUNI.CZ *

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

Konfigurace klienta

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

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

Odkazy

PAM

Konfigurace

Konfigurační soubory

Kde:

service-name

Jméno služby/aplikace.
Speciální service-name OTHER je rezervovaný pro defaultní autentifikační mechanismus. Zde je dobrým zvykem zakázat vše, co není vysloveně povoleno:

#%PAM-1.0
 # This is /etc/pam.d/other
 auth		required	pam_deny.so
 auth		required	pam_warn.so
 account	required	pam_deny.so
 account	required	pam_warn.so
 password	required	pam_deny.so
 password	required	pam_warn.so
 session	required	pam_deny.so
 session	required	pam_warn.so

module-type

Jeden ze čtyř možných typů modulu:

auth

autentizace uživatele (heslem, biometrikami, ...);

account

provádí se další ověřování přístupu k službě, které však nemá nic společného s ověřováním identity uživatele (např. přístup jen v určitou dobu,...);

session

provádí se před a po skončení služby. Stará se o správu sezení. Může např. nastavovat proměnné prostředí, omezovat systémové prostředky, chroot, logovaní, ...

password

provádí aktualizaci uživatelských autentizačních tokenů (heslo, otisk prstu, ...). Obvykle také umožňuje kontrolu "kvality" hesla (délka, odolnost proti slovníkovému útoku).

control-flag

používá se k definici reakce na (ne)úspěšné ukončení modulu. Moduly stejného typu se spouštějí v sérii (jeden po druhém). Kontrolní příznaky pak určují reakci při skončení modulu. Aplikace se ale nedozví jak skončil který modul, místo toho obdrží jen celkovou odpověď success/fail. Od Linux-PAM v0.60 lze kontrolní příznak definovat jedním ze dvou způsobů:

pomocí jednoho z klíčových slov:

required

jeho neúspěch způsobí zamítnutí, ale až po provedení ostatních modulů ze stejné oblasti.

requisite

liší se od required okamžitým oznámením neúspěchu.
Např. při přihlašování přes nespolehlivý kanál nám nedovolí zadávat heslo.

sufficient

modul s tímto příznakem může okamžitě ukončit kontroly s výsledkem success, pokud tento modul uspěl a žádný z předchozích modulů nezamítl přístup. Jinak je modul ignorován a pokračuje se dál v kontrole.
Využívá se převážně pro přeskočeni zdlouhavých kontrol, pokud službu požaduje superuživatel.

optional

(ne)úspěch těchto modulů se nezahrnuje do celkového výsledku.

Nebo pomocí propracovanější syntaxe, ve které je kontrolní příznak tvaru:
   [value1=action1 value2=action2, ...]

module-path

cesta k modulům. Implicitně (pokud není zadána cesta absolutní) se hledá v /usr/lib/security/ (/lib/security/).

args

argumenty předávané modulu při jeho spuštění.

Příklad modulu

pam_localuser

vyžaduje uživatele uvedeného v /etc/passwd

pam_krb5

autentizace přes Kerberos 5

pam_succeed_if

úspěch tohoto modulu závisí na širší charakteristice uživatelova účtu (LOGIN,UID,GID,SHELL,HOME).

pam_cracklib

kontrola odolnosti hesla.

pam_limits

nastavování limitu (/etc/security/limits.conf).

pam_time

přístup jen v určitou dobu (/etc/security/time.conf).

pam_warn

slouží pro zápis do syslogu.

Příklad konfiguračního souboru

  #%PAM-1.0
  auth       required     pam_securetty.so
  #kontrola, zda pristupujeme pres bezpecny kanal
  auth       required     pam_stack.so service=system-auth
  #vyhodnoce se ulozi na zasobnik
  auth       required     pam_nologin.so
  #kontrola zda neexistuje soubor /etc/nologin
  account    required     pam_stack.so service=system-auth
  password   required     pam_stack.so service=system-auth
  session    required     pam_stack.so service=system-auth
  session    optional     pam_console.so

Odkazy