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 [Digitare qui l'estratto]

3 SOMMARIO INTRODUZIONE... L intranet DISI: Struttura... Servizi... Problemi legati alla sicurezza... KERBEROS... Descrizione del protocollo... Autenticazione cross-realm... Condizioni di funzionamento... Formato dei ticket... Database Kerberos... IMPLEMENTAZIONE NELL AMBIENTE WINDOWS Applicazioni che supportano Kerberos... Funzionalità del protocollo... Accesso all interfaccia... IMPLEMENTAZIONE NELL AMBIENTE UNIX Applicazioni che supportano Kerberos... Accesso all interfaccia... INTEGRAZIONE ED INTEROPERABILITÀ... Scenari di interoperabilità... TEST... Come configurare Kerberos in ambiente Windows Come configurare Kerberos in ambiente Linux... Interoperabilità nell intranet DISI... GLOSSARIO... BIBLIOGRAFIA...

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 ii

5 RINGRAZIAMENTI Si desidera ringraziare per la preziosa collaborazione Davide Petta, Gianni Verduci, 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; 6

13 ? Al termine del processo di autenticazione le due entità devono aver concordato una chiave con la quale eventualmente stabilire una comunicazione riservata. 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. 10

17 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. 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 14

21 furto di un ticket il KDC si rifiuterà di validarlo, rendendo cosi vano il 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 15

22 comporta come il flag proxiable con l unica differenza che può essere 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