Il protocollo Kerberos e le sue implementazioni

Una rappresentazione grafica di come funziona il protocollo:

Introduzione

Il protocollo Kerberos è progettato per fornire un’autenticazione affidabile su reti aperte e non sicure in cui le comunicazioni tra gli host ad esso appartenenti possono essere intercettate.

Tuttavia, si dovrebbe essere consapevoli del fatto che Kerberos non fornisce alcuna garanzia se i computer utilizzati sono vulnerabili:

i server di autenticazione, i server delle applicazioni (imap, pop, SMTP, telnet, ftp, ssh, AFS, lpr, …) e i client deve essere costantemente aggiornato in modo da garantire l’autenticità degli utenti e dei fornitori di servizi richiedenti.

I punti precedenti giustificano la frase: “Kerberos è un protocollo di autenticazione per host attendibili su reti non attendibili”.

A titolo di esempio e per ribadire il concetto: le strategie di Kerberos sono inutili se qualcuno che ottiene l’accesso privilegiato a un server, può copiare il file contenente la chiave segreta. In effetti, l’intruso inserirà questa chiave su un altro computer e dovrà solo ottenere un semplice indirizzo DNS o IP di spoofing affinché quel server appaia ai client come server autentico.

Obbiettivi

Prima di descrivere gli elementi che compongono il sistema di autenticazione Kerberos e osservarne il funzionamento, alcuni degli obiettivi che il protocollo desidera raggiungere sono elencati di seguito:

La password dell’utente non deve mai viaggiare sulla rete;

La password dell’utente non deve mai essere archiviata in nessuna forma sul computer client: deve essere immediatamente scartata dopo essere stata utilizzata;

La password dell’utente non deve mai essere archiviata in una forma non crittografata anche nel database del server di autenticazione;

All’utente viene chiesto di inserire una password una sola volta per sessione di lavoro.

Pertanto, gli utenti possono accedere in modo trasparente a tutti i servizi per i quali sono autorizzati senza dover reinserire la password durante questa sessione.

Questa caratteristica è nota come Single Sign-On;

La gestione delle informazioni di autenticazione è centralizzata e risiede sul server di autenticazione. I server delle applicazioni non devono contenere le informazioni di autenticazione per i loro utenti.

Questo è essenziale per ottenere i seguenti risultati:

L’amministratore può disabilitare l’account di qualsiasi utente agendo in un’unica posizione senza dover agire sui vari server delle applicazioni che forniscono i vari servizi;

Quando un utente cambia la sua password, viene cambiata per tutti i servizi contemporaneamente;

Non vi è ridondanza delle informazioni di autenticazione che altrimenti dovrebbero essere salvaguardate in vari luoghi;

Non solo gli utenti devono dimostrare di essere chi dicono, ma, quando richiesto, anche i server delle applicazioni devono dimostrare la loro autenticità al client.

Questa caratteristica è nota come autenticazione reciproca;

Dopo il completamento dell’autenticazione e dell’autorizzazione, il client e il server devono essere in grado di stabilire una connessione crittografata, se necessario.

A tale scopo, Kerberos fornisce supporto per la generazione e lo scambio di una chiave di crittografia da utilizzare per crittografare i dati.

Definizione dei Componenti e dei Termini

Questa sezione fornisce la definizione degli oggetti e dei termini, la cui conoscenza è essenziale per la successiva descrizione del protocollo Kerberos.

Poiché molte definizioni si basano su altre, per quanto possibile ho cercato di metterle in ordine in modo che il significato di un termine non sia dato prima di definirlo.

Tuttavia, potrebbe essere necessario leggere questa sezione due volte per comprendere appieno tutti i termini.

Realm

Il termine Realm indica un dominio amministrativo di autenticazione.

La sua intenzione è quella di stabilire i limiti entro i quali un server di autenticazione ha l’autorità per autenticare un utente, un host o un servizio.

Ciò non significa che l’autenticazione tra un utente e un servizio a cui devono appartenere allo stesso Realm: se i due oggetti fanno parte di Realm diversi e esiste una relazione di fiducia tra loro, allora può avvenire l’autenticazione.

Questa caratteristica, nota come Cross-Authentication, verrà descritta di seguito.

Fondamentalmente, un utente / servizio appartiene a un Realm se e solo se condivide un segreto (password / chiave) con il server di autenticazione di quel regno.

Il nome di un Realm  fa distinzione tra maiuscole e minuscole, cioè c’è una differenza tra lettere maiuscole e minuscole, ma normalmente i Realm appaiono sempre in lettere maiuscole.

È anche buona norma, in un’organizzazione, rendere il nome del dominio uguale al dominio DNS (in lettere maiuscole).

Seguire questi suggerimenti quando si seleziona il nome del Realm semplifica notevolmente la configurazione dei client Kerberos, soprattutto quando si desidera stabilire relazioni di fiducia con i sottodomini.

A titolo di esempio, se un’organizzazione appartiene al dominio DNS example.com, è opportuno che il dominio Kerberos correlato sia EXAMPLE.COM.

Principale

Un’entità è il nome utilizzato per fare riferimento alle voci nel database del server di autenticazione.

Un’entità è associata a ciascun utente, host o servizio di un determinato regno.

Un’entità in Kerberos 5 è del seguente tipo:

Component1 / Component2 /…/ componentn @ REALM

Tuttavia, in pratica vengono utilizzati al massimo due componenti.

Per una voce che fa riferimento a un utente, il principale è il seguente tipo:

Nome [/ istanza] @REALM

L’istanza è facoltativa e viene normalmente utilizzata per qualificare meglio il tipo di utente.

Ad esempio, gli utenti amministratori hanno normalmente l’istanza admin.

Di seguito sono riportati esempi di entità indirizzate agli utenti:

pippo@EXAMPLE.COM admin/admin@EXAMPLE.COM pluto/admin@EXAMPLE.COM

Se, invece, le voci si riferiscono a servizi, i direttori assumono la seguente forma:

Servizio / Hostname @ REALM

Il primo componente è il nome del servizio, ad esempio imap, AFS, ftp. Spesso è la parola host utilizzata per indicare l’accesso generico alla macchina (telnet, rsh, ssh).

Il secondo componente è il nome host completo (FQDN) della macchina che fornisce il servizio richiesto.

È importante che questo componente corrisponda esattamente (in lettere minuscole) alla risoluzione inversa DNS dell’indirizzo IP del server delle applicazioni.

I seguenti sono esempi validi di entità che si riferiscono ai servizi:

imap/mbox.example.com@EXAMPLE.COM

host/server.example.com@EXAMPLE.COM

afs/example.com@EXAMPLE.COM

Va notato che l’ultimo caso è un’eccezione perché il secondo componente non è un nome host ma il nome della cella AFS a cui fa riferimento il principale.

Infine, vi sono entità che non fanno riferimento a utenti o servizi ma svolgono un ruolo nel funzionamento del sistema di autenticazione.

Un esempio generale è krbtgt / REALM @ REALM con la relativa chiave utilizzata per crittografare il Ticket di concessione del biglietto (lo vedremo più avanti).

In Kerberos 4 non ci possono mai essere più di due componenti e sono separati dal carattere “.” invece di “/” mentre il nome host nelle entità che si riferisce ai servizi è quello breve, ovvero non il nome di dominio completo.

I seguenti sono esempi validi:

pippo@EXAMPLE.COM pluto.admin@EXAMPLE.COM imap.mbox@EXAMPLE.COM

Ticket

Un ticket è qualcosa che un client presenta a un server delle applicazioni per dimostrare l’autenticità della sua identità.

I biglietti vengono emessi dal server di autenticazione e vengono crittografati utilizzando la chiave segreta del servizio a cui sono destinati.

Poiché questa chiave è un segreto condiviso solo tra il server di autenticazione e il server che fornisce il servizio, nemmeno il client che ha richiesto il ticket può conoscerlo o modificarne il contenuto.

Le informazioni principali contenute in un biglietto includono:

Il principale dell’utente richiedente (generalmente il nome utente);

Il principale del servizio a cui è destinato;

L’indirizzo IP del computer client da cui è possibile utilizzare il ticket.

In Kerberos 5 questo campo è facoltativo e può anche essere multiplo per poter eseguire client in NAT o multihomed.

La data e l’ora (in formato data / ora) di inizio della validità dei biglietti;

La durata massima del biglietto

La chiave di sessione (questo ha un ruolo fondamentale che è descritto di seguito);

Ogni biglietto ha una scadenza (generalmente 10 ore).

Ciò è essenziale poiché il server di autenticazione non ha più alcun controllo su un ticket già emesso.

Anche se l’amministratore del Realm può impedire l’emissione di nuovi biglietti per un determinato utente in qualsiasi momento, non può impedire agli utenti di utilizzare i biglietti già in loro possesso.

Questo è il motivo per limitare la durata dei biglietti al fine di limitare eventuali abusi nel tempo.

I Ticket contengono molte altre informazioni e flag che caratterizzano il loro comportamento, ma non approfondiremo qui.

Discuteremo di nuovo ticket e flag  dopo aver visto come funziona il sistema di autenticazione.

Crittografia

Come puoi vedere, Kerberos spesso deve crittografare e de crittografare i messaggi (ticket e autenticatori) che passano tra i vari partecipanti all’autenticazione.

È importante notare che Kerberos utilizza solo la crittografia a chiave simmetrica (in altre parole la stessa chiave viene utilizzata per crittografare e de crittografare).

Alcuni progetti (ad es. Pkinit) sono attivi per introdurre un sistema di chiavi pubbliche al fine di ottenere l’autenticazione iniziale dell’utente attraverso la presentazione di una chiave privata corrispondente a una chiave pubblica certificata, ma poiché non esiste uno standard, per ora salteremo questa discussione.

Tipo di Crittografia

Kerberos 4 implementa un singolo tipo di crittografia che è DES a 56 bit. La debolezza di questa crittografia e altre vulnerabilità del protocollo hanno reso obsoleto Kerberos 4.

La versione 5 di Kerberos, tuttavia, non predetermina il numero o il tipo di metodologie di crittografia supportate.

È compito di ogni specifica implementazione supportare e negoziare al meglio i vari tipi di crittografia.

Tuttavia, questa flessibilità ed espandibilità del protocollo ha accentuato i problemi di interoperabilità tra le varie implementazioni di Kerberos 5.

Affinché i client e i server delle applicazioni e di autenticazione utilizzino diverse implementazioni per interagire, devono avere almeno un tipo di crittografia in comune.

La difficoltà relativa all’interoperabilità tra le implementazioni Unix di Kerberos 5 e quella presente in Active Directory di Windows ne è un classico esempio.

Infatti, Windows Active Directory supporta un numero limitato di crittografie e aveva solo DES a 56 bit in comune con Unix.

Ciò ha richiesto il mantenimento di quest’ultimo abilitato, nonostante i rischi siano ben noti, se fosse necessario garantire l’interoperabilità.

Il problema è stato successivamente risolto con la versione 1.3 di MIT Kerberos 5.

Questa versione ha introdotto il supporto RC4-HMAC, che è presente anche in Windows ed è più sicuro di DES.

Tra le crittografie supportate (ma non da Windows) vale la pena menzionare il triplo DES (3DES) e le più recenti AES128 e AES256.

Chiave di Crittografia

Come indicato sopra, uno degli obiettivi del protocollo Kerberos è impedire la memorizzazione della password dell’utente nella sua forma non crittografata, anche nel database del server di autenticazione.

Considerando che ogni algoritmo di crittografia utilizza la propria lunghezza della chiave, è chiaro che, se l’utente non deve essere costretto a utilizzare una password diversa di una dimensione fissa per ciascun metodo di crittografia supportato, le chiavi di crittografia non possono essere le password.

Per questi motivi è stata introdotta la funzione string2key, che trasforma una password non crittografata in una chiave di crittografia adatta al tipo di crittografia da utilizzare.

Questa funzione viene chiamata ogni volta che un utente cambia la password o la inserisce per l’autenticazione.

String2key è chiamata funzione hash, il che significa che è irreversibile: dato che una chiave di crittografia non può determinare la password che l’ha generata (se non con la forza bruta).

I famosi algoritmi di hashing sono MD5 e CRC32.

