fig. 2: Protocollo di base di Kerberos
In uno scenario come quello appena visto, si prospetta un potenziale problema: per ogni servizio il client dovrà usare la propria chiave "segreta" e questo significa che l'utente dovrà digitare ogni volta la password, perché come vedremo la chiave segreta è calcolata a partire dalla password.
Il problema in questo caso è che l'utente è normalmente portato a vedere come un fastidio la password ed inserirla spesso lo spinge a usare password deboli; inoltre usare la chiave segreta significa in qualche modo esporla troppo ad attacchi di tipo "Known Cyphertext".
Per evitare questo inconveniente introduciamo una nuova figura che chiamiamo "Ticket Granting Server" (TGS)
La figura seguente è da intendersi come integrazione allo schema visto precedentemente.
Funziona nel seguente modo. Il client che ha appena eseguito la login dovrà richiedere all'AS un Ticket per comunicare con il TGS.
L'AS (come abbiamo visto prima) manda al client due Ticket con la chiave di sessione Ks, uno cifrato con Kcli e un altro con KTGS (la chiave del TGS). Dopo ciò il client effettuerà la richiesta al TGS (come in figura) mandando il Ticket cifrato con KTGS e l'Autenticator. Questo Ticket è chiamato Ticket Granting Ticket (TGT) ed ha una vita relativamente corta, circa 8 ore.
Un client che è in possesso di un TGT valido farà le sue richieste di servizio al TGS e non più all'AS, almeno fino a quando il TGT non sarà scaduto. Le comunicazioni tra TGS e client saranno cifrate con la chiave di sessione Ks estratta dal TGT e non con la chiave segreta del client. Il TGS autenticherà il client, con il metodo visto precedentemente per l'autenticazione client/server, e rilascerà un Ticket e un'altra session key per la comunicazione client/server.
Infine le transizioni in arancio avverranno nel modo consueto utilizzando il Ticket e la session key di volta in volta concesse dal TGS.