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