EAP Method Update (emu) Internet Drafts

      
 Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
 
 draft-ietf-emu-aka-pfs-12.txt
 Date: 19/02/2024
 Authors: Jari Arkko, Karl Norrman, John Mattsson
 Working Group: EAP Method Update (emu)
 This document updates RFC 9048, the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'), with an optional extension providing ephemeral key exchange. Similarly, this document also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past, assuming these have been properly deleted. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead.
 Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)
 
 draft-ietf-emu-bootstrapped-tls-05.txt
 Date: 17/02/2024
 Authors: Owen Friel, Dan Harkins
 Working Group: EAP Method Update (emu)
 This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a network. Bootstrapping devices have a public private key pair, and this mechanism enables a network server to prove to the device that it knows the public key, and the device to prove to the server that it knows the private key. The mechanism leverages existing DPP and TLS standards and can be used in an EAP exchange.
 Tunnel Extensible Authentication Protocol (TEAP) Version 1
 
 draft-ietf-emu-rfc7170bis-19.txt
 Date: 07/06/2024
 Authors: Alan DeKok
 Working Group: EAP Method Update (emu)
 This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one.
 EAP-FIDO
 
 draft-janfred-eap-fido-02.txt
 Date: 01/03/2024
 Authors: Jan-Frederik Rieckers, Stefan Winter
 Working Group: EAP Method Update (emu)
 This document specifies an EAP method leveraging FIDO2 keys for authentication in EAP. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-janfred-eap-fido/. Discussion of this document takes place on the EAP Method Update Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/.
 Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman over COSE (EDHOC)
 
 draft-ietf-emu-eap-edhoc-00.txt
 Date: 13/06/2024
 Authors: Dan Garcia-Carrillo, Rafael Marin-Lopez, Goeran Selander, John Mattsson
 Working Group: EAP Method Update (emu)
 The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-EDHOC with Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC provides a lightweight authenticated Diffie-Hellman key exchange with ephemeral keys, using COSE (RFC 9052, RFC 9053) to provide security services efficiently encoded in CBOR (RFC 8949). This document also provides guidance on authentication and authorization for EAP-EDHOC.
 The eap.arpa domain and EAP provisioning
 
 draft-ietf-emu-eap-arpa-00.txt
 Date: 13/06/2024
 Authors: Alan DeKok
 Working Group: EAP Method Update (emu)
 This document defines the eap.arpa domain as a way for EAP peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain pre-defined identifiers which use the Network Access Identifier (NAI) format of RFC7542. A table of identifiers and meanings is defined. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-emu-eap-arpa/. Discussion of this document takes place on the EMU Working Group mailing list (mailto:emut@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emut/. Subscribe at https://www.ietf.org/mailman/listinfo/emut/. Source for this draft and an issue tracker can be found at https://github.com/freeradius/eap-arpa.git.

data-group-menu-data-url="/group/groupmenu.json">

EAP Method Update (emu)

WG Name EAP Method Update
Acronym emu
Area Security Area (sec)
State Active
Charter charter-ietf-emu-07 Approved
Status update Show Changed 2018-11-07
Document dependencies
Additional resources GitHub page
Issue tracker
Wiki
Zulip stream
Personnel Chairs Joseph A. Salowey, Peter E. Yee
Area Director Paul Wouters
Mailing list Address emu@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/emu
Archive https://mailarchive.ietf.org/arch/browse/emu
Chat Room address https://zulip.ietf.org/#narrow/stream/emu

Charter for Working Group

The Extensible Authentication Protocol (EAP) [RFC3748] 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 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.

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.

EDHOC (Ephemeral Diffie-Hellman Over COSE) is a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys that is suitable in constrained environments in which many of the existing EAP methods are not a good fit. EDHOC offers the useful properties of mutual authentication, forward secrecy, and identity protection. The group will accordingly produce a specification for an EAP method incorporating the EDHOC mechanism (RFC9628).

While TLS-based EAP mechanisms provide strong channel protections, if the client does not authenticate and validate the server's credentials properly (possibly owing to a lack of provisioned information necessary to undertake that validation), an EAP mechanism running over TLS that relies on passwords is vulnerable to client credential theft, much the same as password authentication over plain TLS is. The FIDO Alliance and the W3C have developed a passwordless authentication scheme known as FIDO2, which combines elements of the W3C's WebAuthn and FIDO's CTAP standards. The group will devise an EAP method suitable for use with passwordless authentication schemes such as the CTAP2 version of FIDO2.

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

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

  • Develop an EAP method for use in constrained environments that wish to leverage the EDHOC key exchange mechanism.

  • Devise a passwordless EAP method that can incorporate use of CTAP2 or other similar authentication mechanism.

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), the FIDO Alliance, and the 3GPP security architecture group (for EAP-AKA' work).

Milestones

Date Milestone Associated documents
May 2024 WG adopts an ancillary draft on use of the eap.arpa domain for use in other EAP methods
May 2024 WG adopts initial draft on an EAP method for using FIDO CTAP2
May 2024 WG adopts initial draft on an EAP method for use of EDHOC