Valery Smyslov writes: > While all these checks on responder side are useful, they cannot > really prevent this attack.
Actually it does. > 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) Attacker cannot do that, as attacker will not be able to get original initiator to reflect the Nx=C1 back in the m1. Cookies notifications are used because are required from the initiator to be copied from the original SA_INIT reply to the retry SA_INIT request. For that unknown notification that would not work, i.e. when the attacker sends back the SA_INIT(ck=|C1|SA',gx'|ni|) the initiator will ignore the first notification if it not cookie, and will not retry with message sending cookie notification. > So the responder will see two unknown status notifications (Nx and Ny) > and will just ignore them. Nothing suspicious. If the attacker changes the m1' to contain some other notification in the beginning that cookie notification he needs to find different type of collison where the prefix is no longer constant, i.e., he needs to modify that. > So the only real defense against this attack is an unpredictability > of SPIi. And checking the small subgroups in Diffie-Hellman, i.e., not using groups 22-24. > 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... I think using random SPIis is enough. Even if you SPI only contained 2^32 different values, that means that attacker needs to do expensive precalculations for each of those different values, making the cost of attack 2^32 times harder. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
