Kerberos si basa sulla crittografia simmetrica e richiede una terza parte affidabile.
Storia e sviluppo.
Il Massachusetts Institute of Technology (MIT) sviluppò Kerberos per proteggere i servizi di rete forniti dal Project Athena. Il protocollo fu battezzato come il personaggio mitologico Cerbero, che nella mitologia greca era il cane a tre teste posto a guardia dell'Ade. Ci sono diverse versioni del protocollo; le versioni dalla 1 alla 3 furono utilizzate solo all'interno del MIT.
Steve Miller e Clifford Neuman, i principali sviluppatori di Kerberos versione 4, pubblicarono questa versione alla fine degli anni Ottanta, anche se era stata sviluppata principalmente per il Project Athena.
La versione 5, progettata da John Kohl e Clifford Neuman, venne formalizzata nella RFC 1510 nel 1993 (resa obsoleta dalla RFC 4120 nel 2005), con l'intenzione di risolvere i limiti e i problemi di sicurezza della versione 4.
Il MIT mette a disposizione una implementazione di Kerberos libera, sotto una licenza simile alla BSD
Le autorità degli USA classificarono Kerberos come arma [senza fonte] e ne vietarono l'esportazione poiché utilizzava l'algoritmo di crittazione DES (con chiavi da 56 bit). Una implementazione di Kerberos non statunitense, KTH-KRB sviluppata in Svezia, rese il sistema disponibile anche al di fuori degli Stati Uniti, prima che questi cambiassero la propria legge sull'esportazione degli algoritmi crittografici (attorno al 2000). L'implementazione svedese del protocollo era basata su una versione di Kerberos detta eBones. eBones era basata sulla versione MIT Bones (in pratica una versione di Kerberos priva delle funzioni crittografiche e delle loro chiamate) ricavata da Kerberos 4 patchlevel 9. L'australiano Eric Young, autore di diverse librerie crittografiche, reinserì le chiamate alle funzioni crittografiche utilizzando la propria libreria libdes. Questa versione limitata di Kerberos fu chiamata eBones. Una implementazione della versione 5 di Kerberos, Heimdal, fu rilasciata essenzialmente dallo stesso gruppo che creò KTH-KRB.
Windows 2000, Windows XP e Windows Server 2003 usano una variante di Kerberos come sistema predefinito di autenticazione. Alcune aggiunte di Microsoft a Kerberos sono documentate nella RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" (trad.: "Protocolli Kerberos di impostazione password e cambio password in Microsoft Windows 2000"). Anche Mac OS X di Apple utilizza Kerberos sia nella versione client sia in quella server.
Nel 2005 il gruppo di lavoro su Kerberos dello IETF ha aggiornato le specifiche.
Recenti aggiornamenti includono:
* "Encryption and Checksum Specifications" (trad.: "Specifiche di crittazione e calcolo checksum") (RFC 3961)
* "Advanced Encryption Standard (AES) Encryption for Kerberos 5" (trad.: "Crittazione con AES in Kerberos 5") (RFC 3962),
* Una nuova edizione delle specifiche di Kerberos 5 "The Kerberos Network Authentication Service (V5)" (trad.: "Servizio Kerberos per l'Autenticazione su Reti") (RFC 4120). Questa versione rende obsoleta la RFC 1510, chiarifica alcuni aspetti del protocollo e il suo utilizzo in modo più dettagliato e chiaro,
* Una nuova edizione delle specifiche per GSS-API (RFC 4121)
Descrizione.
Kerberos si basa sul protocollo di Needham-Schroeder. Utilizza una terza parte affidabile per centralizzare la distribuzione delle chiavi detta Key Distribution Center (KDC), che consiste di due parti separate logicamente: l'Authentication Server (AS) e il Ticket Granting Server (TGS). Kerberos funziona utilizzando dei "biglietti" (detti ticket) che servono per provare l'identità degli utenti.
L'AS mantiene un database delle chiavi segrete; ogni entità sulla rete — che sia un client o un server — condivide la chiave segreta solo con l'AS. La conoscenza di questa chiave serve per provare l'identità di un'entità. Per comunicazioni tra due entità, Kerberos genera una chiave di sessione, che può essere utilizzata dai due terminali per comunicare.
Utilizzi [modifica]
Il seguente software è in grado di usare Kerberos per l'autenticazione:
* OpenSSH (con Kerberos 5 o successivo)
* NFS (a partire dalla versione NFSv4)
* PAM (con il modulo pam_krb5)
* SOCKS (a partire da SOCKS5)
Il protocollo [modifica]
Il protocollo può essere definito come segue utilizzando la notazione per protocolli di sicurezza, dove Alice (A) si autentica presso Bob (B) usando il server S:
A \rightarrow S: A,B
S \rightarrow A: \{T_S, L, K_{AB}, B, \{T_S, L, K_{AB}, A\}_{K_{BS}}\}_{K_{AS}}
A \rightarrow B: \{T_S, L, K_{AB}, A\}_{K_{BS}}, \{A, T_A\}_{K_{AB}}
B \rightarrow A: \{T_A + 1\}_{K_{AB}}
La sicurezza del protocollo si basa fortemente sui timestamp T e sui tempi di vita L come indicatori affidabili della creazione recente della comunicazione per evitare replay attack (vedi logica BAN).
È importante notare come il server S qui stia sia come Authentication Service (AS) che come Ticket Granting Service (TGS).
Operazioni di Kerberos [modifica]
Quella che segue è una descrizione semplificata del protocollo. Saranno utilizzate le seguenti abbreviazioni: AS = Authentication Server, TGS = Ticket Granting Server, SS = Service Server.
In breve: il client si autentica presso AS che gli fornisce un ticket di sessione per accedere a TGS, si autentica presso TGS e riceve il ticket per aprire una sessione di comunicazione con SS.
In dettaglio:
Utente: Autenticazione di base [modifica]
1. Un utente inserisce username e password sul client.
Client: Autenticazione AS [modifica]
1. Il client manda un messaggio non crittato all'AS richiedendo i servizi per l'utente. ("L'utente XYZ vorrebbe richiedere dei servizi"). Né la chiave segreta né la password vengono inviate all'AS.
2. L'AS controlla se il client è nel suo database. Se lo è invia due messaggi al client:
* Messaggio A: Chiave di sessione client-TGS crittata usando la chiave segreta dell'utente.
* Messaggio B: Ticket-Granting Ticket (che include l'identificativo del client, l'indirizzo di rete, il tempo di validità del ticket e la chiave di sessione client-TGS) crittata utilizzando la chiave segreta di TGS.
3. Quando il client riceve i messaggi A e B, decritta il messaggio A ottenendo la chiave di sessione client-TGS. Questa chiave è utilizzata per le successive comunicazioni con TGS. (Nota: il client non può decrittare il Messaggio B, che è stato crittato con la chiave segreta di TGS). A questo punto il client possiede i mezzi per autenticarsi presso TGS.
Client: Autenticazione TGS [modifica]
1. Quando richiede dei servizi, il client invia i seguenti due messaggi a TGS:
* Messaggio C: composto dal Ticket-Granting Ticket (mandatogli dal AS nel messaggio B) e dall'identificativo del servizio richiesto
* Messaggio D: autenticatore (Authenticator) (che è formato da identificativo del client e timestamp), crittato usando la chiave di sessione client—TGS.
2. Ricevendo i messaggi C e D, TGS decritta il messaggio C con la propria chiave e dal messaggio estrae la chiave di sessione client—TGS che utilizza per decrittare il messaggio D (autenticatore). A questo punto invia i seguenti due messaggi al client:
* Messaggio E: Ticket client-server (che include l'identificativo del client, l'indirizzo di rete del client, il periodo di validità e la chiave di sessione client-server) crittato utilizzando la chiave segreta del server che offre il servizio.
* Messaggio F: Chiave di sessione client-server crittato usando la chiave di sessione client-TGS.
Client: Autenticazione SS [modifica]
1. Ricevendo i messaggi E e F dal TGS, il client può autenticarsi presso il SS. Il client si connette al SS e invia i seguenti due messaggi:
* Messaggio G: Ticket client-server crittato usando la chiave segreta di SS.
* Messaggio H: un nuovo autenticatore, che include l'identificativo del client, il timestamp e è crittato usando la chiave di sessione client-server.
2. Il server decritta il ticket usando la sua chiave segreta e invia il seguente messaggio al client per confermare la propria identità e la volontà di fornire il servizio al client:
* Messaggio I: il timestamp trovato nell'autenticatore incrementato di uno, crittato utilizzando la chiave di sessione client-server.
3. Il client decritta la conferma usando la chiave di sessione client-server e controlla che il timestamp sia correttamente aggiornato. Se lo è, il client può considerare affidabile il server e iniziare a effettuare le richieste di servizio.
4. Il server fornisce i servizi al client.
Aggiornamenti: Cambiamenti per le versioni: 1.8.1+dfsg-5ubuntu0.2 1.8.1+dfsg-5ubuntu0.4 Versione 1.8.1+dfsg-5ubuntu0.4: * SECURITY UPDATE: kpropd denial of service via invalid network input - src/slave/kpropd.c: don't return on kpropd child exit; applied inline. - CVE-2010-4022 - MITKRB5-SA-2011-001 * SECURITY UPDATE: kdc denial of service from unauthenticated remote attackers - src/plugins/kdb/ldap/libkdb_ldap/kdb_ldap.h, src/plugins/kdb/ldap/libkdb_ldap/kdb_ldap_conn.c, src/plugins/kdb/ldap/libkdb_ldap/ldap_misc.c, src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c: applied inline - CVE-2011-0281 - CVE-2011-0282 - MITKRB5-SA-2011-002
Cambiamenti per le versioni:
1.8.1+dfsg-5ubuntu0.2
1.8.1+dfsg-5ubuntu0.4
Versione 1.8.1+dfsg-5ubuntu0.4:
* SECURITY UPDATE: kpropd denial of service via invalid network input
- src/slave/kpropd.c: don't return on kpropd child exit; applied
inline.
- CVE-2010-4022
- MITKRB5-SA-2011-001
* SECURITY UPDATE: kdc denial of service from unauthenticated remote
attackers
- src/plugins/kdb/ldap/libkdb_ldap/kdb_ldap.h,
src/plugins/kdb/ldap/libkdb_ldap/kdb_ldap_conn.c,
src/plugins/kdb/ldap/libkdb_ldap/ldap_misc.c,
src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c:
applied inline
- CVE-2011-0281
- CVE-2011-0282
- MITKRB5-SA-2011-002
Cambiamenti per le versioni:
1.8.1+dfsg-5ubuntu0.2
1.8.1+dfsg-5ubuntu0.4
Versione 1.8.1+dfsg-5ubuntu0.4:
* SECURITY UPDATE: kpropd denial of service via invalid network input
- src/slave/kpropd.c: don't return on kpropd child exit; applied
inline.
- CVE-2010-4022
- MITKRB5-SA-2011-001
* SECURITY UPDATE: kdc denial of service from unauthenticated remote
attackers
- src/plugins/kdb/ldap/libkdb_ldap/kdb_ldap.h,
src/plugins/kdb/ldap/libkdb_ldap/kdb_ldap_conn.c,
src/plugins/kdb/ldap/libkdb_ldap/ldap_misc.c,
src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c:
applied inline
- CVE-2011-0281
- CVE-2011-0282
- MITKRB5-SA-2011-002
Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog: