Subject: RE: KINK user-user scenario

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Wed, 24 Jan 2001 15:18:28 -0500

Derek,

What I meant is that anyone can send the 'Initiate' command in your proposed
sequence and when the bogus server then gets a GetTGT request, it can reply
with whatever TGT it likes - valid or not.

In my proposal: server -> client: Authenticate Request
		    client -> server: AP Request
		    server -> client: AP Reply

The Authenticate Request and AP Request are also tied together with a
'server cookie' and so if the Authenticate Request is from an adversary
impersonating some server and the AP Request is to a real server - the real
server will drop the AP Request.  So, the Denial of Service attack wasn't on
the server.  Mike Thomas brought up the issue of the zombie attacks on the
KDC, where the clients will send TGS Requests to the KDC after a bogus
Authenticate Request.

Your proposal doesn't help with this denial of service attack - anyone can
still send the 'Initiate' and wait for the GetTGT, respond with anything
they like.  The KDC would still get hit with the TGS requests for
user-to-user tickets possibly with bogus server TGTs.  So, it requires an
adversary to implement a couple more messages.  If you want to use the
user-to-user mode, the Authenticate Request could contain the server's TGT
as Mike once proposed.

I am not sure that this denial of service attack on the KDC is a big
problem, but my point is that the extra two messages in your proposed flows
(GetTGT requst and response) don't provide any additional security.

Sasha.

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2001 6:15 PM
> To: Medvinsky, Sasha (SD-EX)
> Cc: Michael Thomas; Jonathan Trostle; [email-masked]
> Subject: Re: KINK user-user scenario
> 
> 
> 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
> 
> "Medvinsky, Sasha (SD-EX)" <[email-masked]> writes:
> 
> > 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
> > > 
> 
> -- 
>        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: 24 Jan 2001 15:28:04 -0500

Ahh, but those extra packets DO provide extra security -- it requires
the attacker to not only stay in the loop but to provide their real IP
Address in order to get proper responses from the client and back to
the client.  This type of attack is extremely easy to track down, and
it directly points to the attacker.  In other words, in my version of
the protocol the attacker must provide their real identity (IP
Address) before any work is done by the client or KDC.

In your version, the attacker could send a fake source-address and
never be tracked down.  Also, you leave out the client->KDC and
KDC->client messages (before the AP Request)..  Your protocol is just
as suspect as mine in that respect -- the client would make a KDC
request if it needs a ticket (just like it would in mine).

The difference is that in my protocol, the client knows that the
"server" (or attacker) is real and wants to be a part of the protocol.
If it's an attacker, we know who it is.

-derek

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Jan 2001 13:14:08 -0800 (PST)

> If it's an attacker, we know who it is.

Ah, OK. My main uncomfort is having a situation
where an attacker can anonymously (via spoofing)
leverage unwitting zombies (clients) to attack
both the client and KDC. I still think that we
have a situation where you can mount a zombie
attack, but at least this one isn't an _anonymous_
attack.

If we have to do something like this -- and I
still don't really think it's a very good idea --
I'd feel a lot more comfortable with this method.
Also: if we do this, we ought to have a method for
the client to decline the initiate which can be
administratively turned on/off (ie, it is a MUST
requirement for the client to implement).

	   Mike

---

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

> requirement for the client to implement).

I also think we should rate-limit this as well.  I have no objections,
only a question: how do you "administratively turn [it] off"?  Do you
recommend that we say that an implementation must have a means to turn
it off, but leave off the how as an implementation detail?

-derek

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Jan 2001 13:51:09 -0800 (PST)

> it off, but leave off the how as an implementation detail?

   Yes.

			Mike

---

From: "Matthew Broda" <[email-masked]>
Date: Thu, 25 Jan 2001 15:46:32 -0500

Derek,

Is there anything to prevent the initiator with a spoofed IP address to send the
initiate message, wait for a certain period of time, and then send the bogus U2U
TGT without ever looking for the GetTGT message?

Matt

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Derek Atkins
| Sent: Wednesday, January 24, 2001 3:28 PM
| To: Medvinsky, Sasha (SD-EX)
| Cc: Michael Thomas; Jonathan Trostle; [email-masked]
| Subject: Re: KINK user-user scenario
|
|
| Ahh, but those extra packets DO provide extra security -- it requires
| the attacker to not only stay in the loop but to provide their real IP
| Address in order to get proper responses from the client and back to
| the client.  This type of attack is extremely easy to track down, and
| it directly points to the attacker.  In other words, in my version of
| the protocol the attacker must provide their real identity (IP
| Address) before any work is done by the client or KDC.
|
| In your version, the attacker could send a fake source-address and
| never be tracked down.  Also, you leave out the client->KDC and
| KDC->client messages (before the AP Request)..  Your protocol is just
| as suspect as mine in that respect -- the client would make a KDC
| request if it needs a ticket (just like it would in mine).
|
| The difference is that in my protocol, the client knows that the
| "server" (or attacker) is real and wants to be a part of the protocol.
| If it's an attacker, we know who it is.
|
| -derek
|
| "Medvinsky, Sasha (SD-EX)" <[email-masked]> writes:
|
| > Derek,
| >
| > What I meant is that anyone can send the 'Initiate' command in your proposed
| > sequence and when the bogus server then gets a GetTGT request, it can reply
| > with whatever TGT it likes - valid or not.
| >
| > In my proposal: server -> client: Authenticate Request
| > 		    client -> server: AP Request
| > 		    server -> client: AP Reply
| >
| > The Authenticate Request and AP Request are also tied together with a
| > 'server cookie' and so if the Authenticate Request is from an adversary
| > impersonating some server and the AP Request is to a real server - the real
| > server will drop the AP Request.  So, the Denial of Service attack wasn't on
| > the server.  Mike Thomas brought up the issue of the zombie attacks on the
| > KDC, where the clients will send TGS Requests to the KDC after a bogus
| > Authenticate Request.
| >
| > Your proposal doesn't help with this denial of service attack - anyone can
| > still send the 'Initiate' and wait for the GetTGT, respond with anything
| > they like.  The KDC would still get hit with the TGS requests for
| > user-to-user tickets possibly with bogus server TGTs.  So, it requires an
| > adversary to implement a couple more messages.  If you want to use the
| > user-to-user mode, the Authenticate Request could contain the server's TGT
| > as Mike once proposed.
| >
| > I am not sure that this denial of service attack on the KDC is a big
| > problem, but my point is that the extra two messages in your proposed flows
| > (GetTGT requst and response) don't provide any additional security.
| >
| > Sasha.
| >
| > > -----Original Message-----
| > > From: Derek Atkins [mailto:[email-masked]]
| > > Sent: Tuesday, January 23, 2001 6:15 PM
| > > To: Medvinsky, Sasha (SD-EX)
| > > Cc: Michael Thomas; Jonathan Trostle; [email-masked]
| > > Subject: Re: KINK user-user scenario
| > >
| > >
| > > 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
| > >
| > > "Medvinsky, Sasha (SD-EX)" <[email-masked]> writes:
| > >
| > > > 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
| > > > >
| > >
| > > --
| > >        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
| > >
|
| --
|        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: 25 Jan 2001 16:01:13 -0500

Yes, the U2U TGT requires a client cookie that the client sends as
part of the GetTGT.  Without that client cookie the attacker cannot
send a message that the client won't ignore.

-derek