[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KINK user-user scenario
Jonathan Trostle <jtrostle@xxxxxxxxx> writes:
> Not clear to me why the request would be different each time except for the
> IP address which the attacker would change for each request anyway. An
> attacker can easily build AS requests in advance and use these to saturate
> a KDC, without any help from other hosts.
The KDC keeps a replay cache. The first thing it does is check to see
if it's seen the request before, and if it has, then it ignores it.
This means that an attacker change the request for every message.
Granted, this just implies changing one byte, but it also must change
the checksum as well.
A MUCH easier attack would be to generate a single "TGT" and send it
off to a thousand app-clients, each of which will expend energy
building a "real" message for the KDC. I've just reduced the
attacker's overhead by 1000:1. The benefits of this attack are
two-fold. One, it's much less work for the attacker. Two, it hides
the attacker's address because there are only low-level flows to each
app-client and nothing to the KDC.
> Interesting protocol, but one issue in the past has been the need to get
> data flowing over an SA after a minimum number of messages.
This is true. However I believe that that an Initiator Handoff is a
special case scenario and not something that happens very often or in
very many cases. In most cases I would think that KINK would be used
as a true peer-to-peer protocol. Adding one extra message to a
special case scenario is not, IMHO, a showstopper. But let's see what
others in the WG think.
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@xxxxxxx PGP key available