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

[Weijun Wang]

Thanks for the answer.

Do you have any insight why that last salt is "XXX.EDU"? Is it also 
related to krb4?

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