Kerberos

Kerberos è un protocollo di autenticazione sviluppato presso il MIT, il cui nome evoca il famoso cane a tre teste della mitologica greca, e fornisce un meccanismo per una autenticazione reciproca (mutual authentication) tra client e server o tra due server. Il protocollo assume che le transazioni iniziali tra client e server avvengano in una rete insicura, probabilmente sotto monitor di qualche utente smaliziato, e che anche i computer non siano posti in un luogo sicuro, probabilmente saranno collegati a Internet. In un ambiente poco sicuro, sia esso Internet o una intranet, non è escluso poter trovare un attaccante in grado di intercettare le comunicazioni tra client e server e di catturare dati o, peggio, di modificarli. Il sistema di autenticazione Kerberos, così come la figura mitologica, è composto da tre elementi: il Key Distribution Center (KDC), l’utente e il server con il servizio a cui l’utente vuole accedere. Nei prossimi paragrafi si riassumeranno le caratteristiche salienti di Kerberos, ma per maggiori informazioni si suggerisce una lettura approfondita della bibliografia, in particolare del whitepaper “Kerberos: An Authentication Service for Open Network Systems”, presentato a USENIX nel 1988, e del WhitePaper “Windows 2000 Kerberos Authentication”.

Il Key Distribution Center

In Kerberos esiste il concetto di Realm, simile a quello dei domini di Windows. Si tratta di un dominio (o Realm appunto) di autenticazione su cui gli utenti verificano le proprie credenziali, ovvero username e password. Tipicamente ad un nome di dominio DNS viene associato un Realm, ad esempio ATHENA.MIT.EDU oppure AZIENDA.IT. Convenzionalmente i Realm di Kerberos sono scritti in maiuscolo, contrariamente ai nomi DNS che vengono scritti in minuscolo (anche se il DNS non è case sensitive). Il Key Distribution Center è il cuore di un realm e svolge due funzioni principali: l’Authentication Service (AS) e il Ticket Granting Service (TGS). Come si evince dalla figura sottostante, lo scambio di chiavi dell’utente per accedere ad una risorsa avviene in tre fasi: AS Exchange, TGS Exchange e Client/Server (CS) Exchange.

AS Exchange

Quando l’utente effettua un’autenticazione alla rete, esso deve immettere un’utenza e una password che vengono verificate dall’Authentication Service (AS) che fa parte del KDC. Il KDC interroga il suo database di utenza e, una volta verificate le credenziali dell’utente, rilascia all’utente un Ticket Granting Ticket (TGT) che è valido per il Realm di appartenenza. Il TGT ha una “vita limitata” e può essere rinnovata automaticamente qualora la sessione utente sia ancora attiva e senza che quest’ultimo reinserisca username/password. Il TGT è mantenuto in memoria nella macchina client e viene usato per richiedere accesso ad un determinato servizio. Vediamo in dettaglio lo scambio per l’ottenimento del TGT. La richiesta dell’AS identifica il client al KDC in chiaro. Se la preautenticazione è abilitata sull’utente, un timestamp viene criptato con l’hash della password dell’utente come chiave di crittografia. Se il KDC, una volta decriptato il timestamp con l’hash della password, lo identifica come valido, allora il KDC saprà che non si tratta di un playback attack di una richiesta precedente. La preautenticazione dell’utente può essere disabilitata, ma è consigliabile usarla quando possibile. Se il KDC autorizza la richiesta del client all’ottenimento del TGT, la riposta dell’AS nei confronti del client includerà due sezioni: un TGT criptato con una chiave che solamente il KDC (TGS) può decriptare e una chiave di sessione criptata con l’hash della password dell’utente (serve per le future comunicazioni con il KDC). Siccome il client non può leggere il contenuto del TGT, esso dovrà presentarlo così com’è al TGS per avere un service ticket. Il TGT include parametri di time-to-live, autorizzazione, una chiave di sessione per comunicare con il client e il nome del client/utente.

TGS Exchange

L’utente presenta il TGT al TGS (una delle due parti del KDC) quando vuole accedere ad un determinato servizio. Il TGS verifica il TGT dell’utente e crea un ticket e una chiave di sessione sia per il client che per il server remoto. Queste informazioni, conosciute come service ticket, sono poi memorizzate localmente sulla macchina client. Il TGS riceve il TGT del client e lo legge attraverso la propria chiave. Se il TGS ritiene corretta la richiesta del client, un Service Ticket viene generato sia per il client che per il server a cui l’utente sta tentando di accedere. Il client legge la sua porzione usando la chiave di sessione del TGS che ha ricevuto precedentemente durante la risposta dell’AS. Il client presenta la porzione del Service Ticket relativa al server alla risorsa a cui sta accedendo durante il Client/Server Exchange.

Client/Server Exchange

Una volta che l’utente ha ottenuto il Service Ticket, può stabilire la sessione con il servizio erogato dal server. Il server può decriptare le informazioni che arrivano indirettamente dal TGS usando la propria chiave stabilita con il KDC. Il Service Ticket viene quindi usato per autenticare l’utente e stabilire una sessione di erogazione servizio tra il server e il client. Dopo che il time-to-live (lifetime) del ticket è terminato, il Service Ticket deve essere rinnovato per poter usare il servizio. Nello specifico, il client passa la porzione relativa al server del Service Ticket, al server verso cui sta richiedendo il servizio per ottenere la sessione client/server. Se la mutual authentication è abilitata, il server ritorna un timestamp criptato con la chiave di sessione del Service Ticket. Se il timestamp viene decriptato correttamente, non solo il client si è autenticato al server, ma il server si è anche autenticato con il client. Il target server non ha mai comunicato direttamente con il KDC, il che riduce il carico sul KDC.

Kerberos e l’orologio di sistema (clockskew)

Come accennato in precedenza, il meccanismo di autenicazione di Kerberos si basa sui TimeStamp, ovvero sulla data e l’ora. È necessario quindi che tutti i sistemi coinvolti abbiano l’orologio di sistema allineato: sebbene sembri una cosa banale, molte volte durante il setup del laboratorio si sono verificati problemi di autenticazione a causa del disallineamento dell’ora (nel mio caso era il fuso orario). Si consiglia, qualora non si abbia, di installare in azienda un time server di riferimento e sincronizzare sia i server che le workstation con questo server. In Kerberos viene anche introdotto il concetto di clockskew: si tratta di una tolleranza di tempo entro il quale il timestamp risulta comunque valido. Se non diversamente configurato, in Kerberos il clockskew standard è di 5 minuti.