Hi Nico, We discussed this in the WG. The non-PKIX authentication mechanism using EAP entails pointless encapsulation, twice as many messages, unnecessary code bloat from implementation of both client and server EAP state machines (where it had been the case, in RFC 4306, that an implementation only needed to do one), and the introduction of problems that didn't use to exist (like the "lying NAS" problem). The WG added this work item for a very good reason.
So how do you think the work item should be solved given that the WG already decided to solve it? What do you think of my draft? Dan. On Mon, May 24, 2010 2:54 pm, Nicolas Williams wrote: > On Mon, May 24, 2010 at 02:50:23PM -0700, Paul Hoffman wrote: >> At 2:07 PM -0700 5/24/10, Dan Harkins wrote: >> > This is out-of-line. >> >> Would it have been less out-of-line if I, the other co-chair wrote it? >> Or if someone who is not a co-chair but understands how the IETF >> process is supposed to work wrote it? >> >> FWIW, I agree with what Yaron wrote. If there is little or no interest >> in advancing this work other than from the authors of the drafts, we >> should strongly consider taking it out of the WG charter. You >> disagree, and others might agree with you or with Yaron. > > Personally I'd much rather that the WG add non-PKIX authentication > mechanism options to IKEv2 via existing frameworks: either EAP or the > GSS-API. > > Nico > -- > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
