[secdir] [new-work] WG Review: EAP Method Update (emu)

The IESG <iesg@ietf.org> Fri, 01 November 2019 16:22 UTC

Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E598120A70; Fri, 1 Nov 2019 09:22:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1572625366; bh=cevAp+dIUnwL7SwqHwkD0a+ZdgwrBdSnluoATCAISO4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=xNj/drGBDPzNYsu/ifGvUpWOlI42iRoWgoY+YPNiH6I3ClpjwXyQ+rRHhuJYLwwAa EwLVQFovKFoH1u45wfLTCIWTmjnT9DlB2w/L8NThtnpn7ILEWhrv0VOByu2pZ8zXzS x8zIxmproELI7hX124IAVRHJ9eZl6zP1DNrZ7RVE=
X-Mailbox-Line: From new-work-bounces@ietf.org Fri Nov 1 09:22:41 2019
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DEF1209FE; Fri, 1 Nov 2019 09:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1572625360; bh=cevAp+dIUnwL7SwqHwkD0a+ZdgwrBdSnluoATCAISO4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=wR327wfoFQvIhASNQWXLazFR4kqUcwOa7tkENWqLh+cpZbwJiiRHTJwwscfJOw8kE WqeeckMTvfW4/60i2kkAgLZSu56uKletUM7k2Jh8GUIZzvOv3oZATYnwneLuJAN7o9 HyonMGhQ6DM5q4STn7eVYwIwNll2snPzNEMgiQs4=
X-Original-To: new-work@ietf.org
Delivered-To: new-work@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0E120A59 for <new-work@ietf.org>; Fri, 1 Nov 2019 09:22:27 -0700 (PDT)
MIME-Version: 1.0
From: The IESG <iesg@ietf.org>
To: new-work@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply_to: <iesg@ietf.org>
MIME-Version: 1.0
Message-ID: <157262534738.31915.12306452498342992134.idtracker@ietfa.amsl.com>
Date: Fri, 01 Nov 2019 09:22:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/new-work/VwmdZtUxW_VgQnzY6sFL-EgfGuU>
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.29
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: new-work-bounces@ietf.org
Sender: new-work <new-work-bounces@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/6JDnc-1dnlZx9YuW1betcu2LTO0>
X-Mailman-Approved-At: Fri, 01 Nov 2019 09:38:28 -0700
Subject: [secdir] [new-work] WG Review: EAP Method Update (emu)
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2019 16:22:53 -0000

The EAP Method Update (emu) WG in the Security Area of the IETF is undergoing
rechartering. The IESG has not made any determination 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
2019-11-11.

EAP Method Update (emu)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Joseph Salowey <joe@salowey.net>
  Mohit Sethi <mohit.m.sethi@ericsson.com>

Assigned Area Director:
  Roman Danyliw <rdd@cert.org>

Security Area Directors:
  Benjamin Kaduk <kaduk@mit.edu>
  Roman Danyliw <rdd@cert.org>

Mailing list:
  Address: emu@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/emu
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu

Group page: https://datatracker.ietf.org/group/emu/

Charter: https://datatracker.ietf.org/doc/charter-ietf-emu/

The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access
authentication framework used, for instance, in VPN and mobile networks.
EAP itself is a simple protocol and actual authentication happens in EAP
methods. Several EAP methods have been developed at the IETF and
support for EAP exists in a broad set of devices. Previous larger EAP-related
efforts at the IETF included rewriting the base EAP protocol specification and
the development of several standards track EAP methods.

EAP methods are generally based on existing security technologies such as
Transport Layer Security (TLS) and mobile network Authentication and Key
Agreement (AKA). Our understanding of security threats is continuously
evolving. This has driven the evolution of several of these underlying
technologies. As an example, IETF has standardized a new and improved
version of TLS (v1.3) in RFC 8446. The group will therefore provide guidance
and update EAP method specifications where necessary to enable the use of
new versions of these underlying technologies.

At the same time, some new use cases for EAP have been identified. EAP is
now more broadly used in mobile network authentication. The group will
update existing EAP methods such as EAP-AKA' to stay in sync with updates
to the referenced 3GPP specifications. RFC 7258 notes that pervasive
monitoring is an attack. Perfect Forward Secrecy (PFS) is an important
security property for modern protocols to thwart pervasive monitoring. The
group will work on an extension to EAP-AKA' for providing PFS.

Out-of-band (OOB) refers to a separate communication channel
independent of the primary in-band channel over which the actual network
communication takes place. OOB channels are now used for authentication
in a variety of protocols and devices (draft-ietf-oauth-device-flow-13,
WhatsApp Web, etc.). Many users are accustomed to tapping NFC or
scanning QR codes. However, EAP currently does not have any standard
methods that support authentication based on OOB channels. The group
will therefore work on an EAP method where authentication is based on an
out-of-band channel between the peer and the server.

EAP authentication is based on credentials available on the peer and the
server. However, some EAP methods use credentials that are time or domain
limited (such as EAP-POTP), and there may be a need for creating long term
credentials for re-authenticating the peer in a more general context. The
group will investigate minimal mechanisms with which limited-use EAP
authentication credentials can be used for creating general-use long-term
credentials.

In summary, the working group shall produce the following documents:

        * An update to enable the use of TLS 1.3 in the context of EAP-TLS
(RFC 5216). This document will update the security considerations relating to
EAP-TLS, document the implications of using new vs. old TLS versions. It will
add any recently gained new knowledge on vulnerabilities and discuss the
possible implications of pervasive surveillance.

        * Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS
tunnel. Provide guidance or update the relevant specifications explaining
how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will
also involve maintenance work based on errata found in published
specifications (such as EAP-TEAP).

        * Define session identifiers for fast re-authentication for EAP-SIM,
EAP-AKA, EAP-PEAP and EAP-AKA’. The lack of this definition is a recently
discovered bug in the original RFCs.

        * Update the EAP-AKA' specification (RFC 5448) to ensure that its
capability to provide a cryptographic binding to network context stays in
sync with updates to the referenced 3GPP specifications. The document will
also contain any recently gained new knowledge on vulnerabilities or the
possible implications of pervasive surveillance.

        * Develop an extension to EAP-AKA' such that Perfect Forward
Secrecy can be provided. There may also be privacy improvements that have
become feasible with the  introduction of recent identity privacy
improvements in 3GPP networks.

        * Gather experience regarding the use of large certificates and long
certificate chains in the context of TLS based EAP methods, as some
implementations and access networks may limit the number of EAP packet
exchanges that can be handled. Document operational recommendations or
other mitigation strategies to avoid issues.

        * Define a standard EAP method for mutual authentication between
a peer and a server that is based on an out-of-band channel. The method
itself should be independent of the underlying OOB channel and shall
support a variety of OOB channels such as NFC, dynamically generated QR
codes, audio, and visible light.

        * Define mechanisms by which EAP methods can support creation of
long-term credentials for the peer based on initial limited-use credentials.

The working group is expected to stay in close collaboration with the EAP
deployment community, the TLS working group (for work on TLS based EAP
methods), and the 3GPP security architecture group (for EAP-AKA' work).

Milestones:

  Nov 2019 - WG last call on operational recommendations for large
  certificate and chain sizes

  Nov 2019 - WG last call on definition of session identifiers for fast re-
  authentication in EAP-SIM and EAP-AKA

  Nov 2019 - WG adopts initial draft addressing the errata found in EAP-TEAP

  Nov 2019 - WG adopts initial draft on an EAP method for mutual
  authentication based on an OOB channel

  Nov 2019 - WG adopts draft providing guidance for use of TLS 1.3 with TLS
  based EAP methods

  Jan 2020 - WG adopts initial draft on creation of long-term credentials for
  EAP peer based on initial limited-use credentials

  Mar 2020 - WG last call on extension to EAP-AKA to support forward secrecy


_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work