Autentizační systémy

Slávek Licehammer, 255920@mail.muni.cz

Obsah

Kerberos

Kerberos je autentizační protokol, který umožňuje vzájemné prokázání identity mezi serverem a uživatelem. Je navržen tak, aby se klient mohl prokázat serveru (a obráceně) i na nedůvěryhodné síti. Existují dvě implementace protokolu - MIT kerberos a Heimdal. MIT kerberos vznikl jako první, ale jelikož byl vyvíjen v USA, týkala se ho omezení na vývoz kryptografie. Proto byl vyvinut Heimdal(mimo USA), který implementuje stejné api a je s MIT kerberem kompatibilní.

Uživatel (nebo služba, stroj...) se v kerberu identifikuje principalem. Principal se skládá ze tří částí: primary, instance a realm. Zapisuje se ve tvaru: primary/instance@REALM. V primary je uloženo uživatelské jméno nebo jméno služby. Obsah instance se liší pro různé typy principalů, může být i prázdný. Realm je logická entita ve které se nachází účet. Jako jméno realmu se často používá doménové jméno zapsané velkými písmeny.

Popis činnosti protokolu kerberos

Protokol je založen na důvěryhodné třetí straně - KDC (key distribution server) serveru, ten se skládá ze dvou služeb: autentizačního serveru (KAS) a ticket granting serveru (TGS). Tyto služby jsou samostatné, ale většinou se provozují na stejném stroji. Ticket granting server vydává ticket granting ticket (TGT), což je malý zašifrovaný soubor s omezenou platností, který obsahuje klíč sezení, datum a čas expirace a uživatelovu IP adresu.


Popis autentizace (převzato z referátu Michala Procházky):

  1. Klient A pošle žádost KAS o spojení s jiným serverem B.
  2. Pokud je klient A a server B v databázi KAS, pak KAS vygeneruje dočasný klíč TempKey, který bude využit při komunikaci mezi klientem A a TGS. TempKey KAS zašifruje tajným klíčem klienta, který má uložen v databázi. Dále vytvoří TGT, který slouží ke komunikaci s TGS, takže je zašifrován tajným klíčem TGS (tajný klíč zná jen KAS a TGS). TGT obsahuje též dočasný klíč. Obě zprávy jsou zaslány zpět klientovi.
  3. Klient A rozšifruje první zprávu pomocí svého hesla a získá tak dočasný klíč pro komunikaci s TGS. Klient A vytvoří autentizátor (authenticator). Autentizátor obsahuje jméno klienta A, adresu a časové razítko. Klient A zašifruje dočasným klíčem, který obdržel od KAS. Klient A dále pošle TGS žádost o lístek pro server B, žádost obsahuje jméno serveru B, TGT (TGT je zašifrován klíčem TGS) a zašifrovaný autentizátor.
  4. TGS rozšifruje TGT svým tajným klíčem a získá dočasný klíč, kterým rozšifruje autentizátor a zkontroluje jeho pravost. Pokud je vše v pořádku, pak TGS vytvoří nový dočasný klíč, který bude využíván k šifrování komunikace mezi klientem A a serverem B. Nový dočasný klíč začlení do lístku, kterým se bude klient A prokazovat serveru B, lístek je zašifrován tajným klíčem serveru B.
  5. Klient A ze zaslané zprávy získá dočasný klíč pro komunikaci s cílovým serverem B, který vytvořil TGS. Vytvoří nový autentizátor, který zašifruje dočasným klíčem. Cílovému serveru pošle lístek, který obdržel od TGS (zašifrovaný klíčem cílového serveru B) a zašifrovaný autentizátor.
  6. Cílový server B rozšifruje lístek i autentizátor, zkontroluje časovou značku a adresu jak u lístku, tak i autentizátoru. Server B si je v tuto chvíli jist identitou klienta A, dále klient A i server B sdílejí tajmenství, kterým šifrují komunikaci.


Konfigurace

/etc/krb5.conf

[libdefaults]
        default_realm = META 
        forwardable = yes
        forward = yes
        encrypt = yes

[realms]
    ICS.MUNI.CZ = {
            kdc = nimloth.ics.muni.cz
            kdc = sirion.ics.muni.cz:89
            admin_server = nimloth.ics.muni.cz
	    krb524_server = nimloth.ics.muni.cz
	    krb524_server = sirion.ics.muni.cz:89
    }
    META = {
            kdc = sirion.ics.muni.cz
            kdc = nimloth.ics.muni.cz:89
            kdc = sal.ruk.cuni.cz:89
            admin_server = sirion.ics.muni.cz
	    krb524_server = sirion.ics.muni.cz
	    krb524_server = nimloth.ics.muni.cz:89
    }

