Si è già accennato alla possibilità per un utente appartenente ad un certo realm di autenticarsi e accedere ai servizi di un altro realm. Questa caratteristica nota come cross-authentication presuppone che tra i realm interessati vi sia una relazione di fiducia. Quest’ultima può essere monodirezionale, intendendo con ciò che gli utenti di un realm A possono accedere ai servizi di un realm B ma non il viceversa, oppure bidirezionale, cioè in cui come è facile aspettarsi, vale il viceversa di prima. Nei prossimi paragrafi esamineremo in dettaglio la cross authetication distinguendo tra relazioni di fiducia (o relationships) dirette, transitive e gerarchiche.
1.6.1 Relazioni di fiducia dirette (Direct Relationships)
Questo tipo di relazione di fiducia è quello elementare che è alla base della cross-authentication ed è utilizzato anche per costruire gli altri due tipi di relationship che vedremo dopo. Si ha quando il KDC di un realm B ha direttamente fiducia nel KDC di un realm A, permettendo così, agli utenti di quest’ultimo di accedere alle sue risorse. Dal punto di vista pratico, la relazione di fiducia diretta si ottiene facendo condividere ai due KDC coinvolti una chiave (le chiavi diventano due se si vuole un trust bidirezionale). Per far ciò si introduce il concetto di Ticket Granting Ticket remoto che, nell’esempio dei due realm A e B, assume la forma krbtgt/B@A e va aggiunto in entrambi i KDC con la stessa chiave. Quest’ultima è il segreto che sarà a garanzia della fiducia tra i due realm. È ovvio poi, che per rendere la cosa bidirezionale (cioè che anche A si fidi di B), bisognerà creare, in entrambi i KDC, il TGT remoto krbtgt/A@B associandogli un’altra chiave segreta.
Come vedremo tra breve nell’esempio che segue, l’introduzione dei TGT remoti fa della cross autenticazione una naturale generalizzazione dell’autenticazione normale intra-realm: con ciò si sottolinea che la descrizione precedente del funzionamento di Kerberos continua a valere purchè si accetti che il TGS di un realm possa validare i TGT remoti emessi dal TGS di un altro. Si noti l’anomalia formale per cui i TGT remoti non vengono emessi dall’AS come invece accade per quelli locali, ma dal Ticket Granting Server locale su presentazione del TGT locale.
Ora un esempio chiarirà tutto quanto si è detto. Supponiamo che l’utente pippo del realm EXAMPLE.COM, il cui principal associato è pippo@EXAMPLE.COM, voglia accedere via ssh al server pluto.test.com appartente invece al realm TEST.COM:
- Pippo se non ha già un TGT nel realm EXAMPLE.COM fa una richiesta di autenticazione iniziale (kinit). Ovviamente la risposta proviene dall’AS del suo realm;
- Dà il comando ssh pippo@pluto.test.com dal quale si aspetta l’apertura della shell remota su pluto.test.com senza dover ridigitare la password;
- Il client ssh fa due query al DNS: risolve l’IP di pluto.test.com e sull’indirizzo appena ottenuto fa la reverse in modo da ottenere l’hostname (FQDN) in forma canonica (in questo caso coincide con pluto.test.com);
- ssh client si accorge poi, grazie al risultato precedente, che la destinazione non appartiene al realm dell’utente e quindi chiede al TGS del realm EXAMPLE.COM (si noti che lo chiede al TGS del suo realm) il TGT remoto krbtgt/TEST.COM@EXAMPLE.COM;
- Con il TGT remoto chiede al TGS del realm TEST.COM il ticket di servizio host/pluto.test.com@TEST.COM;
- Il Ticket Granting Server di TEST.COM, ricevendo la richiesta, controlla l’esistenza nel suo database del principal krbtgt/TEST.COM@EXAMPLE.COM con il quale potrà verificare la relazione di fiducia. Se la verifica ha esito positivo viene finalmente emesso il ticket di servizio (criptato con la chiave di host/pluto.test.com@TEST.COM) che pippo manderà all’host pluto.test.com per ottenere la shell remota.
1.6.2 Relazioni di fiducia transitive
Quando il numero dei realm in cui deve essere possibile la cross-authentication cresce, il numero di chiavi da scambiare aumenta in maniera quadratica. Solo a titolo di esempio, se i realm sono 5 e le relazioni devono essere bidirezionali le chiavi che gli amministratori devono generare sono 20 (è il doppio delle combinazioni di 5 elementi a 2 a 2).
Per venire incontro a questo problema, Kerberos 5 introduce la transitività delle relazioni di fiducia: se il realm A ha fiducia nel realm B e B ha fiducia in C allora anche A avrà automaticamente fiducia in C. Questa proprietà delle relationships riduce drasticamente il numero delle chiavi (anche se aumenta il numero di passaggi di autenticazione).
Tuttavia rimane ancora un problema: i client non possono indovinare il percorso di autenticazione (capath) se questo non è diretto. Bisogna allora informali del percorso giusto creando una particolare stanza ([capaths]) nella configurazione di ognuno dei client. Peraltro tali percorsi dovranno essere noti anche ai KDC che li useranno per verificare i transiti.
1.6.3 Relazioni di fiducia gerarchiche
Se nelle organizzazioni si usa la convenzione di chiamare i realm con il nome dei domini DNS in maiuscolo (scelta fortemente consigliata) e se quest’ultimi appartengono ad una gerarchia allora Kerberos 5 supporrà che tra realm adiacenti (gerarchicamente) vi sia una relazione di fiducia (naturalmente tale fiducia supposta dovrà comunque essere supportata dalla presenza delle opportune chiavi) e costruirà automaticamente (senza bisogno che ci siano i capaths) i percorsi transitivi di autenticazione. Gli amministratori potranno comunque modificare quest’automatismo (per esempio per ragioni di efficienza) forzando i capaths nella configurazione dei client.