3
<title>Kerberos V5 UNIX User's Guide</title>
4
<meta http-equiv="Content-Type" content="text/html">
5
<meta name="description" content="Kerberos V5 UNIX User's Guide">
6
<meta name="generator" content="makeinfo 4.5">
7
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
12
Node:<a name="Kerberos%20Ticket%20Properties">Kerberos Ticket Properties</a>,
13
Next:<a rel="next" accesskey="n" href="Obtaining-Tickets-with-kinit.html#Obtaining%20Tickets%20with%20kinit">Obtaining Tickets with kinit</a>,
14
Previous:<a rel="previous" accesskey="p" href="Ticket-Management.html#Ticket%20Management">Ticket Management</a>,
15
Up:<a rel="up" accesskey="u" href="Ticket-Management.html#Ticket%20Management">Ticket Management</a>
19
<h4 class="subsection">Kerberos Ticket Properties</h4>
21
<p>There are various properties that Kerberos tickets can have:
23
<p>If a ticket is <dfn>forwardable</dfn>, then the KDC can issue a new ticket with
24
a different network address based on the forwardable ticket. This
25
allows for authentication forwarding without requiring a password to be
26
typed in again. For example, if a user with a forwardable TGT logs
27
into a remote system, the KDC could issue a new TGT for that user with
28
the netword address of the remote system, allowing authentication on
29
that host to work as though the user were logged in locally.
31
<p>When the KDC creates a new ticket based on a forwardable ticket, it
32
sets the <dfn>forwarded</dfn> flag on that new ticket. Any tickets that are
33
created based on a ticket with the forwarded flag set will also have
34
their forwarded flags set.
36
<p>A <dfn>proxiable</dfn> ticket is similar to a forwardable ticket in that it
37
allows a service to take on the identity of the client. Unlike a
38
forwardable ticket, however, a proxiable ticket is only issued for
39
specific services. In other words, a ticket-granting ticket cannot be
40
issued based on a ticket that is proxiable but not forwardable.
42
<p>A <dfn>proxy</dfn> ticket is one that was issued based on a proxiable ticket.
44
<p>A <dfn>postdated</dfn> ticket is issued with the <i>invalid</i> flag set.
45
After the starting time listed on the ticket, it can be presented to
46
the KDC to obtain valid tickets.
48
<p>Tickets with the <dfn>postdateable</dfn> flag set can be used to issue postdated
51
<p><dfn>Renewable</dfn> tickets can be used to obtain new session keys without
52
the user entering their password again. A renewable ticket has two
53
expiration times. The first is the time at which this particular
54
ticket expires. The second is the latest possible expiration time for
55
any ticket issued based on this renewable ticket.
57
<p>A ticket with the <dfn>initial</dfn> flag set was issued based on the
58
authentication protocol, and not on a ticket-granting ticket. Clients
59
that wish to ensure that the user's key has been recently presented for
60
verification could specify that this flag must be set to accept the
63
<p>An <dfn>invalid</dfn> ticket must be rejected by application servers. Postdated
64
tickets are usually issued with this flag set, and must be validated by
65
the KDC before they can be used.
67
<p>A <dfn>preauthenticated</dfn> ticket is one that was only issued after the
68
client requesting the ticket had authenticated itself to the KDC.
70
<p>The <dfn>hardware authentication</dfn> flag is set on a ticket which
71
required the use of hardware for authentication. The hardware is
72
expected to be possessed only by the client which requested the
75
<p>If a ticket has the <dfn>transit policy checked</dfn> flag set, then the KDC that
76
issued this ticket implements the transited-realm check policy and
77
checked the transited-realms list on the ticket. The transited-realms
78
list contains a list of all intermediate realms between the realm of the
79
KDC that issued the first ticket and that of the one that issued the
80
current ticket. If this flag is not set, then the application server
81
must check the transited realms itself or else reject the ticket.
83
<p>The <dfn>okay as delegate</dfn> flag indicates that the server specified in
84
the ticket is suitable as a delegate as determined by the policy of
85
that realm. A server that is acting as a delegate has been granted a
86
proxy or a forwarded TGT. This flag is a new addition to the
87
Kerberos V5 protocol and is not yet implemented on MIT servers.
89
<p>An <dfn>anonymous</dfn> ticket is one in which the named principal is a generic
90
principal for that realm; it does not actually specify the individual
91
that will be using the ticket. This ticket is meant only to securely
92
distribute a session key. This is a new addition to the Kerberos V5
93
protocol and is not yet implemented on MIT servers.