From bjaspan@MIT.EDU Tue Nov 19 17:04:45 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA19779 for <bugs@RT-11.MIT.EDU>; Tue, 19 Nov 1996 17:04:45 -0500
Received: from BEEBLEBROX.MIT.EDU by MIT.EDU with SMTP
id AA11533; Tue, 19 Nov 96 17:04:44 EST
Received: by beeblebrox.MIT.EDU (940816.SGI.8.6.9/4.7) id WAA19560; Tue, 19 Nov 1996 22:04:44 GMT
Message-Id: <199611192204.WAA19560@beeblebrox.MIT.EDU>
Date: Tue, 19 Nov 1996 22:04:44 GMT
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: KDB keytab type multiply defined and wrong
X-Send-Pr-Version: 3.99
System: IRIX beeblebrox 5.3 11091812 IP22 mips
The KDB keytab type is defined once in lib/kdb/keytab.c and once in
lib/krb5/keytab/db/dbkeytab.c. The implementations are slightly
different, but I do not believe either one ever worked: the resolve
function expects to take an allocated krb5_db_context as an argument
whereas the krb5_kt_resolve function passes it the residual portion of
the keytab specifier. Furthermore, the string krb5_kt_kdb_ops is
referenced only in those two files and in a ChangeLog, so the code
isn't used anywhere in the source tree.
This code should either be in one place and fixed to work or removed
entirely.
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Tue, 19 Nov 1996 22:05:54 GMT
Oh, one other thing. I did not implement changes to support the
KRB5_KT_KVNONOTFOUND error code in the kdb keytab, because since it
doesn't work and isn't used I can't test the changes.
From: Christopher Provenzano <proven@proven.org>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 11:01:36 -0500
> The KDB keytab type is defined once in lib/kdb/keytab.c and once in
> lib/krb5/keytab/db/dbkeytab.c. The implementations are slightly
> different, but I do not believe either one ever worked: the resolve
> function expects to take an allocated krb5_db_context as an argument
> whereas the krb5_kt_resolve function passes it the residual portion of
> the keytab specifier. Furthermore, the string krb5_kt_kdb_ops is
> referenced only in those two files and in a ChangeLog, so the code
> isn't used anywhere in the source tree.
>
> This code should either be in one place and fixed to work or removed
> entirely.
The one in lib/kdb/keytab.c did work at one time. It was what the old
kadmind used to get the changepw key out of the database. The other
should be deleted from the tree. It was where I originally put the
KDB keytab routines but because of linker problems I had to move it to
the kdb directory. IMO the KDB keytab should be fixed and the kadmind
should be using the KDB keytab instead of groveling through the database
to find the changepw key.
CAP
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: proven@cygnus.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 11:10:26 -0500
The one in lib/kdb/keytab.c did work at one time... the other
should be deleted from the tree.
Thanks.
IMO, the KDB keytab should be fixed and the kadmind
should be using the KDB keytab instead of groveling through the database
to find the changepw key.
kadmin/admin and kadmin/changepw are both extracted into a real keytab
for kadmind to use (however, kadmind quite definately grovels through
and changes the kdb database all the time; that's its job). Now, if
the KDB keytab layer were fixed such that I could (say) set
KRB5_KTNAME to KDC:/<kdc-dir>/principal and not need an external
keytab, that would be fine (and would eliminate one possible way for
kadmind to be mis-configured). Still post-1.0, of course.
Thanks again,
Barry
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 18:31:17 GMT
Having little else to do at the moment, I decided to try to get the
KDB keytab stuff working. The patches were not that complicated, but
it turns out that they cannot work for a deeper reason. The problem
is that kadmind is a GSS-API application. The GSS-API uses its own
krb5_context for talking to the krb5 libraries, instead of using a
context inherited from kadmind proper. kadmind's context has the
master key in it, but GSS-API's does not. The KDB keytab code
requires the master key, but is called by GSS-API, so the master key
is not available. Mission fails.
The only decent way to solve this is to figure out the correct way to
interface mechanism-specific information with the GSS-API. This is
not going to happen in the near future.
I will now argue that the KDB keytab code should be removed from the
tree:
1. kadmind, and perhaps the KDC, are the only two processes that can
realistically use a KDB keytab.
2. kadmind already uses a file-based keytab for
kadmin/{admin,changepw} and it works fine. There is no reason to add
extra code to reimplement working functionality. Furthermore, as
discussed above, there is no simple way to make kadmind use the KDB
keytab anyway.
3. The KDC, too, is already written. If it is changed, it should be
changed to use the kadm5 api, which is designed for accessing the
entire KDB, not the keytab api.
4. Thus, neither program that might sensibly use a KDB keytab will
ever do so. The idea falls into the category of "interesting, but
ultimately not useful." Furthermore, the code does not already work,
and nothing is using it, so it is not worth the effort to fix it.
Comments?
Barry
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: bjaspan@MIT.EDU, krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 16:44:35 -0500
Date: Wed, 20 Nov 1996 18:31:17 GMT
From: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org
Having little else to do at the moment, I decided to try to get the
KDB keytab stuff working. The patches were not that complicated, but
it turns out that they cannot work for a deeper reason. The problem
is that kadmind is a GSS-API application. The GSS-API uses its own
krb5_context for talking to the krb5 libraries, instead of using a
context inherited from kadmind proper. kadmind's context has the
master key in it, but GSS-API's does not. The KDB keytab code
requires the master key, but is called by GSS-API, so the master key
is not available. Mission fails.
Ultimately, we're going to need to specify a krb5-specific API for our
GSSAPI library, for specifying things such as "which keytab to use"
(right now, the kadm library sets a magic global variable which it
happens to know *for* *our* *implementation* will do the right thing).
So in the future we can put in a better API to do the right thing.
2. kadmind already uses a file-based keytab for
kadmin/{admin,changepw} and it works fine. There is no reason to add
extra code to reimplement working functionality. Furthermore, as
discussed above, there is no simple way to make kadmind use the KDB
keytab anyway.
It "works fine" as long as you don't count all of the confused people
who have screwed up because they either don't (a) create the keytab
file, or (b) forget to update the keytab file after changing the kadmin
key. Indeed, we had enough cases of people who lost this way that we
added a new error code to help reduce some of our support load when
people lsot in this fashion.
Post-1.0 we may wish to revisit this and decide whether or not it would
be useful to change kadmind to use the file-base keytab. Once we design
the krb5-specific access functions to our GSSAPI library (which I argue
we will need to do for other reasons), making the job of using the db
keytab to be utterly trivial.
- Ted
From: Christopher Provenzano <proven@proven.org>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org,
proven@pbi.proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 17:45:17 -0500
You could have the keytab resolve routine read the stash file getting the
master key, then open the database and attach all of the db_context info
to a keytab.
How about kprop or for that matter any server running on a machine with
the database. Is there a reason to have the database AND a keytab on the
same machine?
Other than you've lost functionality. The old kadmind did not require
a keytab file.
CAP
From: Mark Eichin <eichin@MIT.EDU>
To: proven@cygnus.com
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, krb5-bugs@MIT.EDU, krbdev@MIT.EDU,
proven@proven.org, proven@pbi.proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: 20 Nov 1996 18:48:19 -0500
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...)
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: proven@cygnus.com
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org,
proven@pbi.proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 23:52:24 GMT
You could have the keytab resolve routine read the stash file getting the
master key, then open the database and attach all of the db_context info
to a keytab.
I thought of that, and it does seem like a possibility. It does,
however, require the keytab layer to know where the stash file is
stored. That is specified in kdc.conf, and might (theoretically) be
overriden on kadmind's command line. So, now we'd need to be able to
pass through the GSS-API info about the keytab and the stash file.
Not ideal.
How about kprop or for that matter any server running on a machine with
the database. Is there a reason to have the database AND a keytab on the
same machine?
Because the keytab code already works, and works well. The KDB keytab
code does not work, and has all the problems I've already mentioned.
I don't see the benefit associated with the cost of fixing it.
Ted argued that having kadmind or other programs use the local kdb
would be easier since they would not have to create a separate keytab.
That's true, but I think not compelling. First, now we'll have to
document both options: a file keytab created separately and a KDB
keytab. Also, if we really wanted to make kadmind installation
simpler, we could write a script to do it. Keytab creation in
particular can be totally automated on the KDC with kadmin.local.
That would be easier, and would simplify the whole kadmind
installation process, not just the keytab creation process.
So, again, I say that the KDB keytab layer is a neat idea, and would
be nice if we already had it, but pretty much the only reason at all
to have it is its coolness factor, and it just isn't *that* cool, so
why bother?
Barry
From: Christopher Provenzano <proven@proven.org>
To: Mark Eichin <eichin@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 22:19:16 -0500
database. I don't see why we are bothering to store it in the database
though.
CAP
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
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Thu, 21 Nov 1996 18:10:01 -0500
Date: Wed, 20 Nov 1996 23:52:24 GMT
From: "Barry Jaspan" <bjaspan@MIT.EDU>
Ted argued that having kadmind or other programs use the local kdb
would be easier since they would not have to create a separate keytab.
That's true, but I think not compelling. First, now we'll have to
document both options: a file keytab created separately and a KDB
keytab. Also, if we really wanted to make kadmind installation
simpler, we could write a script to do it. Keytab creation in
particular can be totally automated on the KDC with kadmin.local.
That would be easier, and would simplify the whole kadmind
installation process, not just the keytab creation process.
Well, if we do this, we wouldn't document the file keytab created
separately, because we wouldn't support that option.
As far as making it easier because we have a kadmind installation
script, is that really going to be good enough? The reason why we have
a new error code for "wrong key version" is because people were
forgetting to re-extrat the admin keytab after they changed it, and that
(according to Barry) this was happening a lot. If this was happening a
lot, it means that people must be wanting to change the admin keys after
the initial installation, correct?
- Ted
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: proven@cygnus.com
Cc: Mark Eichin <eichin@MIT.EDU>, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Thu, 21 Nov 1996 18:15:02 -0500
Date: Wed, 20 Nov 1996 22:19:16 -0500
From: Christopher Provenzano <proven@proven.org>
I think we should; it's a good long-term thing to do.
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.
I don't see why it matters whether or not it is stored in the database,
except for the side issue that we know how to name the master key
(i.e. K/M@REALM).
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. It's also useful for verifying that you
have the correct master key (since the master key is encrpyted in
itself), and this probably also makes it useful if you're trying to
brute-force break the master key. :-)
- Ted
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tytso@MIT.EDU
Cc: proven@cygnus.com, krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org,
proven@pbi.proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Fri, 22 Nov 1996 13:06:30 -0500
As far as making it easier because we have a kadmind installation
script, is that really going to be good enough? The reason why we have
a new error code for "wrong key version" is because people were
forgetting to re-extrat the admin keytab after they changed it, and that
(according to Barry) this was happening a lot. If this was happening a
lot, it means that people must be wanting to change the admin keys after
the initial installation, correct?
That is a good argument, yes.
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 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?
Barry
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tytso@MIT.EDU
Cc: proven@cygnus.com, eichin@MIT.EDU, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Fri, 22 Nov 1996 13:12:24 -0500
Date: Wed, 20 Nov 1996 22:19:16 -0500
From: Christopher Provenzano <proven@proven.org>
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
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
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Fri, 22 Nov 1996 20:44:59 -0500
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
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA19779 for <bugs@RT-11.MIT.EDU>; Tue, 19 Nov 1996 17:04:45 -0500
Received: from BEEBLEBROX.MIT.EDU by MIT.EDU with SMTP
id AA11533; Tue, 19 Nov 96 17:04:44 EST
Received: by beeblebrox.MIT.EDU (940816.SGI.8.6.9/4.7) id WAA19560; Tue, 19 Nov 1996 22:04:44 GMT
Message-Id: <199611192204.WAA19560@beeblebrox.MIT.EDU>
Date: Tue, 19 Nov 1996 22:04:44 GMT
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: KDB keytab type multiply defined and wrong
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 207
>Category: krb5-libs
>Synopsis: KDB keytab type multiply defined and wrong
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Nov 19 17:05:01 EST 1996
>Last-Modified: Fri Nov 22 20:46:01 EST 1996
>Originator: Barry Jaspan
>Organization:
mit>Category: krb5-libs
>Synopsis: KDB keytab type multiply defined and wrong
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Nov 19 17:05:01 EST 1996
>Last-Modified: Fri Nov 22 20:46:01 EST 1996
>Originator: Barry Jaspan
>Organization:
Show quoted text
>Release: 1.0-development
>Environment:
>Environment:
System: IRIX beeblebrox 5.3 11091812 IP22 mips
Show quoted text
>Description:
The KDB keytab type is defined once in lib/kdb/keytab.c and once in
lib/krb5/keytab/db/dbkeytab.c. The implementations are slightly
different, but I do not believe either one ever worked: the resolve
function expects to take an allocated krb5_db_context as an argument
whereas the krb5_kt_resolve function passes it the residual portion of
the keytab specifier. Furthermore, the string krb5_kt_kdb_ops is
referenced only in those two files and in a ChangeLog, so the code
isn't used anywhere in the source tree.
This code should either be in one place and fixed to work or removed
entirely.
Show quoted text
>How-To-Repeat:
Show quoted text
>Fix:
Show quoted text
>Audit-Trail:
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Tue, 19 Nov 1996 22:05:54 GMT
Oh, one other thing. I did not implement changes to support the
KRB5_KT_KVNONOTFOUND error code in the kdb keytab, because since it
doesn't work and isn't used I can't test the changes.
From: Christopher Provenzano <proven@proven.org>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 11:01:36 -0500
Show quoted text
> >Description:
> > The KDB keytab type is defined once in lib/kdb/keytab.c and once in
> lib/krb5/keytab/db/dbkeytab.c. The implementations are slightly
> different, but I do not believe either one ever worked: the resolve
> function expects to take an allocated krb5_db_context as an argument
> whereas the krb5_kt_resolve function passes it the residual portion of
> the keytab specifier. Furthermore, the string krb5_kt_kdb_ops is
> referenced only in those two files and in a ChangeLog, so the code
> isn't used anywhere in the source tree.
>
> This code should either be in one place and fixed to work or removed
> entirely.
The one in lib/kdb/keytab.c did work at one time. It was what the old
kadmind used to get the changepw key out of the database. The other
should be deleted from the tree. It was where I originally put the
KDB keytab routines but because of linker problems I had to move it to
the kdb directory. IMO the KDB keytab should be fixed and the kadmind
should be using the KDB keytab instead of groveling through the database
to find the changepw key.
CAP
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: proven@cygnus.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 11:10:26 -0500
The one in lib/kdb/keytab.c did work at one time... the other
should be deleted from the tree.
Thanks.
IMO, the KDB keytab should be fixed and the kadmind
should be using the KDB keytab instead of groveling through the database
to find the changepw key.
kadmin/admin and kadmin/changepw are both extracted into a real keytab
for kadmind to use (however, kadmind quite definately grovels through
and changes the kdb database all the time; that's its job). Now, if
the KDB keytab layer were fixed such that I could (say) set
KRB5_KTNAME to KDC:/<kdc-dir>/principal and not need an external
keytab, that would be fine (and would eliminate one possible way for
kadmind to be mis-configured). Still post-1.0, of course.
Thanks again,
Barry
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 18:31:17 GMT
Having little else to do at the moment, I decided to try to get the
KDB keytab stuff working. The patches were not that complicated, but
it turns out that they cannot work for a deeper reason. The problem
is that kadmind is a GSS-API application. The GSS-API uses its own
krb5_context for talking to the krb5 libraries, instead of using a
context inherited from kadmind proper. kadmind's context has the
master key in it, but GSS-API's does not. The KDB keytab code
requires the master key, but is called by GSS-API, so the master key
is not available. Mission fails.
The only decent way to solve this is to figure out the correct way to
interface mechanism-specific information with the GSS-API. This is
not going to happen in the near future.
I will now argue that the KDB keytab code should be removed from the
tree:
1. kadmind, and perhaps the KDC, are the only two processes that can
realistically use a KDB keytab.
2. kadmind already uses a file-based keytab for
kadmin/{admin,changepw} and it works fine. There is no reason to add
extra code to reimplement working functionality. Furthermore, as
discussed above, there is no simple way to make kadmind use the KDB
keytab anyway.
3. The KDC, too, is already written. If it is changed, it should be
changed to use the kadm5 api, which is designed for accessing the
entire KDB, not the keytab api.
4. Thus, neither program that might sensibly use a KDB keytab will
ever do so. The idea falls into the category of "interesting, but
ultimately not useful." Furthermore, the code does not already work,
and nothing is using it, so it is not worth the effort to fix it.
Comments?
Barry
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: bjaspan@MIT.EDU, krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 16:44:35 -0500
Date: Wed, 20 Nov 1996 18:31:17 GMT
From: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org
Having little else to do at the moment, I decided to try to get the
KDB keytab stuff working. The patches were not that complicated, but
it turns out that they cannot work for a deeper reason. The problem
is that kadmind is a GSS-API application. The GSS-API uses its own
krb5_context for talking to the krb5 libraries, instead of using a
context inherited from kadmind proper. kadmind's context has the
master key in it, but GSS-API's does not. The KDB keytab code
requires the master key, but is called by GSS-API, so the master key
is not available. Mission fails.
Ultimately, we're going to need to specify a krb5-specific API for our
GSSAPI library, for specifying things such as "which keytab to use"
(right now, the kadm library sets a magic global variable which it
happens to know *for* *our* *implementation* will do the right thing).
So in the future we can put in a better API to do the right thing.
2. kadmind already uses a file-based keytab for
kadmin/{admin,changepw} and it works fine. There is no reason to add
extra code to reimplement working functionality. Furthermore, as
discussed above, there is no simple way to make kadmind use the KDB
keytab anyway.
It "works fine" as long as you don't count all of the confused people
who have screwed up because they either don't (a) create the keytab
file, or (b) forget to update the keytab file after changing the kadmin
key. Indeed, we had enough cases of people who lost this way that we
added a new error code to help reduce some of our support load when
people lsot in this fashion.
Post-1.0 we may wish to revisit this and decide whether or not it would
be useful to change kadmind to use the file-base keytab. Once we design
the krb5-specific access functions to our GSSAPI library (which I argue
we will need to do for other reasons), making the job of using the db
keytab to be utterly trivial.
- Ted
From: Christopher Provenzano <proven@proven.org>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org,
proven@pbi.proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 17:45:17 -0500
Show quoted text
>
> Having little else to do at the moment, I decided to try to get the
> KDB keytab stuff working. The patches were not that complicated, but
> it turns out that they cannot work for a deeper reason. The problem
> is that kadmind is a GSS-API application. The GSS-API uses its own
> krb5_context for talking to the krb5 libraries, instead of using a
> context inherited from kadmind proper. kadmind's context has the
> master key in it, but GSS-API's does not. The KDB keytab code
> requires the master key, but is called by GSS-API, so the master key
> is not available. Mission fails.
>
> The only decent way to solve this is to figure out the correct way to
> interface mechanism-specific information with the GSS-API. This is
> not going to happen in the near future.
> Having little else to do at the moment, I decided to try to get the
> KDB keytab stuff working. The patches were not that complicated, but
> it turns out that they cannot work for a deeper reason. The problem
> is that kadmind is a GSS-API application. The GSS-API uses its own
> krb5_context for talking to the krb5 libraries, instead of using a
> context inherited from kadmind proper. kadmind's context has the
> master key in it, but GSS-API's does not. The KDB keytab code
> requires the master key, but is called by GSS-API, so the master key
> is not available. Mission fails.
>
> The only decent way to solve this is to figure out the correct way to
> interface mechanism-specific information with the GSS-API. This is
> not going to happen in the near future.
You could have the keytab resolve routine read the stash file getting the
master key, then open the database and attach all of the db_context info
to a keytab.
Show quoted text
>
> I will now argue that the KDB keytab code should be removed from the
> tree:
>
> 1. kadmind, and perhaps the KDC, are the only two processes that can
> realistically use a KDB keytab.
> I will now argue that the KDB keytab code should be removed from the
> tree:
>
> 1. kadmind, and perhaps the KDC, are the only two processes that can
> realistically use a KDB keytab.
How about kprop or for that matter any server running on a machine with
the database. Is there a reason to have the database AND a keytab on the
same machine?
Show quoted text
>
> 2. kadmind already uses a file-based keytab for
> kadmin/{admin,changepw} and it works fine. There is no reason to add
> extra code to reimplement working functionality. Furthermore, as
> discussed above, there is no simple way to make kadmind use the KDB
> keytab anyway.
> 2. kadmind already uses a file-based keytab for
> kadmin/{admin,changepw} and it works fine. There is no reason to add
> extra code to reimplement working functionality. Furthermore, as
> discussed above, there is no simple way to make kadmind use the KDB
> keytab anyway.
Other than you've lost functionality. The old kadmind did not require
a keytab file.
CAP
From: Mark Eichin <eichin@MIT.EDU>
To: proven@cygnus.com
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, krb5-bugs@MIT.EDU, krbdev@MIT.EDU,
proven@proven.org, proven@pbi.proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: 20 Nov 1996 18:48:19 -0500
Show quoted text
> You could have the keytab resolve routine read the stash file getting the
> master key, then open the database and attach all of the db_context info
> to a keytab.
> master key, then open the database and attach all of the db_context info
> to a keytab.
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...)
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: proven@cygnus.com
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org,
proven@pbi.proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 23:52:24 GMT
You could have the keytab resolve routine read the stash file getting the
master key, then open the database and attach all of the db_context info
to a keytab.
I thought of that, and it does seem like a possibility. It does,
however, require the keytab layer to know where the stash file is
stored. That is specified in kdc.conf, and might (theoretically) be
overriden on kadmind's command line. So, now we'd need to be able to
pass through the GSS-API info about the keytab and the stash file.
Not ideal.
How about kprop or for that matter any server running on a machine with
the database. Is there a reason to have the database AND a keytab on the
same machine?
Because the keytab code already works, and works well. The KDB keytab
code does not work, and has all the problems I've already mentioned.
I don't see the benefit associated with the cost of fixing it.
Ted argued that having kadmind or other programs use the local kdb
would be easier since they would not have to create a separate keytab.
That's true, but I think not compelling. First, now we'll have to
document both options: a file keytab created separately and a KDB
keytab. Also, if we really wanted to make kadmind installation
simpler, we could write a script to do it. Keytab creation in
particular can be totally automated on the KDC with kadmin.local.
That would be easier, and would simplify the whole kadmind
installation process, not just the keytab creation process.
So, again, I say that the KDB keytab layer is a neat idea, and would
be nice if we already had it, but pretty much the only reason at all
to have it is its coolness factor, and it just isn't *that* cool, so
why bother?
Barry
From: Christopher Provenzano <proven@proven.org>
To: Mark Eichin <eichin@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Wed, 20 Nov 1996 22:19:16 -0500
Show quoted text
>
> 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...)
>
Having it as a keytab is better if the key is actually stored in the > > You could have the keytab resolve routine read the stash file getting the
> > master key, then open the database and attach all of the db_context info
> > to a keytab.
> > > master key, then open the database and attach all of the db_context info
> > to a keytab.
> 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...)
>
database. I don't see why we are bothering to store it in the database
though.
CAP
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
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Thu, 21 Nov 1996 18:10:01 -0500
Date: Wed, 20 Nov 1996 23:52:24 GMT
From: "Barry Jaspan" <bjaspan@MIT.EDU>
Ted argued that having kadmind or other programs use the local kdb
would be easier since they would not have to create a separate keytab.
That's true, but I think not compelling. First, now we'll have to
document both options: a file keytab created separately and a KDB
keytab. Also, if we really wanted to make kadmind installation
simpler, we could write a script to do it. Keytab creation in
particular can be totally automated on the KDC with kadmin.local.
That would be easier, and would simplify the whole kadmind
installation process, not just the keytab creation process.
Well, if we do this, we wouldn't document the file keytab created
separately, because we wouldn't support that option.
As far as making it easier because we have a kadmind installation
script, is that really going to be good enough? The reason why we have
a new error code for "wrong key version" is because people were
forgetting to re-extrat the admin keytab after they changed it, and that
(according to Barry) this was happening a lot. If this was happening a
lot, it means that people must be wanting to change the admin keys after
the initial installation, correct?
- Ted
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: proven@cygnus.com
Cc: Mark Eichin <eichin@MIT.EDU>, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Thu, 21 Nov 1996 18:15:02 -0500
Date: Wed, 20 Nov 1996 22:19:16 -0500
From: Christopher Provenzano <proven@proven.org>
Show quoted text
> 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...)
> 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.
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.
I don't see why it matters whether or not it is stored in the database,
except for the side issue that we know how to name the master key
(i.e. K/M@REALM).
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. It's also useful for verifying that you
have the correct master key (since the master key is encrpyted in
itself), and this probably also makes it useful if you're trying to
brute-force break the master key. :-)
- Ted
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tytso@MIT.EDU
Cc: proven@cygnus.com, krb5-bugs@MIT.EDU, krbdev@MIT.EDU, proven@proven.org,
proven@pbi.proven.org
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Fri, 22 Nov 1996 13:06:30 -0500
As far as making it easier because we have a kadmind installation
script, is that really going to be good enough? The reason why we have
a new error code for "wrong key version" is because people were
forgetting to re-extrat the admin keytab after they changed it, and that
(according to Barry) this was happening a lot. If this was happening a
lot, it means that people must be wanting to change the admin keys after
the initial installation, correct?
That is a good argument, yes.
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 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?
Barry
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tytso@MIT.EDU
Cc: proven@cygnus.com, eichin@MIT.EDU, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Fri, 22 Nov 1996 13:12:24 -0500
Date: Wed, 20 Nov 1996 22:19:16 -0500
From: Christopher Provenzano <proven@proven.org>
Show quoted text
> 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...)
> 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
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
Subject: Re: krb5-libs/207: KDB keytab type multiply defined and wrong
Date: Fri, 22 Nov 1996 20:44:59 -0500
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
Show quoted text
>Unformatted: