Subject: Section 4 (take 2) Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Mon, 13 Nov 2000 21:59:03 -0800 (PST)

Attached is section 4 with changes incorporated.  The only changes
(other than editorial and formatting changes) are regarding the
discussion on the list about the use of tamper resistant hardware to
store keys.  The opening paragraph was changed so as not to preclude
such use, and to make it clear that in some implementation (e.g. those
using special hardware) it might not be possible to extract a long
term key from the database.

If the changes are acceptable and I hear no ojections, I would like to
consider discussion on section 4 closed shortly.

The web page with the latest version of each section can be found at:

   http://www.isi.edu/people/bcn/krb-revisions/

Here is section 4.

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.  Specific
implementations may handle the storage of keying material separate
from the Kerberos database (e.g. in hardware) or by encrypting the
keying material before placing it in the Kerberos database.  Some
implementations might provide a means for using long term secret keys,
but not for retrieving them from the Kerberos database.

<H3>4.1.  Database contents</H3>

A database entry will typically contain the following fields, though
in some instances a KDC may obtain these values through other means:

<PRE>
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
</PRE>

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
Ticket.)

<P>

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
name.

<P>

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.

<P>

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
database:

<PRE>
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
</PRE>

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

<P>

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.)

<P>

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.

<P>

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).

<P>

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:

<UL>
<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.
</UL>

<HR>

<H1>Commentary</H1>

Changes: Added language about who has access to the keys in the
Kerberos database.  Also made it clear that KDC's may obtain the
information from some database field through other means - for
example, one form of pkinit may extract some of these fields from a
certificate.

<P>

Regarding the discussion on the list regarding the use of tamper
resistant hardware to store keys, I was not able to determine specific
suggested changes to the text in the RFC regarding this.  Much of this
discussion centers around particular implementations.  I did however
loosen the wording about the database so as not to preclude keys that
can not be extracted in the clear from such hardware.