Multiple ETYPE-INFO-ENTRY with same etype but different salts
weijun.wang at oracle.com
Fri Jul 15 09:59:36 EDT 2011
Thanks for the answer.
Do you have any insight why that last salt is "XXX.EDU"? Is it also
related to krb4?
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.
More information about the krbdev