Architettura Kerberos e flusso dei ticket

Kerberos è stato sviluppato al MIT negli anni Ottanta nell'ambito del Project Athena per fornire un'autenticazione di rete sicura in un ambiente di elaborazione distribuito. Il nome deriva dal cane a tre teste che custodisce gli inferi; Kerberos fornisce l'autenticazione reciproca tra client e servizi usando una terza parte fidata: il Key Distribution Center.

Il KDC ha due componenti logici: l'Authentication Service (AS) e il Ticket Granting Service (TGS). In Microsoft Active Directory, entrambi vengono eseguiti sul controller di dominio. L'AS gestisce l'accesso iniziale e rilascia i Ticket Granting Ticket (TGT). Il TGS rilascia i ticket di servizio per accedere a servizi specifici.

Il client inizia l'autenticazione inviando un AS-REQ all'Authentication Service. Kerberos moderno richiede la pre-autenticazione: il client crittografa un timestamp con la propria chiave a lungo termine (derivata dalla password) per dimostrare di conoscere la password. Questo impedisce gli attacchi a dizionario offline contro messaggi AS-REQ non protetti.

L'AS verifica i dati di pre-autenticazione e risponde con un AS-REP contenente un Ticket Granting Ticket (TGT), crittografato con la chiave a lungo termine dell'account krbtgt (che il client non può decifrare), e una chiave di sessione crittografata con la chiave a lungo termine del client. Il client decifra solo la parte a lui destinata per ottenere la chiave di sessione del TGS.

Quando il client vuole accedere a un servizio, invia un TGS-REQ al Ticket Granting Service, includendo il TGT (come prova della propria identità) e un autenticatore crittografato con la chiave di sessione del TGS. Il TGS decifra il TGT con la chiave krbtgt per verificare l'identità del client.

Il TGS risponde con un ticket di servizio crittografato con la chiave a lungo termine del servizio di destinazione, oltre a una nuova chiave di sessione crittografata per il client. Il client non può leggere il contenuto del ticket di servizio, ma solo la parte crittografata per lui. Questo ticket dimostra l'identità del client al servizio.

Il client invia un AP-REQ al servizio di destinazione, includendo il ticket di servizio e un nuovo autenticatore crittografato con la chiave di sessione del servizio. Il servizio decifra il ticket di servizio usando la propria chiave a lungo termine, verifica l'autenticatore e autentica il client. La password non viene mai inviata al servizio.

Un realm Kerberos è un dominio amministrativo gestito da un singolo KDC. L'autenticazione tra realm viene stabilita tramite chiavi inter-realm condivise tra i KDC di realm diversi. Quando un client del Realm A accede a un servizio del Realm B, il KDC del Realm A rilascia un ticket di riferimento che il client presenta al KDC del Realm B.

I ticket Kerberos hanno una durata configurata (in genere 10 ore per i TGT), al termine della quale scadono ed è necessaria una nuova autenticazione. I TGT possono anche essere configurati come rinnovabili, consentendo al client di richiedere un nuovo TGT al KDC senza reinserire le credenziali, fino al raggiungimento della durata massima di rinnovo.

Kerberos usa due tipi di chiavi. Le chiavi a lungo termine derivano dalle password degli account e vengono usate solo per crittografare parti dei messaggi di autenticazione. Le chiavi di sessione vengono negoziate nuovamente per ogni scambio di autenticazione e usate per la sessione di comunicazione vera e propria. La compromissione di una chiave di sessione non espone la chiave a lungo termine.

Kerberos fornisce autenticazione reciproca (vengono verificati sia il client sia il servizio), protezione dai replay (tramite timestamp e autenticatori) e forward secrecy per le singole sessioni. Durante il normale funzionamento, il KDC non espone mai le chiavi a lungo termine. L'ipotesi fondamentale di attendibilità è che il KDC stesso non venga compromesso.

Qual è lo scopo di un Ticket Granting Ticket (TGT) in Kerberos?

Kerberos usa un KDC con i componenti AS e TGS. L'accesso produce un TGT (AS-REQ/AS-REP). Per accedere a un servizio è necessario scambiare il TGT con un ticket di servizio (TGS-REQ/TGS-REP). Il ticket di servizio viene presentato al servizio di destinazione (AP-REQ). Solo il KDC e i rispettivi servizi possono leggere i ticket. I realm consentono l'autenticazione tra domini tramite l'attendibilità inter-realm.