[16517] in Kerberos_V5_Development
Re: Comments on the checksum vulnerabilities
daemon@ATHENA.MIT.EDU (John Hascall)
Fri Dec 3 10:33:33 2010
To: Sam Hartman <hartmans@mit.edu>
In-reply-to: Your message of Fri, 03 Dec 2010 10:15:23 -0500.
<tsl62varipg.fsf@carter-zimmerman.suchdamage.org>
Date: Fri, 03 Dec 2010 09:33:29 CST
Message-ID: <5470.1291390409@malison.ait.iastate.edu>
From: John Hascall <john@iastate.edu>
Cc: krbdev@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
I think you were right on target in your blog where you said that
the API needs to make it easier to do the right thing instead of
the wrong thing.
And, yes, better documentation always helps -- particularly where
it shows examples of the right way to do things -- many people are
lazy/pressed for time/etc, better to have them crib from a correct
example than toss together whatever comes off the top of their head.
John
-------------------------------------------------------------------------------
John Hascall, john@iastate.edu
Team Lead, NIADS (Network Infrastructure, Authentication & Directory Services)
IT Services, The Iowa State University of Science and Technology
>
> I'd like to draw people's attention to a blog post I made on the
> checksum vulnerabilities. I would like to start a discussion on what if
> anything we still need to fix and on what we did wrong to get here.
> http://www.painless-security.com/blog/2010/12/03/bad-hair-day-for-kerber
>
> Initial thoughts:
>
> * Is it desirable that you have to make an extra step when verifying a
> checksum to make sure it is keyed?
>
> * People were probably assuming that if a checksum works with a given
> key and it is a keyed checksum, then it is a right kind of checksum
> for that key from a security standpoint. Roughly, this is close to
> assuming that checksums should either be unkeyed or work with one kind
> of key. I think we want to make this actually true going forward.
>
> * People assumed something similar when finding a keyed checksum.
>
> * Documentation might have heleped.
>
> However I feel like there is something I'm missing in here somewhere.
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
