Subject: [kitten] FAST option interop bug in MIT krb5 1.7-1.11 KDC

From: Greg Hudson <[email-masked]>
Date: Sat, 31 Aug 2013 13:48:23 -0400

We have discovered a bug in the MIT krb5 KDC's handling of FastOption
values in KDC requests.  RFC 6113 specifies that bits 1-15 are critical,
meaning that the KDC will deny the request if an unsupported bit is set.
But the mask we used to detect those bits was defined as 0x00ff, which
corresponds to the eight bits 24-31 in our representation of ASN.1 flag
values.

To complicate matters, Heimdal clients unconditionally send the
hide-client-names option (bit 1, which is critical).  We don't yet
implement this option, and right now we are incorrectly ignoring it.  If
we simply fix our mask, our KDC would stop interoperating with Heimdal
clients, which is arguably worse than failing to hide the client name.

For our 1.12 release, we will be implementing hide-client-names and
fixing our mask.  (I have written and tested the code, but haven't yet
pushed it to master.)  We haven't yet decided what backports to make for
previous releases because there is a new feature involved.  Whatever we
do, there are likely to be a substantial number of KDCs in the field
with incorrect FAST option recognition for some time to come.

Future specifications should consider that:

* Option bits 1-15 will be correctly considered critical by some
  implementations (Heimdal and MIT 1.12+, and presumably AD) but not by
  all.

* Option bits 16-23 will be correctly considered non-critical by all
  implementations.

* Option bits 24-31 will be erroneously considered critical by some
  implementations (MIT 1.7-1.11).

If there are ever any specifications containing new non-critical FAST
options, they should start with bit 16 and go forward, rather than
starting at bit 31 and going backwards.

If there are ever any specifications containing new critical FAST
options, the first one should consider requiring that clients also set
bit 31, which would be chewed up as a "make MIT 1.7-1.11 fail" measure.
Bit 31 could be re-used for this purpose for all new critical FAST
options; we wouldn't have to use a different bit in the 24-31 range for
each new option.