Autenticazione sicurezza informatica

TGS

Manda quindi ad AS il proprio codice identificativo (IDc) e quello del TGS di cui intende

servirsi.

- AS  C: qui AS manda al client un ticket crittografato attraverso una chiave generata a

partire dalla password dell’utente: Kc. Il client chiede quindi la password all’utente, genera

la chiave ed è in grado di estrarre ticket .

TGS

In questo modo l’utente ottiene il ticket senza trasmettere in chiaro la sua password cosi è risolto il

secondo problema. Per risolvere il primo problema, nel ticket si mette anche un timestamp che

TGS

indica il momento dell’emissione del ticket ed un Lifetime che indica la durata di validità del ticket.

La versione 5 di kerberos, pur mantenendo la forma base della versione 4, apporta modifiche volte

a risolvere problemi e vulnerabilità del sistema, di natura ambientale e tecnica.

Molte migliorie vengono apportate mediante l’uso di flags dei ticket.

Il campo FLAG è un campo del ticket che può supportare funzionalità differenti a seconda della

versione di kerberos considerata.

Possiamo dire che la versione 4 impiega DES che non è un sistema adattabile a diverse

piattaforme e non è un sistema di sicurezza assoluto; nella versione 5 il tipo di crittografia può

variare, anche nel numero e nel tipo delle chiavi.

Inoltre nella versione 4 i ticket ai client vengono crittografati 2 volte e quindi è uno spreco di lavoro

a livello computazionale (quindi nella versione 5 lo abolisce).

In kerberos 5 i ticjket includono:

- From: tempo di inizio della validità del ticket;

- Till: tempo di fine della validità del ticket;

- Rtime: tempo di rinnovo richiesto;

la durata del ticket è dunque arbitraria. Se un ticket ha durata lunga può essere intercettato e

sfruttato per un periodo di tempo importante; se la durata è breve si dovrà considerare il

sovraccarico dovuto all’acquisizione di nuovi ticket. Per gestire queste problematiche viene anche

introdotto nei ticket il flag RENEWABLE. Un ticket con questo flag attivo è rinnovabile cioè include

due date di scadenza: una vera e propria e una che rappresenta l’ultimo valore consentito come

data di scadenza.

Infine per quanto riguarda gli attacchi alle password, kerberos 5 prevede un sistema detto

preautenticazione che complica, pur non impedendo, gli attacchi alle password. Per quanto

riguarda gli attacchi di tipo replay, qui client e server ad ogni nuova connessione, ovvero ad ogni

utilizzo del ticket, concordano una nuova chiave di sottosessione: in particolare è il client che, ad

ogni utilizzo nuovo del ticket, introduce una sottochiave nell’autenticatore; se il client omette tale

passaggio, per quella connessione si userà la chiave di sessione principale.

I principali aspetti di Kerberos che lo rendono ancora un sistema non del tutto sicuro sono:

- Non protegge efficacemente contro la possibilità che la password dell’utente sia

compromessa;

- Richiede un canale sicuro che gestisca la password dell’utente, e la presenza di AS, un

server di autenticazione sicuro e fidato che dovrà stare, protetto, in una area fisicamente

sicura;

- Il server AS deve essere costantemente in funzione;

- Soggetto ad attacchi di tipo spoofing;

Federated Identity Management (Identità federate)

Un utente può aver bisogno di usare la propria identità in più contesti. Si trasferisce

l’autenticazione di un utente su più domini. Qui il concetto più importante è il SSO (single sign-on)

ossia che un utente si firma una sola volta e dopo di che l’autenticazione ed i permessi relativi alla

sua identità rimangono validi nel corso della sessione su più server; questo si porta dietro una

serie di servizi che richiedono:

- Fiducia sull’entità della persona;

- Rilascio di chiavi;

- servizi che permettono di gestire le autorizzazioni;

- Gestire il proprio profilo

Il funzionamento è il seguente:

l’utente nel quale richiede questa identità è chiamato principal. Il responsabile di autenticare

questa l’identità di questo principal è chiamato Identity provider.

I dati vengono poi utilizzati da un consumatore di dati. Tutto ciò che qualifica le caratteristiche del

principal vengono chiamati attributi.

La richiesta viene fatta al fornitore di identità (ad esempio a partire dal browser dell’utente); nel

chiedere all’identity provider l’autenticazione della propria entità, l’utente può anche fornire una

serie di attributi; altri attributi che sono associati invece ai ruoli che l’utente può svolgere vengono

aggiunti dal provider. L’amministratore permette al fornitore di identità di fare queste modifiche,

cioè di verificare effettivamente se tutti i dati sono congruenti.

Queste informazioni vengono passate ad un fornitore di servizio che si trova in un dominio

qualunque e corrisponde all’ente nel quale l’utente richiede il servizio.