[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: