Subject: RE: [Emu] EMU charter update for tunneled method

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 3 Dec 2007 16:39:54 -0800

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-masked]] 
> Sent: Wednesday, November 28, 2007 3:28 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> 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-masked]]
> Sent: Monday, November 19, 2007 3:35 PM
> To: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu