ZeroShell    Forum
   Feed RSS Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth an interface for Captive Portal


      What is it?
      Screenshots
      License
      Announcements
      Mailing List
      Forum
      Documentation  
      FAQ
      Hardware
      Download
      On-line Updates
      Kerberos Tutorial  
      Terms of use
      Contact me


  In greater details:
      Hotspot Router
      RADIUS Accounting
      Shibboleth SP
      Performances
      Net Balancer
      UMTS Router
      Soekris Net5501
      Proxy with Antivirus
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS and LDAP
      X.509 Certificates
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional

Kerberos Authentication Protocol

Kerberos   Introduction   Aims   Definitions   Operation   Tickets   Cross Authentication

1.5  Tickets in further detail

As mentioned earlier, now that the operation of the KDC and messages between the hosts involved in the authentication have been discussed, we can now turn to the tickets. These, depending on whether they have attributes (also called flags) set inside them, behave in a certain manner. I have listed the most important types of tickets below, and even if not completely correct given that I are talking about a protocol, I will refer (just enough to make things clear) to version 1.3.6 of MIT Kerberos 5.

1.5.1 Initial tickets

An initial ticket is what is obtained directly from AS, i.e. when users must authenticate by entering the password. From here, it may be deduced that the TGT is always an initial ticket. On the other hand, the service tickets are distributed by the TGS upon presentation of a TGT and thus are not initial tickets. However, there is an exception to this rule: in order to guarantee that the user entered the password only a few seconds before, some Kerberos applications may request that the service ticket be initial; in this case the ticket, despite not being a TGT, is requested from the AS instead of the TGS and is thus an initial ticket. In operational terms, the user pippo, wishing to obtain a ticket which is initial (thus without using the TGT) for an imap service on the machine mbox.example.com uses the command:

[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
The presence of the flag I should be noted, indicating that it is an initial ticket.

1.5.2  Renewable tickets

A renewable ticket can be resubmitted to the KDC for renewal, i.e. it is reassigned the entire lifetime. Obviously, the KDC will honour the renewal request only if the ticket has not expired yet and has not exceeded the maximum renewal time (set in the Key Distribution Center database). Being able to renew a ticket combines the necessity of having short duration tickets for security reasons, with not having to re-enter the password for long periods: for example, imagine a job which must be processed for days and must not require any human intervention. In the following example pippo asks for a ticket which lasts for a maximum of one hour but is renewable for 8 days:
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
while for pippo to renew his ticket without re-entering the 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  Forwardable tickets

Let's suppose we have a work session on a machine with the related TGT and wish to login from it onto another machine, keeping the ticket. Forwardable tickets are the solution to this problem. A ticket forwarded from one host to another is in itself forwardable, thus once authenticated it is possible to access the login on all the desired machines without having to re-enter any password.
To obtain the same result without Kerberos, it would be necessary to use much less secure methods such as rsh or public key authentication with ssh. However, this latter method may be impracticable on systems where the user home directories are on network filesystems (e.g. NFS or AFS) since the private key (which should be private) would go over the network.



    Copyright (C) 2005-2013 by Fulvio Ricciardi