draft-ietf-lake-edhoc-11.txt   draft-ietf-lake-edhoc-12.txt 
Network Working Group G. Selander Network Working Group G. Selander
Internet-Draft J. Preuß Mattsson Internet-Draft J. Preuß Mattsson
Intended status: Standards Track F. Palombini Intended status: Standards Track F. Palombini
Expires: 28 March 2022 Ericsson Expires: 23 April 2022 Ericsson
24 September 2021 20 October 2021
Ephemeral Diffie-Hellman Over COSE (EDHOC) Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-edhoc-11 draft-ietf-lake-edhoc-12
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,
forward secrecy, and identity protection. EDHOC is intended for forward secrecy, and identity protection. EDHOC is intended for
usage in constrained scenarios and a main use case is to establish an usage in constrained scenarios and a main use case is to establish an
OSCORE security context. By reusing COSE for cryptography, CBOR for OSCORE security context. By reusing COSE for cryptography, CBOR for
encoding, and CoAP for transport, the additional code size can be encoding, and CoAP for transport, the additional code size can be
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 28 March 2022. This Internet-Draft will expire on 23 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 6 1.3. Message Size Examples . . . . . . . . . . . . . . . . . . 6
1.4. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.4. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.5. Terminology and Requirements Language . . . . . . . . . . 6 1.5. Terminology and Requirements Language . . . . . . . . . . 6
2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 7 2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Connection Identifiers . . . . . . . . . . . . . . . . . 10 3.3. Connection Identifiers . . . . . . . . . . . . . . . . . 10
3.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Authentication Parameters . . . . . . . . . . . . . . . . 12 3.5. Authentication Parameters . . . . . . . . . . . . . . . . 12
3.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 18 3.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 18
3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 20 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 19
3.8. External Authorization Data (EAD) . . . . . . . . . . . . 20 3.8. External Authorization Data (EAD) . . . . . . . . . . . . 20
3.9. Applicability Statement . . . . . . . . . . . . . . . . . 21 3.9. Applicability Statement . . . . . . . . . . . . . . . . . 21
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 23 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Extract . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Extract . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Expand . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2. Expand . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3. EDHOC-Exporter . . . . . . . . . . . . . . . . . . . . . 26 4.3. EDHOC-Exporter . . . . . . . . . . . . . . . . . . . . . 25
4.4. EDHOC-KeyUpdate . . . . . . . . . . . . . . . . . . . . . 27 4.4. EDHOC-KeyUpdate . . . . . . . . . . . . . . . . . . . . . 26
5. Message Formatting and Processing . . . . . . . . . . . . . . 27 5. Message Formatting and Processing . . . . . . . . . . . . . . 26
5.1. Message Processing Outline . . . . . . . . . . . . . . . 27 5.1. Message Processing Outline . . . . . . . . . . . . . . . 27
5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 28 5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 28
5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 30 5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 29
5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 32 5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 32
5.5. EDHOC Message 4 . . . . . . . . . . . . . . . . . . . . . 36 5.5. EDHOC Message 4 . . . . . . . . . . . . . . . . . . . . . 35
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 38 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 37
6.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2. Unspecified . . . . . . . . . . . . . . . . . . . . . . . 39 6.2. Unspecified . . . . . . . . . . . . . . . . . . . . . . . 38
6.3. Wrong Selected Cipher Suite . . . . . . . . . . . . . . . 39 6.3. Wrong Selected Cipher Suite . . . . . . . . . . . . . . . 38
7. Mandatory-to-Implement Compliance Requirements . . . . . . . 41 7. Mandatory-to-Implement Compliance Requirements . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
8.1. Security Properties . . . . . . . . . . . . . . . . . . . 42 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 42
8.2. Cryptographic Considerations . . . . . . . . . . . . . . 45 8.2. Cryptographic Considerations . . . . . . . . . . . . . . 44
8.3. Cipher Suites and Cryptographic Algorithms . . . . . . . 45 8.3. Cipher Suites and Cryptographic Algorithms . . . . . . . 45
8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 46 8.4. Post-Quantum Considerations . . . . . . . . . . . . . . . 46
8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 46 8.5. Unprotected Data . . . . . . . . . . . . . . . . . . . . 46
8.6. Implementation Considerations . . . . . . . . . . . . . . 46 8.6. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 8.7. Implementation Considerations . . . . . . . . . . . . . . 47
9.1. EDHOC Exporter Label Registry . . . . . . . . . . . . . . 48 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
9.1. EDHOC Exporter Label Registry . . . . . . . . . . . . . . 49
9.2. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 49 9.2. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 49
9.3. EDHOC Method Type Registry . . . . . . . . . . . . . . . 51 9.3. EDHOC Method Type Registry . . . . . . . . . . . . . . . 51
9.4. EDHOC Error Codes Registry . . . . . . . . . . . . . . . 51 9.4. EDHOC Error Codes Registry . . . . . . . . . . . . . . . 51
9.5. EDHOC External Authorization Data Registry . . . . . . . 51 9.5. EDHOC External Authorization Data Registry . . . . . . . 52
9.6. COSE Header Parameters Registry . . . . . . . . . . . . . 51 9.6. COSE Header Parameters Registry . . . . . . . . . . . . . 52
9.7. COSE Header Parameters Registry . . . . . . . . . . . . . 52 9.7. COSE Header Parameters Registry . . . . . . . . . . . . . 52
9.8. COSE Key Common Parameters Registry . . . . . . . . . . . 52 9.8. COSE Key Common Parameters Registry . . . . . . . . . . . 53
9.9. CWT Confirmation Methods Registry . . . . . . . . . . . . 53 9.9. CWT Confirmation Methods Registry . . . . . . . . . . . . 53
9.10. The Well-Known URI Registry . . . . . . . . . . . . . . . 53 9.10. The Well-Known URI Registry . . . . . . . . . . . . . . . 53
9.11. Media Types Registry . . . . . . . . . . . . . . . . . . 53 9.11. Media Types Registry . . . . . . . . . . . . . . . . . . 54
9.12. CoAP Content-Formats Registry . . . . . . . . . . . . . . 54 9.12. CoAP Content-Formats Registry . . . . . . . . . . . . . . 55
9.13. Resource Type (rt=) Link Target Attribute Values 9.13. Resource Type (rt=) Link Target Attribute Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . 55 Registry . . . . . . . . . . . . . . . . . . . . . . . . 55
9.14. Expert Review Instructions . . . . . . . . . . . . . . . 55 9.14. Expert Review Instructions . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.1. Normative References . . . . . . . . . . . . . . . . . . 55 10.1. Normative References . . . . . . . . . . . . . . . . . . 56
10.2. Informative References . . . . . . . . . . . . . . . . . 58 10.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 61 Appendix A. Use with OSCORE and Transfer over CoAP . . . . . . . 62
A.1. Selecting EDHOC Connection Identifier . . . . . . . . . . 61 A.1. Selecting EDHOC Connection Identifier . . . . . . . . . . 62
A.2. Deriving the OSCORE Security Context . . . . . . . . . . 62 A.2. Deriving the OSCORE Security Context . . . . . . . . . . 63
A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 63 A.3. Transferring EDHOC over CoAP . . . . . . . . . . . . . . 64
Appendix B. Compact Representation . . . . . . . . . . . . . . . 66 Appendix B. Compact Representation . . . . . . . . . . . . . . . 67
Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 66 Appendix C. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 67
C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 67 C.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 68
C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 68 C.2. CDDL Definitions . . . . . . . . . . . . . . . . . . . . 69
C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 69 C.3. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Appendix D. Applicability Template . . . . . . . . . . . . . . . 71 Appendix D. Applicability Template . . . . . . . . . . . . . . . 72
Appendix E. EDHOC Message Deduplication . . . . . . . . . . . . 72 Appendix E. EDHOC Message Deduplication . . . . . . . . . . . . 73
Appendix F. Transports Not Natively Providing Correlation . . . 73 Appendix F. Transports Not Natively Providing Correlation . . . 74
Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 73 Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 74
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
Many Internet of Things (IoT) deployments require technologies which Many Internet of Things (IoT) deployments require technologies which
are highly performant in constrained environments [RFC7228]. IoT are highly performant in constrained environments [RFC7228]. IoT
devices may be constrained in various ways, including memory, devices may be constrained in various ways, including memory,
storage, processing capacity, and power. The connectivity for these storage, processing capacity, and power. The connectivity for these
settings may also exhibit constraints such as unreliable and lossy settings may also exhibit constraints such as unreliable and lossy
channels, highly restricted bandwidth, and dynamic topology. The channels, highly restricted bandwidth, and dynamic topology. The
IETF has acknowledged this problem by standardizing a range of IETF has acknowledged this problem by standardizing a range of
lightweight protocols and enablers designed for the IoT, including lightweight protocols and enablers designed for the IoT, including
skipping to change at page 7, line 29 skipping to change at page 7, line 29
EDHOC specifies different authentication methods of the Diffie- EDHOC specifies different authentication methods of the Diffie-
Hellman key exchange: digital signatures and static Diffie-Hellman Hellman key exchange: digital signatures and static Diffie-Hellman
keys. This section outlines the digital signature-based method. keys. This section outlines the digital signature-based method.
Further details of protocol elements and other authentication methods Further details of protocol elements and other authentication methods
are provided in the remainder of this document. are provided in the remainder of this document.
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS
1.3 [RFC8446], EDHOC authenticated with digital signatures is built 1.3 [RFC8446], EDHOC authenticated with digital signatures is built
on a variant of the SIGMA protocol which provides identity protection on a variant of the SIGMA protocol which provides identity protection
of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC of the initiator (SIGMA-I) against active attackers, and like IKEv2
implements the MAC-then-Sign variant of the SIGMA-I protocol shown in [RFC7296], EDHOC implements the MAC-then-Sign variant of the SIGMA-I
Figure 2. protocol shown in Figure 2.
Initiator Responder Initiator Responder
| G_X | | G_X |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
| | | |
| G_Y, Enc( ID_CRED_R, Sig( R; MAC( CRED_R, G_X, G_Y ) ) ) | | G_Y, Enc( ID_CRED_R, Sig( R; MAC( CRED_R, G_X, G_Y ) ) ) |
|<------------------------------------------------------------------+ |<------------------------------------------------------------------+
| | | |
| AEAD( ID_CRED_I, Sig( I; MAC( CRED_I, G_Y, G_X ) ) ) | | AEAD( ID_CRED_I, Sig( I; MAC( CRED_I, G_Y, G_X ) ) ) |
+------------------------------------------------------------------>| +------------------------------------------------------------------>|
skipping to change at page 8, line 33 skipping to change at page 8, line 33
for key derivation and as additional authenticated data. for key derivation and as additional authenticated data.
* Computationally independent keys derived from the ECDH shared * Computationally independent keys derived from the ECDH shared
secret and used for authenticated encryption of different secret and used for authenticated encryption of different
messages. messages.
* An optional fourth message giving explicit key confirmation to I * An optional fourth message giving explicit key confirmation to I
in deployments where no protected application data is sent from R in deployments where no protected application data is sent from R
to I. to I.
* A key material exporter and a key update function enabling forward * A key material exporter and a key update function with forward
secrecy. secrecy.
* Verification of a common preferred cipher suite. * Verification of a common preferred cipher suite.
* Method types and error handling. * Method types and error handling.
* Selection of connection identifiers C_I and C_R which may be used * Selection of connection identifiers C_I and C_R which may be used
to identify established keys or protocol state. to identify established keys or protocol state.
* Transport of external authorization data. * Transport of external authorization data.
skipping to change at page 14, line 41 skipping to change at page 14, line 41
specific authentication key/unique associated subject name, or a specific authentication key/unique associated subject name, or a
set of public authentication keys/unique associated subject names, set of public authentication keys/unique associated subject names,
which it is allowed to communicate with. EDHOC provides the proof which it is allowed to communicate with. EDHOC provides the proof
that the other party possesses the private authentication key that the other party possesses the private authentication key
corresponding to the public authentication key. corresponding to the public authentication key.
To prevent misbinding attacks in systems where an attacker can To prevent misbinding attacks in systems where an attacker can
register public keys without proving knowledge of the private key, register public keys without proving knowledge of the private key,
SIGMA [SIGMA] enforces a MAC to be calculated over the "identity". SIGMA [SIGMA] enforces a MAC to be calculated over the "identity".
EDHOC follows SIGMA by calculating a MAC over the whole credential, EDHOC follows SIGMA by calculating a MAC over the whole credential,
which in case of a X.509 or C509 certificate includes the "subject" which in case of an X.509 or C509 certificate includes the "subject"
and "subjectAltName" fields, and in the case of CWT or CCS includes and "subjectAltName" fields, and in the case of CWT or CCS includes
the "sub" claim. While the SIGMA paper only focuses on the identity, the "sub" claim. While the SIGMA paper only focuses on the identity,
the same principle is true for other information such as policies the same principle is true for other information such as policies
associated to the public key. associated to the public key.
3.5.2. Authentication Keys 3.5.2. Authentication Keys
The authentication key (i.e. the public key used for authentication) The authentication key (i.e. the public key used for authentication)
MUST be a signature key or static Diffie-Hellman key. The Initiator MUST be a signature key or static Diffie-Hellman key. The Initiator
and the Responder MAY use different types of authentication keys, and the Responder MAY use different types of authentication keys,
e.g., one uses a signature key and the other uses a static Diffie- e.g., one uses a signature key and the other uses a static Diffie-
Hellman key. The authentication key algorithm needs to be compatible Hellman key. The authentication key algorithm needs to be compatible
with the method and the cipher suite. The authentication key with the method and the cipher suite. The authentication key
algorithm needs to be compatible with the EDHOC key exchange algorithm needs to be compatible with the EDHOC key exchange
algorithm when static Diffie-Hellman authentication is used and algorithm when static Diffie-Hellman authentication is used, and
compatible with the EDHOC signature algorithm when signature compatible with the EDHOC signature algorithm when signature
authentication is used. authentication is used.
Note that for most signature algorithms, the signature is determined Note that for most signature algorithms, the signature is determined
by the signature algorithm and the authentication key algorithm by the signature algorithm and the authentication key algorithm
together. When using static Diffie-Hellman keys the Initiator's and together. When using static Diffie-Hellman keys the Initiator's and
Responder's private authentication keys are called I and R, Responder's private authentication keys are called I and R,
respectively, and the public authentication keys are called G_I and respectively, and the public authentication keys are called G_I and
G_R, respectively. G_R, respectively.
skipping to change at page 16, line 8 skipping to change at page 16, line 8
agree on a specific encoding of the credential, see Section 3.9. It agree on a specific encoding of the credential, see Section 3.9. It
is RECOMMENDED that the COSE 'kid' parameter, when used, refers to a is RECOMMENDED that the COSE 'kid' parameter, when used, refers to a
specific encoding. The Initiator and Responder SHOULD use an specific encoding. The Initiator and Responder SHOULD use an
available authentication credential (transported in EDHOC or available authentication credential (transported in EDHOC or
otherwise provisioned) without re-encoding. If for some reason re- otherwise provisioned) without re-encoding. If for some reason re-
encoding of the authentication credential may occur, then a potential encoding of the authentication credential may occur, then a potential
common encoding for CBOR based credentials is bytewise lexicographic common encoding for CBOR based credentials is bytewise lexicographic
order of their deterministic encodings as specified in Section 4.2.1 order of their deterministic encodings as specified in Section 4.2.1
of [RFC8949]. of [RFC8949].
* When the authentication credential is a X.509 certificate, CRED_x * When the authentication credential is an X.509 certificate, CRED_x
SHALL be the end-entity DER encoded certificate wrapped in a bstr SHALL be the end-entity DER encoded certificate, encoded as a bstr
[I-D.ietf-cose-x509]. [I-D.ietf-cose-x509].
* When the authentication credential is a C509 certificate, CRED_x * When the authentication credential is a C509 certificate, CRED_x
SHALL be the end-entity C509Certificate SHALL be the end-entity C509Certificate
[I-D.ietf-cose-cbor-encoded-cert] [I-D.ietf-cose-cbor-encoded-cert]
* When the authentication credential is a COSE_Key in a CWT, CRED_x * When the authentication credential is a COSE_Key in a CWT, CRED_x
SHALL be the untagged CWT. SHALL be the untagged CWT.
* When the authentication credential is a COSE_Key but not in a CWT, * When the authentication credential is a COSE_Key but not in a CWT,
CRED_x SHALL be an untagged CCS. * Naked COSE_Keys are thus CRED_x SHALL be an untagged CCS.
dressed as CCS when used in EDHOC, which is done by prefixing the
COSE_Key with 0xA108A101. - Naked COSE_Keys are thus dressed as CCS when used in EDHOC,
which is done by prefixing the COSE_Key with 0xA108A101.
An example of a CRED_x is shown below: An example of a CRED_x is shown below:
{ /CCS/ { /CCS/
2 : "42-50-31-FF-EF-37-32-39", /sub/ 2 : "42-50-31-FF-EF-37-32-39", /sub/
8 : { /cnf/ 8 : { /cnf/
1 : { /COSE_Key/ 1 : { /COSE_Key/
1 : 1, /kty/ 1 : 1, /kty/
2 : 0, /kid/ 2 : 0, /kid/
-1 : 4, /crv/ -1 : 4, /crv/
skipping to change at page 17, line 13 skipping to change at page 16, line 51
and an EUI-64 Identity. and an EUI-64 Identity.
3.5.4. Identification of Credentials 3.5.4. Identification of Credentials
ID_CRED_R and ID_CRED_I are transported in message_2 and message_3, ID_CRED_R and ID_CRED_I are transported in message_2 and message_3,
respectively (see Section 5.3.2 and Section 5.4.2). They are used to respectively (see Section 5.3.2 and Section 5.4.2). They are used to
identify and optionally transport the authentication keys of the identify and optionally transport the authentication keys of the
Initiator and the Responder, respectively. ID_CRED_I and ID_CRED_R Initiator and the Responder, respectively. ID_CRED_I and ID_CRED_R
do not have any cryptographic purpose in EDHOC since EDHOC integrity do not have any cryptographic purpose in EDHOC since EDHOC integrity
protects the authentication credential. EDHOC relies on COSE for protects the authentication credential. EDHOC relies on COSE for
identification of authentication credentials and supports all COSE identification of authentication credentials and supports all types
header parameters used to identify authentication credentials of COSE header parameters used to identify authentication credentials
including X.509, C509, CWT and CCS. including X.509, C509, CWT and CCS.
* ID_CRED_R is intended to facilitate for the Initiator to retrieve * ID_CRED_R is intended to facilitate for the Initiator to retrieve
the Responder's authentication key. the Responder's authentication key.
* ID_CRED_I is intended to facilitate for the Responder to retrieve * ID_CRED_I is intended to facilitate for the Responder to retrieve
the Initiator's authentication key. the Initiator's authentication key.
ID_CRED_I and ID_CRED_R are COSE header maps and contains one or more ID_CRED_I and ID_CRED_R are COSE header maps and contains one or more
COSE header parameter. ID_CRED_I and ID_CRED_R MAY contain different COSE header parameter. ID_CRED_I and ID_CRED_R MAY contain different
header parameters. The header parameters typically provide some header parameters. The header parameters typically provide some
information about the format of authentication credential. information about the format of authentication credential.
Note that COSE header parameters in ID_CRED_x are used to identify
the sender's authentication credential. There is therefore no reason
to use the "-sender" header parameters, such as x5t-sender, defined
in Section 3 of [I-D.ietf-cose-x509]. Instead, the corresponding
parameter without "-sender", such as x5t, SHOULD be used.
Example: X.509 certificates can be identified by a hash value using Example: X.509 certificates can be identified by a hash value using
the 'x5t' parameter: the 'x5t' parameter:
* ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, * ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
Example: CWT or CCS can be identified by a key identifier using the Example: CWT or CCS can be identified by a key identifier using the
'kid' parameter: 'kid' parameter:
* ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or * ID_CRED_x = { 4 : key_id_x }, where key_id_x : kid, for x = I or
R. R.
skipping to change at page 18, line 10 skipping to change at page 18, line 10
first. Applications should strive to make ID_CRED_x as unique as first. Applications should strive to make ID_CRED_x as unique as
possible, since the recipient may otherwise have to try several keys. possible, since the recipient may otherwise have to try several keys.
See Appendix C.3 for more examples. See Appendix C.3 for more examples.
3.6. Cipher Suites 3.6. Cipher Suites
An EDHOC cipher suite consists of an ordered set of algorithms from An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length. Algorithms need to be specified with enough as the EDHOC MAC length. Algorithms need to be specified with enough
parameters to make them completely determined. EDHOC is only parameters to make them completely determined. EDHOC is currently
specified for use with key exchange algorithms of type ECDH curves. only specified for use with key exchange algorithms of type ECDH
Use with other types of key exchange algorithms would likely require curves, but any Key Encapsulation Method (KEM), including Post-
a specification updating EDHOC. Note that for most signature Quantum Cryptography (PQC) KEMs, can be used in method 0, see
algorithms, the signature is determined by the signature algorithm Section 8.4. Use of other types of key exchange algorithms to
and the authentication key algorithm together, see Section 3.5.2. replace static DH authentication (method 1,2,3) would likely require
The authentication key algorithm needs to be compatible with the a specification updating EDHOC with new methods.
EDHOC key exchange algorithm when static Diffie-Hellman
authentication is used and compatible with the EDHOC signature EDHOC supports all signature algorithms defined by COSE, including
algorithm when signature authentication is used. PQC signature algorithms such as HSS-LMS. Just like in TLS 1.3
[RFC8446] and IKEv2 [RFC7296], a signature in COSE is determined by
the signature algorithm and the authentication key algorithm
together, see Section 3.5.2. The exact details of the authentication
key algorithm depend on the type of authentication credential. COSE
supports different formats for storing the public authentication keys
including COSE_Key and X.509, which have different names and ways to
represent the authentication key and the authentication key
algorithm.
An EDHOC cipher suite consists of the following parameters:
* EDHOC AEAD algorithm * EDHOC AEAD algorithm
* EDHOC hash algorithm * EDHOC hash algorithm
* EDHOC MAC length in bytes (Static DH) * EDHOC MAC length in bytes (Static DH)
* EDHOC key exchange algorithm (ECDH curve) * EDHOC key exchange algorithm (ECDH curve)
* EDHOC signature algorithm * EDHOC signature algorithm
* Application AEAD algorithm * Application AEAD algorithm
* Application hash algorithm * Application hash algorithm
Each cipher suite is identified with a pre-defined int label. Each cipher suite is identified with a pre-defined int label.
EDHOC can be used with all algorithms and curves defined for COSE. EDHOC can be used with all algorithms and curves defined for COSE.
Implementation can either use one of the pre-defined cipher suites Implementation can either use any combination of COSE algorithms and
(Section 9.2) or use any combination of COSE algorithms and parameters to define their own private cipher suite, or use one of
parameters to define their own private cipher suite. Private cipher the pre-defined cipher suites. Private cipher suites can be
suites can be identified with any of the four values -24, -23, -22, identified with any of the four values -24, -23, -22, -21. The pre-
-21. defined cipher suites are listed in the IANA registry (Section 9.2)
with initial content outlined here:
The following CCM cipher suites are for constrained IoT where message
overhead is a very important factor. Cipher suites 1 and 3 use a
larger tag length (128-bit) in EDHOC than in the Application AEAD
algorithm (64-bit):
0. ( 10, -16, 8, 4, -8, 10, -16 )
(AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA,
AES-CCM-16-64-128, SHA-256)
1. ( 30, -16, 16, 4, -8, 10, -16 )
(AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA,
AES-CCM-16-64-128, SHA-256)
2. ( 10, -16, 8, 1, -7, 10, -16 )
(AES-CCM-16-64-128, SHA-256, 8, P-256, ES256,
AES-CCM-16-64-128, SHA-256)
3. ( 30, -16, 16, 1, -7, 10, -16 )
(AES-CCM-16-128-128, SHA-256, 16, P-256, ES256,
AES-CCM-16-64-128, SHA-256)
The following ChaCha20 cipher suites are for less constrained
applications and only use 128-bit tag lengths.
4. ( 24, -16, 16, 4, -8, 24, -16 )
(ChaCha20/Poly1305, SHA-256, 16, X25519, EdDSA,
ChaCha20/Poly1305, SHA-256)
5. ( 24, -16, 16, 1, -7, 24, -16 )
(ChaCha20/Poly1305, SHA-256, 16, P-256, ES256,
ChaCha20/Poly1305, SHA-256)
The following GCM cipher suite is for general non-constrained * Cipher suites 0-3, based on AES-CCM, are intended for constrained
applications. It uses high performance algorithms that are widely IoT where message overhead is a very important factor. Note that
supported: AES-CCM-16-64-128 and AES-CCM-16-64-128 are compatible with the
IEEE CCM* mode.
6. ( 1, -16, 16, 4, -7, 1, -16 ) - Cipher suites 1 and 3 use a larger tag length (128-bit) in
(A128GCM, SHA-256, 16, X25519, ES256, EDHOC than in the Application AEAD algorithm (64-bit).
A128GCM, SHA-256)
The following two cipher suites are for high security application * Cipher suites 4 and 5, based on ChaCha20, are intended for less
such as government use and financial applications. The two cipher constrained applications and only use 128-bit tag lengths.
suites do not share any algorithms. The first of the two cipher
suites is compatible with the CNSA suite [CNSA].
24. ( 3, -43, 16, 2, -35, 3, -43 ) * Cipher suite 6, based on AES-GCM, is for general non-constrained
(A256GCM, SHA-384, 16, P-384, ES384, applications. It uses high performance algorithms that are widely
A256GCM, SHA-384) supported.
25. ( 24, -45, 16, 5, -8, 24, -45 ) * Cipher suites 24 and 25 are intended for high security
(ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA, applications such as government use and financial applications.
ChaCha20/Poly1305, SHAKE256) These cipher suites do not share any algorithms. Cipher suite 24
is compatible with the CNSA suite [CNSA].
The different methods use the same cipher suites, but some algorithms The different methods (Section 3.2) use the same cipher suites, but
are not used in some methods. The EDHOC signature algorithm is not some algorithms are not used in some methods. The EDHOC signature
used in methods without signature authentication. algorithm is not used in methods without signature authentication.
The Initiator needs to have a list of cipher suites it supports in The Initiator needs to have a list of cipher suites it supports in
order of preference. The Responder needs to have a list of cipher order of preference. The Responder needs to have a list of cipher
suites it supports. SUITES_I contains cipher suites supported by the suites it supports. SUITES_I contains cipher suites supported by the
Initiator, formatted and processed as detailed in Section 5.2.1 to Initiator, formatted and processed as detailed in Section 5.2.1 to
secure the cipher suite negotiation. Examples of cipher suite secure the cipher suite negotiation. Examples of cipher suite
negotiation are given in Section 6.3.2. negotiation are given in Section 6.3.2.
3.7. Ephemeral Public Keys 3.7. Ephemeral Public Keys
skipping to change at page 20, line 42 skipping to change at page 20, line 21
processing, external security applications may be integrated into processing, external security applications may be integrated into
EDHOC by transporting authorization related data in the messages. EDHOC by transporting authorization related data in the messages.
One example is third-party identity and authorization information One example is third-party identity and authorization information
protected out of scope of EDHOC [I-D.selander-ace-ake-authz]. protected out of scope of EDHOC [I-D.selander-ace-ake-authz].
Another example is a certificate enrolment request or the resulting Another example is a certificate enrolment request or the resulting
issued certificate. issued certificate.
EDHOC allows opaque external authorization data (EAD) to be sent in EDHOC allows opaque external authorization data (EAD) to be sent in
the EDHOC messages. External authorization data sent in message_1 the EDHOC messages. External authorization data sent in message_1
(EAD_1) or message_2 (EAD_2) should be considered unprotected by (EAD_1) or message_2 (EAD_2) should be considered unprotected by
EDHOC, see Section 8.4. External authorization data sent in EDHOC, see Section 8.5. External authorization data sent in
message_3 (EAD_3) or message_4 (EAD_4) is protected between Initiator message_3 (EAD_3) or message_4 (EAD_4) is protected between Initiator
and Responder. and Responder.
External authorization data is a CBOR sequence (see Appendix C.1) External authorization data is a CBOR sequence (see Appendix C.1)
consisting of one or more (ead_label, ead_value) pairs as defined consisting of one or more (ead_label, ead_value) pairs as defined
below: below:
ead = 1* ( ead = 1* (
ead_label : int, ead_label : int,
ead_value : any, ead_value : any,
skipping to change at page 24, line 11 skipping to change at page 23, line 37
PRK_2e is used to derive a keystream to encrypt message_2. PRK_2e is PRK_2e is used to derive a keystream to encrypt message_2. PRK_2e is
derived with the following input: derived with the following input:
* The salt SHALL be a zero-length byte string. Note that [RFC5869] * The salt SHALL be a zero-length byte string. Note that [RFC5869]
specifies that if the salt is not provided, it is set to a string specifies that if the salt is not provided, it is set to a string
of zeros (see Section 2.2 of [RFC5869]). For implementation of zeros (see Section 2.2 of [RFC5869]). For implementation
purposes, not providing the salt is the same as setting the salt purposes, not providing the salt is the same as setting the salt
to the zero-length byte string (0x). to the zero-length byte string (0x).
* The IKM SHALL be the ECDH shared secret G_XY (calculated from G_X * The IKM SHALL be the ephemeral-ephemeral ECDH shared secret G_XY
and Y or G_Y and X) as defined in Section 6.3.1 of (calculated from G_X and Y or G_Y and X) as defined in
[I-D.ietf-cose-rfc8152bis-algs]. Section 6.3.1 of [I-D.ietf-cose-rfc8152bis-algs]. The use of G_XY
gives forward secrecy, in the sense that compromise of the private
authentication keys does not compromise past session keys.
Example: Assuming the use of curve25519, the ECDH shared secret G_XY Example: Assuming the use of curve25519, the ECDH shared secret G_XY
is the output of the X25519 function [RFC7748]: is the output of the X25519 function [RFC7748]:
G_XY = X25519( Y, G_X ) = X25519( X, G_Y ) G_XY = X25519( Y, G_X ) = X25519( X, G_Y )
Example: Assuming the use of SHA-256 the extract phase of HKDF Example: Assuming the use of SHA-256 the extract phase of HKDF
produces PRK_2e as follows: produces PRK_2e as follows:
PRK_2e = HMAC-SHA-256( salt, G_XY ) PRK_2e = HMAC-SHA-256( salt, G_XY )
skipping to change at page 27, line 25 skipping to change at page 26, line 45
The EDHOC-KeyUpdate takes a nonce as input to guarantee that there The EDHOC-KeyUpdate takes a nonce as input to guarantee that there
are no short cycles. The Initiator and the Responder need to agree are no short cycles. The Initiator and the Responder need to agree
on the nonce, which can e.g., be a counter or a random number. While on the nonce, which can e.g., be a counter or a random number. While
the KeyUpdate method provides forward secrecy it does not give as the KeyUpdate method provides forward secrecy it does not give as
strong security properties as re-running EDHOC, see Section 8. strong security properties as re-running EDHOC, see Section 8.
5. Message Formatting and Processing 5. Message Formatting and Processing
This section specifies formatting of the messages and processing This section specifies formatting of the messages and processing
steps. Error messages are specified in Section 6. steps. Error messages are specified in Section 6. Annotated traces
of EDHOC protocol runs are provided in [I-D.selander-lake-traces].
An EDHOC message is encoded as a sequence of CBOR data items (CBOR An EDHOC message is encoded as a sequence of CBOR data items (CBOR
Sequence, [RFC8742]). Additional optimizations are made to reduce Sequence, [RFC8742]). Additional optimizations are made to reduce
message overhead. message overhead.
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
structures, only a subset of the parameters is included in the EDHOC structures, only a subset of the parameters is included in the EDHOC
messages, see Appendix C.3. The unprotected COSE header in messages, see Appendix C.3. The unprotected COSE header in
COSE_Sign1, and COSE_Encrypt0 (not included in the EDHOC message) MAY COSE_Sign1, and COSE_Encrypt0 (not included in the EDHOC message) MAY
contain parameters (e.g., 'alg'). contain parameters (e.g., 'alg').
5.1. Message Processing Outline 5.1. Message Processing Outline
This section outlines the message processing of EDHOC. This section outlines the message processing of EDHOC.
For each session, the endpoints are assumed to keep an associated For each new/ongoing session, the endpoints are assumed to keep an
protocol state containing identifiers, keys, etc. used for subsequent associated protocol state containing identifiers, keying material,
processing of protocol related data. The protocol state is assumed etc. used for subsequent processing of protocol related data. The
to be associated to an applicability statement (Section 3.9) which protocol state is assumed to be associated to an applicability
provides the context for how messages are transported, identified, statement (Section 3.9) which provides the context for how messages
and processed. are transported, identified, and processed.
EDHOC messages SHALL be processed according to the current protocol EDHOC messages SHALL be processed according to the current protocol
state. The following steps are expected to be performed at reception state. The following steps are expected to be performed at reception
of an EDHOC message: of an EDHOC message:
1. Detect that an EDHOC message has been received, for example by 1. Detect that an EDHOC message has been received, for example by
means of port number, URI, or media type (Section 3.9). means of port number, URI, or media type (Section 3.9).
2. Retrieve the protocol state according to the message correlation 2. Retrieve the protocol state according to the message correlation
provided by the transport, see Section 3.4. If there is no provided by the transport, see Section 3.4. If there is no
protocol state, in the case of message_1, a new protocol state is protocol state, in the case of message_1, a new protocol state is
created. The Responder endpoint needs to make use of available created. The Responder endpoint needs to make use of available
Denial-of-Service mitigation (Section 8.5). Denial-of-Service mitigation (Section 8.6).
3. If the message received is an error message, then process 3. If the message received is an error message, then process
according to Section 6, else process as the expected next message according to Section 6, else process as the expected next message
according to the protocol state. according to the protocol state.
If the processing fails for some reason then, typically, an error If the processing fails for some reason then, typically, an error
message is sent, the protocol is discontinued, and the protocol state message is sent, the protocol is discontinued, and the protocol state
erased. Further details are provided in the following subsections erased. Further details are provided in the following subsections
and in Section 6. and in Section 6.
skipping to change at page 28, line 50 skipping to change at page 28, line 24
SUITES_I : suites, SUITES_I : suites,
G_X : bstr, G_X : bstr,
C_I : bstr / int, C_I : bstr / int,
? EAD_1 : ead, ? EAD_1 : ead,
) )
suites = [ 2* int ] / int suites = [ 2* int ] / int
where: where:
* METHOD = 0, 1, 2, or 3 (see Figure 4). * METHOD - authentication method, see Section 3.2.
* SUITES_I - array of cipher suites which the Initiator supports in * SUITES_I - array of cipher suites which the Initiator supports in
order of preference, starting with the most preferred and ending order of preference, starting with the most preferred and ending
with the cipher suite selected for this session. If the most with the cipher suite selected for this session. If the most
preferred cipher suite is selected then SUITES_I is encoded as preferred cipher suite is selected then SUITES_I is encoded as
that cipher suite, i.e., as an int. The processing steps are that cipher suite, i.e., as an int. The processing steps are
detailed below and in Section 6.3. detailed below and in Section 6.3.
* G_X - the ephemeral public key of the Initiator * G_X - the ephemeral public key of the Initiator
* C_I - variable length connection identifier * C_I - variable length connection identifier
* EAD_1 - unprotected external authorization data, see Section 3.8. * EAD_1 - unprotected external authorization data, see Section 3.8.
5.2.2. Initiator Processing of Message 1 5.2.2. Initiator Processing of Message 1
The Initiator SHALL compose message_1 as follows: The Initiator SHALL compose message_1 as follows:
* The supported cipher suites and the order of preference MUST NOT * SUITES_I contains a list of supported cipher suites, in order of
be changed based on previous error messages. SUITES_I contains preference, truncated after the cipher suite selected for this
the ordered list of supported cipher suites, truncated after the session.
cipher suite selected for this session. The selected cipher suite
MAY be changed between sessions, e.g., based on previous error
messages (see next bullet), but all cipher suites which are more
preferred than the selected cipher suite in the list MUST be
included in SUITES_I.
* The Initiator MUST select its most preferred cipher suite, - The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the conditioned on what it can assume to be supported by the
Responder. If the Initiator previously received from the Responder.
Responder an error message with error code 2 (see Section 6.3)
indicating cipher suites supported by the Responder, then the - The selected cipher suite MAY be changed between sessions,
Initiator SHOULD select the most preferred supported cipher suite e.g., based on previous error messages (see next bullet), but
among those (note that error messages are not authenticated and all cipher suites which are more preferred than the selected
may be forged). cipher suite in the list MUST be included in SUITES_I.
- If the Initiator previously received from the Responder an
error message with error code 2 (see Section 6.3) indicating
cipher suites supported by the Responder, then the Initiator
SHOULD select the most preferred supported cipher suite among
those (note that error messages are not authenticated and may
be forged).
- The supported cipher suites and the order of preference MUST
NOT be changed based on previous error messages.
* Generate an ephemeral ECDH key pair using the curve in the * Generate an ephemeral ECDH key pair using the curve in the
selected cipher suite and format it as a COSE_Key. Let G_X be the selected cipher suite and format it as a COSE_Key. Let G_X be the
'x' parameter of the COSE_Key. 'x' parameter of the COSE_Key.
* Choose a connection identifier C_I and store it for the length of * Choose a connection identifier C_I and store it for the length of
the protocol. the protocol.
* Encode message_1 as a sequence of CBOR encoded data items as * Encode message_1 as a sequence of CBOR encoded data items as
specified in Section 5.2.1 specified in Section 5.2.1
skipping to change at page 30, line 20 skipping to change at page 29, line 45
* Verify that the selected cipher suite is supported and that no * Verify that the selected cipher suite is supported and that no
prior cipher suite in SUITES_I is supported. prior cipher suite in SUITES_I is supported.
* Pass EAD_1 to the security application. * Pass EAD_1 to the security application.
If any processing step fails, the Responder SHOULD send an EDHOC If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in Section 6, and the error message back, formatted as defined in Section 6, and the
session MUST be discontinued. Sending error messages is essential session MUST be discontinued. Sending error messages is essential
for debugging but MAY e.g., be skipped due to denial-of-service for debugging but MAY e.g., be skipped due to denial-of-service
reasons, see Section 8. reasons, see Section 8.6. If an error message is sent, the session
MUST be discontinued.
5.3. EDHOC Message 2 5.3. EDHOC Message 2
5.3.1. Formatting of Message 2 5.3.1. Formatting of Message 2
message_2 SHALL be a CBOR Sequence (see Appendix C.1) as defined message_2 SHALL be a CBOR Sequence (see Appendix C.1) as defined
below below
message_2 = ( message_2 = (
G_Y_CIPHERTEXT_2 : bstr, G_Y_CIPHERTEXT_2 : bstr,
C_R : bstr / int, C_R : bstr / int,
) )
skipping to change at page 31, line 24 skipping to change at page 30, line 51
3), then mac_length_2 is the EDHOC MAC length given by the 3), then mac_length_2 is the EDHOC MAC length given by the
selected cipher suite. If the Responder authenticates with a selected cipher suite. If the Responder authenticates with a
signature key (method equals 0 or 2), then mac_length_2 is equal signature key (method equals 0 or 2), then mac_length_2 is equal
to the output size of the EDHOC hash algorithm given by the to the output size of the EDHOC hash algorithm given by the
selected cipher suite. selected cipher suite.
- ID_CRED_R - identifier to facilitate retrieval of CRED_R, see - ID_CRED_R - identifier to facilitate retrieval of CRED_R, see
Section 3.5.4 Section 3.5.4
- CRED_R - CBOR item containing the credential of the Responder, - CRED_R - CBOR item containing the credential of the Responder,
see Section 3.5.4 see Section 3.5.3
- EAD_2 = unprotected external authorization data, see - EAD_2 - unprotected external authorization data, see
Section 3.8 Section 3.8
* If the Responder authenticates with a static Diffie-Hellman key * If the Responder authenticates with a static Diffie-Hellman key
(method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the
Responder authenticates with a signature key (method equals 0 or Responder authenticates with a signature key (method equals 0 or
2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1 2), then Signature_or_MAC_2 is the 'signature' field of a
object as defined in Section 4.4 of COSE_Sign1 object as defined in Section 4.4 of
[I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm in [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm of
the selected cipher suite, the private authentication key of the the selected cipher suite, the private authentication key of the
Responder, and the following parameters: Responder, and the following parameters as input (see
Appendix C.3):
- protected = << ID_CRED_R >> - protected = << ID_CRED_R >>
- external_aad = << TH_2, CRED_R, ? EAD_2 >> - external_aad = << TH_2, CRED_R, ? EAD_2 >>
- payload = MAC_2 - payload = MAC_2
COSE constructs the input to the Signature Algorithm as: * CIPHERTEXT_2 is calculated by using the Expand function as a
binary additive stream cipher.
- The key is the private authentication key of the Responder.
- The message M to be signed =
[ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? EAD_2 >>,
MAC_2 ]
* CIPHERTEXT_2 is encrypted by using the Expand function as a binary
additive stream cipher.
- plaintext = ( ID_CRED_R / bstr / int, Signature_or_MAC_2, ? - plaintext = ( ID_CRED_R / bstr / int, Signature_or_MAC_2, ?
EAD_2 ) EAD_2 )
o Note that if ID_CRED_R contains a single 'kid' parameter, o If ID_CRED_R contains a single 'kid' parameter, i.e.,
i.e., ID_CRED_R = { 4 : kid_R }, only the byte string or ID_CRED_R = { 4 : kid_R }, then only the byte string or
integer kid_R is conveyed in the plaintext encoded as a bstr integer kid_R is conveyed in the plaintext encoded
or int. accordingly as bstr or int.
- Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2",
h'', plaintext_length ), where plaintext_length is the length
of the plaintext.
- CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 - CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2
* Encode message_2 as a sequence of CBOR encoded data items as * Encode message_2 as a sequence of CBOR encoded data items as
specified in Section 5.3.1. specified in Section 5.3.1.
5.3.3. Initiator Processing of Message 2 5.3.3. Initiator Processing of Message 2
The Initiator SHALL process message_2 as follows: The Initiator SHALL process message_2 as follows:
* Decode message_2 (see Appendix C.1). * Decode message_2 (see Appendix C.1).
* Retrieve the protocol state using the message correlation provided * Retrieve the protocol state using the message correlation provided
by the transport (e.g., the CoAP Token and the 5-tuple as a by the transport (e.g., the CoAP Token, the 5-tuple, or the
client, or the prepended C_I as a server). prepended C_I, see Appendix A.3).
* Decrypt CIPHERTEXT_2, see Section 5.3.2. * Decrypt CIPHERTEXT_2, see Section 5.3.2.
* Pass EAD_2 to the security application. * Pass EAD_2 to the security application.
* Verify that the identity of the Responder is an allowed identity * Verify that the identity of the Responder is an allowed identity
for this connection, see Section 3.5. for this connection, see Section 3.5.1.
* Verify Signature_or_MAC_2 using the algorithm in the selected * Verify Signature_or_MAC_2 using the algorithm in the selected
cipher suite. The verification process depends on the method, see cipher suite. The verification process depends on the method, see
Section 5.3.2. Section 5.3.2.
If any processing step fails, the Initiator SHOULD send an EDHOC If any processing step fails, the Initiator SHOULD send an EDHOC
error message back, formatted as defined in Section 6. Sending error error message back, formatted as defined in Section 6. Sending error
messages is essential for debugging but MAY e.g., be skipped if a messages is essential for debugging but MAY e.g., be skipped if a
session cannot be found or due to denial-of-service reasons, see session cannot be found or due to denial-of-service reasons, see
Section 8. If an error message is sent, the session MUST be Section 8.6. If an error message is sent, the session MUST be
discontinued. discontinued.
5.4. EDHOC Message 3 5.4. EDHOC Message 3
5.4.1. Formatting of Message 3 5.4.1. Formatting of Message 3
message_3 SHALL be a CBOR Sequence (see Appendix C.1) as defined message_3 SHALL be a CBOR Sequence (see Appendix C.1) as defined
below below
message_3 = ( message_3 = (
CIPHERTEXT_3 : bstr, CIPHERTEXT_3 : bstr,
) )
5.4.2. Initiator Processing of Message 3 5.4.2. Initiator Processing of Message 3
skipping to change at page 33, line 36 skipping to change at page 33, line 9
3), then mac_length_3 is the EDHOC MAC length given by the 3), then mac_length_3 is the EDHOC MAC length given by the
selected cipher suite. If the Initiator authenticates with a selected cipher suite. If the Initiator authenticates with a
signature key (method equals 0 or 1), then mac_length_3 is equal signature key (method equals 0 or 1), then mac_length_3 is equal
to the output size of the EDHOC hash algorithm given by the to the output size of the EDHOC hash algorithm given by the
selected cipher suite. selected cipher suite.
- ID_CRED_I - identifier to facilitate retrieval of CRED_I, see - ID_CRED_I - identifier to facilitate retrieval of CRED_I, see
Section 3.5.4 Section 3.5.4
- CRED_I - CBOR item containing the credential of the Initiator, - CRED_I - CBOR item containing the credential of the Initiator,
see Section 3.5.4 see Section 3.5.3
- EAD_3 = protected external authorization data, see Section 3.8 - EAD_3 - protected external authorization data, see Section 3.8
* If the Initiator authenticates with a static Diffie-Hellman key * If the Initiator authenticates with a static Diffie-Hellman key
(method equals 2 or 3), then Signature_or_MAC_3 is MAC_3. If the (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3. If the
Initiator authenticates with a signature key (method equals 0 or Initiator authenticates with a signature key (method equals 0 or
1), then Signature_or_MAC_3 is the 'signature' of a COSE_Sign1 1), then Signature_or_MAC_3 is the 'signature' field of a
object as defined in Section 4.4 of COSE_Sign1 object as defined in Section 4.4 of
[I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm in [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm of
the selected cipher suite, the private authentication key of the the selected cipher suite, the private authentication key of the
Initiator, and the following parameters: Initiator, and the following parameters as input (see
Appendix C.3):
- protected = << ID_CRED_I >> - protected = << ID_CRED_I >>
- external_aad = << TH_3, CRED_I, ? EAD_3 >> - external_aad = << TH_3, CRED_I, ? EAD_3 >>
- payload = MAC_3
COSE constructs the input to the Signature Algorithm as:
- The key is the private authentication key of the Initiator.
- The message M to be signed = - payload = MAC_3
[ "Signature1", << ID_CRED_I >>, << TH_3, CRED_I, ? EAD_3 >>,
MAC_3 ]
* Compute an outer COSE_Encrypt0 as defined in Section 5.3 of * Compute a COSE_Encrypt0 object as defined in Section 5.3 of
[I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm
in the selected cipher suite, K_3, IV_3, and the following of the selected cipher suite, using the encryption key K_3, the
parameters. The protected header SHALL be the empty CBOR byte initialization vector IV_3, the plaintext P, and the following
string. parameters as input (see Appendix C.3):
- protected = h'' - protected = h''
- external_aad = TH_3 - external_aad = TH_3
- plaintext = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? where
EAD_3 )
o Note that if ID_CRED_I contains a single 'kid' parameter,
i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or
integer kid_I is conveyed in the plaintext encoded as a bstr
or int.
COSE constructs the input to the AEAD [RFC5116] as follows: - K_3 = EDHOC-KDF( PRK_3e2m, TH_3, "K_3", h'', key_length )
- Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3", h'', length ) o key_length - length of the encryption key of the EDHOC AEAD
algorithm
- Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3", h'', length ) - IV_3 = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3", h'', iv_length )
- Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? o iv_length - length of the intialization vector of the EDHOC
EAD_3 ) AEAD algorithm
- Associated data A = [ "Encrypt0", h'', TH_3 ] - P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? EAD_3 )
o If ID_CRED_I contains a single 'kid' parameter, i.e.,
ID_CRED_I = { 4 : kid_I }, only the byte string or integer
kid_I is conveyed in the plaintext encoded accordingly as
bstr or int.
CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0. CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.
* Encode message_3 as a sequence of CBOR encoded data items as * Encode message_3 as a CBOR data item as specified in
specified in Section 5.4.1. Section 5.4.1.
Pass the connection identifiers (C_I, C_R) and the application Pass the connection identifiers (C_I, C_R) and the application
algorithms in the selected cipher suite to the application. The algorithms in the selected cipher suite to the application. The
application can now derive application keys using the EDHOC-Exporter application can now derive application keys using the EDHOC-Exporter
interface, see Section 4.3. interface, see Section 4.3.
After sending message_3, the Initiator is assured that no other party After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (implicit key than the Responder can compute the key PRK_4x3m (implicit key
authentication). The Initiator can securely derive application keys authentication). The Initiator can securely derive application keys
and send protected application data. However, the Initiator does not and send protected application data. However, the Initiator does not
skipping to change at page 35, line 30 skipping to change at page 34, line 39
confirmation is e.g., assured when the Initiator has verified an confirmation is e.g., assured when the Initiator has verified an
OSCORE message or message_4 from the Responder. OSCORE message or message_4 from the Responder.
5.4.3. Responder Processing of Message 3 5.4.3. Responder Processing of Message 3
The Responder SHALL process message_3 as follows: The Responder SHALL process message_3 as follows:
* Decode message_3 (see Appendix C.1). * Decode message_3 (see Appendix C.1).
* Retrieve the protocol state using the message correlation provided * Retrieve the protocol state using the message correlation provided
by the transport (e.g., the CoAP Token and the 5-tuple as a by the transport (e.g., the CoAP Token, the 5-tuple, or the
client, or the prepended C_R as a server). prepended C_I, see Appendix A.3).
* Decrypt and verify the outer COSE_Encrypt0 as defined in * Decrypt and verify the COSE_Encrypt0 as defined in Section 5.3 of
Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm
AEAD algorithm in the selected cipher suite, K_3, and IV_3. in the selected cipher suite, and the parameters defined in
Section 5.4.2.
* Pass EAD_3 to the security application. * Pass EAD_3 to the security application.
* Verify that the identity of the Initiator is an allowed identity * Verify that the identity of the Initiator is an allowed identity
for this connection, see Section 3.5. for this connection, see Section 3.5.1.
* Verify Signature_or_MAC_3 using the algorithm in the selected * 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 5.4.2. Section 5.4.2.
* 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 security algorithms in the selected cipher suite to the security
application. The application can now derive application keys application. The application can now derive application keys
using the EDHOC-Exporter interface. using the EDHOC-Exporter interface.
If any processing step fails, the Responder SHOULD send an EDHOC If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in Section 6. Sending error error message back, formatted as defined in Section 6. Sending error
messages is essential for debugging but MAY e.g., be skipped if a messages is essential for debugging but MAY e.g., be skipped if a
session cannot be found or due to denial-of-service reasons, see session cannot be found or due to denial-of-service reasons, see
Section 8. If an error message is sent, the session MUST be Section 8.6. If an error message is sent, the session MUST be
discontinued. discontinued.
After verifying message_3, the Responder is assured that the After verifying message_3, the Responder is assured that the
Initiator has calculated the key PRK_4x3m (explicit key confirmation) Initiator has calculated the key PRK_4x3m (explicit key confirmation)
and that no other party than the Responder can compute the key. The and that no other party than the Responder can compute the key. The
Responder can securely send protected application data and store the Responder can securely send protected application data and store the
keying material PRK_4x3m and TH_4. keying material PRK_4x3m and TH_4.
5.5. EDHOC Message 4 5.5. EDHOC Message 4
skipping to change at page 36, line 34 skipping to change at page 35, line 43
deployments where no protected application message is sent from the deployments where no protected application message is sent from the
Responder to the Initiator, the Responder MUST send message_4. Two Responder to the Initiator, the Responder MUST send message_4. Two
examples of such deployments: examples of such deployments:
1. When EDHOC is only used for authentication and no application 1. When EDHOC is only used for authentication and no application
data is sent. data is sent.
2. When application data is only sent from the Initiator to the 2. When application data is only sent from the Initiator to the
Responder. Responder.
Further considerations are provided in Section 3.9. Further considerations about when to use message_4 are provided in
Section 3.9 and Section 8.1.
5.5.1. Formatting of Message 4 5.5.1. Formatting of Message 4
message_4 SHALL be a CBOR Sequence (see Appendix C.1) as defined message_4 SHALL be a CBOR Sequence (see Appendix C.1) as defined
below below
message_4 = ( message_4 = (
CIPHERTEXT_4 : bstr, CIPHERTEXT_4 : bstr,
) )
5.5.2. Responder Processing of Message 4 5.5.2. Responder Processing of Message 4
The Responder SHALL compose message_4 as follows: The Responder SHALL compose message_4 as follows:
* Compute a COSE_Encrypt0 as defined in Section 5.3 of * Compute a COSE_Encrypt0 as defined in Section 5.3 of
[I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm
skipping to change at page 36, line 51 skipping to change at page 36, line 14
message_4 = ( message_4 = (
CIPHERTEXT_4 : bstr, CIPHERTEXT_4 : bstr,
) )
5.5.2. Responder Processing of Message 4 5.5.2. Responder Processing of Message 4
The Responder SHALL compose message_4 as follows: The Responder SHALL compose message_4 as follows:
* Compute a COSE_Encrypt0 as defined in Section 5.3 of * Compute a COSE_Encrypt0 as defined in Section 5.3 of
[I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm
in the selected cipher suite, and the following parameters. The of the selected cipher suite, using the encryption key K_4, the
protected header SHALL be the empty CBOR byte string. initialization vector IV_4, the plaintext P, and the following
parameters as input (see Appendix C.3):
- protected = h'' - protected = h''
- external_aad = TH_4 - external_aad = TH_4
- plaintext = ( ? EAD_4 ), where EAD_4 is protected external where
authorization data, see Section 3.8
- Key K_4 = EDHOC-Exporter( "EDHOC_K_4", h'', length )
- IV IV_4 = EDHOC-Exporter( "EDHOC_IV_4", h'', length ) - K_4 = EDHOC-Exporter( "EDHOC_K_4", h'', key_length )
COSE constructs the input to the AEAD [RFC5116] as follows: o key_length - length of the encryption key of the EDHOC AEAD
algorithm
- Key K = K_4 - IV_4 = EDHOC-Exporter( "EDHOC_IV_4", h'', iv_length )
- Nonce N = IV_4 o iv_length - length of the intialization vector of the EDHOC
AEAD algorithm
- Plaintext P = ( ? EAD_4 ) - P = ( ? EAD_4 )
- Associated data A = [ "Encrypt0", h'', TH_4 ] o EAD_4 - protected external authorization data, see
Section 3.8.
CIPHERTEXT_4 is the ciphertext of the COSE_Encrypt0. CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.
* Encode message_4 as a sequence of CBOR encoded data items as * Encode message_4 as a CBOR data item as specified in
specified in Section 5.5.1. Section 5.5.1.
5.5.3. Initiator Processing of Message 4 5.5.3. Initiator Processing of Message 4
The Initiator SHALL process message_4 as follows: The Initiator SHALL process message_4 as follows:
* Decode message_4 (see Appendix C.1). * Decode message_4 (see Appendix C.1).
* Retrieve the protocol state using the message correlation provided * Retrieve the protocol state using the message correlation provided
by the transport (e.g., the CoAP Token and the 5-tuple as a by the transport (e.g., the CoAP Token, the 5-tuple, or the
client, or the prepended C_I as a server). prepended C_I, see Appendix A.3).
* Decrypt and verify the outer COSE_Encrypt0 as defined in * Decrypt and verify the COSE_Encrypt0 as defined in Section 5.3 of
Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC [I-D.ietf-cose-rfc8152bis-struct], with the EDHOC AEAD algorithm
AEAD algorithm in the selected cipher suite, and the parameters in the selected cipher suite, and the parameters defined in
defined in Section 5.5.2. Section 5.5.2.
* Pass EAD_4 to the security application. * Pass EAD_4 to the security application.
If any processing step fails, the Responder SHOULD send an EDHOC If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in Section 6. Sending error error message back, formatted as defined in Section 6. Sending error
messages is essential for debugging but MAY e.g., be skipped if a messages is essential for debugging but MAY e.g., be skipped if a
session cannot be found or due to denial-of-service reasons, see session cannot be found or due to denial-of-service reasons, see
Section 8. If an error message is sent, the session MUST be Section 8.6. If an error message is sent, the session MUST be
discontinued. discontinued.
6. Error Handling 6. Error Handling
This section defines the format for error messages. This section defines the format for error messages.
An EDHOC error message can be sent by either endpoint as a reply to An EDHOC error message can be sent by either endpoint as a reply to
any non-error EDHOC message. How errors at the EDHOC layer are any non-error EDHOC message. How errors at the EDHOC layer are
transported depends on lower layers, which need to enable error transported depends on lower layers, which need to enable error
messages to be sent and processed as intended. messages to be sent and processed as intended.
skipping to change at page 41, line 48 skipping to change at page 41, line 27
message_2 containing the transcript hash TH_2 will fail and the message_2 containing the transcript hash TH_2 will fail and the
Initiator will discontinue the protocol. Initiator will discontinue the protocol.
7. Mandatory-to-Implement Compliance Requirements 7. Mandatory-to-Implement Compliance Requirements
An implementation may support only Initiator or only Responder. An implementation may support only Initiator or only Responder.
An implementation may support only a single method. None of the An implementation may support only a single method. None of the
methods are mandatory-to-implement. methods are mandatory-to-implement.
Implementations MUST support 'kid' parameters of type int. None of
the other COSE header parameters are mandatory-to-implement.
An implementation may support only a single credential type (CCS,
CWT, X.509, C509). None of the credential types are mandatory-to-
implement.
Implementations MUST support the EDHOC-Exporter. Implementations Implementations MUST support the EDHOC-Exporter. Implementations
SHOULD support EDHOC-KeyUpdate. SHOULD support EDHOC-KeyUpdate.
Implementaions MAY support message_4. Error codes 1 and 2 MUST be Implementations MAY support message_4. Error codes 1 and 2 MUST be
supported. supported.
Implementations MUST support 'kid' parameters of type int. Implementations MAY support EAD.
Editor's note: Is any COSE header parameters (kid, kcwt, kccs, x5t,
c5c, etc. ) MTI?
Editor's note: Is any credential type (CCS, CWT, X.509, C509) MTI?
Editor's note: Is support of EAD MTI?
For many constrained IoT devices it is problematic to support more For many constrained IoT devices it is problematic to support more
than one cipher suite. Existing devices can be expected to support than one cipher suite. Existing devices can be expected to support
either ECDSA or EdDSA. To enable as much interoperability as we can either ECDSA or EdDSA. To enable as much interoperability as we can
reasonably achieve, less constrained devices SHOULD implement both reasonably achieve, less constrained devices SHOULD implement both
cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES- cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-
CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA- CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA-
256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained 256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained
endpoints SHOULD implement cipher suite 0 or cipher suite 2. endpoints SHOULD implement cipher suite 0 or cipher suite 2.
Implementations only need to implement the algorithms needed for Implementations only need to implement the algorithms needed for
skipping to change at page 42, line 38 skipping to change at page 42, line 15
8. Security Considerations 8. Security Considerations
8.1. Security Properties 8.1. Security Properties
EDHOC inherits its security properties from the theoretical SIGMA-I EDHOC inherits its security properties from the theoretical SIGMA-I
protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides
forward secrecy, mutual authentication with aliveness, consistency, forward secrecy, mutual authentication with aliveness, consistency,
and peer awareness. As described in [SIGMA], peer awareness is and peer awareness. As described in [SIGMA], peer awareness is
provided to the Responder, but not to the Initiator. provided to the Responder, but not to the Initiator.
EDHOC protects the credential identifier of the Initiator against As described in [SIGMA], different levels of identity protection is
active attacks and the credential identifier of the Responder against provided to the Initiator and the Responder. EDHOC protects the
passive attacks. The roles should be assigned to protect the most credential identifier of the Initiator against active attacks and the
sensitive identity/identifier, typically that which is not possible credential identifier of the Responder against passive attacks. The
to infer from routing information in the lower layers. roles should be assigned to protect the most sensitive identity/
identifier, typically that which is not possible to infer from
routing information in the lower layers.
Compared to [SIGMA], EDHOC adds an explicit method type and expands Compared to [SIGMA], EDHOC adds an explicit method type and expands
the message authentication coverage to additional elements such as the message authentication coverage to additional elements such as
algorithms, external authorization data, and previous messages. This algorithms, external authorization data, and previous messages. This
protects against an attacker replaying messages or injecting messages protects against an attacker replaying messages or injecting messages
from another session. from another session.
EDHOC also adds selection of connection identifiers and downgrade EDHOC also adds selection of connection identifiers and downgrade
protected negotiation of cryptographic parameters, i.e., an attacker protected negotiation of cryptographic parameters, i.e., an attacker
cannot affect the negotiated parameters. A single session of EDHOC cannot affect the negotiated parameters. A single session of EDHOC
skipping to change at page 46, line 12 skipping to change at page 46, line 5
certificates, EDHOC, and the protection of application data. The certificates, EDHOC, and the protection of application data. The
Initiator and the Responder should enforce a minimum security level. Initiator and the Responder should enforce a minimum security level.
The hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to The hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to
64-bits) SHALL NOT be supported for use in EDHOC except for 64-bits) SHALL NOT be supported for use in EDHOC except for
certificate identification with x5t and c5t. Note that secp256k1 is certificate identification with x5t and c5t. Note that secp256k1 is
only defined for use with ECDSA and not for ECDH. Note that some only defined for use with ECDSA and not for ECDH. Note that some
COSE algorithms are marked as not recommended in the COSE IANA COSE algorithms are marked as not recommended in the COSE IANA
registry. registry.
8.4. Unprotected Data 8.4. Post-Quantum Considerations
As of the publication of this specification, it is unclear when or
even if a quantum computer of sufficient size and power to exploit
public key cryptography will exist. Deployments that need to
consider risks decades into the future should transition to Post-
Quantum Cryptography (PQC) in the not-too-distant future. Many other
systems should take a slower wait-and-see approach where PQC is
phased in when the quantum threat is more imminent. Current PQC
algorithms have limitations compared to Elliptic Curve Cryptography
(ECC) and the data sizes would be problematic in many constrained IoT
systems.
Symmetric algorithms used in EDHOC such as SHA-256 and AES-CCM-
16-64-128 are practically secure against even large quantum
computers. EDHOC supports all signature algorithms defined by COSE,
including PQC signature algorithms such as HSS-LMS. EDHOC is
currently only specified for use with key exchange algorithms of type
ECDH curves, but any Key Encapsulation Method (KEM), including PQC
KEMs, can be used in method 0. While the key exchange in method 0 is
specified with terms of the Diffie-Hellman protocol, the key exchange
adheres to a KEM interface: G_X is then the public key of the
Initiator, G_Y is the encapsulation, and G_XY is the shared secret.
Use of PQC KEMs to replace static DH authentication would likely
require a specification updating EDHOC with new methods.
8.5. Unprotected Data
The Initiator and the Responder must make sure that unprotected data The Initiator and the Responder must make sure that unprotected data
and metadata do not reveal any sensitive information. This also and metadata do not reveal any sensitive information. This also
applies for encrypted data sent to an unauthenticated party. In applies for encrypted data sent to an unauthenticated party. In
particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error
messages. Using the same EAD_1 in several EDHOC sessions allows messages. Using the same EAD_1 in several EDHOC sessions allows
passive eavesdroppers to correlate the different sessions. Another passive eavesdroppers to correlate the different sessions. Another
consideration is that the list of supported cipher suites may consideration is that the list of supported cipher suites may
potentially be used to identify the application. potentially be used to identify the application.
The Initiator and the Responder must also make sure that The Initiator and the Responder must also make sure that
unauthenticated data does not trigger any harmful actions. In unauthenticated data does not trigger any harmful actions. In
particular, this applies to EAD_1 and error messages. particular, this applies to EAD_1 and error messages.
8.5. Denial-of-Service 8.6. Denial-of-Service
EDHOC itself does not provide countermeasures against Denial-of- As CoAP provides Denial-of-Service protection in the form of the Echo
Service attacks. By sending a number of new or replayed message_1 an option [I-D.ietf-core-echo-request-tag], EDHOC itself does not
attacker may cause the Responder to allocate state, perform provide countermeasures against Denial-of-Service attacks. By
cryptographic operations, and amplify messages. To mitigate such sending a number of new or replayed message_1 an attacker may cause
attacks, an implementation SHOULD rely on lower layer mechanisms such the Responder to allocate state, perform cryptographic operations,
as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that and amplify messages. To mitigate such attacks, an implementation
forces the initiator to demonstrate reachability at its apparent SHOULD rely on lower layer mechanisms such as the Echo option in CoAP
that forces the initiator to demonstrate reachability at its apparent
network address. network address.
An attacker can also send faked message_2, message_3, message_4, or An attacker can also send faked message_2, message_3, message_4, or
error in an attempt to trick the receiving party to send an error error in an attempt to trick the receiving party to send an error
message and discontinue the session. EDHOC implementations MAY message and discontinue the session. EDHOC implementations MAY
evaluate if a received message is likely to have been forged by an evaluate if a received message is likely to have been forged by an
attacker and ignore it without sending an error message or attacker and ignore it without sending an error message or
discontinuing the session. discontinuing the session.
8.6. Implementation Considerations 8.7. Implementation Considerations
The availability of a secure random number generator is essential for The availability of a secure random number generator is essential for
the security of EDHOC. If no true random number generator is the security of EDHOC. If no true random number generator is
available, a truly random seed MUST be provided from an external available, a truly random seed MUST be provided from an external
source and used with a cryptographically secure pseudorandom number source and used with a cryptographically secure pseudorandom number
generator. As each pseudorandom number must only be used once, an generator. As each pseudorandom number must only be used once, an
implementation needs to get a new truly random seed after reboot, or implementation needs to get a new truly random seed after reboot, or
continuously store state in nonvolatile memory, see ([RFC8613], continuously store state in nonvolatile memory, see ([RFC8613],
Appendix B.1.1) for issues and solution approaches for writing to Appendix B.1.1) for issues and solution approaches for writing to
nonvolatile memory. Intentionally or unintentionally weak or nonvolatile memory. Intentionally or unintentionally weak or
skipping to change at page 56, line 8 skipping to change at page 56, line 31
provided, the description provided needs to have sufficient provided, the description provided needs to have sufficient
information to verify the points above. information to verify the points above.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", Work in Progress, Request-Tag, and Token Processing", Work in Progress,
Internet-Draft, draft-ietf-core-echo-request-tag-13, 12 Internet-Draft, draft-ietf-core-echo-request-tag-14, 4
July 2021, <https://www.ietf.org/archive/id/draft-ietf- October 2021, <https://www.ietf.org/archive/id/draft-ietf-
core-echo-request-tag-13.txt>. core-echo-request-tag-14.txt>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-cose- <https://www.ietf.org/archive/id/draft-ietf-cose-
rfc8152bis-algs-12.txt>. rfc8152bis-algs-12.txt>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
skipping to change at page 60, line 12 skipping to change at page 60, line 46
Selander, G., Mattsson, J. P., Vucinic, M., Richardson, Selander, G., Mattsson, J. P., Vucinic, M., Richardson,
M., and A. Schellenbaum, "Lightweight Authorization for M., and A. Schellenbaum, "Lightweight Authorization for
Authenticated Key Exchange.", Work in Progress, Internet- Authenticated Key Exchange.", Work in Progress, Internet-
Draft, draft-selander-ace-ake-authz-03, 4 May 2021, Draft, draft-selander-ace-ake-authz-03, 4 May 2021,
<https://www.ietf.org/archive/id/draft-selander-ace-ake- <https://www.ietf.org/archive/id/draft-selander-ace-ake-
authz-03.txt>. authz-03.txt>.
[I-D.selander-lake-traces] [I-D.selander-lake-traces]
Selander, G. and J. P. Mattsson, "Traces of EDHOC", Work Selander, G. and J. P. Mattsson, "Traces of EDHOC", Work
in Progress, Internet-Draft, draft-selander-lake-traces- in Progress, Internet-Draft, draft-selander-lake-traces-
00, 10 September 2021, <https://www.ietf.org/archive/id/ 01, 24 September 2021, <https://www.ietf.org/archive/id/
draft-selander-lake-traces-00.txt>. draft-selander-lake-traces-01.txt>.
[Norrman20] [Norrman20]
Norrman, K., Sundararajan, V., and A. Bruni, "Formal Norrman, K., Sundararajan, V., and A. Bruni, "Formal
Analysis of EDHOC Key Establishment for Constrained IoT Analysis of EDHOC Key Establishment for Constrained IoT
Devices", September 2020, Devices", September 2020,
<https://arxiv.org/abs/2007.11427>. <https://arxiv.org/abs/2007.11427>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
skipping to change at page 70, line 9 skipping to change at page 71, line 9
[I-D.ietf-cose-rfc8152bis-struct] describes how to create and process [I-D.ietf-cose-rfc8152bis-struct] describes how to create and process
signatures, message authentication codes, and encryption using CBOR. signatures, message authentication codes, and encryption using CBOR.
COSE builds on JOSE, but is adapted to allow more efficient COSE builds on JOSE, but is adapted to allow more efficient
processing in constrained devices. EDHOC makes use of COSE_Key, processing in constrained devices. EDHOC makes use of COSE_Key,
COSE_Encrypt0, and COSE_Sign1 objects in the message processing: COSE_Encrypt0, and COSE_Sign1 objects in the message processing:
* ECDH ephemeral public keys of type EC2 or OKP in message_1 and * ECDH ephemeral public keys of type EC2 or OKP in message_1 and
message_2 consist of the COSE_Key parameter named 'x', see message_2 consist of the COSE_Key parameter named 'x', see
Section 7.1 and 7.2 of [I-D.ietf-cose-rfc8152bis-algs] Section 7.1 and 7.2 of [I-D.ietf-cose-rfc8152bis-algs]
* Certain ciphertexts in message_2 and message_3 consist of a subset * The ciphertexts in message_3 and message_4 consist of a subset of
of the single recipient encrypted data object COSE_Encrypt0, which the single recipient encrypted data object COSE_Encrypt0, which is
is described in Sections 5.2-5.3 of described in Sections 5.2-5.3 of
[I-D.ietf-cose-rfc8152bis-struct]. The ciphertext is computed [I-D.ietf-cose-rfc8152bis-struct]. The ciphertext is computed
over the plaintext and associated data, using an encryption key over the plaintext and associated data, using an encryption key
and a nonce. The associated data is an Enc_structure consisting and an initialization vector. The associated data is an
of protected headers and externally supplied data (external_aad). Enc_structure consisting of protected headers and externally
supplied data (external_aad). COSE constructs the input to the
AEAD [RFC5116] for message_i (i = 3 or 4, see Section 5.4 and
Section 5.5, respectively) as follows:
- Secret key K = K_i
- Nonce N = IV_i
- Plaintext P for message_i
- Associated Data A = [ "Encrypt0", h'', TH_i ]
* Signatures in message_2 of method 0 and 2, and in message_3 of * Signatures in message_2 of method 0 and 2, and in message_3 of
method 0 and 1, consist of a subset of the single signer data method 0 and 1, consist of a subset of the single signer data
object COSE_Sign1, which is described in Sections 4.2-4.4 of object COSE_Sign1, which is described in Sections 4.2-4.4 of
[I-D.ietf-cose-rfc8152bis-struct]. The signature is computed over [I-D.ietf-cose-rfc8152bis-struct]. The signature is computed over
a Sig_structure containing payload, protected headers and a Sig_structure containing payload, protected headers and
externally supplied data (external_aad) using a private signature externally supplied data (external_aad) using a private signature
key and verified using the corresponding public signature key. key and verified using the corresponding public signature key.
For COSE_Sign1, the message to be signed is:
[ "Signature1", protected, external_aad, payload ]
where protected, external_aad and payload are specified in
Section 5.3 and Section 5.4.
Different header parameters to identify X.509 or C509 certificates by Different header parameters to identify X.509 or C509 certificates by
reference are defined in [I-D.ietf-cose-x509] and reference are defined in [I-D.ietf-cose-x509] and
[I-D.ietf-cose-cbor-encoded-cert]: [I-D.ietf-cose-cbor-encoded-cert]:
* by a hash value with the 'x5t' or 'c5t' parameters, respectively: * by a hash value with the 'x5t' or 'c5t' parameters, respectively:
- ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, - ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
- ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R; - ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R;
skipping to change at page 73, line 25 skipping to change at page 74, line 34
server does not send any such indicator, as responses are matched to server does not send any such indicator, as responses are matched to
request by the client-server protocol design. request by the client-server protocol design.
Protocols that do not provide any correlation at all can prescribe Protocols that do not provide any correlation at all can prescribe
prepending of the peer's chosen C_x to all messages. prepending of the peer's chosen C_x to all messages.
Appendix G. Change Log Appendix G. Change Log
RFC Editor: Please remove this appendix. RFC Editor: Please remove this appendix.
* From -11 to -12:
- Clarified applicability to KEMs
- Clarified use of COSE header parameters
- Updates on MTI
- Updated security considerations
- New section on PQC
- Removed duplicate definition of cipher suites
- Explanations of use of COSE moved to Appendix C.3
- Updated internal references
* From -10 to -11: * From -10 to -11:
- Restructured section on authentication parameters - Restructured section on authentication parameters
- Changed UCCS to CCS - Changed UCCS to CCS
- Changed names and description of COSE header parameters for - Changed names and description of COSE header parameters for
CWT/CCS CWT/CCS
- Changed several of the KDF and Exporter labels - Changed several of the KDF and Exporter labels
skipping to change at page 78, line 4 skipping to change at page 79, line 28
- New section 1.2 Use of EDHOC - New section 1.2 Use of EDHOC
- Clarification of identities - Clarification of identities
- New section 4.3 clarifying bstr_identifier - New section 4.3 clarifying bstr_identifier
- Updated security considerations - Updated security considerations
- Updated text on cipher suite negotiation and key confirmation - Updated text on cipher suite negotiation and key confirmation
- Test vector for static DH o
- Test vector for static DH
* From -00 to -01: * From -00 to -01:
- Removed PSK method - Removed PSK method
- Removed references to certificate by value - Removed references to certificate by value
Acknowledgments Acknowledgments
The authors want to thank Christian Amsuess, Alessandro Bruni, The authors want to thank Christian Amsuess, Alessandro Bruni,
 End of changes. 102 change blocks. 
282 lines changed or deleted 331 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/