Comments on the checksum vulnerabilities
ghudson at MIT.EDU
Fri Dec 3 12:48:39 EST 2010
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).
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.
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.
Sometimes a sender out in the wild uses a checksum we wouldn't expect.
* AD sometimes uses hmac-md5 checksums with AES keys in PAC
* 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
* MIT krb5's FAST client code in 1.7 and 1.8 uses md5-des with
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".
More information about the krbdev