| Internet-Draft | EAP-EDHOC | April 2026 |
| Garcia-Carrillo, et al. | Expires 19 October 2026 | [Page] |
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP-EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC.¶
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-edhoc/.¶
Discussion of this document takes place on the EAP Method Update 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/.¶
Source for this draft and an issue tracker can be found at https://github.com/dangarciacarrillo/i-d-eap-edhoc.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 October 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Extensible Authentication Protocol (EAP), defined in [RFC3748], provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP-EDHOC, which is based on the lightweight security handshake protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528].¶
EAP-EDHOC is similar to EAP-TLS 1.3 [RFC9190], since EDHOC is based on a similar security protocol design as the TLS 1.3 handshake [RFC8446]. However, EDHOC has been optimized for highly constrained settings, for example involving wirelessly connected battery powered 'things' with embedded microcontrollers, sensors, and actuators. An overview of EDHOC is given in Section 1.1.¶
The EAP-EDHOC method enables the integration of EDHOC into different applications and use cases using the EAP framework.¶
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated ephemeral key exchange, including mutual authentication and establishment of shared secret keying material, see [RFC9528].¶
EDHOC provides state-of-the-art security design at very low message overhead, targeting low complexity implementations and allowing extensibility. The security of EDHOC has been thoroughly analyzed, some references are provided in Section 9.1 of [RFC9528].¶
The main features of EDHOC are:¶
Support for different authentication methods and credentials. The authentication methods include (mixed) signatures and static Diffie-Hellman keys [RFC9528], and pre-shared keys [I-D.ietf-lake-edhoc-psk]. A wide and extensible range of authentication credentials is supported, including public key certificates such as X.509 and C509 [I-D.ietf-cose-cbor-encoded-cert], as well as CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392].¶
A standardized and extensible format for identification of credentials, using COSE header parameters [RFC9052], supporting credential transport by value or by reference, enabling very compact representations.¶
Crypto agility and secure cipher suite negotiation, with predefined compactly represented cipher suites and support for extensibility using the COSE algorithms registry [RFC9053].¶
Selection of connection identifiers identifying a session for which keys are agreed.¶
Support for integration of external security applications into EDHOC by transporting External Authorization Data (EAD) included in and protected as EDHOC messages.¶
A necessary condition for a successful completion of an EDHOC session is that both peers support a common application profile including method, cipher suite, etc. More details are provided in [I-D.ietf-lake-app-profiles].¶
EDHOC messages make use of lightweight primitives, specifically CBOR [RFC8949] and COSE [RFC9052] [RFC9053] for efficient encoding and security services in constrained devices. EDHOC is optimized for use with CoAP [RFC7252] and OSCORE [RFC8613] to secure resource access in constrained IoT use cases, but it is not bound to a particular transport or communication security protocol.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Readers are expected to be familiar with the terms and concepts defined in EAP [RFC3748] and EDHOC [RFC9528], in particular the following.¶
Acronyms and Terms:¶
Initiator - In EAP-EDHOC, the EAP peer assumes the role of the EDHOC Initiator; therefore, this term is used interchangeably with EAP peer; defined in [RFC9528].¶
Responder - In EAP-EDHOC, the EAP server assumes the role of the EDHOC Responder; therefore, this term is used interchangeably with EAP server; defined in [RFC9528].¶
The EAP exchange involves three key entities: the EAP peer, the EAP authenticator, and the EAP server. The EAP authenticator is a network device that enforces access control and initiates the EAP authentication process. The EAP peer is the device seeking network access and communicates directly with the EAP authenticator. The EAP server is responsible for selecting and implementing the authentication methods and for authenticating the EAP peer. When the EAP server is not located on a separate backend authentication server, it is integrated into the EAP authenticator. For simplicity, the operational flow diagrams in this document depict only the EAP peer and the EAP server.¶
The EDHOC protocol running between an Initiator and a Responder consists of three mandatory messages (message_1, message_2, message_3), an optional message_4, and an error message. In an EDHOC session, EAP-EDHOC uses all messages including message_4, which is mandatory and acts as a protected success indication.¶
After receiving an EAP-Request packet with EAP-Type=EAP-EDHOC as described in this document, the conversation will continue with the EDHOC messages transported in the data fields of EAP-Response and EAP-Request packets. When EAP-EDHOC is used, the formatting and processing of EDHOC messages SHALL be done as specified in [RFC9528]. This document only lists additional and different requirements, restrictions, and processing compared to [RFC9528].¶
The message processing in Section 5 of [RFC9528] states that certain data (EAD items, connection identifiers, application algorithms, etc.) is made available to the application. Since EAP-EDHOC is now acting as the application of EDHOC, it may need to handle this data to complete the protocol execution. See also [I-D.ietf-lake-edhoc-impl-cons].¶
Resumption of EAP-EDHOC may be defined using the EDHOC-PSK authentication method [I-D.ietf-lake-edhoc-psk].¶
EDHOC allows EAP-EDHOC to support authentication credentials of any type defined by COSE, which can be either transported or referenced during the protocol.¶
The optimization combining the execution of EDHOC with the first subsequent OSCORE transaction specified in [RFC9668] is not applicable to this EAP method.¶
Figure 1 shows an example message flow for a successful execution of EAP-EDHOC.¶