~ubuntu-branches/ubuntu/maverick/krb5/maverick

« back to all changes in this revision

Viewing changes to doc/krb5-user/Kerberos-Ticket-Properties.html

  • Committer: Bazaar Package Importer
  • Author(s): Sam Hartman, Russ Allbery, Sam Hartman
  • Date: 2008-08-21 10:41:41 UTC
  • mfrom: (11.1.15 intrepid)
  • Revision ID: james.westby@ubuntu.com-20080821104141-a0f9c4o4cpo8xd0o
Tags: 1.6.dfsg.4~beta1-4
[ Russ Allbery ]
* Translation updates:
  - Swedish, thanks Martin Bagge.  (Closes: #487669, #491774)
  - Italian, thanks Luca Monducci.  (Closes: #493962)

[ Sam Hartman ]
* Translation Updates:
    - Dutch, Thanks Vincent Zweije, Closes: #495733

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
<html lang="en">
2
 
<head>
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">
8
 
</head>
9
 
<body>
10
 
<div class="node">
11
 
<p>
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>
16
 
<hr><br>
17
 
</div>
18
 
 
19
 
<h4 class="subsection">Kerberos Ticket Properties</h4>
20
 
 
21
 
<p>There are various properties that Kerberos tickets can have:
22
 
 
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.
30
 
 
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.
35
 
 
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.
41
 
 
42
 
<p>A <dfn>proxy</dfn> ticket is one that was issued based on a proxiable ticket.
43
 
 
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.
47
 
 
48
 
<p>Tickets with the <dfn>postdateable</dfn> flag set can be used to issue postdated
49
 
tickets.
50
 
 
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.
56
 
 
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
61
 
ticket.
62
 
 
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.
66
 
 
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.
69
 
 
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
73
 
tickets.
74
 
 
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.
82
 
 
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.
88
 
 
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.
94
 
 
95
 
</body></html>
96