Protocollo di autenticazione KERBEROS

1. Corso di Sistemi di elaborazione delle informazioni: sicurezza Anno Accademico 2000-2001 Protocollo di autenticazione KERBEROS Daniela Demergasso

2. KERBEROS • KERBEROS: un protocollo di autenticazione. • Storia • Le componenti del processo di autenticazione. • Protezione della rete entro un dominio (reame). • Protezione della rete tra più domini. • Kerberos versioni 4 e 5. • Limiti.

3. Servizio di autenticazione Kerberos • Permette ad un processo (client), in nome di un utente (user), di provare la sua identità ad un verificatore (verifier) senza spedire dati attraverso la rete. • E’dellacategoria“authenticationforreal-time”. • Usato per applicazioni quali: remote login, file system r/w, information retrieval su Web.

4. Storia di Kerberos • E’ stato sviluppato a metà degli anni ‘80 dall’ MIT (Massachusset Institute of Tecnology), come parte del Project Athena Network. • La release Kerberos 4 è stata la prima ad essere usata al di fuori dell’MIT. • Dai limiti di Kerberos 4 (Es. l’uso del DES) si è realizzata l’implementazione di Kerberos 5. • Kerberos 5 è definito dal Request for Comment (RFC) 1510.

5. “Componenti” di Kerberos • Kerberos ha processo di autenticazione “three-sided” a chiave segreta condivisa(DES). • Il processo coinvolge tre componenti: • l’applicazione client che rappresenta l’utente che accede a un servizio • l’application server: è la risorsa che vuole accertarsi che i client siano autorizzati • il repository centralizzato delle chiavi, Key Distribution Center (KDC), e il servizio di generazione ticket Ticket Granting Service (TGS) (Authentication Server)

6. “Componenti di Kerberos”

7. Protezione della rete entro un dominio Protezione della rete entro un dominio • Un client C1 che vuole accedere a informazioni su di un application server S1 all’interno di un reame contatta il KDC per ottenere l’autenticazione. • A fronte di tale richiesta è generata una catena di eventi che porta all’autenticazione di C1. • In corrispondenza di tali eventi sono generati dei messaggi della forma: KDC > C1: {12345} KC1,S1

8. C1 KDC ts1 Client C1 {KC1,TGS {C1 KC1,TGS ts2}KTGS }KC1 KDC S1 {C1 KC1,TGS ts2}KTGS {ts3 cks}KC1,TGS {S1 KC1,S1}KC1,TGS {C1 KC1,S1}KS1 TGS {C1 KC1,S1}KS1 {ts4}KC1,S1 Server S1 { ts4 + 1} KC1,S1 Protezione della rete entro un dominio

9. Protezione della rete entro un dominioPASSO 1 • C1 effettua la richiesta di autenticazione al KDC. • Il messaggio inviato è: C1>KDC: C1 KDC ts1 • Il timestamp ts1 è l’identificativo della richiesta presso il KDC.

10. Protezione della rete entro un dominio PASSO 2 • KDC risponde con • Ticket Granting Ticket (TGT) criptato con una chiave KTGS conosciuta solo dal TGS. • KC1,TGS chiave di sessione tra TGS e C1. • TGT contiene KC1,TGS e un timestamp ts2. • L’intera risposta del KDC è criptata con la chiave privata di C1. • Messaggio: KDC>C1: {KC1,TGS{C1 KC1,TGS ts2}KTGS}KC1

11. Protezione della rete entro un dominioPASSO 3 • C1decifra con la sua chiave KC1 il messaggio ricevuto e ne estrae il TGT e la chiave di sessione KC1,TGS. • C1 manda la richiesta al TGS composta da: • nome dell’application server S1 • TGT • un “authenticator” criptato con KC1,TGS contenente • un timestamp ts3 per i controlli di validità • un checksum cks per i controlli di integrità. • Messaggio: C1>TGS: S1 {C1 KC1,TGS ts2}KTGS {ts3 cks}KC1,TGS

12. Protezione della rete entro un dominioPASSO 4 • TGS decripta il TGT con la sua chiave e controlla la validità della chiave di sessione KC1,TGS ricevuta. • Se è valida decripta l’authenticator e ne controlla validità e integrità. • Se tutto è corretto • genera la chiave di sessione per C1 ed S1 KC1,S1 • costruisce un ticket per S1contente l’identità di C1 e KC1,S1, criptato con KS1(chiave privata di S1). • Completa il messaggio con una parte contenente l’identità di S1 e la chiave KC1,S1, criptati con KC1,TGS. TGS>C1: {S1 KC1,S1}KC1,TGS {C1 KC1,S1}KS1