Salt

In Kerberos 5, a differenza della versione 4, è stato introdotto il concetto di password salt.

Questa è una stringa da concatenare alla password non crittografata prima di applicare la funzione string2key per ottenere la chiave.

Kerberos 5 utilizza lo stesso principio dell’utente come salt:

Kpippo = string2key (Ppippo + “pippo@EXAMPLE.COM”)

Kpippo è la chiave di crittografia

Questo tipo di Salt presenta i seguenti vantaggi:

Due entità appartenenti allo stesso regno e con la stessa password non crittografata hanno ancora chiavi diverse.

Ad esempio, immagina un amministratore con un responsabile per il lavoro quotidiano (pippo@EXAMPLE.COM) e uno per il lavoro amministrativo (pippo/admin@EXAMPLE.COM).

È molto probabile che questo utente abbia impostato la stessa password per entrambi i principali per motivi di praticità.

La presenza del salt garantisce che le relative chiavi siano diverse.

Se un utente ha due account in diversi regni, è abbastanza frequente che la password non crittografata sia la stessa per entrambi i regni:

grazie alla presenza del salt, un possibile compromesso di un account in un regno, non causerà automaticamente l’altro a essere compromesso.

Un salt null può essere configurato per la compatibilità con Kerberos 4.

Viceversa, per la compatibilità con AFS, è possibile configurare un salt che non è il nome completo dell’entità, ma semplicemente il nome della cella.

Dopo aver discusso i concetti di tipo di crittografia, string2key e salt, è possibile verificare l’accuratezza della seguente osservazione:

per garantire l’interoperabilità tra le varie implementazioni Kerberos, non è sufficiente negoziare un tipo comune di crittografia, ma il devono essere usati anche gli stessi tipi di string2key e salt.

È anche importante notare che, nello spiegare i concetti di string2key e salt, si è fatto riferimento solo ai principali dell’utente e mai a quelli dei server.

Il motivo è chiaro: un servizio, anche se condivide un segreto con il server di autenticazione, non è una password non crittografata (chi l’avrebbe inserito?),.

Ma una chiave che, una volta generata dall’amministratore sul server Kerberos, viene memorizzata come è sul server che fornisce il servizio.

Kvno Numero versione chiave

Quando un utente cambia una password o un amministratore aggiorna la chiave segreta per un server delle applicazioni, questa modifica viene registrata facendo avanzare un contatore.

Il valore corrente del contatore che identifica la versione della chiave, è noto come il numero di versione della chiave o più brevemente kvno.

Kdc Centro distruzione Chiavi

Abbiamo parlato genericamente del server di autenticazione.

Poiché è l’oggetto fondamentale coinvolto nell’autenticazione di utenti e servizi, ora esamineremo in modo più approfondito senza entrare in tutti i dettagli del suo funzionamento, che sono invece l’argomento della sezione dedicata al funzionamento del protocollo.

Il server di autenticazione in un ambiente Kerberos, basato sulla sua funzione di distribuzione dei ticket per l’accesso ai servizi, è chiamato Key Distribution Center o più brevemente KDC.

Poiché risiede interamente su un singolo server fisico (spesso coincide con un singolo processo) può essere logicamente considerato diviso in tre parti:

Database, Authentication Server (AS) e Ticket Granting Server (TGS). Diamo una breve occhiata a loro.

Nota: è possibile rendere il server ridondante all’interno del Realm in una struttura Master / Slave (MIT e Heimdal) o Multi master (Windows Active Directory).

Come ottenere la ridondanza non è descritto dal protocollo, ma dipende dall’implementazione utilizzata e non verrà discusso qui.

Database

Il database è il contenitore per le voci associate a utenti e servizi.

Ci riferiamo ad una voce usando il principale (cioè il nome della voce) anche se spesso il termine principale è usato come sinonimo di voce.

Ogni voce contiene le seguenti informazioni:

Il principale a cui è associata la voce;

La chiave di crittografia e relativo kvno;

La durata massima di validità per un biglietto associato al principale;

Il tempo massimo di rinnovo di un biglietto associato al principale (solo Kerberos 5);

Gli attributi o i flag che caratterizzano il comportamento dei biglietti;

La data di scadenza della password;

La data di scadenza del principale, dopo la quale non saranno emessi biglietti.

Per rendere più difficile il furto delle chiavi presenti nel database, le implementazioni crittografano il database usando la chiave master, che è associata al principale K / M @ REALM.

Anche qualsiasi dump di database, usato come backup o per la propagazione dal master KDC verso lo slave, viene crittografato usando questa chiave, che è necessario conoscere per ricaricarli.

Authentication Server (AS)

Il server di autenticazione è la parte del KDC che risponde alla richiesta di autenticazione iniziale dal client, quando l’utente, non ancora autenticato, deve inserire la password.

In risposta a una richiesta di autenticazione, l’AS emette un biglietto speciale noto come Ticket Granting Ticket, o più brevemente TGT, il principale associato al quale è krbtgt / REALM @ REALM.

Se gli utenti sono effettivamente chi dicono di essere (e vedremo in seguito come lo dimostrano) possono utilizzare il TGT per ottenere altri ticket di servizio, senza dover reinserire la password.

Ticket Granting Server (TGS)

Ticket Granting Server è il componente KDC che distribuisce i ticket di servizio ai client con un TGT valido, garantendo l’autenticità dell’identità per ottenere la risorsa richiesta sui server delle applicazioni.

Il TGS può essere considerato come un server delle applicazioni (dato che per accedervi è necessario presentare il TGT) che fornisce l’emissione dei ticket di servizio come servizio.

È importante non confondere le abbreviazioni TGT e TGS: il primo indica un biglietto e il secondo un servizio.

Chiave di sessione

Come abbiamo visto, gli utenti e i servizi condividono un segreto con il KDC.

Per gli utenti, questo segreto è la chiave derivata dalla loro password, mentre per i servizi è la loro chiave segreta (impostata dall’amministratore).

Queste chiavi sono chiamate a lungo termine, poiché non cambiano quando cambia la sessione di lavoro.

Tuttavia, è necessario che l’utente condivida anche un segreto con il servizio, almeno per il momento in cui un client ha una sessione di lavoro aperta su un server:

