Kerberos v5 Presentazione dello studente Flavio Caroli per il corso di Griglie Computazionali prof....

Kerberos v5

Presentazione dello studente Flavio Presentazione dello studente Flavio CaroliCaroliper il corso di Griglie per il corso di Griglie Computazionali Computazionali prof. Tiziana Ferrari - a.a. 2005/06 prof. Tiziana Ferrari - a.a. 2005/06 --

2

Il protocollo Kerberos

Obiettivi Componenti

Servizi e ruoli

Strategie del protocollo

Crittografia

Integrazione

3


Nasce nei primi anni ’80 dalla collaborazione di IBM, Digital e M.I.T. Il nome deriva dalla mitologia grecaAutorizzazione: determinare se un client è autorizzato ad usufruire di un servizio Autenticazione: determinare se l’identità dichiarata dal client è veraCifratura - accounting: garantire la segretezza della comunicazione e prevenire che parti estranee la modificano o la intercettano

4

Il protocollo KerberosÈ un protocollo distribuito che fornisce la sicurezza di autenticazione su reti aperte e insicure dove la comunicazione tra gli host può essere intercettataUtilizza uno schema Third Party Trust (^) e si basa sull’uso di chiavi segrete per cifrare le informazioni scambiate tra le entitàGli utenti, i client e i server si autenticano a vicenda tramite il KDC, Key Distribution Center

(^) Nota: “Third party trust refers to a situation where two parties can trust each other, even if they don't know each other, based on a relationship with a mutual, trusted third party. In third party trust, one authority acts to ensure the trustworthiness of the other parties.”

5

ObiettiviLa password dell'utente non viene inviata sulla rete, non viene memorizzata sull’ host (non dovrebbe essere memorizzata “in chiaro” neanche nel database del KDC) e viene cancellata dopo l’utilizzoSingle Sign-On: l'utente inserisce la password all’inizio della sessione di lavoro. Può accedere, senza reinserirla durante tale sessione, a tutti i servizi per il quale è autorizzatoMutua autenticazione: anche i server applicativi provano la loro autenticità ai client

6

ObiettiviL'intero processo di autenticazione risulta invisibile all'utente e realizza uno scambio di Ticket cifrati senza che sulla rete circolino informazioni segreteSi limita così l’invio delle informazioni di autenticazione attraverso la rete ed agisce su host e su server applicativi (imap, pop, smtp, telnet, ftp, ssh , AFS ) considerati vulnerabili La gestione delle informazioni di autenticazione è centralizzata e protetta sul sistema KDC

7

ObiettiviLe informazioni di autenticazione dei client non vengono memorizzate sui server applicativiViene limitata la ridondanza di informazioni di autenticazione e ridotte le locazioni “attaccabili”L'account di un utente può essere disabilitato agendo direttamente sul KDCDopo autenticazione e autorizzazione, la connessione tra client e server viene impostata come sicura e i dati vengono trasmessi e criptati con l’uso delle chiavi

8

Il protocollo KerberosRappresenta un’alternativa al modello di autenticazione a due partiElimina la trasmissione delle informazioni di autenticazione sulla rete riducendo le locazioni “attaccabili” da utenti estraneiNon si ha la necessità di dimostrare il possesso di informazioni segreteIl sistema di autenticazione è supportato solo dal KDC e senza l’ausilio di certificati digitali contenenti le chiavi pubbliche degli utenti firmate con la chiave privata di un’autorità di certificazione

9


È differente rispetto allo schema X.509, utilizzato in molte applicazioni(SSL/TLS...), il cui fulcro è costituito dai certificati a chiave pubblica associati ad ogni client

Autenticazione a due parti

Autenticazione a terza parte di fiducia

10

SSL vs KerberosConfronto tra il sistema a chiavi pubbliche basato sui certificati contro quello con autenticazione a chiavi private basato su Third Party Trust SSL può essere usato per stabilire una connessione sicura anche tra due parti e non richiede una terza parte fidataIn Kerberos non c'è la necessità di ricerca di certificati per l'autenticazione, tranne per la password che però non è su HDKerberos è flessibile, per aggiornarlo occorre modificare il KDC, è un pacchetto libero e può essere installato senza costi di licenza, al contrario di SSLIl sistema Kerberos può risultare compromesso se l'autenticazione di un utente è per un servizio che non utilizza Kerberos, come Telnet e FTP, si rimedia utilizzando i protocolli cifrati, come i servizi sicuri SSH o SSL

11


Autenthication Server AS

Ticket Granting

Server TGS

DB

Key Distribution Center (KDC)

Application Server

Client

…

12


REALM 2

Server……Client

REALM 1

REALM 3

Server……Client

Server……Client

13

Componenti: Realm

È il dominio amministrativo di autenticazione, entro cui il/i server di autenticazione è responsabile dell'autenticare un utente o un servizioRappresenra l'insieme di utenti e di server appartenenti e coordinati da uno specifico Authentication Server Un utente/servizio appartiene ad un Realm se e solo se condivide un password/chiave con il server di autenticazione AS

14

Componenti: Realm

example.coexample.comm

EXAMPLE.COMEXAMPLE.COM

Dominio Dominio DNSDNS

Realm KerberosRealm Kerberos

Il nome del Realm coincide con il dominio DNS semplifica la configurazione e l’integrazione del sistema Kerberos

Cross-Authentication: Cross-Authentication: l'autenticazione avviene anche se l'autenticazione avviene anche se le entità attive fanno parte di le entità attive fanno parte di Realm differentiRealm differenti

15

Componenti: PrincipalRappresenta la entry del database del KDCÈ l’associazione usata per identificare ogni utente, host o servizio all’interno del proprio Realm, per assegnare le credenziali di accesso alle risorsecomponent1/component2/.../componentN@REALM

[email protected] admin/[email protected]

L'istanza è opzionale e si usa per specificare il tipo di utente

16

Componenti: PrincipalSe le entry sono riferite a servizi, i principal sono definiti come: Servizio/Hostname@REALM

imap/[email protected]/[email protected]/[email protected]

Ci sono principal che non fanno riferimento nè ad utenti nè a servizi, ma hanno un ruolo nel funzionamento del sistema di autenticazione

krbtgt/REALM@REALM, con la cui chiave associata, viene criptato il Ticket Granting Ticket

17

Componenti: KDCIl cuore del sistema è il Key Distribution CenterÈ strutturato in tre parti, centralizzate su un unico server:

Database, Authentication Server(As), Ticket Granting Server(Tgs)

Nel database sono memorizzate le chiavi degli utenti e le chiavi dei servizi, ed è in grado di scambiare con ognuno di loro dei messaggi cifrati Kerberos supporta solo algoritmi simmetrici, quindi la stessa chiave è usata sia per criptare che per decriptareVengono usate come default le porte 88 per il KDC e la porta 749 per il server di amministrazione

18

Componenti: TicketContiene informazioni criptate con una chiave segreta:

Il principal del richiedente Il principal del server/servizio a cui è destinatoIl timestamp, con data ed ora dell’inizio della sua validitàL'indirizzo IP della macchina client Il tempo massimo di vitaLa chiave di sessione Ks

È usato dal client per dimostrare l’autenticità della sua identità ad un server applicativoEsistono diversi tipi ognuno caratterizzato dal valore dei flag:

Initial e Pre-authenticated: viene emesso dall’AS. Le opzioni PRE-AUTHENT e HW-AUTHENT possono essere utilizzate per fornire informazioni addizionali nella fase di autenticazione iniziale

19

Componenti: TicketInvalid: indica un ticket non validoRenewable: sono i ticket utilizzati per minimizzare i danni derivanti dal possibile furto di tickets, è caratterizzato da due tempi di scadenza:

il tempo di scadenza associato al singolo ticket ed il massimo tempo di rinnovo possibile

Postdated: ticket generato per essere utilizzato in seguito Proxiable e proxy: nel caso in cui un principal permette ad un servizio di effettuare delle operazioni al suo posto. Il servizio sarà in grado di sostituire il client, ma solo per un determinato scopoForwardable: è una versione particolare di ticket proxy, nella quale al servizio è garantita la sostituizione totale del client

20

Le fasi di Kerberos

1 AS exchange

2 TGS exchange

3 Client – Server exchange

KDCKDCClientClient

21

Le fasi di Kerberos


Ticket Granting

Server TGS

DB

Key Distribution Center (KDC)

AS_Rep

TGS_Req

TGS_Rep

Application Server

AP_Req

AP_Rep

AS_ReqClient Fase 1

Fase 2

Fase 3

22

AS exchangeIl client invia all'AS una richiesta di autenticazione per accedere ad una applicazione fornita da un serverIl messaggio di richiesta contiene:

il nome - principalil nome del server a cui vuole accedere una data di scadenza calcolata a partire dalla sua data e ora locale

23

AS exchange (2)

AS_Rep

AS_Req

Client

Ticket Tgs


Ticket Tgt

Richiesta Autenticazione

Kser Kcli

24

AS exchange (3)L'AS riceve ed invia al client due Ticket di risposta:

Uno è detto TGS ed è cifrato con la chiave del server Kser, per cui è stata fatta la richiesta, assieme all'Id del clientL'altro è detto TGT ed è cifrato con la chiave del client Kcli

In entrambi i Ticket c'è la data di scadenza ricevuta dal client ed una copia della chiave di sessione Ks, criptata con l'hash della password dell'utente, valida per l'algoritmo crittografico scelto

25

AS exchange (4)La chiave di sessione, presente in entrambi i Ticket, permette di stabilire una comunicazione cifrata con il server interessatoSe è abilitata la pre-autenticazione sull'utente, nella richiesta viene inserito un timestamp criptato con l'hash della passwordUna volta decriptato il timestamp, l’AS accertandosi della validità, è certo che non si tratta di un playback attack, cioè di una richiesta precedente, e invierà al client i due TicketL’uso dei timestamp in un sistema distribuito comporta l’uso corretto della sincronizzazione

26

TGS exchangeRicevuti i due Ticket, il client decripta il TGT con la sua chiave segreta Kcli:

estrae la chiave di sessione (Ks) prepara un Ticket speciale, detto Authenticator, cifrato con la chiave di sessione Ks e inserisce: un timestamp calcolato a partire dalla sua ora locale, un chksum e alcune opzioni di cifratura

Il client invia al server TGS:l'Authenticator il ticket Tgs, ricevuto dall’AS e cifrato con la chiave Kser, a cui vuole accedere

27

TGS exchange (2)

TGS_Rep

TGS_Req

Client

Ticket Service

Ticket Granting

Server TGS

Ticket Tgs Authenticator

Kser Ks

Kservice

28

TGS exchange (3)Il server Tgs decripta il Ticket Tgs con la chiave segreta Kser e così estrae la chiave di sessione Ks, con la quale decripta l'Authenticator

Ne può verificare la scadenza usando l'informazione contenuta nel Ticket Tgs e si accerta che è stata generata dall’ ASDecifrando l'Authenticator, il server verifica l'integrità del Ticket controllando il timestamp e si accerta che non si tratti di un Ticket replica

Lo scambio risulta sicuro dato che la richiesta è stata fatta dal client associato all’ Authenticator, unico a conoscenza della chiave di sessione Ks

29

TGS exchange (4)Un client in possesso di un TGT con il time-to-live valido invia le sue richieste al TGS e non più all'ASLe comunicazioni tra TGS e client sono cifrate con la chiave di sessione KsCrea in modo random una chiave di sessione, SKService. Crea il Ticket service inserendo il principal del client richiedente, il principal del servizio, la lista di indirizzi IP, un timestamp del KDC, il lifetime, il valore minimo tra il lifetime del TGT e quello associato al principal del servizio e infine la session key SKServiceIl TGS genera un'altra chiave di sessione, Kservice, utile sia per il client che per l’ Application server ed invia al client il Service Ticket

30

Client – Server ExchangeIn questa fase il KDC non è coinvolto, perciò non vi è una strategia definita affinchè il client mostri le sue credenziali al server applicativo, ma userà la Kservice per stabilire la sessioneRicevuto il Service Ticket, il client crea un Authenticator contenente il suo principal, un timestamp e cripta tutto con la chiave di sessione KserviceIl server decripta le informazioni usando la propria chiave Kservice, stabilita in precedenza con il KdcMutua Autenticazione, se abilitata, il server ritorna un timestamp cifrato con la chiave di sessione del Service Ticket. Non solo il client è stato autenticato, ma anche il server applicativo non ha comunicato direttamente con il Kdc

31

Client – Server Exchange (2)

AP_Rep

AP_Req

Client

Accesso al servizio

Application Server

Service Ticket

Ks SKservice

Authenticator

32


In Kerberos versione 5, nei server applicativi e nel Tgs si è implementata la Replay Cache, ossia la capacità di tener traccia degli Authenticator ricevuti dal TgsLe richieste con stesso Authenticator, cioè le richieste replicate, sono eliminate e si evita che utenti estranei riescano ad acquisire sia il Ticket che l’AuthenticatorPer garantire il meccanismo di autenticazione è necessario che tutti i pricipal coinvolti abbiano l'orologio di sistema sincronizzato

33


