1.1. The Kerberos Protocol (Il Protocollo Kerberos)

Kerberos fornisce un mezzo per verificare le identità dei principal (ad esempio, un utente di workstation o un server di rete) su una rete aperta (non protetta). Questo viene realizzato senza fare affidamento su asserzioni del sistema operativo host, senza basare la fiducia sugli indirizzi host, senza richiedere la sicurezza fisica di tutti gli host sulla rete, e sotto l'assunzione che i pacchetti che viaggiano lungo la rete possano essere letti, modificati e inseriti a volontà. Kerberos esegue l'autenticazione in queste condizioni come servizio di autenticazione con terza parte fidata (trusted third-party authentication service) utilizzando crittografia convenzionale (chiave segreta condivisa). Le estensioni a Kerberos (al di fuori dell'ambito di questo documento) possono prevedere l'uso della crittografia a chiave pubblica durante alcune fasi del protocollo di autenticazione. Tali estensioni supportano l'autenticazione Kerberos per gli utenti registrati presso autorità di certificazione a chiave pubblica e forniscono determinati vantaggi della crittografia a chiave pubblica in situazioni in cui sono necessari.

Il processo di autenticazione Kerberos di base procede come segue: un client invia una richiesta al server di autenticazione (AS, Authentication Server) per le "credenziali" per un determinato server. L'AS risponde con queste credenziali, crittografate nella chiave del client. Le credenziali consistono in un "ticket" per il server e una chiave di crittografia temporanea (spesso chiamata "chiave di sessione", session key). Il client trasmette il ticket (che contiene l'identità del client e una copia della chiave di sessione, tutto crittografato nella chiave del server) al server. La chiave di sessione (ora condivisa dal client e dal server) viene utilizzata per autenticare il client e può facoltativamente essere utilizzata per autenticare il server. Può anche essere utilizzata per crittografare ulteriori comunicazioni tra le due parti o per scambiare una chiave di sotto-sessione separata da utilizzare per crittografare ulteriori comunicazioni. Si noti che molte applicazioni utilizzano le funzioni di Kerberos solo all'avvio di una connessione di rete basata su stream. A meno che un'applicazione non esegua la crittografia o la protezione dell'integrità per il flusso di dati, la verifica dell'identità si applica solo all'avvio della connessione e non garantisce che i messaggi successivi sulla connessione provengano dallo stesso principal.

L'implementazione del protocollo di base consiste in uno o più server di autenticazione in esecuzione su host fisicamente sicuri. I server di autenticazione mantengono un database di principal (cioè, utenti e server) e delle loro chiavi segrete. Le librerie di codice forniscono la crittografia e implementano il protocollo Kerberos. Per aggiungere l'autenticazione alle sue transazioni, un'applicazione di rete tipica aggiunge chiamate alla libreria Kerberos direttamente o attraverso la Generic Security Services Application Programming Interface (GSS-API) descritta in un documento separato [RFC4121]. Queste chiamate risultano nella trasmissione dei messaggi necessari per ottenere l'autenticazione.

Il protocollo Kerberos consiste in diversi sotto-protocolli (o scambi). Ci sono due metodi di base con cui un client può chiedere credenziali a un server Kerberos. Nel primo approccio, il client invia una richiesta in chiaro per un ticket per il server desiderato all'AS. La risposta viene inviata crittografata nella chiave segreta del client. Di solito questa richiesta è per un ticket-granting ticket (TGT), che può essere successivamente utilizzato con il ticket-granting server (TGS). Nel secondo metodo, il client invia una richiesta al TGS. Il client utilizza il TGT per autenticarsi al TGS nello stesso modo in cui contatta qualsiasi altro server applicativo che richiede l'autenticazione Kerberos. La risposta è crittografata nella chiave di sessione del TGT. Sebbene la specifica del protocollo descriva l'AS e il TGS come server separati, in pratica sono implementati come diversi punti di ingresso del protocollo all'interno di un singolo server Kerberos.

Una volta ottenute, le credenziali possono essere utilizzate per verificare l'identità dei principal in una transazione, per garantire l'integrità dei messaggi scambiati tra loro, o per preservare la privacy dei messaggi. L'applicazione è libera di scegliere qualsiasi protezione possa essere necessaria.

Per verificare le identità dei principal in una transazione, il client trasmette il ticket al server applicativo. Poiché il ticket viene inviato "in chiaro" (parti di esso sono crittografate, ma questa crittografia non impedisce il replay) e potrebbe essere intercettato e riutilizzato da un attaccante, vengono inviate informazioni aggiuntive per dimostrare che il messaggio ha avuto origine dal principal a cui è stato rilasciato il ticket. Queste informazioni (chiamate authenticator) sono crittografate nella chiave di sessione e includono un timestamp. Il timestamp dimostra che il messaggio è stato generato di recente e non è un replay. La crittografia dell'authenticator nella chiave di sessione dimostra che è stato generato da una parte in possesso della chiave di sessione. Poiché nessuno tranne il principal richiedente e il server conoscono la chiave di sessione (non viene mai inviata sulla rete in chiaro), questo garantisce l'identità del client.

L'integrità dei messaggi scambiati tra i principal può anche essere garantita utilizzando la chiave di sessione (passata nel ticket e contenuta nelle credenziali). Questo approccio fornisce il rilevamento sia degli attacchi di replay che degli attacchi di modifica del flusso di messaggi. Viene realizzato generando e trasmettendo un checksum a prova di collisione (altrove chiamato funzione hash o digest) del messaggio del client, cifrato con la chiave di sessione. La privacy e l'integrità dei messaggi scambiati tra i principal possono essere protette crittografando i dati da passare utilizzando la chiave di sessione contenuta nel ticket o la chiave di sotto-sessione trovata nell'authenticator.

Gli scambi di autenticazione menzionati sopra richiedono accesso in sola lettura al database Kerberos. A volte, tuttavia, le voci nel database devono essere modificate, come quando si aggiungono nuovi principal o si cambia la chiave di un principal. Questo viene fatto utilizzando un protocollo tra un client e un terzo server Kerberos, il Kerberos Administration Server (KADM). C'è anche un protocollo per mantenere più copie del database Kerberos. Nessuno di questi protocolli è descritto in questo documento.