[kerberos-discuss] removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008]

[Nicolas Williams]

On Tue, Jun 03, 2008 at 10:58:29AM -0400, James Carlson wrote:
> I guess I was thinking more about what happens when things are
> restored from backup; the key will always be the one in the db, even
> if a different one is (somehow) given elsewhere.  Perhaps that just
> doesn't happen in practice ...

The KDB is the authoritative DB.  kadm5.keytab can be seen as a "cache"
that administrators previously had to _manually_ keep in sync with the
KDB.

Keytabs can be seen as a subset of the KDB.  Remember, Kerberos V is a
protocol where principals share secret keys with the KDC; the KDB is the
database where the KDC stores the keys it shares with all its
principals.  Users, of course, just remember their passwords and the
system derives their keys therefrom.  Non-human principals store their
keys in a local key store; for MIT krb5-derived implementations that
would be a "keytab" file.

Now, kadmind *always* has direct access to the KDB, so it shouldn't ever
have needed any keytabs: it has direct access to the relevant keys via
the KDB!

kadm5.keytab was only ever needed because the relevant code
infrastructure (pertaining to the AP exchange part of the protocol)
didn't support looking for keys in the KDB.  MIT krb5 1.6.3 fixes this.
That fix renders kadm5.keytab no longer necessary.

There is nothing that administrators can do to kadm5.keytab via the
usual admin utilities (kadmin(1M) and kadmin.local(1M)) that wouldn't
also update the KDB anyways.  (Very knowledgeable admins could use
ktutil(1), which doesn't update the KDB, but savvy admins just wouldn't
do that for kadm5.keytab maintenance.)

Nico
--