Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-selander-ace-cose-ecdhe-11
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Göran Selander , John Preuß Mattsson , Francesca Palombini | ||
| Last updated | 2019-01-02 | ||
| Replaced by | draft-selander-lake-edhoc | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-selander-ace-cose-ecdhe-11
quot;Evaluation of Certificate Enrollment over
Application Layer Security", May 2018,
<https://www.nada.kth.se/~ann/exjobb/
alexandros_krontiris.pdf>.
[LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S.,
Fernandez, P., Santa, J., Hernandez-Ramos, J., and A.
Skarmeta, "Enhancing LoRaWAN Security through a
Lightweight and Authenticated Key Management Approach",
June 2018,
<https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6021899/pdf/
sensors-18-01833.pdf>.
[LoRa2] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S.,
Fernandez, P., Santa, J., Hernandez-Ramos, J., and A.
Skarmeta, "Internet Access for LoRaWAN Devices Considering
Security Issues", June 2018,
<https://ants.inf.um.es/~josesanta/doc/GIoTS1.pdf>.
Selander, et al. Expires July 6, 2019 [Page 28]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
[Perez18] Perez, S., Garcia-Carrillo, D., Marin-Lopez, R.,
Hernandez-Ramos, J., Marin-Perez, R., and A. Skarmeta,
"Architecture of security association establishment based
on bootstrapping technologies for enabling critical IoT
infrastructures", October 2018, <http://www.anastacia-
h2020.eu/publications/Architecture_of_security_association
_establishment_based_on_bootstrapping_technologies_for_ena
bling_critical_IoT_infrastructures.pdf>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T.,
and C. Schuermann, "Formal Verification of Ephemeral
Diffie-Hellman Over COSE (EDHOC)", November 2018,
<https://www.springerprofessional.de/en/formal-
verification-of-ephemeral-diffie-hellman-over-cose-
edhoc/16284348>.
Appendix A. Use of CBOR, CDDL and COSE in EDHOC
This Appendix is intended to simplify for implementors not familiar
with CBOR [I-D.ietf-cbor-7049bis], CDDL [I-D.ietf-cbor-cddl], COSE
[RFC8152], and HKDF [RFC5869].
A.1. CBOR and CDDL
The Concise Binary Object Representation (CBOR)
[I-D.ietf-cbor-7049bis] is a data format designed for small code size
and small message size. CBOR builds on the JSON data model but
extends it by e.g. encoding binary data directly without base64
conversion. In addition to the binary CBOR encoding, CBOR also has a
diagnostic notation that is readable and editable by humans. The
Concise Data Definition Language (CDDL) [I-D.ietf-cbor-cddl] provides
a way to express structures for protocol messages and APIs that use
CBOR. [I-D.ietf-cbor-cddl] also extends the diagnostic notation.
CBOR data items are encoded to or decoded from byte strings using a
type-length-value encoding scheme, where the three highest order bits
of the initial byte contain information about the major type. CBOR
supports several different types of data items, in addition to
integers (int, uint), simple values (e.g. null), byte strings (bstr),
Selander, et al. Expires July 6, 2019 [Page 29]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
and text strings (tstr), CBOR also supports arrays [] of data items
and maps {} of pairs of data items. Some examples are given below.
For a complete specification and more examples, see
[I-D.ietf-cbor-7049bis] and [I-D.ietf-cbor-cddl]. We recommend
implementors to get used to CBOR by using the CBOR playground
[CborMe].
Diagnostic Encoded Type
------------------------------------------------------------------
1 0x01 unsigned integer
24 0x1818 unsigned integer
-24 0x37 negative integer
-25 0x3818 negative integer
null 0xf6 simple value
h'12cd' 0x4212cd byte string
'12cd' 0x4431326364 byte string
"12cd" 0x6431326364 text string
<< 1, 2, null >> 0x430102f6 byte string
[ 1, 2, null ] 0x830102f6 array
[_ 1, 2, null ] 0x9f0102f6ff array (indefinite-length)
( 1, 2, null ) 0x0102f6 group
{ 4: h'cd' } 0xa10441cd map
------------------------------------------------------------------
All EDHOC messages consist of a sequence of CBOR encoded data items.
While an EDHOC message in itself is not a CBOR data item, it may be
viewed as the CBOR encoding of an indefinite-length array [_
message_i ] without the first byte (0x9f) and the last byte (0xff),
for i = 1, 2 and 3. The same applies to the EDHOC error message.
The message format specification uses the constructs '.cbor',
'.cborseq' and '~' enabling conversion between different CDDL types
matching different CBOR items with different encodings. Some
examples are given below.
A type (e.g. an uint) may be wrapped in a byte string (bstr), and
back again:
CDDL Type Diagnostic Encoded
------------------------------------------------------------------
uint 24 0x1818
bstr .cbor uint << 24 >> 0x421818
~ bstr .cbor uint 24 0x1818
------------------------------------------------------------------
A array, say of an uint and a byte string, may be converted into a
byte string (bstr):
Selander, et al. Expires July 6, 2019 [Page 30]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
CDDL Type Diagnostic Encoded
--------------------------------------------------------------------
bstr h'cd' 0x41cd
[ uint, bstr ] [ 24, h'cd' ] 0x82181841cd
bstr .cborseq [ uint, bstr ] << 24, h'cd' >> 0x44181841cd
--------------------------------------------------------------------
A.2. COSE
CBOR Object Signing and Encryption (COSE) [RFC8152] describes how to
create and process signatures, message authentication codes, and
encryption using CBOR. COSE builds on JOSE, but is adapted to allow
more efficient processing in constrained devices. EDHOC makes use of
COSE_Key, COSE_Encrypt0, COSE_Sign1, and COSE_KDF_Context objects.
A.2.1. Encryption and Decryption
The COSE parameters used in COSE_Encrypt0 (see Section 5.2 of
[RFC8152]) are constructed as described below. Note that "i" in
"K_i", "IV_i" and "aad_i" is a variable with value i = 2 or 3,
depending on whether the calculation is made over message_2 or
message_3.
o The secret key K_i is a CBOR bstr, generated with the EDHOC-Key-
Derivation function as defined in Section 3.3.
o The initialization vector IV_i is a CBOR bstr, also generated with
the EDHOC-Key-Derivation function as defined in Section 3.3.
o The plaintext is a CBOR bstr. If the application data (UAD and
PAD) is omitted, then plaintext = h'' in the symmetric case, and
plaintext = << ~protected, signature >> in the asymmetric case.
For instance, if protected = h'a10140' and signature = h'050607'
(CBOR encoding 0x43050607), then plaintext = h'a1014043050607'.
o The external_aad is a CBOR bstr. It is always set to aad_i.
COSE constructs the input to the AEAD [RFC5116] as follows:
o The key K is the value of the key K_i.
o The nonce N is the value of the initialization vector IV_i.
o The plaintext P is the value of the COSE plaintext. E.g. if the
COSE plaintext = h'010203', then P = 0x010203.
o The associated data A is the CBOR encoding of:
Selander, et al. Expires July 6, 2019 [Page 31]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
[ "Encrypt0", h'', aad_i ]
This equals the concatenation of 0x8368456e63727970743040 and the
CBOR encoding of aad_i. For instance if aad_2 = h'010203' (CBOR
encoding 0x43010203), then A = 0x8368456e6372797074304043010203.
A.2.2. Signing and Verification
The COSE parameters used in COSE_Sign1 (see Section 4.2 of [RFC8152])
are constructed as described below. Note that "i" in "aad_i" is a
variable with values i = 2 or 3, depending on whether the calculation
is made over message_2 or message_3. Note also that "x" in
"ID_CRED_x" and "CRED_x" is a variable with values x = U or V,
depending on whether it is the credential of U or of V that is used
in the relevant protocol message.
o The key is the private authentication key of U or V. This may be
stored as a COSE_KEY object or as a certificate.
o The protected parameter is a map { abc : ID_CRED_x } wrapped in a
byte string.
o The payload is a bstr containing the CBOR encoding of a COSE_KEY
or a single certificate.
o external_aad = aad_i.
COSE constructs the input to the Signature Algorithm as follows:
o The key is the private authentication key of U or V.
o The message to be signed M is the CBOR encoding of:
[ "Signature1", << { abc : ID_CRED_x } >>, aad_i, CRED_x ]
For instance if abc = 4 (CBOR encoding 0x04), ID_CRED_U = h'1111'
(CBOR encoding 0x421111), aad_3 = h'222222' (CBOR encoding
0x43222222), and CRED_U = h'55555555' (CBOR encoding
0x4455555555), then M =
0x846a5369676e61747572653145A104421111432222224455555555.
A.2.3. Key Derivation
Assuming use of the mandatory-to-implement algorithms HKDF SHA-256
and AES-CCM-16-64-128, the extract phase of HKDF produces a
pseudorandom key (PRK) as follows:
PRK = HMAC-SHA-256( salt, ECDH shared secret )
Selander, et al. Expires July 6, 2019 [Page 32]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
where salt = 0x in the asymmetric case and salt = PSK in the
symmetric case. As the output length L is smaller than the hash
function output size, the expand phase of HKDF consists of a single
HMAC invocation, and K_i and IV_i are therefore the first 16 and 13
bytes, respectively, of
output parameter = HMAC-SHA-256( PRK, info || 0x01 )
where || means byte string concatenation, and info is the CBOR
encoding of
COSE_KDF_Context = [
AlgorithmID,
[ null, null, null ],
[ null, null, null ],
[ keyDataLength, h'', aad_i ]
]
If AES-CCM-16-64-128 then AlgorithmID = 10 and keyDataLength = 128
for K_i, and AlgorithmID = "IV-GENERATION" (CBOR encoding
0x6d49562d47454e45524154494f4e) and keyDataLength = 104 for IV_i.
Hence, if aad_2 = h'aaaa' then
K_2 = HMAC-SHA-256( PRK, 0x840a83f6f6f683f6f6f68318804042aaaa01 )
IV_2 = HMAC-SHA-256( PRK, 0x846d49562d47454e45524154494f4e
83f6f6f683f6f6f68318804042aaaa01 )
Appendix B. Test Vectors
This appendix provides a wealth of test vectors to ease
implementation and ensure interoperability.
TODO: This section needs to be updated.
Appendix C. EDHOC PSK Chaining
An application using EDHOC may want to derive new PSKs to use for
authentication in future EDHOC sessions. In this case, the new PSK
and KID SHOULD be derived as follows where length is the key length
(in bytes) of the AEAD Algorithm.
PSK = EDHOC-Exporter("EDHOC Chaining PSK", length)
KID = EDHOC-Exporter("EDHOC Chaining KID", 4)
Selander, et al. Expires July 6, 2019 [Page 33]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
Appendix D. EDHOC with CoAP and OSCORE
D.1. Transferring EDHOC in CoAP
EDHOC can be transferred as an exchange of CoAP [RFC7252] messages.
By default, the CoAP client is Party U and the CoAP server is Party
V, but the roles SHOULD be chosen to protect the most sensitive
identity, see Section 8. By default, EDHOC is transferred in POST
requests and 2.04 (Changed) responses to the Uri-Path: "/.well-known/
edhoc", but an application may define its own path that can be
discovered e.g. using resource directory
[I-D.ietf-core-resource-directory].
By default, the message flow is as follows: EDHOC message_1 is sent
in the payload of a POST request from the client to the server's
resource for EDHOC. EDHOC message_2 or the EDHOC error message is
sent from the server to the client in the payload of a 2.04 (Changed)
response. EDHOC message_3 or the EDHOC error message is sent from
the client to the server's resource in the payload of a POST request.
If needed, an EDHOC error message is sent from the server to the
client in the payload of a 2.04 (Changed) response.
An example of a successful EDHOC exchange using CoAP is shown in
Figure 5.
Client Server
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc"
| | Content-Format: application/edhoc
| | Payload: EDHOC message_1
| |
|<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/edhoc
| | Payload: EDHOC message_2
| |
+--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc"
| | Content-Format: application/edhoc
| | Payload: EDHOC message_3
| |
|<---------+ Header: 2.04 Changed
| 2.04 |
| |
Figure 5: Example of transferring EDHOC in CoAP
Selander, et al. Expires July 6, 2019 [Page 34]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
D.2. Deriving an OSCORE context from EDHOC
When EDHOC is used to derive parameters for OSCORE
[I-D.ietf-core-object-security], the parties must make sure that the
EDHOC connection identifiers are unique, i.e. C_V MUST NOT be equal
to C_U. In case that the CoAP client is party U and the CoAP server
is party V:
o The client's OSCORE Sender ID is C_V and the server's OSCORE
Sender ID is C_U, as defined in this document
o The AEAD Algorithm and the HMAC-based Key Derivation Function
(HKDF) are the AEAD and HKDF algorithms in the cipher suite
CIPHER_SUITE_U.
o The Master Secret and Master Salt are derived as follows where
length is the key length (in bytes) of the AEAD Algorithm.
Master Secret = EDHOC-Exporter("OSCORE Master Secret", length)
Master Salt = EDHOC-Exporter("OSCORE Master Salt", 8)
Appendix E. Message Sizes
This appendix gives an estimate of the message sizes of EDHOC with
different authentication methods. Note that the examples in this
appendix are not test vectors, the cryptographic parts are just
replaced with byte strings of the same length. All examples are
given in CBOR diagnostic notation and hexadecimal.
E.1. Message Sizes RPK
E.1.1. message_1
message_1 = (
1,
h'c3',
0,
0,
h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
1e1f'
)
message_1 (39 bytes):
01 41 C3 00 00 58 20 00 01 02 03 04 05 06 07 08 09 0A 0B 0C
0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
Selander, et al. Expires July 6, 2019 [Page 35]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
E.1.2. message_2
plaintext = <<
{ 4 : 'acdc' },
h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b
3c3d3e3f'
>>
The protected header map is 7 bytes. The length of plaintext is 73
bytes so assuming a 64-bit MAC value the length of ciphertext is 81
bytes.
message_2 = (
null,
h'c4',
h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
1e1f',
h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b
3c3d3e3f404142434445464748494a4b4c4d4e4f50'
)
message_2 (120 bytes):
F6 41 C4 58 20 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 58 51 00
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14
15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28
29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C
3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50
E.1.3. message_3
The plaintext and ciphertext in message_3 are assumed to be of equal
sizes as in message_2.
message_3 = (
h'c3',
h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b
3c3d3e3f404142434445464748494a4b4c4d4e4f50'
)
Selander, et al. Expires July 6, 2019 [Page 36]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
message_3 (85 bytes):
41 C3 58 51 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23
24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37
38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B
4C 4D 4E 4F 50
E.2. Message Sizes Certificates
When the certificates are distributed out-of-band and identified with
the x5t header and a SHA256/64 hash value, the protected header map
will be 13 bytes instead of 7 bytes (assuming labels in the range
-24...23).
protected = << { TDB1 : [ TDB6, h'0001020304050607' ] } >>
When the certificates are identified with the x5chain header, the
message sizes depends on the size of the (truncated) certificate
chains. The protected header map will be 3 bytes + the size of the
certificate chain (assuming a label in the range -24...23).
protected = << { TDB3 : h'0001020304050607...' } >>
E.3. Message Sizes PSK
E.3.1. message_1
message_1 = (
2,
h'c3',
0,
0,
h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
1e1f',
'abba'
)
message_1 (44 bytes):
02 41 C3 00 00 58 20 00 01 02 03 04 05 06 07 08 09 0A 0B 0C
0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
44 61 63 64 63
E.3.2. message_2
Assuming a 0 byte plaintext and a 64-bit MAC value the ciphertext is
8 bytes
Selander, et al. Expires July 6, 2019 [Page 37]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
message_2 = (
null,
h'c4',
h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
1e1f',
h'0001020304050607'
)
message_2 (46 bytes):
F6 41 C4 58 20 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 48 61 62
63 64 65 66 67 68
E.3.3. message_3
The plaintext and ciphertext in message_3 are assumed to be of equal
sizes as in message_2.
message_3 = (
h'c3',
h'0001020304050607'
)
message_3 (11 bytes):
41 C3 48 00 01 02 03 04 05 06 07
E.4. Summary
The previous estimates of typical message sizes are summarized in
Figure 6.
=====================================================================
PSK RPK x5t x5chain
---------------------------------------------------------------------
message_1 44 39 39 39
message_2 46 120 126 116 + Certificate chain
message_3 11 85 91 81 + Certificate chain
---------------------------------------------------------------------
Total 101 244 256 236 + Certificate chains
=====================================================================
Figure 6: Typical message sizes in bytes
Figure 7 compares of message sizes of EDHOC with the DTLS 1.3
handshake [I-D.ietf-tls-dtls13] with connection ID.
Selander, et al. Expires July 6, 2019 [Page 38]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
=====================================================================
Flight #1 #2 #3 Total
---------------------------------------------------------------------
DTLS 1.3 RPK + ECDHE 149 373 213 735
DTLS 1.3 PSK + ECDHE 186 190 57 433
DTLS 1.3 PSK 136 150 57 343
---------------------------------------------------------------------
EDHOC RPK + ECDHE 39 120 85 244
EDHOC PSK + ECDHE 44 46 11 101
=====================================================================
Figure 7: Comparison of message sizes in bytes with Connection ID
Figure 8 compares of message sizes of EDHOC with the DTLS 1.3
[I-D.ietf-tls-dtls13] and TLS 1.3 [RFC8446] handshakes without
connection ID.
=====================================================================
Flight #1 #2 #3 Total
---------------------------------------------------------------------
DTLS 1.3 RPK + ECDHE 143 364 212 721
DTLS 1.3 PSK + ECDHE 180 183 56 419
DTLS 1.3 PSK 130 143 56 329
---------------------------------------------------------------------
TLS 1.3 RPK + ECDHE 129 322 194 645
TLS 1.3 PSK + ECDHE 166 157 50 373
TLS 1.3 PSK 116 117 50 283
---------------------------------------------------------------------
EDHOC RPK + ECDHE 38 119 84 241
EDHOC PSK + ECDHE 44 45 10 98
=====================================================================
Figure 8: Comparison of message sizes in bytes without Connection ID
Acknowledgments
The authors want to thank Alessandro Bruni, Theis Groenbech Petersen,
Dan Harkins, Klaus Hartke, Alexandros Krontiris, Ilari Liusvaara,
Salvador Perez, Michael Richardson, Thorvald Sahl Joergensen, Jim
Schaad, Carsten Schuermann, and Ludwig Seitz for reviewing
intermediate versions of the draft. We are especially indebted to
Jim Schaad for his continuous reviewing and implementation of
different versions of the draft.
Selander, et al. Expires July 6, 2019 [Page 39]
Internet-Draft Ephemeral Diffie-Hellman Over COSE (EDHOC) January 2019
Authors' Addresses
Goeran Selander
Ericsson AB
Email: goran.selander@ericsson.com
John Mattsson
Ericsson AB
Email: john.mattsson@ericsson.com
Francesca Palombini
Ericsson AB
Email: francesca.palombini@ericsson.com
Selander, et al. Expires July 6, 2019 [Page 40]