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

Re: Bellovin's and Ahar's attacks

	 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. 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.

I suspect that it will take a bit of experimentation to determine what's
really the best course.  However, if one end of the UDP association has
terminated, its socket is unbound, and hence the key tied to it is released.
If a new user allocates that port number, a different key (and SPI) will
be allocated.  A packet from its former peer, encrypted with the old
key, will be bounced via (authenticated?) ICMP.

This doesn't work for router-based encryptors; however, I've concluded
that we need to refine our model there.  Rather, we need to make explicit
our assumptions.  By *definition*, the net behind a router-based encryptor
is trusted, and is at (more or less) the same security level.  We must
still contend with the problem of an internal net that is physically
secure, and hence proof against internal eavesdroppers, while still
finding a defense against corrupt insiders who reinject encrypted packets
on the outside net.

It's important not to confuse the replay attack with my CBC
cut-and-paste attack.  The latter is comparatively easy to counter,
either by per-packet rekeying (which SKIP could do architecturally,
albeit at some cost), per- user or per-connection keying, or mandatory
integrity checks.  The former can't be countered by SKIP or by
integrity checks, though per-connection or per-user keying would work.
For a router-based encryptor, though, replays seem to be preventable only
by keeping track of old packets, and rekeying whenever the cache is full.