Scott Fluhrer (sfluhrer) writes: > > That implementation is broken, and needs to be fixed. > > I can easily see a manufacturer claiming "my implementation has been > working without a problem for 13 years; why does it need to be > fixed?"
And the answer will be: Because it is broken, and it is not following what RFC says. Even if this issue was not found before as this feature was not used, this does not mean that their implementation would be less broken. And if any vendor says that they have not done any single security fix for their implementation for last 13 years, it is time to switch vendors. > Ultimately, it's the working group that needs to decide whether we > need to respect the (to the implementors) apparently valid > assumption as de facto, or whether we feel we can break them. We had same issue earlier. I.e., several implementations did assume that we never need mor than one proposal, as there is never need to support policies that would require more than one proposal. I.e., they did not support policies which said 3DES + MD5 or AES + SHA1, but which forbid 3DES + SHA1 and AES + MD5. This would have required two proposals, and as those kind of policies are stupid, some implementations (like mine) did not support them. When we defined combined mode ciphers, we decided that you need to do that with two proposals, one having non-combined mode ciphers and other having only combined mode ciphers. All implementations wanting to support combined mode ciphers, needed to include support for at least two proposals if they wanted to allow policies that allow both. To support backwards compability implementations can put the non-combined mode ciphers in first proposal, so if other end only parses first proposal, it will find the find the acceptable proposal from there. Those old implementations did not support combined mode ciphers anyways. We can do same here. Put traditional DH version in first proposal, and they will most likely pick that... Or you can put vendor ID check and return error "Other end is using obsolete implementation of the IKEv2, please upgrade it immediately as those kind of implementations not receiving updates are most likely vulnerable to all kind of attacks. Are you sure you really still want to connect using compatibility mode?" -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
