Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer.
regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: > 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-eaptunnel-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
