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

[Greg Hudson]

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.