ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth una interfaccia per il Captive Portal

      Cosa è?
      Screenshots
      Licenza
      Annunci
      Mailing List
      Forum
      English Forum
      Documentazione
      FAQ
      Hardware
      Download
      Update On-line
      Kerberos Tutorial  
      Note Legali
      Contattami


  Più in dettaglio:
      Hotspot Router
      Accounting
      Shibboleth SP
      Grafici e Prestazioni
      Net Balancer
      Router UMTS
      Proxy con Antivirus
      Filtri Web
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS e LDAP
      Certificati X.509
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional




Il protocollo di autenticazione Kerberos

Kerberos   Premessa   Obiettivi   Definizioni   Funzionamento   Ticket   Cross Autenticazione

1.5  Ticket più in dettaglio

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.



    Copyright (C) 2005-2016 by Fulvio Ricciardi