Subject: [Ietf-krb-wg] Interop issues related to TGS subkeys

From: Larry Zhu <[email-masked]>
Date: Wed, 10 Jun 2009 09:00:42 +0000

Jeff wrote:
> True, but that list derives from the list of key usages in RFC4120 7.5.1,
>which uses the same language, implying that it was intended that the TGS
>session key always be used in this case.  Similarly, the entry for key
>usage 10 implies the same intent for other AP-REQs.  However, that section
>is a list of key usage values, and was not intended to specify which data
> should be encrypted or checksummed with which keys, so the implication is
> rather weak.  I think we should clarify this more explicitly.

Agreed. The intend is implied from RFC4120 but it could be made more explicit.

>Do we know of any existing clients which support RC4 and use subkeys in
> tgs-reqs?  Particularly, do any Windows clients do this?

No existing deployed windows clients would do populate the subkey in the TGS.

ghudson wrote:

> 3. tgs-req subkeys + enc-authorization-data = key ambiguity

It is great to hear that this is now fixed in 1.7.

>1. tgs-req subkeys + RC4 keys = key usage issue

ws2k8 and later releses are doing the right thing on the KDC side, but the client side still uses T=8 to decrypt the KDC reply even if the subkey is populated. So it is hard to make a call in this case. So for backward compatibility with the existing deployment, it would be wise not to use the subkey unless you are using FAST.

>2. tgs-req subkeys + keyed checkum types = checksum key ambiguity

The observed behavior is expected and the incorrect behavior was fixed in the later releases. The intention of RFC4120 is noted by Jeff in the beginning of this message. So for backward compatibility with the existing deployment, it would be wise not to use the subkey unless you are using FAST.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg