Kerberos è uno dei più diffusi e collaudati protocolli per l'autenticazione alle risorse di rete. Per garantire la massima sicurezza possibile, adotta un'architettura piuttosto articolata. Che
vede interagire tre componenti. Il client che accede a una risorsa di rete, ad esempio un server. Un elemento specifico di Kerberos, denominato
Key Distribution Center. La risorsa a cui il client vuole accedere, nel nostro esempio un server. Ma può essere anche astrattamente un servizio di rete.
In Kerberos, un client non si identifica direttamente alla risorsa a cui vuole accedere. Prima si identifica al Key Distribution Center. Per la precisione, a un suo modulo che si chiama
Authentication Service. Questo una volta riconosciuto il client gli passa
due chiavi cifrate. Semplificando, la prima identifica e mantiene "valida" la sessione di connessione del client, la seconda è un ticket che gli dà il diritto di chiedere accesso alle risorse di rete.
Quando vuole collegarsi ad una specifica risorsa di rete, il client "chiama" di nuovo il KDC. E dialoga con un altro suo componente, il
Ticket-Granting Service. Gli comunica la risorsa che gli interessa e dimostra il diritto a collegarvisi inviando il ticket che l'Authentication Service gli ha passato in precedenza. Se tutte le informazioni sono valire, il Ticket-Granting Service risponde con altre informazioni. Tra cui una chiave cifrata che di fatto è
un ticket valido per accedere a quella determinata risorsa. Questo ticket è cifrato usando una chiave specifica della singola risorsa di rete che può conoscere solo il KDC, perché è memorizzata in un suo file (keytab nei sistemi Linux)
A questo punto il client si collega finalmente alla risorsa di cui ha bisogno.
Dimostra la sua affidabilità inviandole la chiave della sessione di collegamento e il ticket di "accesso" alla risorsa. Due elementi che il KDC ha generato e comunicato in due fasi diverse, dopo gli opportuni controlli. La sessione viene stabilita e il dialogo tra client e risorsa di rete prosegue.
Questo funzionamento è stato ideato perché per un attaccante
sia impossibile impersonare del tutto il KDC ed effettuare un attacco di tipo "man in the middle". Intercettare cioè le connessioni tra un client e il KDC lecito. E rispondere alle richieste del client con dati che apparirebbero perfettamente corretti. Ma nel frattempo
carpire informazioni che permettessero all'attaccante di identificarsi a sua volta, illecitamente, a una risorsa di rete.
Un attaccante potrebbe in teoria anche arrivare a creare una chiave di sessione valida per un client.
Ma sarebbe inutile, perché non potrebbe mai creare i ticket cifrati necessari per accedere alle varie risorse di rete. Non ne possiede le rispettive chiavi di cifratura, quindi non può attivare un Ticket-Granting Service funzionante. E qualsiasi autenticazione cadrebbe.
Almeno questa è la teoria di Kerberos. Poi la pratica
dipende da come il protocollo è stato implementato. E qui sorgono i problemi, come si è visto
anche di recente. Alcune implementazioni sorvolano sulla terza parte dell'identificazione Kerberos (il primissimo dialogo tra client e risorsa di rete), spesso perché si basano su processi che non possono accedere ad un file keytab. Non possono quindi gestire i ticket specifici per risorsa e
si "fidano" che la prima parte di autenticazione - quella gestita dall'Autenthication Server - sia sufficiente.
Questo è un comportamento non sicuro che potrebbe permettere, in determinate condizioni, il successo di un attacco di tipo "man in the middle". Questo attacco è detto di
KDC spoofing ed è noto da diversi anni. Ma è ancora fattibile, perché pur essendo conosciuto non ha portato a una armonizzazione sicura delle varie implementazioni.