[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bellovin's and Ahar's attacks
Danny said:
>IPSEC processing will happen both on the source and destination >systems. The
>destination can't rekey unilaterally, since the source would still be >using
>the old key. So there has to be synchronization between the source >and
>destination when rekeying occurs.
The destination "owns" the SPI and security association, so it certainly can
initiate a new key-management exchange to tell the source to start using a new
SPI and new key.
However, there is a definite problem here. The destination has to allow for
the fact that the source will continue to use the old SPI for some time.
During that time, the destination has to be willing to accept data under the
old SPI since the alternative is to stop communication for awhile. This opens
a period during which Ashar's replay attack would succeed. Not good.
We can minimize but not close this hole by careful engineering of the re-key
protocol. For example, we can require that the source respond to the re-key
and that the destination delete the old SPI when it gets the response or after
a timeout, whichever is sooner. Then the replay attack can only last as long
as the timeout and then only if the attacker somehow intercepts the re-key
response. We could also get fancy and have the key management protocol keep a
running estimate of the round-trip time and set the timeout accordingly.
> Its been known for a long time that
>TCP connections could support rekeying when they open a >connection. However,
>UDP doesn't support the notion of a connection, so rekeying UDP >end-points
>requires some external synchronization.
IPSEC re-keying is NOT an extension to the TCP or UDP protocol; it is external
to both of those protocols. I propose that it could be triggered by the fact
that a socket is closed, not that it be part of TCP or UDP.