Subject: KINK user-user scenario

From: Jonathan Trostle <[email-masked]>
Date: Mon, 15 Jan 2001 21:51:11 -0800

Sasha,

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. 

Jonathan

---

From: Derek Atkins <[email-masked]>
Date: 16 Jan 2001 10:04:28 -0500

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
forged).

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.

-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: Michael Thomas <[email-masked]>
Date: Tue, 16 Jan 2001 07:52:07 -0800 (PST)

Derek Atkins writes:
 > 'no'.)  

   Because of an unauthenticated request? I'd say "heavens no" :-)

 > I would also think that we would need to have some level of

   Sure... this is true of every protocol which is subject
   to DoS attacks... which is every protocol, I suspect.
   The question I have is whether we need to be explicit
   here, or whether we could just point to a BCP-like
   document which outlines general strategies for
   coping with and/or narrowing DoS opportunities.

 > blindly request out to the KDC.

   Yes. This is the thing that really bothers
   me. A single well placed attacker could flood
   its n-B-T ethernet segment with U-U kinds of 
   requests to high fan out gateways and slag an
   entire farm of KDC's. Since it's not coming from a
   point source, it makes it very hard to defend
   as well as trace back.

	      Mike

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 16 Jan 2001 15:35:47 -0800

>request and build and return an error to the client (assuming it was

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.

>'no'.)  I would also think that we would need to have some level of

I would hope that no would be the right answer.

>messages off a single app-client.

Makes sense.

>blindly request out to the KDC.

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. 

Jonathan

---

From: Derek Atkins <[email-masked]>
Date: 17 Jan 2001 11:56:08 -0500

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

> 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

---

From: Jonathan Trostle <[email-masked]>
Date: Wed, 17 Jan 2001 14:05:47 -0800

>this way (they need to build a new request every time), and b) by

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.

>So, what do people think of this proposal?

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.

Jonathan

---

From: Derek Atkins <[email-masked]>
Date: 18 Jan 2001 10:35:47 -0500

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

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.

> 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

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 18 Jan 2001 11:00:54 -0500

>if it's seen the request before, and if it has, then it ignores it.

FYI - I'm not sure that's true anymore (for example, recent MIT releases
have the KDC replay cache turned off).

--Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 18 Jan 2001 10:41:53 -0800

>Granted, this just implies changing one byte, but it also must change

There is no checksum in the AS request. 

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

Jonathan

---

From: Derek Atkins <[email-masked]>
Date: 18 Jan 2001 13:55:33 -0500

> principal's location and is a good place to initiate intrusion detection. 

Who says an attacker needs to use a real TGT?  The TGT need only look
valid enough that:

	a) the client believes it is a TGT and forwards it to the KDC, and
	b) the KDC believes it is a TGT and tries to decrypt it.

Keep in mind that a client usually cannot do much in terms of TGT
validation.  It certainly cannot decrypt the TGT.  All it can do is
look at the ASN.1 formatting and make sure it looks like a TGT.
Similarly, the KDC just needs to get far enough in the ASN.1 encoding
to actually try to decrypt the TGT.

This means an attacker does not have to capture anything off the wire
in order to mount this attack.  They just build a fake TGT using the
ASN.1 encoding, a "known service principal", and then use any random
key to encrypt the encrypted portion of the TGT.  It doesn't matter
that the KDC can't decrypt it; that's the point -- you want the KDC to
_try_ to decrypt it and fail.

-derek

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 18 Jan 2001 13:03:26 -0800

Kerberos is vulnerable to these types of DoS attacks already. For example,
an attacker can create a delegated request targetted at himself with a
bogus krb creds inside and then send that out in multiple delegated request
to 1000 servers which then try to authenticate to the KDC using the bogus
krb creds.

I'm not convinced we should go to a lot of work to try to prevent these
types of attacks, because we will only be able to give some improvement to
a few cases instead of all the cases. Some sort of IDS system would
probably be needed to handle these types of attacks and might do an equally
good job against all of them. 

Jonathan

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Jan 2001 16:36:46 -0800 (PST)

> good job against all of them. 

   As currently instantiated in draft-ietf-kink-kink-00, this
   DoS attack does not exist. Adding some sort of wakeup 
   mechanism explicitly allows the attack. 

   I'd say that these proposals go out their way to *allow*
   the attack. That to my mind is bogus.

		Mike