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

From: [email-masked]
Date: Tue, 19 May 2009 19:45:09 -0400 (EDT)

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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: [email-masked]
Date: Wed, 20 May 2009 14:47:18 -0400 (EDT)

As promised, I'm back to report on a third subkey interop issue:

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

RFC 4120 specifies:

      The enc-authorization-data, if present (and it can only be present
      in the TGS_REQ form), is an encoding of the desired
      authorization-data encrypted under the sub-session key if present
      in the Authenticator, or alternatively from the session key in the
      TGT (both the Authenticator and TGT come from the padata field in
      the KRB_TGS_REQ).  The key usage value used when encrypting is 5
      if a sub-session key is used, or 4 if the session key is used.

We have verified that Heimdal, AD 2003, and AD 2008, and MIT krb5 1.7
get this right.  Unfortunately, MIT krb5 prior to 1.7 does not; it
attempts to decrypt the enc-authorization-data with the TGS session
key and usage 4 regardless of whether a subkey is present.

I am not aware of any current use cases for enc-authorization-data in
TGS requests.  (We were previously expecting to use it for TGS FAST,
but it turns out we will be using the authenticator's authorization
data field instead.)  However, any implementor who comes up with a
reason to use it may want to be aware of the interoperability problem
with MIT krb5 <1.7 KDCs.  I'm not aware of any good workarounds
besides the obvious ones: (1) don't do it, and (2) try it the right
way, then retry it the wrong way if you get an integrity error reply.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: [email-masked]
Date: Thu, 21 May 2009 13:00:43 -0400 (EDT)

I realized that I forgot to mention a fourth subkey interop issue.

4. tgs-req subkeys = tgs-rep enc-part key ambiguity

This one is very simple.  RFC 4120 states:

   The ciphertext part of the response in the KRB_TGS_REP message is
   encrypted in the sub-session key from the Authenticator, if present,
   or in the session key from the TGT.

I think the intent is that the subkey must be used if present,
although the language isn't as strong as it probably should be.  MIT
and AD encrypt the enc-part response in the subkey if one is present,
but Heimdal encrypts the enc-part in the TGS session key regardless.

The workaround for clients using subkeys is equally simple: try
decrypting the enc-part with the subkey and key usage 9, and if that
fails, retry with the TGS session key and key usage 8.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg