Argomenti
Kerberos V5
Di
•Cos’e’ KERBEROS
•Perché KERBEROS
Max Giordano
•Funzionamento
[email protected]
•Installazione
Giuseppe Giongati
•Configurazione
[email protected]
Cos’e’ Kerberos
Lo Scenario
Nel mondo di kerberos valgono 3 assunzioni:
•sistema di autenticazione distribuito
•realizzato al MIT dall’ATHENA Group in
alternativa al sistema di autenticazione
tradizionale
La versione 4 fu ideata nel 1987 da
Steve Miller e Clifford Neuman
• la rete e’ insicura
• gli host sono sicuri
La Version 5, John Kohl e Clifford Neuman,
fu ideata nel 1990
• le chiavi non sono banali
Concetti base
Autenticazione Tradizionale
•non ci si basa sulle affermazioni degli utenti
•elimina la necessità di dimostrare il possesso di
informazioni segrete (password,etc)
•un vigile non si accontenta di ciò che affermiamo
per accertare la nostra identità
Userid, password
Accesso
Patente e
libretto!
1
Autenticazione Tradizionale
Autenticazione Tradizionale
Userid, password
Userid, password
Accesso
Accesso
Posso intercettare
userid e password
(attaccante)
(attaccante)
Autenticazione con Kerberos
Autenticazione con Kerberos
AS
AS
AS: Autentication Server
•Conosce le chiavi segrete degli
utenti e dei servizi
•Rilascia le chiavi di sessione
SERVER
Politica delle Chiavi
AS
ie
s
ta
se
rv
iz
i
o
CHIAVI
SEGRETE
2
Ri
ch
AS
CHIAVE SEGRETA =
hash(password||salt)
Funzionamento Semplificato
ti
ck
et
CLIENT
Autenticazione
CLIENT
SERVER
[mutua autenticazione]
2
Dialogo AS -> Client
Dialogo Client -> Server
•Preparo una chiave di sessione Ks
•Ekcli(Ks,exptime,idserver…)
•Ekser(Ks,exptime,idutente…)
Autenticazione
Conosco le loro chiavi segrete
AS
Richiesta servizio
Ekser(Ks,exptime,idutente…)
Eks(timestamp, chksum,…)
iz
i
o
idutente
se
rv
idserver
ticket
Ekcli(Ks,exptime,idserver…)
•E-1kcli(Ekcli(Ks,exptime,idserver…))
•Kcli è la mia chiave !
•Verifico la validità di Ks (controllo la
scadenza exptime)
•Eks(timestamp,chksum,…)
•E-1kser(Ekser(Ks,exptime,idutente))
•E-1ks(Eks(timestamp, chksum, …))
•Se (timestamp valido) &&(chksum
corretto) allora: il client e’
autenticato perché solo lui
conosce Ks
Ekser(Ks,exptime,idutente…)
2
Ri
ch
ti
ck
et
ie
s
ta
exptime
Autenticazione
CLIENT
CLIENT
SERVER
[mutua autenticazione]
[Mutua autenticazione]
Eks(timestamp, …)
struttura dei Ticket
Ekcli(sessionkey ,id,exptime)
io
AS
exptime
se
rv
iz
id
Autenticator
timestamp
2
Ri
ch
ie
st
a
Chiave sessione
Per ogni
Eks(timestamp, chksum, …)
chksum
servizio uso
la password!
[Cipher opt]
ti
ck
et
Ticket
Problema
autenticazione
CLIENT
SERVER
Mutua autent.
Subkey: chiave di cifratura
specificata dall’utente
Seq#: associato ai messaggi
inviati dal server al
client
E-1kcli(Ekcli(Ks,exptime,idutente))
Ticket Granting System
Ticket Granting Server
Funzionamento Modificato
ticket
AS
Permette ad un client di ottenere
ticket senza riutilizzare la propria
chiave segreta
EKTGS(Ks,exptime,idclient…)
Autenticazione
EkTGS(Ks,exptime,idutente…)
2 ticket
TGS: Ticket Granting Server
Richiesta serv. tgs
TGS
EKcli(Ks,exptime,idtgs…)
Eks(timestamp, chksum, …)
Autenticazione
CLIENT
TGS
Mutua Autenticazione
3
Ticket Granting System
Calcolo della chiave
Funzionamento Modificato
TGS
ticket
EKs(Ks2,exptime,idserver…)
Richiesta serv. SERVER
EKser(Ks2,exptime,idclient…)
CHIAVE SEGRETA =
hash(password||salt)
2 ticket
Autenticazione
EKser(Ks2,exptime,idutente…)
EKs2(timestamp, chksum, …)
Ma come e’ implementata
la funziona HASH ?
Autenticazione
CLIENT
SERVER
Mutua Autenticazione
“Password to key”
“Password to key”
S Å PASSWORD
Å 1 byte Æ
Å s[0] Æ
KPw
Å s[1] Æ
Å s[2] Æ
s
E(S,Kpw)
…
P1
P2
PN
PN-1
b
…
Å 56 bit Æ
KPw
DES
KPw
KPw
DES
DES
CN-1
C1
C2
CN
…
KPw
Key Distribution Center
alcuni termini
KDC
•Client
AS
E’ un entità che puo’ ottenere un “ticket”
puo’ essere sia un utente che un “host”
•Host
•Keytab
•Principal
TGS
•Realm
•KDC e’ sinonimo di AS e TGS
4
alcuni termini
•Client
E’ Un computer accessibile dalla rete
alcuni termini
•Client
•Host
•Host
•Keytab
•Keytab
•Principal
•Principal
•Realm
•Realm
alcuni termini
•Client
•Host
•Keytab
Denota un utente o un servizio a cui
assegnamo delle credenziali.
E’ una stringa del tipo: Primary/instance@REALM
-Primary equivale al nome dell’utente/servizio
-Instance e’ la qualifica di un utente
Una tabella usata dagli host o dai servizi
per memorizzare la loro chiave segreta
alcuni termini
•Client
•Host
•Keytab
•Principal
•Principal
•Realm
•Realm
E’ una rete “logica” che fa capo ad un unico
database.
Definisce un area di validita’ dei ticket
Obiettivo
KDC
AS
INSTALLAZIONE
TGS
CLIENT
SERVER
5
Scelta dei “Realm”
Considerazioni Preliminari
Scelta dei "Realm“
•Scelta del/dei "kerberos Realm“.
Per convenzione utilizziamo i nomi di dominio in
lettere MAIUSCOLE.
•Mapping hostnames Î "kerberos Realm“.
•Porte usate dal KDC e dal kadmin.
•KDC Secondari
SPARTACO.IT
spartaco.it
mapping hostnameÎRealm
mapping hostnameÎRealm
Due possibilità:
Primo approccio via file "krb5.conf“:
•
Tramite i files di configurazione
Dal generale al particolare:
•
Tramite il DNS
dominio Î sottodomino Î eccezioni
Esempio:
.it=IT
spartaco.it=SPARTACO.IT
mapping hostnameÎRealm
PROBLEMA: non e’
scalabile per
ogni host va
modificato un
file di
configurazione
mapping hostnameÎRealm
Secondo approccio via DNS:
Secondo approccio via DNS:
•
Nel DNS ogni hostname ha un record associato
•
Usiamo il campo “TXT” di questo record per
memorizzare il REALM associato all’Host
SPARTACO.IT
_kerberos.spartaco.it
irrisolvibile
client
REALM=hostname.txt
DNS
_kerberos.it
irrisolvibile
[…][TXT][…][…][…]
[…][TXT][…][…][…]
[…][TXT][…][…][…]
DNS
L’interrogazione si ferma quando il DNS risolve l’hostname
6
Porte usate
KDC Secondari
•
• 88 per il KDC
• 749 per il server di amministrazione.
Forniscono continuità al servizio “ticketgranting”
KDC
sul KDC
secondario non
si possono
amministrare gli
utenti
KDC
secondario
Continuità del Servizio
CHIAVI
Consistenza dei database
KDC
Kerberos
CHIAVI
=
CHIAVI
KDC
Kerberos-1
CHIAVI
…
CHIAVI
KDC
Kerberos
CHIAVI
KDC
Kerberos-n
KDC
Kerberos-2
Con un job
periodico il
database
principale si
propaga agli
altri KDC
KDC
Kerberos-1
CHIAVI
KDC
Kerberos-3
Compilazione
Nomi per i KDC secondari
Uso degli alias
DNS: ad ogni hostname sono associati uno o piu’
alias detti “CNAME”
Requisiti: Circa 70 mega byte di spazio su
disco
Preleviamo il pacchetto da:
HOSTNAME
CNAME
HOST1:
kerberos
HOST2:
kerberos-1
HOST3:
kerberos-2
...
…
HOSTN:
kerberos-n
http://www.crypto-publish.org/dist/mitkerberos5/krb5-1.2.2.tar.gz
DNS
7
Compilazione
“Configure”
personalizzare il pacchetto senza editare
manualmente i Makefile
1. cd krb5-1.2/src
2. ./configure
3. make
4. make install
“Configure”
“Configure”
Alcune opzioni:
Alcune opzioni:
--prefix=PREFIX
--localstatedir=LOCALSTATEDIR
Per impostare una radice diversa dal default, questo
serve a:
Indica un percorso alternativo per i file di
configurazione.
•rendere piu' agevole una eventuale "dekerberizzazione“ e l’aggiornamento.
•separare i files Kerberizzati dalle versioni
standard
•usare versioni non kerberizzate dei servizi (per
compatibilita’)
“configure”
Configurazione
Comandi:
esempio:
Kdb5_util: che ci permette di gestire il db delle
password (creazione, cancellazione, … di un db)
./configure --prefix=/opt/krb5 --localstatedir=/opt/krb5/var/krb5kdc
Kadmin: ci permette di amministrare i principal, le
policies e le chiavi dei servizi (il file keytab).
•E’ un tool remoto che si basa sull’autenticazione
Spartaco# ./configure –prefix=/opt/krb5
…
Spartaco# make
…
Spartaco# make install
…
Kerberos e su una RPC
•Per auteticarsi usa il principal kadmin/admin che e’
creato automaticamente quando creiamo il database
Kadmin.local: e’ una versione che non usa
l’autenticazione kerberos e che funziona solo in
locale
8
Passaggi
•Creazione file di configurazione
•Creazione del DB Principale
Configurazione
La configurazione e’ basata su due files:
•kdc.conf
•krb5.conf
•Impostazione dei privilegi di amministrazione
•Creazione del keytab per gli host
organizzati in sezioni
•Aggiunta dei “Principal”
•Configurazione “application” server
•Avvio di Kadmin e del KDC
File di configurazione
Krb5.conf e’ il file principale e contiene sette
sezioni:
File di configurazione
Kdc.conf contiene tre sezioni:
Libdefault: impostazioni per la libreria
Appdefalut: impostazioni per le applicazioni
kdcdefaults: impostazioni per il Kdc
Realms: impostazioni per i singoli realm
Realms: impostazioni per i singoli realm
Domain_realm: mapping domainname->realm
Logging: impostazioni funzioni di log
Logging: impostazioni funzioni di log
Capaths: path non gerarchico per l’autenticazione
cross realm
Kdc: indica il file “kdc.conf”
Configurazione
In particolare le sezioni piu’ significative sono:
•Libdefaults
•realms
•domain_realm
Configurazione
[libdefaults]
ticket_lifetime = 24000
default_realm = SPARTACO.IT
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
dns_lookup_realm = false
dns_lookup_kdc = false
Qui posso
impostare l’alg.
Di cifratura e la
vita del ticket
9
Configurazione
[realms]
SPARTACO.IT = {
kdc = spartaco.it:88
admin_server = spartaco.it:749
default_domain = it
}
Configurazione
[domain_realm]
.it = SPARTACO.IT
it = SPARTACO.IT
spartaco.it = SPARTACO.IT
spartaco = SPARTACO.IT
Qui definisco i
“REALM”
Creazione DB
Il database principale contiene le chiavi.
Si crea con il comando:
kdb5_util:
Qui definisco il
mapping
hostname Æ realm
Privilegi di amministrazione
I livelli di privilegio sul file della password
sono memorizzati nel file kadm5.acl
spartaco# cat kadm5.acl
Spartaco# ./kdb5_util create -r SPARTACO.IT -s
Initializing database '/krb5/lvar/krb5kdc/principal' for realm
'spartaco.it',
master key name 'K/[email protected]'
Enter KDC database master key:
your_master_key
Re-enter KDC database master key to verify:
your_master_key
l'opzione -r indica il dominio, -s crea un file
"stash" usato dal KDC per "autenticarsi".
*/[email protected]
*
[email protected]
ADMCIL
giugio/*@SPARTACO.IT
l
Quindi:
•giugio/admin puo’ tutto
•giugio non puo niente
•giugio/qualsiasicosa puo solo
listare il contenuto del db
a/A permette/vieta l’aggiunta di un principal
d/D permette/vieta la rimozione di un principal
m/M permette/vieta la modifica di un principal
c/C permette/vieta changepw di un principal
i/I permette/vieta query sul DB principale
l/L permette/vieta l’elencazione dei principal
Creazione keytab
Creazione Principal
Definiti i privilegi creiamo il file keytab
Aggiungiamo almeno i due principal kadmin/admin e
kadmin/changepw per poter usare kadmin
Sempre dal software kadmin.local possiamo creare
un principal con addprinc:
Spartaco# ./kadmin.local
Spartaco# ./kadmin.local
kadmin.local: ktadd -k /opt/krb5/var/krb5kdc/kadm5.keytab kadmin/admin
kadmin/changepw
Entry for principal kadmin/admin with kvno 3, encryption type DES3SHA1-HMAC added to keytab WRFILE:/krb5/var/krb5kdc/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES3SHA-HMAC added to keytab WRFILE:/krb5/var/krb5kdc/kadm5.keytab.
kadmin.local: quit
Kadmin: addprinc [email protected] –expire “10/05/2002 24.00”
Il comando ktadd aggiunge i principal indicati al
file keytab
Enter password for principal [email protected]:
Re-enter password for principal:
Principal [email protected] created.
Kadmin:
Altri comandi:
modprinc, listprinc, delprinc.
Quit chiude kadmin
10
Aggiunta Servizi
Avviamo i server
I servizi sono considerati come principal e come
tali vanno aggiunti:
La parola
nerone# ./kadmin
Kadmin: addprinc host/[email protected]
Enter password for principal host/[email protected]:
Re-enter password for principal:
Principal host/[email protected] created.
Kadmin:
“host” indica
un tipo di
servizio che
e’ l’accesso
via rlogin o
telnet. Altri
servizi hanno
altri nomi,
es. ftp, pop…
Naturalmente vanno aggiunti al keytab locale
nerone# ./kadmin
modifichiamo il file /etc/services e il file
/etc/inetd.conf
Spartaco# vi /etc/inetd.conf
klogin stream tcp nowait root /krb5/sbin/klogind klogind -ki
eklogin stream tcp nowait root /krb5/sbin/klogind klogind -eki
kshell stream tcp nowait root /krb5/sbin/kshd kshd -ki
ktelnet stream tcp nowait root /krb5/sbin/telnetd telnetd -a user
kftp stream tcp nowait root /krb5/sbin/ftpd -a
~
~
kadmin.local: ktadd host/[email protected]
Entry for principal host/nerone.it with kvno 3, encryption type DES3SHA1-HMAC added to keytab WRFILE:/etc/kadm5.keytab.
kadmin.local: quit
Avviamo i server
Lato Utente
Non ci resta che avviare i due server e riavviare
i servizi:
Con il comando kinit inizia la sessione di lavoro
giomas@spartaco$ kinit
Password for [email protected]:
spartaco# /opt/krb5/sbin/krb5kdc
spartaco# /opt/krb5/sbin/kadmind
Spartaco# /etc/rc.d/init.d/inetd restart
Con uno script
posso rendere
effettivi questi
due comandi
KINIT
Non
leggo
piu’
niente
(attaccante)
Lato Utente
L’utente ha a disposizione altri comandi per
gestire la sua cache di “ticket”:
Pregi e difetti
le limitazioni possono essere riassunte nei seguenti
punti:
Klist: ci mostra i ticket acquisiti
•Non protegge dalla possibilità di scoperta della
password dell'utente
Kdestroy: li distrugge
giomas@spartaco$ rlogin nerone
Welcome to nerone!
You’ve mail !
giomas@nerone$ ^d
Nessuna password
Anche le
comunicazioni si
possono cifrare
•Richiede in genere una macchina dedicata e sicura
come Authentication server
•Le applicazioni devono essere in parte riscritte
•Superato il DES sussistono ancora conflitti con la
legislazione degli USA
•l'installazione e' molto "intrusiva”
11
Pregi e difetti
Kerberos V5
Tuttavia Kerberos ha anche dei pregi:
•
E’ scalabile
•
La gestione centralizzata delle chiavi e degli
utenti (revoca, rinnovo, cancellazione,ecc,ecc) è
più semplice ed efficiente che in altri sistemi
come SSL.
E’ un sistema FREE cioè aperto a tutte le modifiche
e contributi.
•
•
E’ sicuro perché la chiave non circola sulla rete e
non e’ memorizzata in nessun posto oltre che la
testa dell’utente e il KDC.
•
E’ flessibile, volendo usare una nuova tecnologia
di autenticazione (per esempio un nuovo tipo di
Smart Card con il proprio algoritmo), basta ”solo”
modificare il KDC.
F I N E !
12