[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention SecurityTransform to Proposed Standard




> >> >      1. (Optional step) Decrypt the first bock of data using the
> >> >      appropriate DES_key_ and IV_key_ (or IV) and then do a quick
> "san-
> >> >      ity check" of the count.
>
> Lets now take a -fresh- look at the optimization and forget what
> the draft says or what the previous email said.
>
> If someone wanted to perform a SYN type (clogging attack) of
> attack on an IPsec device, it could take any open SPI and send in
> packets with random data exchanged for the encrypted data. To
> detect a bogus packet, the decrypting device would require DES
> on the entire packet and MD5 on the whole packet as well. If the
> network the device is attached to is faster than the packet
> processing (DES/MD5) engine, then the queues will fill and
> packets will be tossed and denial of service may result.
>
> Since the count is encrypted (and assuming the attacker does
> not have the DES key and therefore can not create known
> non-duplicate counts), detecting someone trying to clog can
> be performed by decrypting the first block and seeing -if- the
> decrypted count is reasonably valid (since the attacker can
> not control what the data looks like after the decryption
> step).
>

Since is no mechanism to validate the replay counter without
decrypting the whole packet and validating it, there is a
replay window size dependent probability that randomly
chosen "first DES words" may cause the whole packet to be
processed. If the replay window is 64k and the replay counter 32
bits, then that probability is 64000/4294967296 = ~.000014, or
~1/67108.

Presumably the replay window size is that large (64k) to
account for high speed data. It seems reasonable to believe,
then, from a flood of 67k packets one will result in a CPU spike.
If we assume the attacker is able to monitor the receptor and
detect the spike then some valuable information is gained:
bogus_data = DES(replay count +/- 64k), or several bits of fixed,
albeit unknown, text.

I can't say how useful the knowledge of unknown fixed text will
be to an attacker (it may be useful in conjunction with other
data) or whether the assumption I made holds, successful
attacks based on timing information have been mounted on
systems in the past.


-dpg



References: