Comments on the checksum vulnerabilities

Sam Hartman hartmans at MIT.EDU
Fri Dec 3 13:37:55 EST 2010

>>>>> "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

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.


More information about the krbdev mailing list