Ephemeral Diffie-Hellman Over COSE (EDHOC)
Extracted elements (30)
EDHOC does not include a dedicated protocol version field. Breaking changes are introduced by specifying and registering new method types, avoiding a version negotiation round trip while still allowing incremental protocol evolution.
EDHOC omits Pre-Shared Key (PSK) authentication because static Diffie-Hellman public key authentication by reference produces equally compact message sizes while offering simpler key distribution and stronger identity protection than PSK.
EDHOC uses the MAC-then-Sign variant of SIGMA-I (the same construction as IKEv2 and TLS 1.3) to provide identity protection for the Initiator against active attacks. SIGMA-I specifically protects the protocol initiator's identity, as the Responder authenticates first in the exchange.
EDHOC always uses Deterministically Encoded CBOR (RFC 8949 Sections 4.2.1 and 4.2.2). Authentication credentials (CRED_I, CRED_R) SHOULD be used without re-encoding, because both endpoints must use bit-for-bit identical credential representations for integrity verification (via MAC fields) to succeed.
EDHOC is transport-agnostic and can be used without IP. Reliable transport such as CoAP in reliable mode is RECOMMENDED. If message correlation is not provided by the transport, the binding SHOULD mandate prepending C_I or C_R; if message_1 cannot be identified by other means, prepending the CBOR simple value true (0xf5) is RECOMMENDED.
After sending an error message the sender MUST abort the EDHOC session. Error messages in EDHOC are always fatal. Error code 0 MUST NOT be used in the message exchange; if received, the endpoint MUST abort the session and MUST NOT reply with another error.
Different instances of the same EDHOC message MUST NOT be processed in one EDHOC session. Message deduplication MUST be done by the transport protocol or, if not supported, as described in Section 7 (explicit deduplication).
If an endpoint receives a critical EAD item it does not recognize, or that it cannot process, it MUST send an EDHOC error message back and MUST abort the EDHOC session. Non-critical EAD items may be ignored.
In deployments where no protected application message is sent from Responder to Initiator, message_4 MUST be supported and MUST be used to provide key confirmation to the Initiator.
The EAD fields of EDHOC MUST only be used with registered EAD items from the EDHOC External Authorization Data Registry. The compact encoding for ID_CRED_x containing only a 'kid' parameter MUST be applied if and only if ID_CRED_x = {4: kid_x} and ID_CRED_x appears in PLAINTEXT_y.
The EDHOC MAC length in a cipher suite MUST be at least 8 bytes.
The Initiator MUST NOT change its order of preference for cipher suites and MUST NOT omit a cipher suite preferred over the selected one due to prior error messages, preventing downgrade attacks on cipher suite negotiation.
The Initiator SHOULD NOT persistently store PRK_out or application keys until it has verified message_4 or a message protected with a derived application key from the Responder. The Initiator SHOULD NOT send protected application data until the application has authenticated the Responder.
When EDHOC is used to establish OSCORE keys, the Initiator and Responder MUST NOT select connection identifiers that result in the same OSCORE Recipient ID, because connection identifiers map directly to OSCORE Recipient IDs.
An EDHOC cipher suite specifies: EDHOC AEAD algorithm, EDHOC hash algorithm, EDHOC MAC length in bytes (for static DH authentication), EDHOC key exchange algorithm (ECDH curve), EDHOC signature algorithm, application AEAD algorithm, and application hash algorithm. Each suite has an integer label.
Connection identifiers (C_I, C_R) are byte strings, but values coinciding with one-byte CBOR-encoded integers (-24 to 23) MUST be represented as those integers on the wire rather than as CBOR byte strings, enabling 1-byte overhead. Other byte strings use normal CBOR bstr encoding.
EDHOC defines four authentication method types (0–3) combining signature keys and static Diffie-Hellman keys for the Initiator and Responder. Method 0 uses signature keys for both parties; method 3 uses static DH keys for both; methods 1 and 2 are mixed. Value 23 is reserved.
External Authorization Data (EAD) items consist of an ead_label (int) and optional ead_value (bstr). A negative ead_label marks the item as critical; nonnegative marks it as non-critical. EAD_1 through EAD_4 appear in the corresponding EDHOC messages. ead_label = 0 is reserved for padding.
Key derivation uses EDHOC_Extract (HKDF-Extract or KMAC) and EDHOC_Expand (HKDF-Expand or KMAC) to produce PRK_2e from G_XY and TH_2, PRK_3e2m (optionally incorporating G_RX for static DH Responder), PRK_4e3m (optionally incorporating G_IY for static DH Initiator), and PRK_out = EDHOC_KDF(PRK_4e3m, 7, TH_4, hash_length).
The EDHOC_Exporter interface derives application keying material as EDHOC_Exporter(exporter_label, context, length) = EDHOC_KDF(PRK_exporter, exporter_label, context, length), where PRK_exporter = EDHOC_KDF(PRK_out, 10, h'', hash_length). The (exporter_label, context) pair MUST be unique per purpose.
IANA created the EDHOC Cipher Suites Registry with integer labels for predefined suites (0–6, 24–25), each specifying AEAD, hash, MAC length, key exchange, signature, and application algorithms. Private suites use labels -24, -23, -22, -21.
IANA created the EDHOC Method Type Registry (integer values 0–3 defined, 23 reserved), EDHOC Error Codes Registry (codes 0–3 and 23 defined), EDHOC External Authorization Data Registry (for ead_label absolute values), and EDHOC Exporter Label Registry. Two new COSE header parameters ('kcwt', 'kccs') were registered.
EDHOC does not currently provide post-quantum security for static DH authentication methods (1–3). A post-quantum KEM can replace ECDH in method 0, but supporting PQC for static DH authentication would require new method specifications extending EDHOC.
EDHOC is susceptible to denial-of-service attacks because the Responder must allocate state before authenticating the Initiator. Implementations MUST use available DoS mitigation such as puzzle mechanisms. Padding in EAD_1 mitigates amplification attacks by equalizing request/response sizes.
EDHOC provides identity protection for the Initiator against active attackers via the SIGMA-I design; the Responder's identity is protected against passive attackers only. Unprotected data in message_1 (METHOD, SUITES_I, G_X, C_I, EAD_1) is visible to observers and may reveal information about endpoints and supported capabilities.
EDHOC error messages are CBOR Sequences with ERR_CODE (int; 0 reserved for success, all other values indicate errors) and ERR_INFO (type depends on error code). Error code 1 uses a text string; error code 2 uses suites; error code 3 uses the value true.
message_1 is a CBOR Sequence containing METHOD (int), SUITES_I (int or array of ints listing cipher suites in preference order), G_X (bstr, Initiator's ephemeral public key 'x' coordinate), C_I (bstr or int -24..23), and optional EAD_1.
message_2 is a single CBOR bstr field G_Y_CIPHERTEXT_2, which is the concatenation of G_Y (Responder's ephemeral public key) and CIPHERTEXT_2. CIPHERTEXT_2 is PLAINTEXT_2 XOR KEYSTREAM_2, where PLAINTEXT_2 = (C_R, ID_CRED_R, Signature_or_MAC_2, optional EAD_2).
message_3 is a CBOR Sequence containing a single bstr field CIPHERTEXT_3, the ciphertext of a COSE_Encrypt0 protecting PLAINTEXT_3 = (ID_CRED_I, Signature_or_MAC_3, optional EAD_3), encrypted with key K_3 and IV_3 derived from PRK_3e2m.
message_4 is a CBOR Sequence containing a single bstr field CIPHERTEXT_4, a COSE_Encrypt0 ciphertext with external_aad = TH_4 and PLAINTEXT_4 = (optional EAD_4), providing key confirmation from Responder to Initiator.