directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [Kerberos] FYI, draft Kerberos schema
Date Thu, 17 May 2007 12:46:34 GMT
On May 13,  8:52pm, "Apache Directory Developers List" wrote:
} Subject: Re: [Kerberos] FYI, draft Kerberos schema

Good morning to everyone, I hope your respective weeks are going well.

First of all kudos to Enrique for his efforts on the Kerberos
implementation.  I've probably been as deep inside general Kerberos
issues as anyone.  Much of this stuff is vague and only characterized
by implementation(s).  It is a non-trivial exercise to get things
functional yet alone interoperable.

> On 5/10/07, Enrique Rodriguez <> wrote:
> > ...
> > I pinged the Novell authors, since the author of [2] is also at
> > Novell, so maybe there's no need for the overlap in password policy
> > and I was curious if they had any thoughts on licensing.

> I found another issue with the Kerberos schema [1].  They don't
> store the time at which keys were created.  When a key is exported
> from a store to a keytab file, eg for use on a service host, the
> keytab entry for each key has a timestamp field representing the
> time at which the key was created.  I couldn't see how to determine
> the time at which a key is created from the proposed schema, so I
> reported this to the authors at Novell.

> There is a 'krbLastPwdChange' which one could assume is the time the
> keys were created, but this would only apply to keys derived from
> passwords.  The semantics would be wrong for random keys generated
> for a service host.

The problem being struggled with may be an issue of semantics.  I
believe the correct definition for the time in the keytab file is the
last password change time.

In the MIT implementation there are essentially two dates carried in
the database:

	- last date of modification of the principal

	- last password change

Since a password is really implemented as symmetric encryption key(s)
the last password change time is effectively the date of creation of
the keys.  One has to consider this in the context of how service keys
are used.

In the current MIT implementation the extraction of a service key,
eg. host/fqdn@REALM, onto a host results in generation and insertion
of a random key into the database.  This random key is what is
inserted into the keytab file.  I believe it would be technically
correct to carry this date as the last password change for the
principal and to propagate the date into the keytab file.

The MIT command-line interface has a -randkey switch which is used
when service principals are created.  This causes a random key to be
generated and stored for the principal in order to avoid the need for
the administrator to enter a password for that key.

The random key generated at principal creation time is actually
irrelevant since it will be re-randomized at extraction time.  So the
time of extraction randomization is effectively the last password
change for a service principal.

All of this is a security measure to defeat a quasi man-in-the-middle
attack if the administrative interface to a KDC were to be
compromised.  The process of extracting service keys needed to
impersonate a server invalidates the real server's credentials, a
readily detectable event.

This randomization at time of extraction is something which generally
plagues young Kerberos administrators.  In an attempt to get things
working keys are sometimes extracted multiple times.  If the
administrator does not do a a full credential refresh they can get
into an infinite loop of continually breaking their implementation
while they are trying to get it working.

All of this is why standard advice to anyone working on Kerberos
access problems is to always check that the KVNO's (key version
numbers) in the keytabs match the value in the KDC data repository.
The KVNO's are incremented each time the symmetric keys are updated,
either through a password change or extraction randomization.

> Enrique

Hopefully the above information is helpful.

Greetings and continued best wishes for the success of your project
from the Northern Plains.

}-- End of excerpt from "Apache Directory Developers List"

As always,
Greg Wettstein

			 The Hurderos Project
         Open Identity, Service and Authorization Management

"My spin on the meeting?  I lie somewhere between the individual who
 feels that we are all going to join hands and march forward carrying
 the organization into the information age and Dr. Wettstein.  Who
 feels that they are holding secret meetings at 6 o'clock in the
 morning plotting strategy on how to replace our system."
                                -- Paul S. Etzell, M.D.
                                   Medical Director, Roger Maris Cancer Center

View raw message