RE: KINK user-user scenario

[Jonathan Trostle <jtrostle@xxxxxxxxx>]

The KDC will process an AS request without a preauthenticator. It doesn't
really matter though, since as Derek points out, the preauthenticator does
not need to be valid in order to force the KDC to do work.

Jonathan


At 03:02 PM 1/18/01 -0500, Medvinsky, Sasha (SD-EX) wrote:
>Jonathan,
>
>Yes there is a checksum in the AS Request - if you are using a
>pre-authenticator such as an encrypted timestamp or PKINIT.  These
>preauthenticators now contain a checksum over the request message body.
>
>Sasha.
>
>> -----Original Message-----
>> From: Jonathan Trostle [mailto:jtrostle@xxxxxxxxx]
>> Sent: Thursday, January 18, 2001 10:42 AM
>> To: Derek Atkins; Jonathan Trostle
>> Cc: smedvinsky@xxxxxx; ietf-kink@xxxxxxxx
>> Subject: 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. 
>> 
>> Jonathan
>> 
>> >
>> >> 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
>> >
>> >-- 
>> >       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
>>