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

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;
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.

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm