[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bellovin's and Ahar's attacks
Danny, regarding the issue you raise:
> However, in
> high value applications, there is no reason to believe an intruder will not
> spend the resources to write a program that detects a potentially valuable
> stream of target traffic, coordinates with an end system program and
> replay's it according to Phil's and Ashar's suggestion. For example,
transaction
> systems (of the kind used to execute stock market trades) would be a perfect
> target for such an attack. Each transaction is an independent action, may
> quickly use a port and then make it available for use by other programs and
> might provide an intruder with potentially valuable information (buy/sell
> signals).
If we use Steve Bellovin's suggestion that ESP require AH, then the
destination system will always deliver current traffic to the appropriate port.
So the only issue is Ashar's attack, where the attacker (quickly) reopens
the same port, replays the encrypted packets, and thus gains access to
the cleartext. I have several suggestions:
1. If the IPSEC processing is happening within the destination system,
then it should rekey every time a socket is closed. This ensures that
any subsequent user of the same port will get a different key.
2. If the IPSEC processing is happening in a firewall, then it could notice
whenever a TCP connection is closed and could rekey at that time.
That ensures that any subsequent TCP session will use another key.
3. If the IPSEC processing is happening in a firewall, and the application
uses UDP then there is no possibility of either per-session keying or of
re-keying at some appropriate time. The firewall just doesn't have the
necessary information. Unless maybe we could get the end systems to
send some kind of indication (like an ICMP packet) that rekeying should
happen. But this requires changing end-systems - which dilutes the
value of the firewall scheme.
Follow-Ups: