STUDIO DI APPLICABILITÀ DEL PROTOCOLLO KERBEROS ALL INTRANET DISI. Alessandro Siena

Transcript

1 STUDIO DI APPLICABILITÀ DEL PROTOCOLLO KERBEROS ALL INTRANET DISI di Alessandro Siena Tesi presentata per la discussione del diploma di laurea in Informatica Università di Genova Facoltà di Scienze Matematiche Fisiche e Naturali Dipartimento di Informatica e Scienze dell Informazione A.A. 2000/2001 Relatori prof. Giovanni Chiola dott. ing. Stefano Bencetti Correlatore prof. Vittoria Gianuzzi Università degli Studi di Genova Genova, xx/yy/2002

2 Università di Genova ESTRATTO STUDIO DI APPLICABILITÀ DEL PROTOCOLLO KERBEROS ALL INTRANET DISI di Alessandro Siena Relatori: prof. G. Chiola, dott. ing. S. Bencetti Correlatore: prof. V. Gianuzzi Dipartimento di informatica e Scienze dell Informazione Kerberos è un protocollo di autenticazione progettato per fornire un alto livello di autenticazione per le applicazioni client-server attraverso l uso della crittografia a chiave segreta. Originariamente sviluppato al Massachussetts Institute of Technology, è oggi incluso in gran parte del software presente sul mercato. Oggetto di questa tesi di laurea è lo studio dell integrazione di quanto fornito da diversi sistemi operativi al fine di permettere un autenticazione sicura su sistemi informativi non omogenei sia da un punto di vista software che hardware.

3 SOMMARIO INTRODUZIONE... 1 L intranet DISI... 2 KERBEROS... 5 Descrizione del protocollo... 7 Autenticazione cross-realm Condizioni di funzionamento Formato dei ticket Database Kerberos IMPLEMENTAZIONE NELL AMBIENTE WINDOWS Funzionalità del protocollo Accesso all interfaccia Applicazioni che supportano Kerberos IMPLEMENTAZIONE NELL AMBIENTE UNIX Applicazioni che supportano Kerberos Accesso all interfaccia Implementazione nell ambiente Solaris INTEGRAZIONE ED INTEROPERABILITÀ Scenari di interoperabilità TEST Come configurare Kerberos in ambiente Windows Come configurare Kerberos in ambiente Linux Il prototipo sviluppato Configurazione del prototipo GLOSSARIO BIBLIOGRAFIA... 73

4 INDICE DELLE FIGURE Numero Pagina Figura 1: Struttura dell intranet DISI 3 Figura 2: Protocollo di autenticazione Kerberos (Base) 8 Figura 3: Protocollo Kerberos completo 9 Figura4: Processo di autenticazione Kerberos 19 Figura 5: Processo delega Kerberos 22 Figura 6: Processo di accesso interattivo locale 23 Figura 7: Processo di accesso interattivo di domino 24 Figura 8. L interfaccia dell implementazione di Kerberos in Linux 36 Figura 9. Il prototipo implementato in laboratorio 66 ii

5 RINGRAZIAMENTI Un doveroso ringraziamento va a tutti coloro che hanno seguito con vivo interesse lo sviluppo di questa tesi; in particolare: Davide Petta, che mi ha supportato (col suo firewall) e sopportato fianco a fianco in laboratorio; Gianni Verduci e Angelo margarino, per il preziosissimo supporto sistemistico. Ringrazio anche tutti coloro che sono stati al mio fianco in questi anni di studi: Papà e mamma, che hanno sostenuto e sopportato (in tutti i sensi) la mia carriera universitaria; I nonni Armando e Luisa, che ogni volta che avevo un esame si facevano salire la pressione; Gli zii Stefano e Pinin, che ogni volta che avevo un esame addolcivano la pillola; Mia cugina Silvia che dopo avermi stressato per cinque anni tutte le mattine sulla via per l università ha pensato fosse meglio laurearsi piuttosto che sentire ancora per una anno le mie lamentele sul traffico in corso Europa. I compagni di studi con i quali ho condiviso faticose ma divertenti giornate di studi: Siete troppi per elencarvi tutti!!! Gli amici della Corale Polifonica S. Maria di Bogliasco che hanno contribuito ad alleggerire il peso di questi anni di studio. Tutti i miei amici vicini e lontani. iii

6 Giunti che furo, il gran Cerbero udiro abbaiar con tre gole, e l buio regno intonar tutto; indi in un antro immenso sel vider pria ginger disteso avanti, poi sorger, digrignar, rapido farsi, con tre colli arruffarsi, e mille serpi squassarsi intorno. (Virgilio, Eneide: Libro VI, ) Cerbero, fiera crudele e diversa, con tre gole carinamente latra sopra la gente che quivi è sommersa. Li occhi ha vermigli, la barba unta e atra, e l ventre largo, e unghiate le mani; graffia li spirti, iscuoia ed isquarta. (Dante, La Divina Commedia, Inferno: Canto VI, 13-18) iv

7 Capitolo 1 Oggetto della nostra ricerca è lo studio del protocollo di autenticazione Kerberos nell ottica di una sua applicazione al sistema informatico del Dipartimento di Informatica e Scienze dell Informazione dell Università di Genova. INTRODUZIONE I moderni sistemi informatici forniscono una grande varietà di servizi ad una molteplicità di utenti, per cui si é reso necessario identificare i singoli utenti in maniera univoca. Questo servizio è offerto dai sistemi tradizionali in fase di login, attraverso la verifica della corrispondenza di una password ad un determinato nome utente; il sistema può così validarlo e offrirgli i servizi a lui concessi. Tale metodo di autenticazione non é più sufficiente per gli attuali sistemi informativi, costituiti da un gran numero di elaboratori collegati fra loro attraverso reti che sempre più spesso sono di dimensione geografica su larga scala. Le password che viaggiano in rete nei sistemi tradizionali sono trasmesse in chiaro, motivo per cui qualunque intercettatore le può in seguito utilizzare per impersonare un certo utente su una determinata rete. Questo scenario può essere complicato a piacere, introducendo nell ambiente operativo ulteriori fattori di rischio dati da particolari necessità degli utenti, da errori nella fase di progettazione del sistema informativo, dalla disomogeneità degli apparati (sia hardware che software) e da quanto altro la fantasia di utenti maliziosi può generare. 1

8 La vulnerabilità di un sistema nel quale il sistema di autenticazione non é sicuro porta principalmente a tre grossi problemi che potrebbero presentare anche implicazioni dal punto di vista legale: integrità, riservatezza e autorizzazioni per concedere determinati servizi. L INTRANET DISI In uno scenario di questo tipo si colloca l attuale intranet del DISI (Dipartimento di Informatica e Scienze dell Informazione) dell Università di Genova. Si tratta infatti di una rete di calcolatori mista da un punto di vista relativo all hardware (personal computer IBM compatibili, Macintosh, San), come software (Unix, MacOs, Windows2000), sia come bacino di utenza (personale tecnico scientifico, studenti, visitatori). La situazione attuale di questa rete é la situazione tipo descritta al punto precedente: un server autentica l utente in fase di login attraverso l inserimento di un userid e di una password, gli assegna un gruppo di utenza basato su ACL attraverso il quale gli viene riconosciuto l accesso ad un certo servizio piuttosto che ad un altro. Inoltre la rete é connessa in modo permanente ad Internet e ciò la espone ad ulteriori rischi provenienti da eventuali hacker esterni che possono avere interesse a violare le risorse del dipartimento. Attualmente ci si trova in una fase di transizione nella quale si sta cercando di individuare sia i problemi che necessitano di una soluzione più rapida (cominciando a sostituire i servizi tradizionali quali telnet, rsh, rlogin con i servizi equivalenti basati su 2

9 C A x 1x 8x 2x 9x 3x A 10x 4x 11x 5x 12x 6x 7x 1x 8x 2x 9x 3x B 10x 4x 11x 5x 12x 6x C A x 1x 8x 2x 9x 3x A 10x 4x 11x 5x 12x 6x 7x 1x 8x 2x 9x 3x B 10x 4x 11x 5x 12x 6x C A C A C A x 1x 7x 1x 7x 1x 8x 2x 8x 2x 8x 2x 9x 3x 9x 3x 9x 3x A A A 10x 4x 10x 4x 10x 4x 11x 5x 11x 5x 11x 5x 12x 6x 12x 6x 12x 6x 7x 1x 7x 1x 7x 1x 8x 2x 8x 2x 8x 2x 9x 3x 9x 3x 9x 3x B B B 10x 4x 10x 4x 10x 4x 11x 5x 11x 5x 11x 5x 12x 6x 12x 6x 12x 6x tecniche crittografiche quali ssh, IPSec, ecc.), che quelli con soluzioni più laboriose (Firewall e autenticazione). WWW Server SUN Selene Router Modem Eth ern et x Hub 152 Eth ern et x Eth ern et Hub 10 Lab. Sw1 (No gateway) Server NT Eth e rn e t Hub Lab. Sw2 (No gateway) Hub Lab. Tesisti (Gateway) Modem Eth ern et Server SUN Elios Server NT Hub 61 (Docenti e altri gruppi) Figura 1 L intranet DISI Questa rete fornisce accesso ai domini disi.unige.it ed educ.disi.unige.it ad un numero elevato di utenti attraverso i due server di dominio Elios e Selene, rispettivamente per docenti/personale e per gli studenti. La sottorete educ, identificata dall IP x è collegata alla rete disi.unige.it attraversi il server SUN Elios. Questa sottorete è 3

10 composta principalmente da personal computer dual boot (s. o. Windows 2000 e Linux) distribuiti in tre laboratori: Sw1, Sw2, tesisti. L autenticazione nell ambiente Linux è gestita dal server SUN Selene, mentre per i sistemi Windows 2000 è gestita da un server Windows 2000 in Sw1. In particolare il server Selene (SUN) funziona anche come server per la posta e per le home directory degli studenti, come DNS e fornisce inoltre servizi di NIS e di pagine gialle. Il server del laboratorio Sw1 (Windows 2000) fornisce servizi di quote di stampa e servizi web per il sito Internet degli studenti (http, FTP). Il server Elios (SUN) fornisce servizi di posta per i docenti, servizi DNS e servizi PROXY per la rete educ, al fine di permettere l accesso controllato ad Internet. Le macchine appartenenti ai laboratori SW1 e Sw2 appartengono ad una virtual lan non visibile all esterno della rete, che non ha gateway e che può accedere all esterno solo attraverso il proxy Elios; quelle del laboratorio tesisti, invece, non hanno gateway e sono quindi visibili dall esterno e possono accedere liberamente alla rete Internet. 4

11 Capitolo 2 Sono stati fin qui discussi i problemi legati all autenticazione basata su password, in particolare sui rischi a cui questa metodologia espone. Tutto ciò risulta anche scomodo per quel utente finale che, trovandosi ad utilizzare una rete, si vede richiedere userid e password ad ogni accesso di un servizio. Da qui la necessità di sviluppare dei sistemi di autenticazione più robusti basati sulla crittografia. Un esempio comune di questi sistemi è dato dal protocollo Kerberos. KERBEROS Kerberos è un sistema distribuito di autenticazione che permette ad un processo (detto client) che agisce a nome di un utente di provare la propria identità ad un entità di verifica (server di autenticazione) senza trasmettere dati che, se intercettati, in futuro potrebbero permettere a qualcuno di impersonare un certo utente 1. È stato sviluppato presso il Massachusetts Institute of Technology di Boston come parte del progetto Athena 2. Scopo di Kerberos, a questo livello, era connettere fra di loro alcune LAN senza un sistema di controllo centralizzato, agendo da substrato per l accesso ai diversi servizi decentrati forniti dalle diverse reti del MIT., quali file system, centri stampa, servizi di posta, ecc. In questo caso l utente ha il controllo completo sulla macchina in casi estremi può anche 1 Kerberos: An authentication Service for Computer Networks (op. cit.) 2 Sviluppo di un ambiente di lavoro distribuito indipendente dalla workstation utilizzata nel quale l utente agisce in un suo ambiente personale che viaggia sulle macchine di una determinata rete. 5

12 sostituirla o modificarla per cui non può più essere considerata affidabile per l integrità della rete cui appartiene. Per essere efficace Kerberos deve essere integrato con altre parti del sistema; infatti non protegge tutte le comunicazioni della rete, ma solamente le comunicazioni che avvengono fra elementi del sistema (o applicazioni) kerberizzati cioè progettati o modificati in modo tale da sfruttare le potenzialità del protocollo. Kerberos da solo, infatti, non è in grado di fornire autorizzazioni, ma si occupa di trasferire le informazioni necessarie a questo servizio fra i processi coinvolti. In particolare, durante la progettazione di Kerberos sono stati considerati fattori di vitale importanza i punti seguenti:? Massima trasparenza del sistema: l utente deve identificarsi solo in fase di login;? Minimo sforzo per modificare applicazioni che facevano uso di altri sistemi di autenticazione;? Limitatezza dell autenticazione alla sessione corrente;? Entrambe le entità coinvolte nell autenticazione devono farsi riconoscere;? Nessuna password o chiave deve essere trasmessa in chiaro nella rete;? Nessuna password deve essere immagazzinata in chiaro nei server;? Nei client le password in chiaro devono essere immagazzinate per il minor tempo possibile e poi distrutte;? Al termine del processo di autenticazione le due entità devono aver concordato una chiave con la quale eventualmente stabilire una comunicazione riservata. 6

13 Lo schema scelto è basato sul protocollo Needham Schroeder, ed a un primo livello di dettaglio i due protocolli sono assimilabili. Assunzione di base di questo protocollo è l'esistenza di un server sicuro, chiamato centro di distribuzione chiavi (KDC), la cui funzione è quella di ridistribuire alle entità interessate le chiavi segrete con cui queste possano stabilire una comunicazione sicura. Per far ciò il KDC dovrà avere una chiave di comunicazione per ogni cliente. DESCRIZIONE DEL PROTOCOLLO Il modello di kerberos è dettagliatamente descritto dal documento RFC Immaginiamo una realtà nella quale esista un server di autenticazione sicuro (AS) ed un insieme di utenze e di servizi di rete che supportino Kerberos. Vediamo ad un livello di base il processo di autenticazione di un utente presso un servizio:? Il client richiede delle credenziali al AS;? L AS risponde inviando al client un ticket per il servizio richiesto ed una chiave di sessione cifrati con la chiave del client;? Il client può ora accreditarsi sul server mandandogli un messaggio contenente il suo ticket e la chiave di sessione codificati con la chiave del server. 7

14 Client Richiesta credenziali() Autentication Server Verifier Credenziali() operation1() Ok() Figura2: Protocollo di autenticazione Kerberos (Base) Poiché il ticket inviato al server viene trasmesso per lo più in chiaro e potrebbe quindi essere intercettato e riutilizzato, il messaggio è composto di informazioni addizionali che permettono di verificare inequivocabilmente che il messaggio è stato generato proprio dall entità a cui era stato rilasciato. Questa informazione, infatti è codificata con la chiave di sessione ed include una marca temporale che prova che il messaggio è stato generato da poco tempo e non è quindi una replica. Inoltre la codifica con la chiave di sessione prova che chi l ha generata possiede questa chiave, e questi non può essere altro che colui che l ha richiesta all AS in quanto gli è stata restituita cifrata in modo tale che soltanto lui potesse leggerla. Inoltre, la chiave di sessione, ora condivisa dai due, può essere usata per stabilire un canale di comunicazione sicuro fra le due parti che garantisca la privacy e l integrità dei messaggi scambiati. Da un punto di vista implementativo tutto questo è valido se su di una rete sono presenti uno o più AS in funzione su host fisicamente sicuri. L AS mantiene un database degli utenti e dei servizi della rete (principal) e una copia delle loro chiavi private. 8

15 Tipicamente un client di una rete può accedere a numerosi servizi che potrebbero richiedere una qualche autenticazione; in questo modo però ogni volta che il client deve essere accreditato presso un verifier l utente deve digitare la sua password. Questo non è consigliabile né perché limita la trasparenza del sistema, né perché espone la password dell utente a rischi di cattura di eventuali hacker. Una possibile soluzione sembrerebbe essere quella di memorizzare la password, ma ciò è poco sicuro. Kerberos risolve questo problema introducendo un nuovo elemento il Ticket Granting Server (TGS). Questo è un entità logicamente separata dall Authentication Server anche se fisicamente può risiedere sulla stessa macchina di quest ultimo; di solito ci si riferisce all insieme di queste due entità con la sigla KDC: Key Distribution Center. Client AS TGS Verifier Richiesta TGT() TGT() Richiesta ticket di sessione() Ticket di Sessione() Richiesta Verifier() Ok() Figura 3: Protocollo di autenticazione Kerberos (Completo) In questo modo il client si autentica al momento del login presso l AS, ricevendo come credenziali un Ticket Granting Ticket che utilizzerà presso il Ticket Granting Server per ottenere nuove 9

16 credenziali ogni qual volta gli sarà necessario per accedere ai servizi di un verifier accreditato su quella rete. Giunti a questo livello di dettaglio nella spiegazione del protocollo è necessario introdurre il concetto di realm di Kerberos. AUTENTICAZIONE CROSS-REALM Fino ad ora si è considerata solo la situazione in cui è presente solo un server di autenticazione ed un unico TGS. Questo non provoca problemi in situazioni in cui il numero di utenti è limitato, mentre per grossi sistemi questo sistema può diventare un collo di bottiglia per il processo di autenticazione: in altre parole questo sistema non è scalabile. È spesso vantaggioso dividere una rete in diversi realm kerberos, ognuno dei quali ha i propri AS e TGS. Queste divisioni coincidono spesso con i confini dipartimentali. Per permettere l autenticazione cross-realm - cioè per permettere ad utenti registrati in un realm di accedere a servizi in un altro è necessario che il realm dell utente abbia un TGS remoto (RTGS) registrato nell altro realm per il servizio richiesto. Vediamo come cambia il protocollo per questa estensione del protocollo:? Il client contatta l AS per accedere al TGS;? Il client contatta il TGS per accedere al RTGS;? Il client contatta l RTGS per accedere al servizio richiesto. Nella realtà la situazione si può complicare a piacere. In alcuni casi, dove ci sono molti realm, è inefficiente registrare ogni realm in ogni altro realm. 10

17 Nella versione 4 del protocollo Kerberos era necessario che un AS si registrasse presso ogni altro realm col quale era richiesta l autenticazione cross-realm per uno o più utenti. Questo non rientra nei canoni della scalabilità in quanto l interconnessione completa fra i reami richiederebbe lo scambio di n 2 chiavi dove n è il numero dei realm. La versione 5 ha introdotto il supporto per l autenticazione multihop-cross-realm, permettendo la condivisione delle chiavi in maniera gerarchica. Ogni realm condivide una chiave con i realm genitori e figli; ad esempio il realm ISI.EDU condivide una chiave con il dominio EDU che a sua volta condivide chiavi con MIT.EDU, USC.EDU. Se ISI.EDU e USC.EDU non condividono una chiave l autenticazione di client@isi.edu su un server registrato presso MIT.EDU procede in questo modo:? Si ottiene un TGT per il realm EDU dall AS del realm ISI.EDU;? Si usa questo TGT per ottenerne uno dal realm MIT.EDU dall AS di EDU;? Infine si ottiene un ticket per il verifier dall AS del realm MIT.EDU. 11

18 La lista dei realm attraversati nel corso dell autenticazione multi-hop è registrata nel ticket ed è il verifier che si occupa del verificare che il percorso di autenticazione sia corretto. Sono inoltre supportate anche cammini di autenticazione alternativi (scorciatoie) a quello gerarchico in modo tale da migliorare notevolmente le performance del processo di autenticazione. CONDIZIONI DI FUNZIONAMENTO Per un corretto funzionamento di Kerberos bisogna fare alcune assunzioni sull ambiente in cui opera:? Kerberos non previene gli attacchi DoS, ma la loro prevenzione (e l eventuale cura) è lasciata agli amministratori e agli utenti del sistema.? I principal devono tenere segrete le loro chiavi; se un intruso riesce a venire in possesso di una chiave sarà in grado in qualunque momento di impersonare l identità di un dato principal.? Kerberos non previene gli attacchi brutali sulle password. Un utente che utilizza password facili mette a rischio la sicurezza delle sue stesse chiavi in quanto queste sono derivate dalla sua password, che una volta scoperta è una porta aperta alla violazione del sistema.? Ogni host di un realm deve essere sincronizzato con gli altri, in quanto la sincronizzazione è utilizzata per scoprire eventuali attacchi da furto di ticket.? Gli identificatori dei principal non vengono riutilizzati in tempi brevi; infatti utilizzando le ACL per controllare i permessi di accesso dei singoli principal, nel caso in cui 12

19 un utente venisse eliminato senza che l ACL corrispondente venga cancellata, questa, nel caso in cui un vecchio identificatore cancellato venisse riciclato, verrebbe automaticamente ereditata dal nuovo principal. Non permettendo il riciclo questo pericolo è scongiurato. FORMATO DEI TICKET Ogni ticket di Kerberos contiene un insieme di flag che sono usati per indicarne I vari attributi. La maggior parte dei flag sono richiesti dal client quando questi lo ottiene dal server, mentre altri sono settati automaticamente dal server. Vediamo nel seguito quale sia il valore di questi flag attraverso alcuni esempi. Il flag initial indica che il ticket é stato emesso utilizzando il protocollo AS e non basandosi su di un TGT. Questo pó essere utile nel caso in cui un server voglia ottenere la chiave di un client (p.e. in caso di modifica della password). Il flag pre-authent e hw-authent portano informazioni addizionali circa l autenticazione iniziale, senza considerare se il ticket sia stato emesso su base di un TGT o meno (di ciò se ne occupa il flag initial). Il flag invalid indica che un ticket non é valido. L application server che lo riceve deve rifiutare un ticket con questo flag attivo. Di solito un ticket postdatato reca questo flag a 1. I ticket invalidi prima di essere usati devono essere validati dal KDC, cui verranno presentati in una richiesta di TGS con l opzione validate specificata. Il KDC validerà il ticket solo dopo che il suo starttime sarà passato; in questo 13

20 modo i ticket rubati non verranno più attivati (grazie all uso scongiunto di hot-list). Alcune applicazioni possono avere la necessità di dover mantenere validi dei ticket per un tempo piuttosto lungo, anche se ciò può essere pericoloso in quanto espone le credenziali di un principal a rischi maggiori e, nel caso di un loro furto, queste resteranno valide più a lungo. I ticket rinnovabili hanno due expiration time : il primo é il momento in cui il ticket perde valore, il secondo é il tempo massimo entro il quale il ticket può essere rinnovato. Un client deve periodicamente presentare un ticket rinnovabile al KDC con l opzione renew attiva nella richiesta al KDC. Il KDC emetterà un nuovo ticket con una nuova chiave di sessione e una expiration time successiva. Tutti gli altri capi del ticket resteranno immutati. Nel momento in cui i raggiunge il latest expiration time il ticket perderà completamente validità. Ad ogni operazione di rinnovo il KDC dovrà consultare la hot-list per determinare se il ticket é stato rubato o meno e quindi se sia o meno rinnovabile. Il flag renewable in un ticket é normalmente interpretato solo dal TGS e di solito viene ignorato dagli application server; alcune applicazioni particolari possono comunque disabilitare quest opzione. Occasionalmente un applicazione può richiedere un ticket che userà in futuro (p.e. un sistema batch può richiedere un ticket che dovrà essere valido al momento in cui il processo sarà attivo). Ciò é comunque pericoloso in quanto questi saranno disponibili più a lungo e validi in futuro e, quindi, più appetibili per possibili furti. Per limitare i danni possibili i ticket posdatati necessitano di un autenticazione ulteriore da parte del KDC al momento dell esecuzione del processo che li aveva richiesti (fino a questo momento sono in stato dormant ). Nel caso in cui venga segnalato il furto di un ticket il KDC si rifiuterà di validarlo, rendendo cosi vano il 14

