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

[Weijun Wang]

Hi Greg

Thanks for your investigation.

On Jul 18, 2011, at 12:06 PM, Greg Hudson wrote:

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

No.

So if Java does not support AFS, it should simply ignore this entry? Please conform that the correct procedure should look like:

1. Java sees both ETYPE-INFO and ETYPE-INFO2 in KRB-ERROR, now it should ignore ETYPE-INFO at all (coz it also contains a (1,"REALM") entry)
2. Now the last entry in ETYPE-INFO2 has a 0x1 s2kparams which Java does not support, it should ignore this entry too
3. The other 2 entries have salt missing or empty, so the default salt should be used
4. Of course, in this case, Java can also only look at the 1st entry

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

Well, very unfortunately, Java has an internal assumption that if there is a different salt other than the default one, it should be the same for all etypes. So Java only save *one* salt value after parsing the KRB-ERROR response. We've seen ETYPE-INFO look like --

    Entry 1: rc4-hmac, salt is empty
    Entry 2: aes128, salt is "REALMuser"

so Java goes thru each one and save "REALMuser" as the new salt. Maybe we should only ignore the rc4-hmac ones.

Java SE 7 saves one salt for each etype, but it still uses the wrong one in the customer's (i.e. Martin's) case.  It should also be fixed.

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

Well, if all of the entries can be correctly understood by the client. Unfortunately Java does not understand the last entry well, i.e. "non-standard extension in MIT krb5 (and Heimdal) for the benefit of AFS".

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

Oh.

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

This setting is on the KDC side. In the customer's case, the client side's krb5.conf only lists des-cbc-crc.

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

As I said, we skip entry with an empty salt.

We will fix our problem. My last question would be: so the customer has no workaround now on their KDC side?

Thanks
Weijun (aka Max)


> 
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev