Cap XIV William Stallings Cryptography Cap XIV William Stallings

La rete e la sicurezza dei dati Internet per natura è una rete insicura Alcuni dei pericoli possibili sono quando si trasferiscono informazioni attraverso una rete: - furto di informazioni riservate - defacing (modifica contenuti sito Web) - intercettazione del traffico (packet sniffer)

La rete e la sicurezza dei dati Ad esempio,nel caso del packet sniffer, tra le informazioni intercettabili possono esserci: File Messaggi di posta elettronica Dati login utente ad un servizio Username PASSWORD etc….etc….etc… Ma come possiamo tutelarci ed essere più sicuri?

Viaggio sicuro sulla rete Come? creando informazioni cifrate (CRITTOGRAFIA) utilizzando protocolli adatti per l’invio delle stesse I protocolli più utilizzati sono: HTTPS, SSL, Kerberos

Viaggio sicuro sulla rete •HTTPS (Secure http - hypertext transport protocol secure ) - permette la comunicazione cifrata sul www basandosi su SSL • SSL (Secure Socket Layer) stabilisce: -modalità di comunicazione client-server garantisce: - che la comunicazione avvenga tra i veri soggetti - l’autenticazione a chiavi pubbliche basata sui certificati - la protezione tra livello applicazione (HTTP) e trasporto (TCP/IP)

KERBEROS (L’avvento del “Cane”) Le origini di KERBEROS Sistema di autenticazione prodotto nell’ambito del progetto “Athena” (1983) frutto della collaborazione tra il M.I.T.(Massachusetts Institute of Tecnology),l’IBM e il DEC Il nome KERBEROS deriva dalla mitologia greca Era il nome del cane a tre teste a guardia delle porte dell’inferno

Introduzione – L’avvento del “Cane” Perché proprio un cane a tre teste? Il cane simboleggia con le sue tre teste i tre scopi originali di KERBEROS ossia Autorizzazione Autenticazione Cifratura Autenticazione: verificare l'identità di un client o di un servizio; Autorizzazione: autorizzare un client autenticato ad utilizzare un particolare servizio; Cifratura: capacità del sistema di prevenire che terze parti ascoltino i contenuti di qualunque comunicazione

2. KERBEROS – La struttura L'autenticazione nel sistema Kerberos si basa su un nuovo modello di fiducia. (a chiavi private con terza parte fidata) A differenza del modello a due parti, in cui è prevista la presenza di due elementi aventi fiducia reciproca (trasmissione password avviene in chiaro = pericolo sniffer), nel sistema Kerberos le due parti vengono a trovarsi in una relazione di fiducia verso una terza parte avente funzione di garante dell'identità dell'uno verso l'altro.

KERBEROS Modello a “terza parte di fiducia” Descrizione La terza parte KDC (Key Distribution Center) tratta tutti (client e server) come “principal” utente o servizio che si possono autenticare tramite Kerberos struttura nome di un principal: Primary/instance@NOMEREALM Primary = equivale al nome dell’utente o del servizio instance = equivale alla qualifica di un utente. client e server condividono con lui una key (o password) crittografica si occupa di presentare un principal ad un altro principal tramite le key mantenendone la segretezza reciproca

KERBEROS Modello a “terza parte di fiducia” KDC ha due funzioni logiche: quella di AS (Authentication server) riceve la richiesta di ticket TGS da parte del client quella di TGS (Ticket granting server) fornisce i ticket per i server Nonostante la divisione in due parti, le due funzioni del KDC vengono svolte entrambe da un server program che risiede sul sistema KDC

KERBEROS – i Ticket Descrizione insieme di dati che permette ad un servizio di identificare un client anche chiamati ‘passaporto temporaneo’ poiché hanno la durata di una sessione

Un semplice dialogo di autenticazione

Un dialogo di autenticazione più sicuro -Per ridurre al minimo il numero di volte che un utente deve introdurre la password -Per non trasmettere la password in chiaro

Dialogo di autenticazione per la versione 4 -Per risolvere il problema della durata del ticket -Vi deve essere un requisito di autenticazione dei server presso gli utenti senza il quale un estraneo potrebbe sabotare la configurazione in modo che i messaggi inviati al server giungano altrove

Dialogo di autenticazione per la versione 4

Kerberos 4 Overview Stallings Fig 14.1. Discuss in relation to Table 14.1 which details message exchanges.

I real Kerberos e l’impiego di più Kerberos

KERBEROS – i Ticket Struttura

KERBEROS – i Ticket (2) Le 11 parti della sequenza cifrata FLAGS: istruzioni attiv/disattiv per necessità KEY:necessario per passaggio chiave da kerberos a client e server (keytype=tipo chiave cifratura usata; keyvalue=contiene chiave codificata) CREALM: contiene nome realm dove registrato client CNAME: parte nome del principal identifier del client TRANSITED: elenco realms (dislocazioni kerberos sulla rete) partecipanti all’autenticazione dell’utente per cui è stato emesso il ticket (nodi sul percorso) AUTHTIME: indica quando è avvenuta autenticazione STARTTIME: indica da quando è valido il ticket ENDTIME: indica fino a quando è valido il ticket RENEW-TILL: tempo esistenza assoluto ticket (incluso rinnovi eventuali) AUTHORIZATION-DATA: usato per passaggio dati di autorizzazione dal client al server ricercato CADDR: elenco host dai quali poter usare il ticket (se vuoto,ticket utiliz da ovunque)

KERBEROS – i Ticket (3) Le istruzioni attivabili/disattivabili del FLAG Initial e Pre-authenticated: il ticket è stato emesso utilizzando il protocollo AS e non servendosi di un ticket-granting. Invalid: il ticket non è valido. Renewable: ogni ticket di questo tipo è caratterizzato da due 'tempi di scadenza'. Il tempo di scadenza associato al singolo ticket ed il massimo tempo di rinnovo possibile. I tickets rinnovabili vengono utilizzati per minimizzare i danni derivanti dal possibile furto di tickets. Postdated: ticket generato per essere utilizzato in seguito. Proxiable e proxy: vi potrebbe essere la necessità per un principal di permettere ad un servizio di effettuare delle operazioni al suo posto. Il servizio dovrà quindi essere in grado di impersonare il client, ma solo per un determinato scopo. Per fare questo, si utilizza un ticket proxy. Forwardable: è una versione particolare di ticket proxy nella quale al servizio è garantita l'impersonazione totale del client. Un esempio potrebbe essere: un utente si collega ad un sistema e vuole che l'autenticazione funzioni nel sistema come se il login fosse effettuato in locale.

KERBEROS – il DataBase Il Database - cuore di Kerberos parte fondamentale del sistema kerberos conserva all’interno tutte le chiavi e gli identificatori risiede sul server di autenticazione AS è soggetto sia a lettura che a scrittura ad ogni accesso Kerberos aggiunge/toglie record dai vari campi che compongono il database Struttura Le voci del database NAME: contiene indicatori dei Principal KEY: contiene le chiavi crittografiche dei Principal P KVNO ( Principal Key Version Number): versione della chiave dei Principal MAX LIFE: contiene durata massima vita del ticket-Principal MAX RENEWABLE LIFE: contiene durata massima vita del ticket rinnovabili

KERBEROS – REALM & Trasporto dislocazioni Kerberos sparse geograficamente e non i vari REALM comunicano tra loro solo se: hanno una chiave inter-real condivisa se tra i due real esiste un nodo realm che fa da tramite ? Come farà un client ad accedere ad un servizio fornito da un server presente in un realm diverso dal proprio? Non farà altro che richiedere al suo TGS un ticket da presentare al TGS remoto per ottenere un nuovo ticket da utilizzare con il relativo server remoto. Trasporto - Porte usate Il sistema Kerberos, su reti TCP/IP, utilizza come trasporto il protocollo non connesso UDP e come porta per il servizio, la porta 88 per KDC e 1024 per il Client.

