| ACE Working Group | G. Selander |
| Internet-Draft | J. Mattsson |
| Intended status: Standards Track | F. Palombini |
| Expires: May 4, 2017 | Ericsson AB |
| October 31, 2016 |
Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-selander-ace-cose-ecdhe-04
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [I-D.hartke-core-e2e-security-reqs]. IoT devices may be constrained in various ways, including memory, storage, processing capacity, and energy [RFC7228]. A method for protecting individual messages at application layer suitable for constrained devices, is provided by COSE [I-D.ietf-cose-msg]), which builds on CBOR [RFC7049].
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 [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 [I-D.seitz-ace-oscoap-profile]. This document also specifies the derivation of shared key material.
The DH exchange and the key derviation follow [SIGMA], NIST SP-800-56a [SP-800-56a] and HKDF [RFC5869], and make use of the data structures of COSE which are aligned with these standards.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119]. These words may also appear in this document in lowercase, absent their normative meanings.
This section gives an overview of EDHOC, together with Section 4.3 and Section 5.3, which explains how the messages are processed, while Section 4.1 and Section 5.1 focus on the detailed message formats embedded as CBOR objects, and Section 4.2, Section 5.2, and Section 6 specify the key derivation.
EDHOC is built on the SIGMA family of protocols, with the basic protocol specified in Section 5, here in variant (ii) as in Section 5.4, of [SIGMA], see Figure 1.
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)) |
+------------------------------------------------------>|
| |
Figure 1: The basic SIGMA protocol
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 (Figure 1):
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 [SIGMA], see Figure 2. This protocol adds encryption which is required for identity protection in the asymmetric key case:
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))) |
+------------------------------------------------------>|
| |
Figure 2: The SIGMA-I protocol
The protocols are detailed further in the following sections.
This section defines the formatting of the ephemeral public keys E_U and E_V.
The ECDH ephemeral public key SHALL be formatted as a COSE_Key with the following fields and values (see [I-D.ietf-cose-msg]):
For the field ‘crv’, refer to Table 22 of [I-D.ietf-cose-msg]. The value 1 MUST be supported by party V (NIST P-256 a.k.a. secp256r1 [RFC4492]).
TODO: Consider replacing P-256 with Curve25519 as mandatory
In this section we assume that the protocol messages are authenticated with asymmetric keys. Both the scenarios where the parties use raw public keys (RPK) and X.509 certificates (Cert) are supported.
ID_U and ID_V may be public key certificates [SIGMA], which we then denote as C_U and C_V, respectively.
The pre-established credentials may thus be the public keys of U at V, and of V at U. Alternatively, a pre-established public key of a Certificate Authority (CA) may be used as trust anchor for verification of received certificate.
The protocol is based on SIGMA-I (Section 2). As described in Appendix B of [SIGMA], in order to create a “full-fledge” protocol some additional protocol elements are needed:
EDHOC makes the following additions to this scheme (see Figure 3):
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
Figure 3: EDHOC with asymmetric keys.
This section details the format for the objects used. Examples are provided for each object in Appendix A.
Note that * identifies fields that do not exist in COSE structures ([I-D.ietf-cose-msg]), and are thus defined in this document.
This section defines the formatting of message_1.
message_1 is a CBOR map object containing:
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 ]
In case of asymmetric keys, message_2 SHALL have the COSE_Encrypt structure [I-D.ietf-cose-msg] with the following fields and values:
nonce-array = [ N_U: bstr, N_V: bstr ]
The plaintext for message_2 SHALL have the COSE_Sign1 structure [I-D.ietf-cose-msg] with the following fields and values:
The payload for COSE_Sign1 SHALL have the COSE_MAC0 structure [I-D.ietf-cose-msg] with the following fields and values:
payl_2_rpk = [ N_U: bstr, N_V: bstr, E_V: COSE_Key, ID_V: bstr ]
payl_2_cert = [ N_U: bstr, N_V: bstr, E_V: COSE_Key, C_V: bstr ]
In case of asymmetric keys, message_3 SHALL have the COSE_Encrypt0 structure [I-D.ietf-cose-msg] with the following fields and values:
The plaintext for message_3 SHALL have the COSE_Sign1 structure [I-D.ietf-cose-msg] with the following fields and values:
The payload for COSE_Sign1 SHALL have the COSE_MAC0 structure [I-D.ietf-cose-msg] with the following fields and values:
payl_3_rpk = [ N_V : bstr, N_U : bstr, E_U : COSE_Key, ALG_U : alg_arr, ID_V : bstr ]
payl_3_cert = [ N_V : bstr, N_U : bstr, E_U : COSE_Key, ALG_U : alg_arr, C_V : bstr ]
It is described in this section how the keys for encryption (K_UE, K_VE) and MAC (K_UM, K_VM) are derived.
Party U and Party V SHALL derive K_UE, K_VE, K_UM, and K_VM from the information available in message_1 and message_2 through the key exchange, as described in this section.
The key derivation is identical to Section 11.1 of [I-D.ietf-cose-msg], using HKDF [RFC5869] agreed as part of the ECDH-ES w/ HKDF negociation during the message exchange.
The context information COSE_KDF_Context is defined as follows:
The key derivation is done using the following context information COSE_KDF_Context for asymmetric keys:
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")
]
]
PartyInfo_U = (
nonce : N_U
)
PartyInfo_V = (
nonce : N_V
)
Using the different combination of these parameters creates the four keys K_UE, K_UM, K_VE and K_VM when raw public keys or certificates are used.
For example, to derive K_UE when asymmetric keys are used, the context MUST include:
Party U and V are assumed to have pre-established credentials as described in Section 4.
Party U processes message_1 for party V as follows:
Party V processes the received message_1 as follows:
Party V composes message_2 for party U as follows:
Party U processes the received message_2 as follows:
Party U composes message_3 for party V as follows:
Party V processes the received message_3 as follows:
In this section we assume that the protocol messages are authenticated with pre-shared symmetric keys.
Parties U and V are assumed to have a pre-shared uniformly random key, PSK. The value of the key identifier (kid_psk) SHALL be unique for U and V.
The protocol is based on the basic SIGMA protocol (Section 2), 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 (Section 7).
For a specific pre-shared key (and corresponding kid-psk):
Since kid-psk is unique, only one additional pre-established bit is needed to identify the parties.
As in the asymmetric case, some additional protocol elements are added to the final protocol:
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
Figure 4: EDHOC with symmetric keys.
This section details the format for the objects used. Examples are provided for each object in Appendix A.
Note that * identifies fields that do not exist in COSE structures ([I-D.ietf-cose-msg]), and are thus defined in this document.
This section defines the formatting of message_1.
message_1 is a CBOR map object containing:
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
]
In case of pre-shared key, message_2 SHALL have the COSE_MAC structure [I-D.ietf-cose-msg] with the following fields and values:
nonce-array = [ N_U: bstr, N_V: bstr ]
The payload for message_2 SHALL have the COSE_MAC0 structure [I-D.ietf-cose-msg] with the following fields and values:
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) ]
Note that ALG_V contains the set of chosen algorithms, in order ECDH, AEAD, MAC, selected from the list provided in ALG_U.
In case of symmetric keys, message_3 SHALL have the COSE_MAC0 structure [I-D.ietf-cose-msg] with the following fields and values:
The payload for message_3 SHALL have the COSE_MAC0 structure [I-D.ietf-cose-msg] with the following fields and values:
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 ]
It is described in this section how the keys for MAC (K_UM, K_VM, K_UMP, K_VMP) are derived.
Party U and Party V SHALL derive K_UM, K_VM, K_UMP and K_VMP from the information available in message_1 and message_2 through the key exchange, as described in this section.
The key derivation is identical to Section 4.2, with 3 differences:
The context information COSE_KDF_Context is defined as follows:
The key derivation is done using the following context information COSE_KDF_Context for symmetric keys:
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")
]
]
PartyInfo_U_psk = (
nonce : N_U
)
PartyInfo_V_psk = (
nonce : N_V
identity: ID_V
)
In practice, the difference in deriving K_UM or K_VM is in the SuppPubInfo string: to derive K_UM the context MUST include “PartyU”, while to derive K_VM the context MUST include “PartyV”.
Party U and V are assumed to have pre-established credentials as previously described in Section 5.
Party U processes message_1 for party V as follows:
Party V processes the received message_1 as follows:
Party V composes message_2 for party U as follows:
Party U processes the received message_2 as follows:
Party U composes message_3 for party V as follows:
Party V processes the received message_3 as follows:
It is described in this section how the traffic secret for further communication is derived, based on the messages exchanged.
Party U and Party V SHALL derive the traffic secret (base_key) from the information available in message_1, message_2 and message_3 through the key exchange, as described in this section.
The key derivation is identical to Section 11.1 of [I-D.ietf-cose-msg], using HKDF [RFC5869] agreed as part of the ECDH-ES w/ HKDF negotiation during the message exchange.
The context information COSE_KDF_Context is defined as follows:
The key derivation is done using the following context information COSE_KDF_Context:
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)
]
]
PartyInfo_U = (
nonce : N_U,
identity: ID_U / C_U
)
PartyInfo_V = (
nonce : N_V,
identity: ID_V / C_V
)
The referenced processing instructions in [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.
The choice of key length used in the different algorithms needs to be harmonized, so that right security level is maintained throughout the calculations.
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.
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.
TODO
The authors wants to thank Ilari Liusvaara, Jim Schaad and Ludwig Seitz for reviewing previous versions of the draft.
| [I-D.ietf-cose-msg] | Schaad, J., "CBOR Object Signing and Encryption (COSE)", Internet-Draft draft-ietf-cose-msg-23, October 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7049] | Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013. |
| [SIGMA] | Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE-Protocols", Advances in Cryptology - CRYPTO 2003, 23rd Annual International Cryptology Conference, Santa Barbara, California, USA, August 17-21, 2003, Proceedings, August 2003. |
| [SP-800-56a] | Barker, E., Chen, L., Roginsky, A. and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, May 2013. |
| [I-D.hartke-core-e2e-security-reqs] | Selander, G., Palombini, F. and K. Hartke, "Requirements for CoAP End-To-End Security", Internet-Draft draft-hartke-core-e2e-security-reqs-01, July 2016. |
| [I-D.ietf-ace-oauth-authz] | Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S. and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE)", Internet-Draft draft-ietf-ace-oauth-authz-04, October 2016. |
| [I-D.ietf-core-object-security] | Selander, G., Mattsson, J., Palombini, F. and L. Seitz, "Object Security of CoAP (OSCOAP)", Internet-Draft draft-ietf-core-object-security-00, October 2016. |
| [I-D.seitz-ace-oscoap-profile] | Seitz, L., "OSCOAP profile of ACE", Internet-Draft draft-seitz-ace-oscoap-profile-00, July 2016. |
| [RFC4492] | Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C. and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006. |
| [RFC5869] | Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010. |
| [RFC7228] | Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014. |
| [RFC7252] | Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014. |
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.
An example of COSE_Key structure, representing an ECDH public key, is given in Figure 5, using CBOR’s diagnostic notation.
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590b
bfbf054e1c7b4d91d6280',
/ y / -3:true
}
Figure 5: Example of an ECDH public key formatted as a COSE_Key
The equivalent CBOR encoding is: h’a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5’, which has a size of 44 bytes.
In this example, the identifier of V is 4 bytes.
An example of COSE encoding for message_1 is given in Figure 6, using CBOR’s diagnostic notation.
The message_1 is:
{
'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 /
/ ] /
}
Figure 6: Example of message_1
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.
An example of COSE encoding for message_2 is given in Figure 7 using CBOR’s diagnostic notation.
The payload of the COSE_MAC0 is:
[
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 /
]
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.
The COSE_MAC0 is:
[
h'a10104', / protected : {01:04} /
{}, / unprotected /
h'84485598a57b47db7f2c487ce4cae9c9698bac5832a120a401022001215820acb
ee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544
0f4907e1', / payload /
MAC / truncated 8-byte MAC /
]
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.
The COSE_Sign1 is:
[
h'a20126474d41432d616c6704', / protected : {1:-7, 'MAC-alg':04} /
{04:h'00'}, / unprotected /
h'', / detached payload /
SIG / 64-byte signature /
]
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.
The COSE_Encrypt is:
[
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 /
]
]
]
Figure 7: Example of message_2
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.
An example of COSE encoding for message_3 is given in Figure 8 using CBOR’s diagnostic notation.
The payload of the COSE_MAC0 is:
[
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 /
]
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.
The COSE_MAC0 is:
[
h'a10104', / protected : {01:04} /
{}, / unprotected /
h'85487ce4cae9c9698bac485598a57b47db7f2c582ca120a40102200121582098f
50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f54a
8481381a810c81268104440f4907e1', / payload /
MAC / truncated 8-byte MAC /
]
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.
The COSE_Sign1 is:
[
h'a20126474d41432d616c6704', / protected : {1:-7, 'MAC-alg':4} /
{04:h'0f4907e1'}, / unprotected /
h'', / detached payload /
SIG / 64-byte signature /
]
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.
The COSE_Encrypt0 is:
[
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 /
]
Figure 8: Example of message_3
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.
In this example, the identifiers of U and V are 4 bytes.
An example of COSE encoding for message_1 is given in Figure 9, using CBOR’s diagnostic notation.
The message_1 is:
{
'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 /
/ ] /
}
Figure 9: Example of message_1
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.
An example of COSE encoding for message_2 is given in Figure 10 using CBOR’s diagnostic notation.
The payload of the COSE_MAC0 is:
[
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 /
/ ] /
]
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.
The COSE_MAC0 is:
[
h'a10104', / protected : {01:04} /
{}, / unprotected /
h'86485598a57b47db7f2c487ce4cae9c9698bac582ca120a401022001215820acb
ee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f544
e19648b5440f4907e14583381a0c04', / payload /
MAC / truncated 8-byte MAC /
]
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.
The COSE_MAC is:
[
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 /
]
]
]
Figure 10: Example of message_2
The equivalent CBOR encoding of the COSE_MAC is:
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.
An example of COSE encoding for message_3 is given in Figure 11 using CBOR’s diagnostic notation.
The payload of the COSE_MAC0 is:
[
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 /
/ ] /
]
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.
The COSE_MAC0 is:
[
h'a10104', / protected : {01:04} /
{}, / unprotected /
h'86485598a57b47db7f2c487ce4cae9c9698bac582fa120a401022001215
82098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d6280
22f544e19648b5440f4907e1488381381a810c8104', / payload /
MAC / truncated 8-byte MAC /
]
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.
The COSE_MAC0 is:
[
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 /
]
Figure 11: Example of message_3
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.
The DH key exchange specified in this document can be implemented as a CoAP [RFC7252] message exchange with the CoAP client as party U and the CoAP server as party V. EDHOC and OSCOAP [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.
The process to run EDHOC over CoAP, combined with and followed by OSCOAP is described here and showed in Figure 12 and Figure 13.
Client Server
| ------------- EDHOC message_1 ------------> |
| |
| <------------ EDHOC message_2 ------------- |
| |
| ---- OSCOAP Request + EDHOC message_3 ----> |
| |
| <------------ OSCOAP Response ------------- |
| |
Figure 12: EDHOC and OSCOAP
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 |
| |
Figure 13: Detail of EDHOC and OSCOAP
The CoAP client makes the following request:
The CoAP server performs the first step of the protocol as specified in this document. Then the server provides the following response:
The CoAP client verifies the message_2 as specified in this document. If successful, the client continues the protocol and generates EDHOC message_3.
The client derives OSCOAP Common Context (section 3.1 of [I-D.ietf-core-object-security]) from the messages exchanged:
Additionally, we define here that:
With these parameters, the CoAP client can derive the full security context, following section 3.2 of [I-D.ietf-core-object-security].
Finally, the client generates the OSCOAP request, containing the Object-Security option and the COSE_Encrypt0 object as defined in [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.
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 [I-D.ietf-core-object-security]) from the messages exchanged:
Additionally, we define here that:
With these parameters, the CoAP server can derive the full security context, following section 3.2 of [I-D.ietf-core-object-security].
Finally, the client can verify the OSCOAP request using the security context, and act according to [I-D.ietf-core-object-security]. Further communication can be protected using OSCOAP.