[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