[500] in Kerberos_Protocol

home help back first fref pref prev next nref lref last post

Section 2 Kerberos Revisions for comment

daemon@ATHENA.MIT.EDU (Clifford Neuman)
Sun Aug 6 23:22:23 2000

Date: Sun, 6 Aug 2000 20:21:04 -0700 (PDT)
Message-Id: <200008070321.UAA08065@cayman-islands.isi.edu>
From: Clifford Neuman <bcn@ISI.EDU>
To: ietf-krb-wg@anl.gov, krb-protocol@mit.edu

I have received several comments on section 1.2, and will revise that
section and resubmit it to the list shortly.  In the meantime, here is
the edited section 2 of the revisions for comment (please submit
comments or suggestions to the working group mailing list).

Cliff

---
<H3>2.  Ticket flag uses and requests</H3>

Each Kerberos ticket contains a set of flags which are used to
indicate attributes of that ticket.  Most flags may be requested by a
client when the ticket is obtained; some are automatically turned on
and off by a Kerberos server as required.  The following sections
explain what the various flags mean, and gives examples of reasons to
use such a flag.

<H3>2.1.  Initial, pre-authenticated, and hardware authenticated
tickets</H3>

The INITIAL flag indicates that a ticket was issued using the AS
protocol and not issued based on a ticket-granting ticket.
Application servers that want to require the demonstrated knowledge of
a client's secret key (e.g. a password-changing program) can insist
that this flag be set in any tickets they accept, and thus be assured
that the client's key was recently presented to the application
client.

<P>

The PRE-AUTHENT and HW-AUTHENT flags provide additional information
about the initial authentication, regardless of whether the current
ticket was issued directly (in which case INITIAL will also be set) or
issued on the basis of a ticket-granting ticket (in which case the
INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
carried forward from the ticket-granting ticket).

<H3>2.2.  Invalid tickets</H3>

The INVALID flag indicates that a ticket is invalid.  Application
servers must reject tickets which have this flag set.  A postdated
ticket will usually be issued in this form.  Invalid tickets must be
validated by the KDC before use, by presenting them to the KDC in a
TGS request with the VALIDATE option specified.  The KDC will only
validate tickets after their starttime has passed.  The validation is
required so that postdated tickets which have been stolen before their
starttime can be rendered permanently invalid (through a hot-list
mechanism) (see section 3.3.3.1).

<H3>2.3.  Renewable tickets</H3>

Applications may desire to hold tickets which can be valid for long
periods of time.  However, this can expose their credentials to
potential theft for equally long periods, and those stolen credentials
would be valid until the expiration time of the ticket(s).  Simply
using short-lived tickets and obtaining new ones periodically would
require the client to have long-term access to its secret key, an even
greater risk.  Renewable tickets can be used to mitigate the
consequences of theft.  Renewable tickets have two "expiration times":
the first is when the current instance of the ticket expires, and the
second is the latest permissible value for an individual expiration
time.  An application client must periodically (i.e.  before it
expires) present a renewable ticket to the KDC, with the RENEW option
set in the KDC request.  The KDC will issue a new ticket with a new
session key and a later expiration time.  All other fields of the
ticket are left unmodified by the renewal process.  When the latest
permissible expiration time arrives, the ticket expires permanently.
At each renewal, the KDC may consult a hot-list to determine if the
ticket had been reported stolen since its last renewal; it will refuse
to renew such stolen tickets, and thus the usable lifetime of stolen
tickets is reduced.

<P>

The RENEWABLE flag in a ticket is normally only interpreted by the
ticket-granting service (discussed below in section 3.3).  It can
usually be ignored by application servers.  However, some particularly
careful application servers may wish to disallow renewable tickets.

<P>

If a renewable ticket is not renewed by its expiration time, the KDC
will not renew the ticket.  The RENEWABLE flag is reset by default,
but a client may request it be set by setting the RENEWABLE option in
the KRB_AS_REQ message.  If it is set, then the renew-till field in
the ticket contains the time after which the ticket may not be
renewed.

<H3>2.4.  Postdated tickets</H3>

Applications may occasionally need to obtain tickets for use much
later, e.g. a batch submission system would need tickets to be valid
at the time the batch job is serviced.  However, it is dangerous to
hold valid tickets in a batch queue, since they will be on-line longer
and more prone to theft.  Postdated tickets provide a way to obtain
these tickets from the KDC at job submission time, but to leave them
"dormant" until they are activated and validated by a further request
of the KDC.  If a ticket theft were reported in the interim, the KDC
would refuse to validate the ticket, and the thief would be foiled.

<P>

The MAY-POSTDATE flag in a ticket is normally only interpreted by the
ticket-granting service.  It can be ignored by application servers.
This flag must be set in a ticket-granting ticket in order to issue a
postdated ticket based on the presented ticket.  It is reset by
default; it may be requested by a client by setting the ALLOW-POSTDATE
option in the KRB_AS_REQ message.  This flag does not allow a client
to obtain a postdated ticket-granting ticket; postdated
ticket-granting tickets can only by obtained by requesting the
postdating in the KRB_AS_REQ message.  The life (endtime-starttime) of
a postdated ticket will be the remaining life of the ticket-granting
ticket at the time of the request, unless the RENEWABLE option is also
set, in which case it can be the full life (endtime-starttime) of the
ticket-granting ticket.  The KDC may limit how far in the future a
ticket may be postdated.

<P>

The POSTDATED flag indicates that a ticket has been postdated.  The
application server can check the authtime field in the ticket to see
when the original authentication occurred.  Some services may choose
to reject postdated tickets, or they may only accept them within a
certain period after the original authentication.  When the KDC issues
a POSTDATED ticket, it will also be marked as INVALID, so that the
application client must present the ticket to the KDC to be validated
before use.

<H3>2.5.  Proxiable and proxy tickets</H3>

At times it may be necessary for a principal to allow a service to
perform an operation on its behalf.  The service must be able to take
on the identity of the client, but only for a particular purpose.  A
principal can allow a service to take on the principal's identity for
a particular purpose by granting it a proxy.

<P>

The process of granting a proxy using the proxy and proxiable flags is
used to provide credentials for use with specific services.  Though
conceptually also a proxy, user's wishing to delegate their identity
for ANY purpose must use the ticket forwarding mechanism described in
the next section to forward a ticket granting ticket.

<P>

The PROXIABLE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers.
When set, this flag tells the ticket-granting server that it is OK to
issue a new ticket (but not a ticket-granting ticket) with a different
network address based on this ticket.  This flag is set if requested
by the client on initial authentication.  By default, the client will
request that it be set when requesting a ticket granting ticket, and
reset when requesting any other ticket.

<P>

This flag allows a client to pass a proxy to a server to perform a
remote request on its behalf, e.g. a print service client can give the
print server a proxy to access the client's files on a particular file
server in order to satisfy a print request.

<P>

In order to complicate the use of stolen credentials, Kerberos tickets
are usually valid from only those network addresses specifically
included in the ticket<A HREF="#fn4">[4]</A>.  When granting a proxy,
the client must specify the new network address from which the proxy
is to be used, or indicate that the proxy is to be issued for use from
any address.

<P>

The PROXY flag is set in a ticket by the TGS when it issues a proxy
ticket.  Application servers may check this flag and at their option
they may require additional authentication from the agent presenting
the proxy in order to provide an audit trail.

<H3>2.6.  Forwardable tickets</H3>

Authentication forwarding is an instance of a proxy where the service
granted is complete use of the client's identity.  An example where it
might be used is when a user logs in to a remote system and wants
authentication to work from that system as if the login were local.

<P>

The FORWARDABLE flag in a ticket is normally only interpreted by the
ticket-granting service.  It can be ignored by application servers.
The FORWARDABLE flag has an interpretation similar to that of the
PROXIABLE flag, except ticket-granting tickets may also be issued with
different network addresses.  This flag is reset by default, but users
may request that it be set by setting the FORWARDABLE option in the AS
request when they request their initial ticket-granting ticket.

<P>

This flag allows for authentication forwarding without requiring the
user to enter a password again.  If the flag is not set, then
authentication forwarding is not permitted, but the same result can
still be achieved if the user engages in the AS exchange specifying
the requested network addresses and supplies a password.

<P>

The FORWARDED flag is set by the TGS when a client presents a ticket
with the FORWARDABLE flag set and requests a forwarded ticket by
specifying the FORWARDED KDC option and supplying a set of addresses
for the new ticket.  It is also set in all tickets issued based on
tickets with the FORWARDED flag set.  Application servers may choose
to process FORWARDED tickets differently than non-FORWARDED tickets.

<h3>2.7 Transited Policy Checking</H3>

While the application server is ultimately responsible for accepting
or rejecting authentication and should check the transited field, a
KDC may apply a realm specific policy for validating the transited
field and accepting credentials for cross-realm authentication.  When
the KDC applies such checks and accepts such cross-realm
authentication it will set the TRANSITED-POLICY-CHECKED flag in the
service tickets it issues based on the cross-realm TGT.  A client may
request that the KDC's not check the transited field by setting the
DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not required to
honor this flag.

<h3>2.8 Anonymous Tickets</H3>

When policy allows, a KDC may issue anonymous tickets for the purpose
of enabling encrypted communication between a client and server
without identifying the client to the server.  Such anonymous tickets
are issued with a generic principal name configured on the KDC
(e.g. "anonymous@<realm>") and will have the ANONYMOUS flag set.  A
server accepting such a ticket may assume that subsequent requests
using the same ticket and session key originate from the same user.
Requests with the same username but different tickets are likely to
originate from different users.  Users request anonymous ticket by
setting the REQUEST-ANONYMOUS option in an AS or TGS request.

<H3>2.9.  Other KDC options</H3>

There are three additional options which may be set in a client's
request of the KDC.

<h3>2.9.1 Name canonicalization [JBrezak]</h3>

The NAME-CANONICALIZATION option allows the KDC to replace the name of
the server requested by the client with the canonical form of the
server's name, if known, or to refer the client to a KDC for the ream
with which the requested server principal is registered.

<P>

Where name cannonicalization is supported a a client who can identify
a server but does not know the full principal name for the server can
request that the Kerberos server attempt to lookup the name in its
database and return the canonical name of the requested principal or a
referral to a realm that has the requested principal in its namespace.
Use of name canonicalization supports the case where a principal has
multiple common names, all of which are known to the KDC, but only one
Kerberos identity (the canonical name is the Kerberos principal name).
Name canonicalization is intended solely to provide a secure mapping
from the name known to a user, and its principal identifier.  It is not
intended for use as a general purpose nameserver or to identify
instances of a service.

<P>

The CANONICALIZE flag in a ticket request is used to indicate to the
Kerberos server that the client will accept an alternative name to the
principal in the request or a referral to another realm. When name
cannonicalization is supported in a realm, all instances of the AS and
TGS for the realm must be able to interpret requests with this flag.
In realms where name cannonicalization is not supported, this flag may
be ignored.  By using this flag, the client can avoid extensive
configuration needed to map specific host names to a particular realm.

<h3>2.9.2 Renewable-OK</h3>

The RENEWABLE-OK option indicates that the client will accept a
renewable ticket if a ticket with the requested life cannot otherwise
be provided.  If a ticket with the requested life cannot be provided,
then the KDC may issue a renewable ticket with a renew-till equal to
the the requested endtime.  The value of the renew-till field may
still be adjusted by site-determined limits or limits imposed by the
individual principal or server.

<h3>2.9.3 ENC-TKT-IN-SKEY</h3>

The ENC-TKT-IN-SKEY option support user-to-user authentication.  It
allows the KDC to issue a service ticket encrypted using the session
key from a ticket granting ticket issued to another user.  This is
needed to support peer-to-peer authentication since the long term key
of the user does not remain on the workstation after initial login.
The ENC-TKT-IN-SKEY option is honored only by the ticket-granting
service.  It indicates that the ticket to be issued for the end server
is to be encrypted in the session key from the additional second
ticket-granting ticket provided with the request.  See section 3.3.3
for specific details.


-----

Commentary:

Section 2: No changes were made to existing options and flags
specified in RFC1510, though some of the sections in the specification
were renumbered, and text was revised to make the description and
intent of existing options clearer, especially with respect to the
ENC-TKT-IN-SKEY option (now section 2.9.3) which is used for
user-to-user authentication.  New options and ticket flags added since
RFC1510 include transited policy checking (section 2.7), anonymous
tickets (section 2.8) and name canonicalization (section 2.9.1).

home help back first fref pref prev next nref lref last post