Comments on the checksum vulnerabilities

[Greg Hudson]

The main questions I'd like to consider going forward are (1) what
constraints we generally want to put on a sender's choice of checksum,
(2) whether those constraints should be enforced at the crypto layer or
the protocol layer, and (3) what API allowances should exist so that we
can be tolerant of exceptions (when they aren't insecure).

1. Constraints

RFC 3961 defines some relations between enctypes and cksumtypes:

  enctype -> required cksumtype
  cksumtype -> set of allowed key types

Typically, standards using keyed checksums say that the cksumtype is the
required cksumtype of the key's enctype, but they don't specify whether
that's a MUST or a SHOULD.  Heimdal enforces that the cksumtype matches
the enctype's required cksumtype (see crypto.c:verify_checksum() where
it looks at crypto->et->keyed_checksum); MIT instead enforces that the
key be in the checksum's allowed key types.  Both systems have some
exceptions for older algorithms.

Sam has argued (privately) that it's better to use an MIT-style check
because it allows the deployment of new cksumtypes for an enctype.  I am
not sure that this is valuable, since we have no checksum type
negotiation in the Kerberos protocol, only enctype negotiation.  I would
be more comfortable with a Heimdal-style check.

2. Enforcement

Right now, the crypto layer is responsible for ensuring that a keyed
cksumtype isn't being misapplied to the wrong kind of key, and the
protocol layer is responsible for ensuring that a checksum is keyed when
it has to be.

Since not all checksums need to be keyed (some are contained within an
encrypted blob), we cannot suddenly start enforcing keyed checksums for
every krb5_[ck]_verify_checksum operation.

3. Allowances

Sometimes a sender out in the wild uses a checksum we wouldn't expect.
For instance:

  * AD sometimes uses hmac-md5 checksums with AES keys in PAC
checksums[1].

  * Prior to the CVE fixes, MIT code uses hmac-sha1-des3 with AES and
RC4 keys in krb-safe messages and PKINIT KDC checksums.  (This isn't
even well-defined.  Currently 1.9 won't interoperate with such a choice,
which we think is okay, but it's possible we will have to revisit that
decision.)

  * MIT krb5's FAST client code in 1.7 and 1.8 uses md5-des with
des-cbc-md4 keys.

MIT handled the PAC exception by allowing hmac-md5 to be used with any
key type.  hmac-md5 uses no encryption operations, so this is as secure
as MD5--but it's probably not good that we're reducing every enctype to
MD5-level security for all protocol checksums.  Heimdal handled the
exception by making the PAC code detect hmac-md5 checksums and use a
lower-level verification interface (see pac.c:HMAC_MD5_any_checksum and
its call site).

4. Some options

I'm reluctant to revise the verify-checksum API because there are
already four versions of it (IOV/non-IOV and krb5_c/krb5_k).  But let's
say we do it anyway.  Perhaps the new function takes an extra argument
"allowances", which is a bitfield.  If allowances is 0, verification is
as strict as we want checksums to be for new protocol operations.  The
caller can specify flags for things like "unkeyed checksums are okay",
or "allow hmac-md5 with any key type".

[1]
http://blogs.msdn.com/b/openspecification/archive/2010/01/01/verifying-the-server-signature-in-kerberos-privilege-account-certificate.aspx