Kerberos v5

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

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

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 l’identità 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 sull’uso 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 vieneinviata sulla rete, non viene memorizzata sull’ host (non dovrebbe essere memorizzata “in chiaro” neanche nel database del KDC) e viene cancellata dopo l’utilizzo • Single Sign-On: l'utente inserisce la password all’inizio 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ì l’invio 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 l’uso delle chiavi

8. Il protocollo Kerberos • Rappresenta un’alternativa 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 l’ausilio di certificati digitali contenenti le chiavi pubbliche degli utenti firmate con la chiave privata di un’autorità di certificazione

9. Il protocollo Kerberos Autenticazione a due parti • È 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 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 DB Autenthication Server AS Client Ticket Granting Server TGS Key Distribution Center (KDC) … Application Server

12. Il protocollo Kerberos REALM 1 REALM 2 Server … … Client Server … … Client REALM 3 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 • Il nome del Realm coincide con il dominio DNS semplifica la configurazione e l’integrazione del sistema Kerberos Dominio DNS Realm Kerberos EXAMPLE.COM example.com 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 • È l’associazione usata per identificare ogni utente, host o servizio all’interno del proprio Realm, per assegnare le credenziali di accesso alle risorse • component1/component2/.../componentN@REALM • user@EXAMPLE.COM  • admin/admin@EXAMPLE.COM • 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: Servizio/Hostname@REALM • imap/mbox.example.com@EXAMPLE.COMhost/server.example.com@EXAMPLE.COMafs/example.com@EXAMPLE.COM • Ci sono principal che non fanno riferimento nè ad utenti nè a servizi, ma hanno un ruolo nel funzionamento del sistema di autenticazione • krbtgt/REALM@REALM, 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 dell’inizio della sua validità • L'indirizzo IP della macchina client • Il tempo massimo di vita • La chiave di sessione Ks • È usato dal client per dimostrare l’autenticità della sua identità ad un server applicativo • Esistono diversi tipi ognuno caratterizzato dal valore dei flag: • Initial e Pre-authenticated: viene emesso dall’AS. 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 3 Client – Server exchange Client KDC

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

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_Req Autenthication Server AS Client Richiesta Autenticazione AS_Rep Kser Kcli Ticket Tgs Ticket Tgt

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, l’AS accertandosi della validità, è certo che non si tratta di un playback attack, cioè di una richiesta precedente, e invierà al client i due Ticket • L’uso dei timestamp in un sistema distribuito comporta l’uso 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 dall’AS e cifrato con la chiave Kser, a cui vuole accedere

27. TGS exchange (2) TGS_Req Ticket Granting Server TGS Kser Ks Client Ticket Tgs Authenticator TGS_Rep Kservice Ticket Service

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_Req Ks SKservice Application Server Client Service Ticket Authenticator AP_Rep Accesso al servizio

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 l’Authenticator • 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 l’uso 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 l’Application 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 l’uso 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è dall’encryption 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 + “client@EXAMPLE.COM" ) • 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 l’uso 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 • http://web.mit.edu/rhel-doc/3/rhel-rg-it-3/index.html • http://web.mit.edu/kerberos/www • http://en.wikipedia.org/wiki/Kerberos • http://www.zeroshell.net/kerberos/