]> University of Oviedo

Gijon, Asturias 33203 Spain garciadan@uniovi.es

University of Murcia

Murcia 30100 Spain rafa@um.es

Ericsson

SE-164 80 Stockholm Sweden goran.selander@ericsson.com

Ericsson

SE-164 80 Stockholm Sweden john.mattsson@ericsson.com

University of Murcia

Murcia 30100 Spain francisco.lopezg@um.es

EAP Method Update 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. About This Document Status information for this document may be found at . Discussion of this document takes place on the EAP Method Update mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Extensible Authentication Protocol (EAP), defined in , 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) . EAP-EDHOC is similar to EAP-TLS 1.3 , since EDHOC is based on a similar security protocol design as the TLS 1.3 handshake . 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 . The EAP-EDHOC method enables the integration of EDHOC into different applications and use cases using the EAP framework.

EDHOC Overview Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated ephemeral key exchange, including mutual authentication and establishment of shared secret keying material, see . 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 . The main features of EDHOC are:

• Support for different authentication methods and credentials. The authentication methods include (mixed) signatures and static Diffie-Hellman keys , and pre-shared keys . A wide and extensible range of authentication credentials is supported, including public key certificates such as X.509 and C509 , as well as CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) .
• A standardized and extensible format for identification of credentials, using COSE header parameters , 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 .
• 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 . EDHOC messages make use of lightweight primitives, specifically CBOR and COSE for efficient encoding and security services in constrained devices. EDHOC is optimized for use with CoAP and OSCORE to secure resource access in constrained IoT use cases, but it is not bound to a particular transport or communication security protocol.

Conventions and Definitions 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 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 and EDHOC , in particular the following. Acronyms and Terms:

• MSK - Master Session Key; defined in .
• EMSK - Extended Master Session Key; defined in .
• 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 .
• 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 .

Protocol Overview

Overview of the EAP-EDHOC Conversation 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 . This document only lists additional and different requirements, restrictions, and processing compared to . The message processing in 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 . Resumption of EAP-EDHOC may be defined using the EDHOC-PSK authentication method .

Successful EAP-EDHOC Message Flow without Fragmentation 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 is not applicable to this EAP method. shows an example message flow for a successful execution of EAP-EDHOC.

EAP-EDHOC Message Flow | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC Start) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC message_1) | | ----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC message_2) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC message_3) | | ----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC message_4) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | ----------------------------------------------------> | | | | EAP-Success | | <---------------------------------------------------- | | | ]]>

If the EAP-EDHOC peer authenticates successfully, the EAP-EDHOC server MUST send an EAP-Request packet with EAP-Type=EAP-EDHOC containing message_4 as a protected success indication. If the EAP-EDHOC server authenticates successfully, and the EAP-EDHOC peer achieves key confirmation by successfully verifying EDHOC message_4, then the EAP-EDHOC peer MUST send an EAP-Response message with EAP-Type=EAP-EDHOC containing no data. Finally, the EAP-EDHOC server sends an EAP-Success. Note that the Identity request is optional and might not be used in systems like 3GPP 5G where the identity is transferred encrypted by other means before the EAP exchange. While the EAP-Response/EAP-Type=EAP-EDHOC and EAP-Success are mandatory they do not contain any information and might be encoded into other system specific messages .

Transport and Message Correlation EDHOC is not bound to a particular transport layer and can even be used in environments without IP. Nonetheless, provides a set of requirements for a transport protocol to use with EDHOC. These include: handling the loss, reordering, duplication, correlation, and fragmentation of messages; demultiplexing EDHOC messages from other types of messages; and denial-of-service protection. These requirements can be met by the EAP framework, the EAP-EDHOC method specification, and properties of the EAP lower layer, as specified in . For message loss, this can be either fulfilled by the EAP layer, the EAP lower layer, or both. For message reordering, correct operation assumes that the EAP lower layer preserves packet ordering within an EAP conversation. For duplication and message correlation, EAP has the Identifier field, which allows both the EAP peer and EAP authenticator to detect duplicates and match a request with a response. Fragmentation is defined by this EAP method, see . The EAP framework , specifies that EAP methods need to provide fragmentation and reassembly if EAP packets can exceed the minimum MTU of 1020 octets. To demultiplex EDHOC messages from other types of messages, EAP provides the Type field. This method does not provide any additional mitigation against denial-of-service attacks beyond those specified in EAP .

Termination , , , and illustrate message flows in several cases where the EAP-EDHOC peer or EAP-EDHOC server sends an EDHOC error message. shows an example message flow where the EAP-EDHOC server rejects message_1 with an EDHOC error message.

EAP-EDHOC Server Rejection of message_1 | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC Start) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC message_1) | | ----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC error) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | ----------------------------------------------------> | | | | EAP-Failure | | <---------------------------------------------------- | | | ]]>

shows an example message flow where the EAP-EDHOC server authentication is unsuccessful and the EAP-EDHOC peer sends an EDHOC error message.

EAP-EDHOC Peer Rejection of message_2 | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC Start) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC message_1) | | ----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC message_2) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC error) | | ----------------------------------------------------> | | | | EAP-Failure | | <---------------------------------------------------- | | | ]]>

shows an example message flow where the EAP-EDHOC server authenticates to the EAP-EDHOC peer successfully, but the EAP-EDHOC peer fails to authenticate to the EAP-EDHOC server, and the server sends an EDHOC error message. Note that the EDHOC error message cannot be omitted. For example, with EDHOC ERR_CODE 3 "Unknown credential referenced", it is indicated that the EDHOC peer should, for the next EDHOC session, try another credential identifier supported according to the application profile.

EAP-EDHOC Server Rejection of message_3 | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC Start) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC message_1) | | ----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC message_2) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC message_3) | | ----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC error) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | ----------------------------------------------------> | | | | EAP-Failure | | <---------------------------------------------------- | | | ]]>

shows an example message flow where the EAP-EDHOC server sends the EDHOC message_4 to the EAP peer, but the protected success indication fails, and the peer sends an EDHOC error message.

EAP-EDHOC Peer Rejection of message_4 | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC Start) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC message_1) | | ----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC message_2) | | <---------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC message_3) | | ----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC | | (EDHOC message_4) | | <--------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC | | (EDHOC error) | | ----------------------------------------------------> | | | | EAP-Failure | | <---------------------------------------------------- | | | ]]>

Identity It is RECOMMENDED to use anonymous Network Access Identifiers (NAIs) in the Identity Response, as such identities are routable and privacy-friendly. While opaque blobs are allowed by , such identities are NOT RECOMMENDED as they are not routable and should only be considered in local deployments where the EAP-EDHOC peer, EAP authenticator, and EAP-EDHOC server all belong to the same network. Many client certificates contain an identity such as an email address, which is already in NAI format. When the certificate contains an NAI as subject name or alternative subject name, an anonymous NAI SHOULD be derived from the NAI in the certificate. See .

Privacy EAP-EDHOC peer and server implementations supporting EAP-EDHOC MUST support anonymous NAIs (Section 2.4 of ). A node supporting EAP-EDHOC MUST NOT send its username (or any other permanent identifiers) in cleartext in the Identity Response (or any message used instead of the Identity Response). Following , it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g., anonymous@realm) or an encrypted username (e.g., xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of .

Fragmentation EDHOC is designed to perform well in constrained networks where message sizes are restricted for performance reasons. When credentials are transferred by reference, EAP-EDHOC messages are typically so small that fragmentation is not needed. However, as EAP-EDHOC also supports large X.509 certificate chains, EAP-EDHOC implementations MUST provide support for fragmentation and reassembly. Some EAP implementations and access networks impose limits on the number of EAP packet exchanges that can be processed. To minimize fragmentation, it is RECOMMENDED to use compact EAP-EDHOC peer, EAP-EDHOC server, and trust anchor authentication credentials, as well as to limit the length of certificate chains. Additionally, mechanisms that reduce the size of Certificate messages are RECOMMENDED. Since EAP is a lock-step protocol, fragmentation support can be easily added. To do so, the EAP-Response and EAP-Request packets of EAP-EDHOC have a set of information fields that allow for the specification of the fragmentation process (see for the detailed description). As a summary, EAP-EDHOC fragmentation support is provided through the addition of flag bits (M and L) within the EAP-Response and EAP-Request packets, as well as a (conditional) EAP-EDHOC Message Length field that can be zero to four octets. The EDHOC Message Length field conveys the total length of the EDHOC message being fragmented, which facilitates buffer allocation. The L flag consists of three bits that determine the length of the EDHOC Message Length field. This L flag and the EAP-EDHOC Message Length field MUST be present only in the first fragment of a fragmented EDHOC message, thereby signaling that the EDHOC message is fragmented. Implementations MUST NOT set any of the L flag bits to 1 in unfragmented messages. The S flag bit SHALL be set in the EAP-EDHOC Start message sent by the EAP server to the peer. The S flag bit SHALL NOT be set in any other EAP-EDHOC messages. The M flag bit SHALL be set in all fragments except the last one. When an EAP-EDHOC peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response packet with EAP-Type=EAP-EDHOC, including the flags octect with S=0, M=0, L=0 and an empty EDHOC payload. This message serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. To prevent errors in the processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value. Similarly, when the EAP-EDHOC server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request packet with EAP-Type=EAP-EDHOC, including the flags octect with S=0, M=0, L=0 and an empty EDHOC payload. This message serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. To prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response. Explanations and considerations regarding retransmission timers are provided in . illustrates the exchange between the endpoints in the case where the EAP-EDHOC mutual authentication is successful and fragmentation is required. EAP Identifiers are also shown to illustrate their progression. A retransmission is also included.

EAP-EDHOC Fragmentation Example | | | | EAP-Request/EAP-Type=EAP-EDHOC (EAP-ID: 0x1) | | (EDHOC Start, S bit set) | | <----------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC (EAP-ID: 0x1) | | (EDHOC message_1) | | -----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC (EAP-ID: 0x2) | | (EDHOC message_2, Fragment 1, L and M bits set) | | <----------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC (EAP-ID: 0x2) | | -----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC (EAP-ID: 0x3) | | (EDHOC message_2, Fragment 2, M bit set) | | <----------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC (EAP-ID: 0x3) | | -----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC (EAP-ID: 0x4) | | (EDHOC message_2, Fragment 3) | | <----------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC (EAP-ID: 0x4) | | (EDHOC message_3, Fragment 1, L and M bits set) | | -----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC (EAP-ID: 0x5) | | X-------------------------- | | | | EAP-Request/EAP-Type=EAP-EDHOC (EAP-ID: 0x5) | | (Retransmission) | | <----------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC (EAP-ID: 0x5) | | (EDHOC message_3, Fragment 2, M bit set) | | -----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC (EAP-ID: 0x6) | | <----------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC (EAP-ID: 0x6) | | (EDHOC message_3, Fragment 3) | | -----------------------------------------------------> | | | | EAP-Request/EAP-Type=EAP-EDHOC (EAP-ID: 0x7) | | (EDHOC message_4) | | <----------------------------------------------------- | | | | EAP-Response/EAP-Type=EAP-EDHOC (EAP-ID: 0x7) | | -----------------------------------------------------> | | | | EAP-Success (EAP-ID: 0x7) | | <----------------------------------------------------- | | | ]]>

Identity Verification The EAP peer identity provided in the EAP-Response/Identity is not authenticated by EAP-EDHOC. Unauthenticated information MUST NOT be used for accounting purposes or to give authorization. The EAP authenticator and the EAP server MAY examine the identity presented in EAP-Response/Identity for purposes such as routing and EAP method selection. EAP-EDHOC servers MAY reject conversations if the identity does not match their policy. The EAP server identity in the EDHOC server certificate is typically a fully qualified domain name (FQDN) in the SubjectAltName (SAN) extension. Since EAP-EDHOC deployments may use more than one EAP server, each with a different certificate, EAP peer implementations SHOULD allow for the configuration of one or more trusted root certificates (CA certificate) to authenticate the server certificate and one or more server names to match against the SubjectAltName (SAN) extension in the server certificate. If any of the configured names match any of the names in the SAN extension, then the name check passes. To simplify name matching, an EAP-EDHOC deployment can assign a designated name to represent an authorized EAP server. This name can then be included in the SANs list of each certificate used by this EAP-EDHOC server. If server name matching is not used, the EAP peer has reduced assurance that the EAP server it is interacting with is authoritative for the given network. If name matching is not used with a trusted root CA, then effectively any server can obtain a certificate that will be trusted for EAP authentication by the peer. The process of configuring a root CA certificate and a server name is non-trivial; therefore, automated methods of provisioning are RECOMMENDED. For example, the eduroam federation provides a Configuration Assistant Tool (CAT) to automate the configuration process. In the absence of a trusted root CA certificate (user-configured or system-wide), EAP peers MAY implement a Trust On First Use (TOFU) mechanism where the peer trusts and stores the server certificate during the first connection attempt. The EAP peer ensures that the server presents the same stored certificate on subsequent interactions. The use of a TOFU mechanism does not allow for the server certificate to change without out-of-band validation of the certificate and is therefore not suitable for many deployments including ones where multiple EAP servers are deployed for high availability. TOFU mechanisms increase the susceptibility to traffic interception attacks and should only be used if there are adequate controls in place to mitigate this risk. As an alternative to standard certificate validation, EDHOC extensions such as the Lightweight Authorization mechanism defined in can provide additional means of verifying server credentials. Such mechanisms may be suitable in deployments where no prior trust relationship exists or where managing trusted root CAs is impractical.

Key Hierarchy The key derivation for EDHOC is described in Section 4 of . The key material and Method-Id SHALL be derived from the PRK_exporter using the EDHOC_Exporter interface, see Section 4.2.1 of . Type is the value of the EAP Type field defined in Section 2 of . For EAP-EDHOC, Type has the value TBD1. The << >> notation defined in Section G.3 of means that the CBOR-encoded integer Type value is embedded in a CBOR byte string. The use of Type as context enables the reuse of exporter labels across other future EAP methods based on EDHOC. >, 64) EMSK = EDHOC_Exporter(TBD3, << Type >>, 64) Method-Id = EDHOC_Exporter(TBD4, << Type >>, 64) Session-Id = Type || Method-Id Peer-Id = ID_CRED_I Server-Id = ID_CRED_R ]]> EAP-EDHOC exports the MSK and the EMSK and does not specify how it is used by lower layers.

Parameter Negotiation and Compliance Requirements The EAP-EDHOC peers and EAP-EDHOC servers MUST comply with the requirements defined in Section 8 of , including mandatory-to-implement cipher suites, signature algorithms, key exchange algorithms, and extensions.

EAP State Machines It is worth remembering that the EAP state machine is defined in . However, the following considerations apply to EAP-EDHOC. The EAP-EDHOC server sends message_4 in an EAP-Request as a protected success result indication. Because EDHOC error messages are unauthenticated, they MUST NOT be relied upon to determine the cause of failure; they only indicate that the exchange did not complete and are vulnerable to injection by an attacker (DoS). However, EDHOC error messages SHOULD be considered failure result indication, as defined in . After sending or receiving an EDHOC error message, the EAP-EDHOC server may only send an EAP-Failure. The keying material can be derived by the Initiator upon receiving EDHOC message_2, and by the Responder upon receiving EDHOC message_3. Implementations following can then set the eapKeyData and aaaEapKeyData variables. The keying material can be made available to lower layers and the EAP authenticator after the protected success indication (message_4) has been sent or received. Implementations following can set the eapKeyAvailable and aaaEapKeyAvailable variables.

EAP Channel Binding EAP-EDHOC allows the secure exchange of information between the endpoints of the authentication process (i.e., the EAP peer and the EAP server) using protected data fields. These fields can be used to exchange EAP channel binding information, as defined in . Section 6 in outlines requirements for components implementing channel binding information, all of which are satisfied by EAP-EDHOC, including confidentiality and integrity protection. Additionally, EAP-EDHOC supports fragmentation, allowing the inclusion of additional information at the method level without issues. While the EAD_1 and EAD_2 fields (carried in EDHOC message_1 and EDHOC message_2, respectively) are integrity protected through the transcript hash, the channel binding protocol defined in must be transported after keying material has been derived between the endpoints in the EAP communication and before the peer is exposed to potential adverse effects from joining an adversarial network. Therefore, compliance with requires use of the EAD_3 and EAD_4 fields, transmitted in EDHOC message_3 and EDHOC message_4, respectively. It is important to note that EAD fields in EDHOC are optional; consequently, the inclusion of EAP Channel Binding information in an authentication exchange is also optional. Accordingly, this document specifies a new EAD item, with ead_label = TBD5, to incorporate EAP channel binding information into the EAD fields of the EAP-EDHOC messages. See the definition in . This new EAD item is intended only for EAD_3 and EAD_4. Then, it MUST be ignored if included in other EAD fields. Multiple occurrences of this new EAD item in one EAD field are NOT allowed.

• Implementation Note: This document defines only the container for carrying EAP Channel Binding information within EAP-EDHOC messages, using the EAD_3 and EAD_4 fields. The format and semantics of the channel binding content are application-specific and are determined by the authentication domain in which the protocol is deployed.

If the server detects a consistency error in the channel binding information contained in EAD_3, it MUST send an EDHOC error message, as specified in , since the new EAD item defined to carry EAP Channel Binding information is critical. In this case, the exchange proceeds according to . Similarly, if the Initiator detects an error in the channel binding information contained in EAD_4, it MUST send an EDHOC error message, and the exchange proceeds according to .

Detailed Description of the EAP-EDHOC Request and Response Protocol The EAP-EDHOC packet format for Requests and Responses is summarized in . Fields are transmitted from left to right, following a structure inspired by the EAP-TLS packet format . As specified in Section 4.1 of , EAP Request and Response packets consist of Code, Identifier, Length, Type, and Type-Data fields. The functions of the Code, Identifier, Length, and Type fields are reiterated here for convenience. The EAP Type-Data field consists of the R, S, M, L, EDHOC Message Length, and EDHOC Data fields.

EAP-EDHOC Request and Response Packet Format

EAP-EDHOC Request Packet

Code:

1 (Request)

Identifier:

The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each new (non-retransmission) Request packet, and MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. In the case of fragmented messages, the Identifier will follow the indications of .

Length:

The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception.

Type:

TBD1 (EAP-EDHOC)

R:

Implementations of this specification MUST set the R bits (reserved) to zero and MUST ignore them on reception.

S:

The S bit (EAP-EDHOC start) is set in an EAP-EDHOC Start message. This differentiates the EAP-EDHOC Start message from a fragment acknowledgement.

M:

The M bit (more fragments) is set on all but the last fragment. I.e., when there is no fragmentation, it is set to zero.

L:

The L flag bits represent the binary encoding of the size of the EDHOC Message Length, which can range from 0 to 4 bytes. When all three bits are set to 0, the EDHOC Message Length field is not present. If the first two bits of the L field are set to 0 and the last bit is set to 1, then the size of the EDHOC Message Length field is 1 byte, and so on. Values from 5 to 7 are not used in this specification.

EDHOC Message Length:

The EDHOC Message Length field, when present, has a size of one to four octets, as determined by the L flag bits. It is included only if the L flag bits indicate a value greater than zero and specifies the total length of the EDHOC message being fragmented. When fragmentation is not used, this field is omitted.

EDHOC Data:

The EDHOC data consists of the whole or a fragment of the transported EDHOC message.

EAP-EDHOC Response Packet

Code:

2 (Response)

Identifier:

The Identifier field is one octet and MUST match the Identifier field from the corresponding request.

Length:

The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception.

Type:

TBD1 (EAP-EDHOC)

R:

Implementations of this specification MUST set the R bits (reserved) to zero and MUST ignore them on reception.

S:

The S bit (EAP-EDHOC start) is set to zero.

M:

The M bit (more fragments) is set on all but the last fragment. I.e., when there is no fragmentation, it is set to zero.

L:

The L flag bits represent the binary encoding of the size of the EDHOC Message Length, which can range from 0 to 4 bytes. When all three bits are set to 0, the EDHOC Message Length field is not present. If the first two bits of the L field are set to 0 and the last bit is set to 1, then the size of the EDHOC Message Length field is 1 byte, and so on. Values from 5 to 7 are not used in this specification.

EDHOC Message Length:

The EDHOC Message Length field, when present, has a size of one to four octets, as determined by the L flag bits. It is included only if the L flag bits indicate a value greater than zero and specifies the total length of the EDHOC message being fragmented. When fragmentation is not used, this field is omitted.

EDHOC Data:

The EDHOC data consists of the whole or a fragment of the transported EDHOC message.

IANA Considerations

EAP Type IANA has registered the following new type in the "Method Types" registry under the group name "Extensible Authentication Protocol (EAP) Registry": NOTE: Suggested value: TBD1 = 57. RFC Editor: Remove this note.

EDHOC Exporter Label Registry IANA has registered the following new labels in the "EDHOC Exporter Label" registry under the group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)": NOTE: Suggested values: TBD2 = 26, TBD3 = 27, TBD4 = 28. RFC Editor: Remove this note. The allocations have been updated to reference this document.

EDHOC External Authorization Data Registry IANA has registered the following new label in the "EDHOC External Authorization Data" registry under the group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)": NOTE: Suggested value: TBD5 = 1. RFC Editor: Remove this note.

Security Considerations The security considerations of EAP and EDHOC apply to this document. Since the design of EAP-EDHOC closely follows EAP-TLS 1.3 , many of its security considerations are also relevant.

Security Claims

EAP Security Claims EAP security claims are defined in Section 7.2.1 of . EAP-EDHOC security claims are described next and summarized in . EAP-EDHOC security claims

Claim
Auth. principle:	Certificates, CWTs, and all credential types for which COSE header parameters are defined (1)
Cipher suite negotiation:	Yes (2)
Mutual authentication:	Yes (3)
Integrity protection:	Yes (4)
Replay protection:	Yes (5)
Confidentiality:	Yes (6)
Key derivation:	Yes (7)
Key strength:	The specified cipher suites provide key strength of at least 128 bits.
Dictionary attack protection:	Yes (8)
Fast reconnect:	No
Crypt. binding:	N/A
Session independence:	Yes (9)
Fragmentation:	Yes ()
Channel binding:	Yes (: EAD_3 and EAD_4 can be used to convey integrity-protected channel properties, such as network SSID or peer MAC address.)

• (1) Authentication principle: EAP-EDHOC establishes a shared secret based on an authenticated ECDH key exchange. The key exchange is authenticated using different kinds of credentials. EAP-EDHOC supports EDHOC credential types. EDHOC supports all credential types for which COSE header parameters are defined. These include X.509 certificates , C509 certificates, CWTs ( Section 3.5.3.1), and CCSs ( Section 7.1).
• (2) Cipher suite negotiation: The Initiator's list of supported cipher suites and order of preference is fixed, and the selected cipher suite is the cipher suite that is most preferred by the Initiator and that is supported by both the Initiator and the Responder. EDHOC supports all signature algorithms defined by COSE.
• (3) Mutual authentication: The initiator and responder authenticate each other through the EDHOC exchange.
• (4) Integrity protection: EDHOC integrity protects all message content using transcript hashes for key derivation and as additional authenticated data, including, e.g., method type, cipher suites, and external authorization data.
• (5) Replay protection. EDHOC broadens the message authentication coverage to include algorithms, external authorization data, and prior plaintext messages, as well as adding an explicit method type. By doing this, an attacker cannot replay or inject messages from a different EDHOC session.
• (6) Confidentiality. EDHOC protects the method payload transported within the EAP-Request and EAP-Response messages; however, the EAP-Success and EAP-Failure packets themselves are not encrypted or protected by EDHOC. EDHOC message_1 is not confidential, but it does not convey any private information. EDHOC message_2 provides confidentiality against passive attackers, while message_3 and message_4 provide confidentiality against active attackers.
• (7) Key derivation. Except for MSK and EMSK, derived keys are not exported. Key derivation is discussed in .
• (8) Dictionary attack protection. EAP-EDHOC provides Dictionary attack protection.
• (9) Session independence. EDHOC generates computationally independent keys derived from the ECDH shared secret.

Additional Security Claims

• (10) Cryptographic strength and Forward secrecy: Only ephemeral key exchange methods are supported by EDHOC, which ensures that the compromise of a session key does not also compromise earlier sessions' keys.
• (11) Identity protection: EDHOC secures the Responder's credential identifier against passive attacks and the Initiator's credential identifier against active attacks. An active attacker can get the credential identifier of the Responder by eavesdropping on the destination address used for transporting message_1 and then sending their own message_1.

Peer and Server Identities The Peer-Id represents the identity to be used for access control and accounting purposes. The Server-Id represents the identity of the EAP server. The Peer-Id and Server-Id are determined from the information provided in the credentials used. ID_CRED_I and ID_CRED_R are used to identify the credentials of the Initiator (EAP peer) and Responder (EAP server). Therefore, for Server-Id the ID_CRED_R is used, and for Peer-Id the ID_CRED_I is used.

