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

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.

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.)
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg