WG Review: EAP Method Update (emu)

The IESG <iesg-secretary@ietf.org> Wed, 21 December 2005 13:30 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 1Ep42a-0006As-QF; Wed, 21 Dec 2005 08:30:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep42X-00069N-2x; Wed, 21 Dec 2005 08:29:57 -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 IAA11178; Wed, 21 Dec 2005 08:28:53 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep45A-0004Jl-AU; Wed, 21 Dec 2005 08:32:40 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Ep42T-0007jW-5w; Wed, 21 Dec 2005 08:29:53 -0500
Content-Type: text/plain
Mime-Version: 1.0
To: IETF-Announce@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1Ep42T-0007jW-5w@newodin.ietf.org>
Date: Wed, 21 Dec 2005 08:29:53 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc:
Subject: WG Review: EAP Method Update (emu)
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org

A new IETF working group has been proposed in the Security Area.  
The IESG has not made any determination as yet. The following draft charter was
submitted, and is provided for informational purposes only.  
Please send your comments to the IESG mailing list (iesg@ietf.org) by December
28.

+++

EAP Method Update (emu)
========================

Current Status: Proposed Working Group

Chairs:
TBD

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 List: 
TBD

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