WG Review: EAP Method Update (emu)

[The IESG]

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 (i...@ietf.org) by
2019-11-11.

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

Chairs:
  Joseph Salowey 
  Mohit Sethi 

Assigned Area Director:
  Roman Danyliw 

Security Area Directors:
  Benjamin Kaduk 
  Roman Danyliw 

Mailing list:
  Address: e...@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.

WG Review: EAP Method Update (emu)

[The IESG]

A new IETF WG has been proposed in the Security Area. 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 (i...@ietf.org) by 2018-02-19.

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

Chairs:
  TBD

Assigned Area Director:
  Kathleen Moriarty 

Security Area Directors:
  Kathleen Moriarty 
  Eric Rescorla 

Mailing list:
  Address: e...@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 802.11 and VPN
networks and mobile networks. EAP itself is a simple
protocol and actual authentication happens in EAP methods.

Over 50 different EAP methods exist, including several methods
developed in the IETF, and support for EAP exists in a broad set
of different devices. Previous larger EAP-related efforts at the
IETF included rewriting the base EAP protocol documentation and
the development of several standards track EAP methods.

EAP methods are generally based on existing other security
technologies, such as TLS, SIM cards, and various algorithms.
Some of these technologies continue to evolve. And the
understanding of security threats in today's Internet evolves as
well, which has driven some of the evolution in these underlying
technologies. At the same time, some new use cases for EAP have
been identified, such as broader use of EAP in mobile network
authentication.

This working group has been chartered to provide updates to some
commonly used EAP method. Specifically, the working group shall
produce documents to:

   - Provide a guidance or update to enable the use of TLS 1.3 in the
 context of EAP TLS (RFC 5216). Update the security
 considerations relating to EAP TLS, to document the implications
 of using new vs. old TLS version, any recently gained new
 knowledge on vulnerabilities, and the possible implications of
 pervasive survellaince or other new concerns.

   - Update the EAP-AKA' specification (RFC 5448) to ensure that its
 capability to provide a cryptographic binding to network context
 stays in sync with what updates may come to the referenced 3GPP
 specifications through the use of EAP in 5G.

 Also, the group should document any recently gained new
 knowledge on vulnerabilities or the possible implications of
 pervasive surveillance or other new concerns.

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

   - 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 certificate and
 certificate chain sizes in the context of EAP-TLS (all versions),
 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.

In all of the above, it is a requirement that none of the updates
break backwards compatibility with existing specifications or
implementations. The current RFCs shall not be obsoleted but
rather updated with either new information or instructions on
what is needed, for instance, to employ a new TLS version.

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

Milestones:

  Apr 2018 - WG adopts initial draft on guidance for EAP TLS with TLS 1.3

  Apr 2018 - Begin work on EAP-AKA update, RFC5448-bis

  May 2018 - Adopt draft for extension to EAP-AKA to support forward secrecy

  Jul 2018 - Adopt draft to define session identifiers for fast
  re-authentication for EAP-SIM, EAP-AKA, and EAP-AKA

  Jul 2018 - Adopt draft on operational recommendations for large certificate
  and chain sizes

  Feb 2019 - Working group last call for EAP-AKA update, RFC5448-bis

WG Review: EAP Method Update (emu)

[The IESG]

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 [EMAIL PROTECTED]
Sam Hartman [EMAIL PROTECTED]

Security Area Advisor:
Sam Hartman [EMAIL PROTECTED]

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