Enctype configuration

Greg Hudson ghudson at MIT.EDU
Fri Jul 24 16:22:11 EDT 2009


On Thu, 2009-07-23 at 09:56 -0400, Sam Hartman wrote:
> My initial reaction to changing supported_enctypes and dropping salt
> was negative.  However after examining my reaction I found no
> justification other than resistance to change, so that sounds good
> too.

I found two complications with random explicit salt generation:

1. It breaks our current implementation of password history checking
(unless the principal has rc4-hmac keys, which don't use the salt in
string2key).  I think password history checking could be improved to try
encrypting the new key in the historical salts.

2. As noted in RFC 4120, "it is not possible to generate a user's key
reliably given a pass phrase without contacting the KDC, since it will
not be known whether alternate salt or parameter values are required."
However, you can guess that the salt is the mangled principal, and our
ktutil addent -password command does exactly that.  That guess is wrong
if the admin used any non-NORMAL salt type when creating the principal,
or the principal has been renamed (you can't rename a NORMAL-salted
principal right now, but you could if we processed the patch in RT
#6323)... but in the usual case, the guess is right.  That would cease
to be true if we switched to explicit random salts.

It should be possible to modify ktutil to contact the KDC, assuming that
salt information is present in PREAUTH_REQUIRED errors, which seems to
be true according to a scan of the RFC.

If I can resolve these problems with reasonable effort, I will go ahead
and stick with the plan.  Hopefully this won't turn into one of those
home repair projects where you start out doing something simple and wind
up doing major remodeling.





More information about the krbdev mailing list