Subject: [Emu] EMU charter update for tunneled method

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 19 Nov 2007 12:34:48 -0800

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

---

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 28 Nov 2007 06:28:26 -0500

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

------------------

Goals and Milestones: