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

[Weijun Wang]

On 07/18/2011 09:39 PM, Greg Hudson wrote:
> 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.

The original ETYPE-INFO in customer's response is:

  SEQUENCE
      SEQUENCE
          [0] INTEGER 1
      SEQUENCE
          [0] INTEGER 1
          [1] OCTET STRING     ""
      SEQUENCE
          [0] INTEGER 1
          [1] OCTET STRING     "UFL.EDU"

ETYPE-INFO2 is:

  SEQUENCE
      SEQUENCE
          [0] INTEGER 1
      SEQUENCE
          [0] INTEGER 1
          [1] STRING           ""
      SEQUENCE
          [0] INTEGER 1
          [1] STRING           "UFL.EDU"
          [2] OCTET STRING     0000: 01

How do I explain the 2nd entry in either structure? They are empty.

Also, the 3rd entry in ETYPE-INFO2 can be explained because it has a 
special s2kparams, but it's also confusing in the ETYPE-INFO.

Thanks
Max

>
> 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.
>
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev