[16520] in Kerberos_V5_Development
Re: Comments on the checksum vulnerabilities
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Dec 3 13:38:19 2010
From: Sam Hartman <hartmans@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
Date: Fri, 03 Dec 2010 13:37:55 -0500
In-Reply-To: <1291398519.20307.237.camel@ray> (Greg Hudson's message of "Fri,
03 Dec 2010 12:48:39 -0500")
Message-ID: <tsl4oaupurg.fsf@carter-zimmerman.suchdamage.org>
MIME-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>>>>> "Greg" == Greg Hudson <ghudson@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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
