Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method?
Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term "snail race" is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan > Harkins > Sent: Monday, April 28, 2008 2:12 AM > To: Stephen Hanna > Cc: emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > > That's true. One person's opinion does not negate consensus, > even if that one person is the only one who is able to opine > in the alloted time given for opinions (twice now). But so what? > If someone asks then I'll give an honest opinion, especially > since no one else seems to be able to. > > But maybe you're right. Any additional work taken on by this > group would distract from the fantastic progress we've made in the > past 9 months on the tunneled method. It would be a shame to lose > all that. Yes, let's just focus on the snail race.... > > Dan. > > On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: > > I apologize for my tardy response. I have been on vacation. > > > > I agree with and support the proposed charter below. As for > > Dan's suggestion that we not require the password based > > method to be based on the tunnel method, the WG already > > went through a long discussion and consensus check last > > fall on this matter. There was clear consensus that we > > should NOT work on a new password based method designed > > to function without the tunnel method. One person's > > opinion to the contrary does not negate that consensus. > > I think that the reason we are not seeing much email on > > this charter is that the issues and language have been > > hashed through many times. > > > > Thanks, > > > > Steve > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > > Dan Harkins > > Sent: Friday, April 25, 2008 5:43 PM > > To: Joseph Salowey (jsalowey) > > Cc: emu@ietf.org > > Subject: Re: [Emu] EMU charter revision > > > > > > Hi Joe, > > > > Once again, a call for comments and I'm the only one to comment. > > > > Whether removing that line achieves "my goals" or not I still think > > it should be removed. And that really seems to be the only comment > > on the charter you get when you ask. > > > > regards, > > > > Dan. > > > > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: > >> > >> > >>> -----Original Message----- > >>> From: Dan Harkins [mailto:[EMAIL PROTECTED] > >>> Sent: Friday, April 11, 2008 10:38 AM > >>> To: Joseph Salowey (jsalowey) > >>> Cc: emu@ietf.org > >>> Subject: Re: [Emu] EMU charter revision > >>> > >>> > >>> Hi Joe, > >>> > >>> Thank you for giving me the opportunity to object, once > >>> again, to the last sentence in the last item in the charter. > >>> If you were to run the following sed filter on the charter I > >>> would approve: > >>> > >>> s/This item will be based on the above tunnel method.// > >>> > >> > >> [Joe] I do not think that removing this line would achieve the goal > > you > >> wish. With this line removed EAP-PWD is still out of scope of the > >> charter as it does not meet the requirements of supporting legacy > >> password databases. The message from the ADs in the last meeting was > >> pretty clear in that EAP-PWD style mechanisms is not something for the > >> group to take on right now. This does not mean that we cannot take on > >> an EAP-PWD style mechanism once we have made progress on the current > >> charter items. > >> > >>> What is the process here? This looks the same as the > >>> charter revision you made a consensus call on back in > >>> January. I was the only one to opine before your cutoff last > >>> time and my comment was the same as above. Now we're doing this > > again. > >>> > >> [Joe] There have been several revisions posted to the list and > > feedback > >> from several working group members that have been worked into the new > >> proposal along with input from the discussion in the last meeting. If > >> enough people respond positively, such that we have rough consensus, > >> then we can move forward. > >> > >> > >>> Dan. > >>> > >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: > >>> > Below is a revision to the EMU charter that is intended to > >>> reflect the > >>> > discussions in the Philadelphia meeting. Please respond to > >>> the list > >>> > if you approve of the charter or if you have any comments > >>> on the charter. > >>> > I would like to have responses by 4/24. > >>> > > >>> > Thanks, > >>> >f > >>> > Joe > >>> > > >>> > Description of Working Group: > >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is > >>> a network > >>> > access authentication framework used in the PPP, 802.11, > >>> 802.16, VPN, > >>> > PANA, and in some functions in 3G networks. EAP itself is a simple > >>> > protocol and actual authentication happens in EAP methods. > >>> > > >>> > Over 40 different EAP methods exist. Most of these methods are > >>> > proprietary methods, but some are documented in > >>> informational RFCs. In > >>> > the past the lack of documented, open specifications has been a > >>> > deployment and interoperability problem. There are > >>> currently only two > >>> > EAP methods in the standards track that implement features > >>> such as key > >>> > derivation that are required for many modern applications. > >>> > Authentication types and credentials continue to evolve as do > >>> > requirements for EAP methods. > >>> > > >>> > This group is chartered to work on the following types of > >>> mechanisms > >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: > >>> > > >>> > - An update to RFC 2716 to bring EAP-TLS into standards > >>> track, clarify > >>> > specification, interoperability, and implementation issues gathered > >>> > over the years, and update the document to meet the requirements of > >>> > RFC 3748, RFC 4017, and EAP keying framework documents. Backwards > >>> > compatibility with RFC 2716 is a requirement. > >>> > > >>> > - A mechanism based on strong shared secrets. This mechanism should > >>> > strive to be simple and compact for implementation in resource > >>> > constrained environments. > >>> > > >>> > - A document that defines EAP channel bindings and provides > >>> guidance > >>> > for establishing EAP channel bindings within EAP methods. > >>> > > >>> > - A mechanism to support extensible communication within a TLS > >>> > protected tunnel. This mechanism must support channel bindings in > >>> > order to meet RFC 4962 requirements. This mechanism will support > >>> > meeting the requirements of an enhanced TLS mechanism, a password > >>> > based authentication mechanism, and additional inner authentication > >>> > mechanisms. > >>> > > >>> > - Enable a TLS-based EAP method to support channel > >>> bindings. This item > >>> > will not generate a new method, rather it will extend > >>> EAP-TLS and/or > >>> > the above tunnel method. > >>> > > >>> > - A mechanism that makes use of existing password databases such as > >>> > AAA databases. This item will be based on the above tunnel method. > >>> > > >>> > Goals and Milestones: > >>> > Done Form design team to work on strong shared secret > >>> > mechanism > >>> > Done Submit 2716bis I-D > >>> > Done Submit first draft of shared secret > >>> mechanism I-D > >>> > Done Form password based mechanism design team > >>> > Done Submit 2716bis draft to IESG for > >>> Proposed Standard > >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG > >>> > May 2008 Submit Tunnel and Password Method requirements first > >>> > Draft > >>> > Sep 2008 Submit EAP Channel Bindings First Draft > >>> > Sep 2008 Submit Tunnel Method first draft > >>> > Oct 2008 Submit TLS based method channel binding first draft > >>> > Oct 2008 Submit Password Method first draft > >>> > Jan 2009 Send EAP Channel Bindings to IESG > >>> > Mar 2009 Send Tunnel Method to IESG > >>> > Apr 2009 Send TLS based method channel binding to IESG > >>> > Apr 2009 Send Password based method to IESG > >>> > _______________________________________________ > >>> > Emu mailing list > >>> > Emu@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/emu > >>> > > >>> > >>> > >>> > >> > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
