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

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Mon, 20 Nov 2000 13:58:29 -0500

Derek,

KINK is a peer-to-peer protocol, but Kerberos is not.  A client-server
architecture is more commonly used with Kerberos than the user-to-user case.
I would say Kerberos looses some of its advantages when it is used in the
user-to-user mode.

There is nothing special about the PacketCable architecture, except that it
assumes a client-server architecture and I don't think that we should
exclude it from KINK.

Sasha.

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 7:30 AM
> To: Medvinsky, Sasha (SD-EX)
> Cc: 'Michael Thomas'; [email-masked]'
> Subject: Re: alternative to user-to-user Kerberos in KINK
> 
> 
> "Medvinsky, Sasha (SD-EX)" <[email-masked]> writes:
> 
> > Also, the client should really have an Access Control List 
> of the servers it
> > wants to talk to and would not normally respond to a 
> request from a server
> > it doesn't know about.  Even if a client did respond to any 
> such server -
> > the KDC has only a limited number of them in its database.
> 
> This doesn't make sense in the KINK framework.  KINK is meant as a
> peer-to-peer protocol.  You cannot expect a KINK Peer to necessarily
> know what other peers to expect to talk to it.  I think you are
> applying PacketCable architecture requirements to KINK, in a way that
> those requirements do not apply.
> 
> -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      N1NWH
>        [email-masked]                        PGP key available
>

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 20 Nov 2000 14:05:43 -0500

> 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: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 14:10:52 -0500

> assumes a client-server architecture and I don't think that we should

The special case of PacketCable is that servers may need to initiate
IPSec with clients, but you don't want to have the server store keys.
So, you want to be able to securely "handoff" the authentication to
the clients, via a wakeup or other mechanism.  What this amounts to is
the application server telling the application client something like
"I want to authenticate to you, so initiate an authentication to me".
This is particularly a problem with PKINIT entities, as you cannot
obtain an AP_REQ for a PKINIT ID.

I believe that the latter problem is one that KINK will have to solve
(most likely by using user-2-user, initiated by either party).
However, I do believe that the former is out-of-scope for KINK.  I
don't think KINK should try to worry about forcing the initiator of
sessions.

-derek