[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KINK user-user scenario

At 10:35 AM 1/18/01 -0500, Derek Atkins wrote:
>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.

There is no checksum in the AS request. 

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

TGT's are captured off the wire, unless the attacker wants to use his own
TGT which is unlikely. So this localizes the attack to a particular
principal's location and is a good place to initiate intrusion detection. 


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