Valentino Ricci Prof. Luciano Margara

Presentazione sul tema: "Valentino Ricci Prof. Luciano Margara"— Transcript della presentazione:

1 Valentino Ricci Prof. Luciano Margara
Kerberos Valentino Ricci Prof. Luciano Margara

2 Cos’è Kerberos? Kerberos è un protocollo di rete per l'autenticazione.
Modello client-server, fornisce mutua autenticazione. Si basa sulla crittografia simmetrica e sul protocollo Needham-Schroeder, utilizza però una terza parte affidabile.

3 Utilizzi AFS, NFS, Coda File System (distributed networked file system ) Apache (mod_auth_kerb) e Apache 2 (libapache-mod-auth-kerb) Cisco routers and switches running Eudora, Mulberry ( client) Mac OS X Microsoft Windows 2000 e successivi (default authentication protocol) OpenSSH SSH protocol (Kerberos v5) PAM Pluggable authentication modules (pam_krb5 module) Samba, Netatalk networking protocol SOCKS Internet protocol X Window System standard toolkit and protocol to build GUI Qualsiasi software che usi il framework SASL (OpenLDAP, Dovecot IMAP4 , POP3, Postfix) La suite di Kerberos contiene versioni kerberizzate di rsh, FTP e Telnet Qualsiasi software java che utilizzi JAAS/JGSS È possibile modificare qualsiasi applicazione affinché utilizzi Kerberos

4 Un po’ di storia Realizzato dal MIT per il progetto ATHENA in alternativa al sistema di autenticazione tradizionale. La versione 4 fu ideata nel 1987 da Steve Miller e Clifford Neuman. La Versione 5 (RFC 1510 proposed standard) fu ideata nel 1990 John Kohl e Clifford Neuman . Le autorità degli USA classificarono Kerberos come arma e ne vietarono l'esportazione poiché utilizzava l'algoritmo di crittazione DES (con chiavi da 56 bit). Una implementazione di Kerberos non statunitense, KTH-KRB sviluppata in Svezia, rese il sistema disponibile anche al di fuori degli Stati Uniti.

5 Perché Kerberos? Il nome KERBEROS deriva dalla mitologia greca (Cerbero) Cerbero 3 teste = Kerberos 3 moduli: Authentication: un servizio che consente di accertare l'identita' dichiarata da una entita' mediante la verifica di credenziali. Authorization: Protegge l'accesso ad una risorsa mediante l'applicazione di “Security Policy”. Audit: Registrazione di eventi di sistema o di rete. Consente di rintracciare, ricostruire l'utilizzo delle risorse. In realtà le ultime due componenti non sono mai state realizzate (la 2 implementata nel Kerberos di Microsoft).

6 Motivazioni L’obbiettivo di Athena era quello di creare e amministrare un ambiente distribuito scalabile fino a workstation. Problema: Gli utenti collegati alle workstation desiderano accedere a servizi forniti da server distribuiti sulla rete. I server devono essere in grado di consentire gli accessi solo a utenti autorizzati e di autenticare le richieste di servizi. (rischio spoofing e sniffing)

7 Le assunzioni di Kerberos
Le password non sono "facili“. Le workstation sono sicure (no keylogger o software simili). La rete è insicura.

8 Autenticazione tradizionale
pwd User id 1 - Richiesta di autenticazione Server User 2 – Se l’utente è riconosciuto ACCESSO

9 Autenticazione tradizionale
Problemi: per evitare che utenti non autorizzati accedano alle risorse occorre implementare un meccanismo di autenticazione per ciascun servizio per garantire la sicurezza di ciascun servizio bisogna implementare meccanismi complessi per ciascuno di essi (nell’esempio precedente password in chiaro non è sicuro) in un ambiente distribuito in cui i client interagiscono spesso con i server il sistema di autenticazione decentralizzato appesantisce molto l’attività dei server Soluzione: Authentication server (AS): l’autenticazione è centralizzata, l’AS condivide con ciascun server e ciascun utente una chiave segreta

10 Authentication Server
IDV PU IDU 1 - Richiesta di autenticazione AS Ticket User 2 – Se l’utente è riconosciuto viene restituito un Ticket = EKV[ IDU | ADU | IDV ] che permette di accedere alla risorsa V Ticket IDU Server V

11 Authentication Server
Problemi: Richiesta di password per accedere a ciascun servizio (ticket utilizzabile una volta sola). Richiesta di password per accedere a servizi diversi (ticket riutilizzabile). Possibile sniffing del ticket e successivo spoofing per impersonare l’utente (si risolverà più avanti). Password in chiaro (bleah!!!). Soluzione: Ticket granting server (TGT): distributore di ticket per le risorse. Protocollo che non prevede il passaggio della password in chiaro.

12 Ticket granting server
IDTGS IDU AS EKU[TicketTGS] 1 – L’AS restituisce TicketTGS=EKTGS[IDU|ADU|IDTGS|TS1|Tvalidità1] cifrato con la chiave segreta dell’utente (una sola volta per connessione) IDV IDU TicketTGS User TGS TicketV TicketV IDU 2 – TGS restituisce TicketV=EKV[IDU|ADU|IDV|TS2|Tvalidità2] (una sola volta per tipologia di servizio) Server V 3 – Il server fornisce il servizio al client (una sola volta per sessione di servizio)

13 Ticket granting server
Problemi: Tempo di validità Se il tempo di validità del TicketTGS è basso all’utente verrà chiesta molte volte la password Se il tempo di validità del TicketTGS è alto (ore) c’è la possibilità che un avversario faccia sniffing del ticket e lo riutilizzi quando l’utente leggittimo si sarà disconesso impersonificandolo. Analogo discorso si può fare per il TicketV Un avversario potrebbe mettersi nel mezzo e fare in modo che i messaggi siano inviati a un server fasullo impedendo all’utente di comunicare con il vero server. Soluzione: Autenticatore: permette a un server di assicurarsi che la persona che utilizza il ticket è la stessa per cui il ticket è stato emesso. Chiavi di sessione: permettono ai server di autenticarsi agli utenti (MUTUA ESCLUSIONE, CONFIDENZIALITÀ).

14 Kerberos v4 AS TGS IDTGS IDU TS1
EKU[KU,TGS|IDTGS|TS2|Tvalidità2|TicketTGS] 1 – TicketTGS=EKTGS[KU,TGS|IDU|ADU|IDTGS|TS2|Tvalidità2] (una sola volta per connessione) AutetenticatoreU IDU TicketTGS TGS User EKU,TGS[KU,V|IDV|TS4|Tvalidità4] EKU,V[TS5 +1] TicketV AutenticatoreU2 2 – TicketV= EKV [KU,V|IDU|ADU|IDV|TS4|Tvalidità4] AutenticatoreU= EKU,TGS[IDU|ADU|TS3] (una sola volta per tipologia di servizio) 3 – AutenticatoreU = EKU,TGS[IDU|ADU|TS5] Anche V si autentica (M.A. e CONF.) (una sola volta per sessione di servizio) Server V

15 Definizioni KDC (Key Distribution Center) = è sinonimo di AS e TGS, nonostante la divisione in due parti, le due funzioni vengono svolte entrambe da un server program che risiede sul sistema KDC Client = è un entità che puo’ ottenere un “ticket”puo’ essere sia un utente che un “host” Host = è un computer accessibile dalla rete Keytab = Una tabella usata dagli host o dai servizi per memorizzare la loro chiave segreta Principal = Denota un utente o un servizio a cui assegnamo delle credenziali. È una stringa del tipo: Primary equivale al nome dell’utente/servizio Instance e’ la qualifica di un utente Realm = E’ una rete “logica” che fa capo ad un unico database. Definisce un area di validita’ dei ticket

16 Differenze tra V4 e V5 Dalla versione 4 alla versione 5 sono stati introdotti molti miglioramenti sia all'implementazione che al protocollo, essi possono essere riassunti nei seguenti punti: I nomi dei Principal sono multi-componente piuttosto che del tipo Nuovi flag nei ticket Autenticazione two-tgt user-to-user Sostituzione dell'algoritmo di cifratura Indipendenza dal tipo di indirizzo

17 Cifratura La parte cifrata riveste un ruolo fondamentale all'interno dei singoli passaggi legati al processo di scambio delle credenziali alla base del Kerberos string2key: funzione che converte password in chiave di cifratura simmetrica per implementare lo scambio di messaggi tra AS, client e server, sono necessari tre elementi: una algoritmo di crittografia forte; una funzione HASH; una funzione che implementi il checksum per l'Authenticator; nelle prime versioni di Kerberos l’alg. di crittografia usato era solo il DES,e non si usava il SALT nella versione 5 (attuale) algoritmi disponibili sono DES e Triplo DES per la crittografia (si ottiene chiave da 64 bit ) DES-CBC per l'hash CRC32 per i checksum

18 Attacchi Nella gestione dei ticket è possibile per un pirata intromettersi nella workstation (Backdoor,trojan) intercettare un ticket, prelevare le credenziali e spacciarsi per il client Nella risposta di Kerberos ad un principal, possibilità di intercettazione della chiave privata rilasciata (attacco BRUTE FORCE) Nella versione 5 trovate due falle (nel software, non nel protocollo) con possibili attacchi Ddos (creare carico di lavoro elevato tale da bloccare il sistema)

19 Pregi e difetti Le limitazioni possono essere riassunte nei seguenti
punti: Non protegge dalla possibilità di scoperta della password dell'utente Richiede in genere una macchina dedicata e sicura come KDC Le applicazioni devono essere in parte riscritte Superato il DES sussistono ancora conflitti con la legislazione degli USA l'installazione e' molto "intrusiva”

20 Pregi e difetti Kerberos ha molti dei pregi:
La gestione centralizzata delle chiavi e degli utenti (revoca, rinnovo, cancellazione,ecc,ecc) è più semplice ed efficiente che in altri sistemi come SSL. è un sistema FREE cioè aperto a tutte le modifiche e contributi. è sicuro perché la chiave non circola sulla rete e non e’ memorizzata in nessun posto oltre che la testa dell’utente e il KDC. è flessibile, volendo usare una nuova tecnologia di autenticazione (per esempio un nuovo tipo di Smart Card con il proprio algoritmo), basta ”solo” modificare il KDC.

21 Bibliografia http://web.mit.edu/Kerberos/#what_is
W. Stalling. Sicurezza delle reti, Addison Wesley, 2001. Bill Bryant. Designing an Authentication System: a Dialogue in Four Scenes Afterword by Theodore Ts'o, 1997. Brian Tung. The Moron's Guide to Kerberos. B. Clifford Neuman and Theodore Ts'o. Kerberos: An Authentication Service for Computer Networks, IEEE Communications, 32(9): September 1994. John T. Kohl, B. Clifford Neuman, and Theodore Y. T'so, The Evolution of the Kerberos Authentication System. In Distributed Open Systems, pages IEEE Computer Society Press, 1994. John Kohl and B. Clifford Neuman. The Kerberos Network Authentication Service (Version 5). Internet Request for Comments RFC September 1993.