[SECMECH] FW: WG Action: EAP Method Update (emu)

Jari Arkko <jari.arkko@piuha.net> Sat, 21 January 2006 06:35 UTC

Received: from localhost.cnri.reston.va.us ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0CLn-0002OR-FV; Sat, 21 Jan 2006 01:35:51 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0CLb-0002IC-18 for secmech@megatron.ietf.org; Sat, 21 Jan 2006 01:35:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05214 for <secmech@ietf.org>; Sat, 21 Jan 2006 01:34:09 -0500 (EST)
Received: from p130.piuha.net ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0CPs-0005hP-U0 for secmech@ietf.org; Sat, 21 Jan 2006 01:40:05 -0500
Received: from p130.piuha.net (localhost []) by p130.piuha.net (Postfix) with ESMTP id 46336898A6; Sat, 21 Jan 2006 08:30:34 +0200 (EET)
Received: from [] (p130.piuha.net []) by p130.piuha.net (Postfix) with ESMTP id B1A6A89852; Sat, 21 Jan 2006 08:30:33 +0200 (EET)
Message-ID: <43D1D526.7090101@piuha.net>
Date: Sat, 21 Jan 2006 08:31:02 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: eap@frascone.com, secmech@ietf.org
References: <E1F03fu-0002A9-1h@newodin.ietf.org>
In-Reply-To: <E1F03fu-0002A9-1h@newodin.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Content-Transfer-Encoding: 7bit
Subject: [SECMECH] FW: WG Action: EAP Method Update (emu)
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

The EMU WG has been created. There's a new list
(see below), please subscribe to it.


IESG Secretary wrote:

>A new IETF working group has been formed in the Security Area. For additional
>information, please contact the Area Directors or the WG Chairs.
>EAP Method Update (emu)
>Current Status: Active Working Group
>Jari Arkko <jari.arkko@piuha.net>
>Joe Salowey <jsalowey@cisco.com>
>Security Area Director(s):
>Russ Housley <housley@vigilsec.com>
>Sam Hartman <hartmans-ietf@mit.edu>
>Security Area Advisor:
>Sam Hartman <hartmans-ietf@mit.edu>
>Mailing Lists: 
>General Discussion: emu@ietf.org
>To Subscribe: https://www1.ietf.org/mailman/listinfo/emu
>Archive: http://www.ietf.org/mail-archive/web/emu/current/index.html
>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.
>- Enhanced functionality to enable a TLS-based EAP method to support
>authentication methods beyond certificates, channel bindings and other
>optional functions required in RFC 4017. So as to enable RFC 2716bis to
>focus solely on clarifications to the existing protocol, this effort
>will be handled in a separate document. Depending on an analysis of the
>behavior of existing implementations, it is possible that this effort
>may be able to use the existing EAP-TLS type code, or it may need to be
>handled via assignment of a new EAP Type Code.
>- 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 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.
>In order to facilitate the development of the shared secret and password
>based methods design teams will be formed. The design teams should take
>into consideration existing methods including mechanisms based on
>EAP-TLS such as TLS-PSK.
>Feb 2006 Form design team to work on strong shared secret mechanism
>Mar 2006 Submit 2716bis I-D
>Jun 2006 Submit first draft of enhanced EAP-TLS I-D
>Jul 2006 Form password based mechanism design team
>Jul 2006 Submit first draft of shared secret mechanism I-D
>Aug 2006 Submit 2716bis draft to IESG for Proposed Standard
>Nov 2006 Submit 2716bis draft to IESG for draft standard
>Dec 2006 Submit first draft password based method I-D
>Jan 2007 Submit Strong Shared Secret Mechanism to IESG
>Jan 2007 Submit enhanced EAP-TLS to IESG
>Aug 2007 Submit password Based Mechanism to IESG
>IETF-Announce mailing list

SECMECH mailing list