questa chiave, generata dal KDC quando viene emesso un ticket, viene chiamata Chiave di sessione.

La copia destinata al servizio è racchiusa dal KDC nel ticket (in ogni caso il loro server delle applicazioni conosce la chiave a lungo termine e può decodificarla ed estrarre la chiave di sessione), mentre la copia destinata all’utente è incapsulata in un pacchetto crittografato con la chiave a lungo termine dell’utente.

La chiave di sessione svolge un ruolo fondamentale nella dimostrazione dell’autenticità dell’utente che vedremo nel paragrafo seguente.

Autenticatore

Anche se l’entità utente è presente in un ticket e solo il server delle applicazioni può estrarre e possibilmente gestire tali informazioni (poiché il ticket è crittografato con la chiave segreta del servizio), ciò non è sufficiente per garantire l’autenticità del client.

Un impostore potrebbe catturare (ricordare l’ipotesi di una rete aperta e insicura?) il ticket quando viene inviato da un client legittimo al server delle applicazioni e, in un momento opportuno, inviarlo per ottenere il servizio illegittimamente.

D’altra parte, compresi gli indirizzi IP della macchina da cui è possibile utilizzarlo non è molto utile: è noto che in una rete aperta e insicura gli indirizzi sono facilmente falsificati.

Per risolvere il problema, è necessario sfruttare il fatto che client e server, almeno durante una sessione, hanno in comune la chiave di sessione che solo loro conoscono (anche il KDC lo conosce da quando lo ha generato, ma è attendibile per definizione! !!).

Pertanto, viene applicata la seguente strategia:

insieme alla richiesta contenente il ticket, il client aggiunge un altro pacchetto (l’autenticatore) in cui sono inclusi l’entità utente e il timestamp (in quel momento) e lo crittografa con la chiave di sessione.

il server che deve offrire il servizio, una volta ricevuta questa richiesta, decomprime il primo ticket, estrae la chiave di sessione e, se l’utente è effettivamente chi dice, il server è in grado di decodificare l’autenticatore che estrae il timestamp.

Se quest’ultimo differisce dal tempo del server per meno di 2 minuti (ma è possibile configurare la tolleranza), l’autenticazione ha esito positivo.

Ciò sottolinea la criticità della sincronizzazione tra macchine appartenenti allo stesso Realm.

Replay Cache

Esiste la possibilità per un impostore di rubare contemporaneamente sia il ticket che l’autenticatore e utilizzarli durante i 2 minuti in cui l’autenticatore è valido.

Questo è molto difficile ma non impossibile.

Per risolvere questo problema con Kerberos 5, è stata introdotta Replay Cache.

Nei server delle applicazioni (ma anche in TGS) esiste la capacità di ricordare gli autenticatori arrivati ​​negli ultimi 2 minuti e di rifiutarli se sono repliche.

Con questo il problema viene risolto fintanto che l’impostore non è abbastanza intelligente da copiare il ticket e l’autenticatore e farli arrivare al server delle applicazioni prima che arrivi la richiesta legittima.

Questo sarebbe davvero uno scherzo, poiché l’utente autentico verrebbe rifiutato mentre l’impostore avrebbe accesso al servizio.

Cache delle credenziali

Il client non conserva mai la password dell’utente, né memorizza la chiave segreta ottenuta applicando string2key:

vengono utilizzati per de crittografare le risposte da KDC e immediatamente scartati.

Tuttavia, per implementare la caratteristica Single Sign-On (SSO), in cui all’utente viene richiesto di inserire la password una sola volta per sessione di lavoro, è necessario memorizzare i ticket e la relativa chiave di sessione.

Il luogo in cui sono archiviati questi dati è chiamato “Credential Cache”.

La posizione della cache non dipende dal protocollo, ma varia da un’implementazione all’altra.

Spesso ai fini della portabilità si trovano nel filesystem (MIT e Heimdal).

In altre implementazioni (AFS e Active Directory), al fine di aumentare la sicurezza in caso di client vulnerabili, la cache delle credenziali viene collocata in un’area della memoria accessibile solo ai kernel e non scambiabile sul disco.

Operazione Kerberos

Infine, dopo aver acquisito i concetti descritti nei paragrafi precedenti, è possibile discutere su come opera Kerberos.

Lo faremo elencando e descrivendo ciascuno dei pacchetti che vanno tra il client e KDC e tra client e application server durante l’autenticazione.

A questo punto, è importante sottolineare che un server delle applicazioni non comunica mai direttamente con il Key Distribution Center:

I ticket di servizio, anche se confezionati da TGS, raggiungono il servizio solo attraverso il client che desidera accedervi.

I messaggi che discuteremo sono elencati di seguito:

AS_REQ è la richiesta di autenticazione dell’utente iniziale (ovvero fatta con kinit) Questo messaggio è diretto al componente KDC noto come Authentication Server (AS);

AS_REP è la risposta del server di autenticazione alla richiesta precedente. Fondamentalmente contiene il TGT (crittografato utilizzando la chiave segreta TGS) e la chiave di sessione (crittografata utilizzando la chiave segreta dell’utente richiedente);

TGS_REQ è la richiesta dal client al Ticket Granting Server (TGS) per un ticket di servizio. Questo pacchetto include il TGT ottenuto dal messaggio precedente e un autenticatore generato dal client e crittografato con la chiave di sessione;

TGS_REP è la risposta del Ticket Granting Server alla richiesta precedente.

All’interno si trovano il ticket di servizio richiesto (crittografato con la chiave segreta del servizio) e una chiave di sessione di servizio generata da TGS e crittografata utilizzando la chiave di sessione precedente generata dall’AS;

AP_REQ è la richiesta che il client invia a un server delle applicazioni per accedere a un servizio.

I componenti sono il ticket di servizio ottenuto da TGS con la risposta precedente e un autenticatore nuovamente generato dal client, ma questa volta crittografato utilizzando la chiave di sessione di servizio (generata da TGS);

AP_REP è la risposta che il server delle applicazioni fornisce al client per dimostrare che è davvero il server che il client si aspetta.

Questo pacchetto non è sempre richiesto.

