Joe, I do not approve of the charter revision; the charter should not prohibit the group from using a non-tunneled method for the password-based method. My previous mail gave a suggested charter text change.
I can participate as a reviewer. Thanks, Dorothy Stanley On Tue, Feb 19, 2008 at 11:14 AM, Joseph Salowey (jsalowey) < [EMAIL PROTECTED]> 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<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