13. Protezione della rete entro un dominioPASSO 5 • C1 decripta parte del messaggio, con la chiave che condivide con il TGS, ottenendo la chiave di sessione per comunicare con l’application server KC1,S1. • Manda a S1 un messaggio contenente • il ticket ricevuto dal TGS per S1 • un timestamp ts4 criptato con KC1,S1. • Messaggio: C1>S1: {C1 KC1,S1}KS1{ts4}KC1,S1

14. Protezione della rete entro un dominioPASSO 6 • S1 decifra con la sua chiave privata il ticket ottenendo la chiave di sessione condivisa con C1 KC1,S1. • Controlla la validità del messaggio. • Poiché è sicuro di parlare con C1 gli manda un messaggio contenente il timestamp ts4 incrementato di uno e criptato con la chiave di sessione. • Messaggio: S1>C1: { ts4 + 1} KC1,S1 Questo messaggio è per C1 la prova che sta comunicando con S1.

15. Protezione della rete entro un dominio • Ora C1 e S1 sono sicuri delle reciproche identità. • Se C1 vuole comunicare con un altro application server S2 deve solo ripetere la richiesta (a partire dal passo 3) specificando S2 al posto di S1. Non deve autenticarsi di nuovo presso il KDC. • Il TGS gli fornirà subito un ticket cifrato per il server S2 che C1 potrà inviargli per autenticarsi e iniziare una nuova sessione. • Il ticket presentato è solo un’autenticazione, quello che C1 può fare dipende solo dal server contattato.

16. Protezione della rete tra più domini • Kerberos può “coprire” più domini. • Ogni reame dispone di un KDC e di un TGS. • C1 per autenticarsi presso un server in altro reame fa una richiesta ai propri KDC e TGS locali. • TGS riconosce la richiesta per un altro reame e fornisce a C1 un TGT per la richiesta al TGS remoto. • Il TGT è cifrato con la chiave condivisa dai due TGS.

17. Protezione della rete tra più domini • Il TGS remoto autentica il client fornendogli il ticket per il server voluto. • I client dovrebbero registrarsi nei diversi domini: proposta inaccettabile. • Kerberos 5 prevede la condivisione di chiavi gerarchica. • C1 contatta un reame che conosce l’altro reame e così via fino a che non si trova il TGS remoto che emette i ticket per il server voluto.

18. Kerberos 4 e Kerberos 5 • Kerberos 4 è passibile del off-line password guessing. • In Kerberos 5 si è risolto il problema: il timestamp ts1 del primo messaggio viene criptato con la chiave privata del client, ottenuta dall’immediata digitazione della password e solo dopo è inviato al KDC. C1>KDC: C1 KDC {ts1} KC1 • KDC determina la KC1 dal suo data base locale, decifra ts1e solo se il tempo è corretto manda il TGT.

19. C1 KDC ts1 Client C1 Client C1 KDC KDC C1 KDC {ts1}KC1 Kerberos 4 e Kerberos 5 Kerberos 4: Il primo messaggio inviato non e` criptato. Kerberos 5: Il primo messaggio inviato e` criptato.

20. Limiti di Kerberos • E’ soggetto ad attacchi con dizionari di password. • Ogni programma che lo usa deve essere kerberizzato e questo non è sempre possibile. • Il server di autenticazione KDC deve essere fisicamente protetto. • Tutte le password sono crittografate con una singola master key. Un server compromesso implica il cambiamento di tutte le password.

21. Limiti di Kerberos • Il server di Kerberos deve essere sempre disponibile. • Non c’è protezione contro le modifiche del sistema Sw: un utente non può sapere se il server è compromesso. • Kerberos non lavora bene in ambiente time-sharing. (Esempio: memorizzazione dei ticket in /tmp di Unix) • Il tempo limitato per la validità dei ticket è un problema per applicazioni con run time elevato.

22. Riferimenti • Reti di computer Tanenbaum -Terza Edizione - Edizione Italiana (1997) UTET (Prentice Hall International) • Kerberos Authentication System G.Gramegna - Università degli studi di Padova www.dei.unipi.it/~megna/Reti/Kerberos.html • Un cerbero per proteggere i dati Michael E. Chacon www.netmagazine.net/wwire/mesi/free/nt-9801/w9801096.htm