[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bellovin's and Ashar's attacks
Russ says:
>
> In the case of the shared host, we need to ensure that the protocol
> conveys information necessary to prevent leakage when the enemies
> serially reuse the same resource, a port in the recent examples.
> discading the key when the port is closed sounds great. Better yet,
> Discard the key and tell the other key management daemon that you did
> it.
This is fine when the host is running IP-SEC. The problem persists if
the host is unmodified and IP-SEC is done at a firewall/encrypting router.
In this case, the firewall would not know that the port was closed.
The only solutions so far are fast re-key and counters; both are, as pointed
out on the list, imperfect as they still allow an attacker to re-play packets
within the timeout period (both methods must allow time-out period of at least
the maximal allowable round trip delay). For manual attackers this may be OK,
but, as was pointed out, one could run a program that constantly looks for
closed ports and immediately tries to replay traffic.
This attack is possible, but if fast re-keying is used, it is very difficult
if not unrealistic, and the gain is limited (just the last few packets before
the latest key-change). Furthermore, the attack is very `noisy' i.e. could
often be detected, which makes it a poor cracking method.
Note that the attack is more difficult if the two endpoints maintain just one
security association to all traffic, i.e. end to end based keying. In this case
the attacker would not know which packets to replay (which belong to the
correct
port). Also, faster re-keying could be supported.
I'm not sure that the counters would buy us much more than just plain fast
re-key. Maybe fast re-key is enough. Unless somebody has a good argument,
I prefer we keep the ESP document simple and minimally modified.
>
> In the shared comms case, I have a real hard time. If your enemy is
> sharing the comms between you and your crypto, then you shouldn't bther
> with the crypto at all.
That's true for _real time_ attacker. But the system should be secure against
a _midnight_attack_ where the attacker gains access only much after the
communication took place. Fast re-key would definitely solve this problem.
Best, Amir
References: