Multiple ETYPE-INFO-ENTRY with same etype but different salts

[Weijun Wang]

On Jul 17, 2011, at 10:09 PM, Martin B. Smith wrote:

> On 07/17/2011 03:18 AM, Weijun Wang wrote:
>>> In this case, the etype-info2 entries are determined by the keys in
>>> >  the KDB records.  The KDC administrator could change the
>>> >  supported_enctypes variable to include only one des-cbc-crc entry and
>>> >  then have the affected users change their passwords.
>> The customer has tens of thousands of existing accounts and cannot do a
>> simple password reset. Is it possible to remove the ETYPE-INFO-ENTRY
>> with only realm as salt by reconfigure the KDC? Or, is there a tool to
>> clean up the KDC records automatically?
>> 
>> Thanks
>> Max
> 
> Hi Greg & all,
> 
> First of all, thank you *very* much for your help with this issue. It's been a severe hold-up for us in terms of upgrading various kerberized clients (specifically Java).
> 
> Doesn't removing the offending enctype that is putting bad salts in the KDB records just mask a bug with that enctype? We have brand new principals that are affected by this issue every day, so it seems like one of the enctypes is actually broken if it's generating invalid salt values.
> 
> Our current list of supported enctype is:
> 
> supported_enctypes =  des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:v4 des-cbc-crc:afs3 des3-hmac-sha1:normal arcfour-hmac:normal
> 
> As you can see, I think we *are* already listing 'normal' ones first. How would you re-order that list to fix the problem? Would you just remove the two latter des- entries?

Hi Martin

Do you need to keep the "des-cbc-crc:v4 des-cbc-crc:afs3" entries there?

This is not a problem of re-ordering. Your ETYPE-INFO already places the entry with the wrong salt at the end of the list. The problem here is that Java insists on reading a non-empty and non-missing salt from the list. Therefore, unless you completely remove the wrong entry (or, manage to insert an entry with the correct salt before it), Java will always use the wrong salt.

I think the bug here is that even if some-etype:v4 exists in the supported_enctypes, the KDC should not generate an ETYPE-INFO-ENTRY for it in a response to a v5 AS-REQ.

Thanks
Max


> 
> Thanks again,
> -- 
> Martin B. Smith
> smithmb at ufl.edu - (352) 273-1374
> CNS/Open Systems Group
> University of Florida
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev