Here is my feedback on this proposed charter update. 1) RFC 3748 and RFC 4017 requirements should apply to all deliverables. The proposed language omits them from the tunneled method deliverable. Please add them to that deliverable.
2) Some of the new milestones are not clear. The main problem is that there's no verb. For example, what does "Tunnel Method requirements" mean? It should say "Agree on Tunnel Method requirements" or some such. 3) I think that we should have an Internet Draft on "Tunnel Method requirements" that goes through the normal approval process to achieve IETF consensus and become an RFC. Agreeing on a Tunnel Method is a major effort (and quite valuable). We should have IETF consensus on the requirements before we start. Publishing the requirements as an Internet Draft will also make it easier for other standards groups to comments, which is probably a good idea in this instance. 4) The terms "tunneled" and "tunnel" are used interchangably. We should choose one or the other and stick to it. I think the term "tunneled" is more common for this usage so I suggest that we use that term. 5) In the second paragraph, the "this methods" should be "these methods". I appreciate your work on drafting this proposed charter update. It's a good start. I'm glad that we're getting some discussion of it and look forward to more discussion on the email list and in Vancouver. Thanks, Steve -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Monday, November 19, 2007 3:35 PM To: [email protected] Subject: [Emu] EMU charter update for tunneled method Below is a proposed update to the EMU charter to add a tunneled method. The following are the changes to the existing charter: - add charter item for tunneled EAP method - modified password based item to make use of the above tunneled method - modify "enhanced TLS" item to focus on adding channel bindings to a TLS based mechanism - updated milestones ------------------ 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 this 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 to support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and to support additional inner authentication mechanisms. - Enhanced functionality to 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 should not generate a new method rather it should be based on existing EAP-TLS or a TLS based tunneled method. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments. This item will make use of the above tunneled method. 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 (July 2007) Submit 2716bis draft to IESG for Proposed Standard Dec 2007 Submit Strong Shared Secret Mechanism to IESG Dec 2007 Tunnel Method requirements Mar 2008 Tunnel Method first draft submitted May 2008 Submit Password method extensions to tunnel method June 2008 Submit Extended TLS method extensions to tunnel method Nov 2008 Submit Tunnel Method to IESG Nov 2008 Submit Enhanced EAP-TLS to IESG Nov 2008 Submit Password based method to IESG _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
