Dan Harkins writes: > That said, the problem I want to fix-- IKEv1's susceptibility to > dictionary attack, it's binding of a PSK to an IP address, and the > prevalence of XAUTH because there's no other option-- should be fixed.
All others than the dictionary attack IS ALREADY FIXED. The fixes are in the IKEv2. Also the dictionary attack problem will be fixed by your IKEv2 SPSK draft. > We can say, "stop using IKEv1" but giving someone the option of > implementing PAKE + IKEv2 versus just implementing PAKE, or more likely > just continuing on with a broken XAUTH deployment, we all know what > they'll do and it's not doing PAKE + IKEv2. Yes, we can and should say "Stop using IKEv1". That is the part I agree with you. I do not want to add any new features to IKEv1, as that just makes people to continue use it, and not to update to the IKEv2. If PAKE is the stick that causes people to move from IKEv1 to IKEv2, that is very good. > It would be a service to the Internet to provide a fix for this. The > IETF has not been successful in forcing people to do things against > their will (viz, the history of IPv6) and if we tried here we'd > likely fail again. > > So let me turn it around, what's wrong with "Specification Required"? Read the whole original thread and find out there. I do not really have any objections for Specification Required, that was what I originally proposed. The original thread (I just gave the link to first email in the full thread) has emails which explains why people felt it was not enough. Regardless whether it is Specification Required or not, I am still objecting if someone tries to add new features to IKEv1. Of course my objecting might not have any effect, but I still think it is BAD idea. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
