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