Re: Retransmitting a command with different tickets

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

At Thu, 28 Jul 2005 11:43:20 -0400,
Sam Hartman <hartmans-ietf@xxxxxxx> wrote:
> 
> Presumably the correct behavior is to start a new transaction with the
> new ticket?

Yes, I also thought that is the most straight forward.  But, to do so,
the initiator needs to tell the responder that the old transaction was
canceled.
Consider the case that the ticket is not expired at the first
transmission of a command, and the reply was dropped.  In such case,
the responder think the transaction was successful, but the initiator
starts a new transaction.  As a result, the responder will have two
pairs of SAs.

To inform the responder the cancel, we have some candidate way.

1) The initiator makes the responder notice the expire, by sending the
   old ticket.  If it is failed with KRB_AP_ERR_TKT_EXPIRED, the
   initiators start a new transaction.  (This is the second proposal
   of my original mail).
   I pretty like this because this doesn't require the implementation
   to do any extra thing.  This just requires the initiator *not* to
   check the expiration.  But I have a concern that we can't do this
   with the MIT library because of krb5_validate_times() in
   krb5_mk_req_extended().

2) The initiator sends a DELETE command.  (This is precisely not a
   cancel, but trying to delete the discarded SPIs just in case).
   I don't like this because this introduces a new race condition and
   needs some description to avoid it.

3) Prepare a message to cancel a transaction in the KINK spec.  (a new
   message, an ACK message with an error payload, or something).
   (I know the kink-00 had an "unexpected ACK" indicating errors).
   I don't like this because this increases the variation of KINK
   message flows.

-- 
KAMADA Ken'ichi <kamada@xxxxxxxxxx>