21 furto. Il flag may-postdate è solitamente interpretato soltanto dal TGS mentre viene ignorato dagli altri servizi. Questo flag deve essere impostato nel caso in cui il ticket in questione possa servire per emettere ticket posdatati; non serve tuttavia ad un client per ottenere un TGT posdatato. Il KDC può limitare la durata nel futuro di un ticket posdatato. Il flag postdated indica che un ticket è stato posdatato; in questo caso l application server può verificare la data dell autenticazione originale nel campo authtime del ticket stesso. Alcuni servizi possono essere configurati per rifiutare i ticket posdatati o, a discrezione dell amministratore di sistema, per accettare solo quelli posdatati entro un determinato periodo. Quando il KDC emette un ticket posdatato deve anche impostare il campo invalid in modo da obbligare il client a validarlo presso il KDC prima dell uso. A volte può essere necessario che un principal permetta ad un servizio di compiere delle operazioni a suo nome. Per fare ciò il servizio deve essere in grado di prendere l identità del client ma solo per un ben determinato scopo. Un principal può permettere ciò grazie al flag proxiable del ticket Kerberos. Questo flag solitamente ignorato dai server applicativi permette al TGS di emettere un ticket (ma non un TGT) basato su questo stesso, ma con un diverso indirizzo di rete. Questo può essere utile nel caso di un server di stampa che debba accedere un certo file server per stampare dei dati a nome di un determinato principal. L inoltro dell autenticazione è un istanza del caso precedente nel quale al servizio è garantito il completo uso dell identità del principal. Questo genere di autenticazione può essere utile nel quale un utente autenticato su un certo realm abbia necessità di lavorare su un altro realm remoto come se lavorasse in locale (login remoto). Il flag forwardable in un ticket è di solito considerato solo dal TGS e si comporta come il flag proxiable con l unica differenza che può essere 15

22 utilizzato anche per generare dei TGT. L uso di questo flag permette all utente di ottenere credenziali da un AS remoto senza dover ogni volta reinserire la password. DATABASE KERBEROS Il server Kerberos deve avere accesso ad un database contenente gli identificatori dei principal registrati e le loro chiavi segrete; visto il contenuto di tale database è ragionevole pensare che l host su cui risiede il server Kerberos sia fisicamente separato da quello su cui risiede il database, che dovrebbe trovarsi in condizioni di inviolabilità assoluta per evitare accessi e/o modifiche non permessi pena la completa inaffidabilità del sistema. Una entry del database deve contenere almeno i campi seguenti: Campo Valore Name Identificatore del principal key Chiave private del principal p_kvno Versione della chiave del principal max_life Lifetime massimo del ticket max_renewable_life Lifetime massimo totale per i ticket rinnovabili Il campo name è una codifica dell identificatore del principal. Il campo chiave contiene la chiave segreta del principal che può venire cifrata prima con una master key del server per essere protetta in caso di attacco del server. In questo caso deve essere inserito un campo supplementare che specifica quale chiave si è usata. Il campo p_kvno contiene il numero della versione della chiave segreta del principal, mentre i campi max_life e max_renewable_life contengono i parametri di lifetime per i ticket rinnovabili. 16

23 Se il database è progettato per distinguere record di principal che differiscono solo per il nome del realm di appartenenza, un server può fornire il servizio di KDC a diversi realm. Quando la chiave di un application server cambia, se il cambiamento e routine (non è conseguenza di scadenze o attacchi) la vecchia chiave deve essere mantenuta nel server fino a che tutti i ticket emessi con quella chiave non sono più validi. Per questo è possibile che un server abbia a disposizione più chiavi per un singolo principal. Quando per un particolare principal più di una chiave è attiva, nel database saranno presenti tanti record per quel determinato principal quante sono le chiavi disponibili; le chiavi e le loro versioni saranno diverse per ogni record (gli altri campi possono essere o meno uguali). Ogni qualvolta che un server Kerberos emette un ticket o risponde ad una richiesta di autenticazione userà la chiave più recente conosciuta dal server stesso per la cifratura; questa sarà la chiave col più alto numero di versione. 17

24 Capitolo 3 IMPLEMENTAZIONE NELL AMBIENTE WINDOWS 2000 Nel sistema operativo Windows 2000 la versione 5 del protocollo kerberos è disegnata per operare con altri servizi di sicurezza basati sul reference implementation della versione 5 di Kerberos sviluppata al MIT. Un server di dominio Windows 2000 può essere utilizzato come centro di distribuzione delle chiavi (KDC) per sistemi MIT Kerberos-based. Per autenticarsi presso un server Windows 2000 i sistemi UNIX possono usare l utilità kinit a l algoritmo crittografico DES-CBC-MD5 o DES-CBC-CRC. Il supporto alla sicurezza integrato in Windows 2000 implementa l interfaccia di Kerberos ed il formato dei token definiti nell RFC Windows 2000 non fornisce l interfaccia GSS API mentre è disponibile il supporto per applicazioni che usino l API basata su SSPI implementata dall SSP di Kerberos. Le applicazioni client di UNIX che utilizzano le API GSS possono ottenere comunque dei ticket di sessione dai server Windows 2000 e possono quindi supportare l autenticazione, l integrità e la confidenzialità forniti da Kerberos. I client Windows 2000 Professional possono essere configurati per integrarsi all interno di un realm Kerberos, con single sign-on fra il realm e l account locale basato su Windows Professional. L interoperabilità con servizi Kerberos richiede meno modifiche alla configurazione di default. Ad esempio una workstation che utilizza un realm Kerberos deve essere configurata in modo da localizzare il realm Kerberos, il KDC e i server di scambio delle password. A 18

25 questo proposito Microsoft fornisce dei tool per i vari passi di configurazione: Ksetup: configura i realm, i KDC, e i server delle password Ktpass: imposta le password, l accounting e genera le tabelle di chiavi che utilizzerà il KDC di Kerberos. FUNZIONALITÀ DEL PROTOCOLLO Autenticazione di connessione più veloce Con l utilizzo del protocollo Kerberos, i server non devono passare attraverso l autenticazione. Un server che esegue Windows 2000 può verificare le credenziali del client 3 tramite il ticket fornito dal client senza dover interrogare il servizio Kerberos. Questo perché il client avrà già ottenuto un ticket Kerberos dal controller di dominio, che il server può utilizzare per creare il token di accesso del client. Per non eseguire troppe operazioni il server può più facilmente conciliare un grande numero di richieste di connessione simultanee. Autenticazione reciproca Il protocollo Kerberos fornisce autenticazione reciproca si del client sia del server. Il protocollo di autenticazione Windows NTLM fornisce solo autenticazione del client e presume che tutti i server siano attendibili. Il protocollo non verifica l identità del server a cui il client si connette. La supposizione che tutti i server siano attendibili non è più valida. L autenticazione reciproca del client e del server è un punto fermo importante per reti protette. 3 Il client Active Directory per Windows 9x consente agli utenti l accesso mediante il protocollo di autenticazione Kerberos V5. 19

