Subject: [Emu] Potential re-establishment of the EMU working group

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Dec 2017 15:40:55 +0200

Hi,

I’ve been thinking of what to do with the EAP work that got discussed both in the SAAG meeting last time (my drafts), as well on the list. The latter was more on the EAP-TLS side, and it seems that the discussion has converged to a reasonable direction recently.

Wondering how we could get the work moving forward. The first thought that came to my mind was to start a small working group. Thoughts?  A very drafty idea of what it would do is below. Comments appreciated.

————

EAP Maintenance Update (emu)
       or
EAP Method Maintenance Update (emmu)
------------------------------------

Chairs:
    TBD

Security Area Directors:
    Eric Rescorla <[email-masked] <mailto:[email-masked]>>
    Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>

Security Area Advisor:
    TBD

Mailing Lists:
    General Discussion: [email-masked] <mailto:[email-masked]>
    To Subscribe:       https://www.ietf.org/mailman/listinfo/emu <https://www.ietf.org/mailman/listinfo/emu>
    Archive:            http://www.ietf.org/mail-archive/web/emu/ <http://www.ietf.org/mail-archive/web/emu/>

Description of Working Group:

   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. The specification
     should also be updated to define session identifiers for the fast-
     re-authentication mode, for which there is an errata against the
     existing RFCs.

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

   - 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.

   - Potentially something else, too, but I have not seen requests
     for other things yet. It would be beneficial to keep the WG scope
     small.

   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:

   TBD

---

From: Alan DeKok <[email-masked]>
Date: Thu, 21 Dec 2017 09:01:36 -0500

> Wondering how we could get the work moving forward. The first thought that came to my mind was to start a small working group. Thoughts?  A very drafty idea of what it would do is below. Comments a…

  The Session ID also needs to be defined for SIM and AKA, as per Jouni's comments.  That doesn't fit in with AKA' changes.

  It may also be worth re-examining EAP-TLS.  Modern certificates are getting large, and people are using longer certificate chains.  The result can be that initial EAP-TLS authentication takes many packets.  This has issues not just for latency, but also access point implementations.  Most implementations will drop an EAP session if it hasn't finished after 40-50 packets.

  I've seen people run into this issue with large certificates and long certificate chains.  It would be good to find a way to allow this use-case.

  Alan DeKok.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Dec 2017 16:07:03 +0200

> The Session ID also needs to be defined for SIM and AKA, as per Jouni's comments.  That doesn't fit in with AKA' changes.

Yeah, I was thinking about that but didn’t go far enough. But you’re right. Maybe this needs to be a separate item for EAP-SIM.

>  I've seen people run into this issue with large certificates and long certificate chains.  It would be good to find a way to allow this use-case.

That’s interesting.

Do you have any suggestions on what to do about this issue, or were you thinking about just stating that implementations should not stop that early in the exchange?

Jari

---

From: Alan DeKok <[email-masked]>
Date: Thu, 21 Dec 2017 09:39:59 -0500

> Do you have any suggestions on what to do about this issue, or were you thinking about just stating that implementations should not stop that early in the exchange?

  I think it's good for implementations to have limits on the number of packets being exchanged.  40-50 is even a reasonable limit.

  The question I have is whether we can do anything to EAP-TLS to address the issue.  Answering that question requires a deeper dive into TLS.

  Alan DeKok.