Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

At Mon, 28 Jul 2008 09:31:46 -0700,
Adam Langley wrote:
> 
> On Mon, Jul 28, 2008 at 8:05 AM, Joe Touch <touch@isi.edu> wrote:
> > | There is no need for a unique per-packet nonce.
> >
> > If so, then why generate fresh keys on rollover?
> 
> (This is pretty much a reposting of a previous email, but people still
> seem to be hazy on this point)
> 
> We have a couple of reasons for wanting to define an nonce:
> 
> Reason 1: Without a monotonic counter, a MAC is open to replay
> attacks. I'm not sure how serious this is. Certainly you can elicit
> different behaviour from stacks by replaying, say, an ACK very
> quickly. This is undesirable, but it might be acceptable. More
> troubling is the possibility of exploiting sequence number rollover to
> inject a valid packet from 2^32 bytes in the past into the current
> stream. A monotonic nonce would mean that we could reject replays.
> 
> Rotating the keys faster than the sequence number rolls over mitigates
> the most grievous of these issues.
> 
> Reason 2: Modern dot-product and polynomial MAC functions require an
> nonce as an input and their
> security depends on the nonce never being reused for any other message
> with the same key. Consider a connection where all the
> application-level data transfer is one way and a packet, seq number n,
> is lost by the network. Here, it's very possible that an ACK for n-1
> is transmitted, followed by an ACK for n-1 with a SACK option. Now
> we've transmitted two different messages with the same nonce. Any
> nonce based only the sequence numbers has this problem unless we
> disable/don't include SACK. Also, if we are only including 32-bits of
> seq, then we trivially repeat every 2^32 bytes.
>
> Now, we can just ignore the MAC functions described in reason 2;

Indeed, we should do so. If those algorithms in fact need a MAC they
should describe some procedure for generating and using them 
(and presumably attaching them to the message). AFAIK, neither
HMAC nor CBC-MAC requires such a nonce.

> having a per-message counter is probably too much additional work.
> Having a "pseudo" extended sequence number is very little work
> (really, I've already implemented it) and that mean that we don't have
> to rekey faster than the 32-bit sequence rollover. However, the
> rekeying isn't all that painful anyway.

It depends what you mean by rekeying. If it involves a new protocol
exchange it is incredibly painful. If you mean just running the kdf
again, I agree that's fine.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm