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

From: "Walker, Jesse" <[email-masked]>
Date: Wed, 22 Nov 2000 07:31:32 -0800

Mike,

I think sidestepping the issue is a fundamental strategic mistake that will
render KINK far less relevant than it could otherwise be.

Rightly or wrongly, my belief is that one of the justifications for KINK's
existence is a number of interoperability issues could never be resolved for
IKE. In particular, this issue was never fully addressed for the IKE/IPsec
interaction (it is usually referred to as the rekey issue). My recollection
is that by the time Tim Jenkins finally published a reasonable way to
resolve the problem, vendors had already implemented 8 conformant but
non-interoperable algorithms for accomplishing the coordination, and it
thereby became infeasible to get any consensus on how to move forward, since
no one was willing to give up their own approach.

With KINK there is a clean slate, and if the issue is addressed up front,
there is a far, far better chance for genuine interoperability. It is not
hard to specify an algorithm--the implementation history of the IKE/IPsec
interaction gives us at least 8 to choose from! All the spec should do is
specify one and decree once and for all that that's how to do it when using
KINK.

-- Jesse

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Tuesday, November 21, 2000 8:26 AM
To: Walker, Jesse
Cc: 'Michael Thomas'; [email-masked]'
Subject: RE: alternative to user-to-user Kerberos in KINK 

Jesse,

Correct me if I'm wrong, but this sure looks like
it's out of the scope of the keying protocol per
se. It seems like it would be better to have a BCP
or something with base IPsec which defines what
the expected behavior ought to be when you have 
two SA's with the same flow spec.

	 Mike

Walker, Jesse writes:
 > Mike,
 > 
 > How, when, and if they choose one is precisely the issue. This was
something
 > left unspecified in the interaction between IKE and IPsec, and as a
result
 > vendors implemented conformant but non-interoperable solutions to this
 > problem.
 > 
 > -- Jesse
 > 
 > -----Original Message-----
 > From: Michael Thomas [mailto:[email-masked]]
 > Sent: Tuesday, November 21, 2000 7:55 AM
 > To: [email-masked]
 > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael
 > Thomas'; [email-masked]'
 > Subject: Re: alternative to user-to-user Kerberos in KINK 
 > 
 > 
 > 
 > I guess I don't quite grok the dilemma here. Initiator and
 > responder only matter when setting up/tearing down the
 > SA. Though perhaps not optimal, there shouldn't be a
 > problem having two SA's with the same flow spec between
 > two hosts -- they just needs to chose one. Assuming
 > that either party can tear down an existing SA (which
 > now that I think about it may not work in the current
 > draft), you have the situation where either side can
 > manage the SA's any way they see fit.
 > 
 > What am I missing?
 > 
 > 	Mike
 > 
 > Bill Sommerfeld writes:
 >  > > 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.
 >  > 
 >  > How can that possibly work in a non-VPN, non-connection-oriented
 >  > scenario?  Does the initiator *always* recreate an expiring SA, just
 >  > in case the peer might want to send something in the future?  
 >  > 
 >  > Do you engage in some sort of layering violation, peeking into TCP to
 >  > see if there are still open connections or tracking connection state
 >  > in the IP layer?
 >  > 
 >  > Or do you not care about long-lived connections, and let them drop if
 >  > the initiator doesn't have the session up?
 >  > 
 >  > I'm not happy with any of these alternatives.. the responder must be
 >  > able to turn around and reinitiate back to the initiator..
 >  > 
 >  > 					- Bill
 >  > 
 > 
 >

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Nov 2000 09:21:50 -0800 (PST)

OK, I'm obviously not up to speed on the rekeying
wars and I don't remember the details of the
jenkins draft.  I'm also not sure what, in
particular, was the hole that so many people drove
through. Showing my ignorance, if it's only a
matter in KINK of also describing how the
selectors are processed when you have two
identical ones, could we just say that you
choose the newest one to send on? Does this
actually even matter?

Thus to rekey, the _rekeying_ initiator would
CREATE a new SA on SPI Y, and DELETE the old
SPI on X. During the transition, there are
a few conditions:

0) The CREATE has not been sent; both initiator
   and responder MUST process on the old SPI
   (ie, it's the normal steady state of the
   previous SA).
1) The CREATE REPLY has not arrived; the
   initiator MUST consider only the old SPI for
   sending and receiving traffic.
2) The DELETE has not arrived; the responder
   MUST choose the new SPI if there are two
   flow specs which are identical for outgoing
   traffic and MUST accept incoming traffic on
   the old SPI. The initiator MUST send on the
   new SPI, but accept data on both SPI's.

   The following two are optional; the initiator
   MAY allow the old SPI to time out:

3) The DELETE REPLY has not arrived; same as
   (2) for the responder. For the initiator,
   it MUST accept traffic on either SPI, but
   only send on the new SPI.
4) The DELETE REPLY is received; same as (0).

Am I out in left field here?

	 Mike