[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: alternative to user-to-user Kerberos in KINK
On Mon, 20 Nov 2000, Medvinsky, Sasha (SD-EX) wrote:
> 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.
Which gets back to the fact that KINK is for peer-to-peer, so any server is a
client and any client is a server. So they all need to be principals in the
KDC, so we need to enroll them.
Unless you want to do u-u, I guess, which complicates things. I'd prefer to
have them enrolled.
jan
> 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
> >
>
--
Jan Vilhuber vilhuber@xxxxxxxxx
Cisco Systems, San Jose (408) 527-0847