[7456] in Kerberos
Re: av4k?
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Tue Jun 11 11:33:05 1996
Date: Tue, 11 Jun 1996 11:16:24 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: Dave McGuire <mcguire@rocinante.digex.net>
Cc: Sam Hartman <hartmans@MIT.EDU>, kerberos@MIT.EDU
In-Reply-To: [7445]
From: Dave McGuire <mcguire@rocinante.digex.net>
Cc: kerberos@MIT.EDU
> Dave> Ummm.....ok....in the beta6 kdb5_edit...what happened to
> Dave> av4k? It doesn't seem to be there anymore.
>
> Basically, in kdc.conf, there is a supported keytypes/salt-types
> configuration option...
But won't that make *all* my keys "v4" keys if that's the default
and I just use "ank"? Somehow that strikes me as a bad thing. Is it?
The application is cross-realm authentication, by the way, in case
there's now a better way to do it.
(1) The salt for a principal is used by the string-to-key algorithm.
It exists so that a principal that exists in two realms with the same
password will not have the same key; thus, if you discover a
principal's key in one realm (but not its password), you will not be
able to impersonate the principal in the other realm. If you discover
a principal's actual password, of course, the game is up and you can
impersonate that principal in both realms. "V4 salt" is no salt,
which means that a principal with the same password in two realms
*will* have the same key in both realms. So yes, if you think that
the protection salt provides you is valuable, having all principals
have a V4 salt key is "bad". However, I don't think it should keep
you up at night.
(2) If it does keep you up at night, there is a way to have your
cross-realm keys have no salt without having all principals have
no-salt keys. Do not put a V4 salt type in the KDC configuration file
(kdc.conf), so that principals will not have V4 salt by default. When
you run kdb5_edit to create the cross-realm principal, set the
KRB5_KDC_PROFILE environment variable to the path of a different
kdc.conf file (e.g. /krb5/kdc.conf.with.v4.salt) that does list the V4
salt type; that way, the cross-realm principal will be created with V4
salt.
(3) The new admin system will have an easier way to accomplish (2).
Basically, instead of having to set the environment variable to point
to a separate kdc.conf variable, you'll just be able to specify a
command-line argument to kadmin.local (the new equivalent of
kdb5_edit) that specifies the keysalt tuples to use. This feature
could be pretty easily added to kdb5_edit, too.
(4) The new admin system has password policies, and every principal
can have a policy assigned to it. Key salt tuples to use are not
currently part of the password policy, but they ought to be (there are
a number of other fields that should be added to the policies, but I'm
not doing that in the interest of getting the first version released
as soon as possible). The admin system does have a versioning
mechanism in place so that it will be relatively painless to add new
fields to password policies in the future in a compatible manner.
Barry