3. Il Funzionamento Fasi del funzionamento ipotesi: Un client (A), vuole accedere ad un servizio presente su di un server (B) e per farlo richiederà le giuste credenziali al KDC

Il Funzionamento (1a fase – AS(1)) AS – Authentication Server Questa fase rappresenta il primo passo verso l'accesso a qualsiasi servizio e di norma viene effettuata al primo logon dell'utente. Il sistema client invia un messaggio composto da due componenti, una in chiaro e l'altra cifrata. Nella prima è contenuta una richiesta per ottenere il TGS che permetta l'accesso al Server B, nella seconda i dati necessari al AS, e quindi al KDC, per verificare l'identità del client: nome del sistema client e marcatore orario, il tutto cifrato con la chiave segreta del client.

Il Funzionamento (1a fase – AS(2)) AS – Authentication Server 2. A questo punto, l'AS utilizzando la chiave segreta del client, contenuta insieme ad altri dati nell'archivio del KDC, decifrerà la componente cifrata, ed in questo modo sarà sicuro che la richiesta sia stata effettuata realmente dal client. Il marcatore orario è fondamentale perchè farà si che la richiesta non possa essere ripresentata nuovamente.

Il Funzionamento (1a fase – AS(3)) AS – Authentication Server 3. Una volta verificata l'identità del client, l'AS invierà un messaggio di risposta composto, anche in questo caso, da due componenti. La prima, cifrata con la chiave segreta del client, conterrà la chiave di sessione (CS) necessaria al client per comunicare con il TGS mentre la seconda, a parità del contenuto, sarà cifrata con la chiave segreta del TGS e quindi accessibile solo a quest'ultimo.

Il Funzionamento (2a fase - TGS) TGS – Ticket Granting Service Exchange In questa fase, il client, invierà al TGS un messaggio composto da tre parti distinte. Una in chiaro contenente la richiesta di un TGS per il server B, una cifrata con la chiave segreta del client, contenente il nome del client ed un marcatore orario, e l'ultima costituita dal TGT ottenuto dall'AS nella fase AS_Exchange. 2. Il TGS risponderà con un messaggio composto da due parti, una cifrata con la chiave segreta del client e quindi accessibile solo a quest'ultimo, contenente la chiave di sessione (CS) da utilizzare con il Server B ed un ticket cifrato con la chiave segreta del Server B ma contenente la stessa chiave di sessione (CS) passata al Client A.

Il Funzionamento (3a fase) Client/Server Authentication Exchange 1.Nell'ultima fase, il client si presenta al server, sfruttando i dati ottenuti dal TGS, con un messaggio composto da due parti completamente cifrate. La prima parte, cifrata con la chiave di sessione ottenuta dal TGS, è chiamata anche Authenticator, e contiene, fra l'altro, il nome del client ed un marcatore orario. La seconda è costituita dal ticket, ottenuto sempre dal TGS, contenente la stessa chiave di sessione vista in precedenza,  ma cifrato con la chiave segreta del server. 2. Il server risponderà con un messaggio, cifrato utilizzando la chiave di sessione estratta dal messaggio ricevuto dal client, contenente il marcatore orario ricevuto nel precedente messaggio dal client.

4. Cifratura & Sicurezza Algoritmi usati la parte cifrata riveste un ruolo fondamentale all'interno dei singoli passaggi legati al processo di scambio delle credenziali alla base del Kerberos string2key: funzione che converte password in chiave di cifratura simmetrica come?  applicare una funzione HASH alla stringa composta concatenando la password dell'utente con un "SALT" il cui valore varia a secondo delle versioni di Kerberos e che serve a rendere la trasformazione sulla password dipendente dalla macchina sulla quale è effettuata. per implementare lo scambio di messaggi tra AS, client e server, sono necessari tre elementi: una algoritmo di crittografia forte; una funzione HASH; una funzione che implementi il checksum per l'Authenticator; nelle prime versioni di Kerberos l’alg. di crittografia usato era solo il DES,e non si usava il SALT nella versione 5 (attuale) algoritmi disponibili sono DES e Triplo DES per la crittografia (si ottiene chiave da 64 bit ) DES-CBC per l'hash CRC32 per i checksum

5. Bugs & Attacks Punti deboli di Kerberos Nella gestione dei ticket è possibile per un pirata intromettersi facendo credere a Kerberos di essere un client, (SPOOFING ATTACK) avendo il totale controllo della rete. Ma come avviene? 1. pirata tramite Backdoor,trojan prende possesso di un pc 2. lancia uno sniffer invisibile 3. intercetta un ticket,preleva le credenziali e si spaccia per il client al quale il ticket era riferito 2. Nella risposta di Kerberos ad un principal, possibilità di intercettazione della chiave privata rilasciata (attacco BRUTE FORCE) 3. Nella versione 5 trovate due falle con possibili attacchi Ddos che consiste nel creare carico di lavoro elevato tale da bloccare il sistema 1a falla: tipo "double-free" e potrebbe essere sfruttata da un cracker per compromettere l'intera infrastruttura di autenticazione di una rete. 2a falla: tipo "buffer overflow", quindi potrebbe essere utilizzata da un aggressore sia per mandare in crash un server per la distribuzione delle chiavi Kerberos sia per eseguire del codice

5. Bugs & Attacks (2) Altri attacchi Attacco alle credenziali di amministratore Kerberos un pirata scopre la password dell’amministratore principale con la quale si ha completo accesso al database di kerberos Denial of service creazione carico elevato The Insider Kerberos non è protetto da possibili modifiche dannose ai privilegi da parte di utenti interni (come amministratori ) Social engineering and password exposure Anche in questo caso,Kerberos non è protetto da possibili divulgazioni non autorizzate da parte degli utenti, di password,impostazioni di sicurezza Security holes in the Kerberos software itself Questo è un rischio costante,perché nonostante gli sviluppi nella progettazione di software, è davvero difficile creare software sicuro e stabile.

6. Pregi e difetti Pregi ( anche confronti con SSL ) Elimina la trasmissione di password in chiaro attraverso la rete Costo di utilizzo: Kerberos è un pacchetto libero e può essere installato liberamente (mentre SSL è a pagamento) La flessibilità: Kerberos è più flessibile di SSL se si vuole aggiungere una nuova tecnologia di autenticazione a Kerberos l'unica cosa da fare è modificare il proprio KDC,mentre SSL non è modificabile con facilità. La sicurezza delle chiavi in SSL: quando si ottiene un certificato, esso risiederà sull'hard disk del sistema. Essendo cifrato con una password memorizzata nel sistema e vulnerabile ad eventuali attacchi di cracker. In Kerberos invece non c'è la necessità di ricerca di certificati per l'autenticazione. Le chiavi revocate : nel caso di SSL, tutti i server devono ricevere notifica che il certificato è compromesso,quindi dispendio di risorse! In Kerberos basta disabilitare la chiave con il KDC senza alcun impegno per i server

6. Pregi e difetti (2) Quale il sistema più efficiente?… Difetti ( anche confronti con SSL ) Per utilizzare Kerberos bisogna modificare codice sorgente delle applicazioni per permettere chiamate alle librerie necessarie Per proteggere la rete con Kerberos bisogna “ kerberizzare” tutte le applicazioni che inviano password in chiaro Necessaria terza parte di fiducia,mentre in SSL no! Richiede un cammino sicuro attraverso il quale deve transitare la password dell'utente, inoltre richiede in genere una macchina dedicata e sicura come Authentication server Installazione difficile (casi di incompatibilità software,modifiche file di configurazione,sostituzione di server non adatti) Quale il sistema più efficiente?… Kerberos è più efficiente su alcune applicazioni (reti eterogenee di dimensioni significative) SSL su altre (ideale per comunicazione sul Web)!

x. 509 Authentication Service ITU-T Recc. X.500 Serie di standard che definicono un servizio di directory X.509 è parte dello standard X.500 Recc. X.509 Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks Lavoro sviluppato in buona parte dal w.g. PKIX di IETF Standard X.509 utilizzato in molti contesti: S/MIME, SSL/TLS, SET, etc

x. 509 Authentication Service X.509 definisce il formato standard per i certificati delle chiavi pubbliche e i protocolli di autenticazione Una directory può essere usata come deposito per i certificati con le chiavi pubbliche degli utenti firmati da una certification authority X.509 definisce in generale tutto il framework di autenticazione Fondata sull’uso di criptografia asimmetrica e di firme Digitali Non definisce algoritmi come standard, ma raccomanda RSA

Creazione di un certificato The X.509 certificate is the heart of the standard. There are 3 versions, with successively more info in the certificate - must be v2 if either unique identifier field exists, must be v3 if any extensions are used.

Certificati X.509 Un certificato contiene: Versione (1, 2 o 3) Serial number (unico all’interno di una CA) Identificatore dell’algoritmo di firma Nome X.500 della CA creatrice del certificato Periodo di validità del certificato (inizio - termine) Proprietario del certificato (Subject name) Info sulla chiave pubblica del soggetto (algoritmo, parametri, chiave) Identificatore unico della CA (v2+) Identificatore unico del proprietario (v2+) Estensioni Firma (dell’hash di tutti i campi presenti) Lo standard indica con CA<<X>> il certificato di X fornito da CA Stallings Fig 14.3

Certificati X.509 Stallings Fig 14.3

Certificati X.509 Certificate: Data: Version: 1 (0x0) Serial Number: 7829 (0x1e95) Signature Algorithm: md5WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/Email=server-certs@thawte.com Validity Not Before: Jul 9 16:04:02 1998 GMT Not After : Jul 9 16:04:02 1999 GMT Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/Email=baccala@freesoft.org Stallings Fig 14.3

Certificati X.509 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb: 33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1: 66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66: 70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17: 16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b: c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77: 8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3: d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8: e8:35:1c:9e:27:52:7e:41:8f Exponent: 65537 (0x10001) Stallings Fig 14.3

Certificati X.509 Signature Algorithm: md5WithRSAEncryption 93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d: 92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92: ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67: d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72: 0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1: 5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7: 8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22: 68:9f Stallings Fig 14.3

Ottenere un Certificato Ognuno che può accedere ad una CA può ottenere da questa un certificato Soltanto la CA può modificare un certificato I certificati non possono essere falsificati, quindi possono essere posti in una directory a disposizione del pubblico

CA in Italia Actalis S.p.A. Consorzio Certicomm Banca di Roma S.p.A. Infocamere SC.p.A. Banca Intesa S.p.A. In.Te.S.A. S.p.A. Banca Monte dei Paschi di Siena S.p.A. I.T. Telecom S.r.l. Cedacri S.p.A. Lombardia Integrata S.p.A. CNIPA Postecom S.p.A. Comando C4 Difesa Sanpaolo IMI S.p.A. Comando Trasm. e Inf. Esercito SOGEI S.p.A. Consiglio Nazionale del Notariato Trust Italia S.p.A. Consiglio Nazionale Forense

Uso dei certificati X vuole comunicare con Y Y fornisce a X il suo certificato X decripta con la chiave pubblica della CA la firma criptata con la chiave privata della stessa CA e calcolata sull’hash della prima parte del certificato di Y X calcola l’hash della prima parte del certificato di y e lo confronta con il risultato della decriptazione Se uguali tutto OK Lo stesso accade se la chiave di Y è stata rilasciata da un’altra CA di cui X possiede la chiave pubblica

Uso dei certificati Diversamente se X e Y fanno capo a CA1 e CA2 rispettivamente e X non possiede la chiave pubblica di CA2 X vuole comunicare con Y Y fornisce a X il suo certificato X ricava dal certificato di Y il nome di CA2 X richiede a CA1 il certificato di CA2 da dove ricava la sua chiave pubblica X decripta con la chiave pubblica di CA1 il certificato di CA2 ricavando la chiave pubblica di CA2 X decripta con la chiave pubblica di CA2 la firma di Y criptata con la chiave privata di CA2 e calcolata sull’hash della prima parte del certificato di Y X calcola l’hash della prima parte del certificato di Y e lo confronta con il risultato della decriptazione Se uguali tutto OK

Gerarchia delle CA Se il certificato di CA2 non è stato rilasciato da CA1 ma da CA3 X si deve rivolgere a quest’ultima La procedura si estende al caso di molte CA Tutti i certificati delle CA devono trovarsi in una directory X.509 suggerisce una struttura gerarchica All very easy is both parties use the same CA. If not, then there has to be some means to form a chain of certifications between the CA's used by the two parties. And that raises issues about whether the CA's are equivalent, whether they used the same policies to generate their certificates, and how much you're going to trust a CA at some remove from your own. These are all open issues.

Gerarchia delle CA Stallings Fig 14.4. Track chains of certificates: A acquires B certificate using chain: X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>> B acquires A certificate using chain: Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>

Revoca dei certificati Certificati hanno un periodo di validità Può essere necessario revocarli in anticipo Compromissione della chiave privata dell’utente Utente non più certificato dalla CA Certificato compromesso Ogni CA mantiene una lista dei certificati revocati (CRL) Un utente dovrebbe controllare volta per volta la validità di un certificato

Procedure di autenticazione La Recc. X.509 e i suoi annessi includono tre procedure alternative di autenticazione One-Way Authentication Two-Way Authentication Three-Way Authentication Tutte fanno uso delle firme a chiave pubblica The X.509 standard specifies the authentication protocols that can be used when obtaining and using certificates. 1-way for unidirectional messages (like email), 2-way for interactive sessions when timestamps are used, 3-way for interactive sessions with no need for timestamps (and hence synchronised clocks).

Autenticatione One-Way Un messaggio A -> B usato per stabilire: Identità di A e provenienza del messaggio da A Messaggio indirizzato a B Integrità e originalità del messaggio Il messaggio deve comprendere timestamp, nonce, identità di B

Autenticatione Two-Way Due messaggi (A -> B, B -> A) che stabiliscono pure: -L’identità di B e che la risposta proviene da B -Che la risposta è diretta ad A -L’integrità e l’originalità della risposta Risposta include il nonce originale di A, e il timestamp e il nonce di B

Autenticatione Three-Way Tre messaggi (A -> B, B -> A, A -> B) che consentono l’autenticazione senza clock sincronizzati La risposta da A a B contenente la copia firmata del nonce proveniente da B permette di non fare uso di timestamp o comunque di non basarsi su essi

X.509 Versione 3 Notato che è necessario/utile porre nei certificati altre informazioni: -email address -policy -usage constraints Piuttosto che creare nuovi campi espliciti si è definito un metodo di estensione generale con cui un estensione consiste di: -Extension identifier -Criticality indicator -Extension value

Estensioni dei certificati Tre tipi di estensioni Key and policy information Informazioni circa il soggetto e il fornitore delle chiavi e indicatori della policy per il certificato Certificate subject and issuer attributes Nomi alternativi del soggetto, nomi alternativi del fornitore, attributi particolari del soggetto Certificate path constraints Permettono l’introduzione di limitazioni sull’uso dei certificati da parte di altre CA (p.e. un soggettonon può agire da CA)

Public Key Infrastructure RFC 2822 – Internet Security Glossary Definizione di una PKI e di tutti i suoi componenti

7. bibliografia http://www.areanetworking.it/index.php/Kerberos http://www.amagri.it/Sicurezza_MS_Windows/Metodi_autenticazione/Kerberos/kerberos.htm http://www.tu-chemnitz.de/docs/lindocs/RH73/RH-DOCS/rhl-rg-it-7.3/ch-kerberos.html http://www.hackeralliance.net