[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 ([127.0.0.1] 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 ([132.151.1.176] 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 [132.151.6.1]) 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 ([193.234.218.130]) 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 [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 46336898A6; Sat, 21 Jan 2006 08:30:34 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) 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
Cc:
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.

--Jari

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
>
>Chairs:
>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.
>
>Milestones:
>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
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
>  
>


_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech