Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)
Extracted elements (28)
Combining EDHOC message_3 with the first OSCORE request reduces the handshake from three round trips to the absolute minimum of two. This optimization is specifically motivated by constrained IoT scenarios where radio technology latency makes extra round trips costly, and is enabled by the fact that message_3 can be made relatively small.
EDHOC message_3 is placed in the payload rather than a CoAP option because it may be too large for an option, for example when conveying a large public key certificate chain in ID_CRED_I or large External Authorization Data in EAD_3. C_R, being compact, is instead reused from the OSCORE 'kid' field.
The EDHOC + OSCORE optimization is only possible when the default forward message flow is used (CoAP client as EDHOC Initiator, CoAP server as EDHOC Responder). The reverse message flow cannot achieve two round trips because the client already has enough state after receiving message_2 to preemptively derive the OSCORE Security Context.
CoRE Link Format is weakly typed and does not distinguish between the string "-10" and the integer -10. Since 'ed-idcred-t' values come from the strongly typed 'Label' column of the COSE Header Parameters registry, string values that look like integers are not supported and MUST NOT be used in the 'ed-idcred-t' parameter when responses are in CoRE Link Format.
The EDHOC + OSCORE combined workflow requires Block-wise transfer awareness: the EDHOC option must only appear in the first block, and if COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE the client must fall back to the sequential workflow. The performance advantage of the optimization can be lost under certain Block-wise parameter values.
A client SHOULD NOT have multiple simultaneous outstanding interactions with the same server such that they consist of EDHOC + OSCORE requests pertaining to the same EDHOC session (same C_R). This does not affect security but is recommended to avoid confusion.
An application profile MUST NOT specify support for the EDHOC + OSCORE request when it indicates that the server shall send EDHOC message_4, because the optimized workflow is incompatible with message_4 and using both together will always fail.
If EDHOC processing (Step 4) and OSCORE processing (Step 8) both succeed, the server MUST reply with an OSCORE-protected response. If EDHOC processing fails, the server MUST NOT establish a new OSCORE Security Context and responds with an unprotected EDHOC error message (Content-Format: application/edhoc+cbor-seq).
If the application profile specifies that EDHOC message_4 shall be sent, the server MUST stop EDHOC processing and consider it failed due to a client error when an EDHOC + OSCORE request is received. EDHOC message_4 is not applicable to the optimized workflow.
If the Initiator receives EDHOC message_2 with C_R equal to the C_I it selected, it MUST abort the session and reply with an EDHOC error message with error code 1. This prevents identifier collision between the two connection identifiers.
The client MUST NOT include the EDHOC option in OSCORE-protected requests conveying a non-first inner block (Block1 NUM != 0) of the first CoAP application request during Block-wise transfer.
The EDHOC option MUST occur at most once and MUST be empty. If any value is sent, the recipient MUST ignore it.
The Initiator MUST choose a C_I that is neither used in any current EDHOC session as this peer's connection identifier nor the Recipient ID in a current OSCORE Security Context where the ID Context is not present. C_I SHOULD NOT be the Recipient ID of any current OSCORE Security Context.
The Responder MUST choose a C_R that is not used in any current EDHOC session as its connection identifier, not equal to C_I from the current session, and not the Recipient ID in a current OSCORE Security Context where the ID Context is not present. C_R SHOULD NOT be the Recipient ID of any current OSCORE Security Context.
The server MUST perform all nine steps in Section 3.3.1 when processing a request containing the EDHOC option. If the request lacks the OSCORE option or COMB_PAYLOAD is malformed, the server MUST stop and MUST reply with a 4.00 (Bad Request) error response.
When Block-wise transfers are supported and COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE, the client MUST stop processing and MUST abandon the Block-wise transfer, then fall back to the sequential EDHOC workflow (sending EDHOC message_3 first, then the OSCORE request).
Client processing of the EDHOC + OSCORE request follows six steps: (1) compose EDHOC message_3, (2) establish OSCORE Security Context and encrypt the CoAP request, (3) build COMB_PAYLOAD by concatenating EDHOC_MSG_3 and OSCORE_PAYLOAD, (4) replace the OSCORE request payload with COMB_PAYLOAD (C_R is already in the 'kid' field), (5) include the EDHOC option, and (6) send.
EDHOC connection identifiers C_I and C_R serve directly as the OSCORE Sender/Recipient IDs. C_R is the OSCORE Sender ID of the client and is transported in the 'kid' field of the OSCORE option; in the EDHOC + OSCORE request, it simultaneously serves as both the OSCORE kid and the EDHOC connection identifier C_R for session lookup.
Server processing of an EDHOC + OSCORE request follows nine steps: verify OSCORE option and COMB_PAYLOAD format, extract EDHOC_MSG_3, derive C_R from the OSCORE 'kid' field, retrieve the EDHOC session and process message_3, establish the OSCORE Security Context, extract OSCORE_PAYLOAD, rebuild the OSCORE request, decrypt and verify it, and deliver to the application.
The EDHOC option (CoAP option number 21) signals that a request payload combines EDHOC message_3 and OSCORE-protected data. It is Critical, Safe-to-Forward, part of the Cache-Key, MUST occur at most once, and MUST be empty (length 0). It is Class U for OSCORE and intended only for CoAP requests.
This document defines eight web linking target attributes for EDHOC resource discovery: 'ed-i' (Initiator role supported), 'ed-r' (Responder role supported), 'ed-method' (authentication method), 'ed-csuite' (cipher suite), 'ed-cred-t' (credential type), 'ed-idcred-t' (credential identifier type), 'ed-ead' (EAD item), and 'ed-comb-req' (EDHOC + OSCORE request supported). The target attribute rt="core.edhoc" MUST be included when specifying these parameters.
IANA has created the 'EDHOC Authentication Credential Types' registry within the EDHOC registry group, with initial entries: 0 (CWT with COSE_Key in 'cnf' claim), 1 (CWT Claims Set with COSE_Key in 'cnf' claim), and 2 (X.509 certificate). Registration policy ranges from Private Use to Standards Action with Expert Review based on integer value range.
IANA has registered CoAP option number 21 with the name 'EDHOC' in the 'CoAP Option Numbers' registry within the 'Constrained RESTful Environments (CoRE) Parameters' registry group.
IANA has registered eight target attributes in the 'Target Attributes' registry: ed-i, ed-r, ed-method, ed-csuite, ed-cred-t, ed-idcred-t, ed-ead, and ed-comb-req, all with Change Controller IETF and reference RFC 9668.
Even if a client sends multiple simultaneous EDHOC + OSCORE requests with the same C_R (violating the SHOULD NOT), there is no security impact: the server will not process the same EDHOC message_3 more than once in the same session and will enforce OSCORE replay protection regardless.
The rebuilt OSCORE-protected application request from Step 7 of server processing MUST undergo the same access-control checks that would be performed on a traditional OSCORE-protected request. Validated authorization information must be available at the server before processing begins; successful EDHOC completion alone does not authorize access to the protected resource.
Using the optimized workflow, a minimum of 128-bit security against online brute-force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response. With method 3 and cipher suite 2, this combines 64-bit MACs from EDHOC message_3 and the first OSCORE request/response.
The EDHOC + OSCORE request payload (COMB_PAYLOAD) is the byte concatenation EDHOC_MSG_3 | OSCORE_PAYLOAD, where EDHOC_MSG_3 is the binary encoding of CIPHERTEXT_3 (a CBOR byte string) and OSCORE_PAYLOAD is the OSCORE ciphertext. C_R is not repeated in the payload; it is carried in the 'kid' field of the OSCORE option.