[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KINK user-user scenario
Jonathan Trostle <jtrostle@xxxxxxxxx> writes:
> Right, but the situation isn't as bad (with respect to DoS attacks) as when
> using a pure wakeup approach. Of course, DoS attacks are even harder when
> using the approach currently specified. My thought was to find a middle
> ground between DoS attack concerns and having the app servers do less work.
Clearly this is a question we need to ask the Working Group at large:
Should we complicate the KINK protocol in order to support an
architecure where the application servers don't want to store kerberos
U2U tickets? Or perhaps a better phrasing is "which is more
important, more protection against DoS style attacks or supporting an
architecture where application servers don't store U2U tickets?"
> True, but you can send unauthenticated messages to the KDC to do a DoS
> attack on a KDC. The difference is that you would have to trace from the
> app clients instead of the KDC, but tracing from the KDC might be easier.
The other difference is that a) the attacker needs to do more work
this way (they need to build a new request every time), and b) by
bouncing off an application-client, they can cause even more traffic
to hit the KDC. Not to mention that by bouncing the attacks they wind
up reducing the individual flows to each app-client (making it harder
to trace) while still having a large aggregation at the KDC, in
addition to hiding their IP Address.
I guess the real question that needs to be answered (and this may have
to wait until Minneapolis when we can call for a show of hands) is
which goal is more important? I think we'll have to make this choice,
unless someone can come up with an approach that allows the initiator
to handoff the Kerberos U2U request to the recipient while retaining
the DoS protection characteristics of the current protocol.
I can see one approach but it adds one extra message to the protocol:
App-Client App-Server KDC
<--- Inititate (1)
GetTGT (2) ------>
<----- U2U TGT (3)
<------ AP_REP (5)
Basically, if the initiator (the app-server in this case) knows it
wants to handoff to the responder, then in the initiate message (1) it
basically just sends a message that says "I want to initiate KINK with
a handoff. Here's my cookie." The responder replies (2) with "Send
your TGT. Here's your cookie back." The initiator can verify the
cookie (so it wont do extra work) and then the standard KINK U2U
continues: (3) send TGT with cookie (to continue transaction) (4) U2U
AP_REQ (5) AP_REP
So basicaly we add one extra message here (#1) that is basically an
"initiate handoff" message but no real work is happens until after
message 3. But the only way to get to message three is if both
initiator and responder agree to complete a protocol. We would also
need to add a flag to the GetTGT message to say whether it's being
used as an initiate or a response.
So, what do people think of this proposal?
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