(:title Elementi di Sicurezza e Privatezza - Kerberos:)
%titolo%''':: Elementi di Sicurezza e Privatezza - Kerberos ::'''
Questo è una sorta di riassunto semplificato di Kerberos, così che si capisca un po' meglio rispetto alle slide. Ci sono 4 passi, ma è solo per semplicità. Non si entra in dettagli scabrosi.
Le entità in gioco sono AS, TGS, client e Server:
* AS = Authentication Server
* TGS = Ticket Granting Server
* Server = il server generico che offre il servizio voluto dal client
Un '''kerberos realm''' è l'insieme dei Server e dei client che fanno capo ad una singola coppia AS/TGS. I vari realms possono comunicare, così che non è necessario per un utente iscriversi a mille realms. Per ottenere ciò è comunque necessario un pre-accordo fra i vari realms.
AS contiene le password di tutti gli utenti: quando un client si connette a lui, AS verifica che ID e password coincidano, e quindi prosegue l'autenticazione.\\
Inoltre, AS sa anche tutte le password dei vari TGS: altrimenti, non potrebbe mai dare al client il tgt (ticket granting ticket) che il client poi deve forwardare al server.
I ticket in ballo sono 2:
# tgt = lo scrive AS, e viene recapitato a TGS dal client, e dice: "Caro TGS, il client che ti recapita il messaggio è chi dice di essere. Saluti, AS"
# ticket di servizio= lo scrive TGS e viene forwardato dal client al Server, e dice: "Caro Server, il client che ti recapita il messaggio è chi dice di essere"
Riguardo ai ticket, occorre sapere che hanno sempre un timestamp, perché hanno '''durata limitata'''. Ciò vuol dire che se mando un ticket vecchio, esso non è più accettato.
Il fatto che sia necessario il timestamp implica un'altra cosa: gli orologi di tutti i sistemi devono essere '''sincronizzati'''. A questo scopo si usa il network time protocol, va beh.
Va inoltre evidenziato che AS deve essere '''sempre disponibile''': quando va giù, tutto il sistema non si regge più in piedi. È quindi un '''single point of failure'''. Inoltre, sapendo esso le password di tutti i client, se viene crackato la faccenda si fa grama.
!!!Passo 1
Il client si autentica presso AS. Riceve 2 messaggi:
# chiave di sessione per il TGS (che chiamo '''chiaveTGS''')
# messaggio da forwardare al TGS (contiene la '''chiaveTGS''' e l''''ID''' del client; è crittato con la chiave SEGRETA del TGS) ('''tgt = ticket granting ticket''')
!!!Passo 2
Il client comunica con TGS, e gli invia:
# il proprio id, crittato con la '''chiaveTGS'''
# il messaggio 2 proveniente dalla fase precedente, ovvero il tgt
Il messaggio numero 2, essendo stato crittato da AS con la chiave segreta di TGS, viene aperto da TGS. Conteine la chiaveTGS, e la usa per aprire il messaggio numero 1, e controlla che l'ID del client corrisponda.
!!!Passo 3
Il TGS allora invia al client:
# la chiave di sessione da usare con il server = '''chiaveServer'''
# un messaggio da forwardare al Server (contiene la '''chiaveServer''', e l'ID del client; è crittato con la chiave SEGRETA del Server) ('''ticket di servizio''')
!!!Passo 4
Il client invia al Server:
# il messaggio da forwardare (il messaggio 2 del punto precedente, cioè il ticket di servizio)
# il proprio ID crittato con la chiaveServer
Il Server al solito decritta 1, ne trae '''chiaveServer''', la usa per aprire 2 e vede se i dati coincidono. Se sì, allora il client è autenticato. e gli dà finalmente quello che vuole.
!!!Domandina
Perché ci sono un AS e un TGS? Non basterebbe un AS e basta, senza il TGS di mezzo?
La risposta è che AS e TGS fanno cose diverse. AS fornisce l'autenticazione, mentre TGS fornisce il controllo dell'accesso. L'autenticazione serve per stabilire CHI è il client, mentre il controllo dell'accesso serve per sapere CHE COSA quel client può fare.
Quindi, l'AS in tutto sto bailamme ha questi ruoli:
# fornisce autenticazione
# conosce le password degli utenti
# conosce le password dei TGS
Mentre il TGS, nello stesso bailamme:
# fornisce controllo dell'accesso
# conosce le password dei server
# dà al client il ticket di servizio necessario per accedere a un servizio su un certo Server
