[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: KINK user-user scenario
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.
At 03:02 PM 1/18/01 -0500, Medvinsky, Sasha (SD-EX) wrote:
>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.
>> -----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.
>> >> 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