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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Joseph Salowey (jsalowey)
Sent: Tuesday, February 19, 2008 2:15 PM
To: Joseph Salowey (jsalowey); emu@ietf.org
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
(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: emu@ietf.org
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
