raeburn at MIT.EDU
Fri Jul 24 20:38:37 EDT 2009
On Jul 24, 2009, at 16:22, Greg Hudson wrote:
> 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
> encrypting the new key in the historical salts.
Interesting... that aspect had escaped me. Since using the wrong salt
means basically no chance of matching the old keys, and AFAIK we
already support changing salts (just not automatically and randomly),
I'd say this is an existing bug.
> 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
> if the admin used any non-NORMAL salt type when creating the
> 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.
Yep. Other theoretical cases are possible where you'd make the same
assumption, but this is probably the important one. In proposing
randomized salts before, I assumed that service passwords would use
NORMAL salts instead.
> It should be possible to modify ktutil to contact the KDC, assuming
> salt information is present in PREAUTH_REQUIRED errors, which seems to
> be true according to a scan of the RFC.
I like this. Some issues occur to me though:
1) With PREAUTH_REQUIRED, a simple denial-of-service attack is
possible by forging the KDC reply; ktutil gets the wrong salt, does no
validation, and stores the wrong key, and the admin happily goes about
his business. Getting and decrypting initial credentials would be a
2) If canonicalization and referrals are enabled for this validation,
either ktutil should check that the name didn't actually change, or it
faces the same issues as I've written up in the past for kinit on the
IETF list (e.g., careless admin reuses passwords, forged reply alters
name and salt). I'm not sure if it actually gets an attacker anything
in this case beyond a denial of service, but breaking the service's
keytabs could be bad enough. If canonicalization is disabled in this
request, I think just decrypting the AS-REP will be sufficient; the
admin is not likely to be cooperating with a forger on the wire, so we
don't need to worry about the Zanarotti attack. I'm not sure offhand
what ought to happen if the admin supplies a name that's an alias
instead of the canonical name; answering that might suggest whether
canonicalization should be disabled or not.
3) A chicken-and-egg problem for key rollover: Is the new key enabled
in the database before or after running ktutil? If it's enabled
before, there's an obvious window where the service won't work with
newly-issued credentials. If it's enabled after, how do you get the
salt for the new password?
More information about the krbdev