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

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 20 May 2009 10:09:23 -0400

--On Tuesday, May 19, 2009 07:45:09 PM -0400 [email-masked] wrote:

> During the testing process of MIT krb5's new release, we discovered
> some interoperability issues surrounding the use of subkeys with TGS
> requests.  This note is primarily to save other implementors time,
> although the second problem points out an omission in RFC 4120.
>
> This list may not be exhaustive; there is a third potential problem
> area which Sam and I plan to investigate over the next week or so, but
> we don't yet know of a specific interoperability issue yet.  I'll
> report back if we turn anything up.
>
> 1. tgs-req subkeys + RC4 keys = key usage issue
>
> RFC 4757 specifies:
>
>       9.  TGS-REP encrypted part (includes application session key),
>           encrypted with the TGS authenticator subkey (T=8)
>
> However, this appears to be a typo; the actual key usage value used by
> AD 2003 or AD 2008 is 9.  Clients are only harmed by this issue if
> they use subkeys in tgs-reqs.  My suggested workaround: KDCs should
> encrypt replies to TGS requests containing subkeys with key usage 9 to
> match the AD behavior; clients using subkeys in tgs-reqs should
> attempt to decrypt responses with key usage 9, but on failure should
> try again with key usage 8 in case they are talking to a Heimdal or
> pre-1.7 MIT KDC.

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

> 2. tgs-req subkeys + keyed checkum types = checksum key ambiguity
>
> RFC 4120 is silent about what key should be used to construct and
> verify ap-req checksums, including the checksums in a tgs-req.  MIT
> and Heimdal both use the TGS session key whether or not there is a
> subkey in the tgs-req, but AD 2003 only accepts a checksum keyed with
> the subkey if one is present.  (That's experimentally true for RC4
> keys.  One can't safely use keyed checksum types with DES keys for
> other reasons, so we haven't tested it.)
>
> Experimentally, AD 2008 will accept a checksum keyed with the TGS
> session key (with either AES or RC4 keytypes), so it is safe to use
> keyed checksum types in combination with subkeys when the key type is
> AES.  I recommend against clients using keyed checksum types with RC4
> keys if the client is also using tgs-req subkeys.
>
> (For completeness, I will note that RFC 4757 specifies:
>
>       6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
>           with the TGS session key (T=6)
>
> However, that RFC is informational and exists to document RC4 in
> Kerberos, not Kerberos itself.)

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.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg