Subject: Re: [Emu] EMU charter revision

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 19 Feb 2008 11:14:42 -0800

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: [email-masked]
> 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
[email-masked]
http://www.ietf.org/mailman/listinfo/emu

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Tue, 19 Feb 2008 14:42:45 -0500

Joe:

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Tuesday, February 19, 2008 2:15 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> 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 
> txt) that I hope can provided a starting point for 
> discussions on the list and in the Philadelphia meeting.  
> 
> Thanks,
> 
> Joe
> 
> > 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
> > 
> > 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 
> 4017, which 
> > documents IEEE 802.11 requirements for EAP methods.
> > 
> mechanisms 
> > to meet RFC 3748 and RFC 4017 requirements:
> > 
> 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.
> > 
> > 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.
> > 
> > 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:

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Feb 2008 22:53:01 +0100

> contribute towards tunneled method development: contributor, reviewer or

  I approve of the charter revision, and can contribute to the tunneled
method development as a reviewer, possibly as a contributor.

  Alan DeKok.

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 19 Feb 2008 19:50:59 -0500

I approve of the current charter revision and would be willing to
contribute towards tunneled method development as a contributor.

Thanks,

Steve Hanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joseph Salowey (jsalowey)
Sent: Tuesday, February 19, 2008 2:15 PM
To: Joseph Salowey (jsalowey); [email-masked]
Subject: Re: [Emu] EMU charter revision

Thanks,

Joe

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 19 Feb 2008 19:56:08 -0800 (PST)

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.

---

From: "Dorothy Stanley" <[email-masked]>
Date: Fri, 22 Feb 2008 08:24:52 -0800

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-masked]> wrote:

> 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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sat, 23 Feb 2008 16:49:13 -0800

Hi Dorothy,

The current charter item is for a method that works with existing
password databases.  This requires the method to work with databases
where the EAP server does not have access to the cleartext password and
in some cases does not have access even to the transform of the password
(in these cases a comparison function is available).  I don't believe
the method proposed in
http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-00.txt
meets this requirement.

Can you clarify if you want to remove this requirement or if you want to
add a charter item for a "secure password only method" such as the on
proposed in the draft? 

Thanks,

Joe

> From: Dorothy Stanley [mailto:[email-masked]] 
> Sent: Friday, February 22, 2008 8:25 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> 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. 
> On Tue, Feb 19, 2008 at 11:14 AM, Joseph Salowey (jsalowey) 
> <[email-masked]> wrote:
> 
> 
> members that
> 	txt 
> <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