Elementi di Sicurezza e Privatezza - Kerberos

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

1. 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"
2. 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:

1. chiave di sessione per il TGS (che chiamo chiaveTGS)
2. 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:

1. il proprio id, crittato con la chiaveTGS
2. 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:

1. la chiave di sessione da usare con il server = chiaveServer
2. 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:

1. il messaggio da forwardare (il messaggio 2 del punto precedente, cioè il ticket di servizio)
2. 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:

1. fornisce autenticazione
2. conosce le password degli utenti
3. conosce le password dei TGS

Mentre il TGS, nello stesso bailamme:

1. fornisce controllo dell'accesso
2. conosce le password dei server
3. dà al client il ticket di servizio necessario per accedere a un servizio su un certo Server