Retransmitting a command with different tickets

["KAMADA Ken'ichi" <kamada@xxxxxxxxxx>]

The current draft says nothing about retransmitting a command with
different service tickets.  I think we should forbid it, how do you
think of it?


When a KINK initiator sends a command and the command or its reply is
dropped, the initiator retransmits the command.  If the initiator
renews a service ticket between the first and second transmission,
some careless implementations may use different tickets.  In that
case, some problems may occur.

Problem example:
   If the initiator retransmit the command with the new ticket, the
   responder may receive the same command with different keys.  The
   responder doesn't know which reply (the reply to the first command
   or the second one) will get to the initiator, thus doesn't know
   which key should be used to generate KEYMAT.

Another problem:
   If the initiator detects the ticket renewal and aborts the
   transaction, the initiator and the responder go out of sync.  That
   is, the initiator thinks the transaction was failed, but the
   responder may think the transaction was successful.

To deal with this problem, the KINK spec need to prohibit a
retransmission with a different ticket.  Then, how the initiator's
behavior should be defined?

-  Before a transaction, the initiator should check the lifetime of the
   ticket and avoid near-end-of-life (e.g. shorter lifetime than full
   retransmission cycle) ticket.
-  The initiator must continue to use the same ticket in a transaction
   even if it notices the lifetime is expired.
-  Leave the behavior to implementations.  In this case, some
   implementation hints may be necessary to avoid above problems.
-  any other ideas?


Regards,
-- 
KAMADA Ken'ichi <kamada@xxxxxxxxxx>