[2002] in Kerberos_V5_Development
Re: krb5-libs/207: KDB keytab type multiply defined and wrong
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Nov 22 20:45:22 1996
Date: Fri, 22 Nov 1996 20:44:59 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: proven@cygnus.com, krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org,
proven@pbi.proven.org
In-Reply-To: Barry Jaspan's message of Fri, 22 Nov 1996 13:06:30 -0500,
<9611221806.AA06223@DUN-DUN-NOODLES.MIT.EDU>
Date: Fri, 22 Nov 1996 13:06:30 -0500
From: "Barry Jaspan" <bjaspan@MIT.EDU>
But again, I point out that no one here knows any practical way to
make the KDB keytab layer work. So, while it might be a good idea, it
is currently impossible and therefore out of the question. Making it
work will require krb5 GSS-API design changes, possibly requiring
careful coordination with other krb5 and GSS-API providers as well as
with the standarization process, so it will not be done soon.
I don't think this is hard, actually. We're going to have to have an
MIT-specific krb5 API for the GSSAPI. It does *not* have to be the same
as what other krb5 GSSAPI providers will be providing, although
admittedly this is a good thing.
As long as we don't use things which are specific to the MIT
implementation, I doubt there'll be any problem with specifying the
API. While it will require work, I don't think any of it is
particularily hard.
And, whether we do the keytab layer or not, we're going to want to
define some part of this API anyway....
I thought of another option. If having kadmind depend on a
user-created keytab is too much hassle, kadmind can simply extract the
keytab file itself every time it is run. The kadm5 server libraries
can extract the keys without changing them; it could then just
overwrite the keytab file specified in kdc.conf with entries that are
guarnanteed to be right. Comments?
That's a nice option. It certainly would work....
- Ted
