On Tue, March 27, 2012 7:39 am, Tero Kivinen wrote: > 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.
Yet there is still this massive deployment of XAUTH + IKEv1. >> 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". Yes we should. But we should not suffer any delusions that we can force anyone to do anything. > 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. We can't always get what we want and we should be reasonable in understanding that. If we could wave a magic wand and grant your wish that would be good; we can't. And given the limits to our power we have to accept that what will happen is people will continue to use IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK though, so it is likely that by adding SPSK to IKEv1 we could get people off of XAUTH and that too would be a good thing. So if we weigh the improbable stretch goal of forcing people to stop using IKEv1 with the probable, more easily attainable, goal of getting people to stop using XAUTH by giving them an alternative that can pretty easily be implemented, I still come down on settling for an achievable goal of goodness and not making that be a victim for an unachievable goal of betterness. >> 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. OK, so we're in agreement: "Specification Required." Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
