Come già anticipato, ora che sono noti il funzionamento del KDC e i messaggi tra gli host che partecipano all’autenticazione, si può riparlare di ticket. Questi, a seconda che abbiano o meno al loro interno settati degli attributi (noti anche come flag) si comportano in una determinata maniera. Elenchiamo di seguito i tipi di ticket più importanti, e, anche se non troppo corretto visto che qui si parla di protocollo, faremo riferimento (quel che basta per fissare le idee) alla versione 1.3.6 di Kerberos 5 del MIT.
1.5.1 Ticket iniziali
Un ticket iniziale è quello che si ottiene direttamente dall’AS, cioè quando l’utente deve autenticarsi immettendo la password. Da qui si deduce che il TGT è sempre un ticket iniziale. I ticket di servizio, d’altra parte, vengono distribuiti dal TGS su presentazione di un TGT e quindi non sono ticket iniziali. C’è tuttavia un’eccezione a questa regola: alcune applicazioni Kerberos potrebbero richiedere, per garantirsi che l’utente abbia solo qualche istante prima digitato la password, che il ticket di servizio sia iniziale; in questo caso il ticket pur non essendo un TGT viene richiesto all’AS invece che al TGS e quindi è un ticket iniziale. Operativamente, l’utente pippo che vuole ottenere un ticket che sia iniziale (quindi senza sfruttare un TGT) per il servizio imap sulla macchina mbox.example.com usa il comando:
[pippo@client01 pippo]$ kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM
Password for pippo@EXAMPLE.COM:
[pippo@client01 pippo]$
[pippo@client01 pippo]$ klist -f
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: pippo@EXAMPLE.COM
Valid starting Expires Service principal
01/27/05 14:28:59 01/28/05 14:28:39 imap/mbox.example.com@EXAMPLE.COM
Flags: I
Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
Si noti la presenza del flag I indicante che si tratta di un ticket iniziale.
1.5.2 Ticket rinnovabili
Un ticket rinnovabile può essere rimandato al KDC perché venga rinnovato, cioè gli venga riassegnato l’intero lifetime. È ovvio che il KDC onorerà la richiesta di rinnovo solo se il ticket non è ancora scaduto e non ha superato il tempo massimo di rinnovo (definito nel database del Key Distribution Center). La rinnovabilità di un ticket concilia la necessità di avere ticket di breve durata per ragioni di sicurezza, con quella di non dover ridigitare la password per lunghi periodi: si pensi ad esempio ad un job che deve essere processato per giorni e non può richiedere l’intervento umano. Nell’esempio successivo pippo chiede un ticket che duri al massimo unr’ora ma rinnovabile per 8 giorni:
kinit -l 1h -r 8d pippo
Password for pippo@EXAMPLE.COM:
[pippo@client01 pippo]$
[pippo@client01 pippo]$ klist -f
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: pippo@EXAMPLE.COM
Valid starting Expires Service principal
01/27/05 15:35:14 01/27/05 16:34:54 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 02/03/05 15:35:14, Flags: RI
Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
mentre pippo per rinnovare il suo ticket senza ridigitare la password:
[pippo@client01 pippo]$ kinit -R
[pippo@client01 pippo]$
[pippo@client01 pippo]$ klist -f
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: pippo@EXAMPLE.COM
Valid starting Expires Service principal
01/27/05 15:47:52 01/27/05 16:47:32 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 02/03/05 15:35:14, Flags: RIT
Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
1.5.3 Ticket forwardabili
Supponiamo di avere una sessione di lavoro su di una macchina con il relativo TGT e di voler da questa fare login su di un’altra conservando il ticket. La soluzione a questo problema sono i ticket forwardabili. Un ticket forwardato da un host all’altro è esso stesso forwardabile per cui si conclude che una volta autenticati è possibile accedere al login su tutte le macchine che si vuole senza dover ridigitare nessuna password.
Per ottenere lo stesso risultato senza Kerberos, bisognerebbe ricorrere a metodi molto meno sicuri come rsh o all’autenticazione a chiave pubblica con ssh. Tuttavia, quest’ultimo metodo può essere impraticabile su sistemi in cui le home directory dell’utente sono su filesystem di rete (es. NFS o AFS) poiché la chiave privata (che appunto dovrebbe essere privata) verrebbe fatta passare sulla rete.