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

["Medvinsky, Sasha (SD-EX)" <SMedvinsky@xxxxxx>]

What makes this "hand-off of authentication to clients" out of scope for
KINK?

Sasha.

> -----Original Message-----
> From: Derek Atkins [mailto:warlord@xxxxxxx]
> Sent: Monday, November 20, 2000 11:11 AM
> To: Medvinsky, Sasha (SD-EX)
> Cc: 'Michael Thomas'; 'ietf-kink@xxxxxxxx'
> Subject: Re: alternative to user-to-user Kerberos in KINK
> 
> 
> "Medvinsky, Sasha (SD-EX)" <SMedvinsky@xxxxxx> writes:
> 
> > 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.
> 
> 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
> 
> -- 
>        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
>        warlord@xxxxxxx                        PGP key available
>