[1002] in Kerberos_V5_Development
Re: X authentication stuff
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Wed Feb 7 00:24:11 1996
To: hartmans@MIT.EDU (Sam Hartman)
Cc: krbdev@MIT.EDU, swick@x.org
In-Reply-To: Your message of "06 Feb 1996 23:28:02 EST."
<tsl91ifahf1.fsf_-_@tertius.mit.edu>
Date: Wed, 07 Feb 1996 00:27:11 -0500
From: "Donald T. Davis" <don@cam.ov.com>
sam hartman wrote:
> In my phone conversation with Don, he pointed out that we
> didn't have to transmit a checksum with every packet; if we
> transmitted a running total checksum every few packets, the window for
> damage would be fairly small. (This assumes that the server will only
> service a certain number of requests between such integrity packets.)
> We could rely on the TCP checksums for data integrity, assuming
> anything that spoofed the TCP checksum but not the cryptographic
> checksum was an attack.
sam, i'd sharpen the point here: if the attacker
changes any packet, the infrequent crypto-checksum will
catch it, regardless of whether the tcp checksums catch
the change or not. thus, we can trust the tcp checksums
for fine-grained integrity-checking, with the under-
standing that they'll sometimes fail. the krb-managed
crypto-checksums will certainly catch any alterations,
but will give only a coarse indication of when the
alteration appeared in the data-stream. so, as long as
the crypto-checksums get sent every few seconds (more than
2, much less than 30), there isn't much reason for an
attacker to try a msg-mod attack. the only novelty here,
is the idea that tcp's insecure checksums can be useful
at all for security (it was sam who pointed out to me
that tcp provides such checksums; before he told me this,
i'd thought of adding frequent crc's to infrequent mac's).
my rationale for spacing the crypto-checksums a few
seconds apart, is that that's often enough to catch a
mod before the user can be deceived into acting on it.
note that this rationale only applies to the stuff the
server receives; the user's messages to the x-client will
probably have to send crypto-checksums much more often.
however, for many applications, it's the bulky display
traffic going to the x-server that needs high-speed
integrity checking. in the other direction, checksumming
every packet might not be costly, because the delays
would be smaller than the user's response-delays anyway.
-don davis, boston
