| ACE Working Group | G. Selander |
| Internet-Draft | J. Mattsson |
| Intended status: Standards Track | F. Palombini |
| Expires: January 8, 2017 | Ericsson AB |
| July 07, 2016 |
Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-selander-ace-cose-ecdhe-02
This document specifies authenticated Diffie-Hellman key exchange with ephemeral keys, embedded in messages encoded with 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 January 8, 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]).
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 COSE objects for integrity protecting the transport of ephemeral public keys. The DH key exchange messages may be authenticated using either pre-shared keys, raw public keys or X.509 certificates. 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]. This document also specifies the derivation of the shared key material.
The DH exchange and the key derivation follow [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.
The parties exchanging messages are called “party U” and “party V”, and the ECDH ephemeral public keys of U and V are denoted “E_U” and “E_V”, respectively, see Figure 2. The messages in the authenticated message exchange are called “message_1” and “message_2”, see Figure 3.
The keys used to authenticate the key exchange are either symmetric or asymmetric. In case of symmetric, the pre-shared key is denoted “PSK”. In case of asymmetric, the public keys of U and V are denoted “S_U” and “S_V”, respectively.
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:
The key notation is summarized in Figure 1.
+------------+-----+---------------------------------------------+ | Key | Key | Use | | Identifier | | | +------------+-----+---------------------------------------------+ | kid_eu | E_U | ECDH ephemeral public key of U | | kid_ev | E_V | ECDH ephemeral public key of V | | kid_psk | PSK | Pre-shared static symmetric key (Section 3) | | kid_su | S_U | Static public key of U (Section 4) | | kid_sv | S_V | Static public key of V (Section 4) | +------------+-----+---------------------------------------------+
Figure 1: Notation of keys and key identifiers.
EDHOC is a 2-pass message exchange of COSE objects. This section gives an overview of the protocol, together with section Section 4, which explains how the messages are processed, while section Section 3 focuses on the detailed message formats embedded as COSE objects.
The underlying scheme is the Elliptic Curve Cofactor Diffie-Hellman with two ephemeral keys as specified in Section 6.1.2.2 of [SP-800-56a], see Figure 2. U and V exchange their ephemeral public keys E_U, E_V, computes the shared secret and derives the keying material as described in [SP-800-56a].
Party U Party V
| |
| E_U |
+---------------------->|
| |
| E_V |
|<----------------------+
| |
Shared | | Shared
Secret Secret
| |
| Key Derivation | Key Derivation
V V
Derived Keying Material Derived Keying Material
Figure 2: Diffie-Hellman key exchange and key derivation
EDHOC makes the following additions to this scheme (see Figure 3):
The key exchange messages are called “message_1” and “message_2”, see Figure 3.
Party U Party V
| |
| Header, HKDF(s), ?N_U, TCA(s), E_U, MAC/Signature, ?Cert_U |
+--------------------------------------------------------------> |
| message_1 |
| |
| Header, HKDF, ?N_V, TCA, E_V, MAC/Signature, ?Cert_V |
| <--------------------------------------------------------------+
| message_2 |
| |
| Shared Shared |
Secret Secret
| |
| Key Derivation Key Derivation |
V V
traffic_secret_0 traffic_secret_0
Figure 3: EDHOC Overview. (Optionality indicated by '?'.)
The EDHOC protocol messages are authenticated based on credentials pre-established between U and V. The parties may have acquired such a credential from the other party out of band or from a trusted third party, such as an Authorization Server as specified in [I-D.ietf-ace-oauth-authz]. The pre-established credentials are either symmetric secret keys or public keys. The public keys may be raw public keys (RPK), or public keys of a Certificate Authority (CA) used as trust anchor for verification of received certificates.
This section details the format for the objects used. Examples are provided for each object in Appendix A.
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]):
TODO: Consider replacing P-256 with Curve25519 as mandatory
This section defines the formatting of the payload in message_1.
payload_1 is a CBOR array object containing:
payload_1 = [
HKDFs : AlgID / [ + AlgID ],
N_U : nil / bstr,
TCAs : AlgID / [ + AlgID ],
E_U : COSE_Key
]
AlgID : int / tstr
This section defines the formatting of the payload in message_2.
payload_2 is a CBOR array object containing:
payload_2 = [
HKDF : int / tstr,
N_V : nil / bstr,
TCA : int / tstr,
E_V : COSE_Key
]
Parties U and V are assumed to have a pre-shared key, PSK. The value of the key identifier kid_psk SHALL be unique for U and V.
In case of PSK, message_1 SHALL have the COSE_Mac0_Tagged structure [I-D.ietf-cose-msg] with the following fields and values:
In case of PSK, message_2 SHALL have the COSE_Mac0_Tagged structure [I-D.ietf-cose-msg] with the following fields and values:
The external authenticated data to use in the MAC_structure of Section 6.3 of [I-D.ietf-cose-msg] is the MAC of message_1.
The key derivation is specified in Section 5 using the following context information COSE_KDF_Context for symmetric keys:
COSE_KDF_Context = [
AlgorithmID : int / tstr, ; AlgID
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; MAC message_1 || MAC message_2
],
]
Parties U and V are assumed to have access to each other’s public key.
In case of RPK message_1 SHALL have the COSE_Sign1_Tagged structure [I-D.ietf-cose-msg], with the following fields and values:
In case of RPK, message_2 SHALL have the COSE_Sign1_Tagged structure [I-D.ietf-cose-msg] with the following fields and values:
The external authenticated data to use in the Sig_structure of Section 4.4 of [I-D.ietf-cose-msg] is the signature in message_1.
The case of Certificates is similar to RPK. message_1 SHALL have the COSE_Sign1_Tagged structure [I-D.ietf-cose-msg], with the same fields and values as Section 3.5.1 with the addition of the unprotected header field “x5c” containing the X.509 certificate of S_U as a byte string.
message_2 is analogous to message_1. message_2 SHALL have the COSE_Sign1_Tagged structure [I-D.ietf-cose-msg], with the same fields and values as Section 3.5.2 and with the addition of the unprotected header field “x5c” containing the X.509 certificate of S_V as a byte string.
The external authenticated data to use in the Sig_structure of Section 4.4 of [I-D.ietf-cose-msg] is the signature in message_1.
The key derivation is specified in Section 5 using the following context information COSE_KDF_Context for asymmetric keys:
COSE_KDF_Context = [
AlgorithmID : int / tstr, ; AlgID
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; signature of message_1 ||
signature of message_2
]
]
Party U and V are assumed to have pre-established credentials as described in Section 2.1.
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 V sends message_2 to party U. Then party V derives the traffic_secret_0 key as specified Section 5, and labels it with kid_ev.
Party U processes the received message_2 as follows:
The key derivation is identical to Section 11 of [I-D.ietf-cose-msg], using HKDF [RFC5869] agreed during the message exchange.
The context information COSE_KDF_Context is defined as follows:
The tags are either MACs (PSK) or the Signatures (RPK, Cert) of the COSE messages.
COSE\_KDF\_Context = [
AlgorithmID : int / tstr, ; HKDF
SuppPubInfo : [
keyDataLength : uint, ; length
protected : bstr, ; zero length bstr
other : bstr ; MAC/Signature message_1
|| MAC/Signature message_2
],
]
The output from the key derivation is denoted “traffic_secret_0”.
For unauthenticated Diffie-Hellman it is recommended that public information about parties U and V, such as their identifiers, is included in the context information used in the key derivation. In the present case the assumption is that the parties authenticate each other with pre-established credentials, and the tag (MAC/Signature) created with the pre-established credentials is included in the key derivation context.
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.
The identifier of the ephemeral key of party U is used for replay protection of U’s requests.
With the current protocol, key confirmation of the Diffie-Hellman shared secret/traffic keys is performed when the keys are successfully used. The addition of key confirmation to the protocol is for further study.
TODO: Expand on the security considerations in a future version of the draft
TODO
The authors wants to thank Ilari Liusvaara, Jim Schaad and Ludwig Seitz for timely review and helpful comments.
| [I-D.ietf-cose-msg] | Schaad, J., "CBOR Object Signing and Encryption (COSE)", Internet-Draft draft-ietf-cose-msg-14, June 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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. |
An example of COSE_Key structure, representing an ECDH public key, is given in Figure 4, using CBOR’s diagnostic notation. In this example, the ephemeral key is identified by a 4 bytes ‘kid’.
/ ephemeral / -1:{
/ kty / 1:2,
/ kid / 2:h'78f67901',
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590b
bfbf054e1c7b4d91d6280',
/ y / -3:true
}
Figure 4: Example of an ECDH public key formatted as a COSE_Key
The equivalent CBOR encoding is: h’a120a50102024478f67901200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5’, which has a size of 51 bytes.
An example of COSE encoding for payload_1 is given in Figure 5, using CBOR’s diagnostic notation. In this example, the size of the identifier of U’s ephemeral key, kid_eu, is 1 byte.
The payload_1 is:
[
-27, / HKDFs /
null, / N_U /
12, / TCAs /
h'a120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5a
d7590bbfbf054e1c7b4d91d628022f5' / COSE_Key E_U { /
/ ephemeral -1:{ /
/ kty 1:2, /
/ kid 2:h'03', kid_eu /
/ crv -1:1, /
/ x -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfb /
/ f054e1c7b4d91d6280', /
/ y -3:true /
/ } /
/ } /
]
Figure 5: Example of payload of message_1
The equivalent CBOR encoding of the payload is: h’84381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5’, which has a size of 54 bytes.
An example of COSE encoding for message_2 is given in Figure 6 using CBOR’s diagnostic notation. In this example, kid_ev, the identifier of V’s ephemeral public key, is 4 bytes.
The payload is:
[
-27, / HKDF /
null, / N_V /
12, / TCA /
h'a120a5010202442edb61f92001215820acbee6672a28340affce41c721901eb
d7868231bd1d86e41888a07822214050022f5' / COSE_Key E_V { /
/ ephemeral -1:{ /
/ kty 1:2, /
/ kid 2:h'2edb61f9', kid_ev /
/ crv -1:1, /
/ x -2:h'acbee6672a28340affce41c721901ebd7868231bd1d /
/ 86e41888a078222140500', /
/ y -3:true /
/ } /
/ } /
]
Figure 6: Example of payload of message_2
The equivalent CBOR encoding of the payload is: h’84381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5’, which has a size of 57 bytes.
An example of COSE encoding for message_1 is given in Figure 7 using CBOR’s diagnostic notation. In this example, kid_psk, the identifier of PSK is 4 bytes, and the payload is as in Appendix A.2.
The message_1 is:
996(
[
/ protected / h'a201040444e19648b5' / { /
/ alg 1:4, HMAC 256//64 /
/ kid 4:h'e19648b5' kid_psk /
/ } / ,
/ unprotected / {},
/ payload / h'84381af60c582fa120a501020241032001215820
98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4
d91d628022f5', / payload_1 /
/ tag / h'e77fe81c66c3b5c0'
]
)
Figure 7: Example of message_1 authenticated with PSK
The equivalent CBOR encoding is: h’d903e48449a201040444e19648b5a0583684381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f548e77fe81c66c3b5c0’, which has a size of 80 bytes.
An example of COSE encoding for message_2 is given in Figure 8 using CBOR’s diagnostic notation. In this example, kid_psk, the identifier of PSK, is 4 bytes, and the payload is as in Appendix A.3.
The message_2 is:
996(
[
/ protected / h'a201040444e19648b5' / { /
/ alg 1:4, HMAC 256//64 /
/ kid 4:h'e19648b5' kid_psk /
/ } / ,
/ unprotected / {},
/ payload / h'84381af60c5832a120a5010202442edb61f92001215820
acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214
050022f5', / payload_2 /
/ tag / h'6113268ad246f2c9'
]
)
Figure 8: Example of message_2 authenticated with PSK
The equivalent CBOR encoding is: h’d903e48449a201040444e19648b5a0583984381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5486113268ad246f2c9’, which has a size of 83 bytes.
An example of COSE encoding for message_1 is given in Figure 9, using CBOR’s diagnostic notation. In this example, the size of the identifier of the static public key of U, kid_su, is 4 bytes, and the payload is as in Appendix A.2.
The message_1 is:
997(
[
/ protected / h'a201260444c150d41c' / { /
/ alg 1:-7, ECDSA 256 /
/ kid 4:h'c150d41c', kid_c /
/ } / ,
/ unprotected / {},
/ payload / h'84381af60c582fa120a501020241032001215820
98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4
d91d628022f5', / payload_1 /
/ signature / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a
51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64
327be470355c9657ce0'
]
)
Figure 9: Example of message_1 authenticated with RPK
The equivalent CBOR encoding is: h’d903e58449a201260444c150d41ca0583684381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f55840eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327be470355c9657ce0’, which has a size of 137 bytes.
An example of COSE encoding for Message 2 is given in Figure 11, using CBOR’s diagnostic notation. In this example, the size of the identifier of the public key of V, kid_sv, is 4 bytes, and the payload is as in Appendix A.3.
The external_aad is the signature of message_1:
/ external\_aad / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a 51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327 be470355c9657ce0'
Figure 10: Example of external additional authenticated data
The message_2 is:
997(
[
/ protected / h'a2012604447a2af164' / { /
/ alg 1:-7, ECDSA 256 /
/ kid 4:h'7a2af164', kid_sv /
/ } / ,
/ unprotected / {},
/ payload, / h'84381af60c5832a120a5010202442edb61f92001215820acb
ee6672a28340affce41c721901ebd7868231bd1d86e41888a078222140
50022f5', / payload_2 /
/ signature / h'2374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce
5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327
be470355c9657ce0'
]
)
Figure 11: Example of message_2 authenticated with RPK.
The equivalent CBOR encoding is: h’d903e58449a2012604447a2af164a0583984381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f558402374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327be470355c9657ce0’, which has a size of 140 bytes.
An example of COSE encoding for message_1 is given in Figure 12, using CBOR’s diagnostic notation. In this example, the size of the identifier of the static public key of U, kid_su, is 4 bytes, and the payload is as in Appendix A.2.
The message_1 is:
997(
[
/ protected / h'a201260444c150d41c' / { /
/ alg 1:-7, ECDSA 256 /
/ kid 4:h'c150d41c', kid_su /
/ } / ,
/ unprotected / {"x5c": certificate-chain},
/ payload / h'84381af60c582fa120a50102024103200121582098f
50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d9
1d628022f5', / payload_1 /
/ signature / h'eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a
51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64
327be470355c9657ce0'
]
)
Figure 12: Example of message_1 authenticated with Certificate
The equivalent CBOR encoding is: h’d903e58449a201260444c150d41ca163783563 40… 583684381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f55840eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327be470355c9657ce0’,
which has a size of 142 bytes plus the size of the certificate.
An example of COSE encoding for message_2 is given in Figure 13, using CBOR’s diagnostic notation. In this example, the size of the identifier of the static public key of U, kid_su, is 4 bytes, and the payload is as in Appendix A.3.
The message_2 is:
997(
[
/ protected / h'a2012604447a2af164' / { /
/ alg 1:-7, ECDSA 256 /
/ kid 4:h'7a2af164', kid_sv /
/ } / ,
/ unprotected / {"x5c": certificate-chain},
/ payload / h'84381af60c5832a120a5010202442edb61f92001215820
acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214
050022f5', / payload_2 /
/ signature / h'2374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce
5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327
be470355c9657ce0'
]
)
Figure 13: Example of message_2 authenticated with Certificate.
The equivalent CBOR encoding is: h’d903e58449a2012604447a2af164a163783563 40… 583984381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f558402374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327be470355c9657ce0’,
which has a size of 145 bytes plus the size of the certificate.
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. A strawman is sketched here.
The CoAP client makes the following request:
The CoAP server performs the verifications of the COSE object as specified in [I-D.ietf-cose-msg]. If successful, then the server provides the following response: