Subject: RE: alternative to user-to-user Kerberos in KINK

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Mon, 20 Nov 2000 14:12:24 -0500

All I was saying is that although you can do peer-to-peer authentication
with Kerberos, you shouldn't require it for an architecture where you don't
have a peer-to-peer relationship.

Sasha.

> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 11:06 AM
> To: Medvinsky, Sasha (SD-EX)
> Cc: 'Derek Atkins'; 'Michael Thomas'; [email-masked]'
> Subject: Re: alternative to user-to-user Kerberos in KINK
> 
> 
> > KINK is a peer-to-peer protocol, 
> 
> yes
> 
> > but Kerberos is not.  
> 
> kerberos is a 3-party protocol involving a KDC and two principals.
> 
> All principals in possession of their long term key can trivially do
> peer-to-peer authentication.  the user-to-user extension in kerberos
> v5 also lets "clients" which only have a TGT do peer-to-peer
> authentication without posession of the long-term key.
> 
> 					- Bill
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2000 10:05:16 -0800 (PST)

> have a peer-to-peer relationship.

   I think client/server and peer-peer is somewhat
   misleading. Colloquially, client/server means that
   clients initiate transactions, not servers. Peer
   to peer means that no such distinction is drawn.

   I don't think that Kerberos, per se, has much to
   say on that front because "client" machines can
   host services and "server" machines can act as
   clients, so it appears to _mostly_ be a distinction
   without a difference.

   There are only two things that I know of which
   requires me to qualify myself above:

   1) clients may authenticate using PKINIT which
      leads to the U-U/enrollment debate
   2) it may be a worthwhile optimization to allow
      machines which subtend large numbers of users
      (let's not call them clients, because that's
      misleading) to have the abilty to require
      the high fanout devices to get and maintain
      tickets, thus avoiding duplication of effort
      and storage.

   #1 seems like we may be headed toward consensus
   that Matt's idea of enrollment may be a reasonable
   idea to pursue for PKinit. U-U should also be a
   fallback. The dispute seems mostly
   over #2. I still feel really uneasy about the
   inherent DoS attacks. I'm also not convinced that
   the real-life use of KINK cannot avoid this dilemma
   for the most part.

   Given the downside, I think that waiting to see
   real implementation experience would be a more
   prudent course of action.

		  Mike