[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: alternative to user-to-user Kerberos in KINK
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