Enctype configuration

[Ken Raeburn]

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  
> try
> 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  
> 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.

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  
> that
> 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  
good start.

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?

Ken