Joe: I approve the current charter revision and am willing to contribute to the tunnel method.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Tuesday, February 19, 2008 2:15 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > The response to the charter revision has been underwhelming. > I am a bit concerned that we do not have enough participation > to complete the tunnel method work (most of the recent > discussion has been about other methods). > > I would like to get an idea of the number working group > members that approve of working on the tunnel method items > and are able to participate in the development of > requirements and specifications as contributors and/or reviewers. > > Please respond to this message and state whether you approve > of the current charter revision and what capacity you would > be willing to contribute towards tunneled method development: > contributor, reviewer or not able to contribute. > > I have submitted an internet draft attempt at an outline of > requirements for tunneled methods > (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunn > el-req-00. > txt) that I hope can provided a starting point for > discussions on the list and in the Philadelphia meeting. > > Thanks, > > Joe > > > -----Original Message----- > > From: Joseph Salowey (jsalowey) > > Sent: Monday, February 04, 2008 9:13 PM > > To: emu@ietf.org > > Subject: EMU charter revision > > > > Below is a revised charter update based on the discussion > on the list. > > I have left the password based method item as a tunnel > method because > > this represents the consensus the working group has > reached. I also > > believe the working group will have to focus on the tunnel method > > related items for the near term to make progress. This > does not mean > > that we cannot work on additional methods as working group items in > > the future. > > > > Please review the charter update and post any issues you > have with the > > carter. Please also indicate if you have reviewed the proposed > > charter and have no issues. It is difficult to judge working group > > consensus unless there are sufficient responses. > > > > Thanks, > > > > 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 and only a few methods are documented > in RFCs. The > > lack of documented, open specifications is a deployment and > > interoperability problem. In addition, none of the EAP > methods in the > > standards track implement features such as key derivation that are > > required for many modern applications. This poses a problem > for, among > > other things, the selection of a mandatory to implement EAP > method in > > new network access technologies. For example, no standards track > > methods meet new requirements such as those posed in RFC > 4017, which > > documents IEEE 802.11 requirements for EAP methods. > > > > This group is chartered to work on the following types of > mechanisms > > to meet RFC 3748 and RFC 4017 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 that meets RFC > > 3748 and RFC 4017 requirements. This mechanism should strive to be > > simple and compact for implementation in resource constrained > > environments. > > > > - A mechanism to support extensible communication within a TLS > > protected tunnel that meets RFC 3748 and RFC 4017 > requirements. This > > mechanism must support channel bindings in order to meet RFC 4962 > > requirements and it must provide cryptographic algorithm > agility. 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. > > So as to enable RFC 2716bis to focus solely on > clarifications to the > > existing protocol, this effort will be handled in a > separate document. > > This item will not generate a new method, rather it will enhance > > EAP-TLS or the TLS based tunnel method work item. > > > > - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes > > use of existing password databases such as AAA databases. > This item > > will be based on the tunnel method work item. > > > > 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 > > Done Submit Strong Shared Secret Mechanism to IESG > > Apr 2008 Submit Tunnel and Password Method requirements > > first draft > > Jul 2008 Send Tunnel and Password Method requirements to IESG > > Oct 2008 Submit Tunnel Method first draft > > Nov 2008 Submit TLS based method channel binding first draft > > Nov 2008 Submit Password Method first draft > > Feb 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 > http://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org http://www.ietf.org/mailman/listinfo/emu
