[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
- [SECMECH] Draft EMU working group charter Salowey, Joe
- Re: [SECMECH] Draft EMU working group charter T. Charles Clancy
- RE: [SECMECH] Draft EMU working group charter Salowey, Joe