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

[Jan Vilhuber <vilhuber@xxxxxxxxx>]

As Michael pointed out a few weeks ago, if we assume some sort of enrollment
protocol, that creates a shared secret between pkinit clients and KDC, then
the pkinit case becomes the general case, i.e. anyone can initiate to a
pkinit client, after the pkinit client has 'enrolled' with a KDC (and you
wouldn't even need u-u).

Rather than add complexity to KINK, I would prefer we put together an
enrollment proposal, either within THIS group, or propose it in the kerberos
WG.

jan




On 20 Nov 2000, Derek Atkins wrote:

> I consider it out of scope because it adds uncesseary complexity to
> the general KINK protocol.  It is complexity that perhaps PacketCable
> needs (or, more likely, wants), but it is not complexity that makes
> sense, IMHO, for a general-purpose IPSec key management protocol.  It
> either forces us to add options to the protcol (thereby adding
> complexity), or it forces us to always handoff authentication and
> design a secure way to doing so (also adding complextity).
> 
> The problem is that there is no way to always know a priori whether a
> peer is a PKINIT peer (where PKINIT peer is one that only has a TGT to
> work with, which implies normal users as well as PKINIT-based hosts)
> or a normal peer.  In order to reduce complexity in KINK we have to
> optimize for either PKINIT or non-PKINIT peers.  I believe that
> non-PKINIT peers are the "normal" case (namely, hosts with krb5
> keytabs).
> 
> Based upon this assumption (we should probably discuss whether this
> assumption has merits), we should optimize the protocol for
> non-PKINIT.  This implies that we should try normal Kerberos, and if
> we cannot obtain an AP_REQ, then we try U2U.  It means an extra
> round-trip to the KDC in the case of a PKINIT peer the first time we
> try to authenticate.  We can always cache U2U tickets.  Alternately,
> if we optimize for PKINIT peers, we should just use U2U at all times.
> 
> However, in neither case do we try to offload authentication from one
> entity to the other.  The initiator is always the initiator, the
> responder is always the responder.  Never are we trying to have the
> initiator tell the responder to initiate authentication.
> 
> -derek
> 
> "Medvinsky, Sasha (SD-EX)" <SMedvinsky@xxxxxx> writes:
> 
> > 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
> > > 
> 
> -- 
>        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
> 

 --
Jan Vilhuber                                            vilhuber@xxxxxxxxx
Cisco Systems, San Jose                                     (408) 527-0847