Kerberos (protocollo)

Protocollo

Kerberos utilizza come base il protocollo Needham-Schroeder. Si avvale di un'autenticazione di fiducia di terze parti nota come "key distribution center (KDC)", che consiste di due parti logicamente separate: un Authentication Server (AS) e un Ticket Granting Server (TGS). Kerberos lavora sulla base di "ticket" (chiamati ticket Kerberos) che servono a provare l'identità degli utenti.

Database Kerberos: Il centro di distribuzione delle chiavi (KDC) gestisce un database di chiavi segrete; ogni entità della rete - sia essa un client o un server - condivide una chiave segreta nota solo a se stessa e al KDC. La conoscenza di questa chiave serve a provare l'identità di ogni entità. Per la comunicazione tra due entità, il KDC genera una chiave di sessione che può essere utilizzata per proteggere le loro comunicazioni.

Il termine "server Kerberos" si riferisce generalmente al KDC. Per motivi di affidabilità è possibile avere dei KDC di backup. Questi sono denominati "server slave Kerberos". Tutti gli slave sincronizzano le loro banche dati dal server master Kerberos.

Il termine "application server Kerberized" si riferisce generalmente ai programmi Kerberized con cui i clienti comunicano utilizzando i ticket Kerberos per l'autenticazione. Ad esempio, il server telnet Kerberos telnet è un esempio di application server Kerberized . Mentre il termine "applicazioni Kerberized" è usato per riferirsi al lato client dell'application server Kerberized , Per esempio, il client Kerberos telnet è un esempio di applicazioni Kerberized

La sicurezza del protocollo dipende molto dalla sicurezza:

1. I partecipanti mantengono il tempo liberamente sincronizzato.
2. Una breve dichiarazione di autenticità: i biglietti Kerberos.

Descrizione semplificata del protocollo

Saranno utilizzate le seguenti abbreviazioni:

·         AS = Server di autenticazione

·         TGS = Ticket Granting Server

·         SS o Server = Server di servizio (utente server che richiede il suo servizio, come ad esempio un server di stampa, un file server, ecc...)

·         TGT = Ticket Granting Ticket (biglietto Kerberos per il TGS. Preparato da AS, poi utilizzato per parlare con il TGS).

In breve, il cliente si autentica alla AS utilizzando un segreto condiviso a lungo termine e riceve un biglietto dalla AS. In seguito il cliente può utilizzare questo biglietto per ottenere ulteriori biglietti per le SS utilizzando lo stesso segreto condiviso. Questi biglietti possono essere utilizzati per dimostrare l'autenticazione alle SS.

Il protocollo in dettaglio

Passaggi di accesso basati sul client dell'utente:

1. Un utente inserisce un nome utente e una password sulla macchina client.
2. Il cliente esegue una funzione a senso unico (per lo più una funzione Hash) sulla password inserita, e questa diventa la chiave segreta del cliente/utente.

Fasi di autenticazione del cliente:

1. Il cliente invia un messaggio di testo in chiaro all'AS che richiede i servizi per conto dell'utente.
   Esempio di messaggio: "L'utente XYZ desidera richiedere servizi".
   Nota: Né la chiave segreta né la password vengono inviate all'AS.
2. L'AS controlla se il cliente è nel suo database. In caso affermativo, l'AS invia al cliente i seguenti due messaggi:
• Messaggio A: Client/TGS Session Key criptata utilizzando la chiave segreta del cliente/utente.
• Messaggio B: TGT (che include l'ID cliente, l'indirizzo di rete del cliente, il periodo di validità del biglietto e la Client/TGS Session Key) criptato con la chiave segreta del TGS.
3. Una volta che il cliente riceve i messaggi A e B, decifra il messaggio A per ottenere la Session Key del Cliente/TGS. Questa chiave di sessione viene utilizzata per ulteriori comunicazioni con il TGS. A questo punto, il cliente dispone di informazioni sufficienti per autenticarsi al TGS.
   Nota: il cliente non può decifrare il messaggio B, in quanto viene criptato con la chiave segreta del TGS.

Fasi di autorizzazione del servizio clienti:

1. In caso di richiesta di servizi, il cliente invia al TGS i seguenti due messaggi:
• Messaggio C: Composto dal TGT del messaggio B e dall'ID del servizio richiesto.
• Messaggio D: Authenticator (che è composto dall'ID cliente e dal timestamp), criptato usando la Client/TGS Session Key.
2. Alla ricezione dei messaggi C e D, il TGS recupera il messaggio B dal messaggio C. Decripta il messaggio B utilizzando la chiave segreta del TGS. In questo modo si ottiene la chiave di sessione del Cliente/TGS. Utilizzando questa chiave, il TGS decripta il messaggio D (Authenticator) e invia i due messaggi seguenti al cliente:
• Messaggio E: ticket client-to-Server (che include l'ID cliente, l'indirizzo di rete del cliente, il periodo di validità e la Client/Server Session Key) crittografato con la chiave segreta SS.
• Messaggio F: Client/Server Session Key criptata con la Client/TGS Session Key.

Richiesta di assistenza clienti:

1. Alla ricezione dei messaggi E e F del TGS, il cliente dispone di informazioni sufficienti per autenticarsi alle SS. Il cliente si collega alle SS e invia i seguenti due messaggi:
• Messaggio E: dal passo precedente (il biglietto Client-to-Server, criptato con la chiave segreta SS).
• Messaggio G: un nuovo Authenticator, che include l'ID del cliente, il timestamp e viene criptato con la chiave di sessione client/server.
2. Le SS decifrano il biglietto utilizzando la propria chiave segreta per recuperare la chiave di sessione Client/Server. Utilizzando la chiave di sessione, SS decripta l'Authenticator e invia il seguente messaggio al cliente per confermare la sua vera identità e la sua volontà di servire il cliente:
• Messaggio H: il timestamp trovato nell'Authenticator del client più 1, criptato con la chiave di sessione client/server.
3. Il client decifra la conferma utilizzando la chiave di sessione client/server e controlla se il timestamp è aggiornato correttamente. In caso affermativo, il client può fidarsi del server e può iniziare ad emettere richieste di servizio al server.
4. Il server fornisce i servizi richiesti al cliente.

Svantaggi

• Singolo punto di guasto: Richiede la disponibilità continua di un server centrale. Quando il server Kerberos è fuori servizio, nessuno può accedere. Questo problema può essere risolto utilizzando più server Kerberos e meccanismi di autenticazione di emergenza.
• Kerberos richiede che gli orologi di tutti gli host coinvolti siano sincronizzati. I biglietti hanno un periodo di disponibilità di tempo e se l'orologio dell'host non è sincronizzato con l'orologio del server Kerberos, l'autenticazione fallirà. La configurazione predefinita richiede che i tempi di clock non siano distanti tra loro più di 10 minuti. In pratica, il Network Time Protocol (NTP) viene solitamente utilizzato per mantenere tutti gli host sincronizzati.
• Il protocollo di amministrazione non è standardizzato e differisce tra le implementazioni dei server. Le modifiche della password sono descritte in RFC 3244.
• Poiché le chiavi segrete di tutti gli utenti sono memorizzate sul server centrale, un compromesso di quel server comprometterà le chiavi segrete di tutti gli utenti.
• Un cliente compromesso compromette la password dell'utente.

Pagine correlate

• Gestione dell'identità
• Protocollo di password remota sicura (SRP)
• Generic Security Services Application Program Interface (GSS-API)