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

[Greg Hudson]

On Mon, 2011-07-18 at 02:49 -0400, Weijun Wang wrote:
> 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)

Right, ETYPE-INFO2 should always be used in preference to ETYPE-INFO if
both are present.

> 2. Now the last entry in ETYPE-INFO2 has a 0x1 s2kparams which Java
> does not support, it should ignore this entry too

Yes.  I'm not sure what the RFC language is on unrecognized s2kparams,
but practically speaking, you don't want to use an entry which looks
like this.

> 3. The other 2 entries have salt missing or empty, so the default salt
> should be used

An empty salt is like any other explicit salt.  Do not use the default
salt if you see an empty one.

A missing salt is just shorthand for the principal's default salt, and
should be treated exactly the same as an explicit salt equal to the
default one.

> 4. Of course, in this case, Java can also only look at the 1st entry

Right, although if the AFS3 entry happened to come first, you'd still
need code to ignore it.

> In the customer's case, the client side's krb5.conf only lists
> des-cbc-crc.

That helps to clarify.  Of course, I would recommend the client
configuration be changed in order to migrate away from DES.  In most
cases, there is no need to restrict enctypes in the client
configuration.

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

For existing keys, no.  There aren't a lot of knobs on the KDC for this
other than the key data itself.

For new principals and newly changed passwords, I think there is a
workaround, which is to put des-cbc-md5:norealm at the front of
supported_enctypes.  Because a norealm salt differs from the default
salt, the KDC will send an explicit salt for this key entry, and Java
will pick up that salt in preference to the AFS3 one.