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

[Jan Vilhuber <vilhuber@xxxxxxxxx>]

On 20 Nov 2000, Derek Atkins wrote:

> Bill Sommerfeld <sommerfeld@xxxxxxxxxxxx> writes:
> 
> > > Perhaps we just don't care; or perhaps "users" can only be IPSec
> > > initiators.
> > 
> > That won't work in the general case since many possible uses of ipsec
> > require peer-to-peer keying.  (or, rather, require either end to be
> > able to initiate rekeying).
> 
> It works for road-warrior VPNs :)
> 
> In other cases, you probably aren't authenticating users to users, or
> hosts to users, but rather hosts to hosts.  So I don't think it
> matters there, either.  The only case I can truly think of where you
> might want to have the user authenticate one end is for a road-warrior
> VPN solution, and in that case, no, the server WONT be initiating
> anything :)
> 
It might also be worthwhile to do what IKE failed to do, which is to spell
out re-keying behaviour. If we spell out that the original initiator needs to
be the one to reinitiate a re-key, then problems won't arise.

That's not to say that initiation can not be in both directions, but if
someone will be a responder, that host/user MUST be a principal in the KDC.
That covers your road-warrior example, as those users may NOT need to be
principals, assuming they will always initiate and will always initiate a
re-key.

Whether the semantics I propose above are the correct ones, or not, I think
this should be in the draft somewhere to avoid ambuguities in rekeying which
we now have to deal with in IKE (See Jenkins draft).

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