Oops... a key typo in the earlier version...
Dan, Great, we are now back to let's 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gene > Chang (genchang) > Sent: Monday, April 28, 2008 3:44 PM > To: Dan Harkins > Cc: emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
