ACE Working Group G. Selander
Internet-Draft J. Mattsson
Intended status: Standards Track F. Palombini
Expires: September 22, 2016 Ericsson AB
March 21, 2016
Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-selander-ace-cose-ecdhe-00
Abstract
This document specifies the Diffie-Hellman key exchange with
ephemeral keys embedded in messages encoded with the CBOR Encoded
Message Syntax.
Status of This Memo
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 September 22, 2016.
Copyright Notice
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.
Selander, et al. Expires September 22, 2016 [Page 1]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. ECDH Public Keys . . . . . . . . . . . . . . . . . . . . . . 4
2.1. COSE_Key Formatting . . . . . . . . . . . . . . . . . . . 4
2.2. Example: ECDH Public Key . . . . . . . . . . . . . . . . 5
3. Authentication with Pre-Shared Keys . . . . . . . . . . . . . 5
3.1. Message 1 with PSK . . . . . . . . . . . . . . . . . . . 5
3.2. Example: Message 1 with PSK . . . . . . . . . . . . . . . 6
3.3. Message 2 with PSK . . . . . . . . . . . . . . . . . . . 7
3.4. Example: Message 2 with PSK . . . . . . . . . . . . . . . 7
3.5. Key Derivation . . . . . . . . . . . . . . . . . . . . . 8
4. Authentication with Static ECDH Keys . . . . . . . . . . . . 9
4.1. Message 1 with ECDH-SS . . . . . . . . . . . . . . . . . 9
4.2. Example: Message 1 with ECDH-SS . . . . . . . . . . . . . 10
4.3. Message 2 with ECDH-SS . . . . . . . . . . . . . . . . . 12
4.4. Example: Message 2 with ECDH-SS . . . . . . . . . . . . . 13
4.5. Key Derivation . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Implementing EDHOC with CoAP . . . . . . . . . . . . 17
Appendix B. Integrating EDHOC with ACE . . . . . . . . . . . . . 17
Appendix C. Deriving Security Context for OSCOAP . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
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
the CBOR Encoded Message Syntax (COSE, [I-D.ietf-cose-msg]).
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
Selander, et al. Expires September 22, 2016 [Page 2]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
secret key (Section 3) or public keys (Section 4). The pre-
established keys may be transferred to client and server from a
trusted third party, such as an Authorization Server
[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
[I-D.ietf-oauth-pop-key-distribution].
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
[I-D.ietf-tls-tls13].
1.1. Terminology
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 key exchange messages are called "message_1" and "message_2", and
the parties exchanging the messages are called "client" and "server",
see Figure 1. The messages are encoded using the CBOR Encoded
Message Syntax (COSE, [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
[I-D.ietf-tls-tls13].
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
Figure 1: Diffie-Hellman key exchange and key derivation
Selander, et al. Expires September 22, 2016 [Page 3]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
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:
o kid_x and kid_y represent the values of the key identifiers of the
ECDH ephemeral public keys of the client and server, respectively.
o kid_0 represents the value of the key identifier of the pre-shared
key between client and server (Section 3).
o kid_c and kid_s represent the values of the key identifiers of the
ECDH static public keys of the client and server, respectively
(Section 4).
+------------+-----+-----------------------------------------------+
| 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) |
+------------+-----+-----------------------------------------------+
Figure 2: Notation of keys and key identifiers.
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.
2. ECDH Public Keys
This section defines the formatting of the ephemeral public keys g^x
and g^y.
2.1. COSE_Key Formatting
The ECDH ephemeral public key SHALL be formatted as a COSE_Key with
the following fields and values:
o kty: The value SHALL be 2 (Elliptic Curve Keys)
o kid:
Selander, et al. Expires September 22, 2016 [Page 4]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
o crv: The value 1 SHALL be supported by the server (NIST P-256
a.k.a. secp256r1 [RFC4492])
o x:
o y: The value SHOULD be boolean.
TODO: Consider replacing P-256 with Curve25519
2.2. Example: ECDH Public Key
An example of COSE_Key structure, representing an ECDH public key, is
given in Figure 3, using CBOR's diagnostic notation. In this
example, the pre-shared 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 3: Example of an ECDH public key formatted as a COSE_Key
The equivalent CBOR encoding is: h'a120a50102024478f67901200121582098
f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5',
which has a size of 50 bytes.
3. Authentication with Pre-Shared Keys
This section defines the DH key exchange protocol messages, when the
MAC is calculated with a pre-shared key.
The client and server are assumed to have a pre-shared key, PSK, the
value of its identifier is represented by kid_0.
3.1. Message 1 with PSK
message_1 contains the client's ephemeral public key, g^x, and a MAC
over g^x, calculated with the pre-shared key.
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 Section 2, with the 'kid' field omitted.
Selander, et al. Expires September 22, 2016 [Page 5]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
message_1 SHALL have the COSE_Mac0_Tagged structure
[I-D.ietf-cose-msg] with the following fields and values:
o Header
* Protected
+ Alg: 4 (HMAC 256/64)
+ Kid: kid_0
* Unprotected: Empty, except for the case specified in Appendix B
o Payload: g^x ('kid' field omitted)
o Tag: As in section 6.3 of [I-D.ietf-cose-msg]
TODO: Error handling
3.2. Example: Message 1 with PSK
An example of COSE encoding for message_1 is given in Figure 4 using
CBOR's diagnostic notation. In this example, kid_0, the identifier
of PSK is 4 bytes.
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'
]
)
Figure 4: Example of message_1 authenticated with PSK
Selander, et al. Expires September 22, 2016 [Page 6]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
The equivalent CBOR encoding is: h'd903e48449a201040444e19648b5a0582c
a120a40102200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf05
4e1c7b4d91d628022f548e77fe81c66c3b5c0', which has a size of 70 bytes.
3.3. Message 2 with PSK
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.
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 Section 2,
its identifier (kid_y) SHALL be unique among key identifiers used for
traffic keys by the server.
message_2 SHALL have the COSE_Mac0_Tagged structure
[I-D.ietf-cose-msg] with the following fields and values:
o Header
* Protected
+ Alg: 4 (HMAC 256/64)
+ Kid: kid_0
* Unprotected: empty
o Payload: g^y
o external_aad: message_1
o Tag: as in [I-D.ietf-cose-msg], including the external_aad in the
MAC_structure.
TODO: Error handling
3.4. Example: Message 2 with PSK
An example of COSE encoding for message_2 is given in Figure 5 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.
Selander, et al. Expires September 22, 2016 [Page 7]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
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'
]
)
Figure 5: Example of message_2 authenticated with PSK
The equivalent CBOR encoding is: h'd903e48449a201040444e19648b5a05832
a120a4010202481e6f0c642001215820acbee6672a28340affce41c721901ebd78682
31bd1d86e41888a07822214050022f5486113268ad246f2c9', which has a size
of 76 bytes.
3.5. Key Derivation
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
[I-D.ietf-tls-tls13], using the PSK + ECDHE operational mode and HKDF
[RFC5869] with SHA-256:
o The Static Secret (SS) SHALL be the pre-shared key
o The Ephemeral Secret (ES) SHALL be the ECDH shared secret,
generated from the ephemeral keys, as specified in section 7.3.3.
of [I-D.ietf-tls-tls13]
o The generic string "TLS 1.3, " in HkdfLabel (Section 7.1) SHALL be
replaced by "EDHOC, "
Selander, et al. Expires September 22, 2016 [Page 8]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
o The handshake_hash is replaced by the exchange_hash = SHA-
256(message_1 + message_2), where '+' denotes concatenation of
octet strings
The procedure for deriving "traffic_secret_0" in Section 7 in
[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).
Appendix C provides an example of how to derive a security context
from "traffic_secret_0".
TODO: Align key derivation with that used with ECDH-SS (Section 4).
4. Authentication with Static ECDH Keys
This section defines the DH key exchange protocol messages, when the
MAC is calculated with a key derived from static ECDH keys.
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.
o The client's static public key is denoted g^c, and identified by
kid_c
o The server's static public key is denoted g^s, and identified by
kid_s
4.1. Message 1 with ECDH-SS
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.
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 Section 2, and identified by kid_x.
message_1 SHALL have the COSE_Mac_Tagged structure
[I-D.ietf-cose-msg], with the following fields and values:
o Header
* Protected
+ Alg: 4 (HMAC 256/64)
* Unprotected: empty, except in the specified in Appendix B
Selander, et al. Expires September 22, 2016 [Page 9]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
o Payload: g^x
o Tag: as in [I-D.ietf-cose-msg]
o Recipients
* COSE_recipient
+ Header
- Protected
o Alg: -27 (ECDH-SS + HKDF-256)
- Unprotected
o Static Kid: kid_s
o Kid: kid_c
o U Nonce: pseudo-random octet string
+ Ciphertext: nil
TODO: Error handling
4.2. Example: Message 1 with ECDH-SS
An example of COSE encoding for message_1 is given in Figure 6, 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.
Selander, et al. Expires September 22, 2016 [Page 10]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
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''
]
]
]
)
Figure 6: Example of message_1 authenticated with static ECDH keys
The equivalent CBOR encoding is: h'd903e28543a10104a05832a120a5010202
4478f67901200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf05
4e1c7b4d91d628022f5489287cb4ead0c171d818344a101381aa32244c150d41c0444
f6b705523558204d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d19558ccfec7d34b
824f42d9140', which has a size of 126 bytes.
Selander, et al. Expires September 22, 2016 [Page 11]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
4.3. Message 2 with ECDH-SS
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).
Before sending message_2, the server SHALL verify message_1. The
server SHALL generate a fresh ephemeral ECDH key pair, formatted as
in Section 2, the value of the key identifier (kid_y) SHALL be unique
among key identifiers used for traffic keys by the server.
message_2 SHALL have the COSE_Mac_Tagged structure
[I-D.ietf-cose-msg] with the following fields and values:
o Header
* Protected
+ Alg: 4 (HMAC 256/64)
* Unprotected: empty
o Payload: g^y
o Tag: as in [I-D.ietf-cose-msg].
o Recipients
* COSE_recipient
+ Header
- Protected
o Alg: -27 (ECDH-SS + HKDF-256)
- Unprotected
o Static Kid: kid_x
o Kid: kid_s
o U Nonce: pseudo-random octet string
+ Ciphertext: nil
TODO: Error handling
Selander, et al. Expires September 22, 2016 [Page 12]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
4.4. Example: Message 2 with ECDH-SS
An example of COSE encoding for Message 2 is given in Figure 7, 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.
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''
]
]
]
)
Figure 7: Example of message_2 authenticated with static ECDH keys
The equivalent CBOR encoding is: h'd903e28543a10104a05832a120a5010202
442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e418
Selander, et al. Expires September 22, 2016 [Page 13]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
88a07822214050022f5482cc75952a7c6dc7f818344a101381aa3224478f679010444
c150d41c35582066aabbadf938799613ccbf8a7da0a15f13be5b43d300aa51fceabc0
7a731232a40', which has a size of 126 bytes.
4.5. Key Derivation
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
[I-D.ietf-tls-tls13], using the ECDHE operational mode and HKDF
[RFC5869] with SHA-256:
o 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 [I-D.ietf-tls-tls13]
o The generic string "TLS 1.3, " in HkdfLabel (Section 7.1) SHALL be
replaced by "EDHOC, "
o The handshake_hash is replaced by the exchange_hash = SHA-
256(message_1 + message_2), where '+' denotes concatenation of
octet strings
The procedure for deriving "traffic_secret_0" in Section 7 in
[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).
Appendix C provides an example of how to derive a security context
from "traffic_secret_0".
TODO: Align key derivation with that used with ECDH-SS.
5. Security Considerations
After the key derivation is completed, the intermediate computed
values should be securely deleted, along with any ephemeral ECDH
secrets.
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.
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.
Selander, et al. Expires September 22, 2016 [Page 14]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
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.
6. Privacy Considerations
TBD
7. IANA Considerations
8. Acknowledgments
The authors wish to thank Ludwig Seitz for timely review and helpful
comments.
9. References
9.1. Normative References
[I-D.ietf-cose-msg]
Schaad, J., "CBOR Encoded Message Syntax", draft-ietf-
cose-msg-10 (work in progress), February 2016.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-11 (work in progress),
December 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[I-D.hartke-core-e2e-security-reqs]
Selander, G., Palombini, F., Hartke, K., and L. Seitz,
"Requirements for CoAP End-To-End Security", draft-hartke-
core-e2e-security-reqs-00 (work in progress), March 2016.
Selander, et al. Expires September 22, 2016 [Page 15]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authorization for the Internet of Things
using OAuth 2.0", draft-ietf-ace-oauth-authz-01 (work in
progress), February 2016.
[I-D.ietf-oauth-pop-key-distribution]
Bradley, J., Hunt, P., Jones, M., and H. Tschofenig,
"OAuth 2.0 Proof-of-Possession: Authorization Server to
Client Key Distribution", draft-ietf-oauth-pop-key-
distribution-02 (work in progress), October 2015.
[I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-selander-ace-
object-security-03 (work in progress), October 2015.
[I-D.wahlstroem-ace-cbor-web-token]
Wahlstroem, E., Jones, M., and H. Tschofenig, "CBOR Web
Token (CWT)", draft-wahlstroem-ace-cbor-web-token-00 (work
in progress), December 2015.
[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,
<http://www.rfc-editor.org/info/rfc4492>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>.
Selander, et al. Expires September 22, 2016 [Page 16]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
Appendix A. Implementing EDHOC with CoAP
The DH key exchange specified in this document can be implemented as
a CoAP [RFC7252] message exchange. A strawman is sketched here.
The client makes the following request:
o The request method is POST
o Content-Format is "application/cose+cbor"
o The Uri-Path is "edhoc"
o The Payload is message_1
The 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:
o The response Code is 2.04 (Changed)
o The Payload is message_2
Appendix B. Integrating EDHOC with ACE
A pre-requisite for using the DH key exchange protocols in Section 3
and Section 4 of this document is that some static keys are pre-
established in client and server. The ACE framework
[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 Section 3 and Section 4, respectively.
The ACE protocol specifies a client making a 'token request' to the
AS to retrieve an access token (JWT [RFC7519], or CWT
[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:
POST /authz-info
The access token may also contain a shared secret key or the public
key of the client, for use by the server.
In case of symmetric keys, the AS generates this key and protects it
for the client and server, after which the protocol in Section 3 can
start.
Selander, et al. Expires September 22, 2016 [Page 17]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
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.
Since the protocol in Section 4 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.
The transfer of the access token as defined in
[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:
POST /authz-info-edhoc
The strawman in Appendix A applies also to this case.
Appendix C. Deriving Security Context for OSCOAP
In this section we show how to establish security context for OSCOAP
[I-D.selander-ace-object-security], using the method specified in
this document.
We assume that "traffic_secret_0" has been established, e.g. as
described in Appendix 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
[I-D.selander-ace-object-security]. The computation of keying
material mimics the traffic key calculation of Section 7.3 in TLS 1.3
[I-D.ietf-tls-tls13] using HKDF with SHA-256 and the following
parameters:
o Secret = traffic_secret_0
o phase = "application data key expansion"
Selander, et al. Expires September 22, 2016 [Page 18]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) March 2016
o purpose = "client write key" / "server write key" / "client write
IV" / "server write IV"
o handshake_context = message_1 + message_2, the concatenation of
the exchanged messages
o key_length for key and IV is algorithm specific.
The first three bullets are identical to TLS 1.3.
With the mandatory OSCOAP algorithm AES-CCM-64-64-128 (see
Section 10.2 in [I-D.ietf-cose-msg]), key_length for the keys is 128
bits and key_length for the static IVs is 56 bits.
The Context Identifier (Cid) is set to the key identifier of
traffic_secret_0 (i.e. kid_y, using the terminology of Section 3 and
Section 4).
Authors' Addresses
Goeran Selander
Ericsson AB
Farogatan 6
Kista SE-16480 Stockholm
Sweden
Email: goran.selander@ericsson.com
John Mattsson
Ericsson AB
Farogatan 6
Kista SE-16480 Stockholm
Sweden
Email: john.mattsson@ericsson.com
Francesca Palombini
Ericsson AB
Farogatan 6
Kista SE-16480 Stockholm
Sweden
Email: francesca.palombini@ericsson.com
Selander, et al. Expires September 22, 2016 [Page 19]