draft-ietf-lake-edhoc-03.txt   draft-ietf-lake-edhoc-04.txt 
Network Working Group G. Selander Network Working Group G. Selander
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Intended status: Standards Track F. Palombini Intended status: Standards Track F. Palombini
Expires: June 21, 2021 Ericsson AB Expires: July 31, 2021 Ericsson AB
December 18, 2020 January 27, 2021
Ephemeral Diffie-Hellman Over COSE (EDHOC) Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-edhoc-03 draft-ietf-lake-edhoc-04
Abstract Abstract
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
very compact, and lightweight authenticated Diffie-Hellman key very compact and lightweight authenticated Diffie-Hellman key
exchange with ephemeral keys. EDHOC provides mutual authentication, exchange with ephemeral keys. EDHOC provides mutual authentication,
perfect forward secrecy, and identity protection. EDHOC is intended perfect forward secrecy, and identity protection. EDHOC is intended
for usage in constrained scenarios and a main use case is to for usage in constrained scenarios and a main use case is to
establish an OSCORE security context. By reusing COSE for establish an OSCORE security context. By reusing COSE for
cryptography, CBOR for encoding, and CoAP for transport, the cryptography, CBOR for encoding, and CoAP for transport, the
additional code size can be kept very low. additional code size can be kept very low.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2021. This Internet-Draft will expire on July 31, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale for EDHOC . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Requirements Language . . . . . . . . . . 6 1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 5
1.4. Document Structure . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology and Requirements Language . . . . . . . . . . 5
2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 6 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Method and Correlation . . . . . . . . . . . . . . . . . 9 3.2. Method and Correlation . . . . . . . . . . . . . . . . . 8
3.3. Authentication Parameters . . . . . . . . . . . . . . . . 11 3.3. Authentication Parameters . . . . . . . . . . . . . . . . 10
3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 14
3.5. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 16 3.5. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 16
3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 16 3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 16
3.7. Communication of Protocol Features . . . . . . . . . . . 17 3.7. Communication of Protocol Features . . . . . . . . . . . 16
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 17 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. EDHOC-Exporter Interface . . . . . . . . . . . . . . . . 19 4.1. EDHOC-Exporter Interface . . . . . . . . . . . . . . . . 19
5. Message Formatting and Processing . . . . . . . . . . . . . . 20 5. Message Formatting and Processing . . . . . . . . . . . . . . 20
5.1. Encoding of bstr_identifier . . . . . . . . . . . . . . . 20 5.1. Encoding of bstr_identifier . . . . . . . . . . . . . . . 20
5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 21 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 20
5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 23 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 22
5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 26 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 25
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 29 6.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 29
7. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 32 7. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 32
7.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 32 7.1. EDHOC Message 4 . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 7.2. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 33
8.1. Security Properties . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8.2. Cryptographic Considerations . . . . . . . . . . . . . . 36 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 36
8.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 37 8.2. Cryptographic Considerations . . . . . . . . . . . . . . 38
8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 37 8.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 38
8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 38 8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 39
8.6. Implementation Considerations . . . . . . . . . . . . . . 38 8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 39
8.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 39 8.6. Implementation Considerations . . . . . . . . . . . . . . 39
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 40
9.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 39 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
9.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 41 9.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 41
9.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 41 9.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 42
9.4. Media Types Registry . . . . . . . . . . . . . . . . . . 41 9.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 42
9.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 42 9.4. Media Types Registry . . . . . . . . . . . . . . . . . . 42
9.6. Expert Review Instructions . . . . . . . . . . . . . . . 42 9.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.6. Expert Review Instructions . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 43 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 44
Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 47 10.2. Informative References . . . . . . . . . . . . . . . . . 46
A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 47 Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 49
A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 48 A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 50
B.1. Test Vectors for EDHOC Authenticated with Signature Keys B.1. Test Vectors for EDHOC Authenticated with Signature Keys
(x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 48 (x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.2. Test Vectors for EDHOC Authenticated with Static Diffie- B.2. Test Vectors for EDHOC Authenticated with Static Diffie-
Hellman Keys . . . . . . . . . . . . . . . . . . . . . . 63 Hellman Keys . . . . . . . . . . . . . . . . . . . . . . 67
Appendix C. Applicability Statement Template . . . . . . . . . . 76 Appendix C. Applicability Statement Template . . . . . . . . . . 81
C.1. Use of EDHOC in the XX Protocol . . . . . . . . . . . . . 76 C.1. Use of EDHOC in the XX Protocol . . . . . . . . . . . . . 82
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83
1. Introduction 1. Introduction
Security at the application layer provides an attractive option for 1.1. Motivation
protecting Internet of Things (IoT) deployments, for example where
protection needs to work over a variety of underlying protocols. IoT Many Internet of Things (IoT) deployments require technologies which
are highly performant in constrained environments [RFC7228]. IoT
devices may be constrained in various ways, including memory, devices may be constrained in various ways, including memory,
storage, processing capacity, and energy [RFC7228]. A method for storage, processing capacity and power. The connectivity for these
protecting individual messages at the application layer suitable for settings may also exhibit constraints such as unreliable and lossy
constrained devices, is provided by CBOR Object Signing and channels, highly restricted bandwidth and dynamic topology. The IETF
Encryption (COSE) [RFC8152]), which builds on the Concise Binary has acknowledged this problem by standardizing a range of lightweight
Object Representation (CBOR) [RFC8949]. Object Security for protocols and enablers designed for the IoT, including the
Constrained RESTful Environments (OSCORE) [RFC8613] is a method for Constrained Application Protocol (CoAP, [RFC7252]), Concise Binary
application-layer protection of the Constrained Application Protocol Object Representation (CBOR, [RFC8949]), and Static Context Header
(CoAP), using COSE. Compression (SCHC, [RFC8724]).
In order for a communication session to provide forward secrecy, the The need for special protocols targeting constrained IoT deployments
communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH) extends also to the security domain [I-D.ietf-lake-reqs]. Important
key exchange protocol with ephemeral keys, from which shared key characteristics in constrained environments are the number of round
material can be derived. This document specifies Ephemeral Diffie- trips and protocol message sizes, which if kept low can contribute to
Hellman Over COSE (EDHOC), a lightweight key exchange protocol good performance by enabling transport over a small number of radio
providing perfect forward secrecy and identity protection. frames, reducing latency due to fragmentation or duty cycles, etc.
Authentication is based on credentials established out of band, e.g. Another important criteria is code size, which may be prohibitive for
from a trusted third party, such as an Authorization Server as certain deployments due to device capabilities or network load during
specified by [I-D.ietf-ace-oauth-authz]. The construction provided firmware update. Some IoT deployments also need to support a variety
by EDHOC can be applied to authenticate raw public keys (RPK) and of underlying transport technologies, potentially even with a single
public key certificates. This version of the protocol is focusing on connection.
RPK and certificates by reference which is the initial focus for the
LAKE WG (see Section 2.2 of [I-D.ietf-lake-reqs]).
After successful completion of the EDHOC protocol, application keys Some security solutions for such settings exist already. CBOR Object
and other application specific data can be derived using the EDHOC- Signing and Encryption (COSE) [RFC8152]) specifies basic application-
Exporter interface. A main use case for EDHOC is to establish an layer security services efficiently encoded in CBOR. Another example
OSCORE security context. EDHOC uses COSE for cryptography, CBOR for is Object Security for Constrained RESTful Environments (OSCORE)
encoding, and CoAP for transport. By reusing existing libraries, the [RFC8613] which is a lightweight communication security extension to
additional code footprint can be kept very low. CoAP using CBOR and COSE. In order to establish good quality
cryptographic keys for security protocols such as COSE and OSCORE,
the two endpoints may run an authenticated key exchange protocol,
from which shared secret key material can be derived. Such a key
exchange protocol should also be lightweight; to prevent bad
performance in case of repeated use, e.g., due to device rebooting or
frequent rekeying for security reasons; or to avoid latencies in a
network formation setting with many devices authenticating at the
same time.
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including perfect forward secrecy, identity
protection, and cipher suite negotation. Authentication can be based
on raw public keys (RPK) or public key certificates, and requires the
application to provide input on how to verify that endpoints are
trusted. This specificaton focuses on referencing instead of
transporting credentials to reduce message overhead.
EDHOC makes use of known protocol constructions, such as SIGMA
[SIGMA] and Extract-and-Expand [RFC5869]. COSE also provides crypto
agility and enables the use of future algorithms targeting IoT.
1.2. Use of EDHOC
EDHOC is designed for highly constrained settings making it EDHOC is designed for highly constrained settings making it
especially suitable for low-power wide area networks [RFC8376] such especially suitable for low-power wide area networks [RFC8376] such
as Cellular IoT, 6TiSCH, and LoRaWAN. Compared to the DTLS 1.3 as Cellular IoT, 6TiSCH, and LoRaWAN. A main objective for EDHOC is
handshake [I-D.ietf-tls-dtls13] with ECDH and connection ID, the to be a lightweight AKE for OSCORE, i.e. to provide authentication
number of bytes in EDHOC + CoAP can be less than 1/6 when RPK and session key establishment for IoT use cases such as those built
authentication is used, see on CoAP [RFC7252]. CoAP is a specialized web transfer protocol for
use with constrained nodes and networks, providing a request/response
interaction model between application endpoints. As such, EDHOC is
targeting a large variety of use cases involving 'things' with
embedded microcontrollers, sensors and actuators.
A typical setting is when one of the endpoints is constrained or in a
constrained network, and the other endpoint is a node on the Internet
(such as a mobile phone) or at the edge of the constrained network
(such as a gateway). Thing-to-thing interactions over constrained
networks are also relevant since both endpoints would then benefit
from the lightweight properties of the protocol. EDHOC could e.g. be
run when a device/device(s) connect(s) for the first time, or to
establish fresh keys which are not revealed by a later compromise of
the long-term keys. Further security properties are described in
Section 8.1.
EDHOC builds on the same lightweight primitives as OSCORE: CBOR for
encoding, COSE for cryptography, and CoAP for transport. By reusing
existing libraries the additional code size can be kept very low.
EDHOC is not bound to a particular transport, but it is recommended
to transfer EDHOC messages in CoAP payloads.
1.3. Message Size Examples
Compared to the DTLS 1.3 handshake [I-D.ietf-tls-dtls13] with ECDH
and connection ID, the number of bytes in EDHOC + CoAP can be less
than 1/6 when RPK authentication is used, see
[I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows two [I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows two
examples of message sizes for EDHOC with different kinds of examples of message sizes for EDHOC with different kinds of
authentication keys and different COSE header parameters for authentication keys and different COSE header parameters for
identification: static Diffie-Hellman keys identified by 'kid' identification: static Diffie-Hellman keys identified by 'kid'
[RFC8152], and X.509 signature certificates identified by a hash [RFC8152], and X.509 signature certificates identified by a hash
value using 'x5t' [I-D.ietf-cose-x509]. Further reductions of value using 'x5t' [I-D.ietf-cose-x509]. Further reductions of
message sizes are possible, for example by eliding redundant length message sizes are possible, for example by eliding redundant length
indications. indications.
================================= =================================
skipping to change at page 4, line 34 skipping to change at page 5, line 37
--------------------------------- ---------------------------------
message_1 37 37 message_1 37 37
message_2 46 117 message_2 46 117
message_3 20 91 message_3 20 91
---------------------------------- ----------------------------------
Total 103 245 Total 103 245
================================= =================================
Figure 1: Example of message sizes in bytes. Figure 1: Example of message sizes in bytes.
The ECDH exchange and the key derivation follow known protocol 1.4. Document Structure
constructions such as [SIGMA], NIST SP-800-56A [SP-800-56A], and
Extract-and-Expand [RFC5869]. CBOR [RFC8949] and COSE [RFC8152] are
used to implement these standards. The use of COSE provides crypto
agility and enables use of future algorithms and headers designed for
constrained IoT.
This document is organized as follows: Section 2 describes how EDHOC
authenticated with digital signatures builds on SIGMA-I, Section 3
specifies general properties of EDHOC, including message flow and
formatting of the ephemeral public keys, Section 4 specifies the key
derivation, Section 5 specifies EDHOC with signature key and static
Diffie-Hellman key authentication, Section 6 specifies the EDHOC
error message, and Section 7 describes how EDHOC can be transferred
in CoAP and used to establish an OSCORE security context.
1.1. Rationale for EDHOC
Many constrained IoT systems today do not use any security at all,
and when they do, they often do not follow best practices. One
reason is that many current security protocols are not designed with
constrained IoT in mind. Constrained IoT systems often deal with
personal information, valuable business data, and actuators
interacting with the physical world. Not only do such systems need
security and privacy, they often need end-to-end protection with
source authentication and perfect forward secrecy. EDHOC and OSCORE
[RFC8613] enables security following current best practices to
devices and systems where current security protocols are impractical.
EDHOC is optimized for small message sizes and can therefore be sent
over a small number of radio frames. The message size of a key
exchange protocol may have a large impact on the performance of an
IoT deployment, especially in constrained environments. For example,
in a network bootstrapping setting a large number of devices turned
on in a short period of time may result in large latencies caused by
parallel key exchanges. Requirements on network formation time in
constrained environments can be translated into key exchange
overhead. In network technologies with duty cycle, each additional
frame significantly increases the latency even if no other devices
are transmitting.
Power consumption for wireless devices is highly dependent on message
transmission, listening, and reception. For devices that only send a
few bytes occasionally, the battery lifetime may be impacted by a
heavy key exchange protocol. A key exchange may need to be executed
more than once, e.g. due to a device rebooting or for security
reasons such as perfect forward secrecy.
EDHOC is adapted to primitives and protocols designed for the
Internet of Things: EDHOC is built on CBOR and COSE which enables
small message overhead and efficient parsing in constrained devices.
EDHOC is not bound to a particular transport layer, but it is
recommended to transport the EDHOC message in CoAP payloads. EDHOC
is not bound to a particular communication security protocol but
works off-the-shelf with OSCORE [RFC8613] providing the necessary
input parameters with required properties. Maximum code complexity
(ROM/Flash) is often a constraint in many devices and by reusing
already existing libraries, the additional code footprint for EDHOC +
OSCORE can be kept very low.
1.2. Use of EDHOC
EDHOC is designed as a lightweight AKE for OSCORE, i.e. to provide
authentication and session key establishment for IoT use cases such
as those built on CoAP [RFC7252]. CoAP is a specialized web transfer
protocol for use with constrained nodes and networks, providing a
request/response interaction model between application endpoints. As
such, EDHOC is targeting a large variety of use cases involving
'things' with embedded microcontrollers, sensors and actuators.
A typical setting is when one of the endpoints is constrained or in a The remainder of the document is organized as follows: Section 2
constrained network, and the other endpoint is a node on the Internet outlines EDHOC authenticated with digital signatures, Section 3
(such as a mobile phone) or at the edge of the constrained network describes the protocol elements of EDHOC, including message flow,
(such as a gateway). Thing-to-thing interactions over constrained formatting of the ephemeral public keys, and key derivation,
networks are also relevant since both endpoints would then benefit Section 5 specifies EDHOC with authentication based on signature keys
from the lightweight properties of the protocol. EDHOC could e.g. be or static Diffie-Hellman keys, Section 6 specifies the EDHOC error
run when a device/device(s) connect(s) for the first time, or to message, and Section 7 describes how EDHOC can be transferred in CoAP
establish fresh keys which are not compromised by a later compromise and used to establish an OSCORE security context.
of the long-term keys. (Further security properties are described in
Section 8.1.)
1.3. Terminology and Requirements Language 1.5. Terminology and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE
[RFC8152], and CDDL [RFC8610]. The Concise Data Definition Language [RFC8152], and CDDL [RFC8610]. The Concise Data Definition Language
(CDDL) is used to express CBOR data structures [RFC8949]. Examples (CDDL) is used to express CBOR data structures [RFC8949]. Examples
of CBOR and CDDL are provided in Appendix A.1. of CBOR and CDDL are provided in Appendix A.1.
The single output from authenticated encryption (including the
authentication tag) is called 'ciphertext', following [RFC5116].
2. EDHOC Outline 2. EDHOC Outline
EDHOC specifies different authentication methods of the Diffie- EDHOC specifies different authentication methods of the Diffie-
Hellman key exchange: digital signatures and static Diffie-Hellman Hellman key exchange: digital signatures and static Diffie-Hellman
keys. This section outlines the digital signature based method. keys. This section outlines the digital signature based method.
Further details of protocol elements and other authentication methods Further details of protocol elements and other authentication methods
are provided in the remainder of this document. are provided in the remainder of this document.
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS
skipping to change at page 9, line 10 skipping to change at page 8, line 33
The Initiator can derive symmetric application keys after creating The Initiator can derive symmetric application keys after creating
EDHOC message_3, see Section 4.1. Application protected data can EDHOC message_3, see Section 4.1. Application protected data can
therefore be sent in parallel with EDHOC message_3, optionally in the therefore be sent in parallel with EDHOC message_3, optionally in the
same CoAP message [I-D.palombini-core-oscore-edhoc]. same CoAP message [I-D.palombini-core-oscore-edhoc].
Initiator Responder Initiator Responder
| METHOD_CORR, SUITES_I, G_X, C_I, AD_1 | | METHOD_CORR, SUITES_I, G_X, C_I, AD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
| | | |
| C_I, G_Y, C_R, Enc(K_2e; ID_CRED_R, Signature_or_MAC_2, AD_2) | | C_I, G_Y, C_R, Enc(ID_CRED_R, Signature_or_MAC_2, AD_2) |
|<------------------------------------------------------------------+ |<------------------------------------------------------------------+
| message_2 | | message_2 |
| | | |
| C_R, AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, AD_3) | | C_R, AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, AD_3) |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_3 | | message_3 |
Figure 3: EDHOC Message Flow Figure 3: EDHOC Message Flow
3.2. Method and Correlation 3.2. Method and Correlation
skipping to change at page 11, line 6 skipping to change at page 10, line 28
o corr = 1, the transport provides a correlation mechanism that o corr = 1, the transport provides a correlation mechanism that
enables the Responder to correlate message_2 and message_1. enables the Responder to correlate message_2 and message_1.
o corr = 2, the transport provides a correlation mechanism that o corr = 2, the transport provides a correlation mechanism that
enables the Initiator to correlate message_3 and message_2. enables the Initiator to correlate message_3 and message_2.
o corr = 3, the transport provides a correlation mechanism that o corr = 3, the transport provides a correlation mechanism that
enables both parties to correlate all three messages. enables both parties to correlate all three messages.
For example, if the key exchange is transported over CoAP, the CoAP For example, if the key exchange is transported over CoAP, the CoAP
Token can be used to correlate messages, see Section 7.1. Token can be used to correlate messages, see Section 7.2.
3.3. Authentication Parameters 3.3. Authentication Parameters
3.3.1. Authentication Keys 3.3.1. Authentication Keys
The authentication key MUST be a signature key or static Diffie- The authentication key MUST be a signature key or static Diffie-
Hellman key. The Initiator and the Responder MAY use different types Hellman key. The Initiator and the Responder MAY use different types
of authentication keys, e.g. one uses a signature key and the other of authentication keys, e.g. one uses a signature key and the other
uses a static Diffie-Hellman key. When using a signature key, the uses a static Diffie-Hellman key. When using a signature key, the
authentication is provided by a signature. When using a static authentication is provided by a signature. When using a static
skipping to change at page 14, line 19 skipping to change at page 13, line 38
CBOR maps containing COSE Common Header Parameters, see Section 3.1 CBOR maps containing COSE Common Header Parameters, see Section 3.1
of [RFC8152]). In the following we give some examples of COSE of [RFC8152]). In the following we give some examples of COSE
header_maps. header_maps.
Raw public keys are most optimally stored as COSE_Key objects and Raw public keys are most optimally stored as COSE_Key objects and
identified with a 'kid' parameter: identified with a 'kid' parameter:
o ID_CRED_x = { 4 : kid_x }, where kid_x : bstr, for x = I or R. o ID_CRED_x = { 4 : kid_x }, where kid_x : bstr, for x = I or R.
Public key certificates can be identified in different ways. Header Public key certificates can be identified in different ways. Header
parameters for identifying X.509 certificates are defined in parameters for identifying CBOR certificates and X.509 certificates
are defined in [I-D.mattsson-cose-cbor-cert-compress] and
[I-D.ietf-cose-x509], for example: [I-D.ietf-cose-x509], for example:
o by a hash value with the 'x5t' parameter; o by a hash value with the 'c5t' or 'x5t' parameters;
* ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, * ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
o by a URL with the 'x5u' parameter; * ID_CRED_x = { TDB3 : COSE_CertHash }, for x = I or R,
o by a URI with the 'c5u' or 'x5u' parameters;
* ID_CRED_x = { 35 : uri }, for x = I or R, * ID_CRED_x = { 35 : uri }, for x = I or R,
* ID_CRED_x = { TBD4 : uri }, for x = I or R,
ID_CRED_x MAY contain the actual credential used for authentication, ID_CRED_x MAY contain the actual credential used for authentication,
CRED_x. It is RECOMMENDED that they uniquely identify the public CRED_x. It is RECOMMENDED that they uniquely identify the public
authentication key as the recipient may otherwise have to try several authentication key as the recipient may otherwise have to try several
keys. ID_CRED_I and ID_CRED_R are transported in the ciphertext, see keys. ID_CRED_I and ID_CRED_R are transported in the 'ciphertext',
Section 5.4 and Section 5.3. see Section 5.4 and Section 5.3.
When ID_CRED_x does not contain the actual credential it may be very When ID_CRED_x does not contain the actual credential it may be very
short. One byte credential identifiers are realistic in many short. One byte credential identifiers are realistic in many
scenarios as most constrained devices only have a few keys. In cases scenarios as most constrained devices only have a few keys. In cases
where a node only has one key, the identifier may even be the empty where a node only has one key, the identifier may even be the empty
byte string. byte string.
3.4. Cipher Suites 3.4. Cipher Suites
An EDHOC cipher suite consists of an ordered set of COSE code points An EDHOC cipher suite consists of an ordered set of COSE code points
skipping to change at page 17, line 45 skipping to change at page 17, line 31
material (OKM) from the PRKs. The PRKs are derived using Extract. material (OKM) from the PRKs. The PRKs are derived using Extract.
PRK = Extract( salt, IKM ) PRK = Extract( salt, IKM )
If the EDHOC hash algorithm is SHA-2, then Extract( salt, IKM ) = If the EDHOC hash algorithm is SHA-2, then Extract( salt, IKM ) =
HKDF-Extract( salt, IKM ) [RFC5869]. If the EDHOC hash algorithm is HKDF-Extract( salt, IKM ) [RFC5869]. If the EDHOC hash algorithm is
SHAKE128, then Extract( salt, IKM ) = KMAC128( salt, IKM, 256, "" ). SHAKE128, then Extract( salt, IKM ) = KMAC128( salt, IKM, 256, "" ).
If the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM ) = If the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM ) =
KMAC256( salt, IKM, 512, "" ). KMAC256( salt, IKM, 512, "" ).
PRK_2e is used to derive key and IV to encrypt message_2. PRK_3e2m PRK_2e is used to derive a keystream to encrypt message_2. PRK_3e2m
is used to derive keys and IVs produce a MAC in message_2 and to is used to derive keys and IVs to produce a MAC in message_2 and to
encrypt message_3. PRK_4x3m is used to derive keys and IVs produce a encrypt message_3. PRK_4x3m is used to derive keys and IVs to
MAC in message_3 and to derive application specific data. produce a MAC in message_3 and to derive application specific data.
PRK_2e is derived with the following input: PRK_2e is derived with the following input:
o The salt SHALL be the empty byte string. Note that [RFC5869] o The salt SHALL be the empty byte string. Note that [RFC5869]
specifies that if the salt is not provided, it is set to a string specifies that if the salt is not provided, it is set to a string
of zeros (see Section 2.2 of [RFC5869]). For implementation of zeros (see Section 2.2 of [RFC5869]). For implementation
purposes, not providing the salt is the same as setting the salt purposes, not providing the salt is the same as setting the salt
to the empty byte string. to the empty byte string.
o The input keying material (IKM) SHALL be the ECDH shared secret o The input keying material (IKM) SHALL be the ECDH shared secret
skipping to change at page 19, line 17 skipping to change at page 18, line 47
label : tstr, label : tstr,
length : uint length : uint
] ]
where where
o edhoc_aead_id is an int or tstr containing the algorithm o edhoc_aead_id is an int or tstr containing the algorithm
identifier of the EDHOC AEAD algorithm in the selected cipher identifier of the EDHOC AEAD algorithm in the selected cipher
suite encoded as defined in [RFC8152]. Note that a single fixed suite encoded as defined in [RFC8152]. Note that a single fixed
edhoc_aead_id is used in all invocations of EDHOC-KDF, including edhoc_aead_id is used in all invocations of EDHOC-KDF, including
the derivation of K_2e and invocations of the EDHOC-Exporter. the derivation of KEYSTREAM_2 and invocations of the EDHOC-
Exporter.
o transcript_hash is a bstr set to one of the transcript hashes o transcript_hash is a bstr set to one of the transcript hashes
TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.1. TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.1.
o label is a tstr set to the name of the derived key or IV, i.e. o label is a tstr set to the name of the derived key or IV, i.e.
"K_2m", "IV_2m", "K_2e", "IV_2e", "K_3m", "IV_3m", "K_3ae", or "K_2m", "IV_2m", "KEYSTREAM_2", "K_3m", "IV_3m", "K_3ae", or
"IV_3ae". "IV_3ae".
o length is the length of output keying material (OKM) in bytes o length is the length of output keying material (OKM) in bytes
If the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, length If the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, length
) = HKDF-Expand( PRK, info, length ) [RFC5869]. If the EDHOC hash ) = HKDF-Expand( PRK, info, length ) [RFC5869]. If the EDHOC hash
algorithm is SHAKE128, then Expand( PRK, info, length ) = KMAC128( algorithm is SHAKE128, then Expand( PRK, info, length ) = KMAC128(
PRK, info, L, "" ). If the EDHOC hash algorithm is SHAKE256, then PRK, info, L, "" ). If the EDHOC hash algorithm is SHAKE256, then
Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ). Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ).
K_2e and IV_2e are derived using the transcript hash TH_2 and the KEYSTREAM_2 are derived using the transcript hash TH_2 and the
pseudorandom key PRK_2e. K_2m and IV_2m are derived using the pseudorandom key PRK_2e. K_2m and IV_2m are derived using the
transcript hash TH_2 and the pseudorandom key PRK_3e2m. K_3ae and transcript hash TH_2 and the pseudorandom key PRK_3e2m. K_3ae and
IV_3ae are derived using the transcript hash TH_3 and the IV_3ae are derived using the transcript hash TH_3 and the
pseudorandom key PRK_3e2m. K_3m and IV_3m are derived using the pseudorandom key PRK_3e2m. K_3m and IV_3m are derived using the
transcript hash TH_3 and the pseudorandom key PRK_4x3m. IVs are only transcript hash TH_3 and the pseudorandom key PRK_4x3m. IVs are only
used if the EDHOC AEAD algorithm uses IVs. used if the EDHOC AEAD algorithm uses IVs.
4.1. EDHOC-Exporter Interface 4.1. EDHOC-Exporter Interface
Application keys and other application specific data can be derived Application keys and other application specific data can be derived
skipping to change at page 20, line 10 skipping to change at page 19, line 41
= EDHOC-KDF(PRK_4x3m, TH_4, label, length) = EDHOC-KDF(PRK_4x3m, TH_4, label, length)
where label is a tstr defined by the application and length is a uint where label is a tstr defined by the application and length is a uint
defined by the application. The label SHALL be different for each defined by the application. The label SHALL be different for each
different exporter value. The transcript hash TH_4 is a CBOR encoded different exporter value. The transcript hash TH_4 is a CBOR encoded
bstr and the input to the hash function is a CBOR Sequence. bstr and the input to the hash function is a CBOR Sequence.
TH_4 = H( TH_3, CIPHERTEXT_3 ) TH_4 = H( TH_3, CIPHERTEXT_3 )
where H() is the hash function in the selected cipher suite. Example where H() is the hash function in the selected cipher suite. Example
use of the EDHOC-Exporter is given in Sections 7.1.1. use of the EDHOC-Exporter is given in Sections 7.2.1.
To provide forward secrecy in an even more efficient way than re- To provide forward secrecy in an even more efficient way than re-
running EDHOC, EDHOC provides the function EDHOC-Exporter-FS. When running EDHOC, EDHOC provides the function EDHOC-Rekey-FS. When
EHDOC-Exporter-FS is called the old PRK_4x3m is deleted and the new EHDOC-Rekey-FS is called the old PRK_4x3m is deleted and the new
PRk_4x3m is calculated as a "hash" of the old key using the Extract PRk_4x3m is calculated as a "hash" of the old key using the Extract
function as illustrated by the following pseudocode: function as illustrated by the following pseudocode:
EHDOC-Exporter-FS( nonce ): EHDOC-Rekey-FS( nonce ):
PRK_4x3m = Extract( [ "TH_4", nonce ], PRK_4x3m ) PRK_4x3m = Extract( [ "TH_4", nonce ], PRK_4x3m )
5. Message Formatting and Processing 5. Message Formatting and Processing
This section specifies formatting of the messages and processing This section specifies formatting of the messages and processing
steps. Error messages are specified in Section 6. steps. Error messages are specified in Section 6.
An EDHOC message is encoded as a sequence of CBOR data (CBOR An EDHOC message is encoded as a sequence of CBOR data (CBOR
Sequence, [RFC8742]). Additional optimizations are made to reduce Sequence, [RFC8742]). Additional optimizations are made to reduce
message overhead. message overhead.
skipping to change at page 25, line 4 skipping to change at page 24, line 34
2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1 2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1
object as defined in Section 4.4 of [RFC8152] using the signature object as defined in Section 4.4 of [RFC8152] using the signature
algorithm in the selected cipher suite, the private authentication algorithm in the selected cipher suite, the private authentication
key of the Responder, and the following parameters: key of the Responder, and the following parameters:
* protected = << ID_CRED_R >> * protected = << ID_CRED_R >>
* external_aad = << TH_2, CRED_R, ? AD_2 >> * external_aad = << TH_2, CRED_R, ? AD_2 >>
* payload = MAC_2 * payload = MAC_2
COSE constructs the input to the Signature Algorithm as: COSE constructs the input to the Signature Algorithm as:
* The key is the private authentication key of the Responder. * The key is the private authentication key of the Responder.
* The message M to be signed = * The message M to be signed =
[ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >>, [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >>,
MAC_2 ] MAC_2 ]
o Compute an outer COSE_Encrypt0 as defined in Section 5.3 of o CIPHERTEXT_2 is encrypted by using the Expand function as a binary
[RFC8152], with the EDHOC AEAD algorithm in the selected cipher additive stream cipher.
suite, K_2e, IV_2e, and the following parameters. The protected
header SHALL be empty.
* plaintext = ( ID_CRED_R / bstr_identifier, Signature_or_MAC_2, * plaintext = ( ID_CRED_R / bstr_identifier, Signature_or_MAC_2,
? AD_2 ) ? AD_2 )
+ Note that if ID_CRED_R contains a single 'kid' parameter, + Note that if ID_CRED_R contains a single 'kid' parameter,
i.e., ID_CRED_R = { 4 : kid_R }, only the byte string kid_R i.e., ID_CRED_R = { 4 : kid_R }, only the byte string kid_R
is conveyed in the plaintext encoded as a bstr_identifier, is conveyed in the plaintext encoded as a bstr_identifier,
see Section 3.3.4 and Section 5.1. see Section 3.3.4 and Section 5.1.
COSE constructs the input to the AEAD [RFC5116] as follows: * CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2
* Key K = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length )
* Nonce N = EDHOC-KDF( PRK_2e, TH_2, "IV_2e", length )
* Plaintext P = ( ID_CRED_R / bstr_identifier,
Signature_or_MAC_2, ? AD_2 )
* Associated data A = [ "Encrypt0", h'', TH_2 ]
CIPHERTEXT_2 is the 'ciphertext' of the outer COSE_Encrypt0 with
the tag removed.
o Encode message_2 as a sequence of CBOR encoded data items as o Encode message_2 as a sequence of CBOR encoded data items as
specified in Section 5.3.1. specified in Section 5.3.1.
5.3.3. Initiator Processing of Message 2 5.3.3. Initiator Processing of Message 2
The Initiator SHALL process message_2 as follows: The Initiator SHALL process message_2 as follows:
o Decode message_2 (see Appendix A.1). o Decode message_2 (see Appendix A.1).
o Retrieve the protocol state using the connection identifier C_I o Retrieve the protocol state using the connection identifier C_I
and/or other external information such as the CoAP Token and the and/or other external information such as the CoAP Token and the
5-tuple. 5-tuple.
o Decrypt CIPHERTEXT_2 by computing an outer COSE_Encrypt0 as o Decrypt CIPHERTEXT_2, see Section 5.3.2.
defined in see Section 5.3.2 and XORing CIPHERTEXT_2 with the
'ciphertext' of the outer COSE_Encrypt0 with the tag removed.
o Verify that the identity of the Responder is an allowed identity o Verify that the identity of the Responder is an allowed identity
for this connection, see Section 3.3. for this connection, see Section 3.3.
o Verify Signature_or_MAC_2 using the algorithm in the selected o Verify Signature_or_MAC_2 using the algorithm in the selected
cipher suite. The verification process depends on the method, see cipher suite. The verification process depends on the method, see
Section 5.3.2. Section 5.3.2.
o Pass AD_2 to the security application. o Pass AD_2 to the security application.
If any verification step fails, the Responder MUST send an EDHOC If any verification step fails, the Initiator MUST send an EDHOC
error message back, formatted as defined in Section 6, and the error message back, formatted as defined in Section 6, and the
protocol MUST be discontinued. protocol MUST be discontinued.
5.4. EDHOC Message 3 5.4. EDHOC Message 3
5.4.1. Formatting of Message 3 5.4.1. Formatting of Message 3
message_3 and data_3 SHALL be CBOR Sequences (see Appendix A.1) as message_3 and data_3 SHALL be CBOR Sequences (see Appendix A.1) as
defined below defined below
skipping to change at page 29, line 47 skipping to change at page 29, line 15
After verifying message_3, the Responder is assured that the After verifying message_3, the Responder is assured that the
Initiator has calculated the key PRK_4x3m (explicit key confirmation) Initiator has calculated the key PRK_4x3m (explicit key confirmation)
and that no other party than the Responder can compute the key. The and that no other party than the Responder can compute the key. The
Responder can securely send protected application data and store the Responder can securely send protected application data and store the
keying material PRK_4x3m and TH_4. keying material PRK_4x3m and TH_4.
6. Error Handling 6. Error Handling
6.1. EDHOC Error Message 6.1. EDHOC Error Message
This section defines a message format for the EDHOC error message, This section defines a message format for the EDHOC error message.
used during the protocol. An EDHOC error message can be sent by both
parties as a reply to any non-error EDHOC message. After sending an An EDHOC error message can be sent by both parties as a reply to any
error message, the protocol MUST be discontinued. Errors at the non-error EDHOC message. Errors at the EDHOC layer are sent as
EDHOC layer are sent as normal successful messages in the lower normal successful messages in the lower layers (e.g. CoAP POST and
layers (e.g. CoAP POST and 2.04 Changed). An advantage of using 2.04 Changed). An advantage of using such a construction is to avoid
such a construction is to avoid issues created by usage of cross issues created by usage of cross protocol proxies (e.g. UDP to TCP).
protocol proxies (e.g. UDP to TCP).
All error messages in EDHOC are fatal. After sending an error
message, the sender MUST discontinue the protocol. The receiver
SHOULD treat an error message as an indication that the other party
likely has discontinued the protocol. But as the error message is
not authenticated, a received error messages might also have been
sent by an attacker and the receiver MAY therefore try to continue
the protocol.
error SHALL be a CBOR Sequence (see Appendix A.1) as defined below error SHALL be a CBOR Sequence (see Appendix A.1) as defined below
error = ( error = (
? C_x : bstr_identifier, ? C_x : bstr_identifier,
ERR_MSG : tstr, DIAG_MSG : tstr,
? SUITES_R : [ supported : 2* suite ] / suite, ? SUITES_R : [ supported : 2* suite ] / suite,
) )
where: where:
o C_x - (optional) variable length connection identifier, encoded as o C_x - (optional) variable length connection identifier, encoded as
a bstr_identifier (see Section 5.1). If error is sent by the a bstr_identifier (see Section 5.1). If error is sent by the
Responder and corr (METHOD_CORR mod 4) equals 0 or 2 then C_x is Responder and corr (METHOD_CORR mod 4) equals 0 or 2 then C_x is
set to C_I, else if error is sent by the Initiator and corr set to C_I, else if error is sent by the Initiator and corr
(METHOD_CORR mod 4) equals 0 or 1 then C_x is set to C_R, else C_x (METHOD_CORR mod 4) equals 0 or 1 then C_x is set to C_R, else C_x
is omitted. is omitted.
o ERR_MSG - text string containing the diagnostic payload, defined o DIAG_MSG - text string containing the diagnostic message in
in the same way as in Section 5.5.2 of [RFC7252]. ERR_MSG MAY be English. MUST NOT be the empty string unless the error message
a 0-length text string. This text string is mandatory and contains SUITES_R.
characteristic for error messages, which enables the receiver to
distinguish between a normal message and an error message of the
protocol.
o SUITES_R - (optional) cipher suites from SUITES_I or the EDHOC o SUITES_R - (optional) cipher suites from SUITES_I or the EDHOC
cipher suites registry that the Responder supports. SUITES_R MUST cipher suites registry that the Responder supports. SUITES_R MUST
only be included in replies to message_1. If a single supported only be included in replies to message_1. If a single supported
cipher suite is conveyed then the supported cipher suite is cipher suite is conveyed then the supported cipher suite is
encoded as an int instead of an array. encoded as an int instead of an array.
After receiving SUITES_R, the Initiator can determine which selected After receiving SUITES_R, the Initiator can determine which selected
cipher suite to use for the next EDHOC run with the Responder. If cipher suite to use for the next EDHOC run with the Responder. If
the Initiator intends to contact the Responder in the future, the the Initiator intends to contact the Responder in the future, the
Initiator SHOULD remember which selected cipher suite to use until Initiator SHOULD remember which selected cipher suite to use until
the next message_1 has been sent, otherwise the Initiator and the next message_1 has been sent, otherwise the Initiator and
Responder will likely run into an infinite loop. After a successful Responder will likely run into an infinite loop. After a successful
run of EDHOC, the Initiator MAY remember the selected cipher suite to run of EDHOC, the Initiator MAY remember the selected cipher suite to
use in future EDHOC runs. Note that if the Initiator or Responder is use in future EDHOC runs. Note that if the Initiator or Responder is
updated with new cipher suite policies, any cached information may be updated with new cipher suite policies, any cached information may be
outdated. outdated.
Error messages without SUITES_R MUST contain a human-readable
diagnostic message DIAG_MSG written in English, explaning the error
situation. The diagnostic text message is mainly intended for
software engineers that during debugging need to interpret it in the
context of the EDHOC specification. The diagnostic message SHOULD be
be provided to the calling application where they SHOULD be logged.
Error messages with SUITES_R MAY use the empty string as the
diagnostic message. The DIAG_MSG text string is mandatory and
characteristic for error messages, which enables the receiver to
distinguish between a normal message and an error message.
6.1.1. Example Use of EDHOC Error Message with SUITES_R 6.1.1. Example Use of EDHOC Error Message with SUITES_R
Assuming that the Initiator supports the five cipher suites 5, 6, 7, Assuming that the Initiator supports the five cipher suites 5, 6, 7,
8, and 9 in decreasing order of preference, Figures 5 and 6 show 8, and 9 in decreasing order of preference, Figures 5 and 6 show
examples of how the Initiator can truncate SUITES_I and how SUITES_R examples of how the Initiator can truncate SUITES_I and how SUITES_R
is used by the Responder to give the Initiator information about the is used by the Responder to give the Initiator information about the
cipher suites that the Responder supports. cipher suites that the Responder supports.
In Figure 5, the Responder supports cipher suite 6 but not the In Figure 5, the Responder supports cipher suite 6 but not the
initially selected cipher suite 5. initially selected cipher suite 5.
Initiator Responder Initiator Responder
| METHOD_CORR, SUITES_I = 5, G_X, C_I, AD_1 | | METHOD_CORR, SUITES_I = 5, G_X, C_I, AD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
| | | |
| C_I, ERR_MSG, SUITES_R = 6 | | C_I, DIAG_MSG, SUITES_R = 6 |
|<------------------------------------------------------------------+ |<------------------------------------------------------------------+
| error | | error |
| | | |
| METHOD_CORR, SUITES_I = [6, 5, 6], G_X, C_I, AD_1 | | METHOD_CORR, SUITES_I = [6, 5, 6], G_X, C_I, AD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
Figure 5: Example use of error message with SUITES_R. Figure 5: Example use of error message with SUITES_R.
In Figure 6, the Responder supports cipher suite 7 and 9 but not the In Figure 6, the Responder supports cipher suite 7 and 9 but not the
more preferred (by the Initiator) cipher suites 5 and 6. The order more preferred (by the Initiator) cipher suites 5 and 6. The order
of cipher suites in SUITES_R does not matter. of cipher suites in SUITES_R does not matter.
Initiator Responder Initiator Responder
| METHOD_CORR, SUITES_I = 5, G_X, C_I, AD_1 | | METHOD_CORR, SUITES_I = 5, G_X, C_I, AD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
| | | |
| C_I, ERR_MSG, SUITES_R = [9, 7] | | C_I, DIAG_MSG, SUITES_R = [9, 7] |
|<------------------------------------------------------------------+ |<------------------------------------------------------------------+
| error | | error |
| | | |
| METHOD_CORR, SUITES_I = [7, 5, 6, 7], G_X, C_I, AD_1 | | METHOD_CORR, SUITES_I = [7, 5, 6, 7], G_X, C_I, AD_1 |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| message_1 | | message_1 |
Figure 6: Example use of error message with SUITES_R. Figure 6: Example use of error message with SUITES_R.
Note that the Initiator's list of supported cipher suites and order Note that the Initiator's list of supported cipher suites and order
skipping to change at page 32, line 18 skipping to change at page 32, line 7
If the selected cipher suite is not the first cipher suite which the If the selected cipher suite is not the first cipher suite which the
Responder supports in SUITES_I received in message_1, then Responder Responder supports in SUITES_I received in message_1, then Responder
MUST discontinue the protocol, see Section 5.2.3. If SUITES_I in MUST discontinue the protocol, see Section 5.2.3. If SUITES_I in
message_1 is manipulated then the integrity verification of message_2 message_1 is manipulated then the integrity verification of message_2
containing the transcript hash TH_2 = H( message_1, data_2 ) will containing the transcript hash TH_2 = H( message_1, data_2 ) will
fail and the Initiator will discontinue the protocol. fail and the Initiator will discontinue the protocol.
7. Transferring EDHOC and Deriving an OSCORE Context 7. Transferring EDHOC and Deriving an OSCORE Context
7.1. Transferring EDHOC in CoAP 7.1. EDHOC Message 4
This section specifies message_4 which is OPTIONAL to support. Key
confirmation is normally provided by sending an application message
from the Responder to the Initiator, e.g., using OSCORE. In
deployments where no protected application message is sent from the
Responder to the Initiator, the Responder MUST send message_4. Two
examples of such deployments:
1. When EDHOC is only used for authentication and no application
data is sent.
2. When application data is only sent from the Initiator to the
Responder.
7.1.1. Formatting of Message 4
message_4 and data_4 SHALL be CBOR Sequences (see Appendix A.1) as
defined below
message_4 = (
data_4,
MAC_4 : bstr,
)
data_4 = (
? C_I : bstr_identifier,
)
7.1.2. Responder Processing of Message 4
The Responder SHALL compose message_4 as follows:
o If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted,
otherwise C_I is not omitted.
o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of
[RFC8152], with the EDHOC AEAD algorithm in the selected cipher
suite, and the following parameters:
* protected = h''
* external_aad = << TH_4 >>
* plaintext = h''
COSE constructs the input to the AEAD [RFC5116] as follows:
* Key K = EDHOC-Exporter( "EDHOC_message_4_Key", length )
* Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", length )
* Plaintext P = 0x (the empty string)
* Associated data A =
[ "Encrypt0", h'', << TH_4 >> ]
MAC_4 is the 'ciphertext' of the COSE_Encrypt0.
o Encode message_4 as a sequence of CBOR encoded data items as
specified in Section 7.1.1.
7.1.3. Initiator Processing of Message 4
The Initiator SHALL process message_4 as follows:
o Decode message_4 (see Appendix A.1).
o Retrieve the protocol state using the connection identifier C_I
and/or other external information such as the CoAP Token and the
5-tuple.
o Verify MAC_4 as defined in Section 5.3 of [RFC8152], with the
EDHOC AEAD algorithm in the selected cipher suite, and the
parameters defined in Section 7.1.2.
If any verification step fails the Initiator MUST send an EDHOC error
message back, formatted as defined in Section 6, and the protocol
MUST be discontinued.
7.2. Transferring EDHOC in CoAP
It is recommended to transport EDHOC as an exchange of CoAP [RFC7252] It is recommended to transport EDHOC as an exchange of CoAP [RFC7252]
messages. CoAP is a reliable transport that can preserve packet messages. CoAP is a reliable transport that can preserve packet
ordering and handle message duplication. CoAP can also perform ordering and handle message duplication. CoAP can also perform
fragmentation and protect against denial of service attacks. It is fragmentation and protect against denial of service attacks. It is
recommended to carry the EDHOC messages in Confirmable messages, recommended to carry the EDHOC messages in Confirmable messages,
especially if fragmentation is used. especially if fragmentation is used.
By default, the CoAP client is the Initiator and the CoAP server is By default, the CoAP client is the Initiator and the CoAP server is
the Responder, but the roles SHOULD be chosen to protect the most the Responder, but the roles SHOULD be chosen to protect the most
skipping to change at page 32, line 42 skipping to change at page 34, line 16
can be discovered e.g. using resource directory can be discovered e.g. using resource directory
[I-D.ietf-core-resource-directory]. [I-D.ietf-core-resource-directory].
By default, the message flow is as follows: EDHOC message_1 is sent 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 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 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) 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 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. 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 If needed, an EDHOC error message is sent from the server to the
client in the payload of a 2.04 (Changed) response. client in the payload of a 2.04 (Changed) response. Alternatively,
if EDHOC message_4 is used, it is sent from the server to the client
in the payload of a 2.04 (Changed) response analogously to message_2.
An example of a successful EDHOC exchange using CoAP is shown in An example of a successful EDHOC exchange using CoAP is shown in
Figure 7. In this case the CoAP Token enables the Initiator to Figure 7. In this case the CoAP Token enables the Initiator to
correlate message_1 and message_2 so the correlation parameter corr = correlate message_1 and message_2 so the correlation parameter corr =
1. 1.
Client Server Client Server
| | | |
+--------->| Header: POST (Code=0.02) +--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc" | POST | Uri-Path: "/.well-known/edhoc"
skipping to change at page 33, line 34 skipping to change at page 35, line 5
Figure 7: Transferring EDHOC in CoAP when the Initiator is CoAP Figure 7: Transferring EDHOC in CoAP when the Initiator is CoAP
Client Client
The exchange in Figure 7 protects the client identity against active The exchange in Figure 7 protects the client identity against active
attackers and the server identity against passive attackers. An attackers and the server identity against passive attackers. An
alternative exchange that protects the server identity against active alternative exchange that protects the server identity against active
attackers and the client identity against passive attackers is shown attackers and the client identity against passive attackers is shown
in Figure 8. In this case the CoAP Token enables the Responder to in Figure 8. In this case the CoAP Token enables the Responder to
correlate message_2 and message_3 so the correlation parameter corr = correlate message_2 and message_3 so the correlation parameter corr =
2. 2. If EDHOC message_4 is used, it is transported with CoAP in the
payload of a POST request with a 2.04 (Changed) response.
Client Server Client Server
| | | |
+--------->| Header: POST (Code=0.02) +--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc" | POST | Uri-Path: "/.well-known/edhoc"
| | | |
|<---------+ Header: 2.04 Changed |<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/edhoc | 2.04 | Content-Format: application/edhoc
| | Payload: EDHOC message_1 | | Payload: EDHOC message_1
| | | |
skipping to change at page 34, line 35 skipping to change at page 35, line 38
Server Server
To protect against denial-of-service attacks, the CoAP server MAY To protect against denial-of-service attacks, the CoAP server MAY
respond to the first POST request with a 4.01 (Unauthorized) respond to the first POST request with a 4.01 (Unauthorized)
containing an Echo option [I-D.ietf-core-echo-request-tag]. This containing an Echo option [I-D.ietf-core-echo-request-tag]. This
forces the initiator to demonstrate its reachability at its apparent forces the initiator to demonstrate its reachability at its apparent
network address. If message fragmentation is needed, the EDHOC network address. If message fragmentation is needed, the EDHOC
messages may be fragmented using the CoAP Block-Wise Transfer messages may be fragmented using the CoAP Block-Wise Transfer
mechanism [RFC7959]. mechanism [RFC7959].
7.1.1. Deriving an OSCORE Context from EDHOC 7.2.1. Deriving an OSCORE Context from EDHOC
When EDHOC is used to derive parameters for OSCORE [RFC8613], the When EDHOC is used to derive parameters for OSCORE [RFC8613], the
parties make sure that the EDHOC connection identifiers are unique, parties make sure that the EDHOC connection identifiers are unique,
i.e. C_R MUST NOT be equal to C_I. The CoAP client and server MUST i.e. C_R MUST NOT be equal to C_I. The CoAP client and server MUST
be able to retrieve the OSCORE protocol state using its chosen be able to retrieve the OSCORE protocol state using its chosen
connection identifier and optionally other information such as the connection identifier and optionally other information such as the
5-tuple. In case that the CoAP client is the Initiator and the CoAP 5-tuple. In case that the CoAP client is the Initiator and the CoAP
server is the Responder: server is the Responder:
o The client's OSCORE Sender ID is C_R and the server's OSCORE o The client's OSCORE Sender ID is C_R and the server's OSCORE
skipping to change at page 37, line 14 skipping to change at page 38, line 22
a different mechanism. EDHOC implements SIGMA-I using the same Sign- a different mechanism. EDHOC implements SIGMA-I using the same Sign-
then-MAC approach as TLS 1.3. then-MAC approach as TLS 1.3.
To reduce message overhead EDHOC does not use explicit nonces and To reduce message overhead EDHOC does not use explicit nonces and
instead rely on the ephemeral public keys to provide randomness to instead rely on the ephemeral public keys to provide randomness to
each session. A good amount of randomness is important for the key each session. A good amount of randomness is important for the key
generation, to provide liveness, and to protect against interleaving generation, to provide liveness, and to protect against interleaving
attacks. For this reason, the ephemeral keys MUST NOT be reused, and attacks. For this reason, the ephemeral keys MUST NOT be reused, and
both parties SHALL generate fresh random ephemeral key pairs. both parties SHALL generate fresh random ephemeral key pairs.
As discussed the [SIGMA], the encryption of message_2 does only need
to protect against passive attacker as active attackers can always
get the Responders identity by sending their own message_1. EDHOC
uses the Expand function (typically HKDF-Expand) as a binary additive
stream cipher. HKDF-Expand provides better confidentiality than AES-
CTR but is not often used as it is slow on long messages, and most
applications require both IND-CCA confidentiality as well as
integrity protection. For the encryption of message_2, any speed
difference is negligible, IND-CCA does not increase security, and
integrity is provided by the inner MAC (and signature depending on
method).
The choice of key length used in the different algorithms needs to be The choice of key length used in the different algorithms needs to be
harmonized, so that a sufficient security level is maintained for harmonized, so that a sufficient security level is maintained for
certificates, EDHOC, and the protection of application data. The certificates, EDHOC, and the protection of application data. The
Initiator and the Responder should enforce a minimum security level. Initiator and the Responder should enforce a minimum security level.
The data rates in many IoT deployments are very limited. Given that The data rates in many IoT deployments are very limited. Given that
the application keys are protected as well as the long-term the application keys are protected as well as the long-term
authentication keys they can often be used for years or even decades authentication keys they can often be used for years or even decades
before the cryptographic limits are reached. If the application keys before the cryptographic limits are reached. If the application keys
established through EDHOC need to be renewed, the communicating established through EDHOC need to be renewed, the communicating
parties can derive application keys with other labels or run EDHOC parties can derive application keys with other labels or run EDHOC
again. again.
8.3. Cipher Suites 8.3. Cipher Suites
Cipher suite number 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, For many constrained IoT devices it is problematic to support more
Ed25519, AES-CCM-16-64-128, SHA-256) is mandatory to implement. than one cipher suite. Existing devices can be expected to support
Implementations only need to implement the algorithms needed for either ECDSA or EdDSA. To enable as much interoperability as we can
their supported methods. For many constrained IoT devices it is reasonably achieve, less constrained devices SHOULD implement both
problematic to support more than one cipher suites, so some cipher suite 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519,
deployments with P-256 may not support the mandatory cipher suite. AES-CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128,
This is not a problem for local deployments. SHA-256, P-256, ES256, P-256, AES-CCM-16-64-128, SHA-256).
Constrained endpoints SHOULD implement cipher suite 0 or cipher suite
2. Implementations only need to implement the algorithms needed for
their supported methods.
The HMAC algorithm HMAC 256/64 (HMAC w/ SHA-256 truncated to 64 bits) The HMAC algorithm HMAC 256/64 (HMAC w/ SHA-256 truncated to 64 bits)
SHALL NOT be supported for use in EDHOC. SHALL NOT be supported for use in EDHOC.
8.4. Unprotected Data 8.4. Unprotected Data
The Initiator and the Responder must make sure that unprotected data The Initiator and the Responder must make sure that unprotected data
and metadata do not reveal any sensitive information. This also and metadata do not reveal any sensitive information. This also
applies for encrypted data sent to an unauthenticated party. In applies for encrypted data sent to an unauthenticated party. In
particular, it applies to AD_1, ID_CRED_R, AD_2, and ERR_MSG. Using particular, it applies to AD_1, ID_CRED_R, AD_2, and ERR_MSG. Using
skipping to change at page 44, line 47 skipping to change at page 46, line 20
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
10.2. Informative References 10.2. Informative References
skipping to change at page 45, line 48 skipping to change at page 47, line 28
Mattsson, J., Palombini, F., and M. Vucinic, "Comparison Mattsson, J., Palombini, F., and M. Vucinic, "Comparison
of CoAP Security Protocols", draft-ietf-lwig-security- of CoAP Security Protocols", draft-ietf-lwig-security-
protocol-comparison-05 (work in progress), November 2020. protocol-comparison-05 (work in progress), November 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-39 (work in progress), 1.3", draft-ietf-tls-dtls13-39 (work in progress),
November 2020. November 2020.
[I-D.mattsson-cose-cbor-cert-compress]
Raza, S., Hoglund, J., Selander, G., Mattsson, J., and M.
Furuhed, "CBOR Encoding of X.509 Certificates (CBOR
Certificates)", draft-mattsson-cose-cbor-cert-compress-06
(work in progress), January 2021.
[I-D.palombini-core-oscore-edhoc] [I-D.palombini-core-oscore-edhoc]
Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S., Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S.,
and G. Selander, "Combining EDHOC and OSCORE", draft- and G. Selander, "Combining EDHOC and OSCORE", draft-
palombini-core-oscore-edhoc-01 (work in progress), palombini-core-oscore-edhoc-01 (work in progress),
November 2020. November 2020.
[I-D.selander-ace-ake-authz] [I-D.selander-ace-ake-authz]
Selander, G., Mattsson, J., Vucinic, M., Richardson, M., Selander, G., Mattsson, J., Vucinic, M., Richardson, M.,
and A. Schellenbaum, "Lightweight Authorization for and A. Schellenbaum, "Lightweight Authorization for
Authenticated Key Exchange.", draft-selander-ace-ake- Authenticated Key Exchange.", draft-selander-ace-ake-
skipping to change at page 48, line 36 skipping to change at page 50, line 32
A.2. COSE A.2. COSE
CBOR Object Signing and Encryption (COSE) [RFC8152] describes how to CBOR Object Signing and Encryption (COSE) [RFC8152] describes how to
create and process signatures, message authentication codes, and create and process signatures, message authentication codes, and
encryption using CBOR. COSE builds on JOSE, but is adapted to allow encryption using CBOR. COSE builds on JOSE, but is adapted to allow
more efficient processing in constrained devices. EDHOC makes use of more efficient processing in constrained devices. EDHOC makes use of
COSE_Key, COSE_Encrypt0, and COSE_Sign1 objects. COSE_Key, COSE_Encrypt0, and COSE_Sign1 objects.
Appendix B. Test Vectors Appendix B. Test Vectors
This appendix provides detailed test vectors to ease implementation This appendix provides detailed test vectors based on v-02 of this
and ensure interoperability. In addition to hexadecimal, all CBOR specification, to ease implementation and ensure interoperability.
data items and sequences are given in CBOR diagnostic notation. The In addition to hexadecimal, all CBOR data items and sequences are
test vectors use the default mapping to CoAP where the Initiator acts given in CBOR diagnostic notation. The test vectors use the default
as CoAP client (this means that corr = 1). mapping to CoAP where the Initiator acts as CoAP client (this means
that corr = 1).
A more extensive test vector suite covering more combinations of A more extensive test vector suite covering more combinations of
authentication method used between Initiator and Responder and authentication method used between Initiator and Responder and
related code to generate them can be found at https://github.com/ related code to generate them can be found at https://github.com/
lake-wg/edhoc/tree/master/test-vectors . lake-wg/edhoc/tree/master/test-vectors .
B.1. Test Vectors for EDHOC Authenticated with Signature Keys (x5t) B.1. Test Vectors for EDHOC Authenticated with Signature Keys (x5t)
EDHOC with signature authentication and X.509 certificates is used. EDHOC with signature authentication and X.509 certificates is used.
In this test vector, the hash value 'x5t' is used to identify the In this test vector, the hash value 'x5t' is used to identify the
skipping to change at page 49, line 32 skipping to change at page 51, line 28
preference is the following: preference is the following:
Supported Cipher Suites (4 bytes) Supported Cipher Suites (4 bytes)
00 01 02 03 00 01 02 03
The cipher suite selected by the Initiator is the most preferred: The cipher suite selected by the Initiator is the most preferred:
Selected Cipher Suite (int) Selected Cipher Suite (int)
0 0
The mandatory-to-implement cipher suite 0 is supported by both the Cipher suite 0 is supported by both the Initiator and the Responder,
Initiator and the Responder, see Section 8.3. see Section 8.3.
B.1.1. Message_1 B.1.1. Message_1
X (Initiator's ephemeral private key) (32 bytes) X (Initiator's ephemeral private key) (32 bytes)
8f 78 1a 09 53 72 f8 5b 6d 9f 61 09 ae 42 26 11 73 4d 7d bf a0 06 9a 2d 8f 78 1a 09 53 72 f8 5b 6d 9f 61 09 ae 42 26 11 73 4d 7d bf a0 06 9a 2d
f2 93 5b b2 e0 53 bf 35 f2 93 5b b2 e0 53 bf 35
G_X (Initiator's ephemeral public key) (32 bytes) G_X (Initiator's ephemeral public key) (32 bytes)
89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 ec 07 6b ba 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 ec 07 6b ba
02 59 d9 04 b7 ec 8b 0c 02 59 d9 04 b7 ec 8b 0c
skipping to change at page 50, line 50 skipping to change at page 52, line 47
G_Y (Responder's ephemeral public key) (32 bytes) G_Y (Responder's ephemeral public key) (32 bytes)
71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52
81 75 4c 5e bc af 30 1e 81 75 4c 5e bc af 30 1e
From G_X and Y or from G_Y and X the ECDH shared secret is computed: From G_X and Y or from G_Y and X the ECDH shared secret is computed:
G_XY (ECDH shared secret) (32 bytes) G_XY (ECDH shared secret) (32 bytes)
2b b7 fa 6e 13 5b c3 35 d0 22 d6 34 cb fb 14 b3 f5 82 f3 e2 e3 af b2 b3 2b b7 fa 6e 13 5b c3 35 d0 22 d6 34 cb fb 14 b3 f5 82 f3 e2 e3 af b2 b3
15 04 91 49 5c 61 78 2b 15 04 91 49 5c 61 78 2b
The key and nonce for calculating the ciphertext are calculated as The key and nonce for calculating the 'ciphertext' are calculated as
follows, as specified in Section 4. follows, as specified in Section 4.
HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). HKDF SHA-256 is the HKDF used (as defined by cipher suite 0).
PRK_2e = HMAC-SHA-256(salt, G_XY) PRK_2e = HMAC-SHA-256(salt, G_XY)
Salt is the empty byte string. Salt is the empty byte string.
salt (0 bytes) salt (0 bytes)
skipping to change at page 51, line 48 skipping to change at page 53, line 46
is equal to 0x13. is equal to 0x13.
C_R (1 byte) C_R (1 byte)
13 13
Data_2 is constructed, as the CBOR Sequence of G_Y and C_R. Data_2 is constructed, as the CBOR Sequence of G_Y and C_R.
data_2 = data_2 =
( (
h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e', h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e',
h'13' 19
) )
data_2 (CBOR Sequence) (35 bytes) data_2 (CBOR Sequence) (35 bytes)
58 20 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 58 20 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0
19 52 81 75 4c 5e bc af 30 1e 13 19 52 81 75 4c 5e bc af 30 1e 13
From data_2 and message_1, compute the input to the transcript hash From data_2 and message_1, compute the input to the transcript hash
TH_2 = H( message_1, data_2 ), as a CBOR Sequence of these 2 data TH_2 = H( message_1, data_2 ), as a CBOR Sequence of these 2 data
items. items.
Input to calculate TH_2 (CBOR Sequence) (72 bytes) Input to calculate TH_2 (CBOR Sequence) (72 bytes)
01 00 58 20 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 01 00 58 20 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6
ec 07 6b ba 02 59 d9 04 b7 ec 8b 0c 40 58 20 71 a3 d5 99 c2 1d a1 89 02 ec 07 6b ba 02 59 d9 04 b7 ec 8b 0c 40 58 20 71 a3 d5 99 c2 1d a1 89 02
a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52 81 75 4c 5e bc af 30 1e 13 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52 81 75 4c 5e bc af 30 1e 13
And from there, compute the transcript hash TH_2 = SHA-256( And from there, compute the transcript hash TH_2 = SHA-256(
skipping to change at page 52, line 31 skipping to change at page 54, line 26
TH_2 (32 bytes) TH_2 (32 bytes)
b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 b9 ca fb 60 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 b9 ca fb 60
9d e4 f6 a1 76 0d 6c f7 9d e4 f6 a1 76 0d 6c f7
The Responder's subject name is the empty string: The Responder's subject name is the empty string:
Responders's subject name (text string) Responders's subject name (text string)
"" ""
CRED_R is the certificate (X509_R) encoded as a CBOR byte string: CRED_R is the certificate (X509_R) encoded as a CBOR byte string:
(Note that in this version of the test vectors CRED_R is not a real
certificate, but instead a string of random bytes is used)
X509_R (110 bytes) X509_R (110 bytes)
47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9
03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50
db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 18 0b db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 18 0b
5a 6a f3 1e 80 20 9a 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 0f fb 5a 6a f3 1e 80 20 9a 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 0f fb
8e 3f 9a 32 a5 08 59 ec d0 bf cf f2 c2 18 8e 3f 9a 32 a5 08 59 ec d0 bf cf f2 c2 18
CRED_R (112 bytes) CRED_R (112 bytes)
58 6e 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 58 6e 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e
skipping to change at page 58, line 17 skipping to change at page 60, line 17
TH_3 (32 bytes) TH_3 (32 bytes)
a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd
b3 2e 4a 27 ce 93 58 da b3 2e 4a 27 ce 93 58 da
The initiator's subject name is the empty string: The initiator's subject name is the empty string:
Initiator's subject name (text string) Initiator's subject name (text string)
"" ""
CRED_I is the certificate (X509_I) encoded as a CBOR byte string: CRED_I is the certificate (X509_I) encoded as a CBOR byte string:
(Note that in this version of the test vectors CRED_I is not a real
certificate, but instead a string of random bytes is used)
X509_I (101 bytes) X509_I (101 bytes)
fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79
5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60
1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37
00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87
ec 3f f2 45 b7 ec 3f f2 45 b7
CRED_I (103 bytes) CRED_I (103 bytes)
58 65 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f 58 65 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f
skipping to change at page 58, line 41 skipping to change at page 60, line 43
And because certificates are identified by a hash value with the And because certificates are identified by a hash value with the
'x5t' parameter, ID_CRED_I is the following: 'x5t' parameter, ID_CRED_I is the following:
ID_CRED_I = { 34 : COSE_CertHash }. In this example, the hash ID_CRED_I = { 34 : COSE_CertHash }. In this example, the hash
algorithm used is SHA-2 256-bit with hash truncated to 64-bits (value algorithm used is SHA-2 256-bit with hash truncated to 64-bits (value
-15). The hash value is calculated over the certificate X509_I. -15). The hash value is calculated over the certificate X509_I.
ID_CRED_I = ID_CRED_I =
{ {
34: [-15, h'FC79990F2431A3F5'] 34: [-15, h'5B786988439EBCF2']
} }
ID_CRED_I (14 bytes) ID_CRED_I (14 bytes)
a1 18 22 82 2e 48 5b 78 69 88 43 9e bc f2 a1 18 22 82 2e 48 5b 78 69 88 43 9e bc f2
Since no opaque auxiliary data is exchanged: Since no opaque auxiliary data is exchanged:
AD_3 (0 bytes) AD_3 (0 bytes)
The Plaintext of the COSE_Encrypt is the empty string: The Plaintext of the COSE_Encrypt is the empty string:
P_3m (0 bytes) P_3m (0 bytes)
The external_aad is the CBOR Sequence od CRED_I and TH_3, in this The external_aad is the CBOR Sequence of TH_3 and CRED_I, in this
order: order:
A_3m (CBOR-encoded) (164 bytes) A_3m (CBOR-encoded) (164 bytes)
83 68 45 6e 63 72 79 70 74 30 4e a1 18 22 82 2e 48 5b 78 69 88 43 9e bc 83 68 45 6e 63 72 79 70 74 30 4e a1 18 22 82 2e 48 5b 78 69 88 43 9e bc
f2 58 89 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 f2 58 89 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39
3e f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 58 65 fa 34 b2 2a 9c a4 a1 e1 29 3e f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 58 65 fa 34 b2 2a 9c a4 a1 e1 29
24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79 5f 88 af c4 9c be 8a fd d1 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79 5f 88 af c4 9c be 8a fd d1
ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60 1f 6f 0a 08 52 97 8b d4 3d ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60 1f 6f 0a 08 52 97 8b d4 3d
28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37 00 16 b8 96 5b db 20 74 bf 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37 00 16 b8 96 5b db 20 74 bf
f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 ec 3f f2 45 b7 f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 ec 3f f2 45 b7
skipping to change at page 60, line 24 skipping to change at page 62, line 24
info for IV_3m (CBOR-encoded) (43 bytes) info for IV_3m (CBOR-encoded) (43 bytes)
84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e
f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 65 49 56 5f 33 6d 0d f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 65 49 56 5f 33 6d 0d
From these parameters, IV_3m is computed: From these parameters, IV_3m is computed:
IV_3m (13 bytes) IV_3m (13 bytes)
10 b6 f4 41 4a 2c 91 3c cd a1 96 42 e3 10 b6 f4 41 4a 2c 91 3c cd a1 96 42 e3
MAC_3 is the ciphertext of the COSE_Encrypt0: MAC_3 is the 'ciphertext' of the COSE_Encrypt0:
MAC_3 (8 bytes) MAC_3 (8 bytes)
5e ef b8 85 98 3c 22 d9 5e ef b8 85 98 3c 22 d9
Since the method = 0, Signature_or_Mac_3 is a signature: Since the method = 0, Signature_or_Mac_3 is a signature:
o The message M_3 to be signed = [ "Signature1", << ID_CRED_I >>, o The message M_3 to be signed = [ "Signature1", << ID_CRED_I >>,
<< TH_3, CRED_I >>, MAC_3 ] << TH_3, CRED_I >>, MAC_3 ]
o The signing key is the private authentication key of the o The signing key is the private authentication key of the
skipping to change at page 62, line 41 skipping to change at page 64, line 41
84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e
f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 66 49 56 5f 33 61 65 0d f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 66 49 56 5f 33 61 65 0d
L is the length of IV_3ae, so 13 bytes. L is the length of IV_3ae, so 13 bytes.
From these parameters, IV_3ae is computed: From these parameters, IV_3ae is computed:
IV_3ae (13 bytes) IV_3ae (13 bytes)
cf a9 a5 85 58 10 d6 dc e9 74 3c 3b c3 cf a9 a5 85 58 10 d6 dc e9 74 3c 3b c3
Using the parameters above, the ciphertext CIPHERTEXT_3 can be Using the parameters above, the 'ciphertext' CIPHERTEXT_3 can be
computed: computed:
CIPHERTEXT_3 (88 bytes) CIPHERTEXT_3 (88 bytes)
2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db a4 78 05 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db a4 78 05
e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e af 56 e4 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e af 56 e4
5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 e4 62 f5 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 e4 62 f5
f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a
From the parameter above, message_3 is computed, as the CBOR Sequence From the parameter above, message_3 is computed, as the CBOR Sequence
of the following items: (C_R, CIPHERTEXT_3). of the following items: (C_R, CIPHERTEXT_3).
skipping to change at page 63, line 19 skipping to change at page 65, line 19
) )
Which encodes to the following byte string: Which encodes to the following byte string:
message_3 (CBOR Sequence) (91 bytes) message_3 (CBOR Sequence) (91 bytes)
13 58 58 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db 13 58 58 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db
a4 78 05 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e a4 78 05 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e
af 56 e4 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 af 56 e4 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0
e4 62 f5 f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a e4 62 f5 f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a
B.1.4. OSCORE Security Context Derivation
From here, the Initiator and the Responder can derive an OSCORE
Security Context, using the EDHOC-Exporter interface.
From TH_3 and CIPHERTEXT_3, compute the input to the transcript hash
TH_4 = H( TH_3, CIPHERTEXT_3 ), as a CBOR Sequence of these 2 data
items.
Input to calculate TH_4 (CBOR Sequence) (120 bytes)
a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd
b3 2e 4a 27 ce 93 58 da
2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db a4 78 05
e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e af 56 e4
5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 e4 62 f5
f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a
And from there, compute the transcript hash TH_4 = SHA-256(TH_3 ,
CIPHERTEXT_4)
TH_4 (32 bytes)
36 45 7C 25 90 0B 01 26 36 77 90 2D 34 02 E6 DC
96 D3 8C 45 73 79 F0 DC CA 1E 9B 3A AF 34 2E 43
The Master Secret and Master Salt are derived as follows:
Master Secret = EDHOC-Exporter( "OSCORE Master Secret", 16 ) = EDHOC-
KDF(PRK_4x3m, TH_4, "OSCORE Master Secret", 16) = Expand( PRK_4x3m,
info_ms, 16 )
Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 ) = EDHOC-
KDF(PRK_4x3m, TH_4, "OSCORE Master Salt", 8) = Expand( PRK_4x3m,
info_salt, 8 )
info_ms for OSCORE Master Secret is defined as follows:
info_ms = [
10,
h'36457c25900b01263677902d3402e6dc96d38c457379f0dcca1e9b3aaf342e43',
"OSCORE Master Secret",
16
]
Which as a CBOR encoded data item is:
info_ms for OSCORE Master Secret (CBOR-encoded) (58 bytes)
84 0A 58 20 36 45 7C 25 90 0B 01 26 36 77 90 2D
34 02 E6 DC 96 D3 8C 45 73 79 F0 DC CA 1E 9B 3A
AF 34 2E 43 74 4F 53 43 4F 52 45 20 4D 61 73 74
65 72 20 53 65 63 72 65 74 10
info_salt for OSCORE Master Salt is defined as follows:
info_salt = [
10,
h'36457c25900b01263677902d3402e6dc96d38c457379f0dcca1e9b3aaf342e43',
"OSCORE Master Salt",
8
]
Which as a CBOR encoded data item is:
info for OSCORE Master Salt (CBOR-encoded) (56 Bytes)
84 0A 58 20 36 45 7C 25 90 0B 01 26 36 77 90 2D
34 02 E6 DC 96 D3 8C 45 73 79 F0 DC CA 1E 9B 3A
AF 34 2E 43 72 4F 53 43 4F 52 45 20 4D 61 73 74
65 72 20 53 61 6C 74 08
From these parameters, OSCORE Master Secret and OSCORE Master Salt
are computed:
OSCORE Master Secret (16 bytes)
EB 9E 7C 08 16 37 41 54 C8 EC D8 39 84 5F 25 62
OSCORE Master Salt (8 bytes)
BC E4 BF 91 4B 70 7D C1
The client's OSCORE Sender ID is C_R and the server's OSCORE Sender
ID is C_I.
Client's OSCORE Sender ID (1 bytes)
13
Server's OSCORE Sender ID (0 bytes)
The AEAD Algorithm and the hash algorithm are the application AEAD
and hash algorithms in the selected cipher suite.
OSCORE AEAD Algorithm (int)
10
OSCORE Hash Algorithm (int)
-16
B.2. Test Vectors for EDHOC Authenticated with Static Diffie-Hellman B.2. Test Vectors for EDHOC Authenticated with Static Diffie-Hellman
Keys Keys
EDHOC with static Diffie-Hellman keys is used. EDHOC with static Diffie-Hellman keys is used.
method (Static DH Based Authentication) method (Static DH Based Authentication)
3 3
CoAP is used as transport and the Initiator acts as CoAP client: CoAP is used as transport and the Initiator acts as CoAP client:
skipping to change at page 63, line 51 skipping to change at page 67, line 47
preference is the following: preference is the following:
Supported Cipher Suites (4 bytes) Supported Cipher Suites (4 bytes)
00 01 02 03 00 01 02 03
The cipher suite selected by the Initiator is the most preferred: The cipher suite selected by the Initiator is the most preferred:
Selected Cipher Suite (int) Selected Cipher Suite (int)
0 0
The mandatory-to-implement cipher suite 0 is supported by both the Cipher suite 0 is supported by both the Initiator and the Responder,
Initiator and the Responder, see Section 8.3. see Section 8.3.
B.2.1. Message_1 B.2.1. Message_1
X (Initiator's ephemeral private key) (32 bytes) X (Initiator's ephemeral private key) (32 bytes)
ae 11 a0 db 86 3c 02 27 e5 39 92 fe b8 f5 92 4c 50 d0 a7 ba 6e ea b4 ad ae 11 a0 db 86 3c 02 27 e5 39 92 fe b8 f5 92 4c 50 d0 a7 ba 6e ea b4 ad
1f f2 45 72 f4 f5 7c fa 1f f2 45 72 f4 f5 7c fa
G_X (Initiator's ephemeral public key) (32 bytes) G_X (Initiator's ephemeral public key) (32 bytes)
8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 a5 38 a4 44 8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 a5 38 a4 44
ee 9e 2b 57 e2 44 1a 7c ee 9e 2b 57 e2 44 1a 7c
skipping to change at page 65, line 27 skipping to change at page 69, line 27
G_Y (Responder's ephemeral public key) (32 bytes) G_Y (Responder's ephemeral public key) (32 bytes)
52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33 52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33
01 04 70 69 45 1b af 35 01 04 70 69 45 1b af 35
From G_X and Y or from G_Y and X the ECDH shared secret is computed: From G_X and Y or from G_Y and X the ECDH shared secret is computed:
G_XY (ECDH shared secret) (32 bytes) G_XY (ECDH shared secret) (32 bytes)
de fc 2f 35 69 10 9b 3d 1f a4 a7 3d c5 e2 fe b9 e1 15 0d 90 c2 5e e2 f0 de fc 2f 35 69 10 9b 3d 1f a4 a7 3d c5 e2 fe b9 e1 15 0d 90 c2 5e e2 f0
66 c2 d8 85 f4 f8 ac 4e 66 c2 d8 85 f4 f8 ac 4e
The key and nonce for calculating the ciphertext are calculated as The key and nonce for calculating the 'ciphertext' are calculated as
follows, as specified in Section 4. follows, as specified in Section 4.
HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). HKDF SHA-256 is the HKDF used (as defined by cipher suite 0).
PRK_2e = HMAC-SHA-256(salt, G_XY) PRK_2e = HMAC-SHA-256(salt, G_XY)
Salt is the empty byte string. Salt is the empty byte string.
salt (0 bytes) salt (0 bytes)
skipping to change at page 72, line 42 skipping to change at page 76, line 42
20 6e 61 6d 65 60 20 6e 61 6d 65 60
Since no opaque auxiliary data is exchanged: Since no opaque auxiliary data is exchanged:
AD_3 (0 bytes) AD_3 (0 bytes)
The Plaintext of the COSE_Encrypt is the empty string: The Plaintext of the COSE_Encrypt is the empty string:
P_3m (0 bytes) P_3m (0 bytes)
The external_aad is the CBOR Sequence of CRED_I and TH_3, in this The external_aad is the CBOR Sequence of TH_3 and CRED_I, in this
order: order:
A_3m (CBOR-encoded) (105 bytes) A_3m (CBOR-encoded) (105 bytes)
83 68 45 6e 63 72 79 70 74 30 44 a1 04 41 24 58 58 58 20 51 dd 22 43 a6 83 68 45 6e 63 72 79 70 74 30 44 a1 04 41 24 58 58 58 20 51 dd 22 43 a6
b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc e4 80 16 07 03 ee d9 c4 a1 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc e4 80 16 07 03 ee d9 c4 a1
bc b6 11 a4 01 01 20 04 21 58 20 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae bc b6 11 a4 01 01 20 04 21 58 20 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae
da fe 9c aa 4f 4e 7a bb 83 5e c3 0f 1d e8 8a db 96 ff 71 6c 73 75 62 6a da fe 9c aa 4f 4e 7a bb 83 5e c3 0f 1d e8 8a db 96 ff 71 6c 73 75 62 6a
65 63 74 20 6e 61 6d 65 60 65 63 74 20 6e 61 6d 65 60
Info for K_3m is computed as follows: Info for K_3m is computed as follows:
skipping to change at page 73, line 50 skipping to change at page 77, line 50
info for IV_3m (CBOR-encoded) (43 bytes) info for IV_3m (CBOR-encoded) (43 bytes)
84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc 84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc
e4 80 16 07 03 ee d9 c4 a1 bc b6 11 65 49 56 5f 33 6d 0d e4 80 16 07 03 ee d9 c4 a1 bc b6 11 65 49 56 5f 33 6d 0d
From these parameters, IV_3m is computed: From these parameters, IV_3m is computed:
IV_3m (13 bytes) IV_3m (13 bytes)
1e 10 5b 88 50 0e d5 ae b0 5d 00 6b ea 1e 10 5b 88 50 0e d5 ae b0 5d 00 6b ea
MAC_3 is the ciphertext of the COSE_Encrypt0: MAC_3 is the 'ciphertext' of the COSE_Encrypt0:
MAC_3 (8 bytes) MAC_3 (8 bytes)
1f b7 5a c1 aa d2 34 25 1f b7 5a c1 aa d2 34 25
Since the method = 3, Signature_or_Mac_3 is the MAC_3: Since the method = 3, Signature_or_Mac_3 is the MAC_3:
Signature_or_MAC_3 (8 bytes) Signature_or_MAC_3 (8 bytes)
1f b7 5a c1 aa d2 34 25 1f b7 5a c1 aa d2 34 25
Finally, the outer COSE_Encrypt0 is computed. Finally, the outer COSE_Encrypt0 is computed.
skipping to change at page 75, line 35 skipping to change at page 79, line 35
84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc 84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc
e4 80 16 07 03 ee d9 c4 a1 bc b6 11 66 49 56 5f 33 61 65 0d e4 80 16 07 03 ee d9 c4 a1 bc b6 11 66 49 56 5f 33 61 65 0d
L is the length of IV_3ae, so 13 bytes. L is the length of IV_3ae, so 13 bytes.
From these parameters, IV_3ae is computed: From these parameters, IV_3ae is computed:
IV_3ae (13 bytes) IV_3ae (13 bytes)
0e 74 45 0a fc ec e9 73 af 64 e9 4d 46 0e 74 45 0a fc ec e9 73 af 64 e9 4d 46
Using the parameters above, the ciphertext CIPHERTEXT_3 can be Using the parameters above, the 'ciphertext' CIPHERTEXT_3 can be
computed: computed:
CIPHERTEXT_3 (18 bytes) CIPHERTEXT_3 (18 bytes)
53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0 53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0
From the parameter above, message_3 is computed, as the CBOR Sequence From the parameter above, message_3 is computed, as the CBOR Sequence
of the following items: (C_R, CIPHERTEXT_3). of the following items: (C_R, CIPHERTEXT_3).
message_3 = message_3 =
( (
h'08', h'08',
h'53C3991999A5FFB86921E99B607C067770E0' h'53C3991999A5FFB86921E99B607C067770E0'
) )
Which encodes to the following byte string: Which encodes to the following byte string:
message_3 (CBOR Sequence) (20 bytes) message_3 (CBOR Sequence) (20 bytes)
08 52 53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0 08 52 53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0
B.2.4. OSCORE Security Context Derivation
From here, the Initiator and the Responder can derive an OSCORE
Security Context, using the EDHOC-Exporter interface.
From TH_3 and CIPHERTEXT_3, compute the input to the transcript hash
TH_4 = H( TH_3, CIPHERTEXT_3 ), as a CBOR Sequence of these 2 data
items.
Input to calculate TH_4 (CBOR Sequence) (TODO bytes)
51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc e4 80 16 07
03 ee d9 c4 a1 bc b6 11
53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0
And from there, compute the transcript hash TH_4 = SHA-256(TH_3 ,
CIPHERTEXT_4)
TH_4 (32 bytes)
TODO
The Master Secret and Master Salt are derived as follows:
Master Secret = EDHOC-Exporter( "OSCORE Master Secret", 16 ) = EDHOC-
KDF(PRK_4x3m, TH_4, "OSCORE Master Secret", 16) = Expand( PRK_4x3m,
info_ms, 16 )
Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 ) = EDHOC-
KDF(PRK_4x3m, TH_4, "OSCORE Master Salt", 8) = Expand( PRK_4x3m,
info_salt, 8 )
info_ms for OSCORE Master Secret is defined as follows:
info_ms = [
10,
TODO,
"OSCORE Master Secret",
16
]
Which as a CBOR encoded data item is:
info_ms for OSCORE Master Secret (CBOR-encoded) (58 bytes)
TODO
info_salt for OSCORE Master Salt is defined as follows:
info_salt = [
10,
TODO,
"OSCORE Master Salt",
8
]
Which as a CBOR encoded data item is:
info for OSCORE Master Salt (CBOR-encoded) (56 Bytes)
TODO
From these parameters, OSCORE Master Secret and OSCORE Master Salt
are computed:
OSCORE Master Secret (16 bytes)
TODO
OSCORE Master Salt (8 bytes)
TODO
The client's OSCORE Sender ID is C_R and the server's OSCORE Sender
ID is C_I.
Client's OSCORE Sender ID (1 bytes)
08
Server's OSCORE Sender ID (0 bytes)
21
The AEAD Algorithm and the hash algorithm are the application AEAD
and hash algorithms in the selected cipher suite.
OSCORE AEAD Algorithm (int)
10
OSCORE Hash Algorithm (int)
-16
Appendix C. Applicability Statement Template Appendix C. Applicability Statement Template
EDHOC requires certain parameters to be agreed upon between Initiator EDHOC requires certain parameters to be agreed upon between Initiator
and Responder. A cipher suite is negotiated with the protocol, but and Responder. A cipher suite is negotiated with the protocol, but
certain other parameters need to be agreed beforehand: certain other parameters need to be agreed beforehand:
1. Method and correlation of underlying transport messages 1. Method and correlation of underlying transport messages
(METHOD_CORR, see Section 3.2.1 and Section 3.2.4). (METHOD_CORR, see Section 3.2.1 and Section 3.2.4).
2. Type of authentication credentials (CRED_I, CRED_R, see 2. Type of authentication credentials (CRED_I, CRED_R, see
skipping to change at page 77, line 13 skipping to change at page 82, line 49
made on the parameters. made on the parameters.
o METHOD_CORR = 5 o METHOD_CORR = 5
* method = 1 (I uses signature key, R uses static DH key.) * method = 1 (I uses signature key, R uses static DH key.)
* corr = 1 (CoAP Token or other transport data enables * corr = 1 (CoAP Token or other transport data enables
correlation between message_1 and message_2.) correlation between message_1 and message_2.)
o CRED_I is an 802.1AR IDevID encoded as a CBOR Certificate of type o CRED_I is an 802.1AR IDevID encoded as a CBOR Certificate of type
0 0 [I-D.mattsson-cose-cbor-cert-compress].
* R acquires CRED_I out-of-band, indicated in AD_1 * R acquires CRED_I out-of-band, indicated in AD_1
* ID_CRED_I = {4: h''} is a kid with value empty byte string * ID_CRED_I = {4: h''} is a kid with value empty byte string
o CRED_R is a COSE_Key of type OKP as specified in Section 3.3.4. o CRED_R is a COSE_Key of type OKP as specified in Section 3.3.4.
* The CBOR map has parameters 1 (kty), -1 (crv), and -2 * The CBOR map has parameters 1 (kty), -1 (crv), and -2
(x-coordinate). (x-coordinate).
o ID_CRED_R = CRED_R o ID_CRED_R = CRED_R
o AD_1 contains Auxiliary Data of type A (TBD) o AD_1 contains Auxiliary Data of type A (TBD)
skipping to change at page 77, line 38 skipping to change at page 83, line 25
o AD_2 contains Auxiliary Data of type B (TBD) o AD_2 contains Auxiliary Data of type B (TBD)
Auxiliary Data is processed as specified in Auxiliary Data is processed as specified in
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
o Need to specify use of C_I/C_R ? (TBD) o Need to specify use of C_I/C_R ? (TBD)
Acknowledgments Acknowledgments
The authors want to thank Alessandro Bruni, Karthikeyan Bhargavan, The authors want to thank Alessandro Bruni, Karthikeyan Bhargavan,
Martin Disch, Theis Groenbech Petersen, Dan Harkins, Klaus Hartke, Timothy Claeys, Martin Disch, Theis Groenbech Petersen, Dan Harkins,
Russ Housley, Alexandros Krontiris, Ilari Liusvaara, Karl Norrman, Klaus Hartke, Russ Housley, Stefan Hristozov, Alexandros Krontiris,
Salvador Perez, Eric Rescorla, Michael Richardson, Thorvald Sahl Ilari Liusvaara, Karl Norrman, Salvador Perez, Eric Rescorla, Michael
Joergensen, Jim Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav Richardson, Thorvald Sahl Joergensen, Jim Schaad, Carsten Schuermann,
Smyshlyaev, Valery Smyslov, Rene Struik, Vaishnavi Sundararajan, Erik Ludwig Seitz, Stanislav Smyshlyaev, Valery Smyslov, Rene Struik,
Thormarker, and Michel Veillette for reviewing and commenting on Vaishnavi Sundararajan, Erik Thormarker, Marco Tiloca, Michel
Veillette, and Malisa Vucinic for reviewing and commenting on
intermediate versions of the draft. We are especially indebted to intermediate versions of the draft. We are especially indebted to
Jim Schaad for his continuous reviewing and implementation of Jim Schaad for his continuous reviewing and implementation of
different versions of the draft. different versions of the draft.
Authors' Addresses Authors' Addresses
Goeran Selander Goeran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
John Preuss Mattsson John Preuss Mattsson
Ericsson AB Ericsson AB
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
 End of changes. 78 change blocks. 
255 lines changed or deleted 535 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/