Autenticazione Utente Kerberos 5

Presentazione sul tema: "Autenticazione Utente Kerberos 5"— Transcript della presentazione:

1 Autenticazione Utente Kerberos 5
X Autenticazione Utente Kerberos 5 Tesina di Sicurezza su Reti Studenti: Domenico Di Giorgio 556/ Cris Malinconico 556/000145 Armando Pagliara / Marco Rossi /000875 Anno Accademico 2003/2004

2 Tesina di Sicurezza Su Reti
X Tesina di Sicurezza Su Reti Progettazione di un’applicazione Client/Server per la gestione di un Data-Base Remoto con autenticazione tramite Kerberos 5 T R A C I

3 X Cos’è Kerberos Kerberos è un sistema di autenticazione sviluppato al M.I.T. tra il 1980 e il 1983 in concomitanza col progetto ATHENA e in collaborazione con IBM e la Digital Equipment Corporation. Il sistema di autenticazione è stato paragonato al famoso Cerbero (Kerberos) poiché si basa su tre procedure: autenticazione autorizzazione cifratura Kerberos è stato progettato per eliminare la necessità di dimostrare il possesso di informazioni segrete (come la password) per divulgare la propria identità. Basato sul modello di distribuzione delle chiavi sviluppato da Needham e Schroeder, usa la crittografia a chiave simmetrica (con una chiave per cifrare e decifrare) per le comunicazioni tra client e server.

4 Come funziona Kerberos
X Come funziona Kerberos Kerberos è un protocollo per autenticare utenti e servizi. Esso consta di tre figure fondamentali: Principals KDC Ticket Consideriamo principals gli utenti che Kerberos deve autenticare KDC è il Key Distribution Center il quale pubblica le prove dell’identità attraverso i tickets. I tickets contenitori di chiavi di sessione con una breve durata di vita. L'identità è controllata scambiando messaggi (request-response) in cui si usa una chiave di sessione di vita breve, ciò permette di non inviare sulla rete alcuna password . Vengono generate casualmente chiavi di sessione utilizzate per criptare/decriptare i messaggi.

5 Caratteristiche dei Tickets
X Caratteristiche dei Tickets Valido per un periodo di tempo limitato (e.g. 25h) Può essere rinnovato se valido e nel periodo di tempo permesso per il rinnovamento (e.g. 14d) Può essere inizialmente nullo Può essere inoltrabile agli altri hosts (TGT) può essere usato per ottenere ulteriori ticket Può essere distrutto se non se ne ha bisogno È immagazzinato in un archivio, di solito /tmp/… Tipi di ticket: Tickets iniziali Tickets Pre-Autenticati Ticket Invalidi Ticket Postdatati Ticket rinnovabili Proxy Ticket Forwarded Ticket

6 Installazione di Kerberos
X Installazione di Kerberos kerberos_1.3.3.tar kerberos_1.3.3 linux:> ./configure linux:> make linux:> make install  linux:> make check doc src

7 Configurazione di Kerberos
X Configurazione di Kerberos krb5.conf e kdc.conf sono i due file di configurazione che devono essere modificati per un corretto funzionamento di KerberosV Per la configurazione di Kerberos vedremo anche: Creazione Data-Base Access Control List Administrator Principals Keytab Kerberos Server krb5.conf [logging] [appdefaults] [realms] [domain_realm] [libdefaults] kdc.conf [kdcdefaults] [realms] Struttura dei file

8 X krb5.conf [libdefaults] Contiene le librerie di default utilizzate da Kerberos 5. [realms] Contiene informazioni relative ad ogni realm, ossia le macchine su cui si trovano i server Kerberos. [domain_realm] Questo tag è utilizzato dai programmi per determinare il realm di appartenenza di un host. [logging] Contiene i path dei file di log [appdefaults] Contiene i valori di default che possono essere utilizzati dagli applicativi di Kerberos 5 krb5.conf [logging] [appdefaults] [realms] [domain_realm] [libdefaults]

