[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay attacks
>
> Hi Ran,
>
> Regarding replay detection: I suggest that,
> rather than use as a sequence number the 16-bit reserved space of
> the AH header (which would be a bit spare!) replay detection can
> be handled by choosing a MAC mechanism which directly provides
> that service. Indeed a 96-128 bit MAC has ample space to
> directly incorporate replay detection, and one can "generically"
> modify any (ordinary) Message Authentication mechanism into a new
> one which protects against replays. The cost is making the
> MAC some 32-64 bits longer, say.
>
>
> Phil
>
This sounds like a good idea to me because I no longer have any
confidence in the ability of higher level protocols that were
designed to weed out accedentally delayed packets to weed out
intentionally delayed packets. There are two basic problems you
have to worry about:
1. sequence space wrapping
2. brain dead initialization of the sequence number
Going to a 64 bit sequence number probably takes care of the first
for a while. But remember that the TCP large windows options actually
has a 32 bit sequence number combined in an with a 32 bit time
stamp which just happends to be accurate enough to weed out old
duplicates. This is complex enough that it took me a while to
figure out that it would work on accedently delayed packets.
I don't what an active atacker could do with it.
The real problem though is that every time a machine reboots you are
supposed to come up with a random number for the intial sequence
number. It is unclear how many TCP's actually do this. Thus you may
be able to predict a-prioir what the sequence space will look like
after a re-boot. As we all know a good random number is often hard
to find especially at boot time.
Just to be parinoid I would also like to see any sequence number
designed for protection against active attacks be encrypted or
otherwise obscured. Putting in the clear in the packet is asking
for trouble.
Sean O'Malley
ps. I used to be in the "its not our job" camp on this issue but
enought thought about TCP changed my mind.
Follow-Ups:
References: