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

[Greg Hudson]

I've looked into this further, and there appear to be at least two
things going on:

1. I suspect Java doesn't implement the AFS string-to-key algorithm.
This is indicated by a salt string containing the realm name and a
one-byte s2kparams containing the octet 0x1.  This is a non-standard
extension in MIT krb5 (and Heimdal) for the benefit of AFS.

2. From what Weijun says, Java chooses to skip over the entry with the
empty salt string.  I can't think of any good reason for this.

The MIT krb5 KDC tries all matching keys when processing
encrypted-timestamp data, so returning multiple des-cbc-crc etype-info2
padata entries is not the source of the problem.

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

The v4 salt type is intended to create a key which can be used with both
krb4 and krb5.  Forbidding its use with krb5 would almost certainly
break existing deployments.

Martin Smith wrote:
> 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

I don't know the history of des-hmac-sha1, but I don't believe it's a
standard enctype.  Java is probably ignoring this entry.

I would expect Java to favor the des3-hmac-sha1 or arcfour-hmac
etype-info2 entries over the DES ones.  I don't know why this isn't
happening.

I would expect the des-cbc-md5:normal to result in an etype-info2 entry
with no specified salt (which means the default salt).  I don't know why
Java isn't choosing this entry.