Il client richiede il server solo quando è necessaria l’autenticazione reciproca.

Ora ciascuna delle fasi precedenti è stata descritta in maggior dettaglio con riferimento a Kerberos 5, ma sottolineando le differenze con la versione 4.

Tuttavia, va tenuto presente che il protocollo Kerberos è piuttosto complicato e questo documento non è inteso come guida per coloro che desiderano conoscere i dettagli operativi esatti (in ogni caso, questi sono già scritti in RFC1510).

La discussione di seguito è stata lasciata intenzionalmente astratta, ma sufficiente per coloro che esaminano i registri KDC per comprendere le varie transizioni di autenticazione e gli eventuali problemi che si verificano.

Nota: i paragrafi successivi racchiudono i dati non crittografati tra parentesi tonde () e i dati crittografati tra parentesi graffe {}: (x, y, z) indicano che x, y, z non sono crittografati; {x, y, z} K indica che x, y, z sono crittografati tutti insieme utilizzando la chiave simmetrica K.

È anche importante notare che l’ordine in cui i componenti sono elencati in un pacchetto non ha nulla a che fare con il reale ordine trovato nei messaggi effettivi (UDP o TCP).

 

Richiesta del server di autenticazione (AS_REQ)

In questa fase, nota come richiesta di autenticazione iniziale, il client (kinit) richiede al KDC (più specificamente l’AS) un Ticket di concessione del biglietto.

La richiesta è completamente non crittografata e si presenta così:

AS_REQ = (PrincipalClient, PrincipalService, IP_list, Lifetime)

dove: PrincipalClient è il principale associato all’utente che cerca l’autenticazione (ad esempio pippo@EXAMPLE.COM);

PrincipalService è il principale associato al servizio richiesto dal ticket e quindi è la stringa “krbtgt / REALM @ REALM” (vedi nota *); IP_list è un elenco di indirizzi IP che indicano l’host dove è possibile utilizzare il ticket che verrà emesso (vedi nota **);

La durata è il tempo di validità massimo (richiesto) per l’emissione del biglietto.

Nota *: può sembrare superfluo aggiungere il Servizio principale alla richiesta di autenticazione iniziale poiché questa verrebbe costantemente impostata sul principale TGS, ad esempio krbtgt / REALM @ REALM.

Tuttavia, questo non è il caso, anzi, un utente che intende utilizzare solo un servizio durante una sessione di lavoro, non utilizzerà il Single Sign-on e potrebbe richiedere direttamente al AS il ticket per questo servizio, saltando così la richiesta successiva al TGS.

Dal punto di vista operativo (MIT 1.3.6) è sufficiente il comando seguente: kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM

Nota **: IP_list può anche essere nullo. In questo caso il biglietto corrispondente può essere utilizzato da qualsiasi macchina.

Ciò risolve il problema di quei client in NAT, poiché la loro richiesta sarebbe arrivata al servizio con un indirizzo di origine diverso da quello dell’utente richiedente, ma lo stesso del router che creava il NAT.

Invece, nel caso di macchine con più di una scheda di rete, IP_list dovrebbe contenere gli indirizzi IP di tutte le schede:

infatti sarebbe difficile prevedere in anticipo con quale connessione verrebbe contattato il server che fornisce il servizio.

Risposta del server di autenticazione (AS_REP)

Quando arriva la richiesta precedente, l’AS verifica se PrincipalClient e PrincipalService esistono nel database KDC: se almeno uno dei due non esiste un messaggio di errore viene inviato al client, altrimenti il ​​server di autenticazione elabora la risposta come segue:

Crea in modo casuale una chiave di sessione che sarà il segreto condiviso tra il client e il TGS. Diciamo SKTGS;

Crea il Ticket Granting Ticket inserendolo nel principal dell’utente richiedente, il principal del servizio (generalmente krbtgt / REALM @ REALM, ma leggi la nota * per il paragrafo precedente), l’elenco degli indirizzi IP (queste prime tre informazioni sono copiati all’arrivo dal pacchetto AS_REQ), data e ora (del KDC) nel formato timestamp, durata (vedi nota *) e infine la chiave di sessione. SKTGS; il biglietto che assegna il biglietto appare quindi come segue:

TGT = (PrincipalClient, krbtgt / REALM @ REALM, IP_list, Timestamp, Lifetime, SKTGS)

Genera e invia la risposta contenente: il ticket creato in precedenza, crittografato utilizzando la chiave segreta per il servizio (chiamiamolo KTGS); l’entità servizio, il timestamp, la durata e la chiave di sessione sono tutti crittografati utilizzando la chiave segreta per l’utente che richiede il servizio (chiamiamolo KUser). In sintesi:

AS_REP = {PrincipalService, Timestamp, Lifetime, SKTGS} KUser {TGT} KTGS

Può sembrare che questo messaggio contenga informazioni ridondanti (PrincipalService, data / ora, chiave di durata e sessione).

Ma non è così: poiché le informazioni presenti nel TGT sono crittografate utilizzando la chiave segreta per il server, non possono essere lette dal client e devono essere ripetute.

A questo punto, quando il client riceve il messaggio di risposta, chiederà all’utente di inserire la password.

Il salt viene concatenato con la password e quindi viene applicata la funzione string2key: con la chiave risultante si tenta di de crittografare la parte del messaggio crittografata dal KDC utilizzando la chiave segreta dell’utente memorizzata nel database.

Se l’utente è veramente ciò che dice e ha quindi inserito la password corretta, l’operazione di decodifica avrà esito positivo e quindi la chiave di sessione può essere estratta e con il TGT (che rimane crittografato) memorizzato nella cache delle credenziali dell’utente.

Nota *: la durata effettiva, ovvero quella inserita nel ticket è il più basso dei seguenti valori: la durata richiesta dal cliente, quella contenuta nel principale dell’utente e quella nel principale del servizio. I

n realtà in termini di implementazione un altro limite può essere impostato dalla configurazione del KDC e applicato a qualsiasi ticket.

Richiesta server di concessione ticket (TGS_REQ)

