EAP Method Update (emu)

Last Modified: 2008-07-02

Additional information is available at tools.ietf.org/wg/emu

Chair(s):

  • Joseph Salowey <jsalowey@cisco.com>

  • Alan DeKok <aland@deployingradius.com>

  • Alan DeKok <aland@freeradius.org>

    Security Area Director(s):

  • Tim Polk <tim.polk@nist.gov>
  • Pasi Eronen <pasi.eronen@nokia.com>

    Security Area Advisor:

  • Pasi Eronen <pasi.eronen@nokia.com>

    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 these methods are
    proprietary methods, but some are documented in informational RFCs. In
    the past the lack of documented, open specifications has been a
    deployment and interoperability problem. There are currently only two
    EAP methods in the standards track that implement features such as key
    derivation that are required for many modern applications.
    Authentication types and credentials continue to evolve as do
    requirements for EAP methods.

    This group is chartered to work on the following types of mechanisms
    to meet requirements relevant to EAP methods in RFC 3748, RFC 4017,
    RFC 4962 and EAP Keying:

    - A mechanism based on strong shared secrets. This mechanism should
    strive to be simple and compact for implementation in resource
    constrained environments.

    - A document that defines EAP channel bindings and provides guidance
    for establishing EAP channel bindings within EAP methods.

    - Enable TLS-based EAP methods to support channel bindings. This item
    will not generate a new method; rather, it will focus on adding
    support for EAP channel bindings to the tunneled method (described
    below), and if possible, other TLS-based EAP methods. Potential
    mechanisms for adding channel binding support will be investigated,
    including tunneling of channel binding parameters, or a TLS extension,
    or other standard TLS mechanism

    - A mechanism to support extensible communication within a TLS
    protected tunnel. This mechanism will support meeting the requirements
    of an enhanced TLS mechanism, a password based authentication
    mechanism, and additional inner authentication mechanisms. It will
    also support channel bindings (as described above) in order to meet
    RFC 4962 requirements.

    - A mechanism that makes use of existing password databases such as AAA
    databases. This item will be based on the above tunnel method.

    Goals and Milestones:

    Done  Form design team to work on strong shared secret mechanism
    Done  Submit 2716bis I-D
    Jun 2006  Submit first draft of enhanced EAP-TLS I-D
    Done  Submit first draft of shared secret mechanism I-D
    Done  Form password based mechanism design team
    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
    Jun 2008  Submit Tunnel and Password Method requirements first Draft
    Sep 2008  Submit EAP Channel Bindings First Draft
    Sep 2008  Submit Tunnel Method first draft
    Oct 2008  Submit TLS based method channel binding first draft
    Oct 2008  Submit Password Method first draft
    Jan 2009  Send EAP Channel Bindings to IESG
    Mar 2009  Send Tunnel Method to IESG
    Apr 2009  Send TLS based method channel binding to IESG
    Apr 2009  Send Password based method to IESG

    Internet-Drafts:

    EAP Generalized Pre-Shared Key (EAP-GPSK) Method (81772 bytes)
    Requirements for an Tunnel Based EAP Method (53128 bytes)

    Request For Comments:

    The EAP TLS Authentication Protocol (RFC 5216) (71599 bytes) obsoletes RFC 2716
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.