[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bellovin's and Ahar's attacks
Let's take Ashar's scenario a step further. Assume that two parties LA and LB
are communicating via UDP on machines that are behind firewalls. That is,
IPSEC and ESP are used to provide a secure tunnel between two firewalls. LA
and LB are operating on machines that are "behind" these firewalls at the two
ends of the tunnel. Assume that an attacker can record the traffic in the
tunnel and can also login as a user on LA's or LB's machine. Then, after LA
and LB have gone away, the attacker can replay the recorded traffic and have
one of the firewalls decrypt the traffic and deliver it to the LA or LB machine
where the attacker has taken over the destination port.
I suggest that they only solution for this situation is frequent re-keying in
the firewalls. Using different keys for different UDP source/destination
address & port pairings doesn't help with this attack because the scenario is
that a given address & port are taken over by the attacker. The only option is
a time-based re-keying strategy.
We will certainly need to discuss how often to re-key. When the transport
protocol is TCP, the network layer could notice when a TCP session is closed.
If it re-keyed at that point, then a replay attack would be fruitless.
Re-keying could also be triggered by receiving an ICMP port-unreachable
message. But I think we have to rely on time-based re-keying for UDP. This
argues for a cheap and fast re-keying mechanism, so that we can afford to do it
quite often.
If we follow Bellovin's suggestion that AH be required when ESP is used, then
we guarantee that IP packets are delivered to the correct destination. I
suggest that once we've done that, per-session (or per-user) keys are not
required as long as we re-key frequently. The re-keying defeats Rogoway's
attack as effectively as per-session keying. For example, if we have a single
key between two hosts but change the key every time a TCP session closes then
subsequent users of the same ports can't use Ashar's attack.
Having a separate key per session implies a much larger SA table than having a
key per host. I think we'd do better to re-key a single host key fairly often.