[domain_realm]
        sirion.ics.muni.cz = META
        grond.ics.muni.cz = META
        nympha.zcu.cz = META
        minos.zcu.cz = META
        .ics.muni.cz = ICS.MUNI.CZ
        .cesnet.cz = ICS.MUNI.CZ

Nastaveni KDC serveru - kdc.conf. Umístění tohoto souboru se může lišit podle použité implementace kerbera (Heimdal, MIT) a podle distribuce linuxu. (v deabinu je v etc/heimdal-kdc/kdc.conf)

[kdc]
# See allowed values in krb5_openlog(3) man page.
log_file = FILE:/var/log/heimdal-kdc.log
acl_file = FILE:/etc/heimdal-kdc/kadmind.acl

Nastavení acl_file. Zde povolíme, kdo smí editovat databázi kerbera.

#principal       [priv1,priv2,...]       [glob-pattern]
*/admin@META     *

Nastavovaní databáze kerbera se provádí pomocí příkazu kadmin. Kadmin se připojí na daemon kadmind nebo může pracovat lokálně - toho dosáhneme spuštěním s parametrem -l.

Vytvoření uživatele admin:

kadmin -l "add admin/admin@META"

Replikace

Kerberos byl navržen tak, aby umožňoval snadnou replikaci na principu master/slave. Je jeden primární server (Master) a ostatní servery (Slave) si z něj berou nastavení (vždy po uplynutí nějakého časového intervalu). Pokud master server vypadne, kterýkoliv ze slave serverů ho může zastoupit. Návod jak nastavit replikaci serveru lze nalézt na na adrese http://tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO/server-replication.html.

Nevýhody kerbera



PAM - Pluggable Authentication Modules for Linux

PAM je sada knihoven, používaná pro autentizaci uživatele vůči programům. Cílem je oddělit aplikace od konkrétních autentizačních mechanismů. V aplikacích se nemusejí implementovat jednotlivé metody autentizace, ale pouze se přidá knihovna pro obsluhu PAM modulů. Výhoda je také v tom, že není potřeba upravit a znovu kompilovat program, když se objeví nový způsob autentizace.

PAM je v současné době používán těmito operačímy systémy: AIX operating system, DragonFly BSD, FreeBSD, HP-UX, Linux, Mac OS X, NetBSD a Solaris.

Konfigurace PAM

Konfigurace může být uložena v jediném souboru /etc/pam.conf, častěji se používá uložení konfiguračních souborů do /etc/pam.d, tam má každá aplikace svůj konfigurační soubor. V adresáři /lib/security jsou uloženy sdílené knihovny, takzvané PAM moduly, které využívají aplikace k autentizaci.


Příklad konfiguračího souboru z /etc/pam.d
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_nologin.so
auth sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_unix_auth.so try_first_pass
account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix_acct.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_ldap.so
password required /lib/security/pam_pwdb.so use_first_pass 
session required /lib/security/pam_unix_session.so

Každý řádek se skládá z několika položek. První je typ, druhá kontrolní příznak, další cesta k PAM modulu a poslední parametry.

Type existují čtyři: auth, account, password a session. Tyto typy odpovídají čtyřem různým věcem o které se PAM stará. Auth slouží k autentizaci, account pro správu nebo kontrolu účtu, password pro změnu hesla a session pro správu uživatelské relace.

Kontrolní příznak:
required - pokud tento modul neuspěje, neuspěje ani celý proces autentizace. Ale ostatní moduly se provedou.
requisite - pokud neuspěje, okamžitě končí celý proces autentizace. Např. když se uživatel připojuje ke službě nezabezpečeným kanálem, použijeme tuto volbu, abychom odmítli jeho přihlášení ještě dříve než zadá heslo.
sufficient - pokud uspěje, uspěje okamžitě celý proces autentizace. Další moduly se už neprovádí.
optional - na výsledku tohoto modulu závisí konečný výsledek pouze v případě, kdy žádný z předchozích modulů nedal rozhodující výsledek.


Některé PAM moduly.
pam_deny - zakáže přístup
pam_unix-* - standardní unixová autentizace
pam_rootok - uspěje pokud je uživatel (jeho efektivní UID) root
pam_warn - logování do syslogu
pam_nologin - umožní uživatelům přihlášení pouze pokud neexistuje soubot /etc/nologin, pokud existuje vypíše obsah tohoto souboru a přihlášení zakáže. Root se může přihlásit vždy.

Literatura