[1999] in Kerberos_V5_Development
Re: krb5-libs/207: KDB keytab type multiply defined and wrong
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Fri Nov 22 13:13:55 1996
Date: Fri, 22 Nov 1996 13:12:24 -0500
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tytso@MIT.EDU
Cc: proven@cygnus.com, eichin@MIT.EDU, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <9611212315.AA01396@dcl.MIT.EDU> (tytso@MIT.EDU)
Date: Wed, 20 Nov 1996 22:19:16 -0500
From: Christopher Provenzano <proven@proven.org>
> Which reminds me -- I filed an MIT pr on this, I think, but it should
> probably be discussed -- any good reason that the stash file isn't
> just a normal keytab? (stash files have a number of evil properties,
> such as host-dependence...)
I think we should; it's a good long-term thing to do.
Putting the master key in a keytab is certainly appealing. I'd
suggest making this change (if we ever do) within the current API and
user interface for simplicity. So, "kdb5_util stash" would still
work, and would still use the "stash_file" relation in kdc.conf, it
would just happen to create a keytab-format file. All the mkey setup,
verify, etc. functions can also retain their interface.
We would also need a way to convert an existing stash file into a
keytab, for compatibility. This could be another kdb5_util command,
and wouldn't be too hard to write.
Having it as a keytab is better if the key is actually stored in the
database. I don't see why we are bothering to store it in the database
though.
It's stored there mostly for historical reasons, although the database
fields for the master key are significant --- they're the default values
when creating a new principal.
This used to be true, but isn't any more. The default principal field
values come from kdc.conf, and if they are not specified in kdc.conf
they come from compile-time defaults. Look in
lib/kadm5/srv/svr_principal.c (kadm5_create_principal) and
lib/kadm5/alt_prof.c (kadm5_get_config_params).
Barry
