Il protocollo Kerberos è usato da Windows 2000 come metodo primario per l’autenticazione degli utenti su computer con Windows 2000, in sostituzione del vecchio protocollo NTLM, nonostante quest'ultimo venga ancora mantenuto per la compatibilità verso client e server che usano Windows NT 4.0, o Windows 9x.
Il motivo dell'introduzione del protocollo Kerberos è dovuto alla sua flessibilità, efficienza e maggiore sicurezza rispetto a NTLM.
In particolare Kerberos introduce i seguenti benefici:
Autenticazione più efficiente. Con NTML, un server deve connettersi a un controller di dominio per autenticare ciascun client. Con il Kerberos, invece, il server può autenticare il client esaminando le credenziali presentate dal client.
Mutua autenticazione. NTLM permette ai server di verificare l'identità dei loro client. Esso però non permette ai client di verificare l'identità di un server, o ad un server di verificare l'identità di un altro; infatti NTLM era stato progettato per reti in cui ciascun server era considerato sicuro. Kerberos, invece non fa di tali assunzioni.
Semplificata gestione della fiducia. Il protocollo Kerberos fa in modo che la fiducia tra le autorità di sicurezza per domini Windows 2000 sia bidirezionale e transitiva. In particolare i domini vengono organizzati in un albero di fiducia, in cui ogni nodo ha una relazione di fiducia bidirezionale con il suo genitore. Sfruttando poi la transitività, due domini non connessi direttamente possono comunque stabilire una relazione di fiducia tra loro (figura 1).
Kerberos fu sviluppato al MIT (Massachussets Institute of Technology) negli anni Ottanta con un progetto denominato Athena. Lo scopo di Athena era di progettare, implementare e amministrare gli ambienti distribuiti, in modo da ottenere una massiccia autenticazione per le applicazioni client/server attraverso la crittografia a chiave segreta e condivisa.
Il protocollo Kerberos utilizza una tecnica di autenticazione basata sui cosiddetti segreti condivisi: se Annarella confida un segreto a Biagio, il segreto è conosciuto solo da loro; ma se Biagio riceve comunicazioni riguardo quel segreto, deve essere certo che si tratti di Annarella, perciò Annarella include una password. Se i due amici si mettono d’accordo sulla password, essa rappresenta un segreto condiviso.
Questo meccanismo di può essere violato: se qualcuno avesse sentito Annarella pronunciare la password, il segreto non sarebbe più tale. Kerberos risolve i problemi legati alla sicurezza dell’autenticazione attraverso l’utilizzo della crittografia a chiave simmetrica: piuttosto che condividere una password, Annarella e Biagio condividono una chiave crittografica.
Vediamo con semplice esempio, quale l’idea di schema di autenticazione su cui si basa Kerberos.
Supponiamo che Annarella e
Biagio, prima di trasferire qualunque informazione tra i loro computer, vogliano
verificare l’identità della persona che sta dall’altra parte del
collegamento. Essi si accordano nel seguente modo:
Figura 2 – Autenticazione Annarella - Biagio
Rimane ancora un problema da risolvere: come o dove Annarella e Biagio si accordano sulla chiave segreta?
Se fossero persone, il modo più semplice sarebbe quello di incontrarsi in un luogo pubblico e accordarsi. Purtroppo noi siamo interessati a quelli scenari in cui Annarella è un’applicazione client che è eseguita su una workstation e Biagio è un servizio che è eseguito su un server di rete. Ci sono poi altre considerazioni da fare:
a) un applicazione può richiedere di comunicare con più server, ed ha quindi la necessità di mantenere più chiavi;
b) un servizio potrebbe comunicare con più applicazioni client, e anch’esso deve mantenere un insieme di chiavi.
Pertanto è necessario dover memorizzare e proteggere molte chiavi, ed è qui che il protocollo Kerberos gioca un ruolo fondamentale.
Il nome Kerberos deriva da Cerbero, il famoso cane della mitologia greca munito di tre teste che sorvegliava l’entrata dell’ADE. Le tre teste possono rappresentare, nel nostro ambito, le seguenti tre parti:
Quando un client vuole comunicare con un server, il client trasmette una richiesta al KDC, e quest’ultimo distribuisce una unica chiave di sessione, affinché le due parti possano autenticarsi l’un l’altra. In particolare il client e il server memorizzano, cifrandola, la chiave di sessione nelle proprie chiavi a lungo termine.
Il KDC risponde alla richiesta del client, circa la richiesta di comunicazione con il server, mandando entrambe le chiavi di sessione al client (figura 3). La copia del client viene cifrata con la chiave segreta che il KDC condivide con il client, mentre la copia del server viene inserita in una struttura dati, chiamata ticket di sessione, che viene poi criptata con la chiave segreta che il KDC condivide con il server. Per tali operazioni si dice che il KDC fornisce un Ticket-Granting Service. Da notare che quando il client riceve il ticket di sessione, si assume la responsabilità di gestire tale ticket fino a quando contatterà il server.
Nelle successive figure, con la notazione KA{B} denoteremo il valore di B cifrato con la chiave segreta di A.
Figura 3 – Comunicazione client - KDC
Una volta ricevuta la risposta dal KDC, il client estrae il ticket e la sua copia della chiave di sessione, e li memorizza nella cache delle credenziali.
Quando il client vuole comunicare con il server, gli trasmette un messaggio in cui sono inclusi il ticket di sessione, criptato con la chiave segreta del server, e la coppia (Identificare utente, timestamp) criptata con la chiave di sessione. Quando il server riceve le credenziali da un client, decifra il ticket di sessione, estrae la chiave di sessione e la usa per decifrare la coppia (Identificare utente, timestamp). Se va tutto bene il server autentica il client. A questo punto, affinché il client possa a sua volta autenticare il server, quest'ultimo trasmette al client, cifrandolo con la chiave di sessione, il timestamp precedentemente ricevuto (figura 4).
Figura 4 – Mutua autenticazione tra client e server
Va notato che con tale procedura, il client non necessita di comunicare con il KDC, ogni qualvolta deve accedere al server: le chiavi di sessioni possono essere riutilizzate.
Inoltre, il KDC mantiene un database con informazioni di account su tutti gli utenti appartenenti al dominio insieme con una chiave crittografica nota solo all’utente (e ovviamente al KDC). Questa chiave viene detta chiave a lungo termine , ed è usata per stabilire una iniziale comunicazione tra il client e il KDC. Infatti, una volta che sul client un utente ha effettuato il logon, la password inserita viene trasformata dal client in una chiave a lungo termine dell'utente (attraverso una qualunque funzione hash). A sua volta il KDC, ricevute le credenziali dell'utente, recupera, dal database degli account, la chiave di sessione relativa all'utente. Dopo l'autenticazione dell'utente, il client trasmette al KDC la richiesta per uno speciale ticket di sessione, detto Ticket-Granting Ticket (TGT); tale TGT verrà utilizzato per rendere sicura la comunicazione tra client e KDC. Il KDC, dopo aver criptato il TGT con la propria copia delle chiave a lungo termine dell'utente, lo trasmette al client, il quale provvederà a criptarlo con la chiave a lungo termine dell'utente generata a partire dalla password. A questo punto, il client fornirà il TGT ogni volta che farà al KDC una richiesta per un server.
Nella figura successiva viene mostrata, in maniera sintetica, la sequenza di tutte le operazioni, con i relativi ticket creati, eseguite affinché un client possa accedere ad un server.
Il protocollo Kerberos è strutturato in tre sottoprotocolli:
Authentication Service (AS) Exchange, nel quale il KDC rilascia i TGT (Ticket-Granting Ticket) al client;
Ticket-Granting Service (TGS) Exchange, nel quale il KDC distribuisce i ticket di sessione e le chiavi di sessione;
Client/Server (CS) Exchange, nel quale il client presenta il ticket di sessione per ottenere un servizio.
Per capire come questi tre protocolli lavorano insieme, vedremo come Alice, utente di una workstation, ottiene l'accesso a Bob, che rappresenta un servizio di rete.
Alice comincia il logon sulla rete, inserendo il nome account e la password. Il client Kerberos sulla workstation di Alice converte la sua password in una chiave crittografica e la salva in una zona di memoria.
Successivamente, il client trasmette al servizio di autenticazione del KDC il messaggio Kerberos Authentication Service Request (KRB_AS_REQ): la prima parte di questo messaggio identifica l'utente, Alice, e il nome del servizio per il quale sta richiedendo il ticket di sessione (o TGS); la seconda parte del messaggio contiene il preauthentication data (in genere un timestamp cifrato con la chiave a lungo di termine di Alice), che fornisce la prova che Alice conosce la password.
Quando Il KDC riceve KRB_AS_REQ, controlla le informazioni di Alice nel database, preleva la sua chiave a lungo termine, decifra il preauthentication data, e valuta il timestamp. Se la verifica ha esito positivo, Il KDC è sicuro dell'identità di Alice, crea le credenziali utilizzate dal client per richiedere il ticket di sessione: innanzitutto, il KDC genera una chiave di sessione e ne cifra una sua copia con la chiave a lungo termine di Alice; poi, inserisce un'altra copia, di tale chiave di sessione nel TGT, e cifra quest'ultimo con la sua propria chiave a lungo termine. Queste informazioni vengono spedite sl client al cliente attraverso il messaggio Kerberos Authentication Service Reply (KRB_AS_REP).
Quando il client riceve il messaggio, usa la chiave generata dalla password di Alice per decifrare la sua chiave di sessione, e la memorizza, insieme con il TGT, nella cache delle credenziali.
Il client Kerberos sulla workstation di Alice richiede il ticket di sessione per il server Bob trasmettendo al KDC un Kerberos Ticket-Granting Service Request (KRB_TGS_REQ). Questo messaggio include il nome dell'utente, un identificativo dell'utente (ID utente, timestamp) criptato con la chiave di sessione dell'utente, il TGT ottenuto nel AS Exchange, e il nome del servizio (o server) per il quale l'utente vuole un ticket.
Quando il KDC riceve il messaggio KRB_TGS_REQ, decifra il TGT con la sua chiave privata, estrae la chiave di sessione di Alice, per decifrare l'identificativo utente. Verificata l'identità dell'utente, genera la chiave di sessione che verrà condivisa tra il client e il server (Bob). Il KDC cifra una copia di questa chiave con la chiave di sessione di Alice, mentre l'altra copia viene criptata con la chiave a lungo termine di Bob, ottenendo così il ticket di sessione. Queste informazioni vengono trasmesse al client, incluse nel messaggio Kerberos Ticket-Granting Service Reply (KRB_TGS_REP).
Il client Kerberos sulla workstation di Alice richiede il servizio a Bob (server) trasmettendogli il messaggio Kerberos Application Request (KRB_AP_REQ), che contiene l'identificativo utente (ID utente, timestamp) criptato con la chiave di sessione condivisa con Bob, e il ticket di sessione ottenuto durante il protocollo TGS Exchange.
Bob ricevuto il messaggio, decifra il ticket di sessione, e utilizzando la chiave di sessione condivisa, decifra l'identificativo utente al fine di verificarne l'identità. Successivamente, utilizza la chiave di sessione condivisa per criptare il timestamp ricevuto dal client e lo trasmette al client con il messaggio Kerberos Application Reply (KRB_AP_REP).
Quando il client riceve il messaggio KRB_AP_REP, il contenuto viene decifrato con la chiave di sessione condivisa, e confronta il timestamp così ottenuto con il timestamp precedentemente trasmesso al server. Se c'è corrispondenza, il client autentica il server e la comunicazione procede. Durante la comunicazione tra client e server, la chiave di sessione condivisa può essere utilizzata per criptare i dati.
Figura 8 - Protocollo CS Exchange
In Windows 2000, il componente principale del protocollo Kerberos è il KDC (Key Distribution Center), che viene implementato come un servizio di dominio. Esistono altri componenti, alcuni dei quali vengono di seguito descritti.
Il KDC (Key Distribution Center)
è un servizio attivo su tutti i controller di
dominio. Esso è munito di due
servizi:
Il servizio KDC viene avviato automaticamente in tutti i controller di dominio dal loro LSA e opera nello stesso spazio di quest’ultimo; cosi come LSA, il KDC non può essere sospeso. Windows 2000 assicura la disponibilità di questo servizio permettendo a ciascun dominio di avere diversi controller di dominio; infatti, qualunque di questi controller di dominio può accettare richieste di autenticazione e richieste dei ticket dirette al KDC del dominio.
Il nome utente usato dal KDC per un dominio Windows 2000 è krbtgt, il cui account viene creato automaticamente quando viene creato un dominio; tale account non può essere né modificato né cancellato. La password, assegnata automaticamente, è utilizzata per derivare una chiave per cifrare e decifrare i TGT che sono rilasciati. I client, quando indirizza i messaggi al KDC, include sia il krbtgt che il nome del dominio; inoltre, tali informazioni sono utilizzate nei ticket per identificare l’autorità erogatrice.
Come database degli account, Kerberos si avvale di Active Directory per ottenere le informazioni circa gli utenti: ciascuno utente è rappresentato da un oggetto di account in Active Directory.
Il protocollo Kerberos è implementato come SSP (Security Support Provider, provider di supporto di sicurezza), una DLL fornita da Windows 2000. Windows 2000 include anche un SSP per l’autenticazione NTML; infatti entrambi vengono caricate dal LSA al momento dell’avvio del sistema, e possono essere utilizzati per autenticare il logon di utenti e connessioni client/server. La scelta del protocollo da usare dipende dalle capacità della macchina che si trova sull’altro lato della connessione.
I servizi di sistema possono accedere ai SSP attraverso il SSPI (Security Support Provider Interface); questa interfaccia consente ai vari servizi distribuiti di Windows 2000 di accedere al SSP di Kerberos. Tra questi servizi annoveriamo: servizi di spool di stampa, interrogazioni LDAP ad Active Directory, autenticazione delle intranet sull’IIS (Internet Information Service).
Sulle macchine che utilizzano Windows 2000, le chiavi e i tickets ottenuti dal KDC, vengono mantenute nella cache delle credenziali, ovvero un’area di memoria volatile protetta dal LSA, e che non viene mai paginata sul disco. Tale memoria si svuota quando il sistema viene spento o quando l’utente effettua i log out.
La cache delle credenziali viene gestita dal SSP di Kerberos: quando vi è la necessità di modificare la cache delle credenziali, LSA chiama l’SSP di Kerberos.
Vediamo adesso come avviene il processo di autenticazione in Windows 2000, quando un utente, che per semplicità chiameremo Biagio, tenta di accedere ad una risorsa di rete, per esempio una stampante. Consideriamo due scenari: il primo, in cui Biagio vuole accedere ad una stampante del suo stesso dominio; il secondo in cui la stampante si trova in un dominio diverso.
Biagio avvia la procedura di accesso sulla propria macchina, inserendo l’account con la relativa password. Queste credenziali vengono inviate al controller del dominio, il quale le confronta con le informazioni di accesso contenute in Active Directory; se c’è corrispondenza, Biagio può accedere al dominio e riceve un TGT di riferimento, emesso dal KDC del controller di dominio.
A questo punto Biagio richiede l’utilizzo della stampante di rete, presentando al KDC il proprio TGT e richiedendo un ST (Service Ticket, ticket di servizio) per utilizzare la stampante; il KDC, verificato che Biagio abbia i relativi permessi per utilizzare la stampante, concede il ST (figura 9).
Le cose cambiano leggermente quando la stampante, che Biagio vuole utilizzare, si trova in un altro dominio, per esempio il dominio Y. Biagio, con la procedura di logon, ha ottenuto l’accesso al X e il TGT dal KDC. Biagio però non può richiedere il ST al KDC del proprio dominio, poiché la stampante si trova in un altro dominio, per cui Biagio deve fornire il TGT al KDC del dominio Y, il quale rilascerà l’ST a Biagio per l’utilizzo della risorsa (figura 10).
Figura 9 - Acceso alle risorse in un solo dominio
Figura 10 - Accesso alle risorse di un altro dominio
Il fatto che Biagio possa accedere dalle risorse di un altro dominio, con l’autenticazione che egli ha effettuato con il suo dominio, è possibile grazie al meccanismo della fiducia transitiva che il protocollo Kerberos implementa.
Possiamo definire la fiducia transitiva con un semplice esempio:
il dominio DA ripone fiducia nel dominio DB, e DB la ripone in DC => il dominio DA ripone una fiducia transitiva verso il dominio DC.
In altre parole, il rapporto di fiducia che le due aree di autenticazione hanno definito viene ereditato da tutti i domini sotto di loro; inoltre essi sono bidirezionali, e quindi ogni volta che un nuovo dominio si aggiunge all’albero di domini, esso partecipa immediatamente alle relazioni stabilite con tutte le altre aree di autenticazione.
Ciò vuol dire che il KDC fornisce a Biagio un TGT sul domino di fiducia, il quale consente a Biagio di potersi autenticare sul KDC appartenente a qualsiasi dominio nell’albero, e riceverà da questo un ST con cui potrà accedere alla risorsa richiesta.
Figura 11 - Fiducia transitiva tra domini
Potrebbe succedere, però, che Biagio, per poter accedere ad una determinata risorsa di una altro dominio, sfruttando le relazioni di fiducia, richiede un numero molto alto di riferimenti tra domini, portando ad un notevole aumento del traffico sulla rete. Per rendere efficiente questa operazione, viene stabilita fra domini una scorciatoia di fiducia, riducendo il traffico e aumentando l’efficienza dell’accesso (figura 12).
Per evitare che i ticket possa diventare compromettenti, hanno un tempo di inizio e di fine, ed in un qualunque momento di tale periodo, l’utente li può utilizzare per accedere alle risorse per un numero illimitato di volte. La durata massima dei ticket viene impostata dall’amministratore. Per verificare la durata di un ticket, quando un utente richiede un ST ad un KDC per una risorsa, il KDC determina il valore del campo relativo alla fine del ticket, aggiungendo la durata massima del ticket (determinata dalla politica di Kerberos) al valore memorizzato nel campo d’inizio del ticket, campo impostato all’istante di tempo in cui il ticket è stato creato; il server, a cui viene inoltrata la richiesta di accesso alla risorsa, confronterà tale risultato con l’istante in cui avviene, e l’accesso alla risorsa viene garantito solo se il ticket non è scaduto.
|
|
Qualcuno potrebbe chiedersi: ma perché Kerberos non notifica al client la scadenza del ticket? Il motivo è legato alle prestazione della rete e dei server: se Kerberos notificasse tutti i client che possiedono il ticket, il KDC e la rete potrebbero subire dei cali nelle prestazioni.
Figura 12 - Utilizzo delle scorciatoie di fiducia
Per ulteriori approfondimenti, si può consultare il capitolo Riferimenti.