Comments on the checksum vulnerabilities

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
    Greg> 2. Enforcement

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

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

Or if we do we'd need to handle the cases where unkeyed checksums are
permitted.  However that would probably be too big of a break for
potential non-tree uses of the API.

I understand we have a lot of verify_checksum APIs.  However, I am also
concerned about the fact that we've made this mistake multiple times.

We might be able to get away with changing behavior for the
krb5_k_interface and adding a way to set on a krb5 key object whether
unkeyed checksums are permitted.  That's probably more ugly than a new
API.

We could potentially have a flag to or-in with keyusages.  Or have a set
of key usages for which unkeyed checksums are permitted.
The last is actually something that seems worth considering.
The other options are kind of ugly.

--Sam