Protocollo Kerberos
Anche se la soluzione NTLM è stata lasciata dalla Microsoft per compatibilità con sistemi (client e server) precedenti, la soluzione nativa che viene oramai proposta per autenticazione in ambiente Windows prevede uso del protocollo Kerberos che, nella versione originale, è stato proposto dal MIT come soluzione per proteggere accesso ai servizi della rete sperimentale del progetto Athena.
La prima versione ufficialmente rilasciata dal MIT è la versione 4 (apparsa alla fine degli anni 80).
Successivamente a un accurato processo di crittoanalisi la versione 4 è stata riveduta e corretta per divenire Kerberos v5 (definita nella RFC 4120).
La soluzione adottata da Microsoft è un variante di tale soluzione generale (alcune indicazioni sulle modifiche introdotte sono descritte nella RFC 3244).
La base del protocollo Kerberos è costituita dallo schema Needham-Schroeder, che propone l’uso di ticket per provare l’identità degli utenti.
Lo schema richiede la presenza di una terza parte fidata, nota sia al client sia al server.
Tale terza parte svolge il ruolo di Authentication Server (AS) e di generatore di ticket (Ticket Granting Server, TGS).
Ciascun partecipante è tenuto a condividere con il server terza parte una chiave segreta.
La conoscenza di tale chiave segreta serve a provare l’identità di ciascuna entità coinvolta.
La comunicazione tra due entità avviene attraverso un canale reso sicuro dalla generazione di session key temporanee.
Lo scenario in cui opera Kerberos può essere descritto nel modo seguente:
- Alice vuole utilizzare un servizio erogato da Bob previa autenticazione;
- Alice e Bob si fidano di un Server terza parte che funge da autenticatore;
- Alice condivide una chiave comune con il Server denominata KAS;
- Bob condivide una chiave comune con il Server denom,inata KBS;
- Alice vuole sfruttare un canale sicuro per ottenere dal Server le credenziali per accedere a Bob.
Lo schema prevede i seguenti passi:
- Alice invia al Server un messaggio MAS chiedendo di poter comunicare con Bob (nel messaggio viene inserito un nonce NA);
- il Server genera una chiave di sessione KAB e la invia cifrata ad Alice (nel messaggio inviato esistono due copie della chiave, la prima destinata ad Alice e una seconda cifrata con la chiave KBS destinata a Bob);
- Alice decifra la propria parte del messaggio ricevuto dal Server e invia la parte codificata per Bob all’altro partecipante;
- Bob decodifica il messaggio ricevuto usando la chiave segreta condivisa con il Server per ricavare la chiave di sessione KAB;
- Bob genera un challenge codificando un Nonce NB con la chiave di sessione;
- Alice risponde alla sfida decodificando il challenge restituendo la versione decrementata di una quantità prestabilita del nonce NB a Bob;
Così come descritto il processo di scambio delle chiavi è soggetto a replay attack.
Per evitare questo occorre modificare opportunamente i messaggi inviati, inserendovi dei timestamp.
Il protocollo Kerberos versione 5 si basa sullo schema precedente e permette la generazione di “one time ticket” per ogni richiesta di servizio.
Nel dettaglio il protocollo evolve nel modo seguente:
- Alice digita username e password sul proprio client;
- il software disponibile sul client effettua una trasformata non reversibile (hash) della password per ricavare la chiave segreta di Alice;
- il client invia un messaggio in chiaro all’Authentication Server (AS) contenente la richiesta di servizio;
- AS verifica la presenza del client nel proprio database degli account e se ottiene riscontro positivo restituisce due messaggi al client:
- Msg 1: contiene la chiave di sessione tra client e Ticket Granting Server (TGS) cifrata con la chiave segreta di Alice;
- Msg 2: Denominato Ticket-Granting Ticket contiene l’identificativo del client, il suo indirizzo di rete, il periodo di validità del ticket e la stessa chiave di sessione inserita nel primo messaggio, il tutto codificato con la chiave segreta del TGS;
- ricevuto il primo messaggio, il client lo decodifica e ricava la chiave di sessione da usare in ogni altra comunicazione con il TGS;
- il client richiede la possibilità di accedere ala servizio al TGS inviando due messaggi:
- Msg 3: è la replica del secondo messaggio con l’aggiunta dell’identificativo del servizio richiesto;
- Msg 4: denominato Authenticator contiene l’identificativo del client e il timestamp corrente, il tutto codificato con la chiave di sessione condivisa tra client e TGS;
- TGS ricava la chiave di sessione e decodifica il quarto messaggio, dopodichè invia al client due messaggi:
- Msg 5: denominato Client-to-Server Ticket, contiene l’identificativo del client, il suo indirizzo di rete, il periodo di validità del ticket e una nuova chiave di sessione che dovrà essere condivisa tra client e server, il tutto codificato con la chiave segreta condivisa colo tra server e TGS;
- Msg 6: contiene la chiave di sessione da usare nelle comunicazioni tra client e server cifrata con la chiave condivisa tra client e TGS;
- il client decodifica il sesto messaggio e ricava la nuova chiave di sessione (non può invece operare sul quinto messaggio in quanto non è a conoscenza della chiave segreta del server) dopodichè produce due messaggi e li invia al server che eroga il servizio richiesto;
- Msg 7: è la replica del quinto messaggio;
- Msg 8: denominato Authenticator (ma diverso dal quarto messaggio) contiene l’identificativo del client e il timestamp corrente, il tutto codificato con la chiave di sessione condivisa tra client e server;
- il server decodifica il settimo messaggio e ricava la chiave di sessione per decodificare anche il messaggio successivo, dopodichè produce un ultimo messaggio per provare la propria identità al client e la propria disponibilità all’erogazione del servizio richiesto;
- Msg 9: contiene il timestamp inviato dal client incrementato di uno codificato con la chiave di sessione condivisa tra client e server;
- il client decodifica l’ultimo messaggio trovando contemporanea conferma dell’identità del server e della disponibilità del servizio richiesto (da questo momento può inviare comandi e dati al server);
- il server processa i comandi ricevuti e restituisce le informazioni richieste al client.
Il protocollo Kerberos richiede la disponibilità delle componenti AS e TGS per consentire la generazione di ticket per l’accesso ai vari servizi.
Se il server centrale è momentaneamente indisponibile, l’accesso al server che eroga uno specifico servizio è ugualmente bloccato.
Per evitare single point of failure è possibile prevedere attivazione di più AS e TGS.
Per il corretto funzionamento del protocollo è inoltre necessario che i clock dei sistemi coinvolti siano tra loro sincroni.
Normalmente è accettato uno scostamento relativo purché non superiore a qualche minuto (max10).
