Kerberos v5 Presentazione dello studente Flavio Caroli per il corso di Griglie Computazionali prof. Tiziana Ferrari - a.a. 2005/06 -

2 Il protocollo Kerberos Obiettivi Componenti Servizi e ruoli Strategie del protocollo Crittografia Integrazione

3 Il protocollo Kerberos Nasce nei primi anni 80 dalla collaborazione di IBM, Digital e M.I.T. Il nome deriva dalla mitologia greca Autorizzazione: determinare se un client è autorizzato ad usufruire di un servizio Autenticazione: determinare se lidentità dichiarata dal client è vera Cifratura - accounting: garantire la segretezza della comunicazione e prevenire che parti estranee la modificano o la intercettano

4 Il protocollo Kerberos È un protocollo distribuito che fornisce la sicurezza di autenticazione su reti aperte e insicure dove la comunicazione tra gli host può essere intercettata Utilizza uno schema Third Party Trust (^) e si basa sulluso di chiavi segrete per cifrare le informazioni scambiate tra le entità Gli utenti, i client e i server si autenticano a vicenda tramite il KDC, Key Distribution Center (^) Nota: Third party trust refers to a situation where two parties can trust each other, even if they don't know each other, based on a relationship with a mutual, trusted third party. In third party trust, one authority acts to ensure the trustworthiness of the other parties.

5 Obiettivi La password dell'utente non viene inviata sulla rete, non viene memorizzata sull host (non dovrebbe essere memorizzata in chiaro neanche nel database del KDC) e viene cancellata dopo lutilizzo Single Sign-On: l'utente inserisce la password allinizio della sessione di lavoro. Può accedere, senza reinserirla durante tale sessione, a tutti i servizi per il quale è autorizzato Mutua autenticazione: anche i server applicativi provano la loro autenticità ai client

6 Obiettivi L'intero processo di autenticazione risulta invisibile all'utente e realizza uno scambio di Ticket cifrati senza che sulla rete circolino informazioni segrete Si limita così linvio delle informazioni di autenticazione attraverso la rete ed agisce su host e su server applicativi (imap, pop, smtp, telnet, ftp, ssh, AFS ) considerati vulnerabili La gestione delle informazioni di autenticazione è centralizzata e protetta sul sistema KDC

7 Obiettivi Le informazioni di autenticazione dei client non vengono memorizzate sui server applicativi Viene limitata la ridondanza di informazioni di autenticazione e ridotte le locazioni attaccabili L'account di un utente può essere disabilitato agendo direttamente sul KDC Dopo autenticazione e autorizzazione, la connessione tra client e server viene impostata come sicura e i dati vengono trasmessi e criptati con luso delle chiavi

8 Il protocollo Kerberos Rappresenta unalternativa al modello di autenticazione a due parti Elimina la trasmissione delle informazioni di autenticazione sulla rete riducendo le locazioni attaccabili da utenti estranei Non si ha la necessità di dimostrare il possesso di informazioni segrete Il sistema di autenticazione è supportato solo dal KDC e senza lausilio di certificati digitali contenenti le chiavi pubbliche degli utenti firmate con la chiave privata di unautorità di certificazione

9 Il protocollo Kerberos È differente rispetto allo schema X.509, utilizzato in molte applicazioni(SSL/TLS...), il cui fulcro è costituito dai certificati a chiave pubblica associati ad ogni client Autenticazione a due parti Autenticazione a terza parte di fiducia

10 SSL vs Kerberos Confronto tra il sistema a chiavi pubbliche basato sui certificati contro quello con autenticazione a chiavi private basato su Third Party Trust SSL può essere usato per stabilire una connessione sicura anche tra due parti e non richiede una terza parte fidata In Kerberos non c'è la necessità di ricerca di certificati per l'autenticazione, tranne per la password che però non è su HD Kerberos è flessibile, per aggiornarlo occorre modificare il KDC, è un pacchetto libero e può essere installato senza costi di licenza, al contrario di SSL Il sistema Kerberos può risultare compromesso se l'autenticazione di un utente è per un servizio che non utilizza Kerberos, come Telnet e FTP, si rimedia utilizzando i protocolli cifrati, come i servizi sicuri SSH o SSL

11 Il protocollo Kerberos Autenthication Server AS Ticket Granting Server TGS DB Key Distribution Center (KDC) Application Server Client …

12 Il protocollo Kerberos REALM 2 Server … Client REALM 1 REALM 3 Server … Client Server … Client

13 Componenti: Realm È il dominio amministrativo di autenticazione, entro cui il/i server di autenticazione è responsabile dell'autenticare un utente o un servizio Rappresenra l'insieme di utenti e di server appartenenti e coordinati da uno specifico Authentication Server Un utente/servizio appartiene ad un Realm se e solo se condivide un password/chiave con il server di autenticazione AS

14 Componenti: Realm example.com EXAMPLE.COM Dominio DNS Realm Kerberos Il nome del Realm coincide con il dominio DNS semplifica la configurazione e lintegrazione del sistema Kerberos Cross-Authentication: l'autenticazione avviene anche se le entità attive fanno parte di Realm differenti

15 Componenti: Principal Rappresenta la entry del database del KDC È lassociazione usata per identificare ogni utente, host o servizio allinterno del proprio Realm, per assegnare le credenziali di accesso alle risorse L'istanza è opzionale e si usa per specificare il tipo di utente

16 Componenti: Principal Se le entry sono riferite a servizi, i principal sono definiti come: Ci sono principal che non fanno riferimento nè ad utenti nè a servizi, ma hanno un ruolo nel funzionamento del sistema di autenticazione con la cui chiave associata, viene criptato il Ticket Granting Ticket

17 Componenti: KDC Il cuore del sistema è il Key Distribution Center È strutturato in tre parti, centralizzate su un unico server: Database, Authentication Server(As), Ticket Granting Server(Tgs) Nel database sono memorizzate le chiavi degli utenti e le chiavi dei servizi, ed è in grado di scambiare con ognuno di loro dei messaggi cifrati Kerberos supporta solo algoritmi simmetrici, quindi la stessa chiave è usata sia per criptare che per decriptare Vengono usate come default le porte 88 per il KDC e la porta 749 per il server di amministrazione

18 Componenti: Ticket Contiene informazioni criptate con una chiave segreta: Il principal del richiedente Il principal del server/servizio a cui è destinato Il timestamp, con data ed ora dellinizio della sua validità L'indirizzo IP della macchina client Il tempo massimo di vita La chiave di sessione Ks È usato dal client per dimostrare lautenticità della sua identità ad un server applicativo Esistono diversi tipi ognuno caratterizzato dal valore dei flag: Initial e Pre-authenticated: viene emesso dallAS. Le opzioni PRE-AUTHENT e HW-AUTHENT possono essere utilizzate per fornire informazioni addizionali nella fase di autenticazione iniziale

19 Componenti: Ticket Invalid: indica un ticket non valido Renewable: sono i ticket utilizzati per minimizzare i danni derivanti dal possibile furto di tickets, è caratterizzato da due tempi di scadenza: il tempo di scadenza associato al singolo ticket ed il massimo tempo di rinnovo possibile Postdated: ticket generato per essere utilizzato in seguito Proxiable e proxy: nel caso in cui un principal permette ad un servizio di effettuare delle operazioni al suo posto. Il servizio sarà in grado di sostituire il client, ma solo per un determinato scopo Forwardable: è una versione particolare di ticket proxy, nella quale al servizio è garantita la sostituizione totale del client

20 Le fasi di Kerberos 1 AS exchange 2 TGS exchange 3Client – Server exchange KDC Client

21 Le fasi di Kerberos Autenthication Server AS Ticket Granting Server TGS DB Key Distribution Center (KDC) AS_Rep TGS_Req TGS_Rep Application Server AP_Req AP_Rep AS_Req Client Fase 1 Fase 2 Fase 3

22 AS exchange Il client invia all'AS una richiesta di autenticazione per accedere ad una applicazione fornita da un server Il messaggio di richiesta contiene: il nome - principal il nome del server a cui vuole accedere una data di scadenza calcolata a partire dalla sua data e ora locale

23 AS exchange (2) AS_Rep AS_Req Client Ticket Tgs Autenthication Server AS Ticket Tgt Richiesta Autenticazione KserKcli

24 AS exchange (3) L'AS riceve ed invia al client due Ticket di risposta: Uno è detto TGS ed è cifrato con la chiave del server Kser, per cui è stata fatta la richiesta, assieme all'Id del client L'altro è detto TGT ed è cifrato con la chiave del client Kcli In entrambi i Ticket c'è la data di scadenza ricevuta dal client ed una copia della chiave di sessione Ks, criptata con l'hash della password dell'utente, valida per l'algoritmo crittografico scelto

25 AS exchange (4) La chiave di sessione, presente in entrambi i Ticket, permette di stabilire una comunicazione cifrata con il server interessato Se è abilitata la pre-autenticazione sull'utente, nella richiesta viene inserito un timestamp criptato con l'hash della password Una volta decriptato il timestamp, lAS accertandosi della validità, è certo che non si tratta di un playback attack, cioè di una richiesta precedente, e invierà al client i due Ticket Luso dei timestamp in un sistema distribuito comporta luso corretto della sincronizzazione

26 TGS exchange Ricevuti i due Ticket, il client decripta il TGT con la sua chiave segreta Kcli: estrae la chiave di sessione (Ks) prepara un Ticket speciale, detto Authenticator, cifrato con la chiave di sessione Ks e inserisce: un timestamp calcolato a partire dalla sua ora locale, un chksum e alcune opzioni di cifratura Il client invia al server TGS: l'Authenticator il ticket Tgs, ricevuto dallAS e cifrato con la chiave Kser, a cui vuole accedere

27 TGS exchange (2) TGS_Rep TGS_Req Client Ticket Service Ticket Granting Server TGS Ticket TgsAuthenticator KserKs Kservice

28 TGS exchange (3) Il server Tgs decripta il Ticket Tgs con la chiave segreta Kser e così estrae la chiave di sessione Ks, con la quale decripta l'Authenticator Ne può verificare la scadenza usando l'informazione contenuta nel Ticket Tgs e si accerta che è stata generata dall AS Decifrando l'Authenticator, il server verifica l'integrità del Ticket controllando il timestamp e si accerta che non si tratti di un Ticket replica Lo scambio risulta sicuro dato che la richiesta è stata fatta dal client associato all Authenticator, unico a conoscenza della chiave di sessione Ks

29 TGS exchange (4) Un client in possesso di un TGT con il time-to-live valido invia le sue richieste al TGS e non più all'AS Le comunicazioni tra TGS e client sono cifrate con la chiave di sessione Ks Crea in modo random una chiave di sessione, SKService. Crea il Ticket service inserendo il principal del client richiedente, il principal del servizio, la lista di indirizzi IP, un timestamp del KDC, il lifetime, il valore minimo tra il lifetime del TGT e quello associato al principal del servizio e infine la session key SKService Il TGS genera un'altra chiave di sessione, Kservice, utile sia per il client che per l Application server ed invia al client il Service Ticket

30 Client – Server Exchange In questa fase il KDC non è coinvolto, perciò non vi è una strategia definita affinchè il client mostri le sue credenziali al server applicativo, ma userà la Kservice per stabilire la sessione Ricevuto il Service Ticket, il client crea un Authenticator contenente il suo principal, un timestamp e cripta tutto con la chiave di sessione Kservice Il server decripta le informazioni usando la propria chiave Kservice, stabilita in precedenza con il Kdc Mutua Autenticazione, se abilitata, il server ritorna un timestamp cifrato con la chiave di sessione del Service Ticket. Non solo il client è stato autenticato, ma anche il server applicativo non ha comunicato direttamente con il Kdc

31 Client – Server Exchange (2) AP_Rep AP_Req Client Accesso al servizio Application Server Service Ticket KsSKservice Authenticator

32 Client – Server Exchange (3) In Kerberos versione 5, nei server applicativi e nel Tgs si è implementata la Replay Cache, ossia la capacità di tener traccia degli Authenticator ricevuti dal Tgs Le richieste con stesso Authenticator, cioè le richieste replicate, sono eliminate e si evita che utenti estranei riescano ad acquisire sia il Ticket che lAuthenticator Per garantire il meccanismo di autenticazione è necessario che tutti i pricipal coinvolti abbiano l'orologio di sistema sincronizzato

