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

From: Michael Thomas <[email-masked]>
Date: Mon, 11 Dec 2000 18:54:21 -0800 (PST)

I'm going to bring this up tomorrow. Hopefully, this
will refresh everybody. Answers inline:

Walker, Jesse writes:
 > Mike,
 > 
 > 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.)

   I guess I don't understand what a tie means. The current
   draft says that the initiator is the only one that initiates
   a rekeying operation. Even if there is some clock skew where
   you could get into a situation where there is a collision,
   isn't the worst outcome two SA's for, essentially, the same
   traffic? If so, shouldn't there be two valid SA's, and that
   the old "conserative on what you send, liberal on what you
   receive" should apply?

 > 
 > 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.)

   I believe that we can solve that by having the
   responder set the ACKREQ bit, which will cause
   the initiator to send an ACK. I definitely don't
   want it to be contingent on arrival of a DELETE
   because I think it's worthwhile to just allow 
   the old SA to timeout.

 > 
 > 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). 

   s/DELETE/ACK and I agree.

   How about this text:

   In order to rekey a security association, a standard CREATE
   SA flow is initiated by the original initiator of the security
   association and it MUST set the ACKREQ to elicit a three way
   handshake. The old security association MAY be deleted after 
   the new security association is created. In order to prevent
   ambiguity on which security association should be used, 
   KINK mandates the following:

   o Receivers MUST be able to accept packets simultaneously
     on two security associations for otherwise identical
     flows.

   o If the CREATE REPLY has not arrived, the
     initiator MUST consider only the old SPI for
     sending and receiving traffic.

   o If the ACK has not arrived, the responder
     MUST choose the old 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 only apply if the initator desires
to DELETE the old security association:

   o If the DELETE REPLY 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. For the initiator,it MUST accept 
     traffic on either SPI, but only send on the new SPI.

 > e. We don't have any behavior for when an expected reply never arrives.

   I think I've covered the cases here. Can you find a hole?

 > Presumably we want to continue using the old SAs until their keys expire,

   Yes, unless there's proof the other side knows about the new
   SA.

 > 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? 

   I've tweaked the above a bit; and heavens no on limitless retries :-)

			   Mike