Subject: RE: KINK user-user scenario

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Wed, 24 Jan 2001 19:58:25 -0500

Derek,

My replies are below.

Sasha.

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 2:06 PM
> To: Medvinsky, Sasha (SD-EX)
> Cc: Michael Thomas; Jonathan Trostle; [email-masked]
> Subject: Re: KINK user-user scenario
> 
> 
> "Medvinsky, Sasha (SD-EX)" <[email-masked]> writes:
> 
> > Derek,
> > 
> > OK, I understand the point that you are trying to make.  
> The IP address
> > provided by an attacker doesn't necessarily have to be the 
> real one - but it
> > does have to be on the same LAN, unless the attacker has 
> another machine
> > somewhere.
> 
> True, but that is usually "good enough" to track down an attacker.
> 
> > I would contend though that the 'GetTGT' and 'GetTGT 
> response' messages are
> > optional.  For example, if the client receiving the 
> 'Initiate' already knows
> > who that server is and trusts it, even if it doesn't have a 
> ticket for it
> > already, it does not need to send GetTGT.  If the server name in the
> > 'Initiate' is unknown to the recipient, it can send a 
> 'GetTGT' to get some
> > guarantee about the server's IP address.
> 
> I _suppose_ if you have rate-limiting and you have a priori knowledge
> of the server, then you could _probably_ opt out of the
> 'GetTGT/response' handshake.  I don't particularly like doing that.
> However, in the general case you cannot assume that such a priori
> knowledge is available, so without the handshake you leave yourself
> open to attack.
> 
> Another problem is that without the extra handshake, an attacker can
> cause any client to rekey to a (real) server.  So you definitely need
> rate limiting there, even if we do decide to allow the handshake to be
> optional in the case of a priori knowledge.

[sasha] This is not a big problem if you have a 'server cookie' in the
initiate and then again in the AP Request - the real server would ignore any
AP Requests that it didn't initiate. I suppose the DOS to the server is just
the fact that it is receiving these packets from a client and has to process
them at all.  But in that case, the extra handshake doesn't eliminate this
problem - anyone can still send an 'Initiate' to a client with some server's
IP address and a client has to respond (just with a different message).
Just for that reason, rate limiting would be useful in general.

> 
> > Also, the value of those two extra messages is not in the 
> user-to-user mode
> > but just the fact that the server sends a response back 
> with the client's
> > cookie.  If these two messages were to simply contain the 
> client and server
> > cookies (in both messages) and no TGT, you probably 
> wouldn't loose anything
> > in terms of security.  The user-to-user part only helps in 
> the case where
> > both sides are PKINIT clients and user-to-user is the only 
> way to get a
> > service ticket.
> 
> Right -- the value is the handshake.  I was just overloading the U2U
> messages because it would save an extra round-trip later in the case
> where we actually _needed_ to use U2U.  In other words, if we just
> made a regular handshake that just included the cookies, then if the
> client needed to use U2U to authenticate then it would need another
> round trip in order to obtain the TGT.  So why not just send it in the
> first place and save that trip later?

[sasha] In this case, the GetTGT in the request and TGT in the reply would
be optional attributes - if the client doesn't wish to use the user-to-user
mode it doesn't have to.  Or, the 'initiate' message would have a flag to
specify if user-to-user is needed.

> 
> > Sasha.
> 
> -derek
> 
> > 
> > > -----Original Message-----
> > > From: Derek Atkins [mailto:[email-masked]]
> > > Sent: Wednesday, January 24, 2001 12: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
> > > 
> 
> -- 
>        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 20:12:10 -0500

> Just for that reason, rate limiting would be useful in general.

This doesn't protect the KDC.  An attacker could send a request for a
bunch of servers and cause the client to go off the KDC and expend a
lot of energy.  In the packetcable case, an attacker could basically
force all the clients to 'rekey' to all the "known" CMSes, all at
once!  The extra handshake _does_ eliminate this problem, because no
real work would be done (except sending messages) until both sides
actually agree that work should be done.

-derek

---

From: Michael Thomas <[email-masked]>
Date: Sat, 27 Jan 2001 17:30:37 -0800 (PST)

Medvinsky, Sasha (SD-EX) writes:
 > AP Requests that it didn't initiate.

   Presumably, you'd have to do less work to filter out
   responses with bogus cookies. If the cookie doesn't 
   require an ASN.1 decode or crypto, that seems
   like a fairly good assumption.

		Mike