[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



As I replied to Mike's email, this client enrollment would eliminate some of
the disadvantages of the user-to-user mode (e.g. adding user
policy/authorization into the tickets), but would still require a server to
obtain/maintain tickets for its clients.  I also listed benefits of not
having to do that.

Sasha. 


> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@xxxxxxxxx]
> Sent: Monday, November 20, 2000 11:55 AM
> To: Derek Atkins
> Cc: Medvinsky, Sasha (SD-EX); 'Michael Thomas'; 'ietf-kink@xxxxxxxx'
> Subject: Re: alternative to user-to-user Kerberos in KINK
> 
> 
> 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
>