9 X kdc.conf [kdcdefaults] Contiene informazioni relative alle porte su cui può girare il KDC. [realms] Contiene una sottosezione per ogni realm definito nel krb5.conf ed ogni sottosezione contiene informazioni specifiche per ogni realm, incluse quelle che stabiliscono dove trovare i sever Kerberos (per quel realm). kdc.conf [kdcdefaults] [realms]

10 Creazione database di Kerberos
X Creazione database di Kerberos linux:> /usr/local/sbin/kdb5_util create -r MY.REALM -s Initializing database '/usr/local/var/krb5kdc/principal' for realm 'MY.REALM'. master key name You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <= digita la master password Re-enter KDC database master key to verify: <= ridigita la password Il comando da eseguire per poter creare il database di Kerberos per il realm definito nei file di configurazione.

11 X Access Control List L'Access Control List è un file con estensione .acl e contiene la lista dei principal che sono amministratori del database di Kerberos. Il nome del file .acl deve essere lo stesso del nome specificato nel file kdc.conf (di default kadm5.acl). Kerberos principal permission optional target principal * * Pricipali permessi: a permette l'aggiunta di nuovi principal d permette la cancellazione di principal esistenti m permette la modifica di principal esistenti c permette il cambio di password di un principal i permette le interrogazioni sul database l permette la visualizzazione del principal * Carattere jolly

12 Administrator Principals
X Administrator Principals L'aggiunta di un principal amministratore del database prevede l'utilizzo del seguente comando: linux:> /usr/local/sbin/kadmin.local kadmin.local: addprinc WARNING: no policy specified for defaulting to no policy. Enter password for principal <= digita la master password Re-enter password for principal <= ridigita la password Principal created. kadmin.local:

13 Keytab www.kerberos5.cjb.net X
Il keytab kadmind rappresenta la chiave che i vecchi demoni di amministrazione come kadmind4 e v5passwdd useranno per decifrare i ticket di kerberos provenienti dai client o dagli amministratori e determinare se essi hanno accesso oppure no al database. È necessario creare il keytab kadmind aventi come principal kadmin/admin e kadmin/changepw. linux:> /usr/local/sbin/kadmin.local kadmin.local: ktadd –k /usr/loca/var/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw Entry for principal kadmin/admin with kvno 5, encryption    type Triple DES cbc mode wih HMAC/sha1 added to keytab    WRFILE: /usr/loca/var/krb5kdc/kadm5.keytab. Entry for principal kadmin/admin with kvno 5, encryption    type DES cbc mode wih CRC-32 added to keytab    WRFILE: /usr/loca/var/krb5kdc/kadm5.keytab. Entry for principal kadmin/changepw with kvno 5, encryption    type Triple DES cbc mode wih HMAC/sha1 added to keytab    WRFILE: /usr/loca/var/krb5kdc/kadm5.keytab. Entry for principal kadmin/changepw with kvno 5, encryption    type DES cbc mode wih CRC-32 added to keytab    WRFILE: /usr/loca/var/krb5kdc/kadm5.keytab. Kadmin.local: quit linux:>

14 StartUp Kerberos-Server
X StartUp Kerberos-Server È possibile avviare i demoni di kerberos sulla macchina in cui è stato installato il KDC. I due comandi da eseguire sono i seguenti: linux:> /usr/local/sbin/krb5kdc linux:> /usr/local/sbin/kadmind Se tutto è andato a buon fine eseguendo il comando tail sui due file di log avremo il seguente risultato linux:> tail /var/log/krb5kdc.log Jul :35 :47 beeblerox krb5kdc[3187] (info) : commencing operation linux:> tail /var/log/kadmin.log Jul :35 :47 beeblerox kadmind[3189] (info) : starting

15 Applicazione Client/Server (1)
X Applicazione Client/Server (1) L’accesso ai servizi offerti dal Server è controllato tramite autenticazione con Kerberos5. L’Application Server offre le funzionalità di gestione di un Data-Base remoto inerente ad una anagrafe. L’intera applicazione si basa sui socket di Berkley per la gestione della comunicazione tra client e server.

