Subject: Retransmitting a command with different tickets

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 22 Jul 2005 18:12:54 +0900

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 <[email-masked]>

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Tue, 26 Jul 2005 10:10:10 +0900

At Fri, 22 Jul 2005 14:26:20 -0700,
> > different service tickets.  I think we should forbid it, how do you
[snip]
> This seems reasonable: how about "the initiator MUST obtain
> a ticket whose lifetime MUST be greater than the initiator's
> maximum transaction time including timeouts".

Thanks.  I'll add the following paragraph into the section 9.

   When a KINK peer retransmits a command, it MUST use the same ticket
   within the retransmissions.  This is to avoid race conditions on
   using different keys, which result in different KEYMATs between a
   initiator and a responder.  For this reason, the initiator MUST
   obtain a ticket whose lifetime MUST be greater than the initiator's
   maximum transaction time including timeouts.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Jul 2005 11:43:20 -0400

Presumably the correct behavior is to start a new transaction with the
new ticket?

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 29 Jul 2005 09:55:20 +0900

At Thu, 28 Jul 2005 11:43:20 -0400,
> Presumably the correct behavior is to start a new transaction with the

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.