Subject: [Hipsec] Receiving an R1 in the established state (E3)?

From: [email-masked] (Pekka Nikander)
Date: Fri Sep 5 08:26:02 2003

draft-moskowitz-hip-07.txt currently specifies that if
an implementation receives a valid R1 in the established
state, it sends an I2, drops its SAs, and goes to the
state E2.  For an R1 to be valid, it is required that
the host has recently sent data to the sender of the R1,
and that the birthday number in the R1 is higher than
the currently recorded one.

This opens up a potential attack.  An attacker can
record an R1 from a different connection, forcing
a higher birthday number.  It can get the higher
birthday number by forcing the host to rekey in some
other connection.  Once the attacker has got this
kind of an R1, it can send it to the target node,
which will drop the SAs as described above.  It is
even possible that the state is NOT re-established,
since the sent I2 may fail the birthday check at
the recipient, and as a result the recipient will
never send an R2.

I suggest that we add a new state, maybe called E3'.
This is otherwise similar to E3, but differs in how
an incoming R2 is processed.  Currently in the E3 state
an incoming R2 is dropped.  In the new E3', an incoming
R2 would be processed and the SAs would be replaced
with the new ones.  That would allow the target node
to continue sending data using the old SAs, just in the
case that its peer is still able to receive data.

Hence, in a way, in E3' the implentation remembers
two sets of keying material:  the old one (still used)
and the new one (based on received R1 and sent I2).
Only when a matching R2 is received, the key material
is replaced.

This change would make the implementations more complex,
but also more robust against this specific kind of attack.

Comments?

--Pekka