Dan, Great, we are not back to lets get those requirements done. It's the gate to the next steps.
Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 > -----Original Message----- > From: Dan Harkins [mailto:[EMAIL PROTECTED] > Sent: Monday, April 28, 2008 3:22 PM > To: Gene Chang (genchang) > Cc: Dan Harkins; Stephen Hanna; emu@ietf.org > Subject: RE: [Emu] EMU charter revision > > > Gene, > > I don't think anyone would find an EMU reality show entertaining. The > only comic relief would be one crazy guy who, once every 4 months, pokes > his head in the window and says "I do not approve" to people sitting > around watching paint dry. > > You are restating Stephen's comment from Philly that I'm more > interested in the cage match than in the coronation of the winner. > That is not true but it is also irrelevant. I actually don't care > who wins or how much blood is let, I just want it to be over. > > It would really be an abuse of process to hold up all other work while > each side crunches numbers and pays analysts to run surveys so that > someone can claim to have reached an arbitrary 10M mark. And it would not > be a service to anybody. > > So what we have is argument over the wording of "requirements" so > that they will subtly favor one side over the other. Then we create a > "requirements" document that captures all the carefully constructed > verbage. And while that's getting advanced we then argue over which > candidate best matches the customized wording of the "requirements". And > then we finally get down to the work of actually changing one of the > specifications to add channel binding. And this must all be done > serially. Sigh. > > Both FAST and TTLS are equally amenable to modification and their > differences are not so great or we'd have had a clear "winner" already. > No matter which one gets selected we will not end up with a weak solution. > > You don't see my sense of urgency because what you view as interesting > work is not being held up. > > Dan. > > On Mon, April 28, 2008 11:26 am, Gene Chang (genchang) wrote: > > Dan, > > > > I think we can all appreciate the entertainment value of bringing a > > reality show to the IETF. Imagine replacing the IETF social with an > > arena full of hyped up Internet engineers enjoying a night fellowship > > with beer and trash talk. > > > > Unfortunately, all we are doing is dressing up a down select with two > > 4-5 year old protocols that do not completely meet the requirements > > document that is being assembled. We aren't doing the industry a favor > > freezing the protocol choice to technology ca. 2004. > > > > If you are in such a rush, why not simply declare victory and have a > > tie. That enshrines the status quo. Picking one over the other won't > > change the status quo and thus won't change the deployment preference > > already established. > > > > Better for the industry would be a foot race where the candidate > > protocol that meets the requirements document and gains 10 million > > devices protected would win the standards title. This would advance the > > technology to cover the missing requirements and significantly grow > > adoption. > > > > Let's focus our efforts on moving the technology forward instead > > searching for an entertaining down select. > > > > I really don't see your sense of urgency. I don't see an adoption window > > that we are going to miss with the current effort. Yet, I can be really > > excited pushing to meet the needs of a critical adoption window. > > > > I would like to see things progress faster but not at the expense of a > > weak technical outcome. > > > > Gene > > > > ------------------------------------------------------------------------ > > ---- > > Eugene Chang (genchang) > > Cisco Systems > > Office: 603-559-2978 > > Mobile: 781-799-0233 > > Skype: gene02421 > > > > > > > >> -----Original Message----- > >> From: Dan Harkins [mailto:[EMAIL PROTECTED] > >> Sent: Monday, April 28, 2008 12:05 PM > >> To: Gene Chang (genchang) > >> Cc: Dan Harkins; Stephen Hanna; emu@ietf.org > >> Subject: RE: [Emu] EMU charter revision > >> > >> > >> 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
