doc/rst_source/krb_users/tkt_mgmt/tkt_management.rst

   1 Kerberos ticket properties
   2 ==========================
   3
   4 There are various properties that Kerberos tickets can have:
   5
   6 If a ticket is **forwardable**, then the KDC can issue a new ticket
   7 with a different network address based on the forwardable ticket.
   8 This allows for authentication forwarding without requiring a password
   9 to be typed in again.  For example, if a user with a forwardable TGT
  10 logs into a remote system, the KDC could issue a new TGT for that user
  11 with the netword address of the remote system, allowing authentication
  12 on that host to work as though the user were logged in locally.
  13
  14 When the KDC creates a new ticket based on a forwardable ticket, it
  15 sets the **forwarded** flag on that new ticket.  Any tickets that are
  16 created based on a ticket with the forwarded flag set will also have
  17 their forwarded flags set.
  18
  19 A **proxiable** ticket is similar to a forwardable ticket in that it
  20 allows a service to take on the identity of the client.  Unlike a
  21 forwardable ticket, however, a proxiable ticket is only issued for
  22 specific services.  In other words, a ticket-granting ticket cannot be
  23 issued based on a ticket that is proxiable but not forwardable.
  24
  25 A **proxy** ticket is one that was issued based on a proxiable ticket.
  26
  27 A **postdated** ticket is issued with the invalid flag set.  After the
  28 starting time listed on the ticket, it can be presented to the KDC to
  29 obtain valid tickets.
  30
  31 Tickets with the **postdateable** flag set can be used to issue
  32 postdated tickets.
  33
  34 **Renewable** tickets can be used to obtain new session keys without
  35 the user entering their password again.  A renewable ticket has two
  36 expiration times.  The first is the time at which this particular
  37 ticket expires.  The second is the latest possible expiration time for
  38 any ticket issued based on this renewable ticket.
  39
  40 A ticket with the **initial flag** set was issued based on the
  41 authentication protocol, and not on a ticket-granting ticket.  Clients
  42 that wish to ensure that the user's key has been recently presented
  43 for verification could specify that this flag must be set to accept
  44 the ticket.
  45
  46 An **invalid** ticket must be rejected by application servers.
  47 Postdated tickets are usually issued with this flag set, and must be
  48 validated by the KDC before they can be used.
  49
  50 A **preauthenticated** ticket is one that was only issued after the
  51 client requesting the ticket had authenticated itself to the KDC.
  52
  53 The **hardware authentication** flag is set on a ticket which required
  54 the use of hardware for authentication.  The hardware is expected to
  55 be possessed only by the client which requested the tickets.
  56
  57 If a ticket has the **transit policy** checked flag set, then the KDC
  58 that issued this ticket implements the transited-realm check policy
  59 and checked the transited-realms list on the ticket.  The
  60 transited-realms list contains a list of all intermediate realms
  61 between the realm of the KDC that issued the first ticket and that of
  62 the one that issued the current ticket.  If this flag is not set, then
  63 the application server must check the transited realms itself or else
  64 reject the ticket.
  65
  66 The okay as **delegate** flag indicates that the server specified in
  67 the ticket is suitable as a delegate as determined by the policy of
  68 that realm.  A server that is acting as a delegate has been granted a
  69 proxy or a forwarded TGT.  This flag is a new addition to the Kerberos
  70 V5 protocol and is not yet implemented on MIT servers.
  71
  72 An **anonymous** ticket is one in which the named principal is a
  73 generic principal for that realm; it does not actually specify the
  74 individual that will be using the ticket.  This ticket is meant only
  75 to securely distribute a session key.  This is a new addition to the
  76 Kerberos V5 protocol and is not yet implemented on MIT servers.