Re: [SECMECH] Second secmech bof

Jari Arkko <jari.arkko@piuha.net> Mon, 03 October 2005 16:02 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSlz-0005cY-TJ; Mon, 03 Oct 2005 12:02:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSlx-0005by-Tr; Mon, 03 Oct 2005 12:02:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14866; Mon, 3 Oct 2005 12:02:35 -0400 (EDT)
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMSuS-000497-Gg; Mon, 03 Oct 2005 12:11:25 -0400
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 67AC089870; Mon, 3 Oct 2005 19:02:27 +0300 (EEST)
Message-ID: <4341561F.4090201@piuha.net>
Date: Mon, 03 Oct 2005 19:02:39 +0300
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: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [SECMECH] Second secmech bof
References: <tslu0g233mv.fsf@cz.mit.edu>
In-Reply-To: <tslu0g233mv.fsf@cz.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121
Content-Transfer-Encoding: 7bit
Cc: secmech@ietf.org, iesg@ietf.org
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

This is the planned second BoF agenda.

EAP METHODS UPDATE (EMU) BOF

CHAIRS: Jari Arkko (jari.arkko@piuha.net)
        Joe Salowey (jsalowey@cisco.com)

MAILING LIST: (Being set up.)

DESCRIPTION:

The Extensible Authentication Protocol (EAP), defined in 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 so called EAP methods.

Over 40 different EAP methods exists. This includes many
undocumented and proprietary methods. Only a few methods are
documented in RFCs, and out of these, methods listed in the
original EAP RFC are no longer applicable in today's
environments. For instance, none of the EAP methods that are
applicable in a wireless environment are in Standards Track
RFCs. This poses a problem for, among other things, the
selection of a mandatory to implement EAP method in new
network access technologies.

Some methods have been defined in Internet Drafts, many of
which have expired or have not been updated to reflect the
true behavior in the protocols.

The lack of documented, open specifications is a deployment
and interoperability problem. In addition, new requirements
such as those posed by wireless environments are creating
needs that are currently not well matched by existing
methods. For instance, RFC 4017 documents IEEE 802.11
requirements for EAP methods. Currently, there are only a
few EAP methods that satisfy the mandatory requirements
listed in this document, and there are no methods that
satisfy all requirements. Some proposals for such methods
exist, however.

Finally, there are authentication mechanism types that are
not supported by existing RFCs. For instance, there is no
widely applicable method that would be able to authenticate
using shared secrets in a wireless environment.

The purpose of this BoF is to continue the work started in
the EAP WG and in the SECMECH BOF, in a manner focused on
few key EAP method needs. One immediate goals is to bring
existing widely deployed EAP methods such as EAP-TLS (RFC
2716) to Proposed Standards with clarifications learned
during deployment. Another goal is to standardize additional
mechanism to match the current requirements.

The BoF should have an organized discussion of what specific
needs the community sees as worthwhile pursuing, and to
discuss the specific technical solutions.

The potential work items of the group include

1. Revision of EAP-TLS, to be placed on the standards track.
   The primary goal of this would be to bring the specification
   up to date, clarify unclear issues, etc. A standards
   track specification would also enable the consideration
   of EAP-TLS as a mandatory requirement in other Proposed
   Standard specifications.

   Note that there are limitations in current
   implementations which may need to be considered during
   this update. Similarly, the existing EAP-TLS
   specification may not accommodate all types of extensions
   in a backwards compatible manner. For instance, there may
   be issues in adding channel binding support or the use of
   new TLS mechanisms such as TLS PSK when run against RFC
   2716 compliant devices. These issues shall be
   investigated and clarified; the revised EAP-TLS must be
   backwards compatible with existing deployment.

2. Shared Secret - a pre-shared secret method. This is
   likely to be widely deployed if available, and another
   likely candidate to be referred to by other Proposed
   Standard specifications. Desired by IEEE 802.11.

3. Password based - essentially a shared secret mechanism
   that provides resistance to dictionary attacks. It should
   support various backend databases of password that use
   different storage techniques and perhaps support for one
   time tokens as well. Could use something related to EKE or
   a tunneling approach. Desired by IEEE 802.11, and would
   likely be widely deployed if available.

4. One time passwords - a secure one-time password -based
   mechanism that can provide keying material.

5. Tunneling - a tunneling method is useful to protect
   weaker authentication mechanisms.  Tunneling methods are
   also used to exchange other types of authentication data.

6. Channel binding support - it has been suggested that new
   methods should have an ability to authenticate identifiers
   claimed by NASes. But it has also been suggested that
   backwards compatible extensions to do this in a few commonly
   used current methods should be developed for security
   reasons.

   Similarly, for the ability to retain EAP method and media
   indepedence, it may be necessary to have coordinated
   approach or even binding data formats between different
   methods.

7. Enrollment mechanisms - methods to automatically enroll
   clients in wireless environments.

However, this list should not be taken as a proposal but
rather as a template that can be used to determine community
consensus on which of the items are worthwhile. It is
certainly impossible to take on ALL of the above tasks, so a
set of 3-4 priority tasks needs to be determined. There may
also be IPR, complexity, or existing deployment concerns
that make it undesirable to take on work for a specific
item.

Although the GUAM work is not a subject of the current BOF,
the group's charter may later be extended to cover GUAM work
discussed in the SECMECH BOF in IETF-63. This requires an
explicit rechartering, however.

The creation of this group does not affect existing
procedures for IANA allocation of EAP method type numbers,
or the publication of individual submissions documenting EAP
methods as RFCs.

AGENDA:

 o  Background and relation to past SECMECH BOF and EAP WG
    work (Sam Hartman, 5 min)

 o  EAP methods market situation (chairs, 5 min)

 o  EAP methods technical requirements (tbd, 10 min)

 o  Security AD's requirements for new methods (Russ Housley, 10 min)

 o  EAP methods, SDO requirements (Aboba, 10 min)

 o  EAP TLS issues and limitations (Aboba, 15 min)

 o  Shared secret methods (tbd, 15 min)

 o  Overview of other proposed methods (Eronen, 15 min)

 o  Channel binding approaches (Eronen, 15 min)

 o  Proposed charter (chairs, 15 min)

 o  Discussion (40 min)

READING LIST:

   RFC 3748. Extensible Authentication Protocol
   (EAP). B. Aboba, L. Blunk, J.  Vollbrecht, J. Carlson,
   H. Levkowetz, Ed.. June 2004.

   RFC 2716, PPP EAP TLS Authentication Protocol. B. Aboba,
   D. Simon. October 1999.

   RFC 4017. Extensible Authentication Protocol (EAP) Method
   Requirements for Wireless LANs. D. Stanley, J. Walker,
   B. Aboba. March 2005.

   "EAP IKEv2 Method (EAP-IKEv2)", Hannes Tschofenig,
   20-Jul-05, <draft-tschofenig-eap-ikev2-07.txt>

   "The EAP-PSK Protocol: a Pre-Shared Key EAP Method",
   Hannes Tschofenig, Florent Bersani, 10-Aug-05,
   <draft-bersani-eap-psk-09.txt>

   "EAP Flexible Authentication via Secure Tunneling
   (EAP-FAST)", Joseph Salowey, 25-Apr-05,
   <draft-cam-winget-eap-fast-02.txt>

   "EAP Password Authenticated Exchange", Charles Clancy,
   William Arbaugh, 6-Jun-05, <draft-clancy-eap-pax-04.txt>

   "The EAP-SKL protocol", Thomas Otto, 1-Aug-05,
   <draft-otto-eap-skl-02.txt>

   "The Protected One-Time Password Protocol (EAP-POTP)",
   Magnus Nystrom, 5-Jul-05, <draft-nystrom-eap-potp-02.txt>

   "Dynamic Provisioning using EAP-FAST", Nancy Cam-Winget,
   19-Jul-05,
   <draft-cam-winget-eap-fast-provisioning-01.txt>

   "Authenticated Service Information for the Extensible
   Authentication Protocol (EAP)", Jari Arkko, Pasi Eronen,
   20-Jul-05, <draft-arkko-eap-service-identity-auth-03.txt>

   "An Extensible Authentication Protocol (EAP) Enrollment
   Method", Rohan Mahy, 13-Jul-05,
   <draft-mahy-eap-enrollment-00.txt>

   "AAA-Key Derivation with Lower-Layer Parameter Binding",
   Mayumi Yanagiya, Yoshihiro Ohba, 1-Jul-05,
   <draft-ohba-eap-aaakey-binding-01.txt>


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