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

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


You have proposed a very good start. Here are some comments.

a. The document needs to specify a way to identify who is indeed the
rekeying initiator in cases of a tie. (IPXWAN totally orders IPX addresses
and then arbitrarily decrees the larger of the two wins; perhaps we employ
something similar.)

b. If KINK rekeying works like IKE rekeying, in that each peer has to
contribute nonces and the like as entropy for computing the new SA keys, it
is not evident that (2) below is correct. This is because the responder does
not know that the initiator can compute the correct SA keys for the new SA
until after it knows the peer has received its CREATE REPLY; it will be
sending traffic into a black hole if the CREATE REPLY is lost. The responder
should indeed receive on both old and new SA as (2) suggests, but perhaps it
may be better to continue sending on the old send SA until the DELETE from
the initiator arrives. Then if its CREATE REPLY never arrives, communication
can at least continue until the SA key expires. (In a two-phase commit
protocol, you don't commit until phase 2.)

c. If you buy (b) above, then the initiator needs a retry timer for its
CREATE (to try to ellicit a CREATE REPLY), and the responder needs a retry
timer for CREATE REPLY (to ellicit a DELETE). I think (3) is correct or
almost correct in the case it actually receives a CREATE REPLY: the
initiator sends on the new SA, but receives on both the old and the new. It
knows the responder knows the keys for the new SAs, because it received the
CREATE REPLY. But it can't do away with the old SA until it receives the
DELETE REPLY from the responder (or key expiry), because it doesn't know
that the responder has comitted to use the new SAs. I do not think this is
optional behavior; I think it is mandatory to make interoperability a

d. What seems optional is the responder could send a DELETE REPLY and delete
its old SAs if it receives traffic from the initiator on the new SA; this
says conclusively that the peer received its CREATE REPLAY, because it is
protecting its traffic under the new SPIs and keys associated with the new

Likewise, the initiator can finally delete its old SAs if it receives
traffic on the new SA. This is conclusive evidence that the responder has
received either its DELETE REPLY or noticed that the new SA is in use.

This optional provision will allow progress if the DELETE/DELETE REPLY
messages are all lost but the IPsec datagrams can still get through. It is
optional because retries of the CREATE REPLY and DELETE messages should
eventually cause convergence if the peers are still reachable to each other.

e. We don't have any behavior for when an expected reply never arrives.
Presumably we want to continue using the old SAs until their keys expire,
but this is counter to the decisions discussed above about when to start
sending on the new SA. So maybe there isn't a retry limit on DELETEs? Or
maybe the reasoning of when to begin sending on the new SA is wrong?

-- Jesse

-----Original Message-----
From: Michael Thomas [mailto:mat@xxxxxxxxx]
Sent: Wednesday, November 22, 2000 9:22 AM
To: Walker, Jesse
Cc: 'Michael Thomas'; 'ietf-kink@xxxxxxxx'
Subject: RE: alternative to user-to-user Kerberos in KINK 

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?


Walker, Jesse writes:
 > Mike,
 > I think sidestepping the issue is a fundamental strategic mistake that
 > render KINK far less relevant than it could otherwise be.
 > Rightly or wrongly, my belief is that one of the justifications for
 > existence is a number of interoperability issues could never be resolved
 > IKE. In particular, this issue was never fully addressed for the
 > interaction (it is usually referred to as the rekey issue). My
 > 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,
 > 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
 > KINK.
 > -- Jesse
 > -----Original Message-----
 > From: Michael Thomas [mailto:mat@xxxxxxxxx]
 > Sent: Tuesday, November 21, 2000 8:26 AM
 > To: Walker, Jesse
 > Cc: 'Michael Thomas'; 'ietf-kink@xxxxxxxx'
 > 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:mat@xxxxxxxxx]
 >  > Sent: Tuesday, November 21, 2000 7:55 AM
 >  > To: sommerfeld@xxxxxxxxxxxx
 >  > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael
 >  > Thomas'; 'ietf-kink@xxxxxxxx'
 >  > 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
 >  > spell
 >  >  > > out re-keying behaviour. If we spell out that the original
 >  > 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,
 >  >  > in case the peer might want to send something in the future?  
 >  >  > 
 >  >  > Do you engage in some sort of layering violation, peeking into TCP
 >  >  > see if there are still open connections or tracking connection
 >  >  > in the IP layer?
 >  >  > 
 >  >  > Or do you not care about long-lived connections, and let them drop
 >  >  > the initiator doesn't have the session up?
 >  >  > 
 >  >  > I'm not happy with any of these alternatives.. the responder must
 >  >  > able to turn around and reinitiate back to the initiator..
 >  >  > 
 >  >  > 					- Bill
 >  >  > 
 >  > 
 >  >