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
