One document matched: draft-selander-ace-cose-ecdhe-04.xml
<?xml version="1.0" encoding="us-ascii"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7049 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7049.xml">
<!ENTITY I-D.ietf-cose-msg SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cose-msg.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.hartke-core-e2e-security-reqs SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.hartke-core-e2e-security-reqs.xml">
<!ENTITY I-D.ietf-ace-oauth-authz SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ace-oauth-authz.xml">
<!ENTITY I-D.ietf-core-object-security SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-object-security.xml">
<!ENTITY I-D.seitz-ace-oscoap-profile SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.seitz-ace-oscoap-profile.xml">
<!ENTITY RFC4492 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY RFC7228 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
<!ENTITY RFC7252 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY RFC5869 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-selander-ace-cose-ecdhe-04" category="std">
<front>
<title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
<author initials="G." surname="Selander" fullname="Goeran Selander">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>Kista</city>
<code>SE-16480 Stockholm</code>
<country>Sweden</country>
</postal>
<email>goran.selander@ericsson.com</email>
</address>
</author>
<author initials="J." surname="Mattsson" fullname="John Mattsson">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>Kista</city>
<code>SE-16480 Stockholm</code>
<country>Sweden</country>
</postal>
<email>john.mattsson@ericsson.com</email>
</address>
</author>
<author initials="F." surname="Palombini" fullname="Francesca Palombini">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>Kista</city>
<code>SE-16480 Stockholm</code>
<country>Sweden</country>
</postal>
<email>francesca.palombini@ericsson.com</email>
</address>
</author>
<date year="2016" month="October" day="31"/>
<area>Applications</area>
<workgroup>ACE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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 <xref target="I-D.hartke-core-e2e-security-reqs"/>. IoT devices may be constrained in various ways, including memory, storage, processing capacity, and energy <xref target="RFC7228"/>. A method for protecting individual messages at application layer suitable for constrained devices, is provided by COSE <xref target="I-D.ietf-cose-msg"/>), which builds on CBOR <xref target="RFC7049"/>.</t>
<t>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 <xref target="I-D.ietf-ace-oauth-authz"/>. Note that this document focuses on authentication and key establishment: for integration with authorization of resource access, refer to <xref target="I-D.seitz-ace-oscoap-profile"/>. This document also specifies the derivation of shared key material.</t>
<t>The DH exchange and the key derviation follow <xref target="SIGMA"/>, NIST SP-800-56a <xref target="SP-800-56a"/> and HKDF <xref target="RFC5869"/>, and make use of the data structures of COSE which are aligned with these standards.</t>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>. These
words may also appear in this document in lowercase, absent their
normative meanings.</t>
</section>
</section>
<section anchor="protocol" title="Protocol Overview">
<t>This section gives an overview of EDHOC, together with <xref target="mess-proc"/> and <xref target="mess-proc-sym"/>, which explains how the messages are processed, while <xref target="asym"/> and <xref target="sym"/> focus on the detailed message formats embedded as CBOR objects, and <xref target="key-der-asym"/>, <xref target="key-der-sym"/>, and <xref target="final-key-der"/> specify the key derivation.</t>
<t>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 <xref target="SIGMA"/>, see <xref target="mess-ex0"/>.</t>
<figure title="The basic SIGMA protocol" anchor="mess-ex0"><artwork align="center"><![CDATA[
Party U Party V
| |
| |
| E_U |
+------------------------------------------------------>|
| |
| 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)) |
+------------------------------------------------------>|
| |
]]></artwork></figure>
<t>The parties exchanging messages are called “U” and “V”. U and V exchange identities and ephemeral public keys. They compute the shared secret and derive the keying material. The messages are signed and MAC:ed according to the SIGMA protocol (<xref target="mess-ex0"/>):</t>
<t><list style="symbols">
<t>E_U and E_V are the ECDH ephemeral public keys of U and V, respectively.</t>
<t>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.</t>
<t>Sig(U; . ) and Sig(V; . ) denote signatures made with the private key of U and V, respectively.</t>
<t>Mac(Km; . ) denote message authentication using keys derived from the shared secret</t>
</list></t>
<t>EDHOC used with symmetric keys is based on the basic SIGMA protocol. The underlying scheme for EDHOC using asymmetric keys is the SIGMA-I protocol as specified in Section 5.2, with variant (ii) in Section 5.4, of <xref target="SIGMA"/>, see <xref target="mess-ex"/>. This protocol adds encryption which is required for identity protection in the asymmetric key case:</t>
<t><list style="symbols">
<t>Enc(Ke; .) denote encryption using keys derived from the shared secret</t>
</list></t>
<figure title="The SIGMA-I protocol" anchor="mess-ex"><artwork align="center"><![CDATA[
Party U Party V
| |
| |
| E_U |
+------------------------------------------------------>|
| |
| 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))) |
+------------------------------------------------------>|
| |
]]></artwork></figure>
<t>The protocols are detailed further in the following sections.</t>
<!--# Message formatting using COSE # {#mess-format}
This section details the format for the objects used. Examples are provided for each object in {{examples}}. -->
</section>
<section anchor="COSE_key" title="ECDH Public Keys using COSE_Key">
<t>This section defines the formatting of the ephemeral public keys E_U and E_V.</t>
<t>The ECDH ephemeral public key SHALL be formatted as a COSE_Key with the following fields and values (see <xref target="I-D.ietf-cose-msg"/>):</t>
<t><list style="symbols">
<t>kty: The value SHALL be 2 (Elliptic Curve Keys)</t>
<t>crv: The value of the Curve used.</t>
<t>x:</t>
<t>y: The value SHOULD be boolean.</t>
</list></t>
<t>For the field ‘crv’, refer to Table 22 of <xref target="I-D.ietf-cose-msg"/>. The value 1 MUST be supported by party V (NIST P-256 a.k.a. secp256r1 <xref target="RFC4492"/>).</t>
<t>TODO: Consider replacing P-256 with Curve25519 as mandatory</t>
</section>
<section anchor="asym-keys-intro" title="Asymmetric Keys">
<t>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.</t>
<t><list style="symbols">
<t>Party U’s public key SHALL be uniquely identified at V by ID_U.</t>
<t>Party V’s public key SHALL be uniquely identified at U by ID_V.</t>
</list></t>
<t>ID_U and ID_V may be public key certificates <xref target="SIGMA"/>, which we then denote as C_U and C_V, respectively.</t>
<t>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.</t>
<t>The protocol is based on SIGMA-I (<xref target="protocol"/>). As described in Appendix B of <xref target="SIGMA"/>, in order to create a “full-fledge” protocol some additional protocol elements are needed:</t>
<t><list style="symbols">
<t>Explicit freshness nonces/session identifiers N_U, N_V chosen freshly and anew with each session by U and V, respectively</t>
<t>Computationally independent keys K_UE, K_UM, K_VE, K_VM derived from the DH-shared secret and used for different directions and operations.</t>
</list></t>
<t>EDHOC makes the following additions to this scheme (see <xref target="mess-ex2"/>):</t>
<t><list style="symbols">
<t>Negotiation of algorithms used: AEAD-, signature- and MAC-algorithm used in the protocol, and ECDH-ES w/ HKDF algorithm used in the key derivation:
<list style="symbols">
<t>U proposes one or more algorithms (Alg_U).</t>
<t>V decides and responds with selected algorithms (Alg_V).</t>
<t>Subsequent traffic is protected with the AEAD agreed in this negotiation.</t>
</list></t>
</list></t>
<figure title="EDHOC with asymmetric keys. " anchor="mess-ex2"><artwork align="center"><![CDATA[
Party U Party V
| |
| N_U, E_U, Alg_U |
+---------------------------------------------------------------> |
| 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_V, N_U, E_U, Alg_U, ID_U
]]></artwork></figure>
<section anchor="asym" title="Message Formatting using COSE">
<t>This section details the format for the objects used. Examples are provided for each object in <xref target="examples"/>.</t>
<t>Note that * identifies fields that do not exist in COSE structures (<xref target="I-D.ietf-cose-msg"/>), and are thus defined in this document.</t>
<section anchor="asym-m1" title="Message 1">
<t>This section defines the formatting of message_1.</t>
<t>message_1 is a CBOR map object containing:</t>
<t><list style="symbols">
<t>N_U: nonce</t>
<t>E_U: the ephemeral public key of Party U</t>
<t>ECDH_arr: an array of proposed ECDH-ES w/ HKDF algorithms</t>
<t>AEAD_arr: an array of proposed AEAD algorithms</t>
<t>SIG_arr: an array of proposed Signature algorithms</t>
<t>MAC_arr: an array of proposed MAC algorithms</t>
</list></t>
<figure><artwork><![CDATA[
message_1 = {
N_U : bstr,
E_U : COSE_Key,
ALG_U : alg_arr
}
alg_arr = [
ECDH_arr : alg_array,
AEAD_arr : alg_array,
SIG_arr : alg_array,
MAC_arr : alg_array
]
alg_array = [ + alg : bstr/int ]
]]></artwork></figure>
</section>
<section anchor="asym-m2" title="Message 2">
<t>In case of asymmetric keys, message_2 SHALL have the COSE_Encrypt structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers:
<list style="symbols">
<t>protected:
<list style="symbols">
<t>alg: AEAD, the Authenticated Encryption with Additional Data algorithm chosen by Party V from the set of proposed algorithms AEAD_arr</t>
</list></t>
<t>unprotected:
<list style="symbols">
<t>nonces*: nonce-array</t>
</list></t>
</list></t>
<t>ciphertext: encrypted plaintext as defined below</t>
<t>recipient:
<list style="symbols">
<t>Headers:
<list style="symbols">
<t>protected: ECDH-ES + HKDF algorithm chosen by Party V from the set of proposed algorithms ECDH_arr (table 18 in <xref target="I-D.ietf-cose-msg"/>)</t>
<t>unprotected:
<list style="symbols">
<t>E_V: COSE_Key</t>
</list></t>
<t>ciphertext: empty</t>
</list></t>
</list></t>
</list></t>
<figure><artwork><![CDATA[
nonce-array = [
N_U: bstr,
N_V: bstr
]
]]></artwork></figure>
<t>The plaintext for message_2 SHALL have the COSE_Sign1 structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers
<list style="symbols">
<t>protected
<list style="symbols">
<t>alg: SIG, the Sign algorithm chosen by Party V from the set of proposed algorithms SIG_arr</t>
<t>MAC-alg*: MAC, the MAC algorithm chosen by Party V from the set of proposed algorithms MAC_arr</t>
</list></t>
<t>Unprotected:
<list style="symbols">
<t>kid: ID_V (if raw public keys are used) or</t>
<t>x5c*: C_V (if certificates are used)</t>
</list></t>
</list></t>
<t>detached payload: as defined below</t>
<t>signature: computed as in Section 4.4 of <xref target="I-D.ietf-cose-msg"/></t>
</list></t>
<t>The payload for COSE_Sign1 SHALL have the COSE_MAC0 structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers
<list style="symbols">
<t>protected
<list style="symbols">
<t>alg: MAC (same value as MAC-alg in COSE_Sign1 structure above)</t>
</list></t>
<t>unprotected: empty</t>
</list></t>
<t>payload: payl_2_rpk (resp. payl_2_cert) as defined below if raw public keys (resp. certificates) are used</t>
<t>tag</t>
</list></t>
<figure><artwork><![CDATA[
payl_2_rpk = [
N_U: bstr,
N_V: bstr,
E_V: COSE_Key,
ID_V: bstr
]
]]></artwork></figure>
<figure><artwork><![CDATA[
payl_2_cert = [
N_U: bstr,
N_V: bstr,
E_V: COSE_Key,
C_V: bstr
]
]]></artwork></figure>
</section>
<section anchor="asym-m3" title="Message 3">
<t>In case of asymmetric keys, message_3 SHALL have the COSE_Encrypt0 structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers:
<list style="symbols">
<t>protected:
<list style="symbols">
<t>alg: AEAD</t>
</list></t>
<t>unprotected:
<list style="symbols">
<t>nonces*: nonce-array</t>
</list></t>
</list></t>
<t>ciphertext: encrypted plaintext as defined below</t>
</list></t>
<t>The plaintext for message_3 SHALL have the COSE_Sign1 structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers
<list style="symbols">
<t>protected
<list style="symbols">
<t>alg: SIG</t>
<t>MAC-alg*: MAC</t>
</list></t>
<t>Unprotected:
<list style="symbols">
<t>kid: ID_U (if raw public keys are used) or</t>
<t>x5c*: C_U (if certificates are used)</t>
</list></t>
</list></t>
<t>detached payload: as defined below</t>
<t>signature: computed as in Section 4.4 of <xref target="I-D.ietf-cose-msg"/></t>
</list></t>
<t>The payload for COSE_Sign1 SHALL have the COSE_MAC0 structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers
<list style="symbols">
<t>protected
<list style="symbols">
<t>alg: MAC (same value as MAC-alg in COSE_Sign1 structure above)</t>
</list></t>
<t>unprotected: empty</t>
</list></t>
<t>payload: payl_3_rpk (resp. payl_3_cert) as defined below if raw public keys (resp. certificates) are used</t>
<t>tag</t>
</list></t>
<figure><artwork><![CDATA[
payl_3_rpk = [
N_V : bstr,
N_U : bstr,
E_U : COSE_Key,
ALG_U : alg_arr,
ID_V : bstr
]
]]></artwork></figure>
<figure><artwork><![CDATA[
payl_3_cert = [
N_V : bstr,
N_U : bstr,
E_U : COSE_Key,
ALG_U : alg_arr,
C_V : bstr
]
]]></artwork></figure>
</section>
</section>
<section anchor="key-der-asym" title="Key Derivation with Asymmetric Keys">
<t>It is described in this section how the keys for encryption (K_UE, K_VE) and MAC (K_UM, K_VM) are derived.</t>
<t>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.</t>
<t>The key derivation is identical to Section 11.1 of <xref target="I-D.ietf-cose-msg"/>, using HKDF <xref target="RFC5869"/> agreed as part of the ECDH-ES w/ HKDF negociation during the message exchange.</t>
<t><list style="symbols">
<t>the secret SHALL be the ECDH shared secret as defined in Section 12.4.1 of <xref target="I-D.ietf-cose-msg"/>, where the computed secret is specified in section 5.7.1.2 of <xref target="SP-800-56a"/></t>
<t>the salt SHALL be the concatenation of N_U and N_V.</t>
<t>the length SHALL be the length of the key, depending on the algorithm used.</t>
<t>the context information SHALL be the serialized COSE_KDF_Context defined in the next paragraph.</t>
<t>the PRF SHALL be the one indicated in HKDF using the Table 18 of <xref target="I-D.ietf-cose-msg"/> (in our examples, -27 corresponds to HMAC with SHA-256)</t>
</list></t>
<t>The context information COSE_KDF_Context is defined as follows:</t>
<t><list style="symbols">
<t>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)</t>
<t>PartyUInfo SHALL contain:
<list style="symbols">
<t>nonce SHALL be equal to N_U</t>
</list></t>
<t>PartyVInfo SHALL contain:
<list style="symbols">
<t>nonce SHALL be equal to N_V</t>
</list></t>
<t>SuppPubInfo SHALL contain:
<list style="symbols">
<t>KeyDataLength SHALL be equal to ‘length’</t>
<t>protected SHALL be a zero length bstr</t>
<t>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)</t>
</list></t>
<t>SuppPrivInfo SHALL be empty</t>
</list></t>
<t>The key derivation is done using the following context information COSE_KDF_Context for asymmetric keys:</t>
<figure><artwork><![CDATA[
COSE_KDF_Context = [
AlgorithmID : AEAD / MAC,
PartyUInfo : [ PartyInfo_U ],
PartyVInfo : [ PartyInfo_V ],
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; Hash(message_1 ||
COSE Headers of COSE_Encrypt
(message_2) ||
"PartyU"/"PartyV")
]
]
]]></artwork></figure>
<figure><artwork><![CDATA[
PartyInfo_U = (
nonce : N_U
)
PartyInfo_V = (
nonce : N_V
)
]]></artwork></figure>
<t>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.</t>
<t>For example, to derive K_UE when asymmetric keys are used, the context MUST include:</t>
<t><list style="symbols">
<t>AEAD as Algorithm ID</t>
<t>“PartyU” as the chosen string in SuppPubInfo other</t>
</list></t>
</section>
<section anchor="mess-proc" title="Message Processing">
<t>Party U and V are assumed to have pre-established credentials as described in <xref target="asym-keys-intro"/>.</t>
<section anchor="u-message1" title="U -> message_1">
<t>Party U processes message_1 for party V as follows:</t>
<t><list style="symbols">
<t>Party U SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of <xref target="SP-800-56a"/> using ECC domain parameters of a curve complying with security policies for communicating with party V.</t>
<t>The ephemeral public key, E_U, SHALL be formatted as a COSE_key as specified in <xref target="COSE_key"/>.</t>
<t>Party U SHALL generate a pseudo-random 64-bits nonce N_U and store it for the length of the protocol, for future verifications.</t>
<t>Party U SHALL set the proposed algorithms for communicating with party V.</t>
<t>Party U SHALL format message_1 as specified in <xref target="asym-m1"/>.</t>
<t>Party U sends message_1 to party V.</t>
</list></t>
</section>
<section anchor="message1-v" title="message_1 -> V">
<t>Party V processes the received message_1 as follows:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="message2-v" title="message_2 <- V">
<t>Party V composes message_2 for party U as follows:</t>
<t><list style="symbols">
<t>Party V SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of <xref target="SP-800-56a"/> using same curve/ECC domain parameters as used by party U.
<list style="symbols">
<t>The ephemeral public key, E_V, SHALL be formatted as a COSE_key as specified in <xref target="COSE_key"/>.</t>
</list></t>
<t>Party V SHALL generate a pseudo-random 64-bits nonce N_V and store it for the length of the protocol, for future verifications.</t>
<t>Party V SHALL derive K_UE, K_VE, K_UM and K_VM as defined in <xref target="key-der-asym"/>.</t>
<t>Party V SHALL format message_2 as specified in <xref target="asym-m2"/>:</t>
<t>COSE_MAC0 is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_VM and algorithm MAC;</t>
<t>COSE_Sign1 is computed as defined in section 4.4 of <xref target="I-D.ietf-cose-msg"/>, using the private key of Party V and algorithm SIG;</t>
<t>COSE_Encrypt is computed as defined in section 5.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_VE and algorithm AEAD.</t>
<t>Note that the COSE_Sign1 payload is detached (as defined in section 4.1 of <xref target="I-D.ietf-cose-msg"/>).</t>
<t>Note that in case of certificates, the certificate of Party V, C_V, is sent in place of ID_V</t>
<t>Party V sends message_2 to party U.</t>
</list></t>
</section>
<section anchor="u-message2" title="U <- message_2">
<t>Party U processes the received message_2 as follows:</t>
<t><list style="symbols">
<t>Party U SHALL verify than the received N_U is identical to the saved nonce N_U.</t>
<t>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.</t>
<t>Party U SHALL derive K_UE, K_VE, K_UM and K_VM as defined in <xref target="key-der-asym"/>.</t>
<t>Party U SHALL verify message_2:
<list style="symbols">
<t>COSE_Encrypt is decrypted and verified as defined in section 5.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_VE.</t>
<t>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.</t>
<t>COSE_MAC0 is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_VM. The result is inserted as payload of the received COSE_Sign1 (which was sent with detached payload);</t>
<t>COSE_Sign1 is verified as defined in section 4.4 of <xref target="I-D.ietf-cose-msg"/>, using the public key of Party V;</t>
<t>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.</t>
</list></t>
<t>If the verification of message_2 fails, the message MUST be discarded and Party U SHALL discontinue the protocol.</t>
</list></t>
</section>
<section anchor="u-message3" title="U -> message_3">
<t>Party U composes message_3 for party V as follows:</t>
<t><list style="symbols">
<t>Party U SHALL format message_3 as specified in <xref target="asym-m3"/>:</t>
<t>COSE_MAC0 is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_UM and algorithm MAC;</t>
<t>COSE_Sign1 is computed as defined in section 4.4 of <xref target="I-D.ietf-cose-msg"/>, using the private key of Party U and algorithm SIG;</t>
<t>COSE_Encrypt0 is computed as defined in section 5.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_UE and algorithm AEAD.</t>
<t>Note that the COSE_Sign1 payload is detached (as defined in section 4.1 of <xref target="I-D.ietf-cose-msg"/>).</t>
<t>Note that in case of certificates, the certificate of Party U, C_U, is sent in place of ID_U</t>
<t>Party U sends message_3 to party V.</t>
</list></t>
</section>
<section anchor="message3-v" title="message_3 -> V">
<t>Party V processes the received message_3 as follows:</t>
<t><list style="symbols">
<t>Party V SHALL verify than the received N_U and N_V are identical to the saved nonces N_U and N_V. If the verification fails, the message MUST be discarded.</t>
<t>Party V SHALL verify message_3:
<list style="symbols">
<t>COSE_Encrypt0 is decrypted and verified as defined in section 5.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_UE.</t>
<t>If the message contains a certificate, party V 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.</t>
<t>COSE_MAC0 is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_UM. The result is inserted as payload of the received COSE_Sign1 (which was sent with detached payload);</t>
<t>COSE_Sign1 is verified as defined in section 4.4 of <xref target="I-D.ietf-cose-msg"/>, using the public key of Party U;</t>
<t>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.</t>
</list></t>
<t>If the verification of message_3 fails, the message MUST be discarded and Party V SHALL discontinue the protocol.</t>
</list></t>
</section>
</section>
</section>
<section anchor="PSK" title="Symmetric Keys">
<t>In this section we assume that the protocol messages are authenticated with pre-shared symmetric keys.</t>
<t>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.</t>
<t>The protocol is based on the basic SIGMA protocol (<xref target="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 the key identifier in message_1 to indicate what PSK that V should use (kid_psk). In this case identity protection is achieved by anonymizing the kid (<xref target="sec-cons"/>).</t>
<t>For a specific pre-shared key (and corresponding kid-psk):</t>
<t><list style="symbols">
<t>Party U SHALL be identified by ID_U.</t>
<t>Party V SHALL be identified by ID_V.</t>
</list></t>
<t>Since kid-psk is unique, only one additional pre-established bit is needed to identify the parties.</t>
<t>As in the asymmetric case, some additional protocol elements are added to the final protocol:</t>
<t><list style="symbols">
<t>Explicit freshness nonces/session identifiers N_U, N_V chosen freshly and anew with each session by U and V, respectively</t>
<t>Computationally independent keys K_UM, K_VM derived from the DH-shared secret and used for different directions and operations.</t>
<t>Negotiation of algorithms:
<list style="symbols">
<t>MAC-algorithm used in the protocol</t>
<t>HKDF with hash algorithm used in the key derivation</t>
<t>AEAD-algorithm used to protect subsequent traffic</t>
<t>U proposes one or more algorithms (Alg_U).</t>
<t>V decides and responds with selected algorithms (Alg_V).</t>
</list></t>
</list></t>
<figure title="EDHOC with symmetric keys. " anchor="mess-ex3"><artwork align="center"><![CDATA[
Party U Party V
| |
| N_U, E_U, Kid, Alg_U |
+---------------------------------------------------------------> |
| 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_V, N_U, E_U, Kid, ID_U, Alg_U
]]></artwork></figure>
<section anchor="sym" title="Message Formatting using COSE">
<t>This section details the format for the objects used. Examples are provided for each object in <xref target="examples"/>.</t>
<t>Note that * identifies fields that do not exist in COSE structures (<xref target="I-D.ietf-cose-msg"/>), and are thus defined in this document.</t>
<section anchor="m1-psk" title="Message 1">
<t>This section defines the formatting of message_1.</t>
<t>message_1 is a CBOR map object containing:</t>
<t><list style="symbols">
<t>N_U: nonce</t>
<t>E_U: the ephemeral public key of Party U</t>
<t>KID: identifier of the pre-shared key (it’s value is kid_psk)</t>
<t>ECDH_arr: an array of proposed ECDH-ES w/ HKDF algorithms</t>
<t>AEAD_arr: an array of proposed AEAD algorithms</t>
<t>MAC_arr: an array of proposed MAC algorithms</t>
</list></t>
<figure><artwork><![CDATA[
message_1 = {
N_U : bstr,
E_U : COSE_Key,
KID: bstr,
ALG_U : alg_arr
}
alg_arr = [
ECDH_arr : alg_array,
AEAD_arr : alg_array,
MAC_arr : alg_array
]
alg_array = [
+ alg : bstr/int
]
]]></artwork></figure>
</section>
<section anchor="m2-psk" title="Message 2">
<t>In case of pre-shared key, message_2 SHALL have the COSE_MAC structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers:
<list style="symbols">
<t>protected:
<list style="symbols">
<t>alg: MAC</t>
</list></t>
<t>unprotected:
<list style="symbols">
<t>nonces*: nonce-array</t>
<t>kid: kid_psk</t>
<t>sid*: ID_V</t>
<t>AEAD-alg*: AEAD</t>
</list></t>
</list></t>
<t>detached payload: defined below</t>
<t>tag: calculated as in section 6.3 of <xref target="I-D.ietf-cose-msg"/></t>
<t>recipient:
<list style="symbols">
<t>Headers:
<list style="symbols">
<t>protected: ECDH-ES + HKDF algorithm chosen by Party V from the set of proposed algorithms ECDH_arr (table 18 in <xref target="I-D.ietf-cose-msg"/>)</t>
<t>unprotected:
<list style="symbols">
<t>E_U: COSE_Key</t>
</list></t>
<t>ciphertext: empty</t>
</list></t>
</list></t>
</list></t>
<figure><artwork><![CDATA[
nonce-array = [
N_U: bstr,
N_V: bstr
]
]]></artwork></figure>
<t>The payload for message_2 SHALL have the COSE_MAC0 structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers
<list style="symbols">
<t>protected
<list style="symbols">
<t>alg: MAC (same value as MAC in COSE_MAC structure above)</t>
</list></t>
<t>unprotected: empty</t>
</list></t>
<t>payload: payl_2_psk as defined below</t>
<t>tag: calculated as in section 6.3 of <xref target="I-D.ietf-cose-msg"/></t>
</list></t>
<figure><artwork><![CDATA[
payl_2_psk = [
N_U: bstr,
N_V: bstr,
E_V: COSE_Key,
KID: bstr, ; has value kid_psk
ID_V: bstr,
ALG_V: alg_array ; (ECDH, AEAD, MAC)
]
]]></artwork></figure>
<t>Note that ALG_V contains the set of chosen algorithms, in order ECDH, AEAD, MAC, selected from the list provided in ALG_U.</t>
</section>
<section anchor="m3-psk" title="Message 3">
<t>In case of symmetric keys, message_3 SHALL have the COSE_MAC0 structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers:
<list style="symbols">
<t>protected:
<list style="symbols">
<t>alg: MAC</t>
</list></t>
<t>unprotected:
<list style="symbols">
<t>nonces*: nonce-array</t>
<t>kid: kid_psk</t>
<t>sid*: ID_U</t>
</list></t>
</list></t>
<t>detached payload: defined below</t>
<t>tag: calculated as in section 6.3 of <xref target="I-D.ietf-cose-msg"/></t>
</list></t>
<t>The payload for message_3 SHALL have the COSE_MAC0 structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Headers
<list style="symbols">
<t>protected
<list style="symbols">
<t>alg: MAC (same value as in COSE_MAC0 structure above)</t>
</list></t>
<t>unprotected: empty</t>
</list></t>
<t>payload: payl_3_psk as defined below</t>
<t>tag: calculated as in section 6.3 of <xref target="I-D.ietf-cose-msg"/></t>
</list></t>
<figure><artwork><![CDATA[
payl_3_psk = [
N_V: bstr,
N_U: bstr,
E_U: COSE_Key,
KID: bstr, ; has value kid_psk
ID_V: bstr,
ALG_U : alg_arr
]
]]></artwork></figure>
</section>
</section>
<section anchor="key-der-sym" title="Key Derivation with Symmetric Keys">
<t>It is described in this section how the keys for MAC (K_UM, K_VM, K_UMP, K_VMP) are derived.</t>
<t>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.</t>
<t>The key derivation is identical to <xref target="key-der-asym"/>, with 3 differences:</t>
<t><list style="symbols">
<t>to derive K_UM and K_VM, the secret SHALL be the ECDH shared secret as defined in Section 12.4.1 of <xref target="I-D.ietf-cose-msg"/>, where the computed secret is specified in section 5.7.1.2 of <xref target="SP-800-56a"/></t>
<t>to derive K_UMP and K_VMP, the secret SHALL be the pre-shared key</t>
<t>The COSE_KDF_Context SHALL be the serialized COSE_KDF_Context defined in the next paragraph.</t>
</list></t>
<t>The context information COSE_KDF_Context is defined as follows:</t>
<t><list style="symbols">
<t>AlgorithmID SHALL be the algorithm for which the key material will be derived. It’s value is MAC.</t>
<t>PartyUInfo SHALL contain:
<list style="symbols">
<t>nonce SHALL be equal to N_U</t>
</list></t>
<t>PartyVInfo SHALL contain:
<list style="symbols">
<t>nonce SHALL be equal to N_V</t>
<t>identity SHALL be equal to ID_V</t>
</list></t>
<t>SuppPubInfo SHALL contain:
<list style="symbols">
<t>KeyDataLength SHALL be equal to ‘length’</t>
<t>protected SHALL be a zero length bstr</t>
<t>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)</t>
</list></t>
<t>SuppPrivInfo SHALL be empty</t>
</list></t>
<t>The key derivation is done using the following context information COSE_KDF_Context for symmetric keys:</t>
<figure><artwork><![CDATA[
COSE_KDF_Context = [
AlgorithmID : MAC,
PartyUInfo : [ PartyInfo_U_psk ],
PartyVInfo : [ PartyInfo_V_psk ],
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; Hash(message_1 ||
COSE Headers of COSE_MAC
(message_2) ||
"PartyU"/"PartyV")
]
]
]]></artwork></figure>
<figure><artwork><![CDATA[
PartyInfo_U_psk = (
nonce : N_U
)
PartyInfo_V_psk = (
nonce : N_V
identity: ID_V
)
]]></artwork></figure>
<t>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”.</t>
</section>
<section anchor="mess-proc-sym" title="Message Processing">
<t>Party U and V are assumed to have pre-established credentials as previously described in <xref target="PSK"/>.</t>
<section anchor="u-message1-1" title="U -> message_1">
<t>Party U processes message_1 for party V as follows:</t>
<t><list style="symbols">
<t>Party U SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of <xref target="SP-800-56a"/> using ECC domain parameters of a curve complying with security policies for communicating with party V.</t>
<t>The ephemeral public key, E_U, SHALL be formatted as a COSE_key as specified in <xref target="COSE_key"/>.</t>
<t>Party U SHALL generate a pseudo-random 64-bits nonce N_U and store it for the length of the protocol, for future verifications.</t>
<t>Party U SHALL set the proposed algorithms for communicating with party V.</t>
<t>Party U SHALL format message_1 as specified in <xref target="m1-psk"/>.</t>
<t>Party U sends message_1 to party V.</t>
</list></t>
</section>
<section anchor="message1-v-1" title="message_1 -> V">
<t>Party V processes the received message_1 as follows:</t>
<t><list style="symbols">
<t>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.</t>
<t>Party V SHALL select a set of algorithms (AEAD, MAC, and ECDH-ES) compliant with its security policy. 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.</t>
</list></t>
</section>
<section anchor="message2-v-1" title="message_2 <- V">
<t>Party V composes message_2 for party U as follows:</t>
<t><list style="symbols">
<t>Party V SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of <xref target="SP-800-56a"/> using same curve/ECC domain parameters as used by party U.
<list style="symbols">
<t>The ephemeral public key, E_V, SHALL be formatted as a COSE_key as specified in <xref target="COSE_key"/>.</t>
</list></t>
<t>Party V SHALL generate a pseudo-random 64-bits nonce N_V and store it for the length of the protocol, for future verifications.</t>
<t>Party V SHALL derive K_UM, K_VM, K_UMP and K_VMP as defined in <xref target="key-der-sym"/>.</t>
<t>Party V SHALL format message_2 as specified in <xref target="m2-psk"/>:</t>
<t>COSE_MAC0 is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_VM and algorithm MAC;</t>
<t>COSE_MAC is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_VMP and algorithm MAC.</t>
<t>Note that the COSE_MAC payload is detached (as defined in section 6.1 of <xref target="I-D.ietf-cose-msg"/>).</t>
<t>Party V sends message_2 to party U.</t>
</list></t>
</section>
<section anchor="u-message2-1" title="U <- message_2">
<t>Party U processes the received message_2 as follows:</t>
<t><list style="symbols">
<t>Party U SHALL verify than the received N_U is identical to the saved nonce N_U.</t>
<t>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.</t>
<t>Party U SHALL derive K_UM, K_VM, K_UMP and K_VMP as defined in <xref target="key-der-sym"/>.</t>
<t>Party U SHALL verify message_2:
<list style="symbols">
<t>COSE_MAC0 is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_VM. The result is inserted as payload of the received COSE_MAC (which was sent with detached payload);</t>
<t>COSE_MAC is verified as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_VMP and algorithm MAC;</t>
<t>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.</t>
</list></t>
<t>If the verification of message_2 fails, the message MUST be discarded and Party U SHALL discontinue the protocol.</t>
</list></t>
</section>
<section anchor="u-message3-1" title="U -> message_3">
<t>Party U composes message_3 for party V as follows:</t>
<t><list style="symbols">
<t>Party U SHALL format message_3 as specified in <xref target="m3-psk"/>:</t>
<t>COSE_MAC0 (containing payl_3_psk) is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_UM and algorithm MAC;</t>
<t>COSE_MAC0 is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_UMP and algorithm MAC.</t>
<t>Note that the second COSE_MAC0 payload is detached (as defined in section 6.1 of <xref target="I-D.ietf-cose-msg"/>).</t>
<t>Party U sends message_3 to party V.</t>
</list></t>
</section>
<section anchor="message3-v-1" title="message_3 -> V">
<t>Party V processes the received message_3 as follows:</t>
<t><list style="symbols">
<t>Party V SHALL verify than the received N_U and N_V are identical to the saved nonces N_U and N_V. If the verification fails, the message MUST be discarded.</t>
<t>Party V SHALL verify message_3:
<list style="symbols">
<t>COSE_MAC0 (containing payl_3_psk) is computed as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_UM. The result is inserted as payload of the received COSE_MAC0 (which was sent with detached payload);</t>
<t>COSE_MAC0 is verified as defined in section 6.3 of <xref target="I-D.ietf-cose-msg"/>, with key K_UMP and algorithm MAC;</t>
<t>Note that by verifying message_3, Party V ensures that message_1 was not modified in transit.</t>
</list></t>
<t>If the verification of message_3 fails, the message MUST be discarded and Party V SHALL discontinue the protocol.</t>
</list></t>
</section>
</section>
</section>
<section anchor="final-key-der" title="Derive Traffic Secret">
<t>It is described in this section how the traffic secret for further communication is derived, based on the messages exchanged.</t>
<t>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.</t>
<t>The key derivation is identical to Section 11.1 of <xref target="I-D.ietf-cose-msg"/>, using HKDF <xref target="RFC5869"/> agreed as part of the ECDH-ES w/ HKDF negotiation during the message exchange.</t>
<t><list style="symbols">
<t>the secret SHALL be the ECDH shared secret as defined in Section 12.4.1 of <xref target="I-D.ietf-cose-msg"/>, where the computed secret is specified in section 5.7.1.2 of <xref target="SP-800-56a"/></t>
<t>the salt SHALL be the concatenation of N_U and N_V.</t>
<t>the length SHALL be the length of the key, depending on the AEAD algorithm with which the base_key will be used.</t>
<t>the context information SHALL be the serialized COSE_KDF_Context defined in the next paragraph.</t>
<t>the PRF SHALL be the one indicated in HKDF using the Table 18 of <xref target="I-D.ietf-cose-msg"/> (in our examples, -27 corresponds to HMAC with SHA-256)</t>
</list></t>
<t>The context information COSE_KDF_Context is defined as follows:</t>
<t><list style="symbols">
<t>AlgorithmID SHALL be the AEAD algorithm for which the key material will be derived.</t>
<t>PartyUInfo SHALL contain:
<list style="symbols">
<t>nonce SHALL be equal to N_U</t>
<t>identity SHALL be ID_U (resp. C_U) if raw public keys (resp. certificates) are used</t>
</list></t>
<t>PartyVInfo SHALL contain:
<list style="symbols">
<t>nonce SHALL be equal to N_V</t>
<t>identity SHALL be ID_V (resp. C_V) if raw public keys (resp. certificates) are used</t>
</list></t>
<t>SuppPubInfo SHALL contain:
<list style="symbols">
<t>KeyDataLength SHALL be equal to ‘length’</t>
<t>protected SHALL be a zero length bstr</t>
<t>other SHALL contain the HMAC (as defined by the agreed HKDF) of the concatenation of message_1, message_2 and message_3.</t>
</list></t>
<t>SuppPrivInfo SHALL be empty</t>
</list></t>
<t>The key derivation is done using the following context information COSE_KDF_Context:</t>
<figure><artwork><![CDATA[
COSE_KDF_Context = [
AlgorithmID : AEAD,
PartyUInfo : [ PartyInfo_U ],
PartyVInfo : [ PartyInfo_V ],
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; Hash(message_1 ||
message_2 ||
message_3)
]
]
]]></artwork></figure>
<figure><artwork><![CDATA[
PartyInfo_U = (
nonce : N_U,
identity: ID_U / C_U
)
PartyInfo_V = (
nonce : N_V,
identity: ID_V / C_V
)
]]></artwork></figure>
</section>
<section anchor="sec-cons" title="Security Considerations">
<t>The referenced processing instructions in <xref target="SP-800-56a"/> must be complied with, including deleting the intermediate computed values along with any ephemeral ECDH secrets after the key derivation is completed.</t>
<t>The choice of key length used in the different algorithms needs to be harmonized, so that right security level is maintained throughout the calculations.</t>
<t>Note that, depending on the use, the key established through the EDHOC protocol will need to be renewed, in which case the communicating parties need to run the protocol again.</t>
<t>In case of symmetric keys, the key identifier for the pre-shared secret identifies one party to the other. The kid may reveal information about the communicating parties to others. The communicating parties may protect against this by anonymizing the kid either only initially or between each run of the protocol.</t>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">
<t>TODO</t>
</section>
<section anchor="iana" title="IANA Considerations">
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The authors wants to thank Ilari Liusvaara, Jim Schaad and Ludwig Seitz for reviewing previous versions of the draft.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC7049;
&I-D.ietf-cose-msg;
&RFC2119;
<reference anchor="SP-800-56a" target="http://dx.doi.org/10.6028/NIST.SP.800-56Ar2">
<front>
<title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title>
<author initials="E." surname="Barker" fullname="Elaine Barker">
<organization></organization>
</author>
<author initials="L." surname="Chen" fullname="Lily Chen">
<organization></organization>
</author>
<author initials="A." surname="Roginsky" fullname="Allen Roginsky">
<organization></organization>
</author>
<author initials="M." surname="Smid" fullname="Miles Smid">
<organization></organization>
</author>
<date year="2013" month="May"/>
</front>
<seriesInfo name="NIST" value="Special Publication 800-56A"/>
<format type="PDF" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf"/>
</reference>
<reference anchor="SIGMA" target="http://dx.doi.org/10.1007/978-3-540-45146-4_24">
<front>
<title>SIGMA - The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE-Protocols</title>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization></organization>
</author>
<date year="2003" month="August"/>
</front>
<seriesInfo name="Advances in Cryptology - CRYPTO 2003," value="23rd Annual International Cryptology Conference, Santa Barbara, California, USA, August 17-21, 2003, Proceedings"/>
<format type="PDF" target="http://www.iacr.org/cryptodb/archive/2003/CRYPTO/1495/1495.pdf"/>
</reference>
</references>
<references title='Informative References'>
&I-D.hartke-core-e2e-security-reqs;
&I-D.ietf-ace-oauth-authz;
&I-D.ietf-core-object-security;
&I-D.seitz-ace-oscoap-profile;
&RFC4492;
&RFC7228;
&RFC7252;
&RFC5869;
</references>
<section anchor="examples" title="Examples">
<t>In this section we give examples of messages used in the protocol for the pre-shared key case and for the raw public keys case. Note that the message size is not optimized, for example the labels could be registered and thereby reducing the overhead.</t>
<section anchor="ecdh-public-key" title="ECDH Public Key">
<t>An example of COSE_Key structure, representing an ECDH public key, is given in <xref target="ex-cose-key"/>, using CBOR’s diagnostic
notation.</t>
<figure title="Example of an ECDH public key formatted as a COSE_Key" anchor="ex-cose-key"><artwork><![CDATA[
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590b
bfbf054e1c7b4d91d6280',
/ y / -3:true
}
]]></artwork></figure>
<t>The equivalent CBOR encoding is:
h’a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5’,
which has a size of 44 bytes.</t>
</section>
<section anchor="example-with-asymmetric-keys-rpk" title="Example with Asymmetric Keys (RPK)">
<t>In this example, the identifier of V is 4 bytes.</t>
<section anchor="ex-rpk1" title="Message 1">
<t>An example of COSE encoding for message_1 is given in <xref target="message1"/>, using CBOR’s diagnostic notation.</t>
<t>The message_1 is:</t>
<figure title="Example of message_1" anchor="message1"><artwork><![CDATA[
{
'N_U':h'5598a57b47db7f2c',
'E_U':h'a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7
590bbfbf054e1c7b4d91d628022f5', / COSE_Key E_U { /
/ ephemeral -1:{ /
/ kty 1:2, /
/ crv -1:1, /
/ x -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb /
/ f054e1c7b4d91d6280', /
/ y -3:true /
/ } /
/ } /
'ALG_U' : h'8481381a810c81268104'
/ [ /
/ [ -27 ], ECDH-SS + HKDF-256 /
/ [ 12 ], AES-CCM-64-64-128 /
/ [ -7 ], ES256 /
/ [ 4 ] HMAC 256-64 /
/ ] /
}
]]></artwork></figure>
<t>The equivalent CBOR encoding of the message_1 is:
h’a3434e5f55485598a57b47db7f2c43455f55582ca120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f545414c475f554a8481381a810c81268104’,
which has a size of 81 bytes.
Note that by registering the labels ‘N_U’, ‘E_U’ and ‘ALG_U’ to unsigned values the size can be reduced to 70 bytes.</t>
</section>
<section anchor="ex-rpk2" title="Message 2">
<t>An example of COSE encoding for message_2 is given in <xref target="message2"/> using CBOR’s diagnostic notation.</t>
<t>The payload of the COSE_MAC0 is:</t>
<figure><artwork><![CDATA[
[
h'7ce4cae9c9698bac', / N_V /
h'5598a57b47db7f2c', / N_U /
h'a120a501022001215820acbee6672a28340affce41c721901eb
d7868231bd1d86e41888a07822214050022f5', / COSE_Key E_V { /
/ ephemeral -1:{ /
/ kty 1:2, /
/ crv -1:1, /
/ x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
/ 86e41888a078222140500', /
/ y -3:true /
/ } /
/ } /
h'0f4907e1' / ID_V /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the payload of the COSE_MAC0 is:
h’84485598a57b47db7f2c487ce4cae9c9698bac5832a120a401022001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5440f4907e1’,
which has a size of 70 bytes. Note that these bytes are not sent in the message.</t>
<t>The COSE_MAC0 is:</t>
<figure><artwork><![CDATA[
[
h'a10104', / protected : {01:04} /
{}, / unprotected /
h'84485598a57b47db7f2c487ce4cae9c9698bac5832a120a401022001215820acb
ee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544
0f4907e1', / payload /
MAC / truncated 8-byte MAC /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_MAC0 is:
h’8443a10104a0584684485598a57b47db7f2c487ce4cae9c9698bac5832a120a401022001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5440f4907e148’||MAC,
which has a size of 87 bytes. Note that these bytes are not sent in the message.</t>
<t>The COSE_Sign1 is:</t>
<figure><artwork><![CDATA[
[
h'a20126474d41432d616c6704', / protected : {1:-7, 'MAC-alg':04} /
{04:h'00'}, / unprotected /
h'', / detached payload /
SIG / 64-byte signature /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_Sign1 is:
h’844ca20126474d41432d616c6704a1044100405840’||SIG,
which has a size of 85 bytes.
Note that by registering the label ‘MAC-alg’ to unsigned values the size can be reduced to 78 bytes.</t>
<t>The COSE_Encrypt is:</t>
<figure title="Example of message_2" anchor="message2"><artwork><![CDATA[
[
h'a1010c', / protected : {1:12} /
{'nonces':h'82485598a57b47db7f2c487ce4cae9c9698bac'},/unprotected /
/ [ /
/ h'5598a57b47db7f2c', N_U /
/ h'7ce4cae9c9698bac' N_V /
/ ] /
CIPH+TAG, / 85 bytes-cipher text + truncated 8-byte TAG /
[ / recipients /
[
h'a101381a' / protected : {1:-27} / ,
{ / unprotected /
'E_V':h'a120a401022001215820a
cbee6672a28340affce41c721901ebd7868231bd1
d86e41888a07822214050022f5' / COSE_Key E_V { /
/ ephemeral -1:{ /
/ kty 1:2, /
/ crv -1:1, /
/ x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
/ 86e41888a078222140500', /
/ y -3:true /
/ } /
/ } /
},
h'' / ciphertext /
]
]
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_Encrypt is:
h’8443a1010ca1466e6f6e6365735382485598a57b47db7f2c487ce4cae9c9698bac585b’||CIPH+TAG||h’818344a101381aa143455f565832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f540’,
which has a size of 187 bytes.
Note that by registering the label ‘MAC-alg’ and ‘E_V’ to unsigned values the size can be reduced to 177 bytes.</t>
</section>
<section anchor="ex-rpk3" title="Message 3">
<t>An example of COSE encoding for message_3 is given in <xref target="message3"/> using CBOR’s diagnostic notation.</t>
<t>The payload of the COSE_MAC0 is:</t>
<figure><artwork><![CDATA[
[
h'7ce4cae9c9698bac', / N_V /
h'5598a57b47db7f2c', / N_U /
h'a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d628022f5', / COSE_Key E_U /
h'8481381a810c81268104', / ALG_U /
/ [ /
/ [ -27 ], ECDH-SS + HKDF-256 /
/ [ 12 ], AES-CCM-64-64-128 /
/ [ -7 ], ES256 /
/ [ 4 ] HMAC 256-64 /
/ ] /
h'0f4907e1' / ID_V /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the payload of the COSE_MAC0 is:
h’85487ce4cae9c9698bac485598a57b47db7f2c582ca120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f54a8481381a810c81268104440f4907e1’,
which has a size of 81 bytes. Note that these bytes are not sent in the message.</t>
<t>The COSE_MAC0 is:</t>
<figure><artwork><![CDATA[
[
h'a10104', / protected : {01:04} /
{}, / unprotected /
h'85487ce4cae9c9698bac485598a57b47db7f2c582ca120a40102200121582098f
50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f54a
8481381a810c81268104440f4907e1', / payload /
MAC / truncated 8-byte MAC /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_MAC0 is:
h’8443a10104a0585185487ce4cae9c9698bac485598a57b47db7f2c582ca120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f54a8481381a810c81268104440f4907e148’||MAC,
which has a size of 98 bytes. Note that these bytes are not sent in the message.</t>
<t>The COSE_Sign1 is:</t>
<figure><artwork><![CDATA[
[
h'a20126474d41432d616c6704', / protected : {1:-7, 'MAC-alg':4} /
{04:h'0f4907e1'}, / unprotected /
h'', / detached payload /
SIG / 64-byte signature /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_Sign1 is:
h’844ca20126474d41432d616c6704a104440f4907e1405840’||SIG,
which has a size of 88 bytes.
Note that by registering the label ‘MAC-alg’ to unsigned values the size can be reduced to 81 bytes.</t>
<t>The COSE_Encrypt0 is:</t>
<figure title="Example of message_3" anchor="message3"><artwork><![CDATA[
[
h'a1010c', / protected : {01:12} /
{'nonces':h'82485598a57b47db7f2c487ce4cae9c9698bac'},/unprotected /
/ 'nonces':[ /
/ h'5598a57b47db7f2c', N_U /
/ h'7ce4cae9c9698bac' N_V /
/ ] /
CIPH+TAG / 88 bytes-cipher text + truncated 8-byte TAG /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_Encrypt0 is:
h’8343a1010ca1466e6f6e6365735382485598a57b47db7f2c487ce4cae9c9698bac5860’||CIPH+TAG,
which has a size of 131 bytes.
Note that by registering the labels ‘MAC-alg’ and ‘nonces’ to unsigned values the size can be reduced to 118 bytes.</t>
</section>
</section>
<section anchor="example-with-symmetric-keys-psk" title="Example with Symmetric Keys (PSK)">
<t>In this example, the identifiers of U and V are 4 bytes.</t>
<section anchor="ex-psk1" title="Message 1">
<t>An example of COSE encoding for message_1 is given in <xref target="message1-psk"/>, using CBOR’s diagnostic notation.</t>
<t>The message_1 is:</t>
<figure title="Example of message_1" anchor="message1-psk"><artwork><![CDATA[
{
'N_U':h'5598a57b47db7f2c',
'E_U':h'a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7
590bbfbf054e1c7b4d91d628022f5', / COSE_Key E_U { /
/ ephemeral -1:{ /
/ kty 1:2, /
/ crv -1:1, /
/ x -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb /
/ f054e1c7b4d91d6280', /
/ y -3:true /
/ } /
/ } /
'KID':h'e19648b5',
'ALG_U':h'8381381a810c8104'
/ [ /
/ [ -27 ], ECDH-SS + HKDF-256 /
/ [ 12 ], AES-CCM-64-64-128 /
/ [ 4 ] HMAC 256-64 /
/ ] /
}
]]></artwork></figure>
<t>The equivalent CBOR encoding of the message_1 is:
h’a4434e5f55485598a57b47db7f2c43455f55582ca120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5434b494444e19648b545414c475f55488381381a810c8104’,
which has a size of 88 bytes.
Note that by registering the labels ‘N_U’, ‘E_U’, ‘KID’ and ‘ALG_U’ to unsigned values the size can be reduced to 74 bytes.</t>
</section>
<section anchor="ex-psk2" title="Message 2">
<t>An example of COSE encoding for message_2 is given in <xref target="message2-psk"/> using CBOR’s diagnostic notation.</t>
<t>The payload of the COSE_MAC0 is:</t>
<figure><artwork><![CDATA[
[
h'5598a57b47db7f2c', / N_U /
h'7ce4cae9c9698bac', / N_V /
h'a120a401022001215820acbee6672a28340affce41c721901eb
d7868231bd1d86e41888a07822214050022f5', / COSE_Key E_V { /
/ ephemeral -1:{ /
/ kty 1:2, /
/ crv -1:1, /
/ x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
/ 86e41888a078222140500', /
/ y -3:true /
/ } /
/ } /
h'e19648b5', / KID /
h'0f4907e1', / ID_V /
h'83381a0c04' / ALG_V /
/ [ /
/-27 , ECDH-SS + HKDF-256 /
/ 12 , AES-CCM-64-64-128 /
/ 4 HMAC 256-64 /
/ ] /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the payload of the COSE_MAC0 is:
h’86485598a57b47db7f2c487ce4cae9c9698bac582ca120a401022001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544e19648b5440f4907e14583381a0c04’,
which has a size of 81 bytes. Note that these bytes are not sent in the message.</t>
<t>The COSE_MAC0 is:</t>
<figure><artwork><![CDATA[
[
h'a10104', / protected : {01:04} /
{}, / unprotected /
h'86485598a57b47db7f2c487ce4cae9c9698bac582ca120a401022001215820acb
ee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544
e19648b5440f4907e14583381a0c04', / payload /
MAC / truncated 8-byte MAC /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_MAC0 is:
h’8443a10104a0585186485598a57b47db7f2c487ce4cae9c9698bac582ca120a401022001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544e19648b5440f4907e14583381a0c0448’||MAC,
which has a size of 98 bytes. Note that these bytes are not sent in the message.</t>
<t>The COSE_MAC is:</t>
<figure title="Example of message_2" anchor="message2-psk"><artwork><![CDATA[
[
h'a10104', / protected : {01:04} /
{ / unprotected /
'nonces':h'82485598a57b47db7f2c487ce4cae9c9698bac', / 'nonces':[/
/ h'5598a57b47db7f2c', N_U /
/ h'7ce4cae9c9698bac' N_V /
/ ] /
04:h'e19648b5', / KID /
'sid':h'0f4907e1', / ID_V /
'AEAD-alg': 12
},
h'', / detached payload /
TAG, / 8-byte truncated tag /
[ / recipients /
[
h'a101381a' / protected : {1:-27} / ,
{ / unprotected /
'E_V':h'a120a401022001215820a
cbee6672a28340affce41c721901ebd7868231bd1
d86e41888a07822214050022f5' / COSE_Key E_V { /
/ ephemeral -1:{ /
/ kty 1:2, /
/ crv -1:1, /
/ x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
/ 86e41888a078222140500', /
/ y -3:true /
/ } /
/ } /
},
h'' / ciphertext /
]
]
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_MAC is:</t>
<t>h’8543a10104a4466e6f6e6365735382485598a57b47db7f2c487ce4cae9c9698bac0444e19648b543736964440f4907e148414541442d616c670c4048||MAC||818344a101381aa143455f56582ca120a401022001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f540’,
which has a size of 127 bytes.
Note that by registering the labels ‘nonces’, ‘sid’, ‘AEAD-alg’ and ‘E_V’ to unsigned values the size can be reduced to 107 bytes.</t>
</section>
<section anchor="ex-psk3" title="Message 3">
<t>An example of COSE encoding for message_3 is given in <xref target="message3-psk"/> using CBOR’s diagnostic notation.</t>
<t>The payload of the COSE_MAC0 is:</t>
<figure><artwork><![CDATA[
[
h'5598a57b47db7f2c', / N_U /
h'7ce4cae9c9698bac', / N_V /
h'a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c
3f5ad7590bbfbf054e1c7b4d91d628022f5', / COSE_Key E_U /
h'e19648b5', / KID /
h'0f4907e1', / ID_V /
h'8381381a810c8104'
/ [ /
/ [ -27 ], ECDH-SS + HKDF-256 /
/ [ 12 ], AES-CCM-64-64-128 /
/ [ 4 ] HMAC 256-64 /
/ ] /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the payload of the COSE_MAC0 is:
h’86485598a57b47db7f2c487ce4cae9c9698bac582fa120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f544e19648b5440f4907e1488381381a810c8104’,
which has a size of 84 bytes. Note that these bytes are not sent in the message.</t>
<t>The COSE_MAC0 is:</t>
<figure><artwork><![CDATA[
[
h'a10104', / protected : {01:04} /
{}, / unprotected /
h'86485598a57b47db7f2c487ce4cae9c9698bac582fa120a401022001215
82098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d6280
22f544e19648b5440f4907e1488381381a810c8104', / payload /
MAC / truncated 8-byte MAC /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_MAC0 is:
h’8444a10104a0585486485598a57b47db7f2c487ce4cae9c9698bac582fa120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f544e19648b5440f4907e1488381381a810c810448’||MAC,
which has a size of 101 bytes. Note that these bytes are not sent in the message.</t>
<t>The COSE_MAC0 is:</t>
<figure title="Example of message_3" anchor="message3-psk"><artwork><![CDATA[
[
h'a10104', / protected : {01:04} /
{ / unprotected /
'nonces':h'82485598a57b47db7f2c487ce4cae9c9698bac',
/ [ /
/ h'5598a57b47db7f2c', N_U /
/ h'7ce4cae9c9698bac' N_V /
/ ] /
04:h'e19648b5', / KID /
'sid':h'dbabb666' / ID_U /
},
h'', / detached payload /
MAC / truncated 8-byte MAC /
]
]]></artwork></figure>
<t>The equivalent CBOR encoding of the COSE_MAC0 is:
h’8443a10104a3466e6f6e6365735382485598a57b47db7f2c487ce4cae9c9698bac0444e19648b54373696444dbabb6664048’||MAC,
which has a size of 58 bytes.
Note that by registering the labels ‘nonces’ and ‘sid’ to unsigned values the size can be reduced to 49 bytes.</t>
</section>
</section>
</section>
<section anchor="app-a" title="Implementing EDHOC with CoAP and OSCOAP">
<t>The DH key exchange specified in this document can be implemented as a CoAP <xref target="RFC7252"/> message exchange with the CoAP client as party U and the CoAP server as party V. EDHOC and OSCOAP <xref target="I-D.ietf-core-object-security"/> could be run in sequence embedded in a 2-round trip message exchange, where the base_key used in OSCOAP is obtained from EDHOC.</t>
<t>The process to run EDHOC over CoAP, combined with and followed by OSCOAP is described here and showed in <xref target="edhoc-oscoap"/> and <xref target="edhoc-oscoap-det"/>.</t>
<figure title="EDHOC and OSCOAP" anchor="edhoc-oscoap"><artwork><![CDATA[
Client Server
| ------------- EDHOC message_1 ------------> |
| |
| <------------ EDHOC message_2 ------------- |
| |
| ---- OSCOAP Request + EDHOC message_3 ----> |
| |
| <------------ OSCOAP Response ------------- |
| |
]]></artwork></figure>
<figure title="Detail of EDHOC and OSCOAP" anchor="edhoc-oscoap-det"><artwork><![CDATA[
Client Server
| |
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path:"edhoc"
| | Content-Type: application/cbor
| | Payload: EDHOC message_1
| |
|<---------+ Header: 2.04 Changed
| | Content-Type: application/cose+cbor
| 2.05 | Payload: EDHOC message_2
| |
| |
+--------->| CoAP message including:
| OSCOAP | Object-Security option
| request | COSE_Encrypt0 includes
| | EDHOC message_3
| |
|<---------+ CoAP message including:
| OSCOAP | Object-Security option
| response |
| |
]]></artwork></figure>
<t>The CoAP client makes the following request:</t>
<t><list style="symbols">
<t>The request method is POST</t>
<t>Content-Format is “application/cose+cbor”</t>
<t>The Uri-Path is “edhoc”</t>
<t>The Payload is EDHOC message_1, computed as defined in this document</t>
</list></t>
<t>The CoAP server performs the first step of the protocol as specified in this document. Then the server provides the following response:</t>
<t><list style="symbols">
<t>The response Code is 2.04 (Changed)</t>
<t>The Payload is EDHOC message_2, computed as defined in this document</t>
</list></t>
<t>The CoAP client verifies the message_2 as specified in this document. If successful, the client continues the protocol and generates EDHOC message_3.</t>
<t>The client derives OSCOAP Common Context (section 3.1 of <xref target="I-D.ietf-core-object-security"/>) from the messages exchanged:</t>
<t><list style="symbols">
<t>base_key is the traffic secret, output of EDHOC (section 6 of this document)</t>
<t>Context Identifier is the HMAC computed over the hash of the concatenation of EDHOC message_1, message_2, and message_3 using the key base_key: Cid = HMAC(base_key, hash(message_1 || message_2 || message_3))</t>
<t>the Algorithm is the AEAD algorithm negotiated during EDHOC</t>
</list></t>
<t>Additionally, we define here that:</t>
<t><list style="symbols">
<t>Sender ID for the CoAP client is set to ‘0’</t>
<t>Recipient ID for the CoAP client is set to ‘1’</t>
</list></t>
<t>With these parameters, the CoAP client can derive the full security context, following section 3.2 of <xref target="I-D.ietf-core-object-security"/>.</t>
<t>Finally, the client generates the OSCOAP request, containing the Object-Security option and the COSE_Encrypt0 object as defined in <xref target="I-D.ietf-core-object-security"/>. EDHOC message_3 is added to the unprotected part of the COSE_Encrypt0 Headers, with label ‘edhoc_m3’. The OSCOAP request is sent, and includes also EDHOC message_3. Note that this may considerably increase the size of the COSE_Encrypt0 object (see {#ex-rpk3}), so in case the OSCOAP request method does not allow payload, the Object-Security option may become large.</t>
<t>The server receives the message and extract the message_3 from the unprotected part of the COSE_Encrypt0 object of the OSCOAP request. If the object does not contain the ‘edhoc_m3’ label, or if the ‘edhoc_m3’ value does not comply with the specifications, the message is discarded and the communication terminated.
Otherwise, the server process and verifies the EDHOC message_3 as described in this document. If successful, the server derives OSCOAP Common Context (section 3.1 of <xref target="I-D.ietf-core-object-security"/>) from the messages exchanged:</t>
<t><list style="symbols">
<t>base_key is the traffic secret, output of EDHOC (section 6 of this document)</t>
<t>Context Identifier is the HMAC computed over the hash of the concatenation of EDHOC message_1, message_2, and message_3 using the key base_key: Cid = HMAC(base_key, hash(message_1 || message_2 || message_3))</t>
<t>the Algorithm is the AEAD algorithm negotiated during EDHOC</t>
</list></t>
<t>Additionally, we define here that:</t>
<t><list style="symbols">
<t>Sender ID for the CoAP server is set to ‘1’</t>
<t>Recipient ID for the CoAP server is set to ‘0’</t>
</list></t>
<t>With these parameters, the CoAP server can derive the full security context, following section 3.2 of <xref target="I-D.ietf-core-object-security"/>.</t>
<t>Finally, the client can verify the OSCOAP request using the security context, and act according to <xref target="I-D.ietf-core-object-security"/>. Further communication can be protected using OSCOAP.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:38:04 |