15) Quali sono le fasi di Kerberos?

Login Session Setup:

Il cliente interagisce con Authentication Server

il cliente al Login inserisce lo Username, che viene spedito in chiaro all'Authentication Server, completo di un nonce (che può essere un timestamp), richiedendogli di fornirgli un ticket per comunicare con il TGS.

la comunicazione avviene in chiaro, e non contiene la password del cliente.

Schema comunicazione: Cliente AS

Contenuto messaggio: {C, T, n}, cioè gli identificativi del cliente e del TGS, nonché il nonce.

L’Authentication Server risponde al cliente

L’Authentication Server manda al cliente: il ticket TGS (cioè quello che permetterà al cliente di comunicare con il TGS) crittato con la chiave K_T del TGS e la TGS session key K_CT (sempre per la comunicazione con il TGS) crittata, insieme al nonce, con la chiave del cliente K_C (cioè la sua password), quindi solo il cliente vero può decrittare il messaggio di risposta. Un impostore che avesse spedito il primo messaggio spacciandosi per il cliente vero non potrebbe decrittare la risposta dell’AS. La TGS session key vale per tutta la login session.

Schema comunicazione: AS Cliente

Contenuto messaggio:

{K_CT,n}K_C, cioè la session key da usare con il TGS crittata con la K_C. La presenza del nonce nel messaggio crittato ne garantisce la freschezza

{ticket(C,T)}K_T, cioè il ticket TGS crittato con K_T

a sua volta il ticket(C,T) contiene: {C,T,t₁,t₂,K_CT}, cioè gli identificativi del cliente e del TGS, il tempo di inizio e di termine della validità del ticket (Lifetime) e di nuovo la session key

Server Session Setup:

il cliente interagisce con il TGS

il cliente richiede il ticket per comunicare con un particolare server S per ottenere un servizio

Schema comunicazione: Cliente TGS

Contenuto messaggio:

{auth(C)}K_CT, detto authenticator, che consiste in {C,t}K_CT, cioè nell’identificativo del cliente ed un timestamp crittati con la TGS session key K_CT

{ticket(C,T)}K_T, ricevuto prima dal TGS

S, l’identificativo del server

n, il nonce

il TGS risponde al cliente

Il TGS controlla il ticket inviatogli. Se è valido genera una nuova session key K_CS, crittata con la TGS session key K_CT, e la ritorna assieme ad un ticket per S, crittato con la chiave del server K_s, che è valido per una sessione client/server

Schema comunicazione: TGS Cliente

Contenuto messaggio:

{K_CS,n}K_CT, cioè la session key da usare con S crittata con K_CT insieme al nonce

{ticket(C,S)}K_S, cioè il ticket che il cliente C deve usare con il server S, crittato con K_S

DoOperation:

il cliente interagisce con il server

il cliente richiede il servizio al server

Schema comunicazione: Cliente Server

Contenuto messaggio:

{auth(C)}K_CS, cioè un nuovo authenticator crittato con la session key K_CS

{ticket(C,S)}K_S, ricevuto prima dal TGS

request, la richiesta di servizio

n

il server si autentica con il cliente (opzionale)

il server per provare la sua autenticità ritorna il nonce crittato con la session key K_CS. Per limitare il numero di messaggi questa comunicazione potrebbe essere inserita dal server nella sua risposta alla request

Schema comunicazione: Cliente Server

Contenuto messaggio: {n}K_CS, cioè il nonce crittato con la session key K_CS