Re: [Emu] EMU charter revision

["Hao Zhou (hzhou)" <hzhou at cisco.com>]

Joe:

I approve the current charter revision and am willing to contribute to
the tunnel method. 

> -----Original Message-----
> From: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On 
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Tuesday, February 19, 2008 2:15 PM
> To: Joseph Salowey (jsalowey); emu at 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 at 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 at ietf.org
> http://www.ietf.org/mailman/listinfo/emu
> 
_______________________________________________
Emu mailing list
Emu at ietf.org
http://www.ietf.org/mailman/listinfo/emu