A questo punto, l’utente che ha già dimostrato di essere quello che dice (quindi nella sua cache delle credenziali c’è un TGT e la chiave di sessione SKTGS e vuole accedere al servizio ma non ha ancora un biglietto adatto, invia un richiedere (TGS_REQ) al Ticket Granting Service costruendolo come segue:

Crea un autenticatore con l’entità utente, il timestamp della macchina client e crittografa tutto con la chiave di sessione condivisa con TGS, ad es .:

Authenticator = {PrincipalClient, Timestamp} SKTGS

Creare un pacchetto di richiesta contenente: l’entità servizio per cui è necessario il ticket e non crittografato a vita; il Ticket Granting Ticket che è già crittografato con la chiave del TGS; e l’autenticatore appena creato. In sintesi:

TGS_REQ = (PrincipalService, Lifetime, Authenticator) {TGT} KTGS

Riproduzione server di concessione ticket (TGS_REP)

Quando arriva la richiesta precedente, il TGS verifica innanzitutto che il principale del servizio richiesto (PrincipalService) esista nel database KDC: se esiste, apre il TGT usando la chiave per krbtgt / REAM @ REALM ed estrae la chiave di sessione (SKTGS ) che utilizza per de crittografare l’autenticatore. Per l’emissione del biglietto di servizio verifica che le seguenti condizioni abbiano esito positivo:

il TGT non è scaduto;

Il PrincipalClient presente nell’autenticatore corrisponde a quello presente nel TGT;

L’autenticatore non è presente nella cache di riproduzione e non è scaduto;

Se IP_list non è null verifica che l’indirizzo IP di origine del pacchetto di richiesta (TGS_REQ) sia uno di quelli contenuti nell’elenco;

Le condizioni precedentemente verificate dimostrano che il TGT appartiene davvero all’utente che ha effettuato la richiesta e quindi il TGS inizia a elaborare la risposta come segue:

Crea in modo casuale una chiave di sessione che sarà il segreto condiviso tra il client e il servizio. Diciamo SKService;

Crea il ticket di servizio, inserendo il principal dell’utente richiedente, il principal di servizio, l’elenco di indirizzi IP, la data e l’ora (del KDC) in formato timestamp, la durata (come minimo tra la durata del TGT e quella associato all’entità servizio) e infine alla chiave di sessione SKService.

Conosciuto come TService il nuovo biglietto è:

TService = (PrincipalClient, PrincipalService, IP_list, Timestamp, Lifetime, SKService)

Invia il messaggio di risposta contenente: il ticket precedentemente creato, crittografato utilizzando la chiave segreta del servizio (chiamiamolo KService); l’entità servizio, il timestamp, la durata e la nuova chiave di sessione sono tutti crittografati utilizzando la chiave di sessione estratta da TGT. In sintesi:

TGS_REP = {PrincipalService, Timestamp, Lifetime, SKService} SKTGS {TService} KService

Quando il client riceve la risposta, avendo nella cache delle credenziali la chiave di sessione SKTGS, può de crittografare la parte del messaggio contenente l’altra chiave di sessione e memorizzarla insieme al ticket di servizio TService che, tuttavia, rimane crittografato.

Richiesta applicazione (AP_REQ)

Il client, che dispone delle credenziali per accedere al servizio (ovvero il ticket e la relativa chiave di sessione), può richiedere al server delle applicazioni l’accesso alla risorsa tramite un messaggio AP_REQ.

Va tenuto presente che, a differenza dei messaggi precedenti in cui era coinvolto il KDC, AP_REQ non è standard, ma varia a seconda dell’applicazione.

Pertanto, il programmatore dell’applicazione ha il compito di stabilire la strategia con cui il client utilizzerà le proprie credenziali per dimostrare la propria identità al server.

Tuttavia, possiamo considerare la seguente strategia a titolo di esempio:

Il client crea un autenticatore contenente l’utente principale e il timestamp e crittografa tutto con la chiave di sessione SKService che condivide con il server delle applicazioni, ad es .:

Authenticator = {PrincipalClient, Timestamp} SKService

Crea un pacchetto di richiesta contenente il ticket di servizio TService che è crittografato con la sua chiave segreta e l’autenticatore appena creato.

In sintesi:

AP_REQ = Authenticator {TService} KService

Quando arriva la richiesta precedente, il server delle applicazioni apre il ticket utilizzando la chiave segreta per il servizio richiesto ed estrae la chiave di sessione SKService che utilizza per de crittografare l’autenticatore.

Per stabilire che l’utente richiedente è autentico e quindi concedere l’accesso al servizio, il server verifica le seguenti condizioni:

    il biglietto non è scaduto;

    Il client principale presente nell’autenticatore corrisponde a quello presente nel ticket;

    L’autenticatore non è presente nella cache di riproduzione e non è scaduto;

    Se IP_list (estratto dal ticket) non è null, verifica che l’indirizzo IP di origine del pacchetto di richiesta (AP_REQ) sia uno di quelli contenuti nell’elenco;

Nota: la strategia precedente è molto simile a quella utilizzata dal Ticket Granting Server per verificare l’autenticità dell’utente che richiede un ticket di servizio.

Ma ciò non dovrebbe sorprendere, poiché abbiamo già spiegato che il TGS può essere considerato come un server delle applicazioni il cui servizio è quello di fornire i biglietti a coloro che dimostrano la propria identità con un TGT.

Pre-autenticazione

Come visto nella descrizione della risposta del server di autenticazione (AS_REP), prima di distribuire un ticket il KDC verifica semplicemente che nel database siano presenti il ​​principale dell’utente richiedente e il fornitore di servizi.

Quindi, in particolare se si tratta di una richiesta di un TGT, è ancora più semplice, perché sicuramente esiste krbtgt / REALM @ REALM e quindi è sufficiente sapere che esiste un utente principale per poter ottenere un TGT con una semplice richiesta di autenticazione iniziale.

Ovviamente, questo TGT, se la richiesta proviene da un utente illegittimo, non può essere utilizzato perché non conoscono la password e non possono ottenere la chiave di sessione per la creazione di un autenticatore valido.

Tuttavia, questo biglietto, ottenuto in modo così semplice, può subire un attacco a forza bruta nel tentativo di indovinare la chiave a lungo termine per il servizio a cui è destinato il biglietto.

Ovviamente, indovinare il segreto di un servizio non è una cosa facile nemmeno con le attuali capacità di elaborazione, tuttavia, con Kerberos 5, è stato introdotto un concetto di pre-autenticazione per rafforzare la sicurezza.

Pertanto, se i criteri KDC (configurabili) richiedono la pre-autenticazione per una richiesta client iniziale, il server di autenticazione risponde con un pacchetto di errori che indica la necessità di pre-autenticare. Il client, alla luce dell’errore, chiede all’utente di inserire la password e inviare nuovamente la richiesta, ma questa volta aggiungendo il timestamp crittografato con la chiave a lungo termine dell’utente, che, come sappiamo, si ottiene applicando string2key alla password non crittografata dopo aver aggiunto il salt, se ce n’è uno.

Questa volta, il KDC, poiché conosce la chiave segreta dell’utente, tenta di de crittografare il timestamp presente nella richiesta e se ha esito positivo e il timestamp è in linea, ovvero incluso nella tolleranza stabilita, decide che l’utente richiedente è autentico e il processo di autenticazione continua normalmente.

È importante notare che la pre-autenticazione è una politica KDC e quindi il protocollo non la richiede necessariamente. In termini di implementazione, MIT Kerberos 5 e Heimdal hanno la pre-autenticazione disabilitata per impostazione predefinita, mentre Kerberos in Windows Active Directory e il kaserver AFS (che è un Kerberos 4 pre-autenticato) lo richiedono.

Ticket in ulteriore dettaglio

Come accennato in precedenza, ora che sono state discusse le operazioni del KDC e i messaggi tra gli host coinvolti nell’autenticazione, ora possiamo passare ai ticket.

Questi, a seconda che abbiano attributi (chiamati anche flag) impostati al loro interno, si comportano in un certo modo.

Di seguito ho elencato i tipi di ticket più importanti e, anche se non completamente corretto, dato che sto parlando di un protocollo, farò riferimento (quanto basta per chiarire le cose) alla versione 1.3.6 di MIT Kerberos 5.

Ticket iniziali

Un ticket iniziale è ciò che viene ottenuto direttamente da AS, ovvero quando gli utenti devono autenticarsi inserendo la password.

Da qui, si può dedurre che il TGT è sempre un biglietto iniziale.

D’altra parte, i biglietti di servizio sono distribuiti dal TGS su presentazione di un TGT e quindi non sono biglietti iniziali.

Tuttavia, esiste un’eccezione a questa regola: al fine di garantire che l’utente abbia inserito la password solo pochi secondi prima, alcune applicazioni Kerberos potrebbero richiedere che il ticket di servizio sia iniziale; in questo caso il biglietto, nonostante non sia un TGT, viene richiesto dall’AS anziché dal TGS ed è quindi un biglietto iniziale.

In termini operativi, l’utente pippo, desiderando ottenere un ticket iniziale (quindi senza utilizzare il TGT) per un servizio imap sulla macchina mbox.example.com utilizza il comando:

[pippo @ client01 pippo] $ kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM

Password per pippo@EXAMPLE.COM:

[pippo @ client01 pippo] $

[pippo @ client01 pippo] $ klist -f

Cache ticket: FILE: / tmp / krb5cc_500

Principale predefinito: pippo@EXAMPLE.COM

L’avvio valido scade l’entità servizio

27/01/05 14:28:59 28/01/05 14:28:39 imap/mbox.example.com@EXAMPLE.COM

Flag: I

Cache ticket Kerberos 4: / tmp / tkt500

klist: non hai biglietti memorizzati nella cache

Dovrei notare la presenza dell flag, indicando che si tratta di un Ticket iniziale.

Ticket rinnovabili

Un ticket rinnovabile può essere inviato nuovamente al KDC per il rinnovo, ovvero viene riassegnato per tutta la vita.

Ovviamente, il KDC rispetterà la richiesta di rinnovo solo se il biglietto non è ancora scaduto e non ha superato il tempo massimo di rinnovo (impostato nel database del Key Distribution Center).

Essere in grado di rinnovare un biglietto combina la necessità di avere biglietti di breve durata per motivi di sicurezza, senza dover reinserire la password per lunghi periodi: ad esempio, immaginare un lavoro che deve essere elaborato per giorni e non deve richiedere alcun intervento umano.

Nell’esempio seguente pippo richiede un biglietto che dura al massimo un’ora ma è rinnovabile per 8 giorni:

kinit -l 1h -r 8d pippo

Password per pippo@EXAMPLE.COM:

[pippo @ client01 pippo] $

[pippo @ client01 pippo] $ klist -f

Cache ticket: FILE: / tmp / krb5cc_500

Principale predefinito: pippo@EXAMPLE.COM

L’avvio valido scade l’entità servizio

27/01/05 15:35:14 27/01/05 16:34:54 krbtgt/EXAMPLE.COM@EXAMPLE.COM

rinnovare fino al 02/03/05 15:35:14, flag: RI

Cache ticket Kerberos 4: / tmp / tkt500

klist: non hai biglietti memorizzati nella cache

mentre per pippo a rinnovare il suo biglietto senza reinserire la password:

[pippo @ client01 pippo] $ kinit -R

[pippo @ client01 pippo] $

[pippo @ client01 pippo] $ klist -f

Cache ticket: FILE: / tmp / krb5cc_500

Principale predefinito: pippo@EXAMPLE.COM

L’avvio valido scade l’entità servizio

27/01/05 15:47:52 27/01/05 16:47:32 krbtgt/EXAMPLE.COM@EXAMPLE.COM

rinnovare fino al 02/03/05 15:35:14, flag: RIT

Cache ticket Kerberos 4: / tmp / tkt500

klist: non hai biglietti memorizzati nella cache

Ticket trasferibili

Supponiamo di avere una sessione di lavoro su una macchina con il relativo TGT e desideriamo accedere da essa su un’altra macchina, mantenendo il ticket.

I ticket trasferibili sono la soluzione a questo problema.

Un ticket inoltrato da un host a un altro è di per sé inoltrabile, quindi una volta autenticato è possibile accedere al login su tutte le macchine desiderate senza dover reinserire alcuna password.

Per ottenere lo stesso risultato senza Kerberos, sarebbe necessario utilizzare metodi molto meno sicuri come rsh o autenticazione con chiave pubblica con ssh.

Tuttavia, quest’ultimo metodo potrebbe essere impraticabile su sistemi in cui le directory home dell’utente si trovano su filesystem di rete (ad esempio NFS o AFS) poiché la chiave privata (che dovrebbe essere privata) passerebbe attraverso la rete.

Cross Authentication

Abbiamo già menzionato la possibilità per un utente appartenente a un determinato regno di autenticare e accedere ai servizi di un altro regno.

Questa caratteristica nota come autenticazione incrociata si basa sul presupposto che esiste una relazione di fiducia tra i regni coinvolti.

Questo può essere monodirezionale, nel senso che gli utenti del regno A possono accedere ai servizi del regno B ma non viceversa, o bidirezionale, dove, come ci si potrebbe aspettare, è anche possibile il contrario.

Nei paragrafi seguenti esamineremo l’autenticazione incrociata, suddividendo le relazioni di fiducia in dirette, transitive e gerarchiche.

Rapporti di fiducia diretti

Questo tipo di relazione di trust è elementare ed è la base dell’autenticazione incrociata e viene utilizzata per costruire gli altri due tipi di relazioni che vedremo più avanti.

Si verifica quando il KDC del regno B ha una fiducia diretta nel KDC del regno A, consentendo così agli utenti di quest’ultimo dominio di accedere alle sue risorse.

Da un punto di vista pratico, si ottiene una relazione di fiducia diretta facendo in modo che i due KDC coinvolti condividano una chiave (le chiavi diventano due se si desidera una fiducia bidirezionale).

Per fare ciò viene introdotto il concetto di Ticket di concessione ticket remoto che, nell’esempio dei due regni A e B, assume la forma krbtgt / B @ A e viene aggiunto a entrambi i KDC con la stessa chiave.

Questa chiave è il segreto che garantirà la fiducia tra i due regni.

Ovviamente, per renderlo bidirezionale (ovvero che A si fida anche di B), è necessario creare il TGT remoto krbtgt / A @ B in entrambi i KDC, associandoli a un’altra chiave segreta.

Come vedremo tra poco nel seguente esempio, l’introduzione dei TGT remoti rende l’autenticazione incrociata una generalizzazione naturale della normale autenticazione intra-realm: questo sottolinea che la precedente descrizione dell’operazione Kerberos continua ad essere valida finché si accetta che il TGS di un reame può validare i TGT remoti emessi dal TGS di un altro.

Si noti l’anomalia formale che si verifica quando i TGT remoti non vengono emessi dall’AS, come accade per quelli locali, ma dal Ticket Granting Server locale su presentazione del TGT locale.

Ora diamo un’occhiata a un esempio per chiarire tutto questo.

Supponiamo che l’utente pippo del regno EXAMPLE.COM, il cui principale associato sia pippo@EXAMPLE.COM, desideri accedere al server pluto.test.com appartenente al regno TEST.COM, tramite ssh:

Se Pippo non ha già un TGT nel regno EXAMPLE.COM, effettua una richiesta di autenticazione iniziale (kinit).

Ovviamente, la risposta arriva dall’AS del suo regno;

Dà il comando ssh pippo@pluto.test.com che dovrebbe aprire la shell remota su pluto.test.com senza dover reinserire la password;

il client ssh fa due query al DNS: elabora l’IP di pluto.test.com e sull’indirizzo appena ottenuto esegue il contrario per ottenere il nome host (FQDN) in forma canonica (in questo caso coincide con pluto.test.com);

ssh client si rende quindi conto, grazie al risultato precedente, che la destinazione non appartiene al regno dell’utente e quindi chiede al TGS del regno EXAMPLE.COM (si noti che chiede al TGS del suo regno per questo) per il TGT remoto krbtgt /TEST.COM@EXAMPLE.COM;

Con il TGT remoto richiede al TGS del regno TEST.COM il ticket di servizio host/pluto.test.com@TEST.COM;

Quando il servizio di concessione ticket TEST.COM riceve la richiesta, verifica l’esistenza del principale krbtgt/TEST.COM@EXAMPLE.COM nel suo database con il quale può verificare la relazione di trust.

Se questa verifica è positiva, viene infine emesso il ticket di servizio (crittografato con la chiave host/pluto.test.com@TEST.COM) che pippo invierà all’host pluto.test.com per ottenere la shell remota.

Rapporti di fiducia transitivi

Quando il numero di regni in cui l’autenticazione incrociata deve essere possibile aumenta, il numero di chiavi da scambiare aumenta in modo quadratico.

Ad esempio, se ci sono 5 regni e le relazioni devono essere bidirezionali, gli amministratori devono generare 20 chiavi (il doppio delle combinazioni di 5 elementi per 2 per 2).

Per ovviare a questo problema, Kerberos 5 ha introdotto la transitività nella relazione di fiducia: se il regno A si fida del regno B e il regno B si fida del regno C, allora A si fiderà automaticamente C.

Questa proprietà della relazione riduce drasticamente il numero di chiavi (anche se il numero di aumenta i passaggi di autenticazione).

Tuttavia, c’è ancora un problema: i client non possono indovinare il percorso di autenticazione (capath) se non è diretto.

Quindi devono essere informati del percorso corretto creando una stanza speciale ([capaths]) nella configurazione di ciascuno dei client.

Questi percorsi devono anche essere conosciuti dai KDC che li useranno per controllare i transiti.

Rapporti di fiducia gerarchici

Se, all’interno delle organizzazioni, viene utilizzata la convenzione di denominare i regni con il nome dei domini DNS in lettere maiuscole (scelta altamente consigliata) e se questi ultimi appartengono a una gerarchia, Kerberos 5 supporterà i regni adiacenti (gerarchicamente) con una relazione di fiducia (naturalmente questa fiducia presunta deve essere supportata dalla presenza di chiavi appropriate) e costruirà automaticamente (senza la necessità di capaths) i percorsi di autenticazione transitivi.

Tuttavia, gli amministratori possono modificare questo meccanismo automatico (ad esempio per motivi di efficienza) forzando i capath nella configurazione client.