Hi Gene, I'm not pushing a tunneled method. We have enough of those and their differences are not so great.
Yes, I was using "snail race" as a pejorative. As I said at the last IETF we should have a cage-match-cum-beauty-contest between TTLS and FAST, turn the last RFC text of the winner into a -00 EMU draft, add the channel bindings stuff that was discussed back in Vancouver and then publish. Apparently this working group can work on nothing except a tunneled method. And that work is being done at a snail's pace. I'm glad to hear that you're open to a discussion of adding a non- tunneled method "if there is sufficient demand", but you see we have this long-standing consensus and the mere mention of anything that remotely sounds like a non-tunneled method gets stifled with "consensus!" So apparently we're not allowed to have that discussion. At least until we finish work on a tunneled method. Dan. On Mon, April 28, 2008 3:35 am, Gene Chang (genchang) wrote: > 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
