Subject: RE: KINK user-user scenario

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

Mike,

An adversary can spoof someone you trust, but I am not sure what it would
achieve.  Since tickets are normally cached, a client would not go back to
the KDC each time to get a new ticket.  Also, if the 'Initiate' and 'AP Req'
are bound with a 'server cookie', the real server you spoofed is not going
to respond to this AP Req - the DOS is just on the KDC.  I would say that
the KDC has to handle the load of clients requesting tickets for the servers
that they trust - as long as the clients don't keep requesting new tickets
before old ones expire.

So, if you implement your Kerberos client, where if it doesn't get a
response to an AP Request it removes the ticket from the cache, you would
have a problem.  If you leave valid tickets in the ticket cache until they
expire, this is not a problem.

Sasha.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 3:09 PM
> To: Medvinsky, Sasha (SD-EX)
> Cc: 'Derek Atkins'; Michael Thomas; Jonathan Trostle; 
> [email-masked]
> Subject: RE: KINK user-user scenario
> 
> 
> Medvinsky, Sasha (SD-EX) writes:
>  > 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.
> 
>    Since 'initiate' isn't authenticated, why can't I just
>    spoof somebody you observably trust to mount the attack? 
> 
> 		  Mike
>

---

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

> the KDC each time to get a new ticket.  Also, if the 'Initiate' and 'AP Req'

You can't assume tickets are cached.  Again, in the packetcable case,
you might have a CMS cluster that contains e.g. 10 machines.  In your
proposal an attacker could basically cause ALL of your clients to
authenticate to each of those 10 machines, all at once.

> expire, this is not a problem.

You're still causing the client to do work, because it still has to
form an authenticator -- and it would have to do this for every
Initiate request that an attacker sends.

> Sasha.

-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