Re: Retransmitting a command with different tickets

At Fri, 22 Jul 2005 14:26:20 -0700,
Michael Thomas <[email protected]> wrote:
> 
> > 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?
[snip]
> > 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.
> 
> 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.

-- 
KAMADA Ken'ichi <[email protected]>