David Wierbowski writes: > Thanks for your answers, but I should have been more specific in my > question. I was not asking how a MITM could break IKE. I was asking for > an example of how draft-ietf-ipsecme-failure-detection-01 increases the > risk over what we have today in IKE. That's what I'm not seeing.
If the QCD token generation secret is shared with multiple hosts which do NOT share the same IKE SA state then there are attacks which are not possible without QCD. > An eavesdropper could see an IKE request (e.g. CREATE_CHILD_SA request) > and forge an informational message back to the requester containing N > (INVALID_IKE_SPI) and N(QCD_TOKEN). If he guesses QCD_TOKEN correctly he > can disrupt the IKE_SA and force a negotiation. So in theory this makes > IKE more prone to a passive MITM, but that's theory. Given significant > randomness in the token the attack is not feasible. If there's a flaw in > the RFC that makes tokens easy to guess this would be a valid attack. > True, if we do not mandate the algorithm somebody can implement a token > generation scheme that is easy to guess. There has been talks here in the list about cases where we have loose cluster which do not share same IKE SA state, but which do share QCD token generation secrets. Such clusters would be vulnerable to this kind of attacks regardless whether the token generation contains token takers IP number or not. The attack simply needs to fake one IKE SA message so that its source IP is the real source ip of the host attacker wants to attack, send it to the cluster member which do not have the IKE SA state for that IKE SA, and then see the QCD reply sent by the cluster member. This reply now contains the QCD token which can then be used to attack the host. Actually normally when that packet reaches its final destination the host will tear down its IKE SA anyways. So attacker just need to know the IKE SA SPI pair and the IP addresses of the valid IKE SA on one cluster member and then send any faked IKE message to another cluster member sharing same QCD token generation secret, but separate IKE SA database. The section 10.4 seems to assume that attacker cannot force the load balancer to send the faked packet to any other cluster member than the one mapped by the source IP-address of the packet. As the algorithm how the load balancer really selects the peer where it sends the packet is not necessarely known by the IPsec implementations, I do not think we can trust we can include all same information to the token generation. For example it could use source port numbers, or destination IP-address, etc so I think it is quite unsafe to assume anything what the load balancer might do. I think it would be safer to forbid situations where the cluster members share the same QCD token unless they also share the IKE SA state. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
