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

[Derek Atkins <warlord@xxxxxxx>]

"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