Hi, Let me answer David here in a response to Yaron....
To be equally blunt, it is because this PAKE work became extremely political and I was, and still am, very unhappy with the way it turned out. Repeating it, this time with an obsoleted protocol, would cause (more) people to question my sanity-- i.e. doing the same thing and expecting a different result. I'd like to just get a stable reference for this minor change that has the potential to do good. I don't want to fight over it anymore. regards, Dan. On Tue, March 27, 2012 2:13 pm, Yaron Sheffer wrote: > Hi Dan, > > I haven't made up my mind yet whether I support the addition of SPSK to > IKEv1 or not, because both you and Tero have made some good points. > > But this very discussion is a strong proof to me that we need to have > IETF Review (in the RFC 5226 sense) for this kind of major change to > IKEv1. Because this is exactly the community that needs to discuss new > authentication methods, and to weigh their security and other properties > against the disadvantages of adding yet more stuff to IKEv1. This needs > to be an open discussion, and I am sure the ADs will use our input when > they decide whether to sponsor any such proposal. > > Thanks, > Yaron > > On 03/27/2012 06:41 PM, david.bl...@emc.com wrote: >>> I think we can make things better with a simple addition and I just >>> want to be able to do that. >> >> To ask bluntly - what is the problem with soliciting AD sponsorship for >> the simple addition? >> >> IMHO, "Specification Required" by itself is entirely too weak for >> security protocols. >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Dan Harkins [mailto:dhark...@lounge.org] >>> Sent: Tuesday, March 27, 2012 12:23 PM >>> To: Black, David >>> Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org >>> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication >>> Methods (Value 3) registration >>> policy >>> >>> >>> Hi David, >>> >>> On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote: >>>> Hi Dan, >>>> >>>> One process note: >>>> >>>>> It appears that all the PAKE drafts got one "yes" from the >>>>> sponsoring >>>>> AD and the remaining votes were "no objection" so it doesn't seem >>>>> like >>>>> the IESG is really interested in this topic and, frankly, I think the >>>>> majority think "that stuff is out of my field of expertise". So my >>>>> only >>>>> option is to cajole an AD into sponsoring my draft and hoping that no >>>>> one >>>>> else on the IESG objects by saying, "didn't we just do this?" >>>> >>>> Speaking from long experience as a chair of many WGs, that sort of >>>> IESG >>>> vote tally is typical, even for WG docs (although usually both of the >>>> responsible Area ADs vote yes, as they're both "sponsoring"). IMHO, >>>> you're being overly pessimistic. >>>> >>>>> So let me turn it around, what's wrong with "Specification >>>>> Required"? >>>> >>>> While I know that you're competent to design a solid protocol, who >>>> does >>>> the security review of the next 5 j-random authentication mechanisms >>>> to >>>> make sure that they don't have security flaws? I'd prefer something >>>> like >>>> IESG approval that puts the Security Area in the loop to the notion of >>>> deferring to some form of Expert Review (this is not a slam against >>>> Tero >>>> as the expert - wider review usually produces better results). >>> >>> That's a really good point. Had it been "Specification Required" all >>> along XAUTH might've gotten an official code point. And who knows maybe >>> one of the j-random proposals might be just that. But IKEv1 really is >>> pretty done. At this point I'm pretty sure that j would be zero. >>> >>> I know IKE's being used wrong and I know the people who are using it >>> wrong don't want to go to IKEv2. They understand what they're doing is >>> broken (a shared PSK for everyone followed by PAP in XAUTH) but they >>> don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound >>> like going to IKEv2 with SPSK is much more attractive. >>> >>> I think we can make things better with a simple addition and I just >>> want to be able to do that. >>> >>> regards, >>> >>> Dan. >>> >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
