draft-ietf-lake-edhoc-02.txt   draft-ietf-lake-edhoc-03.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: May 6, 2021 Ericsson AB Expires: June 21, 2021 Ericsson AB
November 02, 2020 December 18, 2020
Ephemeral Diffie-Hellman Over COSE (EDHOC) Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-edhoc-02 draft-ietf-lake-edhoc-03
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 footprint 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 6, 2021. This Internet-Draft will expire on June 21, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . 4 1.1. Rationale for EDHOC . . . . . . . . . . . . . . . . . . . 5
1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Terminology and Requirements Language . . . . . . . . . . 6 1.3. Terminology and Requirements Language . . . . . . . . . . 6
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 6
3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transport and Message Correlation . . . . . . . . . . . . 9 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Authentication Keys and Identities . . . . . . . . . . . 10 3.2. Method and Correlation . . . . . . . . . . . . . . . . . 9
3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Authentication Parameters . . . . . . . . . . . . . . . . 11
3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 14
3.5. Communication/Negotiation of Protocol Features . . . . . 12 3.5. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 16
3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 13 3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 16
3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 13 3.7. Communication of Protocol Features . . . . . . . . . . . 17
3.8. Key Derivation . . . . . . . . . . . . . . . . . . . . . 13 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 17
4. EDHOC Authenticated with Asymmetric Keys . . . . . . . . . . 16 4.1. EDHOC-Exporter Interface . . . . . . . . . . . . . . . . 19
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Message Formatting and Processing . . . . . . . . . . . . . . 20
4.2. Encoding of Public Authentication Key Identifiers . . . . 16 5.1. Encoding of bstr_identifier . . . . . . . . . . . . . . . 20
4.3. Encoding of bstr_identifier . . . . . . . . . . . . . . . 18 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 21
4.4. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 18 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 23
4.5. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 20 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 26
4.6. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 23 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 29
5.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 27 7. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 32
6. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 29 7.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 32
6.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 35
7.1. Security Properties . . . . . . . . . . . . . . . . . . . 32 8.2. Cryptographic Considerations . . . . . . . . . . . . . . 36
7.2. Cryptographic Considerations . . . . . . . . . . . . . . 33 8.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 37
7.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 34 8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 37
7.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 34 8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 38
7.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 35 8.6. Implementation Considerations . . . . . . . . . . . . . . 38
7.6. Implementation Considerations . . . . . . . . . . . . . . 35 8.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 39
7.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 39
8.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 36 9.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 41
8.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 37 9.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 41
8.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 37 9.4. Media Types Registry . . . . . . . . . . . . . . . . . . 41
8.4. Media Types Registry . . . . . . . . . . . . . . . . . . 38 9.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 42
8.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 39 9.6. Expert Review Instructions . . . . . . . . . . . . . . . 42
8.6. Expert Review Instructions . . . . . . . . . . . . . . . 39 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.1. Normative References . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . 41 Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 47
Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 44 A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 47
A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 44 A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 48
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 45
B.1. Test Vectors for EDHOC Authenticated with Signature Keys B.1. Test Vectors for EDHOC Authenticated with Signature Keys
(x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 45 (x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.2. Test Vectors for EDHOC Authenticated with Static Diffie- B.2. Test Vectors for EDHOC Authenticated with Static Diffie-
Hellman Keys . . . . . . . . . . . . . . . . . . . . . . 60 Hellman Keys . . . . . . . . . . . . . . . . . . . . . . 63
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 73 Appendix C. Applicability Statement Template . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 C.1. Use of EDHOC in the XX Protocol . . . . . . . . . . . . . 76
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
Security at the application layer provides an attractive option for Security at the application layer provides an attractive option for
protecting Internet of Things (IoT) deployments, for example where protecting Internet of Things (IoT) deployments, for example where
protection needs to work over a variety of underlying protocols. IoT protection needs to work over a variety of underlying protocols. 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 energy [RFC7228]. A method for
protecting individual messages at the application layer suitable for protecting individual messages at the application layer suitable for
constrained devices, is provided by CBOR Object Signing and constrained devices, is provided by CBOR Object Signing and
Encryption (COSE) [RFC8152]), which builds on the Concise Binary Encryption (COSE) [RFC8152]), which builds on the Concise Binary
Object Representation (CBOR) [RFC7049]. Object Security for Object Representation (CBOR) [RFC8949]. Object Security for
Constrained RESTful Environments (OSCORE) [RFC8613] is a method for Constrained RESTful Environments (OSCORE) [RFC8613] is a method for
application-layer protection of the Constrained Application Protocol application-layer protection of the Constrained Application Protocol
(CoAP), using COSE. (CoAP), using COSE.
In order for a communication session to provide forward secrecy, the In order for a communication session to provide forward secrecy, the
communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH) communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH)
key exchange protocol with ephemeral keys, from which shared key key exchange protocol with ephemeral keys, from which shared key
material can be derived. This document specifies Ephemeral Diffie- material can be derived. This document specifies Ephemeral Diffie-
Hellman Over COSE (EDHOC), a lightweight key exchange protocol Hellman Over COSE (EDHOC), a lightweight key exchange protocol
providing perfect forward secrecy and identity protection. providing perfect forward secrecy and identity protection.
skipping to change at page 4, line 33 skipping to change at page 4, line 35
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 The ECDH exchange and the key derivation follow known protocol
constructions such as [SIGMA], NIST SP-800-56A [SP-800-56A], and HKDF constructions such as [SIGMA], NIST SP-800-56A [SP-800-56A], and
[RFC5869]. CBOR [RFC7049] and COSE [RFC8152] are used to implement Extract-and-Expand [RFC5869]. CBOR [RFC8949] and COSE [RFC8152] are
these standards. The use of COSE provides crypto agility and enables used to implement these standards. The use of COSE provides crypto
use of future algorithms and headers designed for constrained IoT. agility and enables use of future algorithms and headers designed for
constrained IoT.
This document is organized as follows: Section 2 describes how EDHOC This document is organized as follows: Section 2 describes how EDHOC
authenticated with digital signatures builds on SIGMA-I, Section 3 authenticated with digital signatures builds on SIGMA-I, Section 3
specifies general properties of EDHOC, including message flow, specifies general properties of EDHOC, including message flow and
formatting of the ephemeral public keys, and key derivation, formatting of the ephemeral public keys, Section 4 specifies the key
Section 4 specifies EDHOC with signature key and static Diffie- derivation, Section 5 specifies EDHOC with signature key and static
Hellman key authentication, Section 5 specifies the EDHOC error Diffie-Hellman key authentication, Section 6 specifies the EDHOC
message, and Section 6 describes how EDHOC can be transferred in CoAP error message, and Section 7 describes how EDHOC can be transferred
and used to establish an OSCORE security context. in CoAP and used to establish an OSCORE security context.
1.1. Rationale for EDHOC 1.1. Rationale for EDHOC
Many constrained IoT systems today do not use any security at all, Many constrained IoT systems today do not use any security at all,
and when they do, they often do not follow best practices. One and when they do, they often do not follow best practices. One
reason is that many current security protocols are not designed with reason is that many current security protocols are not designed with
constrained IoT in mind. Constrained IoT systems often deal with constrained IoT in mind. Constrained IoT systems often deal with
personal information, valuable business data, and actuators personal information, valuable business data, and actuators
interacting with the physical world. Not only do such systems need interacting with the physical world. Not only do such systems need
security and privacy, they often need end-to-end protection with security and privacy, they often need end-to-end protection with
skipping to change at page 6, line 14 skipping to change at page 6, line 24
A typical setting is when one of the endpoints is constrained or in a 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 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 mobile phone) or at the edge of the constrained network
(such as a gateway). Thing-to-thing interactions over constrained (such as a gateway). Thing-to-thing interactions over constrained
networks are also relevant since both endpoints would then benefit networks are also relevant since both endpoints would then benefit
from the lightweight properties of the protocol. EDHOC could e.g. be 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 run when a device/device(s) connect(s) for the first time, or to
establish fresh keys which are not compromised by a later compromise establish fresh keys which are not compromised by a later compromise
of the long-term keys. (Further security properties are described in of the long-term keys. (Further security properties are described in
Section 7.1.) Section 8.1.)
1.3. Terminology and Requirements Language 1.3. 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 [RFC7049], 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 [RFC7049]. 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.
2. Background 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
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
1.3 [RFC8446], EDHOC authenticated with digital signatures is built 1.3 [RFC8446], EDHOC authenticated with digital signatures is built
on a variant of the SIGMA protocol which provide identity protection on a variant of the SIGMA protocol which provide identity protection
of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC
implements the SIGMA-I variant as Mac-then-Sign. The SIGMA-I implements the SIGMA-I variant as MAC-then-Sign. The SIGMA-I
protocol using an authenticated encryption algorithm is shown in protocol using an authenticated encryption algorithm is shown in
Figure 2. Figure 2.
Initiator Responder Initiator Responder
| G_X | | G_X |
+-------------------------------------------------------->| +-------------------------------------------------------->|
| | | |
| G_Y, AEAD( K_2; ID_CRED_R, Sig(R; CRED_R, G_X, G_Y) ) | | G_Y, AEAD( K_2; ID_CRED_R, Sig(R; CRED_R, G_X, G_Y) ) |
|<--------------------------------------------------------+ |<--------------------------------------------------------+
| | | |
skipping to change at page 8, line 22 skipping to change at page 8, line 24
o Transport of opaque auxiliary data. o Transport of opaque auxiliary data.
EDHOC is designed to encrypt and integrity protect as much EDHOC is designed to encrypt and integrity protect as much
information as possible, and all symmetric keys are derived using as information as possible, and all symmetric keys are derived using as
much previous information as possible. EDHOC is furthermore designed much previous information as possible. EDHOC is furthermore designed
to be as compact and lightweight as possible, in terms of message to be as compact and lightweight as possible, in terms of message
sizes, processing, and the ability to reuse already existing CBOR, sizes, processing, and the ability to reuse already existing CBOR,
COSE, and CoAP libraries. COSE, and CoAP libraries.
To simplify for implementors, the use of CBOR in EDHOC is summarized To simplify for implementors, the use of CBOR and COSE in EDHOC is
in Appendix A and test vectors including CBOR diagnostic notation are summarized in Appendix A and test vectors including CBOR diagnostic
given in Appendix B. notation are given in Appendix B.
3. EDHOC Overview 3. Protocol Elements
3.1. General
EDHOC consists of three messages (message_1, message_2, message_3) EDHOC consists of three messages (message_1, message_2, message_3)
that maps directly to the three messages in SIGMA-I, plus an EDHOC between Initiator and Responder, plus an EDHOC error message. EDHOC
error message. EDHOC messages are CBOR Sequences [RFC8742], where messages are CBOR Sequences [RFC8742], see Figure 3. The protocol
the first data item (METHOD_CORR) of message_1 is an int specifying elements in the figure are introduced in the following sections.
the method and the correlation properties of the transport used, see Message formatting and processing is specified in Section 5 and
Section 3.1. The method specifies the authentication methods used Section 6. An implementation may support only Initiator or only
(signature, static DH), see Section 8.2. An implementation may Responder.
support only Initiator or Responder. An implementation may support
only a single method. The Initiator and the Responder need to have
agreed on a single method to be used for EDHOC.
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 Application data is protected using the agreed application algorithms
structures, only a subset of the parameters is included in the EDHOC (AEAD, hash) in the selected cipher suite (see Section 3.4) and the
messages. The unprotected COSE header in COSE_Sign1, and application can make use of the established connection identifiers
COSE_Encrypt0 (not included in the EDHOC message) MAY contain C_I and C_R (see Section 3.2.4). EDHOC may be used with the media
parameters (e.g. 'alg'). After creating EDHOC message_3, the type application/edhoc defined in Section 9.
Initiator can derive symmetric application keys, and application
protected data can therefore be sent in parallel with EDHOC
message_3. The application may protect data using the algorithms
(AEAD, hash, etc.) in the selected cipher suite and the connection
identifiers (C_I, C_R). EDHOC may be used with the media type
application/edhoc defined in Section 8.
Initiator Responder The Initiator can derive symmetric application keys after creating
| | EDHOC message_3, see Section 4.1. Application protected data can
| ------------------ EDHOC message_1 -----------------> | therefore be sent in parallel with EDHOC message_3, optionally in the
| | same CoAP message [I-D.palombini-core-oscore-edhoc].
| <----------------- EDHOC message_2 ------------------ |
| |
| ------------------ EDHOC message_3 -----------------> |
| |
| <----------- Application Protected Data ------------> |
| |
Figure 3: EDHOC message flow Initiator Responder
| METHOD_CORR, SUITES_I, G_X, C_I, AD_1 |
+------------------------------------------------------------------>|
| message_1 |
| |
| C_I, G_Y, C_R, Enc(K_2e; ID_CRED_R, Signature_or_MAC_2, AD_2) |
|<------------------------------------------------------------------+
| message_2 |
| |
| C_R, AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, AD_3) |
+------------------------------------------------------------------>|
| message_3 |
3.1. Transport and Message Correlation Figure 3: EDHOC Message Flow
Cryptographically, EDHOC does not put requirements on the lower 3.2. Method and Correlation
layers. EDHOC is not bound to a particular transport layer, and can
be used in environments without IP. The transport is responsible to The first data item of message_1, METHOD_CORR (see Section 5.2.1), is
handle message loss, reordering, message duplication, fragmentation, an integer specifying the method and the correlation properties of
and denial of service protection, where necessary. The Initiator and the transport, which are described in this section.
the Responder need to have agreed on a transport to be used for
EDHOC. It is recommended to transport EDHOC in CoAP payloads, see 3.2.1. Method
Section 6.
EDHOC supports authentication with signature or static Diffie-Hellman
keys, as defined in the four authentication methods: 0, 1, 2, and 3,
see Figure 4. (Method 0 corresponds to the case outlined in
Section 2 where both Initiator and Responder authenticate with
signature keys.)
An implementation may support only a single method. The Initiator
and the Responder need to have agreed on a single method to be used
for EDHOC, see Appendix C.
+-------+-------------------+-------------------+-------------------+
| Value | Initiator | Responder | Reference |
+-------+-------------------+-------------------+-------------------+
| 0 | Signature Key | Signature Key | [[this document]] |
| 1 | Signature Key | Static DH Key | [[this document]] |
| 2 | Static DH Key | Signature Key | [[this document]] |
| 3 | Static DH Key | Static DH Key | [[this document]] |
+-------+-------------------+-------------------+-------------------+
Figure 4: Method Types
3.2.2. Connection Identifiers
EDHOC includes connection identifiers (C_I, C_R) to correlate EDHOC includes connection identifiers (C_I, C_R) to correlate
messages. The connection identifiers C_I and C_R do not have any messages. The connection identifiers C_I and C_R do not have any
cryptographic purpose in EDHOC. They contain information cryptographic purpose in EDHOC. They contain information
facilitating retrieval of the protocol state and may therefore be facilitating retrieval of the protocol state and may therefore be
very short. The connection identifier MAY be used with an very short. One byte connection identifiers are realistic in many
application protocol (e.g. OSCORE) for which EDHOC establishes keys, scenarios as most constrained devices only have a few connections.
in which case the connection identifiers SHALL adhere to the In cases where a node only has one connection, the identifiers may
requirements for that protocol. Each party choses a connection even be the empty byte string.
identifier it desires the other party to use in outgoing messages.
(For OSCORE this results in the endpoint selecting its Recipient ID, The connection identifier MAY be used with an application protocol
see Section 3.1 of [RFC8613]). (e.g. OSCORE) for which EDHOC establishes keys, in which case the
connection identifiers SHALL adhere to the requirements for that
protocol. Each party choses a connection identifier it desires the
other party to use in outgoing messages. (For OSCORE this results in
the endpoint selecting its Recipient ID, see Section 3.1 of
[RFC8613]).
3.2.3. Transport
Cryptographically, EDHOC does not put requirements on the lower
layers. EDHOC is not bound to a particular transport layer, and can
be used in environments without IP. The transport is responsible to
handle message loss, reordering, message duplication, fragmentation,
and denial of service protection, where necessary.
The Initiator and the Responder need to have agreed on a transport to
be used for EDHOC, see Appendix C. It is recommended to transport
EDHOC in CoAP payloads, see Section 7.
3.2.4. Message Correlation
If the transport provides a mechanism for correlating messages, some If the transport provides a mechanism for correlating messages, some
of the connection identifiers may be omitted. There are four cases: of the connection identifiers may be omitted. There are four cases:
o corr = 0, the transport does not provide a correlation mechanism. o corr = 0, the transport does not provide a correlation mechanism.
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 6.1. Token can be used to correlate messages, see Section 7.1.
3.2. Authentication Keys and Identities 3.3. Authentication Parameters
The EDHOC message exchange may be authenticated using raw public keys 3.3.1. Authentication Keys
(RPK) or public key certificates. The certificates and RPKs can
contain signature keys or static Diffie-Hellman keys. In X.509 The authentication key MUST be a signature key or static Diffie-
certificates, signature keys typically have key usage Hellman key. The Initiator and the Responder MAY use different types
"digitalSignature" and Diffie-Hellman keys typically have key usage of authentication keys, e.g. one uses a signature key and the other
"keyAgreement". uses a static Diffie-Hellman key. When using a signature key, the
authentication is provided by a signature. When using a static
Diffie-Hellman key the authentication is provided by a Message
Authentication Code (MAC) computed from an ephemeral-static ECDH
shared secret which enables significant reductions in message sizes.
The MAC is implemented with an AEAD algorithm. When using a static
Diffie-Hellman keys the Initiator's and Responder's private
authentication keys are called I and R, respectively, and the public
authentication keys are called G_I and G_R, respectively.
o Only the Responder SHALL have access to the Responder's private
authentication key.
o Only the Initiator SHALL have access to the Initiator's private
authentication key.
3.3.2. Identities
EDHOC assumes the existence of mechanisms (certification authority, EDHOC assumes the existence of mechanisms (certification authority,
trusted third party, manual distribution, etc.) for specifying and trusted third party, manual distribution, etc.) for specifying and
distributing authentication keys and identities. Policies are set distributing authentication keys and identities. Policies are set
based on the identity of the other party, and parties typically only based on the identity of the other party, and parties typically only
allow connections from a specific identity or a small restricted set allow connections from a specific identity or a small restricted set
of identities. For example, in the case of a device connecting to a of identities. For example, in the case of a device connecting to a
network, the network may only allow connections from devices which network, the network may only allow connections from devices which
authenticate with certificates having a particular range of serial authenticate with certificates having a particular range of serial
numbers in the subject field and signed by a particular CA. On the numbers in the subject field and signed by a particular CA. On the
skipping to change at page 11, line 16 skipping to change at page 12, line 30
certificate), the trust anchor is the public authentication key of certificate), the trust anchor is the public authentication key of
the other party. In this case, the identity is typically directly the other party. In this case, the identity is typically directly
associated to the public authentication key of the other party. associated to the public authentication key of the other party.
For example, the name of the subject may be a canonical For example, the name of the subject may be a canonical
representation of the public key. Alternatively, if identities representation of the public key. Alternatively, if identities
can be expressed in the form of unique subject names assigned to can be expressed in the form of unique subject names assigned to
public keys, then a binding to identity can be achieved by public keys, then a binding to identity can be achieved by
including both public key and associated subject name in the including both public key and associated subject name in the
protocol message computation: CRED_I or CRED_R may be a self- protocol message computation: CRED_I or CRED_R may be a self-
signed certificate or COSE_Key containing the public signed certificate or COSE_Key containing the public
authentication key and the subject name, see Figure 2. Before authentication key and the subject name, see Section 3.3.3.
running EDHOC, each endpoint needs a specific public Before running EDHOC, each endpoint needs a specific public
authentication key/unique associated subject name, or a set of authentication key/unique associated subject name, or a set of
public authentication keys/unique associated subject names, which public authentication keys/unique associated subject names, which
it is allowed to communicate with. EDHOC provides proof that the it is allowed to communicate with. EDHOC provides proof that the
other party possesses the private authentication key corresponding other party possesses the private authentication key corresponding
to the public authentication key. to the public authentication key.
3.3. Identifiers 3.3.3. Authentication Credentials
One byte connection and credential identifiers are realistic in many The authentication credentials, CRED_I and CRED_R, contain the public
scenarios as most constrained devices only have a few keys and authentication key of the Initiator and the Responder, respectively.
connections. In cases where a node only has one connection or key, The Initiator and the Responder MAY use different types of
the identifiers may even be the empty byte string. credentials, e.g. one uses an RPK and the other uses a public key
certificate.
The credentials CRED_I and CRED_R are signed or MAC:ed (depending on
method) by the Initiator and the Responder, respectively, see
Section 5.4 and Section 5.3.
When the credential is a certificate, CRED_x is an end-entity
certificate (i.e. not the certificate chain) encoded as a CBOR bstr.
In X.509 certificates, signature keys typically have key usage
"digitalSignature" and Diffie-Hellman keys typically have key usage
"keyAgreement"
When the credential is a COSE_Key, CRED_x is a CBOR map only
containing specific fields from the COSE_Key:
o For COSE_Keys of type OKP the CBOR map SHALL only include the
parameters 1 (kty), -1 (crv), and -2 (x-coordinate).
o For COSE_Keys of type EC2 the CBOR map SHALL only include the
parameters 1 (kty), -1 (crv), -2 (x-coordinate), and -3
(y-coordinate).
To prevent misbinding attacks in systems where an attacker can
register public keys without proving knowledge of the private key,
SIGMA [SIGMA] enforces a MAC to be calculated over the "Identity",
which in case of a X.509 certificate would be the 'subject' and
'subjectAltName' fields. EDHOC follows SIGMA by calculating a MAC
over the whole certificate. While SIGMA paper only focuses on the
identity, the same principle is true for any information such as
policies connected to the public key.
If the parties have agreed on an identity besides the public key, the
identity is included in the CBOR map with the label "subject name",
otherwise the subject name is the empty text string. The parameters
SHALL be encoded in decreasing order with int labels first and text
string labels last. An example of CRED_x when the RPK contains an
X25519 static Diffie-Hellman key and the parties have agreed on an
EUI-64 identity is shown below:
CRED_x = {
1: 1,
-1: 4,
-2: h'b1a3e89460e88d3a8d54211dc95f0b90
3ff205eb71912d6db8f4af980d2db83a',
"subject name" : "42-50-31-FF-EF-37-32-39"
}
3.3.4. Identification of Credentials
ID_CRED_I and ID_CRED_R are identifiers of the public authentication
keys of the Initiator and the Responder, respectively. ID_CRED_I and
ID_CRED_R do not have any cryptographic purpose in EDHOC.
o ID_CRED_R is intended to facilitate for the Initiator to retrieve
the Responder's public authentication key.
o ID_CRED_I is intended to facilitate for the Responder to retrieve
the Initiator's public authentication key.
The identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, i.e.
CBOR maps containing COSE Common Header Parameters, see Section 3.1
of [RFC8152]). In the following we give some examples of COSE
header_maps.
Raw public keys are most optimally stored as COSE_Key objects and
identified with a 'kid' parameter:
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
parameters for identifying X.509 certificates are defined in
[I-D.ietf-cose-x509], for example:
o by a hash value with the 'x5t' parameter;
* ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
o by a URL with the 'x5u' parameter;
* ID_CRED_x = { 35 : uri }, for x = I or R,
ID_CRED_x MAY contain the actual credential used for authentication,
CRED_x. It is RECOMMENDED that they uniquely identify the public
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
Section 5.4 and Section 5.3.
When ID_CRED_x does not contain the actual credential it may be very
short. One byte credential identifiers are realistic in many
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
byte string.
3.4. Cipher Suites 3.4. Cipher Suites
EDHOC cipher suites consist of an ordered set of COSE algorithms: an An EDHOC cipher suite consists of an ordered set of COSE code points
EDHOC AEAD algorithm, an EDHOC hash algorithm, an EDHOC ECDH curve, from the "COSE Algorithms" and "COSE Elliptic Curves" registries:
an EDHOC signature algorithm, an EDHOC signature algorithm curve, an
application AEAD algorithm, and an application hash algorithm from o EDHOC AEAD algorithm
the COSE Algorithms and Elliptic Curves registries. Each cipher
suite is identified with a pre-defined int label. This document o EDHOC hash algorithm
specifies four pre-defined cipher suites.
o EDHOC ECDH curve
o EDHOC signature algorithm
o EDHOC signature algorithm curve
o Application AEAD algorithm
o Application hash algorithm
Each cipher suite is identified with a pre-defined int label.
EDHOC can be used with all algorithms and curves defined for COSE.
Implementation can either use one of the pre-defined cipher suites
(Section 9.1) or use any combination of COSE algorithms to define
their own private cipher suite. Private cipher suites can be
identified with any of the four values -24, -23, -22, -21.
The following cipher suites are for constrained IoT where message
overhead is a very important factor:
0. ( 10, -16, 4, -8, 6, 10, -16 ) 0. ( 10, -16, 4, -8, 6, 10, -16 )
(AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519, (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519,
AES-CCM-16-64-128, SHA-256) AES-CCM-16-64-128, SHA-256)
1. ( 30, -16, 4, -8, 6, 10, -16 ) 1. ( 30, -16, 4, -8, 6, 10, -16 )
(AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519, (AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519,
AES-CCM-16-64-128, SHA-256) AES-CCM-16-64-128, SHA-256)
2. ( 10, -16, 1, -7, 1, 10, -16 ) 2. ( 10, -16, 1, -7, 1, 10, -16 )
(AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256, (AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,
AES-CCM-16-64-128, SHA-256) AES-CCM-16-64-128, SHA-256)
3. ( 30, -16, 1, -7, 1, 10, -16 ) 3. ( 30, -16, 1, -7, 1, 10, -16 )
(AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256, (AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256,
AES-CCM-16-64-128, SHA-256) AES-CCM-16-64-128, SHA-256)
The different methods use the same cipher suites, but some algorithms The following cipher suite is for general non-constrained
are not used in some methods. The EDHOC signature algorithm and the applications. It uses very high performance algorithms that also are
EDHOC signature algorithm curve are not used is methods without widely supported:
signature authentication.
The Initiator need to have a list of cipher suites it supports in 4. ( 1, -16, 4, -7, 1, 1, -16 )
order of preference. The Responder need to have a list of cipher (A128GCM, SHA-256, X25519, ES256, P-256,
suites it supports. A128GCM, SHA-256)
3.5. Communication/Negotiation of Protocol Features The following cipher suite is for high security application such as
government use and financial applications. It is compatible with the
CNSA suite [CNSA].
EDHOC allows the communication or negotiation of various protocol 5. ( 3, -43, 2, -35, 2, 3, -43 )
features during the execution of the protocol. (A256GCM, SHA-384, P-384, ES384, P-384,
A256GCM, SHA-384)
o The Initiator proposes a cipher suite (see Section 3.4), and the The different methods use the same cipher suites, but some algorithms
Responder either accepts or rejects, and may make a counter are not used in some methods. The EDHOC signature algorithm and the
proposal. EDHOC signature algorithm curve are not used in methods without
signature authentication.
o The Initiator decides on the correlation parameter corr (see The Initiator needs to have a list of cipher suites it supports in
Section 3.1). This is typically given by the transport which the order of preference. The Responder needs to have a list of cipher
Initiator and the Responder have agreed on beforehand. The suites it supports. SUITES_I is a CBOR array containing cipher
Responder either accepts or rejects. suites that the Initiator supports. SUITES_I is formatted and
processed as detailed in Section 5.2.1 to secure the cipher suite
negotation.
o The Initiator decides on the method parameter, see Section 8.2. 3.5. Ephemeral Public Keys
The Responder either accepts or rejects.
o The Initiator and the Responder decide on the representation of The ECDH ephemeral public keys are formatted as a COSE_Key of type
the identifier of their respective credentials, ID_CRED_I and EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only
ID_CRED_R. The decision is reflected by the label used in the the 'x' parameter is included G_X and G_Y. For Elliptic Curve Keys
CBOR map, see for example Section 4.2. of type EC2, compact representation as per [RFC6090] MAY be used also
in the COSE_Key. If the COSE implementation requires an 'y'
parameter, any of the possible values of the y-coordinate can be
used, see Appendix C of [RFC6090]. COSE [RFC8152] always use compact
output for Elliptic Curve Keys of type EC2.
3.6. Auxiliary Data 3.6. Auxiliary Data
In order to reduce round trips and number of messages, and in some In order to reduce round trips and number of messages, and in some
cases also streamline processing, certain security applications may cases also streamline processing, certain security applications may
be integrated into EDHOC by transporting auxiliary data together with be integrated into EDHOC by transporting auxiliary data together with
the messages. One example is the transport of third-party the messages. One example is the transport of third-party
authorization information protected outside of EDHOC authorization information protected outside of EDHOC
[I-D.selander-ace-ake-authz]. Another example is the embedding of a [I-D.selander-ace-ake-authz]. Another example is the embedding of a
certificate enrolment request or a newly issued certificate. certificate enrolment request or a newly issued certificate.
skipping to change at page 13, line 27 skipping to change at page 17, line 5
message_1 and message_2, respectively. Protected Auxiliary Data message_1 and message_2, respectively. Protected Auxiliary Data
(AD_3) may be sent in message_3. (AD_3) may be sent in message_3.
Since data carried in AD_1 and AD_2 may not be protected, and the Since data carried in AD_1 and AD_2 may not be protected, and the
content of AD_3 is available to both the Initiator and the Responder, content of AD_3 is available to both the Initiator and the Responder,
special considerations need to be made such that the availability of special considerations need to be made such that the availability of
the data a) does not violate security and privacy requirements of the the data a) does not violate security and privacy requirements of the
service which uses this data, and b) does not violate the security service which uses this data, and b) does not violate the security
properties of EDHOC. properties of EDHOC.
3.7. Ephemeral Public Keys 3.7. Communication of Protocol Features
The ECDH ephemeral public keys are formatted as a COSE_Key of type EDHOC allows the communication or negotiation of various protocol
EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only features during the execution of the protocol.
the 'x' parameter is included in the EDHOC messages. For Elliptic
Curve Keys of type EC2, compact representation as per [RFC6090] MAY
be used also in the COSE_Key. If the COSE implementation requires an
'y' parameter, any of the possible values of the y-coordinate can be
used, see Appendix C of [RFC6090]. COSE [RFC8152] always use compact
output for Elliptic Curve Keys of type EC2.
3.8. Key Derivation o The Initiator proposes a cipher suite (see Section 3.4), and the
Responder either accepts or rejects, and may make a counter
proposal.
EDHOC uses HKDF [RFC5869] with the EDHOC hash algorithm in the o The Initiator decides on the correlation parameter corr (see
selected cipher suite to derive keys. HKDF-Extract is used to derive Section 3.2.4). This is typically given by the transport which
fixed-length uniformly pseudorandom keys (PRK) from ECDH shared the Initiator and the Responder have agreed on beforehand. The
secrets. HKDF-Expand is used to derive additional output keying Responder either accepts or rejects.
material (OKM) from the PRKs. The PRKs are derived using HKDF-
Extract [RFC5869].
PRK = HKDF-Extract( salt, IKM ) o The Initiator decides on the method parameter, see Figure 4. The
Responder either accepts or rejects.
o The Initiator and the Responder decide on the representation of
the identifier of their respective credentials, ID_CRED_I and
ID_CRED_R. The decision is reflected by the label used in the
CBOR map, see for example Section 3.3.4.
Editor's note: This section needs to be aligned with Appendix C.
4. Key Derivation
EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm
in the selected cipher suite to derive keys. Extract is used to
derive fixed-length uniformly pseudorandom keys (PRK) from ECDH
shared secrets. Expand is used to derive additional output keying
material (OKM) from the PRKs. The PRKs are derived using Extract.
PRK = 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
SHAKE128, then Extract( salt, IKM ) = KMAC128( salt, IKM, 256, "" ).
If the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM ) =
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 key and IV 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 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 produce a
MAC in message_3 and to derive application specific data. 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
skipping to change at page 14, line 26 skipping to change at page 18, line 24
Example: Assuming the use of SHA-256 the extract phase of HKDF Example: Assuming the use of SHA-256 the extract phase of HKDF
produces PRK_2e as follows: produces PRK_2e as follows:
PRK_2e = HMAC-SHA-256( salt, G_XY ) PRK_2e = HMAC-SHA-256( salt, G_XY )
where salt = 0x (the empty byte string). where salt = 0x (the empty byte string).
The pseudorandom keys PRK_3e2m and PRK_4x3m are defined as follow: The pseudorandom keys PRK_3e2m and PRK_4x3m are defined as follow:
o If the Reponder authenticates with a static Diffie-Hellman key, o If the Responder authenticates with a static Diffie-Hellman key,
then PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX is the then PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is the ECDH
ECDH shared secret calculated from G_R and X, or G_X and R, else shared secret calculated from G_R and X, or G_X and R, else
PRK_3e2m = PRK_2e. PRK_3e2m = PRK_2e.
o If the Initiator authenticates with a static Diffie-Hellman key, o If the Initiator authenticates with a static Diffie-Hellman key,
then PRK_4x3m = HKDF-Extract( PRK_3e2m, G_IY ), where G_IY is the then PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY is the ECDH
ECDH shared secret calculated from G_I and Y, or G_Y and I, else shared secret calculated from G_I and Y, or G_Y and I, else
PRK_4x3m = PRK_3e2m. PRK_4x3m = PRK_3e2m.
Example: Assuming the use of curve25519, the ECDH shared secrets Example: Assuming the use of curve25519, the ECDH shared secrets
G_XY, G_RX, and G_IY are the outputs of the X25519 function G_XY, G_RX, and G_IY are the outputs of the X25519 function
[RFC7748]: [RFC7748]:
G_XY = X25519( Y, G_X ) = X25519( X, G_Y ) G_XY = X25519( Y, G_X ) = X25519( X, G_Y )
The keys and IVs used in EDHOC are derived from PRK using HKDF-Expand The keys and IVs used in EDHOC are derived from PRK using Expand
[RFC5869] where the EDHOC-KDF is instantiated with the EDHOC AEAD [RFC5869] where the EDHOC-KDF is instantiated with the EDHOC AEAD
algorithm in the selected cipher suite. algorithm in the selected cipher suite.
OKM = EDHOC-KDF( PRK, transcript_hash, label, length ) OKM = EDHOC-KDF( PRK, transcript_hash, label, length )
= HKDF-Expand( PRK, info, length ) = Expand( PRK, info, length )
where info is the CBOR encoding of where info is the CBOR encoding of
info = [ info = [
edhoc_aead_id : int / tstr, edhoc_aead_id : int / tstr,
transcript_hash : bstr, transcript_hash : bstr,
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 K_2e 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 4.5.1, 4.6.1, and TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.1.
3.8.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", "K_3m", "IV_3m", "K_3ae", or "IV_3ae". "K_2m", "IV_2m", "K_2e", "IV_2e", "K_3m", "IV_3m", "K_3ae", or
"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
K_2m and IV_2m are derived using the transcript hash TH_2 and the If the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, length
pseudorandom key PRK_3e2m. K_3ae and IV_3ae are derived using the ) = HKDF-Expand( PRK, info, length ) [RFC5869]. If the EDHOC hash
transcript hash TH_3 and the pseudorandom key PRK_3e2m. K_3m and algorithm is SHAKE128, then Expand( PRK, info, length ) = KMAC128(
IV_3m are derived using the transcript hash TH_3 and the pseudorandom PRK, info, L, "" ). If the EDHOC hash algorithm is SHAKE256, then
key PRK_4x3m. IVs are only used if the EDHOC AEAD algorithm uses Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ).
IVs.
3.8.1. EDHOC-Exporter Interface K_2e and IV_2e are derived using the transcript hash TH_2 and 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
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
transcript hash TH_3 and the pseudorandom key PRK_4x3m. IVs are only
used if the EDHOC AEAD algorithm uses IVs.
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
using the EDHOC-Exporter interface defined as: using the EDHOC-Exporter interface defined as:
EDHOC-Exporter(label, length) EDHOC-Exporter(label, length)
= 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 6.1.1. use of the EDHOC-Exporter is given in Sections 7.1.1.
4. EDHOC Authenticated with Asymmetric Keys
4.1. Overview
This section specifies authentication method = 0, 1, 2, and 3, see
Section 8.2. EDHOC supports authentication with signature or static
Diffie-Hellman keys in the form of raw public keys (RPK) and public
key certificates with the requirements that:
o Only the Responder SHALL have access to the Responder's private
authentication key,
o Only the Initiator SHALL have access to the Initiator's private
authentication key,
o The Initiator is able to retrieve the Responder's public
authentication key using ID_CRED_R,
o The Responder is able to retrieve the Initiator's public
authentication key using ID_CRED_I,
where ID_CRED_I and ID_CRED_R are the identifiers of the public
authentication keys. Their encoding is specified in Section 4.2.
Initiator Responder
| METHOD_CORR, SUITES_I, G_X, C_I, AD_1 |
+------------------------------------------------------------------>|
| message_1 |
| |
| C_I, G_Y, C_R, Enc(K_2e; ID_CRED_R, Signature_or_MAC_2, AD_2) |
|<------------------------------------------------------------------+
| message_2 |
| |
| C_R, AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, AD_3) |
+------------------------------------------------------------------>|
| message_3 |
Figure 4: Overview of EDHOC with asymmetric key authentication.
4.2. Encoding of Public Authentication Key Identifiers
The identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, i.e.
CBOR maps containing COSE Common Header Parameters, see Section 3.1
of [RFC8152]). ID_CRED_I and ID_CRED_R need to contain parameters
that can identify a public authentication key. In the following
paragraph we give some examples of possible COSE header parameters
used.
Raw public keys are most optimally stored as COSE_Key objects and
identified with a 'kid' parameter:
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
parameters for identifying X.509 certificates are defined in
[I-D.ietf-cose-x509], for example:
o by a hash value with the 'x5t' parameter;
* ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, To provide forward secrecy in an even more efficient way than re-
running EDHOC, EDHOC provides the function EDHOC-Exporter-FS. When
EHDOC-Exporter-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
function as illustrated by the following pseudocode:
o by a URL with the 'x5u' parameter; EHDOC-Exporter-FS( nonce ):
PRK_4x3m = Extract( [ "TH_4", nonce ], PRK_4x3m )
* ID_CRED_x = { 35 : uri }, for x = I or R, 5. Message Formatting and Processing
The purpose of ID_CRED_I and ID_CRED_R is to facilitate retrieval of This section specifies formatting of the messages and processing
a public authentication key and when they do not contain the actual steps. Error messages are specified in Section 6.
credential, they may be very short. ID_CRED_I and ID_CRED_R MAY
contain the actual credential used for authentication. It is
RECOMMENDED that they uniquely identify the public 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 Section 4.5.2
and Section 4.6.2.
The authentication key MUST be a signature key or static Diffie- An EDHOC message is encoded as a sequence of CBOR data (CBOR
Hellman key. The Initiator and the Responder MAY use different types Sequence, [RFC8742]). Additional optimizations are made to reduce
of authentication keys, e.g. one uses a signature key and the other message overhead.
uses a static Diffie-Hellman key. When using a signature key, the
authentication is provided by a signature. When using a static
Diffie-Hellman key the authentication is provided by a Message
Authentication Code (MAC) computed from an ephemeral-static ECDH
shared secret which enables significant reductions in message sizes.
The MAC is implemented with an AEAD algorithm. When using a static
Diffie-Hellman keys the Initiator's and Responder's private
authentication keys are called I and R, respectively, and the public
authentication keys are called G_I and G_R, respectively.
The actual credentials CRED_I and CRED_R are signed or MAC:ed by the While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
Initiator and the Responder respectively, see Section 4.6.1 and structures, only a subset of the parameters is included in the EDHOC
Section 4.5.1. The Initiator and the Responder MAY use different messages. The unprotected COSE header in COSE_Sign1, and
types of credentials, e.g. one uses RPK and the other uses COSE_Encrypt0 (not included in the EDHOC message) MAY contain
certificate. When the credential is a certificate, CRED_x is end- parameters (e.g. 'alg').
entity certificate (i.e. not the certificate chain) encoded as a CBOR
bstr. When the credential is a COSE_Key, CRED_x is a CBOR map only
contains specific fields from the COSE_Key. For COSE_Keys of type
OKP the CBOR map SHALL only include the parameters 1 (kty), -1 (crv),
and -2 (x-coordinate). For COSE_Keys of type EC2 the CBOR map SHALL
only include the parameters 1 (kty), -1 (crv), -2 (x-coordinate), and
-3 (y-coordinate). If the parties have agreed on an identity besides
the public key, the indentity is included in the CBOR map with the
label "subject name", otherwise the subject name is the empty text
string. The parameters SHALL be encoded in decreasing order with int
labels first and text string labels last. An example of CRED_x when
the RPK contains an X25519 static Diffie-Hellman key and the parties
have agreed on an EUI-64 identity is shown below:
CRED_x = { 5.1. Encoding of bstr_identifier
1: 1,
-1: 4,
-2: h'b1a3e89460e88d3a8d54211dc95f0b90
3ff205eb71912d6db8f4af980d2db83a',
"subject name" : "42-50-31-FF-EF-37-32-39"
}
4.3. Encoding of bstr_identifier Byte strings are encoded in CBOR as two or more bytes, whereas
integers in the interval -24 to 23 are encoded in CBOR as one byte.
A bstr_identifier is a special encoding for byte strings, used bstr_identifier is a special encoding of byte strings, used
throughout the protocol. throughout the protocol to enable the encoding of the shortest byte
strings as integers that only require one byte of CBOR encoding.
Byte strings of length greater than one are encoded as CBOR byte The bstr_identifier encoding is defined as follows: Byte strings in
strings. Byte strings of length one are encoded as the corresponding the interval h'00' to h'2f' are encoded as the corresponding integer
integer - 24. minus 24, which are all represented by one byte CBOR ints. Other
byte strings are encoded as CBOR byte strings.
For example, the byte string h'59e9' encoded as a bstr_identifier is For example, the byte string h'59e9' encoded as a bstr_identifier is
equal to h'59e9', while the byte string h'2a' is encoded as the equal to h'59e9', while the byte string h'2a' is encoded as the
integer 18. integer 18.
The CDDL definition of the bstr_identifier is given below: The CDDL definition of the bstr_identifier is given below:
bstr_identifier = bstr / int bstr_identifier = bstr / int
Note that, despite what could be interpreted by the CDDL definition Note that, despite what could be interpreted by the CDDL definition
only, bstr_identifier once decoded are always byte strings. only, bstr_identifier once decoded are always byte strings.
4.4. EDHOC Message 1 5.2. EDHOC Message 1
4.4.1. Formatting of Message 1 5.2.1. Formatting of Message 1
message_1 SHALL be a CBOR Sequence (see Appendix A.1) as defined message_1 SHALL be a CBOR Sequence (see Appendix A.1) as defined
below below
message_1 = ( message_1 = (
METHOD_CORR : int, METHOD_CORR : int,
SUITES_I : [ selected : suite, supported : 2* suite ] / suite, SUITES_I : [ selected : suite, supported : 2* suite ] / suite,
G_X : bstr, G_X : bstr,
C_I : bstr_identifier, C_I : bstr_identifier,
? AD_1 : bstr, ? AD_1 : bstr,
) )
suite = int suite = int
skipping to change at page 19, line 17 skipping to change at page 21, line 36
G_X : bstr, G_X : bstr,
C_I : bstr_identifier, C_I : bstr_identifier,
? AD_1 : bstr, ? AD_1 : bstr,
) )
suite = int suite = int
where: where:
o METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see o METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see
Section 8.2) and the correlation parameter corr is chosen based on Figure 4) and the correlation parameter corr is chosen based on
the transport and determines which connection identifiers that are the transport and determines which connection identifiers that are
omitted (see Section 3.1). omitted (see Section 3.2.4).
o SUITES_I - cipher suites which the Initiator supports in order of o SUITES_I - cipher suites which the Initiator supports in order of
(decreasing) preference. The list of supported cipher suites can (decreasing) preference. The list of supported cipher suites can
be truncated at the end, as is detailed in the processing steps be truncated at the end, as is detailed in the processing steps
below. One of the supported cipher suites is selected. If a below. One of the supported cipher suites is selected. The
single supported cipher suite is conveyed then that cipher suite selected suite is the first suite in the SUITES_I CBOR array. If
a single supported cipher suite is conveyed then that cipher suite
is selected and the selected cipher suite is encoded as an int is selected and the selected cipher suite is encoded as an int
instead of an array. instead of an array.
o G_X - the ephemeral public key of the Initiator o G_X - the ephemeral public key of the Initiator
o C_I - variable length connection identifier, encoded as a o C_I - variable length connection identifier, encoded as a
bstr_identifier (see Section 4.3). bstr_identifier (see Section 5.1).
o AD_1 - bstr containing unprotected opaque auxiliary data o AD_1 - bstr containing unprotected opaque auxiliary data
4.4.2. Initiator Processing of Message 1 5.2.2. Initiator Processing of Message 1
The Initiator SHALL compose message_1 as follows: The Initiator SHALL compose message_1 as follows:
o The supported cipher suites and the order of preference MUST NOT o The supported cipher suites and the order of preference MUST NOT
be changed based on previous error messages. However, the list be changed based on previous error messages. However, the list
SUITES_I sent to the Responder MAY be truncated such that cipher SUITES_I sent to the Responder MAY be truncated such that cipher
suites which are the least preferred are omitted. The amount of suites which are the least preferred are omitted. The amount of
truncation MAY be changed between sessions, e.g. based on previous truncation MAY be changed between sessions, e.g. based on previous
error messages (see next bullet), but all cipher suites which are error messages (see next bullet), but all cipher suites which are
more preferred than the least preferred cipher suite in the list more preferred than the least preferred cipher suite in the list
skipping to change at page 20, line 17 skipping to change at page 22, line 36
o Generate an ephemeral ECDH key pair as specified in Section 5 of o Generate an ephemeral ECDH key pair as specified in Section 5 of
[SP-800-56A] using the curve in the selected cipher suite and [SP-800-56A] using the curve in the selected cipher suite and
format it as a COSE_Key. Let G_X be the 'x' parameter of the format it as a COSE_Key. Let G_X be the 'x' parameter of the
COSE_Key. COSE_Key.
o Choose a connection identifier C_I and store it for the length of o Choose a connection identifier C_I and store it for the length of
the protocol. the protocol.
o Encode message_1 as a sequence of CBOR encoded data items as o Encode message_1 as a sequence of CBOR encoded data items as
specified in Section 4.4.1 specified in Section 5.2.1
4.4.3. Responder Processing of Message 1 5.2.3. Responder Processing of Message 1
The Responder SHALL process message_1 as follows: The Responder SHALL process message_1 as follows:
o Decode message_1 (see Appendix A.1). o Decode message_1 (see Appendix A.1).
o Verify that the selected cipher suite is supported and that no o Verify that the selected cipher suite is supported and that no
prior cipher suites in SUITES_I are supported. prior cipher suite in SUITES_I is supported.
o Pass AD_1 to the security application. o Pass AD_1 to the security application.
If any verification step fails, the Initiator MUST send an EDHOC If any verification step fails, the Responder MUST send an EDHOC
error message back, formatted as defined in Section 5, and the error message back, formatted as defined in Section 6, and the
protocol MUST be discontinued. If the Responder does not support the protocol MUST be discontinued. If the Responder does not support the
selected cipher suite, then SUITES_R MUST include one or more selected cipher suite, then SUITES_R MUST include one or more
supported cipher suites. If the Responder does not support the supported cipher suites. If the Responder does not support the
selected cipher suite, but supports another cipher suite in SUITES_I, selected cipher suite, but supports another cipher suite in SUITES_I,
then SUITES_R MUST include the first supported cipher suite in then SUITES_R MUST include the first supported cipher suite in
SUITES_I. SUITES_I.
4.5. EDHOC Message 2 5.3. EDHOC Message 2
4.5.1. Formatting of Message 2 5.3.1. Formatting of Message 2
message_2 and data_2 SHALL be CBOR Sequences (see Appendix A.1) as message_2 and data_2 SHALL be CBOR Sequences (see Appendix A.1) as
defined below defined below
message_2 = ( message_2 = (
data_2, data_2,
CIPHERTEXT_2 : bstr, CIPHERTEXT_2 : bstr,
) )
data_2 = ( data_2 = (
? C_I : bstr_identifier, ? C_I : bstr_identifier,
G_Y : bstr, G_Y : bstr,
C_R : bstr_identifier, C_R : bstr_identifier,
) )
where: where:
o G_Y - the ephemeral public key of the Responder o G_Y - the ephemeral public key of the Responder
skipping to change at page 21, line 15 skipping to change at page 23, line 32
? C_I : bstr_identifier, ? C_I : bstr_identifier,
G_Y : bstr, G_Y : bstr,
C_R : bstr_identifier, C_R : bstr_identifier,
) )
where: where:
o G_Y - the ephemeral public key of the Responder o G_Y - the ephemeral public key of the Responder
o C_R - variable length connection identifier, encoded as a o C_R - variable length connection identifier, encoded as a
bstr_identifier (see Section 4.3). bstr_identifier (see Section 5.1).
4.5.2. Responder Processing of Message 2 5.3.2. Responder Processing of Message 2
The Responder SHALL compose message_2 as follows: The Responder SHALL compose message_2 as follows:
o If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted, o If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted,
otherwise C_I is not omitted. otherwise C_I is not omitted.
o Generate an ephemeral ECDH key pair as specified in Section 5 of o Generate an ephemeral ECDH key pair as specified in Section 5 of
[SP-800-56A] using the curve in the selected cipher suite and [SP-800-56A] using the curve in the selected cipher suite and
format it as a COSE_Key. Let G_Y be the 'x' parameter of the format it as a COSE_Key. Let G_Y be the 'x' parameter of the
COSE_Key. COSE_Key.
skipping to change at page 21, line 44 skipping to change at page 24, line 14
hash TH_2 is a CBOR encoded bstr and the input to the hash hash TH_2 is a CBOR encoded bstr and the input to the hash
function is a CBOR Sequence. function is a CBOR Sequence.
o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of
[RFC8152], with the EDHOC AEAD algorithm in the selected cipher [RFC8152], with the EDHOC AEAD algorithm in the selected cipher
suite, K_2m, IV_2m, and the following parameters: suite, K_2m, IV_2m, and the following parameters:
* protected = << ID_CRED_R >> * protected = << ID_CRED_R >>
+ ID_CRED_R - identifier to facilitate retrieval of CRED_R, + ID_CRED_R - identifier to facilitate retrieval of CRED_R,
see Section 4.2 see Section 3.3.4
* external_aad = << TH_2, CRED_R, ? AD_2 >> * external_aad = << TH_2, CRED_R, ? AD_2 >>
+ CRED_R - bstr containing the credential of the Responder, + CRED_R - bstr containing the credential of the Responder,
see Section 4.2. see Section 3.3.4.
+ AD_2 = bstr containing opaque unprotected auxiliary data + AD_2 = bstr containing opaque unprotected auxiliary data
* plaintext = h'' * plaintext = h''
COSE constructs the input to the AEAD [RFC5116] as follows: COSE constructs the input to the AEAD [RFC5116] as follows:
* Key K = EDHOC-KDF( PRK_3e2m, TH_2, "K_2m", length ) * Key K = EDHOC-KDF( PRK_3e2m, TH_2, "K_2m", length )
* Nonce N = EDHOC-KDF( PRK_3e2m, TH_2, "IV_2m", length ) * Nonce N = EDHOC-KDF( PRK_3e2m, TH_2, "IV_2m", length )
* Plaintext P = 0x (the empty string) * Plaintext P = 0x (the empty string)
* Associated data A = * Associated data A =
[ "Encrypt0", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >> ] [ "Encrypt0", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >> ]
MAC_2 is the 'ciphertext' of the inner COSE_Encrypt0. MAC_2 is the 'ciphertext' of the inner COSE_Encrypt0.
o If the Reponder authenticates with a static Diffie-Hellman key o If the Responder authenticates with a static Diffie-Hellman key
(method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the
Reponder authenticates with a signature key (method equals 0 or Responder authenticates with a signature key (method equals 0 or
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
skipping to change at page 22, line 34 skipping to change at page 25, line 4
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 CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a o Compute an outer COSE_Encrypt0 as defined in Section 5.3 of
plaintext with the following common parameters: [RFC8152], with the EDHOC AEAD algorithm in the selected 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 4.2 and Section 4.3. see Section 3.3.4 and Section 5.1.
* CIPHERTEXT_2 = plaintext XOR K_2e COSE constructs the input to the AEAD [RFC5116] as follows:
* K_2e = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length ), where length * Key K = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length )
is the length of the plaintext.
* 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 4.5.1. specified in Section 5.3.1.
4.5.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. The decryption process depends on the o Decrypt CIPHERTEXT_2 by computing an outer COSE_Encrypt0 as
method, see Section 4.5.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.2. 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 4.5.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 Responder MUST send an EDHOC
error message back, formatted as defined in Section 5, and the error message back, formatted as defined in Section 6, and the
protocol MUST be discontinued. protocol MUST be discontinued.
4.6. EDHOC Message 3 5.4. EDHOC Message 3
4.6.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
message_3 = ( message_3 = (
data_3, data_3,
CIPHERTEXT_3 : bstr, CIPHERTEXT_3 : bstr,
) )
data_3 = ( data_3 = (
? C_R : bstr_identifier, ? C_R : bstr_identifier,
) )
4.6.2. Initiator Processing of Message 3 5.4.2. Initiator Processing of Message 3
The Initiator SHALL compose message_3 as follows: The Initiator SHALL compose message_3 as follows:
o If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted, o If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted,
otherwise C_R is not omitted. otherwise C_R is not omitted.
o Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3) o Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3)
where H() is the hash function in the the selected cipher suite. where H() is the hash function in the the selected cipher suite.
The transcript hash TH_3 is a CBOR encoded bstr and the input to The transcript hash TH_3 is a CBOR encoded bstr and the input to
the hash function is a CBOR Sequence. the hash function is a CBOR Sequence.
o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of
[RFC8152], with the EDHOC AEAD algorithm in the selected cipher [RFC8152], with the EDHOC AEAD algorithm in the selected cipher
suite, K_3m, IV_3m, and the following parameters: suite, K_3m, IV_3m, and the following parameters:
* protected = << ID_CRED_I >> * protected = << ID_CRED_I >>
+ ID_CRED_I - identifier to facilitate retrieval of CRED_I, + ID_CRED_I - identifier to facilitate retrieval of CRED_I,
see Section 4.2 see Section 3.3.4
* external_aad = << TH_3, CRED_I, ? AD_3 >> * external_aad = << TH_3, CRED_I, ? AD_3 >>
+ CRED_I - bstr containing the credential of the Initiator, + CRED_I - bstr containing the credential of the Initiator,
see Section 4.2. see Section 3.3.4.
+ AD_3 = bstr containing opaque protected auxiliary data + AD_3 = bstr containing opaque protected auxiliary data
* plaintext = h'' * plaintext = h''
COSE constructs the input to the AEAD [RFC5116] as follows: COSE constructs the input to the AEAD [RFC5116] as follows:
* Key K = EDHOC-KDF( PRK_4x3m, TH_3, "K_3m", length ) * Key K = EDHOC-KDF( PRK_4x3m, TH_3, "K_3m", length )
* Nonce N = EDHOC-KDF( PRK_4x3m, TH_3, "IV_3m", length ) * Nonce N = EDHOC-KDF( PRK_4x3m, TH_3, "IV_3m", length )
skipping to change at page 25, line 41 skipping to change at page 28, line 21
header SHALL be empty. header SHALL be empty.
* external_aad = TH_3 * external_aad = TH_3
* plaintext = ( ID_CRED_I / bstr_identifier, Signature_or_MAC_3, * plaintext = ( ID_CRED_I / bstr_identifier, Signature_or_MAC_3,
? AD_3 ) ? AD_3 )
+ Note that if ID_CRED_I contains a single 'kid' parameter, + Note that if ID_CRED_I contains a single 'kid' parameter,
i.e., ID_CRED_I = { 4 : kid_I }, only the byte string kid_I i.e., ID_CRED_I = { 4 : kid_I }, only the byte string kid_I
is conveyed in the plaintext encoded as a bstr_identifier, is conveyed in the plaintext encoded as a bstr_identifier,
see Section 4.2 and Section 4.3. see Section 3.3.4 and Section 5.1.
COSE constructs the input to the AEAD [RFC5116] as follows: COSE constructs the input to the AEAD [RFC5116] as follows:
* Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length ) * Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length )
* Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length ) * Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length )
* Plaintext P = ( ID_CRED_I / bstr_identifier, * Plaintext P = ( ID_CRED_I / bstr_identifier,
Signature_or_MAC_3, ? AD_3 ) Signature_or_MAC_3, ? AD_3 )
skipping to change at page 26, line 4 skipping to change at page 28, line 33
COSE constructs the input to the AEAD [RFC5116] as follows: COSE constructs the input to the AEAD [RFC5116] as follows:
* Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length ) * Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length )
* Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length ) * Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length )
* Plaintext P = ( ID_CRED_I / bstr_identifier, * Plaintext P = ( ID_CRED_I / bstr_identifier,
Signature_or_MAC_3, ? AD_3 ) Signature_or_MAC_3, ? AD_3 )
* Associated data A = [ "Encrypt0", h'', TH_3 ] * Associated data A = [ "Encrypt0", h'', TH_3 ]
CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0. CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0.
o Encode message_3 as a sequence of CBOR encoded data items as o Encode message_3 as a sequence of CBOR encoded data items as
specified in Section 4.6.1. specified in Section 5.4.1.
Pass the connection identifiers (C_I, C_R) and the application Pass the connection identifiers (C_I, C_R) and the application
algorithms in the selected cipher suite to the application. The algorithms in the selected cipher suite to the application. The
application can now derive application keys using the EDHOC-Exporter application can now derive application keys using the EDHOC-Exporter
interface. interface.
After sending message_3, the Initiator is assured that no other party After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (implicit key than the Responder can compute the key PRK_4x3m (implicit key
authentication). The Initiator does however not know that the authentication). The Initiator does however not know that the
Responder has actually computed the key PRK_4x3m. While the Responder has actually computed the key PRK_4x3m. While the
Initiator can securely send protected application data, the Initiator Initiator can securely send protected application data, the Initiator
SHOULD NOT store the keying material PRK_4x3m and TH_4 until the SHOULD NOT store the keying material PRK_4x3m and TH_4 until the
Initiator is assured that the Responder has actually computed the key Initiator is assured that the Responder has actually computed the key
PRK_4x3m (explicit key confirmation). Explicit key confirmation is PRK_4x3m (explicit key confirmation). Explicit key confirmation is
e.g. assured when the Initiator has verified an OSCORE message from e.g. assured when the Initiator has verified an OSCORE message from
the Responder. the Responder.
4.6.3. Responder Processing of Message 3 5.4.3. Responder Processing of Message 3
The Responder SHALL process message_3 as follows: The Responder SHALL process message_3 as follows:
o Decode message_3 (see Appendix A.1). o Decode message_3 (see Appendix A.1).
o Retrieve the protocol state using the connection identifier C_R o Retrieve the protocol state using the connection identifier C_R
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 and verify the outer COSE_Encrypt0 as defined in o Decrypt and verify the outer COSE_Encrypt0 as defined in
Section 5.3 of [RFC8152], with the EDHOC AEAD algorithm in the Section 5.3 of [RFC8152], with the EDHOC AEAD algorithm in the
selected cipher suite, K_3ae, and IV_3ae. selected cipher suite, K_3ae, and IV_3ae.
o Verify that the identity of the Initiator is an allowed identity o Verify that the identity of the Initiator is an allowed identity
for this connection, see Section 3.2. for this connection, see Section 3.3.
o Verify Signature_or_MAC_3 using the algorithm in the selected o Verify Signature_or_MAC_3 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 4.6.2. Section 5.4.2.
o Pass AD_3, the connection identifiers (C_I, C_R), and the o Pass AD_3, the connection identifiers (C_I, C_R), and the
application algorithms in the selected cipher suite to the application algorithms in the selected cipher suite to the
security application. The application can now derive application security application. The application can now derive application
keys using the EDHOC-Exporter interface. keys using the EDHOC-Exporter interface.
If any verification step fails, the Responder MUST send an EDHOC If any verification step fails, the Responder MUST send an EDHOC
error message back, formatted as defined in Section 5, and the error message back, formatted as defined in Section 6, and the
protocol MUST be discontinued. protocol MUST be discontinued.
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.
5. Error Handling 6. Error Handling
5.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 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 parties as a reply to any non-error EDHOC message. After sending an
error message, the protocol MUST be discontinued. Errors at the error message, the protocol MUST be discontinued. Errors at the
EDHOC layer are sent as normal successful messages in the lower EDHOC layer are sent as normal successful messages in the lower
layers (e.g. CoAP POST and 2.04 Changed). An advantage of using layers (e.g. CoAP POST and 2.04 Changed). An advantage of using
such a construction is to avoid issues created by usage of cross such a construction is to avoid issues created by usage of cross
protocol proxies (e.g. UDP to TCP). protocol proxies (e.g. UDP to TCP).
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, ERR_MSG : tstr,
? SUITES_R : [ supported : 2* suite ] / suite, ? SUITES_R : [ supported : 2* suite ] / suite,
) )
where: where:
o C_x - variable length connection identifier, encoded as a o C_x - (optional) variable length connection identifier, encoded as
bstr_identifier (see Section 4.3). 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 ERR_MSG - text string containing the diagnostic payload, defined
in the same way as in Section 5.5.2 of [RFC7252]. ERR_MSG MAY be in the same way as in Section 5.5.2 of [RFC7252]. ERR_MSG MAY be
a 0-length text string. a 0-length text string. This text string is mandatory and
characteristic for error messages, which enables the receiver to
distinguish between a normal message and an error message of the
protocol.
o SUITES_R - cipher suites from SUITES_I or the EDHOC cipher suites o SUITES_R - (optional) cipher suites from SUITES_I or the EDHOC
registry that the Responder supports. SUITES_R MUST only be cipher suites registry that the Responder supports. SUITES_R MUST
included in replies to message_1. If a single supported cipher only be included in replies to message_1. If a single supported
suite is conveyed then the supported cipher suite is encoded as an cipher suite is conveyed then the supported cipher suite is
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.
5.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 Responder 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. In Figure 5, the cipher suites that the Responder supports.
Responder supports cipher suite 6 but not the selected cipher suite
5. In Figure 5, the Responder supports cipher suite 6 but not the
initially selected cipher suite 5.
Initiator Responder Initiator Responder
| METHOD_CORR, SUITES_I = [5, 5, 6, 7], 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, ERR_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 but not cipher In Figure 6, the Responder supports cipher suite 7 and 9 but not the
suites 5 and 6. more preferred (by the Initiator) cipher suites 5 and 6. The order
of cipher suites in SUITES_R does not matter.
Initiator Responder Initiator Responder
| METHOD_CORR, SUITES_I = [5, 5, 6], 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 = [7, 9] | | C_I, ERR_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.
As the Initiator's list of supported cipher suites and order of Note that the Initiator's list of supported cipher suites and order
preference is fixed, and the Responder only accepts message_1 if the of preference is fixed (see Section 5.2.1 and Section 5.2.2).
Furthermore, the Responder shall only accept message_1 if the
selected cipher suite is the first cipher suite in SUITES_I that the selected cipher suite is the first cipher suite in SUITES_I that the
Responder supports, the parties can verify that the selected cipher Responder supports (see Section 5.2.3). Following this procedure
suite is the most preferred (by the Initiator) cipher suite supported ensures that the selected cipher suite is the most preferred (by the
by both parties. If the selected cipher suite is not the first Initiator) cipher suite supported by both parties.
cipher suite in SUITES_I that the Responder supports, the Responder
will discontinue the protocol.
6. Transferring EDHOC and Deriving an OSCORE Context If the selected cipher suite is not the first cipher suite which the
Responder supports in SUITES_I received in message_1, then Responder
MUST discontinue the protocol, see Section 5.2.3. If SUITES_I in
message_1 is manipulated then the integrity verification of message_2
containing the transcript hash TH_2 = H( message_1, data_2 ) will
fail and the Initiator will discontinue the protocol.
6.1. Transferring EDHOC in CoAP 7. Transferring EDHOC and Deriving an OSCORE Context
7.1. 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
sensitive identity, see Section 7. By default, EDHOC is transferred sensitive identity, see Section 8. By default, EDHOC is transferred
in POST requests and 2.04 (Changed) responses to the Uri-Path: in POST requests and 2.04 (Changed) responses to the Uri-Path:
"/.well-known/edhoc", but an application may define its own path that "/.well-known/edhoc", but an application may define its own path that
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
skipping to change at page 30, line 33 skipping to change at page 33, line 25
| | | |
+--------->| Header: POST (Code=0.02) +--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc" | POST | Uri-Path: "/.well-known/edhoc"
| | Content-Format: application/edhoc | | Content-Format: application/edhoc
| | Payload: EDHOC message_3 | | Payload: EDHOC message_3
| | | |
|<---------+ Header: 2.04 Changed |<---------+ Header: 2.04 Changed
| 2.04 | | 2.04 |
| | | |
Figure 7: Transferring EDHOC in CoAP Figure 7: Transferring EDHOC in CoAP when the Initiator is CoAP
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.
Client Server Client Server
skipping to change at page 31, line 24 skipping to change at page 34, line 24
+--------->| Header: POST (Code=0.02) +--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/edhoc" | POST | Uri-Path: "/.well-known/edhoc"
| | Content-Format: application/edhoc | | Content-Format: application/edhoc
| | Payload: EDHOC message_2 | | Payload: EDHOC message_2
| | | |
|<---------+ Header: 2.04 Changed |<---------+ Header: 2.04 Changed
| 2.04 | Content-Format: application/edhoc | 2.04 | Content-Format: application/edhoc
| | Payload: EDHOC message_3 | | Payload: EDHOC message_3
| | | |
Figure 8: Transferring EDHOC in CoAP Figure 8: Transferring EDHOC in CoAP when the Initiator is CoAP
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].
6.1.1. Deriving an OSCORE Context from EDHOC 7.1.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 32, line 8 skipping to change at page 35, line 12
o The AEAD Algorithm and the hash algorithm are the application AEAD o The AEAD Algorithm and the hash algorithm are the application AEAD
and hash algorithms in the selected cipher suite. and hash algorithms in the selected cipher suite.
o The Master Secret and Master Salt are derived as follows where o The Master Secret and Master Salt are derived as follows where
length is the key length (in bytes) of the application AEAD length is the key length (in bytes) of the application AEAD
Algorithm. Algorithm.
Master Secret = EDHOC-Exporter( "OSCORE Master Secret", length ) Master Secret = EDHOC-Exporter( "OSCORE Master Secret", length )
Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 ) Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 )
7. Security Considerations 8. Security Considerations
7.1. Security Properties 8.1. Security Properties
EDHOC inherits its security properties from the theoretical SIGMA-I EDHOC inherits its security properties from the theoretical SIGMA-I
protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides
perfect forward secrecy, mutual authentication with aliveness, perfect forward secrecy, mutual authentication with aliveness,
consistency, peer awareness. As described in [SIGMA], peer awareness consistency, peer awareness. As described in [SIGMA], peer awareness
is provided to the Responder, but not to the Initiator. is provided to the Responder, but not to the Initiator.
EDHOC protects the credential identifier of the Initiator against EDHOC protects the credential identifier of the Initiator against
active attacks and the credential identifier of the Responder against active attacks and the credential identifier of the Responder against
passive attacks. The roles should be assigned to protect the most passive attacks. The roles should be assigned to protect the most
skipping to change at page 33, line 42 skipping to change at page 36, line 46
ephemeral secret key can only attack that specific protocol run. ephemeral secret key can only attack that specific protocol run.
Repudiation: In EDHOC authenticated with signature keys, the Repudiation: In EDHOC authenticated with signature keys, the
Initiator could theoretically prove that the Responder performed a Initiator could theoretically prove that the Responder performed a
run of the protocol by presenting the private ephemeral key, and vice run of the protocol by presenting the private ephemeral key, and vice
versa. Note that storing the private ephemeral keys violates the versa. Note that storing the private ephemeral keys violates the
protocol requirements. With static Diffie-Hellman key protocol requirements. With static Diffie-Hellman key
authentication, both parties can always deny having participated in authentication, both parties can always deny having participated in
the protocol. the protocol.
7.2. Cryptographic Considerations 8.2. Cryptographic Considerations
The security of the SIGMA protocol requires the MAC to be bound to The security of the SIGMA protocol requires the MAC to be bound to
the identity of the signer. Hence the message authenticating the identity of the signer. Hence the message authenticating
functionality of the authenticated encryption in EDHOC is critical: functionality of the authenticated encryption in EDHOC is critical:
authenticated encryption MUST NOT be replaced by plain encryption authenticated encryption MUST NOT be replaced by plain encryption
only, even if authentication is provided at another level or through only, even if authentication is provided at another level or through
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
skipping to change at page 34, line 25 skipping to change at page 37, line 27
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.
7.3. Cipher Suites 8.3. Cipher Suites
Cipher suite number 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Cipher suite number 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA,
Ed25519, AES-CCM-16-64-128, SHA-256) is mandatory to implement. Ed25519, AES-CCM-16-64-128, SHA-256) is mandatory to implement.
Implementations only need to implement the algorithms needed for Implementations only need to implement the algorithms needed for
their supported methods. For many constrained IoT devices it is their supported methods. For many constrained IoT devices it is
problematic to support more than one cipher suites, so some problematic to support more than one cipher suites, so some
deployments with P-256 may not support the mandatory cipher suite. deployments with P-256 may not support the mandatory cipher suite.
This is not a problem for local deployments. This is not a problem for local deployments.
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.
7.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
the same AD_1 in several EDHOC sessions allows passive eavesdroppers the same AD_1 in several EDHOC sessions allows passive eavesdroppers
to correlate the different sessions. Another consideration is that to correlate the different sessions. Another consideration is that
the list of supported cipher suites may potentially be used to the list of supported cipher suites may potentially be used to
identify the application. identify the application.
The Initiator and the Responder must also make sure that The Initiator and the Responder must also make sure that
unauthenticated data does not trigger any harmful actions. In unauthenticated data does not trigger any harmful actions. In
particular, this applies to AD_1 and ERR_MSG. particular, this applies to AD_1 and ERR_MSG.
7.5. Denial-of-Service 8.5. Denial-of-Service
EDHOC itself does not provide countermeasures against Denial-of- EDHOC itself does not provide countermeasures against Denial-of-
Service attacks. By sending a number of new or replayed message_1 an Service attacks. By sending a number of new or replayed message_1 an
attacker may cause the Responder to allocate state, perform attacker may cause the Responder to allocate state, perform
cryptographic operations, and amplify messages. To mitigate such cryptographic operations, and amplify messages. To mitigate such
attacks, an implementation SHOULD rely on lower layer mechanisms such attacks, an implementation SHOULD rely on lower layer mechanisms such
as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that
forces the initiator to demonstrate reachability at its apparent forces the initiator to demonstrate reachability at its apparent
network address. network address.
7.6. Implementation Considerations 8.6. Implementation Considerations
The availability of a secure pseudorandom number generator and truly The availability of a secure pseudorandom number generator and truly
random seeds are essential for the security of EDHOC. If no true random seeds are essential for the security of EDHOC. If no true
random number generator is available, a truly random seed must be random number generator is available, a truly random seed must be
provided from an external source. As each pseudorandom number must provided from an external source. As each pseudorandom number must
only be used once, an implementation need to get a new truly random only be used once, an implementation need to get a new truly random
seed after reboot, or continuously store state in nonvolatile memory, seed after reboot, or continuously store state in nonvolatile memory,
see ([RFC8613], Appendix B.1.1) for issues and solution approaches see ([RFC8613], Appendix B.1.1) for issues and solution approaches
for writing to nonvolatile memory. If ECDSA is supported, for writing to nonvolatile memory. If ECDSA is supported,
"deterministic ECDSA" as specified in [RFC6979] is RECOMMENDED. "deterministic ECDSA" as specified in [RFC6979] is RECOMMENDED.
skipping to change at page 36, line 18 skipping to change at page 39, line 22
If two nodes unintentionally initiate two simultaneous EDHOC message If two nodes unintentionally initiate two simultaneous EDHOC message
exchanges with each other even if they only want to complete a single exchanges with each other even if they only want to complete a single
EDHOC message exchange, they MAY terminate the exchange with the EDHOC message exchange, they MAY terminate the exchange with the
lexicographically smallest G_X. If the two G_X values are equal, the lexicographically smallest G_X. If the two G_X values are equal, the
received message_1 MUST be discarded to mitigate reflection attacks. received message_1 MUST be discarded to mitigate reflection attacks.
Note that in the case of two simultaneous EDHOC exchanges where the Note that in the case of two simultaneous EDHOC exchanges where the
nodes only complete one and where the nodes have different preferred nodes only complete one and where the nodes have different preferred
cipher suites, an attacker can affect which of the two nodes' cipher suites, an attacker can affect which of the two nodes'
preferred cipher suites will be used by blocking the other exchange. preferred cipher suites will be used by blocking the other exchange.
7.7. Other Documents Referencing EDHOC 8.7. Other Documents Referencing EDHOC
EDHOC has been analyzed in several other documents. A formal EDHOC has been analyzed in several other documents. A formal
verification of EDHOC was done in [SSR18], an analysis of EDHOC for verification of EDHOC was done in [SSR18], an analysis of EDHOC for
certificate enrollment was done in [Kron18], the use of EDHOC in certificate enrollment was done in [Kron18], the use of EDHOC in
LoRaWAN is analyzed in [LoRa1] and [LoRa2], the use of EDHOC in IoT LoRaWAN is analyzed in [LoRa1] and [LoRa2], the use of EDHOC in IoT
bootstrapping is analyzed in [Perez18], and the use of EDHOC in bootstrapping is analyzed in [Perez18], and the use of EDHOC in
6TiSCH is described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. 6TiSCH is described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join].
8. IANA Considerations 9. IANA Considerations
8.1. EDHOC Cipher Suites Registry 9.1. EDHOC Cipher Suites Registry
IANA has created a new registry titled "EDHOC Cipher Suites" under IANA has created a new registry titled "EDHOC Cipher Suites" under
the new heading "EDHOC". The registration procedure is "Expert the new heading "EDHOC". The registration procedure is "Expert
Review". The columns of the registry are Value, Array, Description, Review". The columns of the registry are Value, Array, Description,
and Reference, where Value is an integer and the other columns are and Reference, where Value is an integer and the other columns are
text strings. The initial contents of the registry are: text strings. The initial contents of the registry are:
Value: -24 Value: -24
Algorithms: N/A Algorithms: N/A
Desc: Reserved for Private Use Desc: Reserved for Private Use
Reference: [[this document]] Reference: [[this document]]
Value: -23 Value: -23
Algorithms: N/A Algorithms: N/A
Desc: Reserved for Private Use Desc: Reserved for Private Use
Reference: [[this document]] Reference: [[this document]]
Value: -22
Algorithms: N/A
Desc: Reserved for Private Use
Reference: [[this document]]
Value: -21
Algorithms: N/A
Desc: Reserved for Private Use
Reference: [[this document]]
Value: 0 Value: 0
Array: 10, 5, 4, -8, 6, 10, 5 Array: 10, 5, 4, -8, 6, 10, 5
Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519, Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519,
AES-CCM-16-64-128, SHA-256 AES-CCM-16-64-128, SHA-256
Reference: [[this document]] Reference: [[this document]]
Value: 1 Value: 1
Array: 30, 5, 4, -8, 6, 10, 5 Array: 30, 5, 4, -8, 6, 10, 5
Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519, Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519,
AES-CCM-16-64-128, SHA-256 AES-CCM-16-64-128, SHA-256
Reference: [[this document]] Reference: [[this document]]
Value: 2 Value: 2
Array: 10, 5, 1, -7, 1, 10, 5 Array: 10, 5, 1, -7, 1, 10, 5
Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256, Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,
AES-CCM-16-64-128, SHA-256 AES-CCM-16-64-128, SHA-256
skipping to change at page 37, line 22 skipping to change at page 40, line 38
Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256, Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,
AES-CCM-16-64-128, SHA-256 AES-CCM-16-64-128, SHA-256
Reference: [[this document]] Reference: [[this document]]
Value: 3 Value: 3
Array: 30, 5, 1, -7, 1, 10, 5 Array: 30, 5, 1, -7, 1, 10, 5
Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256, Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256,
AES-CCM-16-64-128, SHA-256 AES-CCM-16-64-128, SHA-256
Reference: [[this document]] Reference: [[this document]]
8.2. EDHOC Method Type Registry Value: 4
Array: 1, -16, 4, -7, 1, 1, -16
Desc: A128GCM, SHA-256, X25519, ES256, P-256,
A128GCM, SHA-256
Reference: [[this document]]
Value: 5
Array: 3, -43, 2, -35, 2, 3, -43
Desc: A256GCM, SHA-384, P-384, ES384, P-384,
A256GCM, SHA-384
Reference: [[this document]]
9.2. EDHOC Method Type Registry
IANA has created a new registry titled "EDHOC Method Type" under the IANA has created a new registry titled "EDHOC Method Type" under the
new heading "EDHOC". The registration procedure is "Expert Review". new heading "EDHOC". The registration procedure is "Expert Review".
The columns of the registry are Value, Description, and Reference, The columns of the registry are Value, Description, and Reference,
where Value is an integer and the other columns are text strings. where Value is an integer and the other columns are text strings.
The initial contents of the registry are: The initial contents of the registry is shown in Figure 4.
+-------+-------------------+-------------------+-------------------+
| Value | Initiator | Responder | Reference |
+-------+-------------------+-------------------+-------------------+
| 0 | Signature Key | Signature Key | [[this document]] |
| 1 | Signature Key | Static DH Key | [[this document]] |
| 2 | Static DH Key | Signature Key | [[this document]] |
| 3 | Static DH Key | Static DH Key | [[this document]] |
+-------+-------------------+-------------------+-------------------+
Figure 9: Method Types
8.3. The Well-Known URI Registry 9.3. The Well-Known URI Registry
IANA has added the well-known URI 'edhoc' to the Well-Known URIs IANA has added the well-known URI 'edhoc' to the Well-Known URIs
registry. registry.
o URI suffix: edhoc o URI suffix: edhoc
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[this document]] o Specification document(s): [[this document]]
o Related information: None o Related information: None
8.4. Media Types Registry 9.4. Media Types Registry
IANA has added the media type 'application/edhoc' to the Media Types IANA has added the media type 'application/edhoc' to the Media Types
registry. registry.
o Type name: application o Type name: application
o Subtype name: edhoc o Subtype name: edhoc
o Required parameters: N/A o Required parameters: N/A
skipping to change at page 39, line 5 skipping to change at page 42, line 22
"Authors' Addresses" section. "Authors' Addresses" section.
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: N/A o Restrictions on usage: N/A
o Author: See "Authors' Addresses" section. o Author: See "Authors' Addresses" section.
o Change Controller: IESG o Change Controller: IESG
8.5. CoAP Content-Formats Registry 9.5. CoAP Content-Formats Registry
IANA has added the media type 'application/edhoc' to the CoAP IANA has added the media type 'application/edhoc' to the CoAP
Content-Formats registry. Content-Formats registry.
o Media Type: application/edhoc o Media Type: application/edhoc
o Encoding: o Encoding:
o ID: TBD42 o ID: TBD42
o Reference: [[this document]] o Reference: [[this document]]
8.6. Expert Review Instructions 9.6. Expert Review Instructions
The IANA Registries established in this document is defined as The IANA Registries established in this document is defined as
"Expert Review". This section gives some general guidelines for what "Expert Review". This section gives some general guidelines for what
the experts should be looking for, but they are being designated as the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude. experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
o Clarity and correctness of registrations. Experts are expected to o Clarity and correctness of registrations. Experts are expected to
check the clarity of purpose and use of the requested entries. check the clarity of purpose and use of the requested entries.
skipping to change at page 39, line 46 skipping to change at page 43, line 15
o Experts should take into account the expected usage of fields when o Experts should take into account the expected usage of fields when
approving point assignment. The length of the encoded value approving point assignment. The length of the encoded value
should be weighed against how many code points of that length are should be weighed against how many code points of that length are
left, the size of device it will be used on, and the number of left, the size of device it will be used on, and the number of
code points left that encode to that size. code points left that encode to that size.
o Specifications are recommended. When specifications are not o Specifications are recommended. When specifications are not
provided, the description provided needs to have sufficient provided, the description provided needs to have sufficient
information to verify the points above. information to verify the points above.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", draft-ietf-core-echo- Request-Tag, and Token Processing", draft-ietf-core-echo-
request-tag-10 (work in progress), July 2020. request-tag-11 (work in progress), November 2020.
[I-D.ietf-cose-x509] [I-D.ietf-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header parameters for carrying and referencing X.509 Header parameters for carrying and referencing X.509
certificates", draft-ietf-cose-x509-07 (work in progress), certificates", draft-ietf-cose-x509-08 (work in progress),
September 2020. December 2020.
[I-D.ietf-lake-reqs] [I-D.ietf-lake-reqs]
Vucinic, M., Selander, G., Mattsson, J., and D. Garcia- Vucinic, M., Selander, G., Mattsson, J., and D. Garcia-
Carillo, "Requirements for a Lightweight AKE for OSCORE", Carillo, "Requirements for a Lightweight AKE for OSCORE",
draft-ietf-lake-reqs-04 (work in progress), June 2020. draft-ietf-lake-reqs-04 (work in progress), June 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 40, line 45 skipping to change at page 44, line 10
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011, DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>. <https://www.rfc-editor.org/info/rfc6090>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
skipping to change at page 41, line 41 skipping to change at page 45, line 5
[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>.
[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>.
9.2. Informative References [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
10.2. Informative References
[CborMe] Bormann, C., "CBOR Playground", May 2018, [CborMe] Bormann, C., "CBOR Playground", May 2018,
<http://cbor.me/>. <http://cbor.me/>.
[CNSA] (Placeholder), ., "Commercial National Security Algorithm
Suite", August 2015,
<https://apps.nsa.gov/iaarchive/programs/iad-initiatives/
cnsa-suite.cfm>.
[I-D.ietf-6tisch-dtsecurity-zerotouch-join] [I-D.ietf-6tisch-dtsecurity-zerotouch-join]
Richardson, M., "6tisch Zero-Touch Secure Join protocol", Richardson, M., "6tisch Zero-Touch Secure Join protocol",
draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in
progress), July 2019. progress), July 2019.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36
(work in progress), June 2020. (work in progress), November 2020.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.
Stok, "CoRE Resource Directory", draft-ietf-core-resource- Stok, "CoRE Resource Directory", draft-ietf-core-resource-
directory-26 (work in progress), November 2020. directory-26 (work in progress), November 2020.
[I-D.ietf-lwig-security-protocol-comparison] [I-D.ietf-lwig-security-protocol-comparison]
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-38 (work in progress), May 1.3", draft-ietf-tls-dtls13-39 (work in progress),
2020. November 2020.
[I-D.palombini-core-oscore-edhoc]
Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S.,
and G. Selander, "Combining EDHOC and OSCORE", draft-
palombini-core-oscore-edhoc-01 (work in progress),
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-
authz-01 (work in progress), March 2020. authz-02 (work in progress), November 2020.
[Kron18] Krontiris, A., "Evaluation of Certificate Enrollment over [Kron18] Krontiris, A., "Evaluation of Certificate Enrollment over
Application Layer Security", May 2018, Application Layer Security", May 2018,
<https://www.nada.kth.se/~ann/exjobb/ <https://www.nada.kth.se/~ann/exjobb/
alexandros_krontiris.pdf>. alexandros_krontiris.pdf>.
[LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., [LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S.,
Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. Fernandez, P., Santa, J., Hernandez-Ramos, J., and A.
Skarmeta, "Enhancing LoRaWAN Security through a Skarmeta, "Enhancing LoRaWAN Security through a
Lightweight and Authenticated Key Management Approach", Lightweight and Authenticated Key Management Approach",
skipping to change at page 44, line 8 skipping to change at page 47, line 31
[SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T., [SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T.,
and C. Schuermann, "Formal Verification of Ephemeral and C. Schuermann, "Formal Verification of Ephemeral
Diffie-Hellman Over COSE (EDHOC)", November 2018, Diffie-Hellman Over COSE (EDHOC)", November 2018,
<https://www.springerprofessional.de/en/formal- <https://www.springerprofessional.de/en/formal-
verification-of-ephemeral-diffie-hellman-over-cose- verification-of-ephemeral-diffie-hellman-over-cose-
edhoc/16284348>. edhoc/16284348>.
Appendix A. Use of CBOR, CDDL and COSE in EDHOC Appendix A. Use of CBOR, CDDL and COSE in EDHOC
This Appendix is intended to simplify for implementors not familiar This Appendix is intended to simplify for implementors not familiar
with CBOR [RFC7049], CDDL [RFC8610], COSE [RFC8152], and HKDF with CBOR [RFC8949], CDDL [RFC8610], COSE [RFC8152], and HKDF
[RFC5869]. [RFC5869].
A.1. CBOR and CDDL A.1. CBOR and CDDL
The Concise Binary Object Representation (CBOR) [RFC7049] is a data The Concise Binary Object Representation (CBOR) [RFC8949] is a data
format designed for small code size and small message size. CBOR format designed for small code size and small message size. CBOR
builds on the JSON data model but extends it by e.g. encoding binary builds on the JSON data model but extends it by e.g. encoding binary
data directly without base64 conversion. In addition to the binary data directly without base64 conversion. In addition to the binary
CBOR encoding, CBOR also has a diagnostic notation that is readable CBOR encoding, CBOR also has a diagnostic notation that is readable
and editable by humans. The Concise Data Definition Language (CDDL) and editable by humans. The Concise Data Definition Language (CDDL)
[RFC8610] provides a way to express structures for protocol messages [RFC8610] provides a way to express structures for protocol messages
and APIs that use CBOR. [RFC8610] also extends the diagnostic and APIs that use CBOR. [RFC8610] also extends the diagnostic
notation. notation.
CBOR data items are encoded to or decoded from byte strings using a CBOR data items are encoded to or decoded from byte strings using a
type-length-value encoding scheme, where the three highest order bits type-length-value encoding scheme, where the three highest order bits
of the initial byte contain information about the major type. CBOR of the initial byte contain information about the major type. CBOR
supports several different types of data items, in addition to supports several different types of data items, in addition to
integers (int, uint), simple values (e.g. null), byte strings (bstr), integers (int, uint), simple values (e.g. null), byte strings (bstr),
and text strings (tstr), CBOR also supports arrays [] of data items, and text strings (tstr), CBOR also supports arrays [] of data items,
maps {} of pairs of data items, and sequences [RFC8742] of data maps {} of pairs of data items, and sequences [RFC8742] of data
items. Some examples are given below. For a complete specification items. Some examples are given below. For a complete specification
and more examples, see [RFC7049] and [RFC8610]. We recommend and more examples, see [RFC8949] and [RFC8610]. We recommend
implementors to get used to CBOR by using the CBOR playground implementors to get used to CBOR by using the CBOR playground
[CborMe]. [CborMe].
Diagnostic Encoded Type Diagnostic Encoded Type
------------------------------------------------------------------ ------------------------------------------------------------------
1 0x01 unsigned integer 1 0x01 unsigned integer
24 0x1818 unsigned integer 24 0x1818 unsigned integer
-24 0x37 negative integer -24 0x37 negative integer
-25 0x3818 negative integer -25 0x3818 negative integer
null 0xf6 simple value null 0xf6 simple value
skipping to change at page 45, line 23 skipping to change at page 48, line 44
Appendix B. Test Vectors Appendix B. Test Vectors
This appendix provides detailed test vectors to ease implementation This appendix provides detailed test vectors to ease implementation
and ensure interoperability. In addition to hexadecimal, all CBOR and ensure interoperability. In addition to hexadecimal, all CBOR
data items and sequences are given in CBOR diagnostic notation. The data items and sequences are given in CBOR diagnostic notation. The
test vectors use the default mapping to CoAP where the Initiator acts test vectors use the default mapping to CoAP where the Initiator acts
as CoAP client (this means that corr = 1). 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 related code to generate them can be found at https://github.com/
https://github.com/EricssonResearch/EDHOC/tree/master/Test%20Vectors 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
certificate. certificate.
method (Signature Authentication) method (Signature Authentication)
0 0
skipping to change at page 46, line 14 skipping to change at page 49, line 33
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 The mandatory-to-implement cipher suite 0 is supported by both the
Initiator and the Responder, see Section 7.3. Initiator and the Responder, 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 47, line 36 skipping to change at page 50, line 51
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 3.8. 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)
From there, PRK_2e is computed: From there, PRK_2e is computed:
skipping to change at page 48, line 22 skipping to change at page 51, line 37
ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f
d8 2f be b7 99 71 39 4a d8 2f be b7 99 71 39 4a
The Responder chooses a connection identifier C_R. The Responder chooses a connection identifier C_R.
Connection identifier chosen by Responder (1 byte) Connection identifier chosen by Responder (1 byte)
2b 2b
Note that since C_R is a byte string of length one, it is encoded as Note that since C_R is a byte string of length one, it is encoded as
the corresponding integer subtracted by 24 (see bstr_identifier in the corresponding integer subtracted by 24 (see bstr_identifier in
Section 4.3). Thus 0x2b = 43, 43 - 24 = 19, and 19 in CBOR encoding Section 5.1). Thus 0x2b = 43, 43 - 24 = 19, and 19 in CBOR encoding
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',
skipping to change at page 60, line 44 skipping to change at page 63, line 52
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 The mandatory-to-implement cipher suite 0 is supported by both the
Initiator and the Responder, see Section 7.3. Initiator and the Responder, 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
The Initiator chooses a connection identifier C_I: The Initiator chooses a connection identifier C_I:
Connection identifier chosen by Initiator (1 bytes) Connection identifier chosen by Initiator (1 bytes)
16 16
Note that since C_I is a byte strings of length one, it is encoded as Note that since C_I is a byte strings of length one, it is encoded as
skipping to change at page 61, line 14 skipping to change at page 64, line 21
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
The Initiator chooses a connection identifier C_I: The Initiator chooses a connection identifier C_I:
Connection identifier chosen by Initiator (1 bytes) Connection identifier chosen by Initiator (1 bytes)
16 16
Note that since C_I is a byte strings of length one, it is encoded as Note that since C_I is a byte strings of length one, it is encoded as
the corresponding integer - 24 (see bstr_identifier in Section 4.3), the corresponding integer - 24 (see bstr_identifier in Section 5.1),
i.e. 0x16 = 22, 22 - 24 = -2, and -2 in CBOR encoding is equal to i.e. 0x16 = 22, 22 - 24 = -2, and -2 in CBOR encoding is equal to
0x21. 0x21.
C_I (1 byte) C_I (1 byte)
21 21
Since no unprotected opaque auxiliary data is sent in the message Since no unprotected opaque auxiliary data is sent in the message
exchanges: exchanges:
AD_1 (0 bytes) AD_1 (0 bytes)
skipping to change at page 62, line 24 skipping to change at page 65, line 28
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 3.8. 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)
From there, PRK_2e is computed: From there, PRK_2e is computed:
PRK_2e (32 bytes) PRK_2e (32 bytes)
93 9f cb 05 6d 2e 41 4f 1b ec 61 04 61 99 c2 c7 63 d2 7f 0c 3d 15 fa 16 93 9f cb 05 6d 2e 41 4f 1b ec 61 04 61 99 c2 c7 63 d2 7f 0c 3d 15 fa 16
71 fa 13 4e 0d c5 a0 4d 71 fa 13 4e 0d c5 a0 4d
SK_R (Responders's private authentication key) (32 bytes)
bb 50 1a ac 67 b9 a9 5f 97 e0 ed ed 6b 82 a6 62 93 4f bb fc 7a d1 b7 4c
1f ca d6 6a 07 94 22 d0
Since the Responder authenticates with a static Diffie-Hellman key, Since the Responder authenticates with a static Diffie-Hellman key,
PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX is the ECDH PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX is the ECDH
shared secret calculated from G_R and X, or G_X and R. shared secret calculated from G_R and X, or G_X and R.
R (Responder's private authentication key) (32 bytes) R (Responder's private authentication key) (32 bytes)
bb 50 1a ac 67 b9 a9 5f 97 e0 ed ed 6b 82 a6 62 93 4f bb fc 7a d1 b7 4c bb 50 1a ac 67 b9 a9 5f 97 e0 ed ed 6b 82 a6 62 93 4f bb fc 7a d1 b7 4c
1f ca d6 6a 07 94 22 d0 1f ca d6 6a 07 94 22 d0
G_R (Responder's public authentication key) (32 bytes) G_R (Responder's public authentication key) (32 bytes)
a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04 da d2 d4 09 66 ac 6b cb 62 20 51 a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04 da d2 d4 09 66 ac 6b cb 62 20 51
b8 46 59 18 4d 5d 9a 32 b8 46 59 18 4d 5d 9a 32
skipping to change at page 63, line 25 skipping to change at page 66, line 25
PRK_3e2m (32 bytes) PRK_3e2m (32 bytes)
75 07 7c 69 1e 35 01 2d 48 bc 24 c8 4f 2b ab 89 f5 2f ac 03 fe dd 81 3e 75 07 7c 69 1e 35 01 2d 48 bc 24 c8 4f 2b ab 89 f5 2f ac 03 fe dd 81 3e
43 8c 93 b1 0b 39 93 07 43 8c 93 b1 0b 39 93 07
The Responder chooses a connection identifier C_R. The Responder chooses a connection identifier C_R.
Connection identifier chosen by Responder (1 byte) Connection identifier chosen by Responder (1 byte)
20 20
Note that since C_R is a byte strings of length one, it is encoded as Note that since C_R is a byte strings of length one, it is encoded as
the corresponding integer - 24 (see bstr_identifier in Section 4.3), the corresponding integer - 24 (see bstr_identifier in Section 5.1),
i.e. 0x20 = 32, 32 - 24 = 8, and 8 in CBOR encoding is equal to 0x08. i.e. 0x20 = 32, 32 - 24 = 8, and 8 in CBOR encoding is equal to 0x08.
C_R (1 byte) C_R (1 byte)
08 08
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'52FBA0BDC8D953DD86CE1AB2FD7C05A4658C7C30AFDBFC3301047069451BAF35', h'52FBA0BDC8D953DD86CE1AB2FD7C05A4658C7C30AFDBFC3301047069451BAF35',
skipping to change at page 66, line 50 skipping to change at page 69, line 50
64 21 0d 2e 18 b9 28 cd 64 21 0d 2e 18 b9 28 cd
CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a
plaintext constructed from the following parameters and the key K_2e. plaintext constructed from the following parameters and the key K_2e.
o plaintext = CBOR Sequence of the items ID_CRED_R and the CBOR o plaintext = CBOR Sequence of the items ID_CRED_R and the CBOR
encoded Signature_or_MAC_2, in this order. Note that since encoded Signature_or_MAC_2, in this order. Note that since
ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4 ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4
: kid_R }, only the byte string kid_R is conveyed in the plaintext : kid_R }, only the byte string kid_R is conveyed in the plaintext
encoded as a bstr_identifier. kid_R is encoded as the encoded as a bstr_identifier. kid_R is encoded as the
corresponding integer - 24 (see bstr_identifier in Section 4.3), corresponding integer - 24 (see bstr_identifier in Section 5.1),
i.e. 0x07 = 7, 7 - 24 = -17, and -17 in CBOR encoding is equal to i.e. 0x07 = 7, 7 - 24 = -17, and -17 in CBOR encoding is equal to
0x30. 0x30.
The plaintext is the following: The plaintext is the following:
P_2e (CBOR Sequence) (10 bytes) P_2e (CBOR Sequence) (10 bytes)
30 48 64 21 0d 2e 18 b9 28 cd 30 48 64 21 0d 2e 18 b9 28 cd
K_2e = HKDF-Expand( PRK, info, length ), where length is the length K_2e = HKDF-Expand( PRK, info, length ), where length is the length
of the plaintext, so 80. of the plaintext, so 10.
info for K_2e = info for K_2e =
[ [
10, 10,
h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF', h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF',
"K_2e", "K_2e",
10 10
] ]
Which as a CBOR encoded data item is: Which as a CBOR encoded data item is:
skipping to change at page 71, line 20 skipping to change at page 74, line 20
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.
The Plaintext is the following CBOR Sequence: plaintext = ( ID_CRED_I The Plaintext is the following CBOR Sequence: plaintext = ( ID_CRED_I
, Signature_or_MAC_3 ). Note that since ID_CRED_I contains a single , Signature_or_MAC_3 ). Note that since ID_CRED_I contains a single
'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte
string kid_I is conveyed in the plaintext encoded as a string kid_I is conveyed in the plaintext encoded as a
bstr_identifier. kid_I is encoded as the corresponding integer - 24 bstr_identifier. kid_I is encoded as the corresponding integer - 24
(see bstr_identifier in Section 4.3), i.e. 0x24 = 36, 36 - 24 = 12, (see bstr_identifier in Section 5.1), i.e. 0x24 = 36, 36 - 24 = 12,
and 12 in CBOR encoding is equal to 0x0c. and 12 in CBOR encoding is equal to 0x0c.
P_3ae (CBOR Sequence) (10 bytes) P_3ae (CBOR Sequence) (10 bytes)
0c 48 1f b7 5a c1 aa d2 34 25 0c 48 1f b7 5a c1 aa d2 34 25
The Associated data A is the following: Associated data A = [ The Associated data A is the following: Associated data A = [
"Encrypt0", h'', TH_3 ] "Encrypt0", h'', TH_3 ]
A_3ae (CBOR-encoded) (45 bytes) A_3ae (CBOR-encoded) (45 bytes)
83 68 45 6e 63 72 79 70 74 30 40 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 83 68 45 6e 63 72 79 70 74 30 40 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53
skipping to change at page 73, line 8 skipping to change at page 76, line 8
( (
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
Appendix C. Applicability Statement Template
EDHOC requires certain parameters to be agreed upon between Initiator
and Responder. A cipher suite is negotiated with the protocol, but
certain other parameters need to be agreed beforehand:
1. Method and correlation of underlying transport messages
(METHOD_CORR, see Section 3.2.1 and Section 3.2.4).
2. Type of authentication credentials (CRED_I, CRED_R, see
Section 3.3.4).
3. Type for identifying authentication credentials (ID_CRED_I,
ID_CRED_R, see Section 3.3.4).
4. Type and use of Auxiliary Data AD_1, AD_2, AD_3 (see
Section 3.6).
5. Identifier used as identity of endpoint (see Section 3.3).
An example of an applicability statement is shown in the next
section.
Note that for some of the parameters, like METHOD_CORR, ID_CRED_x,
type of AD_x, the receiver is able to assert whether it supports the
parameter or not and thus, if it fails, to infer why.
For other parameters, like type of authentication credential, it may
be more difficult to detect if the receiver got the wrong type since
the credential is not necessarily transported, and a failed integrity
of the received message may be caused by other circumstances. For
example in the case of public key certificates there is a large
variety of profiles and alternative encodings, which the
applicability statement needs to nail down.
Note also that it is not always necessary for the endpoints to agree
on the transport for the EDHOC messages. For example, a mix of CoAP
and HTTP may be used along the path and still allow correlation
between message_1 and message_2.
C.1. Use of EDHOC in the XX Protocol
For use of EDHOC in the XX protocol, the following assumptions are
made on the parameters.
o METHOD_CORR = 5
* method = 1 (I uses signature key, R uses static DH key.)
* corr = 1 (CoAP Token or other transport data enables
correlation between message_1 and message_2.)
o CRED_I is an 802.1AR IDevID encoded as a CBOR Certificate of type
0
* R acquires CRED_I out-of-band, indicated in AD_1
* 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.
* The CBOR map has parameters 1 (kty), -1 (crv), and -2
(x-coordinate).
o ID_CRED_R = CRED_R
o AD_1 contains Auxiliary Data of type A (TBD)
o AD_2 contains Auxiliary Data of type B (TBD)
Auxiliary Data is processed as specified in
[I-D.ietf-ace-oauth-authz].
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, Martin Disch, Theis Groenbech Petersen, Dan Harkins, Klaus Hartke,
Russ Housley, Alexandros Krontiris, Ilari Liusvaara, Karl Norrman, Russ Housley, Alexandros Krontiris, Ilari Liusvaara, Karl Norrman,
Salvador Perez, Eric Rescorla, Michael Richardson, Thorvald Sahl Salvador Perez, Eric Rescorla, Michael Richardson, Thorvald Sahl
Joergensen, Jim Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav Joergensen, Jim Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav
Smyshlyaev, Valery Smyslov, Rene Struik, Vaishnavi Sundararajan, Erik Smyshlyaev, Valery Smyslov, Rene Struik, Vaishnavi Sundararajan, Erik
Thormarker, and Michel Veillette for reviewing and commenting on Thormarker, and Michel Veillette 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
 End of changes. 176 change blocks. 
455 lines changed or deleted 697 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/