26 Delega di autenticazione La delega di autenticazione consente a un utente di connettersi a un server di applicazioni che a turno può connettersi a uno o più server ulteriori per conto del client utilizzando le credenziali del client. Trust transitivi Le credenziali di autenticazione emesse da un sevizio Kerberos vengono accettate da tutti i servizi Kerberos all interno del dominio. Processo di autenticazione Kerberos Il processo di autenticazione Kerberos fa in modo che il computer client negozi scambi tra il server di destinazione e il KDC. La figura 4 fornisce cenni generali sul processo di autenticazione. I passaggi numerati nel diagramma vengono descritti di seguito. 20

27 1 Richiesta (AS (nome, destinazione...) 2 risposta AS (TGT, chiave sessione...) 3 Richiesta TGS (TGT, nome destinazione...) 4 Risposta TGS(Ticket server, chiave sessione...) KDC (AS & TGS) Server Kerberos Client 5 Richiesta (ticket server, autenticatore...) 6 Risposta Server di destinazione Figura 4: Processo di autenticazione Kerberos Il processo di autenticazione Kerberos viene eseguito come segue: 1. Il client invia una richiesta AS 4 iniziale alla parte AS del servizio Kerberos. AS comprende il nome principale del client e il nome principale del server di destinazione per il quale si sta richiedendo un ticket. 2. Il servizio Kerberos genera una risposta AS e la invia al client. La risposta contiene: Un TGT per la parte TGS del servizio Kerberos. Il TGT viene crittografato con la chiave segreta TGS. Il TGT 4 Nota Gli scambi AS e TGS con il servizio Kerberos vengono eseguiti mediante il protocollo UDP (User Datagram Protocol) porta 88. Gli scambi tra il client e il server di destinazione dipendono dal protocollo utilizzato tra i due principali. 21

28 contiene la SID del l utente. Con la crittografia del TGT mediante la chiave segreta TGS, il client non è in grado di cambiare le proprietà della SID. Una chiave di sessione per scambi con la parte TGS del servizio Kerberos. La chiave di sessione viene crittografata con la chiave segreta dell utente. La chiave segreta del client è un calcolo della password del client. E simile alla chiave di sessione utilizzata nel NTLM richiesta/risposta. La crittografia rende difficile per chiunque rubare la chiave di sessione. 3. Il client genera e invia una richiesta TGS che contiene i nomi principali del client e del server di destinazione, gli ambienti e il TGT che identifica il client. 4. La parte TGS del servizio Kerberos genera e invia una risposta TGS al client. Questa risposta contiene un ticket per il server di destinazione. Il ticket viene crittografato con la chiave segreta del server. La chiave segreta del server è un calcolo della password generata quando il server si è unito al dominio. La risposta comprende altre informazioni inclusa la chiave di sessione. 5. Il client estrae la chiave di sessione per il server di destinazione e genera una richiesta per il server. Questa richiesta contiene il server di destinazione e un autenticatore crittografato con la chiave di sessione. Il client invia questa richiesta al server di destinazione utilizzando un percorso di trasporto stabilito. 6. Il server di destinazione decritta il ticket tramite la propria chiave segreta per ottenere la chiave di sessione. In seguito il server utilizza la chiave di sessio ne per decrittare l autenticatore per la verifica del client. Se il client ha richiesto un autenticazione reciproca il server di destinazione genera una risposta crittografata con la chiave di sessione e la invia al 22

29 client. L autenticazione reciproca non solo autentica il client al server di destinazione ma autentica anche il server di destinazione al client. Delega Kerberos Talvolta è necessario che un server di applicazioni si connetta a un altro server per conto di un client. Allo stesso modo della rappresentazione, la delega viene utilizzata per assicurare che le autorizzazioni di protezione esatte siano applicate con la richiesta del server di applicazione. Il protocollo di autenticazione Kerberos supporta l autenticazione delegata. Questo tipo di autenticazione viene utilizzata quando una transazione del client coinvolge diversi server. In tal caso, ciascun server di verifica ottiene un altro ticket e autentica il ticket al server richiesto per conto del client. Non esiste limitazione su numerosi server consecutivi che possono delegare l autenticazione. La differenza con la rappresentazione sta nel fatto che il server accede per conto del client alle risorse remote invece che alle risorse locali. La figura 5 fornisce cenni generali sul processo di delega Kerberos. I passaggi numerati nel diagramma vengono descritti di seguito. 23

30 Client 1 Kerberos Ticket per Server A Ticket per Server B KDC Ticket per Server A 2 3 Richiesta ticket per server B come client Ticket per Server B 4 Server B Server A Figura 5: Processo di delega Kerberos I passaggi seguenti descrivono l accesso di risorse che coinvolge due server: 1. Il client richiede e riceve un ticket per il server di destinazione A dal servizio Kerberos. 2. Il client invia il ticket direttamente al server A. 3. Il server A invia una richiesta, rappresentando il client, al servizio Kerberos per un ticket per il server di destinazione B. 11 servizio Kerberos risponde con un ticket che consente al client l accesso al server B. 4. Il server A può in seguito inviare il ticket al server B, accedendo al server B come il client. 24

31 Processi. di accesso Kerberos L aggiunta di Kerberos come pacchetto di autenticazione in Windows 2000 influenza vari aspetti del processo di accesso. Tuttavia, le parti del processo di accesso che vengono eseguite prima che un pacchetto di autenticazione venga coinvolto restano immutate in Windows Accesso interattivo locale Quando si verifica un accesso interattivo locale, l utente accede con un account esistente sul computer locale piuttosto che con un account utente di dominio. La figura 6 fornisce cenni generali sul processo di accesso interattivo locale in Windows I passaggi numerati nel diagramma vengono descritti di seguito. GINA Autorità di protezione locale Interfaccia provider supporto protezione Pacchetto di aut. Kerberos Corrispondenza rilevata con il nome computer errore Pacchetto di aut. MSV1_0 Figura 6: Processo di accesso di dominio Per gli account utente locali si verificano i seguenti passaggi in Windows 2000: 25

32 1. quando il DLL GINA (Graphical Identification and Authentication) riceve la richiesta di accesso, inoltra la richiesta all autorità LSA (Local Service Authority). Questa richiesta specifica l utilizzo di Kerberos come pacchetto di autenticazione perché è il pacchetto predefinito in Windows LSA elabora la richiesta e la invia al pacchetto di autenticazione Kerberos. 3. Quando Kerberos riceve la richiesta di accesso, restituisce un errore poiché viene utilizzato solo per autenticazione di richieste di accesso per account utente di dominio e non per account utente locali. 4. LSA riceve l errore e restituisce un errore a GINA. 5. Il GINA inoltra nuovamente la richiesta di accesso alla LSA specificando il pacchetto di autenticazione MSV1_0. Si verifica quindi il processo di accesso come il processo di accesso interattivo locale in Windows NT 4.0. Accesso interattivo di dominio Lo scambio che avviene quando un utente accede a Windows 2000 con un account utente di dominio è simile allo scambio Kerberos base. La figura 6 fornisce cenni generali di questo processo di accesso. I passaggi numerati nel diagramma vengono descritti di seguito. 26

33 Client Contiene SID per l'account utente e tutti i gruppi globali nei dati di autorizzazione 1 Richiesta AS (utente, dominio, server=krbtgt) 2 Risposta AS (TGT, Chiave sessione) 3 Richiesta TGS (utente, TGT, server=workstation) 4 Risposta TGS (ticket workstation, Chiave sessione) KDC Figura 7: processo di accesso interattivo di dominio Il processo di accesso interattivo di dominio avviene come segue: 1. Quando la richiesta di accesso raggiunge la LSA, questa trasferisce la richiesta al pacchetto di autenticazione Kerberos. Il client invia una richiesta AS iniziale al servizio Kerberos fornendo il nome utente e il nome di domi nio. E una richiesta per autenticazione e per un TGT. La richiesta viene effettuata utilizzando il nome principale krbtgt@<domain_name>, dove <domain_name> è il nome del dominio in cui l account utente è posizionato. Il primo controller di dominio nel dominio genera automaticamente l account krbtgt@ <domain_name>. 2. Il servizio Kerberos genera una risposta AS che contiene un TGT, crittografato con la chiave segreta Kerberos, e una chiave di sessione per gli scambi TGS, crittografata con la chiave segreta del client. Questa risposta viene reinviata al client. La porzione di dati di autorizzazione del TGT contiene il SID per l account utente e i SID per tutti i gruppi globali a cui l utente appartiene. I SID vengono restituiti alla LSA per includerli nel token di accesso dell utente. I SID vengono copiati, dal servizio Kerberos, dal TGT in ticket successivi ottenuti dal sevizio Kerberos. 3. Il client in seguito genera e invia una richiesta TGS che contiene il nome principale e l ambiente del client, il TGT per 27

34 l identificazione del client, e il nome della wokstation locale come il server di destinazione. L operazione viene effettuata per richiedere accesso al computer locale per l utente. 4. Il servizio Kerberos genera e invia una risposta TGS. La risposta contiene un ticket per la workstation e altre informazioni comprese la chiave di sessione, crittografata mediante la chiave di sessione dal TGT. Nella porzione di dati di autenticazione della risposta TGS si trovano i SID per l account utente e tutti i gruppi globali copiati dal servizio Kerberos dal TGT originale. 5. Il pacchetto di autenticazione Kerberos restituisce l elenco dei SID alla LSA. I servizi Windows 2000 utilizzano l interfaccia SSPI (Security Support Provider Interface) in modalità kernel per eseguire l autenticazione. Invece di comunicare direttamente con il pacchetto di autenticazione Kerberos entrambi i servizi accedono a Kerberos mediante un pacchetto di autenticazione creato nella LSA. Questo pacchetto di autenticazione viene denominato pacchetto Negoziate. Nell avvio sia i servizi server che workstation inizializzano le interfacce con il pacchetto Negotiate in LSA mediante SSPI. In questo processo il servizio server ottiene l handle delle credenziali per le proprie credenziali predefinite. La comunicazione di rete si verifica in due segmenti: negoziazione del protocollo e installazione della sessione. Prima che un utente possa stabilire una sessione con il server il computer client e il server devono concordare il protocollo di protezione da utilizzare stabilendo quale versione di protezione viene supportata. Un volta che il client è stato autenticato e possiede un ticket può stabilire una sessione con il server. 28

35 Supporto di chiave pubblica Kerberos Windows 2000 estende te funzionalità di Kerberos per consentire l interazione con il servizio di Active Directory. Windows 2000 comprende estensione al protocollo di autenticazione Kerberos V5 per supportare autenticazione basata su chiave pubblica. Le estensioni di chiave pubblica consentono ai client di richiedere un TGT iniziale utilizzando una chiave privata. Il servizio Kerberos verifica una richiesta utilizzando la chiave pubblica dell utente ottenuta dal certificato X.509 dell utente pubblicato nell archivio Active Directory. Per Ottenere un ticket i certificati X.509 degli utenti devono venire memorizzati nel proprio oggetto utente. Se il servizio Kerberos trova il certificato emette un ticket per il client e in seguito viene seguita la procedura standard Kerberos. Questo sostituisce la chiave segreta nota solo al principale e al KDC. Le smart card, ad esempio, utilizzano estensioni di chiave pubblica fornite da Kerberos. ACCESSO ALL INTERFACCIA Anche Kerberos come il NTLM - è implementato come package nella libreria Secur32.dll fornita con i sistemi Windows Nei domini Windows 2000 è supportata sia l autenticazione attraverso Kerberos che quella attraverso NTLM. Il protocollo Kerberos quando disponibile è comunque quello a priorità maggiore. I servizi di sistema e le applicazioni a livello di trasporto accedono al supporto per la sicurezza (SSP) attraverso l interfaccia SSPI che fornisce funzionalità per elencare i package per la sicurezza disponibili in un determinato sistema, selezionarne uno ed utilizzarlo per ottenere una connessione sicura. 29

36 I metodi nell SSPI sono generici, routine viste come scatole nere che gli sviluppatori possono utilizzare senza conoscere nel dettaglio la loro implementazione o il funzionamento del protocollo. Ad esempio, quando una connessione client/server viene autenticata, l applicazione lato client invia le credenziali al server usando la funzione dell SSPI InitializeSecurityContext. A questa l applicazione lato server risponde con la funzione AcceptSecurityContext. Quando la connessione è stata autenticata, l LSA server-side usa le informazioni del client per generare un token d accesso. Quindi il server può invocare la funzione ImpersonateSecurityContext per creare un thread per un certo servizio affidandogli quel determinato token di accesso. In particolare: la funzione InitializeSecurityContext inizializza il security context con delle credenziali iniziali. Questa funzione ritorna un token che poi il client passerà al processo con cui deve creare la connessione; la funzione AcceptSecurityContext abilita le componenti del server ad aprire un security context fra il server ed un client remoto (che utlizza InitializeSecuritiCOntext) Il server può richiedere al client uno o più token in risposta per completare il security context. 30

37 L interfaccia SSPI fornisce un interfaccia fra applicazioni che operano a livello di trasporto come RPC, e security support provider (SSPs) come Windows Distributed Security. SSPI permette all applicazione di trasporto di utilizzare uno fra i tanti package per la sicurezza per ottenere una connessione autenticata e scambiare dati su questa connessione. L interfaccia SSPI è disponibile sia in modalità kernel che in modalità utente. APPLICAZIONI CHE SUPPORTANO KERBEROS Tutti i servizi distribuiti presenti in Windows 2000 utilizzano l interfaccia SSPI per accedere al protocollo Kerberos. Una lista parziale dei modi in cui il protocollo viene utilizzato per l autenticazione include: Servizio spooler di stampa; CIFS/SMB remote file access; LDAP query ad Active Directory; File system distribuito; IPSec host-to-host security authority authentication; Richieste di prenotazione per il servizio di rete Quality of Service; Autenticazione su Internet Information Service in ambiente intranet; Gestione remota di server o workstation usando RPC; Richiesta di certificati per utenti e computer su un dominio locale, Servizi Active Directory. 31

38 Capitolo 4 IMPLEMENTAZIONE NELL AMBIENTE UNIX Nell ambiente Unix preso in esame, la distribuzione RedHat 7.0, il modello di Kerberos è basato sulle specifiche del protocollo di Needham e Schroeder e sulle modifiche a questo proposte da Denning e Sacco. La progettazione e l implementazione delle versioni 1 4 sono dovute a Steve Miller della Digital Equipment Corporation e Clifford Neuman (ora all Information Sciences Institute of the University of Southern California), insieme come Jerome Saltzer direttore tecnico del progetto Athena, e Jeffrey Schiller Network manager del MIT. La versione 4 è disponibile in forma gratuita ed ha visto ampia diffusione attraverso Internet. La versione 5 qui descritta è l evoluzione della versione 4 basata su nuovi requisiti e nuove funzionalità assenti nella versione precedente. APPLICAZIONI CHE SUPPORTANO KERBEROS Le nuove distribuzioni di Linux in particolare la versione presa in esame comprendono al loro interno versioni dei comandi di rete pronte per funzionare con Kerberos. Diversamente dal sistema W2k dove questi comandi verificano la presenza di un server Kerberos e nel caso in cui questo sia presente funzionano supportandone pienamente le funzionalità mentre, nel caso in cui il server non sia presente funzionano nella versione vecchia non kerberizzata, il tutto in maniera completamente trasparente per l utente, esistono delle versioni diverse dei comandi. 32

39 In particolare a telnet corrisponde ktelnet, a telnetd il demone ktelnetd, a ftp gssftp, a rlogin login ed eklogin, a rsh infine kshell. Sono inoltre presenti tutti i comandi e le utilità per gestire e mantenere il server KDC quali: krb5: tool grafico per gestire i ticket; gkadmin: tool grafico per gestire i realm Kerberos; kdb5_util: creazione e gestione del database delle chiavi; kinit: per ottenere un tichet e salvarlo in un file cache; klist: per ottenere la lista delle credenziali nella cache; kdestroy: per distruggere la cache e le credenziali contenute; addprinc: permette di aggiungere un principal al database; ACCESSO ALL INTERFACCIA Le funzionalità di Kerberos in ambiente Linux sono fornite nella libreria libkrb5.a; per ragioni di semplicità di programmazione, mantenimento e portabilità questa libreria è costituita di più moduli. Funzione main La funzione main supporta i dettagli più semplici: verifica dei ticket e creazione degli autenticatori; vediamoli un po più in dettaglio. Modulo krb5_context Il modulo krb5_context è stato progettato per rappresentare lo stato per-processo. Quando la libreria sarà resa thread-safe rappresenterà 33

40 lo stato per-thread. In questa struttura sono conservati i parametri globali che sono specifici del contesto, icluso il realm di default, i tipi di crittografia di base e i file di configurazione. Prevede inoltre delle funzioni che forniscono l accesso completo alle strutture dati del contesto e che non devono essere utilizzate in maniera diretta dai programmatori in quanto le loro specifiche possono cambiare da una versione alla successiva. Modulo krb5_auth_context Mentre il modulo krb5_context rappresenta il contesto per-processo (thread), il modulo krb5_auth_context rappresenta i contesti perconnessione utilizzati dalle varie funzioni coinvolte direttamente nell autenticazione client/server. Alcuni dei dati memorizzati nel contesto includono blocchi di chiavi, indirizzi, sequenze di numeri, autenticatori, tipi checksum, e puntatori alla reply cache. Accesso ai principal Un principal definisce in maniera univoca l istanza di un client o di un server che prende parte ad una comunicazione di rete. Le funzioni del modulo krb5_principal, permettono di creare modificare ed accedere a porzioni di questi dati. Funzioni Replay Cache Le funzioni replay cache verificano che le richieste non contengano autenticatori duplicati; devono essere conservate nel sistema in maniera non volatile per tutto il tempo di validità dell autenticatore per il sito in questione. Ogni reply cache ha una stringa nome ad essa associata. L uso di questo nome dipenda dalla strategia di caching scelta; deve comunque essere salvata da qualche parte in maniera persistente per garantire l integrità del sistema in caso di system failure. 34