[SECMECH] Draft EMU working group charter

"Salowey, Joe" <jsalowey@cisco.com> Tue, 06 December 2005 22:41 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 1EjlVD-00031B-Kz; Tue, 06 Dec 2005 17:41:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlVC-00030Q-1z for secmech@megatron.ietf.org; Tue, 06 Dec 2005 17:41:38 -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 RAA01710 for <secmech@ietf.org>; Tue, 6 Dec 2005 17:40:47 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejlql-0004PK-9X for secmech@ietf.org; Tue, 06 Dec 2005 18:03:56 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 06 Dec 2005 14:41:27 -0800
X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208"; a="374840650:sNHT31995552"
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB6MfP9k015011 for <secmech@ietf.org>; Tue, 6 Dec 2005 14:41:26 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 06 Dec 2005 14:47:21 -0800
Message-ID: <7210B31550AC934A8637D6619739CE69065487A5@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: Draft EMU working group charter
Thread-Index: AcX6ti/dNnFN/6izQWS/xKEYI9S4xg==
From: "Salowey, Joe" <jsalowey@cisco.com>
To: secmech@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: quoted-printable
Cc:
Subject: [SECMECH] Draft EMU working group charter
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

Here is a draft EMU working group charter, the milestones may still need
some work:

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 for RFC 2716 to allow EAP-TLS to support TLS
authentication modes beyond certificates, channel bindings, and other
optional functions required in RFC 4017. Depending on technical analysis
and interoperability considerations, this may either be possible as a
part of the above update of RFC 2716, or it may have to be done as a
separate document that has 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.   

February 2006 - form design team to work on strong shared secret
mechanism
March 2006 - Submit revised EAP-TLS draft 
April 2006 - form password based mechanism design team
August 2006 - Update to EAP-TLS submitted to IESG
August 2006 - Submit strong shared secret mechanisms to the IESG
August 2006 - Select approach to Password based Mechanism
December 2006 - Strong Shared Secret mechanism submitted to IESG
December 2006 - Submit password based method draft
August 2007 - Password Based Mechanism submitted to IESG 

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