Subject: [saag] Potential new working group under discussion for EAP related maintenance + small extensions

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Jan 2018 10:42:28 +0200

I wanted to bring this to the SAAG list as well, although some of us have been discussing this on the EMU list.

We have been discussing of what to do with the EAP work that got discussed both in the SAAG meeting last time as well on the list. You may recall that there were a number of different topics:

* At IETF #100 SAAG, I presented a draft on small updates/corrections to EAP-AKA’ (RFC 5448)
* And adding perfect forward secrecy as an extension
* On the list, there were a lot of discussion about how to use TLS 1.3 in EAP-TLS. The discussion has converged, I think, and there seems to be work to be done. There’s a draft, and it has been updated per the most recent discussion.
* There was also a discussion of operational issues relating to long certificate chains in EAP-TLS.
* On the list, some new issues were also brought up affecting EAP-SIM, EAP-AKA, EAP-AKA’, which may need small updates.

I was 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 draft charter proposal is at https://www.ietf.org/mail-archive/web/emu/current/msg02239.html but also copied at the end of this message.

Comments, suggestions and other thoughts would be much welcome. Would such a small working group be reasonable? Are the suggested work items the right ones?

We will continue the discussion in the emu list, but if there are responses on this list those are much appreciated as well. I can also summarise to the emu list as needed. The full archive of the emu list is at https://www.ietf.org/mail-archive/web/emu/current/maillist.html. If you want to subscribe, go to https://www.ietf.org/mailman/listinfo/emu

Jari

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