Hi,
few more thoughts on this attack.
[HJ] yes, you are right. So to summary what has been discussed previous in this
thread:
On Initiator side:
- This attack is impractical if the initiator's SPIi is unpredictable, since it is infeasible
for attacker to compute C1/C2 offline for all possible SPIi. And it is impossible
to compute C1/C2 online before client switch to a different SPIi.
- On responder side:
- if responder is expecting a cookie, then the C2 won't match the expecting cookie,
responder will return the expecting cookie, this attack won't work in this case.
- if responder is not expecting a cookie, then it could still verify the cookie to prevent this attack.
One of the checks could be done is a legit cookie length must be <=64B.
While all these checks on responder side are useful, they cannot really prevent
this attack. The attack can be easily modified so that the message sent from
the attacker to the responder looks unsuspicious. All that attacker need to do
is to find C1 and C2 so, that the COOKIE notification type in C1 is changed to
any unused status notification type in C2. It is just a little bit harder than the current
version of attack. However after that the message sent from the attacker to
the responder will look like:
M' = HDR | Nx=C2 | SAi' | KEi' | NONCEi' | Ny=(SAi | KEi | NONCEi | info_i)
So the responder will see two unknown status notifications (Nx and Ny)
and will just ignore them. Nothing suspicious.
So the only real defense against this attack is an unpredictability of SPIi.
Is it enough? I don't know. I would feel more comfortable if initiator
puts the cookie at the end of the message, thus making this attack
infeasible:
HDR, SAi1, KEi, Ni -->
<-- HDR, N(COOKIE)
HDR, SAi1, KEi, Ni, N(COOKIE) -->
Note that this doesn't violate RFC 7296, since the payloads may come
in any order. However it may break some existing implementations...
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