33 Client – Server Exchange (4) È ammessa l'autenticazione tra Realm differenti tramite luso della Cross-Realm key, una session key nota tra i differenti AS Il client effettua una richiesta al proprio TGS che individua il TGS remoto appartente all altro Realm Il client riceve il TGT per la richiesta al TGS remoto Questo TGT sarà cifrato con la chiave condivisa tra i due TGS e così il TGS remoto potrà autenticare il client fornendogli un Service Ticket, utile allo scambio con lApplication Server remoto

34 Crittografia Kerberos fa largo uso della crittografia nei Ticket scambiati tra le diverse entità coinvolte nell'autenticazione Per implementare lo scambio di messaggi tra AS, client e server, sono necessari tre elementi: un algoritmo di crittografia forte una funzione HASH una funzione per il checksum dell Authenticator Non ci sono limitazioni sulla lunghezza della password dell'utente, molti algoritmi di cifratura utilizzano una chiave a lunghezza fissa

35 Crittografia (2) Fino alla versione 4, l'unico algoritmo di crittografia supportato era il DES, a cui era associato luso di una funzione HASH ottenuta dal DES in una particolare modalità operativa e l'algoritmo CRC-32 per il calcolo dei checksum Nella versione 5, non è stato fissato a priori il numero e il tipo di encryption da supportare, dipende dalla specifica implementazione e dalla piattaforma La tecnica adottata nelle operazioni di cifratura è basata sulla funzione string2key

36 Crittografia (3) È stata introdotta la funzione string2key, che trasforma una password in chiaro in una encryption key, in base al tipo di crittografia, ed è una funzione hash irreversibile, cioè dallencryption key non si può determinare la password Viene richiamata quando un utente cambia la sua password o quando per autenticarsi si avvia una sessione Gli algoritmi disponibili sono: DES e Triplo DES per la crittografia hmac e CRC32 per i chksum sha1, md5 e la funzione derivata da DES-CBC per l'hash

37 Crittografia (4) Di default il salt aveva un valore nullo, con in nuovo Kerberos v5, come valore di salt, si usa il principal dell utente: Kclient=string2key ( Pclient + ) Kclient diventerà l'encryption key del client, dove Pclient è la password in chiaro, in tal modo si hanno i vantaggi: due principal appartenenti allo stesso Realm ed aventi la stessa password in chiaro, hanno chiavi differenti se un utente ha account su Realm diversi, è possibile che la password in chiaro coincida. Con luso del salt, si evita un'eventuale compromissione dello stato degli account Un servizio condivide con il KDC una chiave e non una password

38 Crittografia (5) Alla stringa composta dalla concatenazione della password e del SALT, viene applicata una funzione HASH, così da rendere la trasformazione dipendente dalla macchina Questa flessibilità ed estensibilità del protocollo ha mostrato dei problemi di interoperabilità tra le varie implementazioni, poiché si può applicare una qualsiasi funzione Hash ed un qualsiasi algoritmo per i checksum, occorre stabilire un encryption type in comune

39 Integrazione Le Generic Security Service Application Programming Interface sono un framework che fornisce servizi di sicurezza alle applicazioni Sono state sviluppate per creare un abstraction layer attraverso delle API standard per l'autenticazione in modo che ogni programma potesse implementare l'autenticazione astraendosi dal sistema di autenticazione sottostante L'implementazione più usata delle GSSAPI è quella relativa a Kerberos v5 Ogni implementazione Kerberos v5 include un'implementazione GSSAPI

40 Integrazione In Windows, sono definite le SSPI, ossia Microsoft Security Support Provider Interface, interfacce del tutto simili a quelle fornite da GSSAPI. Molti applicativi di Windows si riferiscono al supporto Kerberos come GSSAPI, ma usando le SSPI interni al sistema operativo In Unix, il modello di security abstraction layer per implementare GSSAPI, è stato realizzato attraverso le SASL, Simple Authentication and Security Layer. Queste API sono state create e documentate nell'RFC 2222 Un esempio dell'uso delle SASL è un' implementazione di LDAP come meccanismo di autenticazione dei clients

41 Riferimenti 3/index.html