[504] in Kerberos_Protocol

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

Section 4 Kerberos Revisions for comment

daemon@ATHENA.MIT.EDU (Clifford Neuman)
Fri Sep 8 20:47:05 2000

Date: Fri, 8 Sep 2000 17:46:44 -0700 (PDT)
Message-Id: <200009090046.RAA11067@cayman-islands.isi.edu>
From: Clifford Neuman <bcn@ISI.EDU>
To: ietf-krb-wg@anl.gov, krb-protocol@MIT.EDU

Attached is the draft text for section 4 of the Kerberos revisions,
with the list of changes at the end.  This section is descriptive of
specific implementations.  I think it makes the description of
Kerberos more complete, but other implementations of Kerberos may
choose to do things differently and still be inter-operable.  If anyone
has ideas for some introductory text to this section that makes this
clear, but which still imposes some constraints where we feel
constraints are appropriate, I would be interested in hearing such

Clifford Neuman

<H3>4.  The Kerberos Database</H3>

The Kerberos server must have access to a database containing the
principal identifiers and secret keys of any principals to be
authenticated<A HREF="#fn21">[21]</A> using such secret keys.  The
keying material in the database must be protected so that they are
only accessible to the Kerberos server and administrative functions
specifically authorized to access such material.

<H3>4.1.  Database contents</H3>

A database entry  should  contain  at  least  the  following

Field                Value

name                 Principal's identifier
key                  Principal's secret key
p_kvno               Principal's key version
max_life             Maximum lifetime for Tickets
max_renewable_life   Maximum total lifetime for renewable Tickets

The name field is an encoding of the principal's identifier.  The key
field contains an encryption key.  This key is the principal's secret
key.  (The key can be encrypted before storage under a Kerberos
"master key" to protect it in case the database is compromised but the
master key is not.  In that case, an extra field must be added to
indicate the master key version used, see below.) The p_kvno field is
the key version number of the principal's secret key.  The max_life
field contains the maximum allowable lifetime (endtime - starttime)
for any Ticket issued for this principal.  The max_renewable_life
field contains the maximum allowable total lifetime for any renewable
Ticket issued for this principal.  (See section 3.1 for a description
of how these lifetimes are used in determining the lifetime of a given


A server may provide KDC service to several realms, as long as the
database representation provides a mechanism to distinguish between
principal records with identifiers which differ only in the realm


When an application server's key changes, if the change is routine
(i.e.  not the result of disclosure of the old key), the old key
should be retained by the server until all tickets that had been
issued using that key have expired.  Because of this, it is possible
for several keys to be active for a single principal.  Ciphertext
encrypted in a principal's key is always tagged with the version of
the key that was used for encryption, to help the recipient find the
proper key for decryption.


When more than one key is active for a particular principal, the
principal will have more than one record in the Kerberos database.
The keys and key version numbers will differ between the records (the
rest of the fields may or may not be the same). Whenever Kerberos
issues a ticket, or responds to a request for initial authentication,
the most recent key (known by the Kerberos server) will be used for
encryption.  This is the key with the highest key version number.

<H3>4.2.  Additional fields</H3>

Project Athena's KDC implementation uses additional fields in its

Field        Value

K_kvno       Kerberos' key version
expiration   Expiration date for entry
attributes   Bit field of attributes
mod_date     Timestamp of last modification
mod_name     Modifying principal's identifier

The K_kvno field indicates the key version of the Kerberos master key
under which the principal's secret key is encrypted.


After an entry's expiration date has passed, the KDC will return an
error to any client attempting to gain tickets as or for the
principal.  (A database may want to maintain two expiration dates: one
for the principal, and one for the principal's current key.  This
allows password aging to work independently of the principal's
expiration date.  However, due to the limited space in the responses,
the KDC combines the key expiration and principal expiration date
into a single value called 'key_exp', which is used as a hint to the
user to take administrative action.)


The attributes field is a bitfield used to govern the operations
involving the principal.  This field might be useful in conjunction
with user registration procedures, for site-specific policy
implementations (Project Athena currently uses it for their user
registration process controlled by the system-wide database service,
Moira [LGDSR87]), to identify whether a principal can play the role of a
client or server or both, to note whether a server is appropriately
trusted to receive credentials delegated by a client, or to identify
the 'string to key' conversion algorithm used for a principal's
key[22].  Other bits are used to indicate that certain ticket options
should not be allowed in tickets encrypted under a principal's key
(one bit each): Disallow issuing postdated tickets, disallow issuing
forwardable tickets, disallow issuing tickets based on TGT
authentication, disallow issuing renewable tickets, disallow issuing
proxiable tickets, and disallow issuing tickets for which the
principal is the server.


The mod_date field contains the time of last modification of the
entry, and the mod_name field contains the name of the principal which
last modified the entry.

<H3>4.3.  Frequently Changing Fields</H3>

Some KDC implementations may wish to maintain the last time that a
request was made by a particular principal.  Information that might be
maintained includes the time of the last request, the time of the last
request for a ticket-granting ticket, the time of the last use of a
ticket-granting ticket, or other times.  This information can then be
returned to the user in the last-req field (see section 5.2).


Other frequently changing information that can be maintained is the
latest expiration time for any tickets that have been issued using
each key.  This field would be used to indicate how long old keys must
remain valid to allow the continued use of outstanding tickets.

<H3>4.4.  Site Constants</H3>

The KDC implementation should have the following configurable
constants or options, to allow an administrator to make and enforce
policy decisions:

<LI>The minimum supported lifetime (used to determine whether the
KDC_ERR_NEVER_VALID error should be returned).  This constant should
reflect reasonable expectations of round-trip time to the KDC,
encryption/decryption time, and processing time by the client and
target server, and it should allow for a minimum 'useful' lifetime.

<LI>The maximum allowable total (renewable) lifetime of a ticket
(renew_till - starttime).

<LI>The maximum allowable lifetime of a ticket (endtime - starttime).

<LI>Whether to allow the issue of tickets with empty address fields
(including the ability to specify that such tickets may only be issued
if the request specifies some authorization_data).

<LI>Whether proxiable, forwardable, renewable or post-datable tickets
are to be issued.


Changes: Added language about who has access to the keys in the
Kerberos database.

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