16 Applicazione Client/Server (2)
X Applicazione Client/Server (2) Protocollo di comunicazione Client/Server Kdc Kerberos User return(ticket) krb5_get_in_tkt_with_password() Client Server fillIn(username,password) send(ticket) return(authorization) choice(request) service(request) service(result) visualizzation(result)

17 Server (1) Notifica del corretto avvio del server.
X Server (1) Notifica del corretto avvio del server. (In precedenza sono stati avviati i demoni krb5kdc e kadmind)

18 Client (1) Richiesta username e password all’utente;
X Client (1) Richiesta username e password all’utente;

19 X Client (2) Dopo aver inserito username e password viene fatta la richiesta del ticket Ottenuto il ticket ci si connette all’host server e si effettua una mutua autenticazione Se tutto ok vengono messi a disposizione una serie di funzioni per la gestione di un database remoto

20 X Server (2) Il server è attivo e si accorge della presenza di in quanto è stata fatta una mutua autenticazione

21 Client (3) www.kerberos5.cjb.net X
Il Client richiede una funzionalità all’Application Server il quale gli risponde con un risultato. Il Client visualizza il risultato ed è pronto ad effettuare un’altra operazione. Il client decide di uscire.

22 X Server (3) Il server notifica l’ingresso e l’uscita dei vari principal dal servizio. Memorizza nel file di log tutte le operazioni effettuate dal Client.

23 X Server (4) File di log in cui vengono memorizzate le operazioni dei Client

24 X Considerazioni L’applicazione offre dei servizi remoti per cui è necessario che tutte le macchine che partecipano allo scambio di messaggi siano on line e pronte a ricevere delle richieste; ricordiamo che devono essere verificate alcune condizioni: I demoni di kerberos (kadmind e krb5kdc ) devono essere avviati prima di tutti gli altri applicativi (Client e Application-Server); I Client che vogliono richiedere dei servizi all’Application-Server devono essere registrati come principal sul KDC; L’Application-Server deve essere avviato prima dei Client; La password è inserita in modalità “cieca” per assicurare un ulteriore livello di sicurezza lato Client; La chiave di ciascun record presente nel database è l’unico elemento di accesso all’utilizzo delle funzioni fornite dall’Application-Server

25 Developers www.kerberos5.cjb.net Domenico Di Giorgio Cris Malinconico
X Developers Domenico Di Giorgio Cris Malinconico Armando Pagliara Marco Rossi

26 Kerberos il mostro della rete
X Kerberos il mostro della rete

27 Kerberos: STEPS Richiesta ticket
X Kerberos: STEPS Richiesta ticket Il client richiede un ticket per il TGS (ticket granting service) Il server restituisce un ticket con la nuova chiave di sessione cifrato con la chiave utente L’ulteriore comunicazione sarà cifrata con la chiave di sessione. Autenticazione Utente Il client inserisce la password, la converte in una chiave e manda una richiesta per il TGT (Ticket granting Ticket) Richiesta Service Tickets con il TGT

28 X Applicazione Client/Server autenticazione con Kerberos 5 - database remoto (GDBM) La nostra applicazione Client/Server sarà strutturata nel seguente modo: un server gestisce un database contenente i dati anagrafici di un insieme arbitrario di persone (i record gestiti saranno composti dai seguenti campi: nome, cognome, luogo e data di nascita, residenza, indirizzo e cittadinanza). Il protocollo di comunicazione è gestito sommariamente nel seguente modo: Il server riceve via TCP/IP le richieste di: 1) inserimento 2) modifica 3) ricerca 4) cancellazione dei record del database. Il client riceve, tramite una semplicissima interfaccia testuale, le richieste dall'utente, e le trasmette via rete al server. Tutta l'applicazione deve poter essere utilizzata soltanto dagli utenti abilitati. L'applicazione utilizza Kerberos 5 per l'autenticazione degli utenti e fa uso della libreria GDBM per l''implementazione del database.