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

[Weijun Wang]

> 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


On 07/15/2011 09:16 PM, Greg Hudson wrote:
> On Fri, 2011-07-15 at 03:21 -0400, Weijun Wang wrote:
>> I lookup RFC 4120 and there is no spec on what to do when there
>> are multiple ETYPE-INFO-ENTRYs with the same etype but different
>> salts. What shall I do now?
>
> MIT krb5 uses the first entry for the most preferred enctype it can
> find in the sequence.  (That is, we iterate over our enctype
> preference list; for each enctype we search the etype-info2 sequence
> for an entry with that enctype, and we use the first entry we find.)
>
> Heimdal appears to do the same thing.
>
>> Or, is there a way to reconfigure their KDC and avoid such a
>> response?
>
> That's hard to answer with confidence without more information about
> the KDC, but I'll go ahead and speculate that it's an MIT krb5 KDC
> with a history of supporting krb4.
>
> 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.
>
> It's arguably a bug that we return multiple etype-info2 entries with
> the same enctype, and then (I assume) only try the first key entry
> matching the enctype when decrypting an encrypted-timestamp preauth
> request.  We should either prune the etype-info2 entries to one per
> enctype, or try multiple keys against a preauth request.
>