draft-ietf-lake-edhoc-01.txt   draft-ietf-lake-edhoc-02.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: February 3, 2021 Ericsson AB Expires: May 6, 2021 Ericsson AB
August 02, 2020 November 02, 2020
Ephemeral Diffie-Hellman Over COSE (EDHOC) Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-edhoc-01 draft-ietf-lake-edhoc-02
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 3, 2021. This Internet-Draft will expire on May 6, 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 . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology and Requirements Language . . . . . . . . . . 5 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology and Requirements Language . . . . . . . . . . 6
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 7 3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transport and Message Correlation . . . . . . . . . . . . 8 3.1. Transport and Message Correlation . . . . . . . . . . . . 9
3.2. Authentication Keys and Identities . . . . . . . . . . . 9 3.2. Authentication Keys and Identities . . . . . . . . . . . 10
3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Communication/Negotiation of Protocol Features . . . . . 11 3.5. Communication/Negotiation of Protocol Features . . . . . 12
3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 12 3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 13
3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 12 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 13
3.8. Key Derivation . . . . . . . . . . . . . . . . . . . . . 12 3.8. Key Derivation . . . . . . . . . . . . . . . . . . . . . 13
4. EDHOC Authenticated with Asymmetric Keys . . . . . . . . . . 15 4. EDHOC Authenticated with Asymmetric Keys . . . . . . . . . . 16
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 17 4.2. Encoding of Public Authentication Key Identifiers . . . . 16
4.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 19 4.3. Encoding of bstr_identifier . . . . . . . . . . . . . . . 18
4.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 22 4.4. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 18
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25 4.5. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 20
5.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 25 4.6. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 23
6. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 27 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 27 5.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 29
7.1. Security Properties . . . . . . . . . . . . . . . . . . . 30 6.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 29
7.2. Cryptographic Considerations . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Security Properties . . . . . . . . . . . . . . . . . . . 32
7.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 32 7.2. Cryptographic Considerations . . . . . . . . . . . . . . 33
7.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 32 7.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 34
7.6. Implementation Considerations . . . . . . . . . . . . . . 33 7.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 34
7.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 34 7.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7.6. Implementation Considerations . . . . . . . . . . . . . . 35
8.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 34 7.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 36
8.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 35 8.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 36
8.4. Media Types Registry . . . . . . . . . . . . . . . . . . 36 8.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 37
8.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 37 8.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 37
8.6. Expert Review Instructions . . . . . . . . . . . . . . . 37 8.4. Media Types Registry . . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.6. Expert Review Instructions . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . 39 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 42 9.1. Normative References . . . . . . . . . . . . . . . . . . 39
A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 42 9.2. Informative References . . . . . . . . . . . . . . . . . 41
A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 44
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 43 A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 44
A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 45
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) . . . . . . . . . . . . . . . . . . . . . . . . . . 43 (x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 B.2. Test Vectors for EDHOC Authenticated with Static Diffie-
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Hellman Keys . . . . . . . . . . . . . . . . . . . . . . 60
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
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
transport layer security is not sufficient protection needs to work over a variety of underlying protocols. IoT
[I-D.hartke-core-e2e-security-reqs] or where the protection needs to devices may be constrained in various ways, including memory,
work over a variety of underlying protocols. IoT devices may be storage, processing capacity, and energy [RFC7228]. A method for
constrained in various ways, including memory, storage, processing protecting individual messages at the application layer suitable for
capacity, and energy [RFC7228]. A method for protecting individual constrained devices, is provided by CBOR Object Signing and
messages at the application layer suitable for constrained devices, Encryption (COSE) [RFC8152]), which builds on the Concise Binary
is provided by CBOR Object Signing and Encryption (COSE) [RFC8152]), Object Representation (CBOR) [RFC7049]. Object Security for
which builds on the Concise Binary Object Representation (CBOR) Constrained RESTful Environments (OSCORE) [RFC8613] is a method for
[RFC7049]. Object Security for Constrained RESTful Environments application-layer protection of the Constrained Application Protocol
(OSCORE) [RFC8613] is a method for application-layer protection of (CoAP), using COSE.
the Constrained Application Protocol (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.
Authentication is based on credentials established out of band, e.g. Authentication is based on credentials established out of band, e.g.
from a trusted third party, such as an Authorization Server as from a trusted third party, such as an Authorization Server as
specified by [I-D.ietf-ace-oauth-authz]. The construction provided specified by [I-D.ietf-ace-oauth-authz]. The construction provided
by EDHOC can be applied to authenticate raw public keys (RPK) and by EDHOC can be applied to authenticate raw public keys (RPK) and
public key certificates. This version of the protocol is focusing on public key certificates. This version of the protocol is focusing on
RPK and certificates by reference which is the initial focus for the RPK and certificates by reference which is the initial focus for the
LAKE WG (see Section 2.2 of [I-D.ietf-lake-reqs]). LAKE WG (see Section 2.2 of [I-D.ietf-lake-reqs]).
After successful completion of the EDHOC protocol, application keys After successful completion of the EDHOC protocol, application keys
and other application specific data can be derived using the EDHOC- and other application specific data can be derived using the EDHOC-
Exporter interface. A main use case for EDHOC is to establish an Exporter interface. A main use case for EDHOC is to establish an
OSCORE security context. EDHOC uses COSE for cryptography, CBOR for OSCORE security context. EDHOC uses COSE for cryptography, CBOR for
encoding, and CoAP for transport. By reusing existing libraries, the encoding, and CoAP for transport. By reusing existing libraries, the
additional code footprint can be kept very low. Note that this additional code footprint can be kept very low.
document focuses on authentication and key establishment: for
integration with authorization of resource access, refer to
[I-D.ietf-ace-oscore-profile].
EDHOC is designed for highly constrained settings making it EDHOC is designed for highly constrained settings making it
especially suitable for low-power wide area networks [RFC8376] such especially suitable for low-power wide area networks [RFC8376] such
as Cellular IoT, 6TiSCH, and LoRaWAN. Compared to the DTLS 1.3 as Cellular IoT, 6TiSCH, and LoRaWAN. Compared to the DTLS 1.3
handshake [I-D.ietf-tls-dtls13] with ECDH and connection ID, the handshake [I-D.ietf-tls-dtls13] with ECDH and connection ID, the
number of bytes in EDHOC + CoAP can be less than 1/6 when RPK number of bytes in EDHOC + CoAP can be less than 1/6 when RPK
authentication is used, see authentication is used, see
[I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows two [I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows two
examples of message sizes for EDHOC with different kinds of examples of message sizes for EDHOC with different kinds of
authentication keys and different COSE header parameters for authentication keys and different COSE header parameters for
skipping to change at page 5, line 42 skipping to change at page 5, line 42
small message overhead and efficient parsing in constrained devices. small message overhead and efficient parsing in constrained devices.
EDHOC is not bound to a particular transport layer, but it is EDHOC is not bound to a particular transport layer, but it is
recommended to transport the EDHOC message in CoAP payloads. EDHOC recommended to transport the EDHOC message in CoAP payloads. EDHOC
is not bound to a particular communication security protocol but is not bound to a particular communication security protocol but
works off-the-shelf with OSCORE [RFC8613] providing the necessary works off-the-shelf with OSCORE [RFC8613] providing the necessary
input parameters with required properties. Maximum code complexity input parameters with required properties. Maximum code complexity
(ROM/Flash) is often a constraint in many devices and by reusing (ROM/Flash) is often a constraint in many devices and by reusing
already existing libraries, the additional code footprint for EDHOC + already existing libraries, the additional code footprint for EDHOC +
OSCORE can be kept very low. OSCORE can be kept very low.
1.2. Terminology and Requirements Language 1.2. Use of EDHOC
EDHOC is designed as a lightweight AKE for OSCORE, i.e. to provide
authentication and session key establishment for IoT use cases such
as those built on CoAP [RFC7252]. CoAP is a specialized web transfer
protocol for use with constrained nodes and networks, providing a
request/response interaction model between application endpoints. As
such, EDHOC is targeting a large variety of use cases involving
'things' with embedded microcontrollers, sensors and actuators.
A typical setting is when one of the endpoints is constrained or in a
constrained network, and the other endpoint is a node on the Internet
(such as a mobile phone) or at the edge of the constrained network
(such as a gateway). Thing-to-thing interactions over constrained
networks are also relevant since both endpoints would then benefit
from the lightweight properties of the protocol. EDHOC could e.g. be
run when a device/device(s) connect(s) for the first time, or to
establish fresh keys which are not compromised by a later compromise
of the long-term keys. (Further security properties are described in
Section 7.1.)
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 [RFC7049], 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 [RFC7049]. Examples
of CBOR and CDDL are provided in Appendix A.1. of CBOR and CDDL are provided in Appendix A.1.
2. Background 2. Background
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.
skipping to change at page 9, line 6 skipping to change at page 9, line 38
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. The connection identifier MAY be used with an
application protocol (e.g. OSCORE) for which EDHOC establishes keys, application protocol (e.g. OSCORE) for which EDHOC establishes keys,
in which case the connection identifiers SHALL adhere to the in which case the connection identifiers SHALL adhere to the
requirements for that protocol. Each party choses a connection requirements for that protocol. Each party choses a connection
identifier it desires the other party to use in outgoing messages. 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]).
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
skipping to change at page 9, line 31 skipping to change at page 10, line 18
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 6.1.
3.2. Authentication Keys and Identities 3.2. Authentication Keys and Identities
The EDHOC message exchange may be authenticated using raw public keys The EDHOC message exchange may be authenticated using raw public keys
(RPK) or public key certificates. The certificates and RPKs can (RPK) or public key certificates. The certificates and RPKs can
contain signature keys or static Diffie-Hellman keys. In X.509 contain signature keys or static Diffie-Hellman keys. In X.509
certificates, signature keys typically have key usage certificates, signature keys typically have key usage
"digitalSignature" and Diffie-Hellman keys typically have key usage "digitalSignature" and Diffie-Hellman keys typically have key usage
"keyAgreement". EDHOC assumes the existence of mechanisms "keyAgreement".
(certification authority, trusted third party, manual distribution,
etc.) for distributing authentication keys and identities. Policies EDHOC assumes the existence of mechanisms (certification authority,
are set based on the identity of the other party, and parties trusted third party, manual distribution, etc.) for specifying and
typically only allow connections from a small restricted set of distributing authentication keys and identities. Policies are set
identities. based on the identity of the other party, and parties typically only
allow connections from a specific identity or a small restricted set
of identities. For example, in the case of a device connecting to a
network, the network may only allow connections from devices which
authenticate with certificates having a particular range of serial
numbers in the subject field and signed by a particular CA. On the
other side, the device may only be allowed to connect to a network
which authenticate with a particular public key (information of which
may be provisioned, e.g., out of band or in the Auxiliary Data, see
Section 3.6).
The EDHOC implementation must be able to receive and enforce
information from the application about what is the intended peer
endpoint, and in particular whether it is a specific identity or a
set of identities.
o When a Public Key Infrastructure (PKI) is used, the trust anchor o When a Public Key Infrastructure (PKI) is used, the trust anchor
is a Certification Authority (CA) certificate, and the identity is is a Certification Authority (CA) certificate, and the identity is
the subject whose unique name (e.g. a domain name, NAI, or EUI) is the subject whose unique name (e.g. a domain name, NAI, or EUI) is
included in the other party's certificate. Before running EDHOC included in the endpoint's certificate. Before running EDHOC each
each party needs at least one CA public key certificate, or just party needs at least one CA public key certificate, or just the
the public key, and a set of identities it is allowed to public key, and a specific identity or set of identities it is
communicate with. Any validated public-key certificate with an allowed to communicate with. Only validated public-key
allowed subject name is accepted. EDHOC provides proof that the certificates with an allowed subject name, as specified by the
application, are to be accepted. 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 in its certificate. The to the public authentication key in its certificate. The
certification path provides proof that the subject of the certification path provides proof that the subject of the
certificate owns the public key in the certificate. certificate owns the public key in the certificate.
o When public keys are used but not with a PKI (RPK, self-signed o When public keys are used but not with a PKI (RPK, self-signed
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 Figure 2. Before
running EDHOC, each party need a set of public authentication running EDHOC, each endpoint needs a specific public
keys/unique associated subject names it is allowed to communicate authentication key/unique associated subject name, or a set of
with. EDHOC provides proof that the other party possesses the public authentication keys/unique associated subject names, which
private authentication key corresponding to the public it is allowed to communicate with. EDHOC provides proof that the
authentication key. other party possesses the private authentication key corresponding
to the public authentication key.
3.3. Identifiers 3.3. Identifiers
One byte connection and credential identifiers are realistic in many One byte connection and credential identifiers are realistic in many
scenarios as most constrained devices only have a few keys and scenarios as most constrained devices only have a few keys and
connections. In cases where a node only has one connection or key, connections. In cases where a node only has one connection or key,
the identifiers may even be the empty byte string. the identifiers may even be the empty byte string.
3.4. Cipher Suites 3.4. Cipher Suites
skipping to change at page 11, line 50 skipping to change at page 12, line 50
Section 3.1). This is typically given by the transport which the Section 3.1). This is typically given by the transport which the
Initiator and the Responder have agreed on beforehand. The Initiator and the Responder have agreed on beforehand. The
Responder either accepts or rejects. Responder either accepts or rejects.
o The Initiator decides on the method parameter, see Section 8.2. o The Initiator decides on the method parameter, see Section 8.2.
The Responder either accepts or rejects. The Responder either accepts or rejects.
o The Initiator and the Responder decide on the representation of o The Initiator and the Responder decide on the representation of
the identifier of their respective credentials, ID_CRED_I and the identifier of their respective credentials, ID_CRED_I and
ID_CRED_R. The decision is reflected by the label used in the ID_CRED_R. The decision is reflected by the label used in the
CBOR map, see for example Section 4.1. CBOR map, see for example Section 4.2.
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.
EDHOC allows opaque auxiliary data (AD) to be sent in the EDHOC EDHOC allows opaque auxiliary data (AD) to be sent in the EDHOC
messages. Unprotected Auxiliary Data (AD_1, AD_2) may be sent in messages. Unprotected Auxiliary Data (AD_1, AD_2) may be sent in
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 AD1 and AD2 may not be protected, and the Since data carried in AD_1 and AD_2 may not be protected, and the
content of AD3 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. Ephemeral Public Keys
The ECDH ephemeral public keys are formatted as a COSE_Key of type The ECDH ephemeral public keys are formatted as a COSE_Key of type
EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only
the 'x' parameter is included in the EDHOC messages. For Elliptic the 'x' parameter is included in the EDHOC messages. For Elliptic
skipping to change at page 14, line 20 skipping to change at page 15, line 20
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.3.1, 4.4.1, and TH_2, TH_3, or TH_4 as defined in Sections 4.5.1, 4.6.1, and
3.8.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", "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 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 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 transcript hash TH_3 and the pseudorandom key PRK_3e2m. K_3m and
skipping to change at page 15, line 26 skipping to change at page 16, line 26
o Only the Initiator SHALL have access to the Initiator's private o Only the Initiator SHALL have access to the Initiator's private
authentication key, authentication key,
o The Initiator is able to retrieve the Responder's public o The Initiator is able to retrieve the Responder's public
authentication key using ID_CRED_R, authentication key using ID_CRED_R,
o The Responder is able to retrieve the Initiator's public o The Responder is able to retrieve the Initiator's public
authentication key using ID_CRED_I, authentication key using ID_CRED_I,
where the identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, where ID_CRED_I and ID_CRED_R are the identifiers of the public
i.e. CBOR maps containing COSE Common Header Parameters, see authentication keys. Their encoding is specified in Section 4.2.
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 Initiator Responder
following paragraph we give some examples of possible COSE header | METHOD_CORR, SUITES_I, G_X, C_I, AD_1 |
parameters used. +------------------------------------------------------------------>|
| 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 Raw public keys are most optimally stored as COSE_Key objects and
identified with a 'kid' parameter: identified with a 'kid' parameter:
o ID_CRED_x = { 4 : kid_x }, where kid_x : bstr, for x = I or R. o ID_CRED_x = { 4 : kid_x }, where kid_x : bstr, for x = I or R.
Public key certificates can be identified in different ways. Header Public key certificates can be identified in different ways. Header
parameters for identifying X.509 certificates are defined in parameters for identifying X.509 certificates are defined in
[I-D.ietf-cose-x509], for example: [I-D.ietf-cose-x509], for example:
skipping to change at page 16, line 7 skipping to change at page 17, line 28
o by a URL with the 'x5u' parameter; o by a URL with the 'x5u' parameter;
* ID_CRED_x = { 35 : uri }, for x = I or R, * ID_CRED_x = { 35 : uri }, for x = I or R,
The purpose of ID_CRED_I and ID_CRED_R is to facilitate retrieval of The purpose of ID_CRED_I and ID_CRED_R is to facilitate retrieval of
a public authentication key and when they do not contain the actual a public authentication key and when they do not contain the actual
credential, they may be very short. ID_CRED_I and ID_CRED_R MAY credential, they may be very short. ID_CRED_I and ID_CRED_R MAY
contain the actual credential used for authentication. It is contain the actual credential used for authentication. It is
RECOMMENDED that they uniquely identify the public authentication key RECOMMENDED that they uniquely identify the public authentication key
as the recipient may otherwise have to try several keys. ID_CRED_I 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.3.2 and ID_CRED_R are transported in the ciphertext, see Section 4.5.2
and Section 4.4.2. and Section 4.6.2.
The authentication key MUST be a signature key or static Diffie- The authentication key MUST be a signature key or static Diffie-
Hellman key. The Initiator and the Responder MAY use different types Hellman key. The Initiator and the Responder MAY use different types
of authentication keys, e.g. one uses a signature key and the other of authentication keys, e.g. one uses a signature key and the other
uses a static Diffie-Hellman key. When using a signature key, the uses a static Diffie-Hellman key. When using a signature key, the
authentication is provided by a signature. When using a static authentication is provided by a signature. When using a static
Diffie-Hellman key the authentication is provided by a Message Diffie-Hellman key the authentication is provided by a Message
Authentication Code (MAC) computed from an ephemeral-static ECDH Authentication Code (MAC) computed from an ephemeral-static ECDH
shared secret which enables significant reductions in message sizes. shared secret which enables significant reductions in message sizes.
The MAC is implemented with an AEAD algorithm. When using a static The MAC is implemented with an AEAD algorithm. When using a static
Diffie-Hellman keys the Initiator's and Responder's private 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 I and R, respectively, and the public
authentication keys are called G_I and G_R, respectively. 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 The actual credentials CRED_I and CRED_R are signed or MAC:ed by the
Initiator and the Responder respectively, see Section 4.4.1 and Initiator and the Responder respectively, see Section 4.6.1 and
Section 4.3.1. The Initiator and the Responder MAY use different Section 4.5.1. The Initiator and the Responder MAY use different
types of credentials, e.g. one uses RPK and the other uses types of credentials, e.g. one uses RPK and the other uses
certificate. When the credential is a certificate, CRED_x is end- certificate. When the credential is a certificate, CRED_x is end-
entity certificate (i.e. not the certificate chain) encoded as a CBOR 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 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 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), 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 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 only include the parameters 1 (kty), -1 (crv), -2 (x-coordinate), and
-3 (y-coordinate). If the parties have agreed on an identity besides -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 the public key, the indentity is included in the CBOR map with the
skipping to change at page 17, line 4 skipping to change at page 18, line 21
the RPK contains an X25519 static Diffie-Hellman key and the parties the RPK contains an X25519 static Diffie-Hellman key and the parties
have agreed on an EUI-64 identity is shown below: have agreed on an EUI-64 identity is shown below:
CRED_x = { CRED_x = {
1: 1, 1: 1,
-1: 4, -1: 4,
-2: h'b1a3e89460e88d3a8d54211dc95f0b90 -2: h'b1a3e89460e88d3a8d54211dc95f0b90
3ff205eb71912d6db8f4af980d2db83a', 3ff205eb71912d6db8f4af980d2db83a',
"subject name" : "42-50-31-FF-EF-37-32-39" "subject name" : "42-50-31-FF-EF-37-32-39"
} }
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.3. Encoding of bstr_identifier
4.2. EDHOC Message 1 A bstr_identifier is a special encoding for byte strings, used
throughout the protocol.
4.2.1. Formatting of Message 1 Byte strings of length greater than one are encoded as CBOR byte
strings. Byte strings of length one are encoded as the corresponding
integer - 24.
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
integer 18.
The CDDL definition of the bstr_identifier is given below:
bstr_identifier = bstr / int
Note that, despite what could be interpreted by the CDDL definition
only, bstr_identifier once decoded are always byte strings.
4.4. EDHOC Message 1
4.4.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
bstr_identifier = bstr / 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 Section 8.2) 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.1).
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. If a
single supported cipher suite is conveyed then that cipher suite 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. An bstr_identifier o C_I - variable length connection identifier, encoded as a
is a byte string with special encoding. Byte strings of length bstr_identifier (see Section 4.3).
one is encoded as the corresponding integer - 24, i.e. h'2a' is
encoded as 18.
o AD_1 - bstr containing unprotected opaque auxiliary data o AD_1 - bstr containing unprotected opaque auxiliary data
4.2.2. Initiator Processing of Message 1 4.4.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 18, line 43 skipping to change at page 20, line 17
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.2.1 specified in Section 4.4.1
4.2.3. Responder Processing of Message 1 4.4.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 suites in SUITES_I are 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 Initiator MUST send an EDHOC
error message back, formatted as defined in Section 5, and the error message back, formatted as defined in Section 5, and the
protocol MUST be discontinued. If V does not support the selected protocol MUST be discontinued. If the Responder does not support the
cipher suite, then SUITES_R MUST include one or more supported cipher selected cipher suite, then SUITES_R MUST include one or more
suites. If the Responder does not support the selected cipher suite, supported cipher suites. If the Responder does not support the
but supports another cipher suite in SUITES_I, then SUITES_R MUST selected cipher suite, but supports another cipher suite in SUITES_I,
include the first supported cipher suite in SUITES_I. then SUITES_R MUST include the first supported cipher suite in
SUITES_I.
4.3. EDHOC Message 2 4.5. EDHOC Message 2
4.3.1. Formatting of Message 2 4.5.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 19, line 37 skipping to change at page 21, line 14
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
o C_R - variable length connection identifier o C_R - variable length connection identifier, encoded as a
bstr_identifier (see Section 4.3).
4.3.2. Responder Processing of Message 2 4.5.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 20, line 17 skipping to change at page 21, line 44
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.1 see Section 4.2
* 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.1. see Section 4.2.
+ 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 )
skipping to change at page 21, line 23 skipping to change at page 23, line 4
MAC_2 ] MAC_2 ]
o CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a o CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a
plaintext with the following common parameters: plaintext with the following common parameters:
* 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 an bstr_identifier, is conveyed in the plaintext encoded as a bstr_identifier,
see Section 4.1. see Section 4.2 and Section 4.3.
* CIPHERTEXT_2 = plaintext XOR K_2e * CIPHERTEXT_2 = plaintext XOR K_2e
* K_2e = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length ), where length * K_2e = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length ), where length
is the length of the plaintext. is the length of the plaintext.
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.3.1. specified in Section 4.5.1.
4.3.3. Initiator Processing of Message 2 4.5.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. The decryption process depends on the
method, see Section 4.3.2. method, see Section 4.5.2.
o Verify that the identity of the Responder is among the allowed o Verify that the identity of the Responder is an allowed identity
identities for this connection. for this connection, see Section 3.2.
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.3.2. Section 4.5.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 5, and the
protocol MUST be discontinued. protocol MUST be discontinued.
4.4. EDHOC Message 3 4.6. EDHOC Message 3
4.4.1. Formatting of Message 3 4.6.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.4.2. Initiator Processing of Message 3 4.6.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.1 see Section 4.2
* 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.1. see Section 4.2.
+ 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 24, line 12 skipping to change at page 25, line 40
suite, K_3ae, IV_3ae, and the following parameters. The protected suite, K_3ae, IV_3ae, and the following parameters. The protected
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 an bstr_identifier, is conveyed in the plaintext encoded as a bstr_identifier,
see Section 4.1. see Section 4.2 and Section 4.3.
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 24, line 25 skipping to change at page 26, line 4
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.4.1. specified in Section 4.6.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.
4.4.3. Responder Processing of Message 3 After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (implicit key
authentication). The Initiator does however not know that the
Responder has actually computed the key PRK_4x3m. While the
Initiator can securely send protected application data, the Initiator
SHOULD NOT store the keying material PRK_4x3m and TH_4 until the
Initiator is assured that the Responder has actually computed the key
PRK_4x3m (explicit key confirmation). Explicit key confirmation is
e.g. assured when the Initiator has verified an OSCORE message from
the Responder.
4.6.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 among the allowed o Verify that the identity of the Initiator is an allowed identity
identities for this connection. for this connection, see Section 3.2.
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.4.2. Section 4.6.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 5, and the
protocol MUST be discontinued. protocol MUST be discontinued.
After verifying message_3, the Responder is assured that the
Initiator has calculated the key PRK_4x3m (explicit key confirmation)
and that no other party than the Responder can compute the key. The
Responder can securely send protected application data and store the
keying material PRK_4x3m and TH_4.
5. Error Handling 5. Error Handling
5.1. EDHOC Error Message 5.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
skipping to change at page 25, line 41 skipping to change at page 27, line 38
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 - if error is sent by the Responder and corr (METHOD_CORR mod o C_x - variable length connection identifier, encoded as a
4) equals 0 or 2 then C_x is set to C_I, else if error is sent by bstr_identifier (see Section 4.3). If error is sent by the
the Initiator and corr (METHOD_CORR mod 4) equals 0 or 1 then C_x Responder and corr (METHOD_CORR mod 4) equals 0 or 2 then C_x is
is set to C_R, else C_x is omitted. 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
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.
o SUITES_R - cipher suites from SUITES_I or the EDHOC cipher suites o SUITES_R - cipher suites from SUITES_I or the EDHOC cipher suites
registry that the Responder supports. SUITES_R MUST only be registry that the Responder supports. SUITES_R MUST only be
included in replies to message_1. If a single supported cipher included in replies to message_1. If a single supported cipher
suite is conveyed then the supported cipher suite is encoded as an suite is conveyed then the supported cipher suite is encoded as an
int instead of an array. int instead of an array.
After receiving SUITES_R, the Initiator can determine which selected
cipher suite to use for the next EDHOC run with the Responder. If
the Initiator intends to contact the Responder in the future, the
Initiator SHOULD remember which selected cipher suite to use until
the next message_1 has been sent, otherwise the Initiator and
Responder will likely run into an infinite loop. After a successful
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
updated with new cipher suite policies, any cached information may be
outdated.
5.1.1. Example Use of EDHOC Error Message with SUITES_R 5.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 Responder 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. In Figure 5, the
Responder supports cipher suite 6 but not the selected cipher suite Responder supports cipher suite 6 but not the selected cipher suite
5. 5.
skipping to change at page 31, line 13 skipping to change at page 33, line 13
Compromising the private authentication keys of one party lets an Compromising the private authentication keys of one party lets an
active attacker impersonate that compromised party in EDHOC exchanges active attacker impersonate that compromised party in EDHOC exchanges
with other parties, but does not let the attacker impersonate other with other parties, but does not let the attacker impersonate other
parties in EDHOC exchanges with the compromised party. Compromise of parties in EDHOC exchanges with the compromised party. Compromise of
the long-term keys does not enable a passive attacker to compromise the long-term keys does not enable a passive attacker to compromise
future session keys. Compromise of the HDKF input parameters (ECDH future session keys. Compromise of the HDKF input parameters (ECDH
shared secret) leads to compromise of all session keys derived from shared secret) leads to compromise of all session keys derived from
that compromised shared secret. Compromise of one session key does that compromised shared secret. Compromise of one session key does
not compromise other session keys. not compromise other session keys.
If supported by the device, it is RECOMMENDED that at least the long-
term private keys is stored in a Trusted Execution Environment (TEE)
and that sensitive operations using these keys are performed inside
the TEE. To achieve even higher security additional operation such
as ephemeral key generation, all computations of shared secrets, and
storage of the PRK keys can be done inside the TEE. Optimally, the
whole EDHOC protocol can be implemented inside the TEE. Typically an
adversary with physical access to a device can be assumed to gain
access to all information outside of the TEE, but none of the
information inside the TEE.
Key compromise impersonation (KCI): In EDHOC authenticated with Key compromise impersonation (KCI): In EDHOC authenticated with
signature keys, EDHOC provides KCI protection against an attacker signature keys, EDHOC provides KCI protection against an attacker
having access to the long term key or the ephemeral secret key. With having access to the long term key or the ephemeral secret key. With
static Diffie-Hellman key authentication, KCI protection would be static Diffie-Hellman key authentication, KCI protection would be
provided against an attacker having access to the long-term Diffie- provided against an attacker having access to the long-term Diffie-
Hellman key, but not to an attacker having access to the ephemeral Hellman key, but not to an attacker having access to the ephemeral
secret key. Note that the term KCI has typically been used for secret key. Note that the term KCI has typically been used for
compromise of long-term keys, and that an attacker with access to the compromise of long-term keys, and that an attacker with access to the
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, Party U Repudiation: In EDHOC authenticated with signature keys, the
could theoretically prove that Party V performed a run of the Initiator could theoretically prove that the Responder performed a
protocol by presenting the private ephemeral key, and vice versa. run of the protocol by presenting the private ephemeral key, and vice
Note that storing the private ephemeral keys violates the protocol versa. Note that storing the private ephemeral keys violates the
requirements. With static Diffie-Hellman key authentication, both protocol requirements. With static Diffie-Hellman key
parties can always deny having participated in the protocol. authentication, both parties can always deny having participated in
the protocol.
7.2. Cryptographic Considerations 7.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.
skipping to change at page 38, line 13 skipping to change at page 40, line 13
9.1. Normative References 9.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-10 (work in progress), July 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-06 (work in progress), certificates", draft-ietf-cose-x509-07 (work in progress),
March 2020. September 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 39, line 46 skipping to change at page 41, line 46
[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 9.2. Informative References
[CborMe] Bormann, C., "CBOR Playground", May 2018, [CborMe] Bormann, C., "CBOR Playground", May 2018,
<http://cbor.me/>. <http://cbor.me/>.
[I-D.hartke-core-e2e-security-reqs]
Selander, G., Palombini, F., and K. Hartke, "Requirements
for CoAP End-To-End Security", draft-hartke-core-e2e-
security-reqs-03 (work in progress), July 2017.
[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-35
(work in progress), June 2020. (work in progress), June 2020.
[I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-11 (work in progress), June 2020.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Stok, "CoRE Resource Directory", draft-ietf-core-resource-
resource-directory-25 (work in progress), July 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-04 (work in progress), March 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-38 (work in progress), May
2020. 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
skipping to change at page 46, line 30 skipping to change at page 48, line 17
Since neither the Initiator nor the Responder authenticates with a Since neither the Initiator nor the Responder authenticates with a
static Diffie-Hellman key, PRK_3e2m = PRK_2e static Diffie-Hellman key, PRK_3e2m = PRK_2e
PRK_3e2m (32 bytes) PRK_3e2m (32 bytes)
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 bytes) Connection identifier chosen by Responder (1 byte)
2b
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
Section 4.3). Thus 0x2b = 43, 43 - 24 = 19, and 19 in CBOR encoding
is equal to 0x13.
C_R (1 byte)
13 13
Data_2 is constructed, as the CBOR Sequence of G_Y and C_R. Data_2 is constructed, as the CBOR Sequence of G_Y and C_R.
data_2 = data_2 =
( (
h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e', h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e',
h'13' h'13'
) )
skipping to change at page 47, line 16 skipping to change at page 49, line 14
TH_2 (32 bytes) TH_2 (32 bytes)
b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 b9 ca fb 60 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 b9 ca fb 60
9d e4 f6 a1 76 0d 6c f7 9d e4 f6 a1 76 0d 6c f7
The Responder's subject name is the empty string: The Responder's subject name is the empty string:
Responders's subject name (text string) Responders's subject name (text string)
"" ""
And because 'x5t' has value certificate are used, ID_CRED_R is the CRED_R is the certificate (X509_R) encoded as a CBOR byte string:
following:
ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, and since the X509_R (110 bytes)
SHA-2 256-bit Hash truncated to 64-bits is used (value -15): 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9
03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50
db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 18 0b
5a 6a f3 1e 80 20 9a 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 0f fb
8e 3f 9a 32 a5 08 59 ec d0 bf cf f2 c2 18
CRED_R (112 bytes)
58 6e 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e
4b f9 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e
5c 50 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6
18 0b 5a 6a f3 1e 80 20 9a 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d
0f fb 8e 3f 9a 32 a5 08 59 ec d0 bf cf f2 c2 18
And because certificates are identified by a hash value with the
'x5t' parameter, ID_CRED_R is the following:
ID_CRED_R = { 34 : COSE_CertHash }. In this example, the hash
algorithm used is SHA-2 256-bit with hash truncated to 64-bits (value
-15). The hash value is calculated over the certificate X509_R.
ID_CRED_R = ID_CRED_R =
{ {
34: [-15, h'FC79990F2431A3F5'] 34: [-15, h'FC79990F2431A3F5']
} }
ID_CRED_R (14 bytes) ID_CRED_R (14 bytes)
a1 18 22 82 2e 48 fc 79 99 0f 24 31 a3 f5 a1 18 22 82 2e 48 fc 79 99 0f 24 31 a3 f5
CRED_R is the certificate encoded as a byte string:
CRED_R (112 bytes)
58 6e 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e
4b f9 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e
5c 50 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6
18 0b 5a 6a f3 1e 80 20 9a 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d
0f fb 8e 3f 9a 32 a5 08 59 ec d0 bf cf f2 c2 18
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_2 (0 bytes) AD_2 (0 bytes)
The Plaintext is defined as the empty string: The Plaintext is defined as the empty string:
P_2m (0 bytes) P_2m (0 bytes)
The Enc_structure is defined as follows: [ "Encrypt0", The Enc_structure is defined as follows: [ "Encrypt0",
<< ID_CRED_R >>, << TH_2, CRED_R >> ] << ID_CRED_R >>, << TH_2, CRED_R >> ]
A_2m = A_2m =
[ [
"Encrypt0", "Encrypt0",
h'A11822822E48FC79990F2431A3F5', h'A11822822E48FC79990F2431A3F5',
h'5820B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF h'5820B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF
7586E47624DC9CDC6824B2A4C52E95EC9D6B0534B71C2B49E4BF9031500CEE6869979 7586E47624DC9CDC6824B2A4C52E95EC9D6B0534B71C2B49E4BF9031500CEE6869979
C297BB5A8B381E98DB714108415E5C50DB78974C271579B01633A3EF6271BE5C225EB C297BB5A8B381E98DB714108415E5C50DB78974C271579B01633A3EF6271BE5C225EB
skipping to change at page 49, line 5 skipping to change at page 51, line 10
From these parameters, K_2m is computed. Key K_2m is the output of From these parameters, K_2m is computed. Key K_2m is the output of
HKDF-Expand(PRK_3e2m, info, L), where L is the length of K_2m, so 16 HKDF-Expand(PRK_3e2m, info, L), where L is the length of K_2m, so 16
bytes. bytes.
K_2m (16 bytes) K_2m (16 bytes)
b7 48 6a 94 a3 6c f6 9e 67 3f c4 57 55 ee 6b 95 b7 48 6a 94 a3 6c f6 9e 67 3f c4 57 55 ee 6b 95
info for IV_2m is defined as follows: info for IV_2m is defined as follows:
info for K_2m = info for IV_2m =
[ [
10, 10,
h'B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF7', h'B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF7',
"IV_2m", "IV_2m",
13 13
] ]
Which as a CBOR encoded data item is: Which as a CBOR encoded data item is:
info for IV_2m (CBOR-encoded) (43 bytes) info for IV_2m (CBOR-encoded) (43 bytes)
skipping to change at page 52, line 40 skipping to change at page 55, line 8
TH_3 (32 bytes) TH_3 (32 bytes)
a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd
b3 2e 4a 27 ce 93 58 da b3 2e 4a 27 ce 93 58 da
The initiator's subject name is the empty string: The initiator's subject name is the empty string:
Initiator's subject name (text string) Initiator's subject name (text string)
"" ""
And its credential is a certificate identified by its 'x5t' hash: CRED_I is the certificate (X509_I) encoded as a CBOR byte string:
ID_CRED_R =
{
34: [-15, h'FC79990F2431A3F5']
}
ID_CRED_I (14 bytes)
a1 18 22 82 2e 48 5b 78 69 88 43 9e bc f2
CRED_I is the certificate encoded as a byte string: X509_I (101 bytes)
fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79
5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60
1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37
00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87
ec 3f f2 45 b7
CRED_I (103 bytes) CRED_I (103 bytes)
58 65 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f 58 65 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f
fc 79 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 fc 79 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01
95 60 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 95 60 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7
88 37 00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 88 37 00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44
2b 87 ec 3f f2 45 b7 2b 87 ec 3f f2 45 b7
Since no opaque auciliary data is exchanged: And because certificates are identified by a hash value with the
'x5t' parameter, ID_CRED_I is the following:
ID_CRED_I = { 34 : COSE_CertHash }. In this example, the hash
algorithm used is SHA-2 256-bit with hash truncated to 64-bits (value
-15). The hash value is calculated over the certificate X509_I.
ID_CRED_I =
{
34: [-15, h'FC79990F2431A3F5']
}
ID_CRED_I (14 bytes)
a1 18 22 82 2e 48 5b 78 69 88 43 9e bc f2
Since no opaque auxiliary data is exchanged:
AD_3 (0 bytes) AD_3 (0 bytes)
The Plaintext of the COSE_Encrypt is the empty string: The Plaintext of the COSE_Encrypt is the empty string:
P_3m (0 bytes) P_3m (0 bytes)
The external_aad is the CBOR Sequence od CRED_I and TH_3, in this The external_aad is the CBOR Sequence od CRED_I and TH_3, in this
order: order:
skipping to change at page 57, line 34 skipping to change at page 60, line 11
) )
Which encodes to the following byte string: Which encodes to the following byte string:
message_3 (CBOR Sequence) (91 bytes) message_3 (CBOR Sequence) (91 bytes)
13 58 58 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db 13 58 58 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db
a4 78 05 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e a4 78 05 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e
af 56 e4 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 af 56 e4 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0
e4 62 f5 f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a e4 62 f5 f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a
B.2. Test Vectors for EDHOC Authenticated with Static Diffie-Hellman
Keys
EDHOC with static Diffie-Hellman keys is used.
method (Static DH Based Authentication)
3
CoAP is used as transport and the Initiator acts as CoAP client:
corr (the Initiator can correlate message_1 and message_2)
1
From there, METHOD_CORR has the following value:
METHOD_CORR (4 * method + corr) (int)
13
No unprotected opaque auxiliary data is sent in the message
exchanges.
The list of supported cipher suites of the Initiator in order of
preference is the following:
Supported Cipher Suites (4 bytes)
00 01 02 03
The cipher suite selected by the Initiator is the most preferred:
Selected Cipher Suite (int)
0
The mandatory-to-implement cipher suite 0 is supported by both the
Initiator and the Responder, see Section 7.3.
B.2.1. Message_1
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
1f f2 45 72 f4 f5 7c fa
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
ee 9e 2b 57 e2 44 1a 7c
The Initiator chooses a connection identifier C_I:
Connection identifier chosen by Initiator (1 bytes)
16
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),
i.e. 0x16 = 22, 22 - 24 = -2, and -2 in CBOR encoding is equal to
0x21.
C_I (1 byte)
21
Since no unprotected opaque auxiliary data is sent in the message
exchanges:
AD_1 (0 bytes)
Since the list of supported cipher suites needs to contain the
selected cipher suite, the initiator truncates the list of supported
cipher suites to one cipher suite only, 00.
Because one single selected cipher suite is conveyed, it is encoded
as an int instead of an array:
SUITES_I (int)
0
With SUITES_I = 0, message_1 is constructed, as the CBOR Sequence of
the CBOR data items above.
message_1 =
(
13,
0,
h'8D3EF56D1B750A4351D68AC250A0E883790EFC80A538A444EE9E2B57E2441A7C',
-2
)
message_1 (CBOR Sequence) (37 bytes)
0d 00 58 20 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 21
B.2.2. Message_2
Since METHOD_CORR mod 4 equals 1, C_I is omitted from data_2.
Y (Responder's ephemeral private key) (32 bytes)
c6 46 cd dc 58 12 6e 18 10 5f 01 ce 35 05 6e 5e bc 35 f4 d4 cc 51 07 49
a3 a5 e0 69 c1 16 16 9a
G_Y (Responder's ephemeral public key) (32 bytes)
52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33
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:
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
66 c2 d8 85 f4 f8 ac 4e
The key and nonce for calculating the ciphertext are calculated as
follows, as specified in Section 3.8.
HKDF SHA-256 is the HKDF used (as defined by cipher suite 0).
PRK_2e = HMAC-SHA-256(salt, G_XY)
Salt is the empty byte string.
salt (0 bytes)
From there, PRK_2e is computed:
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
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,
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.
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
1f ca d6 6a 07 94 22 d0
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
b8 46 59 18 4d 5d 9a 32
From the Responder's authentication key and the Initiator's ephemeral
key (see Appendix B.2.1), the ECDH shared secret G_RX is calculated.
G_RX (ECDH shared secret) (32 bytes)
21 c7 ef f4 fb 69 fa 4b 67 97 d0 58 84 31 5d 84 11 a3 fd a5 4f 6d ad a6
1d 4f cd 85 e7 90 66 68
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
43 8c 93 b1 0b 39 93 07
The Responder chooses a connection identifier C_R.
Connection identifier chosen by Responder (1 byte)
20
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),
i.e. 0x20 = 32, 32 - 24 = 8, and 8 in CBOR encoding is equal to 0x08.
C_R (1 byte)
08
Data_2 is constructed, as the CBOR Sequence of G_Y and C_R.
data_2 =
(
h'52FBA0BDC8D953DD86CE1AB2FD7C05A4658C7C30AFDBFC3301047069451BAF35',
08
)
data_2 (CBOR Sequence) (35 bytes)
58 20 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 08
From data_2 and message_1, compute the input to the transcript hash
TH_2 = H( message_1, data_2 ), as a CBOR Sequence of these 2 data
items.
Input to calculate TH_2 (CBOR Sequence) (72 bytes)
0d 00 58 20 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 21 58 20 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 08
And from there, compute the transcript hash TH_2 = SHA-256(
message_1, data_2 )
TH_2 (32 bytes)
6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 0c af 9c 49
1a 52 e6 83 6a 25 64 ff
The Responder's subject name is the empty string:
Responders's subject name (text string)
""
ID_CRED_R is the following:
ID_CRED_R =
{
4: h'07'
}
ID_CRED_R (4 bytes)
a1 04 41 07
CRED_R is the following COSE_Key:
{
1: 1,
-1: 4,
-2: h'A3FF263595BEB377D1A0CE1D04DAD2D40966AC6BCB622051B84659184D5D9A32',
"subject name": ""
}
Which encodes to the following byte string:
CRED_R (54 bytes)
a4 01 01 20 04 21 58 20 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 6c 73 75 62 6a 65 63 74
20 6e 61 6d 65 60
Since no unprotected opaque auxiliary data is sent in the message
exchanges:
AD_2 (0 bytes)
The Plaintext is defined as the empty string:
P_2m (0 bytes)
The Enc_structure is defined as follows: [ "Encrypt0",
<< ID_CRED_R >>, << TH_2, CRED_R >> ]
A_2m =
[
"Encrypt0",
h'A1044107',
h'58206A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FFA401012004215820A3FF263595BEB377D1A0CE1D04DAD2D40966AC6BCB622051B84659184D5D9A326C7375626A656374206E616D6560'
]
Which encodes to the following byte string to be used as Additional
Authenticated Data:
A_2m (CBOR-encoded) (105 bytes)
83 68 45 6e 63 72 79 70 74 30 44 a1 04 41 07 58 58 58 20 6a 28 78 e8 4b
2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 0c af 9c 49 1a 52 e6 83 6a
25 64 ff a4 01 01 20 04 21 58 20 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 6c 73 75 62 6a
65 63 74 20 6e 61 6d 65 60
info for K_2m is defined as follows:
info for K_2m =
[
10,
h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF',
"K_2m",
16
]
Which as a CBOR encoded data item is:
info for K_2m (CBOR-encoded) (42 bytes)
84 0a 58 20 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30
0c af 9c 49 1a 52 e6 83 6a 25 64 ff 64 4b 5f 32 6d 10
From these parameters, K_2m is computed. Key K_2m is the output of
HKDF-Expand(PRK_3e2m, info, L), where L is the length of K_2m, so 16
bytes.
K_2m (16 bytes)
81 2a 48 87 d1 90 ff ed 2b 10 0b a7 a5 c2 5e 67
info for IV_2m is defined as follows:
info for IV_2m =
[
10,
h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF',
"IV_2m",
13
]
Which as a CBOR encoded data item is:
info for IV_2m (CBOR-encoded) (43 bytes)
84 0a 58 20 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30
0c af 9c 49 1a 52 e6 83 6a 25 64 ff 65 49 56 5f 32 6d 0d
From these parameters, IV_2m is computed. IV_2m is the output of
HKDF-Expand(PRK_3e2m, info, L), where L is the length of IV_2m, so 13
bytes.
IV_2m (13 bytes)
92 3c 0f 94 31 51 5b 69 21 30 49 2b 7f
Finally, COSE_Encrypt0 is computed from the parameters above.
o protected header = CBOR-encoded ID_CRED_R
o external_aad = A_2m
o empty plaintext = P_2m
MAC_2 (8 bytes)
64 21 0d 2e 18 b9 28 cd
From there Signature_or_MAC_2 is the MAC (since method = 3):
Signature_or_MAC_2 (8 bytes)
64 21 0d 2e 18 b9 28 cd
CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a
plaintext constructed from the following parameters and the key K_2e.
o plaintext = CBOR Sequence of the items ID_CRED_R and the CBOR
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
: kid_R }, only the byte string kid_R is conveyed in the plaintext
encoded as a bstr_identifier. kid_R is encoded as the
corresponding integer - 24 (see bstr_identifier in Section 4.3),
i.e. 0x07 = 7, 7 - 24 = -17, and -17 in CBOR encoding is equal to
0x30.
The plaintext is the following:
P_2e (CBOR Sequence) (10 bytes)
30 48 64 21 0d 2e 18 b9 28 cd
K_2e = HKDF-Expand( PRK, info, length ), where length is the length
of the plaintext, so 80.
info for K_2e =
[
10,
h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF',
"K_2e",
10
]
Which as a CBOR encoded data item is:
info for K_2e (CBOR-encoded) (42 bytes)
84 0a 58 20 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30
0c af 9c 49 1a 52 e6 83 6a 25 64 ff 64 4b 5f 32 65 0a
From there, K_2e is computed:
K_2e (10 bytes)
ec be 9a bd 5f 62 3a fc 65 26
Using the parameters above, the ciphertext CIPHERTEXT_2 can be
computed:
CIPHERTEXT_2 (10 bytes)
dc f6 fe 9c 52 4c 22 45 4d eb
message_2 is the CBOR Sequence of data_2 and CIPHERTEXT_2, in this
order:
message_2 =
(
data_2,
h'DCF6FE9C524C22454DEB'
)
Which as a CBOR encoded data item is:
message_2 (CBOR Sequence) (46 bytes)
58 20 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 08 4a dc f6 fe 9c 52 4c 22 45 4d eb
B.2.3. Message_3
Since corr equals 1, C_R is not omitted from data_3.
SK_I (Initiator's private authentication key) (32 bytes)
2b be a6 55 c2 33 71 c3 29 cf bd 3b 1f 02 c6 c0 62 03 38 37 b8 b5 90 99
a4 43 6f 66 60 81 b0 8e
G_I (Initiator's public authentication key) (32 bytes)
2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae da fe 9c aa 4f 4e 7a bb 83 5e c3
0f 1d e8 8a db 96 ff 71
HKDF SHA-256 is the HKDF used (as defined by cipher suite 0).
From the Initiator's authentication key and the Responder's ephemeral
key (see Appendix B.2.2), the ECDH shared secret G_IY is calculated.
G_IY (ECDH shared secret) (32 bytes)
cb ff 8c d3 4a 81 df ec 4c b6 5d 9a 57 2e bd 09 64 45 0c 78 56 3d a4 98
1d 80 d3 6c 8b 1a 75 2a
PRK_4x3m = HMAC-SHA-256 (PRK_3e2m, G_IY).
PRK_4x3m (32 bytes)
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
data 3 is equal to C_R.
data_3 (CBOR Sequence) (1 bytes)
08
From data_3, CIPHERTEXT_2, and TH_2, compute the input to the
transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3), as a CBOR
Sequence of these 3 data items.
Input to calculate TH_3 (CBOR Sequence) (46 bytes)
58 20 6a 28 78 e8 4b 2c c0 21 cc 1a eb a2 96 52 53 ef 42 f7 fa 30 0c af
9c 49 1a 52 e6 83 6a 25 64 ff 4a dc f6 fe 9c 52 4c 22 45 4d eb 08
And from there, compute the transcript hash TH_3 = SHA-256(TH_2 ,
CIPHERTEXT_2, data_3)
TH_3 (32 bytes)
51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc e4 80 16 07
03 ee d9 c4 a1 bc b6 11
The initiator's subject name is the empty string:
Initiator's subject name (text string)
""
And its credential is:
ID_CRED_I =
{
4: h'24'
}
ID_CRED_I (4 bytes)
a1 04 41 24
CRED_I is the following COSE_Key:
{
1: 1,
-1: 4,
-2: h'2C440CC121F8D7F24C3B0E41AEDAFE9CAA4F4E7ABB835EC30F1DE88ADB96FF71',
"subject name": ""
}
Which encodes to the following byte string:
CRED_I (54 bytes)
a4 01 01 20 04 21 58 20 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae da fe 9c
aa 4f 4e 7a bb 83 5e c3 0f 1d e8 8a db 96 ff 71 6c 73 75 62 6a 65 63 74
20 6e 61 6d 65 60
Since no opaque auxiliary data is exchanged:
AD_3 (0 bytes)
The Plaintext of the COSE_Encrypt is the empty string:
P_3m (0 bytes)
The external_aad is the CBOR Sequence of CRED_I and TH_3, in this
order:
A_3m (CBOR-encoded) (105 bytes)
83 68 45 6e 63 72 79 70 74 30 44 a1 04 41 24 58 58 58 20 51 dd 22 43 a6
b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc e4 80 16 07 03 ee d9 c4 a1
bc b6 11 a4 01 01 20 04 21 58 20 2c 44 0c c1 21 f8 d7 f2 4c 3b 0e 41 ae
da fe 9c aa 4f 4e 7a bb 83 5e c3 0f 1d e8 8a db 96 ff 71 6c 73 75 62 6a
65 63 74 20 6e 61 6d 65 60
Info for K_3m is computed as follows:
info for K_3m =
[
10,
h'51DD2243A6B83F1316DC53291AE191CD93B444CCE480160703EED9C4A1BCB611',
"K_3m",
16
]
Which as a CBOR encoded data item is:
info for K_3m (CBOR-encoded) (42 bytes)
84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc
e4 80 16 07 03 ee d9 c4 a1 bc b6 11 64 4b 5f 33 6d 10
From these parameters, K_3m is computed. Key K_3m is the output of
HKDF-Expand(PRK_4x3m, info, L), where L is the length of K_2m, so 16
bytes.
K_3m (16 bytes)
84 85 31 8a a3 08 6f d5 86 7a 02 8e 99 e2 40 30
Nonce IV_3m is the output of HKDF-Expand(PRK_4x3m, info, L), where L
= 13 bytes.
Info for IV_3m is defined as follows:
info for IV_3m =
[
10,
h'51DD2243A6B83F1316DC53291AE191CD93B444CCE480160703EED9C4A1BCB611',
"IV_3m",
13
]
Which as a CBOR encoded data item is:
info for IV_3m (CBOR-encoded) (43 bytes)
84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc
e4 80 16 07 03 ee d9 c4 a1 bc b6 11 65 49 56 5f 33 6d 0d
From these parameters, IV_3m is computed:
IV_3m (13 bytes)
1e 10 5b 88 50 0e d5 ae b0 5d 00 6b ea
MAC_3 is the ciphertext of the COSE_Encrypt0:
MAC_3 (8 bytes)
1f b7 5a c1 aa d2 34 25
Since the method = 3, Signature_or_Mac_3 is the MAC_3:
Signature_or_MAC_3 (8 bytes)
1f b7 5a c1 aa d2 34 25
Finally, the outer COSE_Encrypt0 is computed.
The Plaintext is the following CBOR Sequence: plaintext = ( ID_CRED_I
, 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
string kid_I is conveyed in the plaintext encoded as a
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,
and 12 in CBOR encoding is equal to 0x0c.
P_3ae (CBOR Sequence) (10 bytes)
0c 48 1f b7 5a c1 aa d2 34 25
The Associated data A is the following: Associated data A = [
"Encrypt0", h'', TH_3 ]
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
29 1a e1 91 cd 93 b4 44 cc e4 80 16 07 03 ee d9 c4 a1 bc b6 11
Key K_3ae is the output of HKDF-Expand(PRK_3e2m, info, L).
info is defined as follows:
info for K_3ae =
[
10,
h'51DD2243A6B83F1316DC53291AE191CD93B444CCE480160703EED9C4A1BCB611',
"K_3ae",
16
]
Which as a CBOR encoded data item is:
info for K_3ae (CBOR-encoded) (43 bytes)
84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc
e4 80 16 07 03 ee d9 c4 a1 bc b6 11 65 4b 5f 33 61 65 10
L is the length of K_3ae, so 16 bytes.
From these parameters, K_3ae is computed:
K_3ae (16 bytes)
bf 29 0b 7e e0 4b 86 5d e1 01 0a 81 1b 36 00 64
Nonce IV_3ae is the output of HKDF-Expand(PRK_3e2m, info, L).
info is defined as follows:
info for IV_3ae =
[
10,
h'51DD2243A6B83F1316DC53291AE191CD93B444CCE480160703EED9C4A1BCB611',
"IV_3ae",
13
]
Which as a CBOR encoded data item is:
info for IV_3ae (CBOR-encoded) (44 bytes)
84 0a 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53 29 1a e1 91 cd 93 b4 44 cc
e4 80 16 07 03 ee d9 c4 a1 bc b6 11 66 49 56 5f 33 61 65 0d
L is the length of IV_3ae, so 13 bytes.
From these parameters, IV_3ae is computed:
IV_3ae (13 bytes)
0e 74 45 0a fc ec e9 73 af 64 e9 4d 46
Using the parameters above, the ciphertext CIPHERTEXT_3 can be
computed:
CIPHERTEXT_3 (18 bytes)
53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0
From the parameter above, message_3 is computed, as the CBOR Sequence
of the following items: (C_R, CIPHERTEXT_3).
message_3 =
(
h'08',
h'53C3991999A5FFB86921E99B607C067770E0'
)
Which encodes to the following byte string:
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
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, Erik Thormarker, and Michel Smyshlyaev, Valery Smyslov, Rene Struik, Vaishnavi Sundararajan, Erik
Veillette for reviewing and commenting on intermediate versions of Thormarker, and Michel Veillette for reviewing and commenting on
the draft. We are especially indebted to Jim Schaad for his intermediate versions of the draft. We are especially indebted to
continuous reviewing and implementation of different versions of the Jim Schaad for his continuous reviewing and implementation of
draft. different versions of the draft.
Authors' Addresses Authors' Addresses
Goeran Selander Goeran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
John Preuss Mattsson John Preuss Mattsson
Ericsson AB Ericsson AB
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
 End of changes. 79 change blocks. 
212 lines changed or deleted 943 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/