Subject: RE: KINK user-user scenario

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Thu, 18 Jan 2001 17:20:59 -0500

Derek,

In your flows below, I would make the flows (2) and (3) optional, since U2U
is optional in Kerberos.  Flows (2) and (3) add some extra non-cryptographic
work for the attacker trying to do the denial of service, but also adds
extra work and messages to the protocol.  So, I would make them optional, if
you want that extra protection against denial of service, where the denial
of service applies when the app-client doesn't use access control when
receiving the 'Initiate' message.

Sasha.

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2001 8:56 AM
> To: Jonathan Trostle
> Cc: [email-masked]; [email-masked]
> Subject: Re: KINK user-user scenario
> 
> 
> Jonathan Trostle <[email-masked]> 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)
>    TGS_REQ --------------------->
>    <------------------------TGS_REP
>    AP_REQ (4)----->
>    <------ 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
> 
> -- 
>        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: 19 Jan 2001 14:16:05 -0500

> is optional in Kerberos.  Flows (2) and (3) add some extra non-cryptographic

Um, where do you find that?  Section 9.1 of RFC 1510 says that
User-to-user is ""mandatory to implement" but is "may be disabled by
policy".  So, where are you getting the fact that U2U is optional in
Kerberos?

> receiving the 'Initiate' message.

Honestly, I'd prefer to have as few optional parts of the KINK
protocol as possible.  I'd like to have a simple state machine that
describes the full protocol, limiting optional portions.  As soon as
you start down the "make that optional" path, you start down the same
path as IKE.  I'd like not to make that same mistake.

Now, I will certainly conceed that in an Initiator-Handoff situation
the "responder" may be able to obtain an AP_REQ directly for the
initiator, which implies that you don't need to use User-to-User.  In
_that_ case, yes, we should allow the use of a direct AP_REQ instead
of the U2U flow, and we can solve the DoS case by doing the same thing
with cookies.  When the responder send's its AP_REQ to the initiator
in response to the Handoff, it includes the cookie from the Initiator.
That way the Initiator need not do any work unless the cookie is recognized.

So, we have this (more complete) flow of the Initiator-Handoff
sub-protocol:

   <--- 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

Basically, the whole protocol beyond the Initiate is the same "KINK"
protocol, except that the GetTGT or AP_REQ need to be differentiated
in a way that the server can tell that it is a response to an
Initiate-Handoff message rather than a regular KINK Initiate.

Does this work for you, Sasha?  I think that this still protects us
from the DoS attacks.

-derek

---

From: Michael Thomas <[email-masked]>
Date: Tue, 23 Jan 2001 16:33:27 -0800 (PST)

> Does this work for you, Sasha?  I think that this still protects us

   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.

		Mike

---

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

>  >    <------------------------TGS_REP
[snip]
>    traffic. This looks like the same old Zombie kind of

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.

-derek