[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KINK user-user scenario
An attacker can still cause the app-client and KDC to do work this
way. Rememeber that the client cannot read the app-server's TGT, so
it had no idea whether it is valid or who really sent it. Therefore,
it has to blindly build a request around the TGT and send it to the
KDC, not knowing if it's valid. The KDC then needs to process the
request and build and return an error to the client (assuming it was
Luckily this wont affect the app-server, necessarily. Do we throw out
any existing SA's in the process? (I would suggest that the answer is
'no'.) I would also think that we would need to have some level of
request limiting so an attacker can't repeatedly bounce tons of
messages off a single app-client.
However you can still get a distributed attack against the KDC,
because an attacker can build a single "fake" packet and send it to
all the app-clients it can find. Then all those app-clients will
blindly request out to the KDC.
Jonathan Trostle <jtrostle@xxxxxxxxx> writes:
> Does the following approach satisfy your concern regarding the app server
> having to do too much work in a failover scenario?
> The app server sends a TGT_REP message (basically containing its TGT) to
> the client, and the client then takes the TGT and uses it as an additional
> ticket in a TGS exchange with the KDC, and then sends an AP_REQ to the app
> server (using user-user mode). The advantage of this approach versus the
> packetcable wakeup message, from a DoS perspective, is that an attacker has
> to actually obtain the victim's TGT which should limit these types of
> attacks (the attacker has to be on the wire instead of on the other side of
> the Internet). And the majority of the work is shifted to the client
> instead of the app server.
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