È ammessa l'autenticazione tra Realm differenti tramite l’uso della Cross-Realm key, una session key nota tra i differenti ASIl client effettua una richiesta al proprio TGS che individua il TGS remoto appartente all’ altro RealmIl client riceve il TGT per la richiesta al TGS remoto Questo TGT sarà cifrato con la chiave condivisa tra i due TGS e così il TGS remoto potrà autenticare il client fornendogli un Service Ticket, utile allo scambio con l’Application Server remoto

34

CrittografiaKerberos fa largo uso della crittografia nei Ticket scambiati tra le diverse entità coinvolte nell'autenticazione Per implementare lo scambio di messaggi tra AS, client e server, sono necessari tre elementi:

un algoritmo di crittografia forteuna funzione HASHuna funzione per il checksum dell’ Authenticator

Non ci sono limitazioni sulla lunghezza della password dell'utente, molti algoritmi di cifratura utilizzano una chiave a lunghezza fissa

35

Crittografia (2)Fino alla versione 4, l'unico algoritmo di crittografia supportato era il DES, a cui era associato l’uso di una funzione HASH ottenuta dal DES in una particolare modalità operativa e l'algoritmo CRC-32 per il calcolo dei checksumNella versione 5, non è stato fissato a priori il numero e il tipo di encryption da supportare, dipende dalla specifica implementazione e dalla piattaformaLa tecnica adottata nelle operazioni di cifratura è basata sulla funzione string2key

36

Crittografia (3)È stata introdotta la funzione string2key, che trasforma una password in chiaro in una encryption key, in base al tipo di crittografia, ed è una funzione hash irreversibile, cioè dall’encryption key non si può determinare la passwordViene richiamata quando un utente cambia la sua password o quando per autenticarsi si avvia una sessioneGli algoritmi disponibili sono:

DES e Triplo DES per la crittografiahmac e CRC32 per i chksumsha1, md5 e la funzione derivata da DES-CBC per l'hash

37

Crittografia (4)Di default il salt aveva un valore nullo, con in nuovo Kerberos v5, come valore di salt, si usa il principal dell’ utente:

Kclient=string2key ( Pclient + “[email protected]" )Kclient diventerà l'encryption key del client, dove Pclient è la password in chiaro, in tal modo si hanno i vantaggi:

due principal appartenenti allo stesso Realm ed aventi la stessa password in chiaro, hanno chiavi differentise un utente ha account su Realm diversi, è possibile che la password in chiaro coincida. Con l’uso del salt, si evita un'eventuale compromissione dello stato degli account

Un servizio condivide con il KDC una chiave e non una password

38

Crittografia (5)Alla stringa composta dalla concatenazione della password e del SALT, viene applicata una funzione HASH, così da rendere la trasformazione dipendente dalla macchinaQuesta flessibilità ed estensibilità del protocollo ha mostrato dei problemi di interoperabilità tra le varie implementazioni, poiché si può applicare una qualsiasi funzione Hash ed un qualsiasi algoritmo per i checksum, occorre stabilire un encryption type in comune

39

IntegrazioneLe Generic Security Service Application Programming Interface sono un framework che fornisce servizi di sicurezza alle applicazioniSono state sviluppate per creare un abstraction layer attraverso delle API standard per l'autenticazione in modo che ogni programma potesse implementare l'autenticazione astraendosi dal sistema di autenticazione sottostante L'implementazione più usata delle GSSAPI è quella relativa a Kerberos v5Ogni implementazione Kerberos v5 include un'implementazione GSSAPI

40

IntegrazioneIn Windows, sono definite le SSPI, ossia Microsoft Security Support Provider Interface, interfacce del tutto simili a quelle fornite da GSSAPI. Molti applicativi di Windows si riferiscono al supporto Kerberos come GSSAPI, ma usando le SSPI interni al sistema operativoIn Unix, il modello di security “abstraction layer” per implementare GSSAPI, è stato realizzato attraverso le SASL, Simple Authentication and Security Layer. Queste API sono state create e documentate nell'RFC 2222

Un esempio dell'uso delle SASL è un' implementazione di LDAP come meccanismo di autenticazione dei clients

41

Riferimenti

http://web.mit.edu/rhel-doc/3/rhel-rg-it-3/index.htmlhttp://web.mit.edu/kerberos/wwwhttp://en.wikipedia.org/wiki/Kerberoshttp://www.zeroshell.net/kerberos/

Kerberos v5 Presentazione dello studente Flavio Caroli per il corso di Griglie Computazionali prof....

Documents

Transcript of Kerberos v5 Presentazione dello studente Flavio Caroli per il corso di Griglie Computazionali prof....