Multiple ETYPE-INFO-ENTRY with same etype but different salts
ghudson at MIT.EDU
Mon Jul 18 00:06:39 EDT 2011
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
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
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.
More information about the krbdev