:: 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
