Subject: RE: KINK user-user scenario

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Tue, 23 Jan 2001 20:56:03 -0500

Derek,

I don't agree that your proposal below protects against all types of DOS
attacks.  It is no different in that respect than my proposal.  The
adversary doesn't even have to possess a valid TGT. When the client receives
a response to a "GetTGT", it has no way to verify the TGT and simply has to
send it over to the KDC. If the adversary wants to have a valid TGT, it can
get that as well - by snooping.

Sasha.

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2001 5:40 PM
> To: Michael Thomas
> Cc: Medvinsky, Sasha (SD-EX); Jonathan Trostle; [email-masked]
> Subject: Re: KINK user-user scenario
> 
> 
> Michael Thomas <[email-masked]> writes:
> 
> > Derek Atkins writes:
> >  > App-Client	App-Server	KDC
> >  >    <--- Inititate
> >  > 
> >  >    { if no ticket is cached ...
> >  > 
> >  >        { direct case:
> >  >    TGS_REQ --------------------->
> >  >    <------------------------TGS_REP
> >  >        }
> >  >        { U2U case (or if direct case failed):
> >  >    GetTGT* --------->
> >  >    <---------- U2U TGT
> >  >    TGS_REQ --------------------->
> >  >    <------------------------TGS_REP
> >  >        }
> >  >    }
> >  > 
> >  >    AP_REQ* -------->
> >  >    <--------- AP_REP
> >  > 
> [snip]
> >    How so? This looks the same to me as any other wakeup 
> >    scheme: a minimal amount of work by the attacker (the
> >    "server" in your diagram) causes the attacked (client,
> >    KDC) to generate a non-minimal amount of work and
> >    traffic. This looks like the same old Zombie kind of
> >    attack as before.
> 
> It's a modification to the wakeup scheme.  Honestly, I was thinking
> about it in terms of U2U, not regular mode.  In the U2U mode, this
> does protect against the DoS attacks.  But you're right, the regular
> case only protects the App Server, not the client or KDC (which I
> suppose implies an impact on the App Server in that the client will
> try to initiate connections with anyone).
> 
> This hybrid was based on the pushback of "too many messages".
> Obviously we can go back to my prior suggestion which basically adds
> one round trip in order to perform the handoff.
> 
> As I said, this is a question for the WG.  How important is the
> handoff situation, versus how many extra messages do we want to add to
> support the handoff?  And which is more important to the WG,
> supporting a handoff situation with fewer messages or protecting
> against DoS?  (Putting on my chairman hat, I would suggest that
> protecting against DoS is more important than supporting handoffs with
> fewer messages -- without my hat I consider handoffs to be a lower
> priority).
> 
> So, we can go back to my older suggestion:
> 
> C	S	K
>  <-- Init
>  Ack -->			(Ack == "GetTGT")
>  <--- TGT
>  TGS_REQ ------->		(REQ/REP can be repeated for 
> service ticket
>  <----------- TGS_REP		 to U2U failover or ignored for 
> cached tickets)
>  AP_REQ->
>  <- AP_REP
> 
> Where the TGS_REQ/TGS_REP could theoretically be either a regular
> service-ticket request, a U2U request, or potentially both.  Obviously
> using U2U is just as cheap as anything else at this point. ;)
> 
> I believe that this protocol _does_ protect against the DoS attacks in
> all cases, but it does add one extra roundtrip in the case of a
> non-U2U case over Sasha's wakeup protocol.
> 
> > 		Mike
> 
> -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
>        [email-masked]                        PGP key available
>

---

From: Derek Atkins <[email-masked]>
Date: 23 Jan 2001 21:14:40 -0500

You're forgetting the client and server cookies :)

The client verifies that the TGT is from the real server because it
contains a cookie that the client inserted into the GetTGT request.
The attacker would have to guess the client's 'cookie' in order to
send a TGT that the client will accept.  In other words, the GetTGT
request contains two cookies, the server cookie as well as the client
cookie.

Sure, you're sacked if the attacker can snoop on the network.  But in
case you have other, bigger problems (and zombies are the worst of
your worries).

Note that the validity of the TGT is being completely ignored.  What
we get from this protocol is that both the client and the server are
mutually aware that they want to perform a handoff.

-derek