Dan Harkins writes: > We've been through nearly 40 revisions of this protocol (18 for IKEv2, > another > 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it > still > needs hacks to add some new elliptic curves-- either N new authentication > modes for N curves, or a new unified and general ECDSA in addition to the > existing 3 for ECDSA (!!!)--
You forgot the IKEv1 drafts too, as IKEv1 does the ECDSA at the same way than IKEv2 (they both come from the same RFC), so they should also be counted as revisions. And, no, I have no idea why the people who added ECDSA did add it that way. I always assumed that there is no way to know the domain parameters and hash from the cert / signature, and thats why they needed to be encoded to the auth algorithm field. Now it seems my assumption was incorrect. But with the patent issues with elliptic curves, nobody really used EC, thus nobody really cared... (at least for me the reason I did not care about EC was those patent issues, and also as there was no real customer demand for them, or to say that the customer demand usually went away when they heard there are patent issues). > and even still there will be interoperability issues because some > people represent an ECDH shared secret as x||y and others represent > it as x. Yes, this just points how little people cared. Some people did notice it, but just assumed that ok, they just wanted to things differently and changed their code to do what original RFC4753 defined. Fixing that kind of problem with errata, was really bad mistake. And I still think fixing that problem without allocating new numbers were again mistake, but I lost that fight. Also it took several years before this issue was even noticed, that tells how little EC groups are really used (either in IKEv1 or IKEv2, as the same mistake was in both of them). > Notice how the Notify payload is becoming the overloaded payload of choice > to "fix" everything? It's hacked for EAP-only, it's hacked for secure > passwords, and it's the method of choice to hack in new curves. Yuck. I do not think notify payload has "become the overloaded payload of choice", it was originally defined in IKEV2 for that purposes also: ---------------------------------------------------------------------- 3.10. Notify Payload ... in any other message to indicate sender capabilities or to modify the meaning of the request. ---------------------------------------------------------------------- The main reason why notify is used in the IKEv2, is that it is secure (compared to IKEv1, where it cannot be used as it is not authenticated in phase 1) and easy way to do capability indications. I myself think notify payload is much better than using vendor ID payloads which was normally done in IKEv1. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
