One document matched: draft-selander-ace-cose-ecdhe-00.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 I-D.ietf-cose-msg SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cose-msg.xml">
<!ENTITY I-D.ietf-tls-tls13 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-tls13.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-oauth-pop-key-distribution SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-pop-key-distribution.xml">
<!ENTITY I-D.selander-ace-object-security SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.selander-ace-object-security.xml">
<!ENTITY I-D.wahlstroem-ace-cbor-web-token SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.wahlstroem-ace-cbor-web-token.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 RFC7519 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.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-00" 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="March" day="21"/>
<area>Applications</area>
<workgroup>ACE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies the Diffie-Hellman key exchange with ephemeral keys embedded in messages encoded with the CBOR Encoded Message Syntax.</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 the CBOR Encoded Message Syntax (COSE, <xref target="I-D.ietf-cose-msg"/>).</t>
<t>In order for a communication session to provide forward secrecy, the communicating parties could run a Diffie-Hellman (DH) key exchange protocol with ephemeral keys, from which session keys are derived. This document specifies two instances of DH key exchange using COSE messages to transport the ephemeral public keys. The DH key exchange messages are authenticated using pre-established keys, either a secret key (<xref target="PSK"/>) or public keys (<xref target="ECDH-SS"/>). The pre-established keys may be transferred to client and server from a trusted third party, such as an Authorization Server <xref target="I-D.ietf-ace-oauth-authz"/>. Successful verification of the protocol messages, defined in this document, provides a method for proof-of-possession of the corresponding secret or private key <xref target="I-D.ietf-oauth-pop-key-distribution"/>.</t>
<t>This document also specifies derivation of traffic keys, from the shared secret established through the DH key exchange with ephemeral keys. The key derivation is identical to TLS 1.3 <xref target="I-D.ietf-tls-tls13"/>.</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>
<t>The key exchange messages are called “message_1” and “message_2”, and the
parties exchanging the messages are called “client” and “server”, see <xref target="mess-ex"/>.
The messages are encoded using the CBOR Encoded Message Syntax (COSE, <xref target="I-D.ietf-cose-msg"/>),
and include an ephemeral public key (g^x/g^y) and a Message Authentication Code (MAC).
The shared secret g^(xy) is used to derive a key called “traffic_secret_0” using the
terminology of TLS 1.3 <xref target="I-D.ietf-tls-tls13"/>.</t>
<figure title="Diffie-Hellman key exchange and key derivation" anchor="mess-ex"><artwork align="center"><![CDATA[
client server
| |
| COSE(g^x, MAC) |
+---------------------->|
| message_1 |
| |
| COSE(g^y, MAC) |
|<----------------------+
| message_2 |
g^(xy) | | g^(xy)
| |
| |
V V
traffic_secret_0 traffic_secret_0
]]></artwork></figure>
<t>Most keys used in this document have an associated identifier. The identifiers used in the document are placeholders for values of the identifiers. The following key identifiers/value representations are used in the draft:</t>
<t><list style="symbols">
<t>kid_x and kid_y represent the values of the key identifiers of the ECDH ephemeral public keys of the client and server, respectively.</t>
<t>kid_0 represents the value of the key identifier of the pre-shared key between client and server (<xref target="PSK"/>).</t>
<t>kid_c and kid_s represent the values of the key identifiers of the ECDH static public keys of the client and server, respectively (<xref target="ECDH-SS"/>).</t>
</list></t>
<figure title="Notation of keys and key identifiers." anchor="Key-notation"><artwork align="center"><![CDATA[
+------------+-----+-----------------------------------------------+
| Key | Key | Use |
| Identifier | | |
+------------+-----+-----------------------------------------------+
| kid_x | g^x | ECDH ephemeral public key of the client |
| kid_y | g^y | ECDH ephemeral public key of the server |
| kid_0 | PSK | Pre-shared key (Section 3) |
| kid_c | g^c | ECDH static public key of the client (Sec. 4) |
| kid_s | g^s | ECDH static public key of the server (Sec. 4) |
+------------+-----+-----------------------------------------------+
]]></artwork></figure>
<t>The server ephemeral key identifier key_y is also used to identify the resulting traffic key security context, which means that the server can ensure that different clients establishing traffic keys using this method have different context identifiers.</t>
</section>
</section>
<section anchor="COSE_key" title="ECDH Public Keys">
<t>This section defines the formatting of the ephemeral public keys g^x and g^y.</t>
<section anchor="cosekey-formatting" title="COSE_Key Formatting">
<t>The ECDH ephemeral public key SHALL be formatted as a COSE_Key with the following fields and values:</t>
<t><list style="symbols">
<t>kty: The value SHALL be 2 (Elliptic Curve Keys)</t>
<t>kid:</t>
<t>crv: The value 1 SHALL be supported by the server (NIST P-256 a.k.a. secp256r1 <xref target="RFC4492"/>)</t>
<t>x:</t>
<t>y: The value SHOULD be boolean.</t>
</list></t>
<t>TODO: Consider replacing P-256 with Curve25519</t>
</section>
<section anchor="example-ecdh-public-key" title="Example: 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. In this example, the pre-shared key is identified by a 4 bytes ‘kid’.</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,
/ kid / 2:h'78f67901',
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590b
bfbf054e1c7b4d91d6280',
/ y / -3:true
}
]]></artwork></figure>
<t>The equivalent CBOR encoding is:
h’a120a50102024478f67901200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5’,
which has a size of 50 bytes.</t>
</section>
</section>
<section anchor="PSK" title="Authentication with Pre-Shared Keys">
<t>This section defines the DH key exchange protocol messages, when the MAC is calculated with a pre-shared key.</t>
<t>The client and server are assumed to have a pre-shared key, PSK, the value of its identifier is represented by kid_0.</t>
<section anchor="message-1-with-psk" title="Message 1 with PSK">
<t>message_1 contains the client’s ephemeral public key, g^x, and a MAC over g^x, calculated with the pre-shared key.</t>
<t>Before sending message_1, the client SHALL generate a fresh ephemeral ECDH key pair. The ephemeral public key, g^x, SHALL be formatted as in <xref target="COSE_key"/>, with the ‘kid’ field omitted.</t>
<t>message_1 SHALL have the COSE_Mac0_Tagged structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Header
<list style="symbols">
<t>Protected
<list style="symbols">
<t>Alg: 4 (HMAC 256/64)</t>
<t>Kid: kid_0</t>
</list></t>
<t>Unprotected: Empty, except for the case specified in <xref target="app-b"/></t>
</list></t>
<t>Payload: g^x (‘kid’ field omitted)</t>
<t>Tag: As in section 6.3 of <xref target="I-D.ietf-cose-msg"/></t>
</list></t>
<t>TODO: Error handling</t>
</section>
<section anchor="example-message-1-with-psk" title="Example: Message 1 with PSK">
<t>An example of COSE encoding for message_1 is given in <xref target="mess1-psk"/> using CBOR’s diagnostic
notation. In this example, kid_0, the identifier of PSK is 4 bytes.</t>
<figure title="Example of message_1 authenticated with PSK" anchor="mess1-psk"><artwork><![CDATA[
996(
[
/ protected / h'a201040444e19648b5' / {
/ alg / 1:4, / HMAC 256//64 /
/ kid / 4:h'e19648b5' / kid_0
} / ,
/ unprotected / {},
/ payload / h'a120a40102200121582098f50a4ff6c05861c8860d13a638
ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5' / COSE_Key g^x / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb
f054e1c7b4d91d6280',
/ y / -3:true
}
} / ,
/ tag / h'e77fe81c66c3b5c0'
]
)
]]></artwork></figure>
<t>The equivalent CBOR encoding is:
h’d903e48449a201040444e19648b5a0582ca120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f548e77fe81c66c3b5c0’,
which has a size of 70 bytes.</t>
</section>
<section anchor="message-2-with-psk" title="Message 2 with PSK">
<t>message_2 contains the server’s ephemeral public key, g^y, and a MAC over g^y and message_1, calculated with the pre-shared key.</t>
<t>Before sending message_2, the server SHALL verify message_1 using the pre-shared key, PSK, and generate a fresh ephemeral ECDH key pair. The ephemeral public key, g^y, SHALL be formatted as in <xref target="COSE_key"/>, its identifier (kid_y) SHALL be unique among key identifiers used for traffic keys by the server.</t>
<t>message_2 SHALL have the COSE_Mac0_Tagged structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Header
<list style="symbols">
<t>Protected
<list style="symbols">
<t>Alg: 4 (HMAC 256/64)</t>
<t>Kid: kid_0</t>
</list></t>
<t>Unprotected: empty</t>
</list></t>
<t>Payload: g^y
<!---
[FP] TODO: consider mentioning that kid is present [/FP]
--></t>
<t>external_aad: message_1</t>
<t>Tag: as in <xref target="I-D.ietf-cose-msg"/>, including the external_aad in the MAC_structure.</t>
</list></t>
<t>TODO: Error handling</t>
</section>
<section anchor="example-message-2-with-psk" title="Example: Message 2 with PSK">
<t>An example of COSE encoding for message_2 is given in <xref target="mess2-psk"/> using CBOR’s diagnostic
notation. In this example, kid_0, the identifier of PSK, and kid_y, the identifier of the
server’s ephemeral public key, is 4 bytes.</t>
<figure title="Example of message_2 authenticated with PSK" anchor="mess2-psk"><artwork><![CDATA[
996(
[
/ protected / h'a201040444e19648b5' / {
/ alg / 1:4, / HMAC 256//64 /
/ kid / 4:h'e19648b5' / kid_0
} / ,
/ unprotected / {},
/ payload / h'a120a5010202442edb61f92001215820acbee6672a28340a
ffce41c721901ebd7868231bd1d86e41888a07822214050022f5'
/ COSE_Key g^y / {
/ ephemeral / -1:{
/ kty / 1:2,
/ kid / 2:h'2edb61f9', / kid_y
/ crv / -1:1,
/ x / -2:h'acbee6672a28340affce41c721901ebd7868231bd1d
86e41888a078222140500',
/ y / -3:true
}
} / ,
/ tag / h'6113268ad246f2c9'
]
)
]]></artwork></figure>
<t>The equivalent CBOR encoding is:
h’d903e48449a201040444e19648b5a05832a120a4010202481e6f0c642001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5486113268ad246f2c9’,
which has a size of 76 bytes.</t>
</section>
<section anchor="key-derivation" title="Key Derivation">
<t>The client and server SHALL derive “traffic_secret_0” from the information available through the key exchange, as described in this section. The key derivation is identical to Section 7 of <xref target="I-D.ietf-tls-tls13"/>, using the PSK + ECDHE operational mode and HKDF <xref target="RFC5869"/> with SHA-256:</t>
<t><list style="symbols">
<t>The Static Secret (SS) SHALL be the pre-shared key</t>
<t>The Ephemeral Secret (ES) SHALL be the ECDH shared secret, generated from the ephemeral keys, as specified in section 7.3.3. of <xref target="I-D.ietf-tls-tls13"/></t>
<t>The generic string “TLS 1.3, “ in HkdfLabel (Section 7.1) SHALL be replaced by “EDHOC, “</t>
<t>The handshake_hash is replaced by the exchange_hash = SHA-256(message_1 + message_2), where ‘+’ denotes concatenation of octet strings</t>
</list></t>
<t>The procedure for deriving “traffic_secret_0” in Section 7 in <xref target="I-D.ietf-tls-tls13"/> SHALL be followed. The “traffic_secret_0” SHALL be identified by the identifier of the server’s ephemeral public key (kid_y).</t>
<t><xref target="app-c"/> provides an example of how to derive a security context from “traffic_secret_0”.</t>
<t>TODO: Align key derivation with that used with ECDH-SS (<xref target="ECDH-SS"/>).</t>
</section>
</section>
<section anchor="ECDH-SS" title="Authentication with Static ECDH Keys">
<t>This section defines the DH key exchange protocol messages, when the MAC is calculated with a key derived from static ECDH keys.</t>
<t>The client and the server are assumed to have static ECDH keys of a common curve. Curve P-256 SHALL be implemented by the server.</t>
<t><list style="symbols">
<t>The client’s static public key is denoted g^c, and identified by kid_c</t>
<t>The server’s static public key is denoted g^s, and identified by kid_s</t>
</list></t>
<section anchor="message-1-with-ecdh-ss" title="Message 1 with ECDH-SS">
<t>message_1 contains the client’s ephemeral public key, g^x, and a MAC over g^x, computed with a key derived from the shared secret g^(cs), calculated from the client’s and server’s static public keys.</t>
<t>Before sending message_1, the client SHALL generate a fresh ephemeral ECDH key pair. The client’s ephemeral public key, g^x, SHALL be formatted as in <xref target="COSE_key"/>, and identified by kid_x.</t>
<t>message_1 SHALL have the COSE_Mac_Tagged structure <xref target="I-D.ietf-cose-msg"/>, with the following fields and values:</t>
<t><list style="symbols">
<t>Header
<list style="symbols">
<t>Protected
<list style="symbols">
<t>Alg: 4 (HMAC 256/64)</t>
</list></t>
<t>Unprotected: empty, except in the specified in <xref target="app-b"/></t>
</list></t>
<t>Payload: g^x</t>
<t>Tag: as in <xref target="I-D.ietf-cose-msg"/></t>
<t>Recipients
<list style="symbols">
<t>COSE_recipient
<list style="symbols">
<t>Header
<list style="symbols">
<t>Protected
<list style="symbols">
<t>Alg: -27 (ECDH-SS + HKDF-256)</t>
</list></t>
<t>Unprotected
<list style="symbols">
<t>Static Kid: kid_s</t>
<t>Kid: kid_c</t>
<t>U Nonce: pseudo-random octet string
<!---
[FP] from cose-alg: If the salt/nonce value is generated randomly, then it is suggested that the length of the random value be the same length as the hash
function underlying HKDF. we use in the following example 32B nonce [/FP]
--></t>
</list></t>
</list></t>
<t>Ciphertext: nil</t>
</list></t>
</list></t>
</list></t>
<t>TODO: Error handling</t>
</section>
<section anchor="example-message-1-with-ecdh-ss" title="Example: Message 1 with ECDH-SS">
<t>An example of COSE encoding for message_1 is given in <xref target="mess1-ecdh-ss"/>, using CBOR’s diagnostic
notation. In this example, the size of the identifiers of the ECDH public keys: kid_x (the client’s ephemeral), kid_c (the client’s static), and kid_s (the server’s static) are 4 bytes,
while the length of U Nonce is 32 bytes.</t>
<figure title="Example of message_1 authenticated with static ECDH keys" anchor="mess1-ecdh-ss"><artwork><![CDATA[
994(
[
/ protected / h'a10104' / {
/ alg / 1:4 / HMAC 256//64 /
} / ,
/ unprotected / {},
/ payload / h'a120a50102024478f67901200121582098f50a4ff6c05861
c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5'
/ COSE_Key g^x / {
/ ephemeral / -1:{
/ kty / 1:2,
/ kid / 2: h'78f67901', / kid_x
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb
f054e1c7b4d91d6280',
/ y / -3:true
}
} / ,
/ tag / h'9287cb4ead0c171d',
/ recipients / [
[
/ protected / h'a101381a' / {
\ alg \ 1:-27 \ ECDH-SS + HKDF-256 \
} / ,
/ unprotected / {
/ static kid / -3:h'c150d41c', / kid_s /
/ kid / 4:h'f6b70552', / kid_c /
/ U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a2
3d19558ccfec7d34b824f42d91'
},
/ ciphertext / h''
]
]
]
)
]]></artwork></figure>
<t>The equivalent CBOR encoding is:
h’d903e28543a10104a05832a120a50102024478f67901200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5489287cb4ead0c171d818344a101381aa32244c150d41c0444f6b705523558204d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d19558ccfec7d34b824f42d9140’,
which has a size of 126 bytes.</t>
</section>
<section anchor="message-2-with-ecdh-ss" title="Message 2 with ECDH-SS">
<t>message_2 contains the server’s ephemeral public key, g^y, and a MAC over g^y, computed with a key derived from the shared secret g^(xs), calculated from the client’s ephemeral public key (kid_x) and the server’s static key (kid_s).</t>
<t>Before sending message_2, the server SHALL verify message_1. The server SHALL generate a fresh ephemeral ECDH key pair, formatted as in <xref target="COSE_key"/>, the value of the key identifier (kid_y) SHALL be unique among key identifiers used for traffic keys by the server.</t>
<t>message_2 SHALL have the COSE_Mac_Tagged structure <xref target="I-D.ietf-cose-msg"/> with the following fields and values:</t>
<t><list style="symbols">
<t>Header
<list style="symbols">
<t>Protected
<list style="symbols">
<t>Alg: 4 (HMAC 256/64)</t>
</list></t>
<t>Unprotected: empty</t>
</list></t>
<t>Payload: g^y</t>
<t>Tag: as in <xref target="I-D.ietf-cose-msg"/>.</t>
<t>Recipients
<list style="symbols">
<t>COSE_recipient
<list style="symbols">
<t>Header
<list style="symbols">
<t>Protected
<list style="symbols">
<t>Alg: -27 (ECDH-SS + HKDF-256)</t>
</list></t>
<t>Unprotected
<list style="symbols">
<t>Static Kid: kid_x</t>
<t>Kid: kid_s</t>
<t>U Nonce: pseudo-random octet string</t>
</list></t>
</list></t>
<t>Ciphertext: nil</t>
</list></t>
</list></t>
</list></t>
<t>TODO: Error handling</t>
</section>
<section anchor="example-message-2-with-ecdh-ss" title="Example: Message 2 with ECDH-SS">
<t>An example of COSE encoding for Message 2 is given in <xref target="mess2-ecdh-ss"/>, using CBOR’s diagnostic
notation. In this example, the size of the identifiers of the ECDH public keys: kid_x
(the client’s ephemeral), kid_y (the server’s ephemeral), and kid_s (the server’s static)
are 4 bytes, while the length of U Nonce is 32 bytes.</t>
<figure title="Example of message_2 authenticated with static ECDH keys" anchor="mess2-ecdh-ss"><artwork><![CDATA[
994(
[
/ protected / h'a10104' / {
/ alg / 1:4 / HMAC 256//64 /
} / ,
/ unprotected / {},
/ payload / h'a120a5010202442edb61f92001215820acbee6672a28340a
ffce41c721901ebd7868231bd1d86e41888a07822214050022f5'
/ COSE_Key g^y / {
/ ephemeral / -1:{
/ kty / 1:2,
/ kid / 2:h'2edb61f9', / kid_y
/ crv / -1:1,
/ x / -2:h'acbee6672a28340affce41c721901ebd7868231bd1d
86e41888a078222140500',
/ y / -3:true
}
} / ,
/ tag / h'2cc75952a7c6dc7f',
/ recipients / [
[
/ protected / h'a101381a' / {
\ alg \ 1:-27 \ ECDH-SS + HKDF-256 \
} / ,
/ unprotected / {
/ static kid / -3:h'78f67901', / kid_x /
/ kid / 4:h'c150d41c', / kid_s /
/ U nonce / -22:h'66aabbadf938799613ccbf8a7da0a15f13be5b
43d300aa51fceabc07a731232a'
},
/ ciphertext / h''
]
]
]
)
]]></artwork></figure>
<t>The equivalent CBOR encoding is:
h’d903e28543a10104a05832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5482cc75952a7c6dc7f818344a101381aa3224478f679010444c150d41c35582066aabbadf938799613ccbf8a7da0a15f13be5b43d300aa51fceabc07a731232a40’,
which has a size of 126 bytes.</t>
</section>
<section anchor="key-derivation-1" title="Key Derivation">
<t>The client and server SHALL derive “traffic_secret_0” from the information available through the key exchange, as described in this section. The key derivation is identical to Section 7 of <xref target="I-D.ietf-tls-tls13"/>, using the ECDHE operational mode and HKDF <xref target="RFC5869"/> with SHA-256:</t>
<t><list style="symbols">
<t>The Static Secret (SS) and the Ephemeral Secret (ES) SHALL be the ECDH shared secret, generated from the ephemeral keys, as specified in section 7.3.3. of <xref target="I-D.ietf-tls-tls13"/></t>
<t>The generic string “TLS 1.3, “ in HkdfLabel (Section 7.1) SHALL be replaced by “EDHOC, “</t>
<t>The handshake_hash is replaced by the exchange_hash = SHA-256(message_1 + message_2), where ‘+’ denotes concatenation of octet strings</t>
</list></t>
<t>The procedure for deriving “traffic_secret_0” in Section 7 in <xref target="I-D.ietf-tls-tls13"/> SHALL be followed. The “traffic_secret_0” SHALL be identified with the value of the ‘kid’ field of the server’s ephemeral public key (kid_y).</t>
<t><xref target="app-c"/> provides an example of how to derive a security context from “traffic_secret_0”.</t>
<t>TODO: Align key derivation with that used with ECDH-SS.</t>
</section>
</section>
<section anchor="sec-cons" title="Security Considerations">
<t>After the key derivation is completed, the intermediate computed values should be securely deleted, along with any ephemeral ECDH secrets.</t>
<t>The choice of key length used in the different algorithms needs to be harmonized, e.g. the size of PSK and the length of the Client/Server Write Key.</t>
<t>message_1 may be replayed and cause unnecessary resource consumption for the server. A limited mitigation can be provided by caching (the hash of) the received ephemeral keys, and compare the ephemeral keys of a new request with this cache.</t>
<t>With the current protocol, key confirmation of the Diffie-Hellman shared secret/traffic keys is performed when the keys are successfully used. One extension of the protocol is to add key confirmation by the server, so that a client detecting a failed key confirmation can initiate a new key exchange. This may be accomplished by including a counter-MAC in the second message of the key exchange, where the key used in the MAC is derived from the traffic keys. Since the calculation of the traffic keys include the hash of the key exchange messages, the counter-MAC must be excluded from the exchange_hash.</t>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">
<t>TBD</t>
</section>
<section anchor="iana" title="IANA Considerations">
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The authors wish to thank Ludwig Seitz for timely review and helpful comments.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&I-D.ietf-cose-msg;
&I-D.ietf-tls-tls13;
&RFC2119;
</references>
<references title='Informative References'>
&I-D.hartke-core-e2e-security-reqs;
&I-D.ietf-ace-oauth-authz;
&I-D.ietf-oauth-pop-key-distribution;
&I-D.selander-ace-object-security;
&I-D.wahlstroem-ace-cbor-web-token;
&RFC4492;
&RFC7228;
&RFC7252;
&RFC7519;
&RFC5869;
</references>
<section anchor="app-a" title="Implementing EDHOC with CoAP">
<t>The DH key exchange specified in this document can be implemented as a CoAP <xref target="RFC7252"/> message exchange. A strawman is sketched here.</t>
<t>The 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 message_1</t>
</list></t>
<t>The server performs the verifications of the COSE object as specified in <xref target="I-D.ietf-cose-msg"/>. If successful, 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 message_2</t>
</list></t>
</section>
<section anchor="app-b" title="Integrating EDHOC with ACE">
<t>A pre-requisite for using the DH key exchange protocols in <xref target="PSK"/> and <xref target="ECDH-SS"/> of this document is that some static keys are pre-established in client and server. The ACE framework <xref target="I-D.ietf-ace-oauth-authz"/> specifies how an authorization server (AS) supports the establishment of keys in client and (resource) server, either a shared secret key or each others’ public keys, which is exactly what is required in <xref target="PSK"/> and <xref target="ECDH-SS"/>, respectively.</t>
<t>The ACE protocol specifies a client making a ‘token request’ to the AS to retrieve an access token (JWT <xref target="RFC7519"/>, or CWT <xref target="I-D.wahlstroem-ace-cbor-web-token"/>) containing authorization information about the client regarding a certain resource on a certain server. The client can then transfer the access token to the server in the CoAP payload of the following request:</t>
<t>POST /authz-info</t>
<t>The access token may also contain a shared secret key or the public key of the client, for use by the server.</t>
<t>In case of symmetric keys, the AS generates this key and protects it for the client and server, after which the protocol in <xref target="PSK"/> can start.</t>
<t>In case of asymmetric keys, the ACE framework allows the client to include its public key in the ‘token request’, which results in the key being included in the access token reaching the server. The server’s public key can be assumed to be known to the AS, which can therefore provide also this information to the client in the response to the token request.</t>
<t>Since the protocol in <xref target="ECDH-SS"/> requires static ECDH keys from the same curve, information about the curve to use must be available to the client before making the request to the AS. There are different candidate sources for this information, for example: the server, a resource directory or the AS itself. As an example of the latter, the AS could, for example, reject a token request for a server with a public key in the wrong curve and provide information about the right curve in the response. The client could then generate a new static ECDH key pair in the right curve, include the public key in a new request to the AS, for inclusion in the access token delivered to the server.</t>
<t>The transfer of the access token as defined in <xref target="I-D.ietf-ace-oauth-authz"/> can be combined with the execution of EDHOC, for example, by including the access token in the Unprotected of Header of message_1. A dedicated resource could be defined for this combined message exchange, for example:</t>
<t>POST /authz-info-edhoc</t>
<t>The strawman in <xref target="app-a"/> applies also to this case.</t>
</section>
<section anchor="app-c" title="Deriving Security Context for OSCOAP">
<t>In this section we show how to establish security context for OSCOAP <xref target="I-D.selander-ace-object-security"/>, using the method specified in this document.</t>
<t>We assume that “traffic_secret_0” has been established, e.g. as described in <xref target="app-b"/> using a DH key exchange specified in this document. OSCOAP requires traffic keying material Client/Server Write Key/IV to be established at client and server, see section 3 of <xref target="I-D.selander-ace-object-security"/>. The computation of keying material mimics the traffic key calculation of Section 7.3 in TLS 1.3 <xref target="I-D.ietf-tls-tls13"/> using HKDF with SHA-256 and the following parameters:</t>
<t><list style="symbols">
<t>Secret = traffic_secret_0</t>
<t>phase = “application data key expansion”</t>
<t>purpose = “client write key” / “server write key” / “client write IV” / “server write IV”</t>
<t>handshake_context = message_1 + message_2, the concatenation of the exchanged messages</t>
<t>key_length for key and IV is algorithm specific.</t>
</list></t>
<t>The first three bullets are identical to TLS 1.3.</t>
<t>With the mandatory OSCOAP algorithm AES-CCM-64-64-128 (see Section 10.2 in <xref target="I-D.ietf-cose-msg"/>), key_length for the keys is 128 bits and key_length for the static IVs is 56 bits.</t>
<t>The Context Identifier (Cid) is set to the key identifier of traffic_secret_0 (i.e. kid_y, using the terminology of <xref target="PSK"/> and <xref target="ECDH-SS"/>).</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:33:59 |