Thanks Steve, I think "Tunnel Method" might be the best term. Adding a deliverable for a requirements draft is a good suggestion we can discuss.
Cheers, Joe > -----Original Message----- > From: Stephen Hanna [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 28, 2007 3:28 AM > To: Joseph Salowey (jsalowey); [email protected] > Subject: RE: [Emu] EMU charter update for tunneled method > > 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
