Scott Fluhrer (sfluhrer) writes: > How is that behavior fundamentally different from the behavior we > would get if the attacker inserted a valid, but different KEr* > payload? In that case, the tests will pass, and we'll perform the > DH, and come up with incorrect SKEYSEED.
Not that much difference, but for those RFC5996 already has text saying you can process multiple KEr's if you want to: ---------------------------------------------------------------------- 2.4. State Synchronization and Connection Timeouts ... There is a DoS attack on the initiator of an IKE SA that can be avoided if the initiator takes the proper care. Since the first two messages of an SA setup are not cryptographically protected, an attacker could respond to the initiator's message before the genuine responder and poison the connection setup attempt. To prevent this, the initiator MAY be willing to accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptographically valid. ---------------------------------------------------------------------- I.e. implementation is allowed to fork the IKE SA creation at that point and process all of the branches and see which one of them leads to the valid authenticated IKE SA. I do not think any of the implementations actually do that, but it is allowed. The current text in the dh-checks would overwrite that and as it says the whole IKE SA MUST be dropped, (not only the offending message), that would open new DoS and prevent using the solution offered for it in the RFC5996. > If the real responder will then send the correct "HDR, SAr1, KEr, > Nr, [CERTREQ]", well, the initiator has already received its > response and generated some SKEYSEEDs. I wasn't aware that it was a > requirement that the initiator create multiple SKEYSEEDs if it > happens to receive multiple initial exchange 2 messages. As you can read from above, there is no REQUIREMENT to do that, but it is allowed. The text in the dh-checks would forbid that... > For an attacker's point of view, the behavior he gets by sending > valid KEr* payloads is even more advantageous; he has not only > prevented the SA from being created, he also forced the initiator to > do more work before doing so. Yep. > > Also these tests might also fail during the CREATE_CHILD_SA exchange. > > There isn't a real requirement to discard the parent IKE SA; of > course, we can't allow the creation of the child SA. The problem is that if this is noticed in the Initiator then the Responder has already created Child SA, but Initiator cannot create it. Thus Child SA state is out of sync, and the general solution for that in the IKEv2 is to restart the IKE SA, i.e. delete IKE SA and start over. As here the other end cannot be unauthenticated, this is most likely caused by a bug in the implementation and restarting might or might not help, but at least that does not cause black hole problems. > While I don't think the below text is wrong (except I would point > out that there is no security requirement to discard the parent IKE > SA during a test failure while generating a child SA), I would also > point out that these don't appear to have any advantage over the > current text. There is no security requirement to discard IKE SA, but there operatinal reasons to do it. I.e. that would be clear indication that something is wrong, thus most likely will cause one of the peers to start investingating the problem, especially if it is persistent problem. On the other hand if the problem is not persistent, and is fixed by starting IKE SA over, then even better... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
