Protocollo di autenticazione

KERBEROS

Corso di Sistemi di elaborazione delle informazioni: sicurezza

Anno Accademico 2000-2001

Daniela Demergasso

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.

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’ della categoria “authentication for real-time”.

Usato per applicazioni quali: remote login, file system r/w, information retrieval su Web.

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.

“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)

“Componenti di Kerberos”

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

Protezione della rete entro un dominio

Protezione della rete entro un dominioC

lien

t C

1

KD

C

TG

S

Serv

er

S1

C1 KDC ts1

{KC1,TGS {C1 KC1,TGS ts2}KTGS }KC1

{S1 KC1,S1}KC1,TGS {C1 KC1,S1}KS1

{ ts4 + 1} KC1,S1

{C1 KC1,S1}KS1 {ts4}KC1,S1

S1 {C1 KC1,TGS ts2}KTGS {ts3 cks}KC1,TGS

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.

Protezione della rete entro un dominioPASSO 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

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

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

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

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.

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.

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.

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.

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.

Kerberos 4 e Kerberos 5

Clien

t C

1

KD

C

C1 KDC ts1

Clien

t C

1

KD

C

C1 KDC {ts1}KC1

Kerberos 5: Il primo messaggio inviato e` criptato.

Kerberos 4: Il primo messaggio inviato non e` criptato.

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.

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.

Riferimenti

Reti di computer Tanenbaum -Terza Edizione - Edizione Italiana (1997)

UTET (Prentice Hall International)

Kerberos Authentication SystemG.Gramegna - Università degli studi di Padova

www.dei.unipi.it/~megna/Reti/Kerberos.html

Un cerbero per proteggere i datiMichael E. Chacon

www.netmagazine.net/wwire/mesi/free/nt-9801/w9801096.htm