Certificate Validation Same considerations as in EAP-TLS 1.3 Section 5.3 apply here in relation to the use of certificates. When other types of credentials are used such as CWT/CCS, the application needs to have a clear trust-establishment mechanism and identify the pertinent trust anchors .

Certificate Revocation Same considerations as in EAP-TLS 1.3 Section 5.4 apply here in relation to certificates. When other types of credentials are used such as CWT/CCS, the endpoints are in charge of handling revocation and confirming the validity and integrity of CWT/CCS .

Packet Modification Attacks EAP-EDHOC relies on EDHOC, which is designed to encrypt and integrity protect as much information as possible. Any change in any message is detected by means of the transcript hashes integrity verification.

Authorization Following the considerations of EDHOC in appendix D.5 Unauthenticated Operation , EDHOC can be used without authentication by allowing the Initiator or Responder to communicate with any identity except its own. When peer authentication is not used, EAP-EDHOC server implementations MUST take care to limit network access appropriately for authenticated peers. Authorization and accounting MUST be based on authenticated information such as information in the certificate. The requirements for Network Access Identifiers (NAIs) specified in Section 4 of apply and MUST be followed.

Privacy Considerations Considerations in Section 9.6 of against tracking of users and eavesdropping on Identity Responses or certificates apply here. Also, the considerations of Section 5.8 of regarding anonymous NAIs also applies.

Pervasive Monitoring Considerations in Section 9.1 of about pervasive monitoring apply here.

Cross-Protocol Attacks The cross-protocol attack of does not apply here, as no resumption mechanism has been defined for EAP-EDHOC.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK] The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK] This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK] In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. Informative References This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative. The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section. The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. Inria Ericsson Ericsson University of Murcia University of Murcia This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280, common certificate profiles and is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is over the CBOR encoding instead of the DER encoding, avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 and the same reduced size compared to X.509. The document also specifies CBOR encoded data structures for certificate (signing) requests and certificate request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698; the TLSA selectors registry is extended to include C509 certificates. RISE AB RISE AB The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, in order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. RISE AB This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). Ericsson AB Ericsson AB INRIA INRIA Sandelman Software Works Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time.

Fragmented Message Example This section provides an example of a fragmented message, including all header field values, to improve clarity and avoid ambiguity. In this example, the total size of the EDHOC message is 128 octets. The MTU allows 32 EAP bytes to be transmitted per packet. No retransmissions are considered in this example. Furthermore, this does not correspond to the EAP-EDHOC Start message. The packets sent by the server are shown below: As shown, the L flags have a value of 0b001 in the first fragment, indicating that the EDHOC Msg Length field is 1 byte in size. The EDHOC Msg Length field indicates the total size of the EDHOC message being fragmented, which is 128 bytes. The L flags and the EDHOC Msg Length field are only present in the first fragment. Another relevant detail is that the first fragment includes 7 bytes of header (1 byte Code, 1 byte Identifier, 2 bytes Length, 1 byte Type, 1 byte Flags, and 1 byte EDHOC Msg Length), as illustrated in . Subsequent fragments include 6 bytes of header, since they do not carry the EDHOC Msg Length field. Consequently, with an MTU of 32 bytes, the first fragment carries 25 bytes of payload, while each subsequent fragment carries up to 26 bytes of payload.

Acknowledgments The authors sincerely thank Eduardo Ingles-Sanchez for his contribution in the initial phase of this work. We also want to thank Marco Tiloca, Christian Amsüss, Gabriel Lopez-Millan, Renzo Navas, Paul Wouters, Rich Salz, Ines Robles and Christopher Inacio for their reviews. This work was supported partially by Project PID2023-148104OB-C43 (ONOFRE4-UMU) from MCIN/AEI; the Formacion del Profesorado Universitario predoctoral grant FPU24/03871, also from MCIN/AEI; and the European Union's NextGenerationEU, as part of the Recovery, Transformation, and Resilience Plan, supported by Spanish INCIBE (6G-SOC project). This work was supported partially by Vinnova - the Swedish Agency for Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS.