Ephemeral Diffie-Hellman Over COSE (EDHOC)

Ephemeral Diffie-Hellman Over COSE (EDHOC) Ericsson AB

Farogatan 6 Kista SE-16480 Stockholm Sweden goran.selander@ericsson.com

Ericsson AB

Farogatan 6 Kista SE-16480 Stockholm Sweden john.mattsson@ericsson.com

Ericsson AB

Farogatan 6 Kista SE-16480 Stockholm Sweden francesca.palombini@ericsson.com

Applications ACE Working Group Internet-Draft This document specifies authenticated Diffie-Hellman key exchange with ephemeral keys, embedded in messages encoded with CBOR and using the CBOR Object Signing and Encryption (COSE) format.

Security at the application layer provides an attractive option for protecting Internet of Things (IoT) deployments, for example where transport layer security is not sufficient . IoT devices may be constrained in various ways, including memory, storage, processing capacity, and energy . A method for protecting individual messages at application layer suitable for constrained devices, is provided by COSE ), which builds on CBOR . In order for a communication session to provide forward secrecy, the communicating parties can run a Diffie-Hellman (DH) key exchange protocol with ephemeral keys, from which shared key material can be derived. This document specifies authenticated DH protocols using CBOR and COSE objects. The DH key exchange messages may be authenticated using either pre-shared keys (PSK), raw public keys (RPK) or X.509 certificates (Cert). Authentication is based on credentials established out of band, or from a trusted third party, such as an Authorization Server as specified by . This document also specifies the derivation of shared key material. The DH exchange and the key derviation follow , SP-800-56a and HKDF , and make use of the data structures of COSE which are aligned with these standards.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in . These words may also appear in this document in lowercase, absent their normative meanings. The parties exchanging messages are called “party U” and “party V”, and the ECDH ephemeral public keys of U and V are denoted “E_U” and “E_V”, respectively. The messages in the authenticated message exchange are called “message_1”, “message_2”, and “message_3”. TBD

This section gives an overview of EDHOC, together with and , which explains how the messages are processed, while and focus on the detailed message formats embedded as CBOR objects, and , , and specify the key derivation. EDHOC is built on the SIGMA family of protocols, with the basic protocol specified in Section 5, here in variant (ii) as in Section 5.4, of , see .

| | | | E_V, ID_V, Sig(V; Mac(Km; E_U, E_V, ID_V)) | |<------------------------------------------------------+ | | | ID_U, Sig(U; Mac(Km; E_V, E_U, ID_U)) | +------------------------------------------------------>| | | ]]> U and V exchange identities and ephemeral public keys E_U, E_V. They compute the shared secret and derive the keying material. The messages are signed and MAC:ed according to the SIGMA protocol: Mac(Km; . ) denote message authentication using keys derived from the shared secret Sig(U; . ) and Sig(V; . ) denote signatures made with the private key of U and V, respectively. ID_U and ID_V are used to identify U and V, respectively. In case of public key certificate, C_U and C_V are used instead. The protocol used with PSK is based on the basic SIGMA protocol. The underlying scheme for asymmetric keys is the SIGMA-I protocol as specified in Section 5.2, with variant (ii) in Section 5.4, of , see . This protocol adds encryption which is required for identity protection in the asymmetric key case: Enc(Ke; .) denote encryption using keys derived from the shared secret

| | | | E_V, Enc(Ke; ID_V, Sig(V; Mac(Km; E_U, E_V, ID_V))) | |<------------------------------------------------------+ | | | Enc(Ke; ID_U, Sig(U; Mac(Km; E_V, E_U, ID_U))) | +------------------------------------------------------>| | | ]]> The protocols are detailed further in the following sections.

This section defines the formatting of the ephemeral public keys E_U and E_V. The ECDH ephemeral public key SHALL be formatted as a COSE_Key with the following fields and values (see ): kty: The value SHALL be 2 (Elliptic Curve Keys) kid: crv: The value of the Curve used. The value 1 SHALL be supported by party V (NIST P-256 a.k.a. secp256r1 ) x: y: The value SHOULD be boolean. TODO: Consider replacing P-256 with Curve25519 as mandatory

In this section we assume that the protocol messages are authenticated with asymmetric keys. Both the scenarios where the parties use raw public keys (RPK) and X.509 certificates (Cert) are supported. Party U’s public key SHALL be uniquely identified at V by ID_U. Party V’s public key SHALL be uniquely identified at U by ID_V. ID_U and ID_V may be public key certificates , which we then denote as C_U and C_V, respectively. The pre-established credentials may thus be the public keys of U at V, and of V at U. Alternatively, a pre-established public key of a Certificate Authority (CA) may be used as trust anchor for verification of received certificate. The protocol is based on SIGMA-I (). As described in Appendix B of , in order to create a “full-fledge” protocol some additional protocol elements are needed: Explicit freshness nonces/session identifiers N_U, N_V chosen freshly and anew with each session by U and V, respectively Computationally independent keys K_UE, K_UM, K_VE, K_VM derived from the DH-shared secret and used for different directions and operations. EDHOC makes the following additions to this scheme (see ): Negotiation of algorithms used: AEAD-, signature- and MAC-algorithm used in the protocol, and ECDH ES w/ HKDF algorithm used in the key derivation: U proposes one or more algorithms (Alg_U). V decides and responds with selected algorithms (Alg_V). Subsequent traffic is protected with the AEAD agreed in this negotiation.

| | message_1 | | | | | | N_U, N_V, E_V, Alg_V, Enc(K_VE; ID_V, Sig(V; Mac(K_VM; prot_2)))| | <---------------------------------------------------------------+ | message_2 | | | | | | N_U, N_V, Enc(K_UE; ID_U, Sig(U; Mac(K_UM; prot_3))) | +---------------------------------------------------------------> | | message_3 | | | where prot_2 = N_U, N_V, E_V, Alg_V, ID_V and prot_3 = N_U, N_V, E_U, Alg_U, ID_U ]]>

This section details the format for the objects used. Examples are provided for each object in . Note that * identifies fields that do not exist in COSE structures (), and are thus defined in this document.

This section defines the formatting of message_1. message_1 is a CBOR array object containing: N_U: nonce E_U: the ephemeral public key of Party U ECDH_arr: an array of proposed ECDH ES w/ HKDF algorithms AEAD_arr: an array of proposed AEAD algorithms SIG_arr: an array of proposed Signature algorithms MAC_arr: an array of proposed MAC algorithms

In case of asymmetric keys, message_2 SHALL have the COSE_Encrypt structure with the following fields and values: Headers: protected: alg: AEAD, the Authenticated Encryption with Additional Data algorithm chosen by Party V from the set of proposed algorithms AEAD_arr unprotected: nonces*: nonce-array ciphertext: over the plaintext defined below recipient: Headers: protected: ECDH-ES + HKDF algorithm chosen by Party V from the set of proposed algorithms ECDH_arr (table 18 in ) unprotected: E_V: COSE_Key ciphertext: empty

The plaintext for message_2 SHALL have the COSE_Sign1 structure with the following fields and values: Headers protected alg: SIG, the Sign algorithm chosen by Party V from the set of proposed algorithms SIG_arr MAC-alg*: MAC, the MAC algorithm chosen by Party V from the set of proposed algorithms MAC_arr Unprotected: kid: ID_V (if raw public keys are used) or x5c*: C_V (if certificates are used) detached payload: as defined below signature: computed as in Section 4.4 of The payload for COSE_Sign1 SHALL have the COSE_MAC0 structure with the following fields and values: Headers protected alg: MAC (same value as MAC-alg in COSE_Sign1 structure above) unprotected: empty payload: payl_2_rpk (resp payl_2_cert) as defined below if raw public keys (resp certificates) are used tag

In case of asymmetric keys, message_3 SHALL have the COSE_Encrypt0 structure with the following fields and values: Headers: protected: alg: AEAD unprotected: nonces*: nonce-array ciphertext: over the plaintext defined below The plaintext for message_3 SHALL have the COSE_Sign1 structure with the following fields and values: Headers protected alg: SIG MAC-alg*: MAC Unprotected: kid: ID_U (if raw public keys are used) or x5c*: C_U (if certificates are used) detached payload: as defined below signature: computed as in Section 4.4 of The payload for COSE_Sign1 SHALL have the COSE_MAC0 structure with the following fields and values: Headers protected alg: MAC (same value as MAC-alg in COSE_Sign1 structure above) unprotected: empty payload: payl_3_rpk (resp payl_3_cert) as defined below if raw public keys (resp certificates) are used tag

It is described in this section how the keys for encryption (K_UE, K_VE) and MAC (K_UM, K_VM) are derived. Party U and Party V SHALL derive K_UE, K_VE, K_UM, and K_VM from the information available in message_1 and message_2 through the key exchange, as described in this section. The key derivation is identical to Section 11 of , using HKDF agreed as part of the ECDH ES w/ HKDF negociation during the message exchange. the secret SHALL be the ECDH shared secret as defined in Section 12.4.1 of , where the computed secret is specified in section 5.7.1.2 of the salt SHALL be the concatenation of N_U and N_V. the length SHALL be the length of the key, depending on the algorithm used. the context information SHALL be the serialized COSE_KDF_Context defined in the next paragraph. the PRF SHALL be the one indicated in HKDF using the Table 18 of (in our examples, -27 corresponds to HMAC with SHA-256) The context information COSE_KDF_Context is defined as follows: AlgorithmID SHALL be the algorithm for which the key material will be derived. It’s value is AEAD (to derive K_UE and K_VE) or MAC (to derive K_UM and K_VM) PartyUInfo SHALL contain: nonce SHALL be equal to N_U PartyVInfo SHALL contain: nonce SHALL be equal to N_V identity SHALL be ID_V (resp C_V) if raw public keys (resp. certificates) are used SuppPubInfo SHALL contain: KeyDataLength SHALL be equal to ‘length’ protected SHALL be a zero length bstr other SHALL contain the HMAC (as defined by the agreed HKDF) of the concatenation of message_1, the COSE Headers of COSE_Encrypt (message_2) and the string “PartyU” (resp “PartyV”) to derive K_UE or K_UM (resp K_VE or K_VM) SuppPrivInfo SHALL be empty The key derivation is done using the following context information COSE_KDF_Context for asymmetric keys:

Using the different combination of these parameters creates the four keys K_UE, K_UM, K_VE and K_VM when raw public keys or certificates are used. For example, to derive K_UE while asymmetric keys are used, the context MUST include: AEAD as Algorithm ID “PartyU” as the chosen string in SuppPubInfo other

Party U and V are assumed to have pre-established credentials as described in .

Party U processes message_1 for party V as follows: Party U SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of using ECC domain parameters of a curve complying with security policies for communicating with party V. The ephemeral public key, E_U, SHALL be formatted as a COSE_key as specified in . Party U SHALL generate a pseudo-random 64-bits nonce N_U and store it for the length of the protocol, for future verifications. Party U SHALL set the proposed algorithms for communicating with party V. Party U SHALL format message_1 as specified in . Party U sends message_1 to party V.

Party V processes the received message_1 as follows: Party V SHALL verify that the nonce has not been received before. If the verification fails, the message MUST be discarded. Otherwise, Party V SHALL store a representation of the nonce for future verifications. Party V SHALL select a set of algorithms (AEAD, SIG, MAC, and ECDH-ES) compliant with its security policy for communicating with U. If no compliant algorithm was proposed by Party U, Party V SHALL stop processing the message and MAY respond with an error, indicating that no common algorithm could be found.

Party V composes message_2 for party U as follows: Party V SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of using same curve/ECC domain parameters as used by party U. The ephemeral public key, E_V, SHALL be formatted as a COSE_key as specified in . Party V SHALL generate a pseudo-random 64-bits nonce N_V and store it for the length of the protocol, for future verifications. Party V SHALL derive K_UE, K_VE, K_UM and K_VM as defined in . Party V SHALL format message_2 as specified in : COSE_MAC0 is computed as defined in section 6.3 of , with key K_VM and algorithm MAC; COSE_Sign1 is computed as defined in section 4.4 of , using the private key of Party V and algorithm SIG; COSE_Encrypt is computed as defined in section 5.3 of , with key K_VE and algorithm AEAD. Note that the COSE_Sign1 payload is detached (as defined in section 4.1 of ). Note that in case of certificates, the certificate of Party V, C_V, is sent in place of ID_V Party V sends message_2 to party U.

Party U processes the received message_2 as follows: Party U SHALL verify than the received N_U is identical to the saved nonce N_U. Party U SHALL verify that the nonce has not been received before. If the verification fails, the message MUST be discarded. Otherwise, Party U SHALL store a representation of the nonce for future verifications. Party U SHALL derive K_UE, K_VE, K_UM and K_VM as defined in . Party U SHALL verify message_2: COSE_Encrypt is decrypted and verified as defined in section 5.3 of , with key K_VE. If the message contains a certificate, party U SHALL verify the certificate using the pre-established trust anchor and the revokation verification policies relevant for party U. If the verification fails the message is discarded. COSE_MAC0 is computed as defined in section 6.3 of , with key K_VM. The result is inserted as payload of the received COSE_Sign1 (which was sent with detached payload); COSE_Sign1 is verified as defined in section 4.4 of , using the public key of Party V; Note that Party U SHALL verify that the algorithms used in message_2 are taken from the set of proposed algorithms in message_1, else stop processing the message. If the verification of message_2 fails, the message MUST be discarded and Party U SHALL discontinue the protocol.

Party U composes message_3 for party V as follows: Party U SHALL format message_3 as specified in : COSE_MAC0 is computed as defined in section 6.3 of , with key K_UM and algorithm MAC; COSE_Sign1 is computed as defined in section 4.4 of , using the private key of Party U and algorithm SIG; COSE_Encrypt is computed as defined in section 5.3 of , with key K_UE and algorithm AEAD. Note that the COSE_Sign1 payload is detached (as defined in section 4.1 of ). Note that in case of certificates, the certificate of Party U, C_U, is sent in place of ID_U Party U sends message_3 to party V.

Party V processes the received message_3 as follows: Party V SHALL verify than the received N_V is identical to the saved nonce N_V. If the verification fails, the message MUST be discarded. Party U SHALL verify message_3: COSE_Encrypt is decrypted and verified as defined in section 5.3 of , with key K_UE. If the message contains a certificate, party U SHALL verify the certificate using the pre-established trust anchor and the revokation verification policies relevant for party U. If the verification fails the message is discarded. COSE_MAC0 is computed as defined in section 6.3 of , with key K_UM. The result is inserted as payload of the received COSE_Sign1 (which was sent with detached payload); COSE_Sign1 is verified as defined in section 4.4 of , using the public key of Party U; Note that Party V SHALL verify that the set of algorithms sent in message_3 is the same as sent in message_1, else stop processing the message. If the verification of message_3 fails, the message MUST be discarded and Party U SHALL discontinue the protocol.

In this section we assume that the protocol messages are authenticated with pre-shared symmetric keys. Parties U and V are assumed to have a pre-shared uniformly random key, PSK. The value of the key identifier kid_psk SHALL be unique for U and V. The protocol is based on the basic SIGMA protocol (), but the signatures Sig(U; . ), Sig(V; . ) are replaced with message authentication codes MAC(K_UMP; . ), MAC(K_VMP; . ), respectively. K_UMP and K_VMP are computationally independent keys, associated to U and V, respectively, and derived from PSK. Also, party U needs to send kid_psk in message_1 to indicate what PSK that V should use (kid_psk). In this case identity protection is achieved by anonymizing the kid_psk (). For a specific pre-shared key (and corresponding kid-psk): Party U SHALL be identified by ID_U. Party V SHALL be identified by ID_V. Since kid-psk is unique, only one additional pre-established bit is needed to identify the parties. As in the asymmetric case, some additional protocol elements are added to the final protocol: Explicit freshness nonces/session identifiers N_U, N_V chosen freshly and anew with each session by U and V, respectively Computationally independent keys K_UM, K_VM derived from the DH-shared secret and used for different directions and operations. Negotiation of algorithms: MAC-algorithm used in the protocol HKDF with hash algorithm used in the key derivation AEAD-algorithm used to protect subsequent traffic U proposes one or more algorithms (Alg_U). V decides and responds with selected algorithms (Alg_V).

| | message_1 | | | | | | N_U, N_V, E_V, Kid, ID_V, Alg_V, Mac(K_VMP; Mac(K_VM; prot_2)) | | <---------------------------------------------------------------+ | message_2 | | | | | | N_U, N_V, Kid, ID_U, Mac(K_UMP; Mac(K_UM; prot_3)) | +---------------------------------------------------------------> | | message_3 | | | where prot_2 = N_U, N_V, E_V, Kid, ID_V, Alg_V and prot_3 = N_U, N_V, E_U, Kid, ID_U, Alg_U ]]>

This section defines the formatting of message_1. message_1 is a CBOR array object containing: N_U: nonce E_U: the ephemeral public key of Party U kid_psk: identifier of the pre-shared key ECDH_arr: an array of proposed ECDH ES w/ HKDF algorithms AEAD_arr: an array of proposed AEAD algorithms MAC_arr: an array of proposed MAC algorithms

In case of pre-shared key, message_2 SHALL have the COSE_MAC structure with the following fields and values: Headers: protected: alg: MAC unprotected: nonces*: nonce-array kid: kid_psk sid*: ID_V AEAD-alg*: AEAD detached payload: defined below tag: calculated as in section 6.3 of recipient: Headers: protected: ECDH-ES + HKDF algorithm chosen by Party V from the set of proposed algorithms ECDH_arr (table 18 in ) unprotected: E_U: COSE_Key ciphertext: empty

The payload for message_2 SHALL have the COSE_MAC0 structure with the following fields and values: Headers protected alg: MAC (same value as MAC in COSE_MAC structure above) unprotected: empty payload: payl_2_psk as defined below tag: calculated as in section 6.3 of

In case of symmetric keys, message_3 SHALL have the COSE_MAC0 structure with the following fields and values: Headers: protected: alg: MAC unprotected: nonces*: nonce-array kid: kid_psk sid*: ID_U detached payload: defined below tag: calculated as in section 6.3 of The payload for message_3 SHALL have the COSE_MAC0 structure with the following fields and values: Headers protected alg: MAC (same value as in COSE_MAC0 structure above) unprotected: empty payload: payl_3_psk as defined below tag: calculated as in section 6.3 of

It is described in this section how the keys for MAC (K_UM, K_VM, K_UMP, K_VMP) are derived. Party U and Party V SHALL derive K_UM, K_VM, K_UMP and K_VMP from the information available in message_1 and message_2 through the key exchange, as described in this section. The key derivation is identical to , with 3 differences: * to derive K_UM and K_VM, the secret SHALL be the ECDH shared secret as defined in Section 12.4.1 of , where the computed secret is specified in section 5.7.1.2 of * to derive K_UMP and K_VMP, the secret SHALL be the pre-shared key * The COSE_KDF_Context SHALL be the serialized COSE_KDF_Context defined in the next paragraph. The context information COSE_KDF_Context is defined as follows: AlgorithmID SHALL be the algorithm for which the key material will be derived. It’s value is MAC. PartyUInfo SHALL contain: nonce SHALL be equal to N_U PartyVInfo SHALL contain: nonce SHALL be equal to N_U SuppPubInfo SHALL contain: KeyDataLength SHALL be equal to ‘length’ protected SHALL be a zero length bstr other SHALL contain the HMAC (as defined by the agreed HKDF) of the concatenation of message_1, the COSE Headers of message_2 and the string “PartyU” (resp “PartyV”) to derive K_UM or K_UMP (resp K_VM or K_VMP) SuppPrivInfo SHALL be empty The key derivation is done using the following context information COSE_KDF_Context for asymmetric keys:

In practice, the difference in deriving K_UM or K_VM is in the SuppPubInfo string: to derive K_UM the context MUST include “PartyU”, while to derive K_VM the context MUST include “PartyV”.

Party U and V are assumed to have pre-established credentials as described in .

Party V processes the received message_1 as follows: Party V SHALL verify that the nonce has not been received before. If the verification fails, the message MUST be discarded. Otherwise, Party V SHALL store a representation of the nonce for future verifications. Party V SHALL select a set of algorithms (AEAD, MAC, and ECDH-ES) compliant with its security policy for communicating with U. If no compliant algorithm was proposed by Party U, Party V SHALL stop processing the message and MAY respond with an error, indicating that no common algorithm could be found.

Party V composes message_2 for party U as follows: Party V SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of using same curve/ECC domain parameters as used by party U. The ephemeral public key, E_V, SHALL be formatted as a COSE_key as specified in . Party V SHALL generate a pseudo-random 64-bits nonce N_V and store it for the length of the protocol, for future verifications. Party V SHALL derive K_UM, K_VM, K_UMP and K_VMP as defined in . Party V SHALL format message_2 as specified in : COSE_MAC0 is computed as defined in section 6.3 of , with key K_VM and algorithm MAC; COSE_MAC is computed as defined in section 6.3 of , with key K_VMP and algorithm MAC. Note that the COSE_MAC payload is detached (as defined in section 6.1 of ). Party V sends message_2 to party U.

Party U processes the received message_2 as follows: Party U SHALL verify than the received N_U is identical to the saved nonce N_U. Party U SHALL verify that the nonce has not been received before. If the verification fails, the message MUST be discarded. Otherwise, Party U SHALL store a representation of the nonce for future verifications. Party U SHALL derive K_UM, K_VM, K_UMP and K_VMP as defined in . Party U SHALL verify message_2: COSE_MAC0 is computed as defined in section 6.3 of , with key K_VM. The result is inserted as payload of the received COSE_MAC (which was sent with detached payload); COSE_MAC is verified as defined in section 6.3 of , with key K_VMP and algorithm MAC; Note that Party U SHALL verify that the MAC algorithm used and the AEAD algorithm sent in message_2 are taken from the set of proposed algorithms in message_1, else stop processing the message. If the verification of message_2 fails, the message MUST be discarded and Party U SHALL discontinue the protocol.

Party U composes message_3 for party V as follows: Party U SHALL format message_3 as specified in : COSE_MAC0 (containing payl_3_psk) is computed as defined in section 6.3 of , with key K_UM and algorithm MAC; COSE_MAC0 is computed as defined in section 6.3 of , with key K_UMP and algorithm MAC. Note that the second COSE_MAC0 payload is detached (as defined in section 6.1 of ). Party U sends message_3 to party V.

It is described in this section how the traffic secret for further communication is derived, based on the messages exchanged. Party U and Party V SHALL derive the traffic secret (base_key) from the information available in message_1, message_2 and message_3 through the key exchange, as described in this section. The key derivation is identical to Section 11 of , using HKDF agreed as part of the ECDH ES w/ HKDF negociation during the message exchange. the secret SHALL be the ECDH shared secret as defined in Section 12.4.1 of , where the computed secret is specified in section 5.7.1.2 of the salt SHALL be the concatenation of N_U and N_V. the length SHALL be the length of the key, depending on the AEAD algorithm with which the base_key will be used. the context information SHALL be the serialized COSE_KDF_Context defined in the next paragraph. the PRF SHALL be the one indicated in HKDF using the Table 18 of (in our examples, -27 corresponds to HMAC with SHA-256) The context information COSE_KDF_Context is defined as follows: AlgorithmID SHALL be the AEAD algorithm for which the key material will be derived. PartyUInfo SHALL contain: nonce SHALL be equal to N_U identity SHALL be ID_U (resp C_U) if raw public keys (resp. certificates) are used PartyVInfo SHALL contain: nonce SHALL be equal to N_V identity SHALL be ID_V (resp C_V) if raw public keys (resp. certificates) are used SuppPubInfo SHALL contain: KeyDataLength SHALL be equal to ‘length’ protected SHALL be a zero length bstr other SHALL contain the HMAC (as defined by the agreed HKDF) of the concatenation of message_1, message_2 and message_3. SuppPrivInfo SHALL be empty The key derivation is done using the following context information COSE_KDF_Context:

An example of key derivation for the traffic secret is given in TODO.

The referenced processing instructions in must be complied with, including deleting the intermediate computed values along with any ephemeral ECDH secrets after the key derivation is completed. The choice of key length used in the different algorithms needs to be harmonized, so that right security level is maintained throughout the calculations. TODO: Expand on the security considerations in a future version of the draft

TODO

The authors wants to thank Ilari Liusvaara, Jim Schaad and Ludwig Seitz for reviewing previous versions of the draft.

&RFC7049; &I-D.ietf-cose-msg; &RFC2119; Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography SIGMA - The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE-Protocols &I-D.hartke-core-e2e-security-reqs; &I-D.ietf-ace-oauth-authz; &I-D.ietf-core-object-security; &RFC4492; &RFC7228; &RFC7252; &RFC5869;

An example of COSE_Key structure, representing an ECDH public key, is given in , using CBOR’s diagnostic notation. In this example, the ephemeral key is identified by a 4 bytes ‘kid’.

The equivalent CBOR encoding is: h’a120a50102024478f67901200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5’, which has a size of 51 bytes. More examples TBD

The DH key exchange specified in this document can be implemented as a CoAP message exchange with the CoAP client as party U and the CoAP server as party V. EDHOC and OSCOAP could be run in sequence embedded in a 2-round trip message exchange, where the base_key used in OSCOAP is obtained from EDHOC. A strawman is sketched here. The CoAP client makes the following request: The request method is POST Content-Format is “application/cose+cbor” The Uri-Path is “edhoc” The Payload is message_1 The CoAP server performs the verifications of the protocol as specified in this document. If successful, then the server provides the following response: The response Code is 2.04 (Changed) The Payload is message_2 The CoAP client verifies the message_2 as specified in this document. If successful, the client generates the OSCOAP request, and includes message_3 in the unprotected part of the COSE Headers of the OSCOAP COSE object.