idnits 2.17.1 draft-ietf-lake-edhoc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 02, 2020) is 1363 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 1223 -- Looks like a reference, but probably isn't: '6' on line 1223 -- Looks like a reference, but probably isn't: '7' on line 1223 -- Looks like a reference, but probably isn't: '9' on line 1219 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-10 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-06 ** Downref: Normative reference to an Informational draft: draft-ietf-lake-reqs (ref. 'I-D.ietf-lake-reqs') ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 6090 ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) ** Downref: Normative reference to an Informational RFC: RFC 8376 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-11 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-25 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-security-protocol-comparison-04 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-01 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Selander 3 Internet-Draft J. Mattsson 4 Intended status: Standards Track F. Palombini 5 Expires: February 3, 2021 Ericsson AB 6 August 02, 2020 8 Ephemeral Diffie-Hellman Over COSE (EDHOC) 9 draft-ietf-lake-edhoc-01 11 Abstract 13 This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a 14 very compact, and lightweight authenticated Diffie-Hellman key 15 exchange with ephemeral keys. EDHOC provides mutual authentication, 16 perfect forward secrecy, and identity protection. EDHOC is intended 17 for usage in constrained scenarios and a main use case is to 18 establish an OSCORE security context. By reusing COSE for 19 cryptography, CBOR for encoding, and CoAP for transport, the 20 additional code footprint can be kept very low. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 3, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Rationale for EDHOC . . . . . . . . . . . . . . . . . . . 4 58 1.2. Terminology and Requirements Language . . . . . . . . . . 5 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Transport and Message Correlation . . . . . . . . . . . . 8 62 3.2. Authentication Keys and Identities . . . . . . . . . . . 9 63 3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 10 65 3.5. Communication/Negotiation of Protocol Features . . . . . 11 66 3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 12 67 3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 12 68 3.8. Key Derivation . . . . . . . . . . . . . . . . . . . . . 12 69 4. EDHOC Authenticated with Asymmetric Keys . . . . . . . . . . 15 70 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 17 72 4.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 19 73 4.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 22 74 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25 75 5.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 25 76 6. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 27 77 6.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 27 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 79 7.1. Security Properties . . . . . . . . . . . . . . . . . . . 30 80 7.2. Cryptographic Considerations . . . . . . . . . . . . . . 31 81 7.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 32 82 7.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 32 83 7.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 32 84 7.6. Implementation Considerations . . . . . . . . . . . . . . 33 85 7.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 34 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 87 8.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 34 88 8.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 35 89 8.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 35 90 8.4. Media Types Registry . . . . . . . . . . . . . . . . . . 36 91 8.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 37 92 8.6. Expert Review Instructions . . . . . . . . . . . . . . . 37 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 95 9.2. Informative References . . . . . . . . . . . . . . . . . 39 96 Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 42 97 A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 42 98 A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 43 99 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 43 100 B.1. Test Vectors for EDHOC Authenticated with Signature Keys 101 (x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 43 102 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 105 1. Introduction 107 Security at the application layer provides an attractive option for 108 protecting Internet of Things (IoT) deployments, for example where 109 transport layer security is not sufficient 110 [I-D.hartke-core-e2e-security-reqs] or where the protection needs to 111 work over a variety of underlying protocols. IoT devices may be 112 constrained in various ways, including memory, storage, processing 113 capacity, and energy [RFC7228]. A method for protecting individual 114 messages at the application layer suitable for constrained devices, 115 is provided by CBOR Object Signing and Encryption (COSE) [RFC8152]), 116 which builds on the Concise Binary Object Representation (CBOR) 117 [RFC7049]. Object Security for Constrained RESTful Environments 118 (OSCORE) [RFC8613] is a method for application-layer protection of 119 the Constrained Application Protocol (CoAP), using COSE. 121 In order for a communication session to provide forward secrecy, the 122 communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH) 123 key exchange protocol with ephemeral keys, from which shared key 124 material can be derived. This document specifies Ephemeral Diffie- 125 Hellman Over COSE (EDHOC), a lightweight key exchange protocol 126 providing perfect forward secrecy and identity protection. 127 Authentication is based on credentials established out of band, e.g. 128 from a trusted third party, such as an Authorization Server as 129 specified by [I-D.ietf-ace-oauth-authz]. The construction provided 130 by EDHOC can be applied to authenticate raw public keys (RPK) and 131 public key certificates. This version of the protocol is focusing on 132 RPK and certificates by reference which is the initial focus for the 133 LAKE WG (see Section 2.2 of [I-D.ietf-lake-reqs]). 135 After successful completion of the EDHOC protocol, application keys 136 and other application specific data can be derived using the EDHOC- 137 Exporter interface. A main use case for EDHOC is to establish an 138 OSCORE security context. EDHOC uses COSE for cryptography, CBOR for 139 encoding, and CoAP for transport. By reusing existing libraries, the 140 additional code footprint can be kept very low. Note that this 141 document focuses on authentication and key establishment: for 142 integration with authorization of resource access, refer to 143 [I-D.ietf-ace-oscore-profile]. 145 EDHOC is designed for highly constrained settings making it 146 especially suitable for low-power wide area networks [RFC8376] such 147 as Cellular IoT, 6TiSCH, and LoRaWAN. Compared to the DTLS 1.3 148 handshake [I-D.ietf-tls-dtls13] with ECDH and connection ID, the 149 number of bytes in EDHOC + CoAP can be less than 1/6 when RPK 150 authentication is used, see 151 [I-D.ietf-lwig-security-protocol-comparison]. Figure 1 shows two 152 examples of message sizes for EDHOC with different kinds of 153 authentication keys and different COSE header parameters for 154 identification: static Diffie-Hellman keys identified by 'kid' 155 [RFC8152], and X.509 signature certificates identified by a hash 156 value using 'x5t' [I-D.ietf-cose-x509]. Further reductions of 157 message sizes are possible, for example by eliding redundant length 158 indications. 160 ================================= 161 kid x5t 162 --------------------------------- 163 message_1 37 37 164 message_2 46 117 165 message_3 20 91 166 ---------------------------------- 167 Total 103 245 168 ================================= 170 Figure 1: Example of message sizes in bytes. 172 The ECDH exchange and the key derivation follow known protocol 173 constructions such as [SIGMA], NIST SP-800-56A [SP-800-56A], and HKDF 174 [RFC5869]. CBOR [RFC7049] and COSE [RFC8152] are used to implement 175 these standards. The use of COSE provides crypto agility and enables 176 use of future algorithms and headers designed for constrained IoT. 178 This document is organized as follows: Section 2 describes how EDHOC 179 authenticated with digital signatures builds on SIGMA-I, Section 3 180 specifies general properties of EDHOC, including message flow, 181 formatting of the ephemeral public keys, and key derivation, 182 Section 4 specifies EDHOC with signature key and static Diffie- 183 Hellman key authentication, Section 5 specifies the EDHOC error 184 message, and Section 6 describes how EDHOC can be transferred in CoAP 185 and used to establish an OSCORE security context. 187 1.1. Rationale for EDHOC 189 Many constrained IoT systems today do not use any security at all, 190 and when they do, they often do not follow best practices. One 191 reason is that many current security protocols are not designed with 192 constrained IoT in mind. Constrained IoT systems often deal with 193 personal information, valuable business data, and actuators 194 interacting with the physical world. Not only do such systems need 195 security and privacy, they often need end-to-end protection with 196 source authentication and perfect forward secrecy. EDHOC and OSCORE 197 [RFC8613] enables security following current best practices to 198 devices and systems where current security protocols are impractical. 200 EDHOC is optimized for small message sizes and can therefore be sent 201 over a small number of radio frames. The message size of a key 202 exchange protocol may have a large impact on the performance of an 203 IoT deployment, especially in constrained environments. For example, 204 in a network bootstrapping setting a large number of devices turned 205 on in a short period of time may result in large latencies caused by 206 parallel key exchanges. Requirements on network formation time in 207 constrained environments can be translated into key exchange 208 overhead. In network technologies with duty cycle, each additional 209 frame significantly increases the latency even if no other devices 210 are transmitting. 212 Power consumption for wireless devices is highly dependent on message 213 transmission, listening, and reception. For devices that only send a 214 few bytes occasionally, the battery lifetime may be impacted by a 215 heavy key exchange protocol. A key exchange may need to be executed 216 more than once, e.g. due to a device rebooting or for security 217 reasons such as perfect forward secrecy. 219 EDHOC is adapted to primitives and protocols designed for the 220 Internet of Things: EDHOC is built on CBOR and COSE which enables 221 small message overhead and efficient parsing in constrained devices. 222 EDHOC is not bound to a particular transport layer, but it is 223 recommended to transport the EDHOC message in CoAP payloads. EDHOC 224 is not bound to a particular communication security protocol but 225 works off-the-shelf with OSCORE [RFC8613] providing the necessary 226 input parameters with required properties. Maximum code complexity 227 (ROM/Flash) is often a constraint in many devices and by reusing 228 already existing libraries, the additional code footprint for EDHOC + 229 OSCORE can be kept very low. 231 1.2. Terminology and Requirements Language 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 235 "OPTIONAL" in this document are to be interpreted as described in BCP 236 14 [RFC2119] [RFC8174] when, and only when, they appear in all 237 capitals, as shown here. 239 Readers are expected to be familiar with the terms and concepts 240 described in CBOR [RFC7049], CBOR Sequences [RFC8742], COSE 242 [RFC8152], and CDDL [RFC8610]. The Concise Data Definition Language 243 (CDDL) is used to express CBOR data structures [RFC7049]. Examples 244 of CBOR and CDDL are provided in Appendix A.1. 246 2. Background 248 EDHOC specifies different authentication methods of the Diffie- 249 Hellman key exchange: digital signatures and static Diffie-Hellman 250 keys. This section outlines the digital signature based method. 252 SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a 253 large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS 254 1.3 [RFC8446], EDHOC authenticated with digital signatures is built 255 on a variant of the SIGMA protocol which provide identity protection 256 of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC 257 implements the SIGMA-I variant as Mac-then-Sign. The SIGMA-I 258 protocol using an authenticated encryption algorithm is shown in 259 Figure 2. 261 Initiator Responder 262 | G_X | 263 +-------------------------------------------------------->| 264 | | 265 | G_Y, AEAD( K_2; ID_CRED_R, Sig(R; CRED_R, G_X, G_Y) ) | 266 |<--------------------------------------------------------+ 267 | | 268 | AEAD( K_3; ID_CRED_I, Sig(I; CRED_I, G_Y, G_X) ) | 269 +-------------------------------------------------------->| 270 | | 272 Figure 2: Authenticated encryption variant of the SIGMA-I protocol. 274 The parties exchanging messages are called Initiator (I) and 275 Responder (R). They exchange ephemeral public keys, compute the 276 shared secret, and derive symmetric application keys. 278 o G_X and G_Y are the ECDH ephemeral public keys of I and R, 279 respectively. 281 o CRED_I and CRED_R are the credentials containing the public 282 authentication keys of I and R, respectively. 284 o ID_CRED_I and ID_CRED_R are data enabling the recipient party to 285 retrieve the credential of I and R, respectively. 287 o Sig(I; . ) and S(R; . ) denote signatures made with the private 288 authentication key of I and R, respectively. 290 o AEAD(K; . ) denotes authenticated encryption with additional data 291 using a key K derived from the shared secret. 293 In order to create a "full-fledged" protocol some additional protocol 294 elements are needed. EDHOC adds: 296 o Explicit connection identifiers C_I, C_R chosen by I and R, 297 respectively, enabling the recipient to find the protocol state. 299 o Transcript hashes (hashes of message data) TH_2, TH_3, TH_4 used 300 for key derivation and as additional authenticated data. 302 o Computationally independent keys derived from the ECDH shared 303 secret and used for authenticated encryption of different 304 messages. 306 o Verification of a common preferred cipher suite: 308 * The Initiator lists supported cipher suites in order of 309 preference 311 * The Responder verifies that the selected cipher suite is the 312 first supported cipher suite 314 o Method types and error handling. 316 o Transport of opaque auxiliary data. 318 EDHOC is designed to encrypt and integrity protect as much 319 information as possible, and all symmetric keys are derived using as 320 much previous information as possible. EDHOC is furthermore designed 321 to be as compact and lightweight as possible, in terms of message 322 sizes, processing, and the ability to reuse already existing CBOR, 323 COSE, and CoAP libraries. 325 To simplify for implementors, the use of CBOR in EDHOC is summarized 326 in Appendix A and test vectors including CBOR diagnostic notation are 327 given in Appendix B. 329 3. EDHOC Overview 331 EDHOC consists of three messages (message_1, message_2, message_3) 332 that maps directly to the three messages in SIGMA-I, plus an EDHOC 333 error message. EDHOC messages are CBOR Sequences [RFC8742], where 334 the first data item (METHOD_CORR) of message_1 is an int specifying 335 the method and the correlation properties of the transport used, see 336 Section 3.1. The method specifies the authentication methods used 337 (signature, static DH), see Section 8.2. An implementation may 338 support only Initiator or Responder. An implementation may support 339 only a single method. The Initiator and the Responder need to have 340 agreed on a single method to be used for EDHOC. 342 While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0 343 structures, only a subset of the parameters is included in the EDHOC 344 messages. The unprotected COSE header in COSE_Sign1, and 345 COSE_Encrypt0 (not included in the EDHOC message) MAY contain 346 parameters (e.g. 'alg'). After creating EDHOC message_3, the 347 Initiator can derive symmetric application keys, and application 348 protected data can therefore be sent in parallel with EDHOC 349 message_3. The application may protect data using the algorithms 350 (AEAD, hash, etc.) in the selected cipher suite and the connection 351 identifiers (C_I, C_R). EDHOC may be used with the media type 352 application/edhoc defined in Section 8. 354 Initiator Responder 355 | | 356 | ------------------ EDHOC message_1 -----------------> | 357 | | 358 | <----------------- EDHOC message_2 ------------------ | 359 | | 360 | ------------------ EDHOC message_3 -----------------> | 361 | | 362 | <----------- Application Protected Data ------------> | 363 | | 365 Figure 3: EDHOC message flow 367 3.1. Transport and Message Correlation 369 Cryptographically, EDHOC does not put requirements on the lower 370 layers. EDHOC is not bound to a particular transport layer, and can 371 be used in environments without IP. The transport is responsible to 372 handle message loss, reordering, message duplication, fragmentation, 373 and denial of service protection, where necessary. The Initiator and 374 the Responder need to have agreed on a transport to be used for 375 EDHOC. It is recommended to transport EDHOC in CoAP payloads, see 376 Section 6. 378 EDHOC includes connection identifiers (C_I, C_R) to correlate 379 messages. The connection identifiers C_I and C_R do not have any 380 cryptographic purpose in EDHOC. They contain information 381 facilitating retrieval of the protocol state and may therefore be 382 very short. The connection identifier MAY be used with an 383 application protocol (e.g. OSCORE) for which EDHOC establishes keys, 384 in which case the connection identifiers SHALL adhere to the 385 requirements for that protocol. Each party choses a connection 386 identifier it desires the other party to use in outgoing messages. 388 If the transport provides a mechanism for correlating messages, some 389 of the connection identifiers may be omitted. There are four cases: 391 o corr = 0, the transport does not provide a correlation mechanism. 393 o corr = 1, the transport provides a correlation mechanism that 394 enables the Responder to correlate message_2 and message_1. 396 o corr = 2, the transport provides a correlation mechanism that 397 enables the Initiator to correlate message_3 and message_2. 399 o corr = 3, the transport provides a correlation mechanism that 400 enables both parties to correlate all three messages. 402 For example, if the key exchange is transported over CoAP, the CoAP 403 Token can be used to correlate messages, see Section 6.1. 405 3.2. Authentication Keys and Identities 407 The EDHOC message exchange may be authenticated using raw public keys 408 (RPK) or public key certificates. The certificates and RPKs can 409 contain signature keys or static Diffie-Hellman keys. In X.509 410 certificates, signature keys typically have key usage 411 "digitalSignature" and Diffie-Hellman keys typically have key usage 412 "keyAgreement". EDHOC assumes the existence of mechanisms 413 (certification authority, trusted third party, manual distribution, 414 etc.) for distributing authentication keys and identities. Policies 415 are set based on the identity of the other party, and parties 416 typically only allow connections from a small restricted set of 417 identities. 419 o When a Public Key Infrastructure (PKI) is used, the trust anchor 420 is a Certification Authority (CA) certificate, and the identity is 421 the subject whose unique name (e.g. a domain name, NAI, or EUI) is 422 included in the other party's certificate. Before running EDHOC 423 each party needs at least one CA public key certificate, or just 424 the public key, and a set of identities it is allowed to 425 communicate with. Any validated public-key certificate with an 426 allowed subject name is accepted. EDHOC provides proof that the 427 other party possesses the private authentication key corresponding 428 to the public authentication key in its certificate. The 429 certification path provides proof that the subject of the 430 certificate owns the public key in the certificate. 432 o When public keys are used but not with a PKI (RPK, self-signed 433 certificate), the trust anchor is the public authentication key of 434 the other party. In this case, the identity is typically directly 435 associated to the public authentication key of the other party. 436 For example, the name of the subject may be a canonical 437 representation of the public key. Alternatively, if identities 438 can be expressed in the form of unique subject names assigned to 439 public keys, then a binding to identity can be achieved by 440 including both public key and associated subject name in the 441 protocol message computation: CRED_I or CRED_R may be a self- 442 signed certificate or COSE_Key containing the public 443 authentication key and the subject name, see Figure 2. Before 444 running EDHOC, each party need a set of public authentication 445 keys/unique associated subject names it is allowed to communicate 446 with. EDHOC provides proof that the other party possesses the 447 private authentication key corresponding to the public 448 authentication key. 450 3.3. Identifiers 452 One byte connection and credential identifiers are realistic in many 453 scenarios as most constrained devices only have a few keys and 454 connections. In cases where a node only has one connection or key, 455 the identifiers may even be the empty byte string. 457 3.4. Cipher Suites 459 EDHOC cipher suites consist of an ordered set of COSE algorithms: an 460 EDHOC AEAD algorithm, an EDHOC hash algorithm, an EDHOC ECDH curve, 461 an EDHOC signature algorithm, an EDHOC signature algorithm curve, an 462 application AEAD algorithm, and an application hash algorithm from 463 the COSE Algorithms and Elliptic Curves registries. Each cipher 464 suite is identified with a pre-defined int label. This document 465 specifies four pre-defined cipher suites. 467 0. ( 10, -16, 4, -8, 6, 10, -16 ) 468 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519, 469 AES-CCM-16-64-128, SHA-256) 471 1. ( 30, -16, 4, -8, 6, 10, -16 ) 472 (AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519, 473 AES-CCM-16-64-128, SHA-256) 475 2. ( 10, -16, 1, -7, 1, 10, -16 ) 476 (AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256, 477 AES-CCM-16-64-128, SHA-256) 479 3. ( 30, -16, 1, -7, 1, 10, -16 ) 480 (AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256, 481 AES-CCM-16-64-128, SHA-256) 483 The different methods use the same cipher suites, but some algorithms 484 are not used in some methods. The EDHOC signature algorithm and the 485 EDHOC signature algorithm curve are not used is methods without 486 signature authentication. 488 The Initiator need to have a list of cipher suites it supports in 489 order of preference. The Responder need to have a list of cipher 490 suites it supports. 492 3.5. Communication/Negotiation of Protocol Features 494 EDHOC allows the communication or negotiation of various protocol 495 features during the execution of the protocol. 497 o The Initiator proposes a cipher suite (see Section 3.4), and the 498 Responder either accepts or rejects, and may make a counter 499 proposal. 501 o The Initiator decides on the correlation parameter corr (see 502 Section 3.1). This is typically given by the transport which the 503 Initiator and the Responder have agreed on beforehand. The 504 Responder either accepts or rejects. 506 o The Initiator decides on the method parameter, see Section 8.2. 507 The Responder either accepts or rejects. 509 o The Initiator and the Responder decide on the representation of 510 the identifier of their respective credentials, ID_CRED_I and 511 ID_CRED_R. The decision is reflected by the label used in the 512 CBOR map, see for example Section 4.1. 514 3.6. Auxiliary Data 516 In order to reduce round trips and number of messages, and in some 517 cases also streamline processing, certain security applications may 518 be integrated into EDHOC by transporting auxiliary data together with 519 the messages. One example is the transport of third-party 520 authorization information protected outside of EDHOC 521 [I-D.selander-ace-ake-authz]. Another example is the embedding of a 522 certificate enrolment request or a newly issued certificate. 524 EDHOC allows opaque auxiliary data (AD) to be sent in the EDHOC 525 messages. Unprotected Auxiliary Data (AD_1, AD_2) may be sent in 526 message_1 and message_2, respectively. Protected Auxiliary Data 527 (AD_3) may be sent in message_3. 529 Since data carried in AD1 and AD2 may not be protected, and the 530 content of AD3 is available to both the Initiator and the Responder, 531 special considerations need to be made such that the availability of 532 the data a) does not violate security and privacy requirements of the 533 service which uses this data, and b) does not violate the security 534 properties of EDHOC. 536 3.7. Ephemeral Public Keys 538 The ECDH ephemeral public keys are formatted as a COSE_Key of type 539 EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only 540 the 'x' parameter is included in the EDHOC messages. For Elliptic 541 Curve Keys of type EC2, compact representation as per [RFC6090] MAY 542 be used also in the COSE_Key. If the COSE implementation requires an 543 'y' parameter, any of the possible values of the y-coordinate can be 544 used, see Appendix C of [RFC6090]. COSE [RFC8152] always use compact 545 output for Elliptic Curve Keys of type EC2. 547 3.8. Key Derivation 549 EDHOC uses HKDF [RFC5869] with the EDHOC hash algorithm in the 550 selected cipher suite to derive keys. HKDF-Extract is used to derive 551 fixed-length uniformly pseudorandom keys (PRK) from ECDH shared 552 secrets. HKDF-Expand is used to derive additional output keying 553 material (OKM) from the PRKs. The PRKs are derived using HKDF- 554 Extract [RFC5869]. 556 PRK = HKDF-Extract( salt, IKM ) 558 PRK_2e is used to derive key and IV to encrypt message_2. PRK_3e2m 559 is used to derive keys and IVs produce a MAC in message_2 and to 560 encrypt message_3. PRK_4x3m is used to derive keys and IVs produce a 561 MAC in message_3 and to derive application specific data. 563 PRK_2e is derived with the following input: 565 o The salt SHALL be the empty byte string. Note that [RFC5869] 566 specifies that if the salt is not provided, it is set to a string 567 of zeros (see Section 2.2 of [RFC5869]). For implementation 568 purposes, not providing the salt is the same as setting the salt 569 to the empty byte string. 571 o The input keying material (IKM) SHALL be the ECDH shared secret 572 G_XY (calculated from G_X and Y or G_Y and X) as defined in 573 Section 12.4.1 of [RFC8152]. 575 Example: Assuming the use of SHA-256 the extract phase of HKDF 576 produces PRK_2e as follows: 578 PRK_2e = HMAC-SHA-256( salt, G_XY ) 580 where salt = 0x (the empty byte string). 582 The pseudorandom keys PRK_3e2m and PRK_4x3m are defined as follow: 584 o If the Reponder authenticates with a static Diffie-Hellman key, 585 then PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX is the 586 ECDH shared secret calculated from G_R and X, or G_X and R, else 587 PRK_3e2m = PRK_2e. 589 o If the Initiator authenticates with a static Diffie-Hellman key, 590 then PRK_4x3m = HKDF-Extract( PRK_3e2m, G_IY ), where G_IY is the 591 ECDH shared secret calculated from G_I and Y, or G_Y and I, else 592 PRK_4x3m = PRK_3e2m. 594 Example: Assuming the use of curve25519, the ECDH shared secrets 595 G_XY, G_RX, and G_IY are the outputs of the X25519 function 596 [RFC7748]: 598 G_XY = X25519( Y, G_X ) = X25519( X, G_Y ) 600 The keys and IVs used in EDHOC are derived from PRK using HKDF-Expand 601 [RFC5869] where the EDHOC-KDF is instantiated with the EDHOC AEAD 602 algorithm in the selected cipher suite. 604 OKM = EDHOC-KDF( PRK, transcript_hash, label, length ) 605 = HKDF-Expand( PRK, info, length ) 607 where info is the CBOR encoding of 608 info = [ 609 edhoc_aead_id : int / tstr, 610 transcript_hash : bstr, 611 label : tstr, 612 length : uint 613 ] 615 where 617 o edhoc_aead_id is an int or tstr containing the algorithm 618 identifier of the EDHOC AEAD algorithm in the selected cipher 619 suite encoded as defined in [RFC8152]. Note that a single fixed 620 edhoc_aead_id is used in all invocations of EDHOC-KDF, including 621 the derivation of K_2e and invocations of the EDHOC-Exporter. 623 o transcript_hash is a bstr set to one of the transcript hashes 624 TH_2, TH_3, or TH_4 as defined in Sections 4.3.1, 4.4.1, and 625 3.8.1. 627 o label is a tstr set to the name of the derived key or IV, i.e. 628 "K_2m", "IV_2m", "K_2e", "K_3m", "IV_3m", "K_3ae", or "IV_3ae". 630 o length is the length of output keying material (OKM) in bytes 632 K_2m and IV_2m are derived using the transcript hash TH_2 and the 633 pseudorandom key PRK_3e2m. K_3ae and IV_3ae are derived using the 634 transcript hash TH_3 and the pseudorandom key PRK_3e2m. K_3m and 635 IV_3m are derived using the transcript hash TH_3 and the pseudorandom 636 key PRK_4x3m. IVs are only used if the EDHOC AEAD algorithm uses 637 IVs. 639 3.8.1. EDHOC-Exporter Interface 641 Application keys and other application specific data can be derived 642 using the EDHOC-Exporter interface defined as: 644 EDHOC-Exporter(label, length) 645 = EDHOC-KDF(PRK_4x3m, TH_4, label, length) 647 where label is a tstr defined by the application and length is a uint 648 defined by the application. The label SHALL be different for each 649 different exporter value. The transcript hash TH_4 is a CBOR encoded 650 bstr and the input to the hash function is a CBOR Sequence. 652 TH_4 = H( TH_3, CIPHERTEXT_3 ) 654 where H() is the hash function in the selected cipher suite. Example 655 use of the EDHOC-Exporter is given in Sections 6.1.1. 657 4. EDHOC Authenticated with Asymmetric Keys 659 4.1. Overview 661 This section specifies authentication method = 0, 1, 2, and 3, see 662 Section 8.2. EDHOC supports authentication with signature or static 663 Diffie-Hellman keys in the form of raw public keys (RPK) and public 664 key certificates with the requirements that: 666 o Only the Responder SHALL have access to the Responder's private 667 authentication key, 669 o Only the Initiator SHALL have access to the Initiator's private 670 authentication key, 672 o The Initiator is able to retrieve the Responder's public 673 authentication key using ID_CRED_R, 675 o The Responder is able to retrieve the Initiator's public 676 authentication key using ID_CRED_I, 678 where the identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, 679 i.e. CBOR maps containing COSE Common Header Parameters, see 680 Section 3.1 of [RFC8152]). ID_CRED_I and ID_CRED_R need to contain 681 parameters that can identify a public authentication key. In the 682 following paragraph we give some examples of possible COSE header 683 parameters used. 685 Raw public keys are most optimally stored as COSE_Key objects and 686 identified with a 'kid' parameter: 688 o ID_CRED_x = { 4 : kid_x }, where kid_x : bstr, for x = I or R. 690 Public key certificates can be identified in different ways. Header 691 parameters for identifying X.509 certificates are defined in 692 [I-D.ietf-cose-x509], for example: 694 o by a hash value with the 'x5t' parameter; 696 * ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, 698 o by a URL with the 'x5u' parameter; 700 * ID_CRED_x = { 35 : uri }, for x = I or R, 702 The purpose of ID_CRED_I and ID_CRED_R is to facilitate retrieval of 703 a public authentication key and when they do not contain the actual 704 credential, they may be very short. ID_CRED_I and ID_CRED_R MAY 705 contain the actual credential used for authentication. It is 706 RECOMMENDED that they uniquely identify the public authentication key 707 as the recipient may otherwise have to try several keys. ID_CRED_I 708 and ID_CRED_R are transported in the ciphertext, see Section 4.3.2 709 and Section 4.4.2. 711 The authentication key MUST be a signature key or static Diffie- 712 Hellman key. The Initiator and the Responder MAY use different types 713 of authentication keys, e.g. one uses a signature key and the other 714 uses a static Diffie-Hellman key. When using a signature key, the 715 authentication is provided by a signature. When using a static 716 Diffie-Hellman key the authentication is provided by a Message 717 Authentication Code (MAC) computed from an ephemeral-static ECDH 718 shared secret which enables significant reductions in message sizes. 719 The MAC is implemented with an AEAD algorithm. When using a static 720 Diffie-Hellman keys the Initiator's and Responder's private 721 authentication keys are called I and R, respectively, and the public 722 authentication keys are called G_I and G_R, respectively. 724 The actual credentials CRED_I and CRED_R are signed or MAC:ed by the 725 Initiator and the Responder respectively, see Section 4.4.1 and 726 Section 4.3.1. The Initiator and the Responder MAY use different 727 types of credentials, e.g. one uses RPK and the other uses 728 certificate. When the credential is a certificate, CRED_x is end- 729 entity certificate (i.e. not the certificate chain) encoded as a CBOR 730 bstr. When the credential is a COSE_Key, CRED_x is a CBOR map only 731 contains specific fields from the COSE_Key. For COSE_Keys of type 732 OKP the CBOR map SHALL only include the parameters 1 (kty), -1 (crv), 733 and -2 (x-coordinate). For COSE_Keys of type EC2 the CBOR map SHALL 734 only include the parameters 1 (kty), -1 (crv), -2 (x-coordinate), and 735 -3 (y-coordinate). If the parties have agreed on an identity besides 736 the public key, the indentity is included in the CBOR map with the 737 label "subject name", otherwise the subject name is the empty text 738 string. The parameters SHALL be encoded in decreasing order with int 739 labels first and text string labels last. An example of CRED_x when 740 the RPK contains an X25519 static Diffie-Hellman key and the parties 741 have agreed on an EUI-64 identity is shown below: 743 CRED_x = { 744 1: 1, 745 -1: 4, 746 -2: h'b1a3e89460e88d3a8d54211dc95f0b90 747 3ff205eb71912d6db8f4af980d2db83a', 748 "subject name" : "42-50-31-FF-EF-37-32-39" 749 } 750 Initiator Responder 751 | METHOD_CORR, SUITES_I, G_X, C_I, AD_1 | 752 +------------------------------------------------------------------>| 753 | message_1 | 754 | | 755 | C_I, G_Y, C_R, Enc(K_2e; ID_CRED_R, Signature_or_MAC_2, AD_2) | 756 |<------------------------------------------------------------------+ 757 | message_2 | 758 | | 759 | C_R, AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, AD_3) | 760 +------------------------------------------------------------------>| 761 | message_3 | 763 Figure 4: Overview of EDHOC with asymmetric key authentication. 765 4.2. EDHOC Message 1 767 4.2.1. Formatting of Message 1 769 message_1 SHALL be a CBOR Sequence (see Appendix A.1) as defined 770 below 772 message_1 = ( 773 METHOD_CORR : int, 774 SUITES_I : [ selected : suite, supported : 2* suite ] / suite, 775 G_X : bstr, 776 C_I : bstr_identifier, 777 ? AD_1 : bstr, 778 ) 780 suite = int 781 bstr_identifier = bstr / int 783 where: 785 o METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see 786 Section 8.2) and the correlation parameter corr is chosen based on 787 the transport and determines which connection identifiers that are 788 omitted (see Section 3.1). 790 o SUITES_I - cipher suites which the Initiator supports in order of 791 (decreasing) preference. The list of supported cipher suites can 792 be truncated at the end, as is detailed in the processing steps 793 below. One of the supported cipher suites is selected. If a 794 single supported cipher suite is conveyed then that cipher suite 795 is selected and the selected cipher suite is encoded as an int 796 instead of an array. 798 o G_X - the ephemeral public key of the Initiator 800 o C_I - variable length connection identifier. An bstr_identifier 801 is a byte string with special encoding. Byte strings of length 802 one is encoded as the corresponding integer - 24, i.e. h'2a' is 803 encoded as 18. 805 o AD_1 - bstr containing unprotected opaque auxiliary data 807 4.2.2. Initiator Processing of Message 1 809 The Initiator SHALL compose message_1 as follows: 811 o The supported cipher suites and the order of preference MUST NOT 812 be changed based on previous error messages. However, the list 813 SUITES_I sent to the Responder MAY be truncated such that cipher 814 suites which are the least preferred are omitted. The amount of 815 truncation MAY be changed between sessions, e.g. based on previous 816 error messages (see next bullet), but all cipher suites which are 817 more preferred than the least preferred cipher suite in the list 818 MUST be included in the list. 820 o Determine the cipher suite to use with the Responder in message_1. 821 If the Initiator previously received from the Responder an error 822 message to a message_1 with diagnostic payload identifying a 823 cipher suite that the Initiator supports, then the Initiator SHALL 824 use that cipher suite. Otherwise the first supported (i.e. the 825 most preferred) cipher suite in SUITES_I MUST be used. 827 o Generate an ephemeral ECDH key pair as specified in Section 5 of 828 [SP-800-56A] using the curve in the selected cipher suite and 829 format it as a COSE_Key. Let G_X be the 'x' parameter of the 830 COSE_Key. 832 o Choose a connection identifier C_I and store it for the length of 833 the protocol. 835 o Encode message_1 as a sequence of CBOR encoded data items as 836 specified in Section 4.2.1 838 4.2.3. Responder Processing of Message 1 840 The Responder SHALL process message_1 as follows: 842 o Decode message_1 (see Appendix A.1). 844 o Verify that the selected cipher suite is supported and that no 845 prior cipher suites in SUITES_I are supported. 847 o Pass AD_1 to the security application. 849 If any verification step fails, the Initiator MUST send an EDHOC 850 error message back, formatted as defined in Section 5, and the 851 protocol MUST be discontinued. If V does not support the selected 852 cipher suite, then SUITES_R MUST include one or more supported cipher 853 suites. If the Responder does not support the selected cipher suite, 854 but supports another cipher suite in SUITES_I, then SUITES_R MUST 855 include the first supported cipher suite in SUITES_I. 857 4.3. EDHOC Message 2 859 4.3.1. Formatting of Message 2 861 message_2 and data_2 SHALL be CBOR Sequences (see Appendix A.1) as 862 defined below 864 message_2 = ( 865 data_2, 866 CIPHERTEXT_2 : bstr, 867 ) 869 data_2 = ( 870 ? C_I : bstr_identifier, 871 G_Y : bstr, 872 C_R : bstr_identifier, 873 ) 875 where: 877 o G_Y - the ephemeral public key of the Responder 879 o C_R - variable length connection identifier 881 4.3.2. Responder Processing of Message 2 883 The Responder SHALL compose message_2 as follows: 885 o If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted, 886 otherwise C_I is not omitted. 888 o Generate an ephemeral ECDH key pair as specified in Section 5 of 889 [SP-800-56A] using the curve in the selected cipher suite and 890 format it as a COSE_Key. Let G_Y be the 'x' parameter of the 891 COSE_Key. 893 o Choose a connection identifier C_R and store it for the length of 894 the protocol. 896 o Compute the transcript hash TH_2 = H(message_1, data_2) where H() 897 is the hash function in the selected cipher suite. The transcript 898 hash TH_2 is a CBOR encoded bstr and the input to the hash 899 function is a CBOR Sequence. 901 o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of 902 [RFC8152], with the EDHOC AEAD algorithm in the selected cipher 903 suite, K_2m, IV_2m, and the following parameters: 905 * protected = << ID_CRED_R >> 907 + ID_CRED_R - identifier to facilitate retrieval of CRED_R, 908 see Section 4.1 910 * external_aad = << TH_2, CRED_R, ? AD_2 >> 912 + CRED_R - bstr containing the credential of the Responder, 913 see Section 4.1. 915 + AD_2 = bstr containing opaque unprotected auxiliary data 917 * plaintext = h'' 919 COSE constructs the input to the AEAD [RFC5116] as follows: 921 * Key K = EDHOC-KDF( PRK_3e2m, TH_2, "K_2m", length ) 923 * Nonce N = EDHOC-KDF( PRK_3e2m, TH_2, "IV_2m", length ) 925 * Plaintext P = 0x (the empty string) 927 * Associated data A = 929 [ "Encrypt0", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >> ] 931 MAC_2 is the 'ciphertext' of the inner COSE_Encrypt0. 933 o If the Reponder authenticates with a static Diffie-Hellman key 934 (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the 935 Reponder authenticates with a signature key (method equals 0 or 936 2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1 937 object as defined in Section 4.4 of [RFC8152] using the signature 938 algorithm in the selected cipher suite, the private authentication 939 key of the Responder, and the following parameters: 941 * protected = << ID_CRED_R >> 943 * external_aad = << TH_2, CRED_R, ? AD_2 >> 944 * payload = MAC_2 946 COSE constructs the input to the Signature Algorithm as: 948 * The key is the private authentication key of the Responder. 950 * The message M to be signed = 952 [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >>, 953 MAC_2 ] 955 o CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a 956 plaintext with the following common parameters: 958 * plaintext = ( ID_CRED_R / bstr_identifier, Signature_or_MAC_2, 959 ? AD_2 ) 961 + Note that if ID_CRED_R contains a single 'kid' parameter, 962 i.e., ID_CRED_R = { 4 : kid_R }, only the byte string kid_R 963 is conveyed in the plaintext encoded as an bstr_identifier, 964 see Section 4.1. 966 * CIPHERTEXT_2 = plaintext XOR K_2e 968 * K_2e = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length ), where length 969 is the length of the plaintext. 971 o Encode message_2 as a sequence of CBOR encoded data items as 972 specified in Section 4.3.1. 974 4.3.3. Initiator Processing of Message 2 976 The Initiator SHALL process message_2 as follows: 978 o Decode message_2 (see Appendix A.1). 980 o Retrieve the protocol state using the connection identifier C_I 981 and/or other external information such as the CoAP Token and the 982 5-tuple. 984 o Decrypt CIPHERTEXT_2. The decryption process depends on the 985 method, see Section 4.3.2. 987 o Verify that the identity of the Responder is among the allowed 988 identities for this connection. 990 o Verify Signature_or_MAC_2 using the algorithm in the selected 991 cipher suite. The verification process depends on the method, see 992 Section 4.3.2. 994 o Pass AD_2 to the security application. 996 If any verification step fails, the Responder MUST send an EDHOC 997 error message back, formatted as defined in Section 5, and the 998 protocol MUST be discontinued. 1000 4.4. EDHOC Message 3 1002 4.4.1. Formatting of Message 3 1004 message_3 and data_3 SHALL be CBOR Sequences (see Appendix A.1) as 1005 defined below 1007 message_3 = ( 1008 data_3, 1009 CIPHERTEXT_3 : bstr, 1010 ) 1012 data_3 = ( 1013 ? C_R : bstr_identifier, 1014 ) 1016 4.4.2. Initiator Processing of Message 3 1018 The Initiator SHALL compose message_3 as follows: 1020 o If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted, 1021 otherwise C_R is not omitted. 1023 o Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3) 1024 where H() is the hash function in the the selected cipher suite. 1025 The transcript hash TH_3 is a CBOR encoded bstr and the input to 1026 the hash function is a CBOR Sequence. 1028 o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of 1029 [RFC8152], with the EDHOC AEAD algorithm in the selected cipher 1030 suite, K_3m, IV_3m, and the following parameters: 1032 * protected = << ID_CRED_I >> 1034 + ID_CRED_I - identifier to facilitate retrieval of CRED_I, 1035 see Section 4.1 1037 * external_aad = << TH_3, CRED_I, ? AD_3 >> 1038 + CRED_I - bstr containing the credential of the Initiator, 1039 see Section 4.1. 1041 + AD_3 = bstr containing opaque protected auxiliary data 1043 * plaintext = h'' 1045 COSE constructs the input to the AEAD [RFC5116] as follows: 1047 * Key K = EDHOC-KDF( PRK_4x3m, TH_3, "K_3m", length ) 1049 * Nonce N = EDHOC-KDF( PRK_4x3m, TH_3, "IV_3m", length ) 1051 * Plaintext P = 0x (the empty string) 1053 * Associated data A = 1055 [ "Encrypt0", << ID_CRED_I >>, << TH_3, CRED_I, ? AD_3 >> ] 1057 MAC_3 is the 'ciphertext' of the inner COSE_Encrypt0. 1059 o If the Initiator authenticates with a static Diffie-Hellman key 1060 (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3. If the 1061 Initiator authenticates with a signature key (method equals 0 or 1062 1), then Signature_or_MAC_3 is the 'signature' of a COSE_Sign1 1063 object as defined in Section 4.4 of [RFC8152] using the signature 1064 algorithm in the selected cipher suite, the private authentication 1065 key of the Initiator, and the following parameters: 1067 * protected = << ID_CRED_I >> 1069 * external_aad = << TH_3, CRED_I, ? AD_3 >> 1071 * payload = MAC_3 1073 COSE constructs the input to the Signature Algorithm as: 1075 * The key is the private authentication key of the Initiator. 1077 * The message M to be signed = 1079 [ "Signature1", << ID_CRED_I >>, << TH_3, CRED_I, ? AD_3 >>, 1080 MAC_3 ] 1082 o Compute an outer COSE_Encrypt0 as defined in Section 5.3 of 1083 [RFC8152], with the EDHOC AEAD algorithm in the selected cipher 1084 suite, K_3ae, IV_3ae, and the following parameters. The protected 1085 header SHALL be empty. 1087 * external_aad = TH_3 1089 * plaintext = ( ID_CRED_I / bstr_identifier, Signature_or_MAC_3, 1090 ? AD_3 ) 1092 + Note that if ID_CRED_I contains a single 'kid' parameter, 1093 i.e., ID_CRED_I = { 4 : kid_I }, only the byte string kid_I 1094 is conveyed in the plaintext encoded as an bstr_identifier, 1095 see Section 4.1. 1097 COSE constructs the input to the AEAD [RFC5116] as follows: 1099 * Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length ) 1101 * Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length ) 1103 * Plaintext P = ( ID_CRED_I / bstr_identifier, 1104 Signature_or_MAC_3, ? AD_3 ) 1106 * Associated data A = [ "Encrypt0", h'', TH_3 ] 1108 CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0. 1110 o Encode message_3 as a sequence of CBOR encoded data items as 1111 specified in Section 4.4.1. 1113 Pass the connection identifiers (C_I, C_R) and the application 1114 algorithms in the selected cipher suite to the application. The 1115 application can now derive application keys using the EDHOC-Exporter 1116 interface. 1118 4.4.3. Responder Processing of Message 3 1120 The Responder SHALL process message_3 as follows: 1122 o Decode message_3 (see Appendix A.1). 1124 o Retrieve the protocol state using the connection identifier C_R 1125 and/or other external information such as the CoAP Token and the 1126 5-tuple. 1128 o Decrypt and verify the outer COSE_Encrypt0 as defined in 1129 Section 5.3 of [RFC8152], with the EDHOC AEAD algorithm in the 1130 selected cipher suite, K_3ae, and IV_3ae. 1132 o Verify that the identity of the Initiator is among the allowed 1133 identities for this connection. 1135 o Verify Signature_or_MAC_3 using the algorithm in the selected 1136 cipher suite. The verification process depends on the method, see 1137 Section 4.4.2. 1139 o Pass AD_3, the connection identifiers (C_I, C_R), and the 1140 application algorithms in the selected cipher suite to the 1141 security application. The application can now derive application 1142 keys using the EDHOC-Exporter interface. 1144 If any verification step fails, the Responder MUST send an EDHOC 1145 error message back, formatted as defined in Section 5, and the 1146 protocol MUST be discontinued. 1148 5. Error Handling 1150 5.1. EDHOC Error Message 1152 This section defines a message format for the EDHOC error message, 1153 used during the protocol. An EDHOC error message can be sent by both 1154 parties as a reply to any non-error EDHOC message. After sending an 1155 error message, the protocol MUST be discontinued. Errors at the 1156 EDHOC layer are sent as normal successful messages in the lower 1157 layers (e.g. CoAP POST and 2.04 Changed). An advantage of using 1158 such a construction is to avoid issues created by usage of cross 1159 protocol proxies (e.g. UDP to TCP). 1161 error SHALL be a CBOR Sequence (see Appendix A.1) as defined below 1163 error = ( 1164 ? C_x : bstr_identifier, 1165 ERR_MSG : tstr, 1166 ? SUITES_R : [ supported : 2* suite ] / suite, 1167 ) 1169 where: 1171 o C_x - if error is sent by the Responder and corr (METHOD_CORR mod 1172 4) equals 0 or 2 then C_x is set to C_I, else if error is sent by 1173 the Initiator and corr (METHOD_CORR mod 4) equals 0 or 1 then C_x 1174 is set to C_R, else C_x is omitted. 1176 o ERR_MSG - text string containing the diagnostic payload, defined 1177 in the same way as in Section 5.5.2 of [RFC7252]. ERR_MSG MAY be 1178 a 0-length text string. 1180 o SUITES_R - cipher suites from SUITES_I or the EDHOC cipher suites 1181 registry that the Responder supports. SUITES_R MUST only be 1182 included in replies to message_1. If a single supported cipher 1183 suite is conveyed then the supported cipher suite is encoded as an 1184 int instead of an array. 1186 5.1.1. Example Use of EDHOC Error Message with SUITES_R 1188 Assuming that the Initiator supports the five cipher suites 5, 6, 7, 1189 8, and 9 in decreasing order of preference, Figures 5 and 6 show 1190 examples of how the Responder can truncate SUITES_I and how SUITES_R 1191 is used by the Responder to give the Initiator information about the 1192 cipher suites that the Responder supports. In Figure 5, the 1193 Responder supports cipher suite 6 but not the selected cipher suite 1194 5. 1196 Initiator Responder 1197 | METHOD_CORR, SUITES_I = [5, 5, 6, 7], G_X, C_I, AD_1 | 1198 +------------------------------------------------------------------>| 1199 | message_1 | 1200 | | 1201 | C_I, ERR_MSG, SUITES_R = 6 | 1202 |<------------------------------------------------------------------+ 1203 | error | 1204 | | 1205 | METHOD_CORR, SUITES_I = [6, 5, 6], G_X, C_I, AD_1 | 1206 +------------------------------------------------------------------>| 1207 | message_1 | 1209 Figure 5: Example use of error message with SUITES_R. 1211 In Figure 6, the Responder supports cipher suite 7 but not cipher 1212 suites 5 and 6. 1214 Initiator Responder 1215 | METHOD_CORR, SUITES_I = [5, 5, 6], G_X, C_I, AD_1 | 1216 +------------------------------------------------------------------>| 1217 | message_1 | 1218 | | 1219 | C_I, ERR_MSG, SUITES_R = [7, 9] | 1220 |<------------------------------------------------------------------+ 1221 | error | 1222 | | 1223 | METHOD_CORR, SUITES_I = [7, 5, 6, 7], G_X, C_I, AD_1 | 1224 +------------------------------------------------------------------>| 1225 | message_1 | 1227 Figure 6: Example use of error message with SUITES_R. 1229 As the Initiator's list of supported cipher suites and order of 1230 preference is fixed, and the Responder only accepts message_1 if the 1231 selected cipher suite is the first cipher suite in SUITES_I that the 1232 Responder supports, the parties can verify that the selected cipher 1233 suite is the most preferred (by the Initiator) cipher suite supported 1234 by both parties. If the selected cipher suite is not the first 1235 cipher suite in SUITES_I that the Responder supports, the Responder 1236 will discontinue the protocol. 1238 6. Transferring EDHOC and Deriving an OSCORE Context 1240 6.1. Transferring EDHOC in CoAP 1242 It is recommended to transport EDHOC as an exchange of CoAP [RFC7252] 1243 messages. CoAP is a reliable transport that can preserve packet 1244 ordering and handle message duplication. CoAP can also perform 1245 fragmentation and protect against denial of service attacks. It is 1246 recommended to carry the EDHOC messages in Confirmable messages, 1247 especially if fragmentation is used. 1249 By default, the CoAP client is the Initiator and the CoAP server is 1250 the Responder, but the roles SHOULD be chosen to protect the most 1251 sensitive identity, see Section 7. By default, EDHOC is transferred 1252 in POST requests and 2.04 (Changed) responses to the Uri-Path: 1253 "/.well-known/edhoc", but an application may define its own path that 1254 can be discovered e.g. using resource directory 1255 [I-D.ietf-core-resource-directory]. 1257 By default, the message flow is as follows: EDHOC message_1 is sent 1258 in the payload of a POST request from the client to the server's 1259 resource for EDHOC. EDHOC message_2 or the EDHOC error message is 1260 sent from the server to the client in the payload of a 2.04 (Changed) 1261 response. EDHOC message_3 or the EDHOC error message is sent from 1262 the client to the server's resource in the payload of a POST request. 1263 If needed, an EDHOC error message is sent from the server to the 1264 client in the payload of a 2.04 (Changed) response. 1266 An example of a successful EDHOC exchange using CoAP is shown in 1267 Figure 7. In this case the CoAP Token enables the Initiator to 1268 correlate message_1 and message_2 so the correlation parameter corr = 1269 1. 1271 Client Server 1272 | | 1273 +--------->| Header: POST (Code=0.02) 1274 | POST | Uri-Path: "/.well-known/edhoc" 1275 | | Content-Format: application/edhoc 1276 | | Payload: EDHOC message_1 1277 | | 1278 |<---------+ Header: 2.04 Changed 1279 | 2.04 | Content-Format: application/edhoc 1280 | | Payload: EDHOC message_2 1281 | | 1282 +--------->| Header: POST (Code=0.02) 1283 | POST | Uri-Path: "/.well-known/edhoc" 1284 | | Content-Format: application/edhoc 1285 | | Payload: EDHOC message_3 1286 | | 1287 |<---------+ Header: 2.04 Changed 1288 | 2.04 | 1289 | | 1291 Figure 7: Transferring EDHOC in CoAP 1293 The exchange in Figure 7 protects the client identity against active 1294 attackers and the server identity against passive attackers. An 1295 alternative exchange that protects the server identity against active 1296 attackers and the client identity against passive attackers is shown 1297 in Figure 8. In this case the CoAP Token enables the Responder to 1298 correlate message_2 and message_3 so the correlation parameter corr = 1299 2. 1301 Client Server 1302 | | 1303 +--------->| Header: POST (Code=0.02) 1304 | POST | Uri-Path: "/.well-known/edhoc" 1305 | | 1306 |<---------+ Header: 2.04 Changed 1307 | 2.04 | Content-Format: application/edhoc 1308 | | Payload: EDHOC message_1 1309 | | 1310 +--------->| Header: POST (Code=0.02) 1311 | POST | Uri-Path: "/.well-known/edhoc" 1312 | | Content-Format: application/edhoc 1313 | | Payload: EDHOC message_2 1314 | | 1315 |<---------+ Header: 2.04 Changed 1316 | 2.04 | Content-Format: application/edhoc 1317 | | Payload: EDHOC message_3 1318 | | 1320 Figure 8: Transferring EDHOC in CoAP 1322 To protect against denial-of-service attacks, the CoAP server MAY 1323 respond to the first POST request with a 4.01 (Unauthorized) 1324 containing an Echo option [I-D.ietf-core-echo-request-tag]. This 1325 forces the initiator to demonstrate its reachability at its apparent 1326 network address. If message fragmentation is needed, the EDHOC 1327 messages may be fragmented using the CoAP Block-Wise Transfer 1328 mechanism [RFC7959]. 1330 6.1.1. Deriving an OSCORE Context from EDHOC 1332 When EDHOC is used to derive parameters for OSCORE [RFC8613], the 1333 parties make sure that the EDHOC connection identifiers are unique, 1334 i.e. C_R MUST NOT be equal to C_I. The CoAP client and server MUST 1335 be able to retrieve the OSCORE protocol state using its chosen 1336 connection identifier and optionally other information such as the 1337 5-tuple. In case that the CoAP client is the Initiator and the CoAP 1338 server is the Responder: 1340 o The client's OSCORE Sender ID is C_R and the server's OSCORE 1341 Sender ID is C_I, as defined in this document 1343 o The AEAD Algorithm and the hash algorithm are the application AEAD 1344 and hash algorithms in the selected cipher suite. 1346 o The Master Secret and Master Salt are derived as follows where 1347 length is the key length (in bytes) of the application AEAD 1348 Algorithm. 1350 Master Secret = EDHOC-Exporter( "OSCORE Master Secret", length ) 1351 Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 ) 1353 7. Security Considerations 1355 7.1. Security Properties 1357 EDHOC inherits its security properties from the theoretical SIGMA-I 1358 protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides 1359 perfect forward secrecy, mutual authentication with aliveness, 1360 consistency, peer awareness. As described in [SIGMA], peer awareness 1361 is provided to the Responder, but not to the Initiator. 1363 EDHOC protects the credential identifier of the Initiator against 1364 active attacks and the credential identifier of the Responder against 1365 passive attacks. The roles should be assigned to protect the most 1366 sensitive identity/identifier, typically that which is not possible 1367 to infer from routing information in the lower layers. 1369 Compared to [SIGMA], EDHOC adds an explicit method type and expands 1370 the message authentication coverage to additional elements such as 1371 algorithms, auxiliary data, and previous messages. This protects 1372 against an attacker replaying messages or injecting messages from 1373 another session. 1375 EDHOC also adds negotiation of connection identifiers and downgrade 1376 protected negotiation of cryptographic parameters, i.e. an attacker 1377 cannot affect the negotiated parameters. A single session of EDHOC 1378 does not include negotiation of cipher suites, but it enables the 1379 Responder to verify that the selected cipher suite is the most 1380 preferred cipher suite by the Initiator which is supported by both 1381 the Initiator and the Responder. 1383 As required by [RFC7258], IETF protocols need to mitigate pervasive 1384 monitoring when possible. One way to mitigate pervasive monitoring 1385 is to use a key exchange that provides perfect forward secrecy. 1386 EDHOC therefore only supports methods with perfect forward secrecy. 1387 To limit the effect of breaches, it is important to limit the use of 1388 symmetrical group keys for bootstrapping. EDHOC therefore strives to 1389 make the additional cost of using raw public keys and self-signed 1390 certificates as small as possible. Raw public keys and self-signed 1391 certificates are not a replacement for a public key infrastructure, 1392 but SHOULD be used instead of symmetrical group keys for 1393 bootstrapping. 1395 Compromise of the long-term keys (private signature or static DH 1396 keys) does not compromise the security of completed EDHOC exchanges. 1397 Compromising the private authentication keys of one party lets an 1398 active attacker impersonate that compromised party in EDHOC exchanges 1399 with other parties, but does not let the attacker impersonate other 1400 parties in EDHOC exchanges with the compromised party. Compromise of 1401 the long-term keys does not enable a passive attacker to compromise 1402 future session keys. Compromise of the HDKF input parameters (ECDH 1403 shared secret) leads to compromise of all session keys derived from 1404 that compromised shared secret. Compromise of one session key does 1405 not compromise other session keys. 1407 Key compromise impersonation (KCI): In EDHOC authenticated with 1408 signature keys, EDHOC provides KCI protection against an attacker 1409 having access to the long term key or the ephemeral secret key. With 1410 static Diffie-Hellman key authentication, KCI protection would be 1411 provided against an attacker having access to the long-term Diffie- 1412 Hellman key, but not to an attacker having access to the ephemeral 1413 secret key. Note that the term KCI has typically been used for 1414 compromise of long-term keys, and that an attacker with access to the 1415 ephemeral secret key can only attack that specific protocol run. 1417 Repudiation: In EDHOC authenticated with signature keys, Party U 1418 could theoretically prove that Party V performed a run of the 1419 protocol by presenting the private ephemeral key, and vice versa. 1420 Note that storing the private ephemeral keys violates the protocol 1421 requirements. With static Diffie-Hellman key authentication, both 1422 parties can always deny having participated in the protocol. 1424 7.2. Cryptographic Considerations 1426 The security of the SIGMA protocol requires the MAC to be bound to 1427 the identity of the signer. Hence the message authenticating 1428 functionality of the authenticated encryption in EDHOC is critical: 1429 authenticated encryption MUST NOT be replaced by plain encryption 1430 only, even if authentication is provided at another level or through 1431 a different mechanism. EDHOC implements SIGMA-I using the same Sign- 1432 then-MAC approach as TLS 1.3. 1434 To reduce message overhead EDHOC does not use explicit nonces and 1435 instead rely on the ephemeral public keys to provide randomness to 1436 each session. A good amount of randomness is important for the key 1437 generation, to provide liveness, and to protect against interleaving 1438 attacks. For this reason, the ephemeral keys MUST NOT be reused, and 1439 both parties SHALL generate fresh random ephemeral key pairs. 1441 The choice of key length used in the different algorithms needs to be 1442 harmonized, so that a sufficient security level is maintained for 1443 certificates, EDHOC, and the protection of application data. The 1444 Initiator and the Responder should enforce a minimum security level. 1446 The data rates in many IoT deployments are very limited. Given that 1447 the application keys are protected as well as the long-term 1448 authentication keys they can often be used for years or even decades 1449 before the cryptographic limits are reached. If the application keys 1450 established through EDHOC need to be renewed, the communicating 1451 parties can derive application keys with other labels or run EDHOC 1452 again. 1454 7.3. Cipher Suites 1456 Cipher suite number 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, 1457 Ed25519, AES-CCM-16-64-128, SHA-256) is mandatory to implement. 1458 Implementations only need to implement the algorithms needed for 1459 their supported methods. For many constrained IoT devices it is 1460 problematic to support more than one cipher suites, so some 1461 deployments with P-256 may not support the mandatory cipher suite. 1462 This is not a problem for local deployments. 1464 The HMAC algorithm HMAC 256/64 (HMAC w/ SHA-256 truncated to 64 bits) 1465 SHALL NOT be supported for use in EDHOC. 1467 7.4. Unprotected Data 1469 The Initiator and the Responder must make sure that unprotected data 1470 and metadata do not reveal any sensitive information. This also 1471 applies for encrypted data sent to an unauthenticated party. In 1472 particular, it applies to AD_1, ID_CRED_R, AD_2, and ERR_MSG. Using 1473 the same AD_1 in several EDHOC sessions allows passive eavesdroppers 1474 to correlate the different sessions. Another consideration is that 1475 the list of supported cipher suites may potentially be used to 1476 identify the application. 1478 The Initiator and the Responder must also make sure that 1479 unauthenticated data does not trigger any harmful actions. In 1480 particular, this applies to AD_1 and ERR_MSG. 1482 7.5. Denial-of-Service 1484 EDHOC itself does not provide countermeasures against Denial-of- 1485 Service attacks. By sending a number of new or replayed message_1 an 1486 attacker may cause the Responder to allocate state, perform 1487 cryptographic operations, and amplify messages. To mitigate such 1488 attacks, an implementation SHOULD rely on lower layer mechanisms such 1489 as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that 1490 forces the initiator to demonstrate reachability at its apparent 1491 network address. 1493 7.6. Implementation Considerations 1495 The availability of a secure pseudorandom number generator and truly 1496 random seeds are essential for the security of EDHOC. If no true 1497 random number generator is available, a truly random seed must be 1498 provided from an external source. As each pseudorandom number must 1499 only be used once, an implementation need to get a new truly random 1500 seed after reboot, or continuously store state in nonvolatile memory, 1501 see ([RFC8613], Appendix B.1.1) for issues and solution approaches 1502 for writing to nonvolatile memory. If ECDSA is supported, 1503 "deterministic ECDSA" as specified in [RFC6979] is RECOMMENDED. 1505 The referenced processing instructions in [SP-800-56A] must be 1506 complied with, including deleting the intermediate computed values 1507 along with any ephemeral ECDH secrets after the key derivation is 1508 completed. The ECDH shared secret, keys, and IVs MUST be secret. 1509 Implementations should provide countermeasures to side-channel 1510 attacks such as timing attacks. Depending on the selected curve, the 1511 parties should perform various validations of each other's public 1512 keys, see e.g. Section 5 of [SP-800-56A]. 1514 The Initiator and the Responder are responsible for verifying the 1515 integrity of certificates. The selection of trusted CAs should be 1516 done very carefully and certificate revocation should be supported. 1517 The private authentication keys MUST be kept secret. 1519 The Initiator and the Responder are allowed to select the connection 1520 identifiers C_I and C_R, respectively, for the other party to use in 1521 the ongoing EDHOC protocol as well as in a subsequent application 1522 protocol (e.g. OSCORE [RFC8613]). The choice of connection 1523 identifier is not security critical in EDHOC but intended to simplify 1524 the retrieval of the right security context in combination with using 1525 short identifiers. If the wrong connection identifier of the other 1526 party is used in a protocol message it will result in the receiving 1527 party not being able to retrieve a security context (which will 1528 terminate the protocol) or retrieve the wrong security context (which 1529 also terminates the protocol as the message cannot be verified). 1531 The Responder MUST finish the verification step of message_3 before 1532 passing AD_3 to the application. 1534 If two nodes unintentionally initiate two simultaneous EDHOC message 1535 exchanges with each other even if they only want to complete a single 1536 EDHOC message exchange, they MAY terminate the exchange with the 1537 lexicographically smallest G_X. If the two G_X values are equal, the 1538 received message_1 MUST be discarded to mitigate reflection attacks. 1539 Note that in the case of two simultaneous EDHOC exchanges where the 1540 nodes only complete one and where the nodes have different preferred 1541 cipher suites, an attacker can affect which of the two nodes' 1542 preferred cipher suites will be used by blocking the other exchange. 1544 7.7. Other Documents Referencing EDHOC 1546 EDHOC has been analyzed in several other documents. A formal 1547 verification of EDHOC was done in [SSR18], an analysis of EDHOC for 1548 certificate enrollment was done in [Kron18], the use of EDHOC in 1549 LoRaWAN is analyzed in [LoRa1] and [LoRa2], the use of EDHOC in IoT 1550 bootstrapping is analyzed in [Perez18], and the use of EDHOC in 1551 6TiSCH is described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. 1553 8. IANA Considerations 1555 8.1. EDHOC Cipher Suites Registry 1557 IANA has created a new registry titled "EDHOC Cipher Suites" under 1558 the new heading "EDHOC". The registration procedure is "Expert 1559 Review". The columns of the registry are Value, Array, Description, 1560 and Reference, where Value is an integer and the other columns are 1561 text strings. The initial contents of the registry are: 1563 Value: -24 1564 Algorithms: N/A 1565 Desc: Reserved for Private Use 1566 Reference: [[this document]] 1568 Value: -23 1569 Algorithms: N/A 1570 Desc: Reserved for Private Use 1571 Reference: [[this document]] 1573 Value: 0 1574 Array: 10, 5, 4, -8, 6, 10, 5 1575 Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519, 1576 AES-CCM-16-64-128, SHA-256 1577 Reference: [[this document]] 1579 Value: 1 1580 Array: 30, 5, 4, -8, 6, 10, 5 1581 Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519, 1582 AES-CCM-16-64-128, SHA-256 1583 Reference: [[this document]] 1584 Value: 2 1585 Array: 10, 5, 1, -7, 1, 10, 5 1586 Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256, 1587 AES-CCM-16-64-128, SHA-256 1588 Reference: [[this document]] 1590 Value: 3 1591 Array: 30, 5, 1, -7, 1, 10, 5 1592 Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256, 1593 AES-CCM-16-64-128, SHA-256 1594 Reference: [[this document]] 1596 8.2. EDHOC Method Type Registry 1598 IANA has created a new registry titled "EDHOC Method Type" under the 1599 new heading "EDHOC". The registration procedure is "Expert Review". 1600 The columns of the registry are Value, Description, and Reference, 1601 where Value is an integer and the other columns are text strings. 1602 The initial contents of the registry are: 1604 +-------+-------------------+-------------------+-------------------+ 1605 | Value | Initiator | Responder | Reference | 1606 +-------+-------------------+-------------------+-------------------+ 1607 | 0 | Signature Key | Signature Key | [[this document]] | 1608 | 1 | Signature Key | Static DH Key | [[this document]] | 1609 | 2 | Static DH Key | Signature Key | [[this document]] | 1610 | 3 | Static DH Key | Static DH Key | [[this document]] | 1611 +-------+-------------------+-------------------+-------------------+ 1613 Figure 9: Method Types 1615 8.3. The Well-Known URI Registry 1617 IANA has added the well-known URI 'edhoc' to the Well-Known URIs 1618 registry. 1620 o URI suffix: edhoc 1622 o Change controller: IETF 1624 o Specification document(s): [[this document]] 1626 o Related information: None 1628 8.4. Media Types Registry 1630 IANA has added the media type 'application/edhoc' to the Media Types 1631 registry. 1633 o Type name: application 1635 o Subtype name: edhoc 1637 o Required parameters: N/A 1639 o Optional parameters: N/A 1641 o Encoding considerations: binary 1643 o Security considerations: See Section 7 of this document. 1645 o Interoperability considerations: N/A 1647 o Published specification: [[this document]] (this document) 1649 o Applications that use this media type: To be identified 1651 o Fragment identifier considerations: N/A 1653 o Additional information: 1655 * Magic number(s): N/A 1657 * File extension(s): N/A 1659 * Macintosh file type code(s): N/A 1661 o Person & email address to contact for further information: See 1662 "Authors' Addresses" section. 1664 o Intended usage: COMMON 1666 o Restrictions on usage: N/A 1668 o Author: See "Authors' Addresses" section. 1670 o Change Controller: IESG 1672 8.5. CoAP Content-Formats Registry 1674 IANA has added the media type 'application/edhoc' to the CoAP 1675 Content-Formats registry. 1677 o Media Type: application/edhoc 1679 o Encoding: 1681 o ID: TBD42 1683 o Reference: [[this document]] 1685 8.6. Expert Review Instructions 1687 The IANA Registries established in this document is defined as 1688 "Expert Review". This section gives some general guidelines for what 1689 the experts should be looking for, but they are being designated as 1690 experts for a reason so they should be given substantial latitude. 1692 Expert reviewers should take into consideration the following points: 1694 o Clarity and correctness of registrations. Experts are expected to 1695 check the clarity of purpose and use of the requested entries. 1696 Expert needs to make sure the values of algorithms are taken from 1697 the right registry, when that's required. Expert should consider 1698 requesting an opinion on the correctness of registered parameters 1699 from relevant IETF working groups. Encodings that do not meet 1700 these objective of clarity and completeness should not be 1701 registered. 1703 o Experts should take into account the expected usage of fields when 1704 approving point assignment. The length of the encoded value 1705 should be weighed against how many code points of that length are 1706 left, the size of device it will be used on, and the number of 1707 code points left that encode to that size. 1709 o Specifications are recommended. When specifications are not 1710 provided, the description provided needs to have sufficient 1711 information to verify the points above. 1713 9. References 1715 9.1. Normative References 1717 [I-D.ietf-core-echo-request-tag] 1718 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1719 Request-Tag, and Token Processing", draft-ietf-core-echo- 1720 request-tag-10 (work in progress), July 2020. 1722 [I-D.ietf-cose-x509] 1723 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1724 Header parameters for carrying and referencing X.509 1725 certificates", draft-ietf-cose-x509-06 (work in progress), 1726 March 2020. 1728 [I-D.ietf-lake-reqs] 1729 Vucinic, M., Selander, G., Mattsson, J., and D. Garcia- 1730 Carillo, "Requirements for a Lightweight AKE for OSCORE", 1731 draft-ietf-lake-reqs-04 (work in progress), June 2020. 1733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1734 Requirement Levels", BCP 14, RFC 2119, 1735 DOI 10.17487/RFC2119, March 1997, 1736 . 1738 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1739 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1740 . 1742 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1743 Key Derivation Function (HKDF)", RFC 5869, 1744 DOI 10.17487/RFC5869, May 2010, 1745 . 1747 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1748 Curve Cryptography Algorithms", RFC 6090, 1749 DOI 10.17487/RFC6090, February 2011, 1750 . 1752 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 1753 Algorithm (DSA) and Elliptic Curve Digital Signature 1754 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 1755 2013, . 1757 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1758 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1759 October 2013, . 1761 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1762 Application Protocol (CoAP)", RFC 7252, 1763 DOI 10.17487/RFC7252, June 2014, 1764 . 1766 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1767 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1768 2016, . 1770 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1771 the Constrained Application Protocol (CoAP)", RFC 7959, 1772 DOI 10.17487/RFC7959, August 2016, 1773 . 1775 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1776 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1777 . 1779 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1780 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1781 May 2017, . 1783 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1784 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1785 . 1787 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1788 Definition Language (CDDL): A Notational Convention to 1789 Express Concise Binary Object Representation (CBOR) and 1790 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1791 June 2019, . 1793 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1794 "Object Security for Constrained RESTful Environments 1795 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1796 . 1798 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1799 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1800 . 1802 9.2. Informative References 1804 [CborMe] Bormann, C., "CBOR Playground", May 2018, 1805 . 1807 [I-D.hartke-core-e2e-security-reqs] 1808 Selander, G., Palombini, F., and K. Hartke, "Requirements 1809 for CoAP End-To-End Security", draft-hartke-core-e2e- 1810 security-reqs-03 (work in progress), July 2017. 1812 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 1813 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 1814 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 1815 progress), July 2019. 1817 [I-D.ietf-ace-oauth-authz] 1818 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1819 H. Tschofenig, "Authentication and Authorization for 1820 Constrained Environments (ACE) using the OAuth 2.0 1821 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1822 (work in progress), June 2020. 1824 [I-D.ietf-ace-oscore-profile] 1825 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1826 "OSCORE profile of the Authentication and Authorization 1827 for Constrained Environments Framework", draft-ietf-ace- 1828 oscore-profile-11 (work in progress), June 2020. 1830 [I-D.ietf-core-resource-directory] 1831 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1832 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1833 resource-directory-25 (work in progress), July 2020. 1835 [I-D.ietf-lwig-security-protocol-comparison] 1836 Mattsson, J., Palombini, F., and M. Vucinic, "Comparison 1837 of CoAP Security Protocols", draft-ietf-lwig-security- 1838 protocol-comparison-04 (work in progress), March 2020. 1840 [I-D.ietf-tls-dtls13] 1841 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1842 Datagram Transport Layer Security (DTLS) Protocol Version 1843 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1844 2020. 1846 [I-D.selander-ace-ake-authz] 1847 Selander, G., Mattsson, J., Vucinic, M., Richardson, M., 1848 and A. Schellenbaum, "Lightweight Authorization for 1849 Authenticated Key Exchange.", draft-selander-ace-ake- 1850 authz-01 (work in progress), March 2020. 1852 [Kron18] Krontiris, A., "Evaluation of Certificate Enrollment over 1853 Application Layer Security", May 2018, 1854 . 1857 [LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., 1858 Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. 1859 Skarmeta, "Enhancing LoRaWAN Security through a 1860 Lightweight and Authenticated Key Management Approach", 1861 June 2018, 1862 . 1865 [LoRa2] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S., 1866 Fernandez, P., Santa, J., Hernandez-Ramos, J., and A. 1867 Skarmeta, "Internet Access for LoRaWAN Devices Considering 1868 Security Issues", June 2018, 1869 . 1871 [Perez18] Perez, S., Garcia-Carrillo, D., Marin-Lopez, R., 1872 Hernandez-Ramos, J., Marin-Perez, R., and A. Skarmeta, 1873 "Architecture of security association establishment based 1874 on bootstrapping technologies for enabling critical IoT 1875 K", October 2018, . 1880 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1881 Constrained-Node Networks", RFC 7228, 1882 DOI 10.17487/RFC7228, May 2014, 1883 . 1885 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1886 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1887 2014, . 1889 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1890 Kivinen, "Internet Key Exchange Protocol Version 2 1891 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1892 2014, . 1894 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1895 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1896 . 1898 [SIGMA] Krawczyk, H., "SIGMA - The 'SIGn-and-MAc' Approach to 1899 Authenticated Diffie-Hellman and Its Use in the IKE- 1900 Protocols (Long version)", June 2003, 1901 . 1903 [SP-800-56A] 1904 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1905 Davis, "Recommendation for Pair-Wise Key-Establishment 1906 Schemes Using Discrete Logarithm Cryptography", 1907 NIST Special Publication 800-56A Revision 3, April 2018, 1908 . 1910 [SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T., 1911 and C. Schuermann, "Formal Verification of Ephemeral 1912 Diffie-Hellman Over COSE (EDHOC)", November 2018, 1913 . 1917 Appendix A. Use of CBOR, CDDL and COSE in EDHOC 1919 This Appendix is intended to simplify for implementors not familiar 1920 with CBOR [RFC7049], CDDL [RFC8610], COSE [RFC8152], and HKDF 1921 [RFC5869]. 1923 A.1. CBOR and CDDL 1925 The Concise Binary Object Representation (CBOR) [RFC7049] is a data 1926 format designed for small code size and small message size. CBOR 1927 builds on the JSON data model but extends it by e.g. encoding binary 1928 data directly without base64 conversion. In addition to the binary 1929 CBOR encoding, CBOR also has a diagnostic notation that is readable 1930 and editable by humans. The Concise Data Definition Language (CDDL) 1931 [RFC8610] provides a way to express structures for protocol messages 1932 and APIs that use CBOR. [RFC8610] also extends the diagnostic 1933 notation. 1935 CBOR data items are encoded to or decoded from byte strings using a 1936 type-length-value encoding scheme, where the three highest order bits 1937 of the initial byte contain information about the major type. CBOR 1938 supports several different types of data items, in addition to 1939 integers (int, uint), simple values (e.g. null), byte strings (bstr), 1940 and text strings (tstr), CBOR also supports arrays [] of data items, 1941 maps {} of pairs of data items, and sequences [RFC8742] of data 1942 items. Some examples are given below. For a complete specification 1943 and more examples, see [RFC7049] and [RFC8610]. We recommend 1944 implementors to get used to CBOR by using the CBOR playground 1945 [CborMe]. 1947 Diagnostic Encoded Type 1948 ------------------------------------------------------------------ 1949 1 0x01 unsigned integer 1950 24 0x1818 unsigned integer 1951 -24 0x37 negative integer 1952 -25 0x3818 negative integer 1953 null 0xf6 simple value 1954 h'12cd' 0x4212cd byte string 1955 '12cd' 0x4431326364 byte string 1956 "12cd" 0x6431326364 text string 1957 { 4 : h'cd' } 0xa10441cd map 1958 << 1, 2, null >> 0x430102f6 byte string 1959 [ 1, 2, null ] 0x830102f6 array 1960 ( 1, 2, null ) 0x0102f6 sequence 1961 1, 2, null 0x0102f6 sequence 1962 ------------------------------------------------------------------ 1964 A.2. COSE 1966 CBOR Object Signing and Encryption (COSE) [RFC8152] describes how to 1967 create and process signatures, message authentication codes, and 1968 encryption using CBOR. COSE builds on JOSE, but is adapted to allow 1969 more efficient processing in constrained devices. EDHOC makes use of 1970 COSE_Key, COSE_Encrypt0, and COSE_Sign1 objects. 1972 Appendix B. Test Vectors 1974 This appendix provides detailed test vectors to ease implementation 1975 and ensure interoperability. In addition to hexadecimal, all CBOR 1976 data items and sequences are given in CBOR diagnostic notation. The 1977 test vectors use the default mapping to CoAP where the Initiator acts 1978 as CoAP client (this means that corr = 1). 1980 A more extensive test vector suite covering more combinations of 1981 authentication method used between Initiator and Responder and 1982 related code to generate them can be found at 1983 https://github.com/EricssonResearch/EDHOC/tree/master/Test%20Vectors 1984 . 1986 B.1. Test Vectors for EDHOC Authenticated with Signature Keys (x5t) 1988 EDHOC with signature authentication and X.509 certificates is used. 1989 In this test vector, the hash value 'x5t' is used to identify the 1990 certificate. 1992 method (Signature Authentication) 1993 0 1994 CoAP is used as transport and the Initiator acts as CoAP client: 1996 corr (the Initiator can correlate message_1 and message_2) 1997 1 1999 From there, METHOD_CORR has the following value: 2001 METHOD_CORR (4 * method + corr) (int) 2002 1 2004 No unprotected opaque auxiliary data is sent in the message 2005 exchanges. 2007 The list of supported cipher suites of the Initiator in order of 2008 preference is the following: 2010 Supported Cipher Suites (4 bytes) 2011 00 01 02 03 2013 The cipher suite selected by the Initiator is the most preferred: 2015 Selected Cipher Suite (int) 2016 0 2018 The mandatory-to-implement cipher suite 0 is supported by both the 2019 Initiator and the Responder, see Section 7.3. 2021 B.1.1. Message_1 2023 X (Initiator's ephemeral private key) (32 bytes) 2024 8f 78 1a 09 53 72 f8 5b 6d 9f 61 09 ae 42 26 11 73 4d 7d bf a0 06 9a 2d 2025 f2 93 5b b2 e0 53 bf 35 2027 G_X (Initiator's ephemeral public key) (32 bytes) 2028 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 ec 07 6b ba 2029 02 59 d9 04 b7 ec 8b 0c 2031 The Initiator chooses a connection identifier C_I: 2033 Connection identifier chosen by Initiator (0 bytes) 2035 Since no unprotected opaque auxiliary data is sent in the message 2036 exchanges: 2038 AD_1 (0 bytes) 2039 Since the list of supported cipher suites needs to contain the 2040 selected cipher suite, the initiator truncates the list of supported 2041 cipher suites to one cipher suite only, 00. 2043 Because one single selected cipher suite is conveyed, it is encoded 2044 as an int instead of an array: 2046 SUITES_I (int) 2047 0 2049 With SUITES_I = 0, message_1 is constructed, as the CBOR Sequence of 2050 the CBOR data items above. 2052 message_1 = 2053 ( 2054 1, 2055 0, 2056 h'898ff79a02067a16ea1eccb90fa52246f5aa4dd6ec076bba0259d904b7ec8b0c', 2057 h'' 2058 ) 2060 message_1 (CBOR Sequence) (37 bytes) 2061 01 00 58 20 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 2062 ec 07 6b ba 02 59 d9 04 b7 ec 8b 0c 40 2064 B.1.2. Message_2 2066 Since METHOD_CORR mod 4 equals 1, C_I is omitted from data_2. 2068 Y (Responder's ephemeral private key) (32 bytes) 2069 fd 8c d8 77 c9 ea 38 6e 6a f3 4f f7 e6 06 c4 b6 4c a8 31 c8 ba 33 13 4f 2070 d4 cd 71 67 ca ba ec da 2072 G_Y (Responder's ephemeral public key) (32 bytes) 2073 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52 2074 81 75 4c 5e bc af 30 1e 2076 From G_X and Y or from G_Y and X the ECDH shared secret is computed: 2078 G_XY (ECDH shared secret) (32 bytes) 2079 2b b7 fa 6e 13 5b c3 35 d0 22 d6 34 cb fb 14 b3 f5 82 f3 e2 e3 af b2 b3 2080 15 04 91 49 5c 61 78 2b 2082 The key and nonce for calculating the ciphertext are calculated as 2083 follows, as specified in Section 3.8. 2085 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 2087 PRK_2e = HMAC-SHA-256(salt, G_XY) 2089 Salt is the empty byte string. 2091 salt (0 bytes) 2093 From there, PRK_2e is computed: 2095 PRK_2e (32 bytes) 2096 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f 2097 d8 2f be b7 99 71 39 4a 2099 SK_R (Responders's private authentication key) (32 bytes) 2100 df 69 27 4d 71 32 96 e2 46 30 63 65 37 2b 46 83 ce d5 38 1b fc ad cd 44 2101 0a 24 c3 91 d2 fe db 94 2103 Since neither the Initiator nor the Responder authenticates with a 2104 static Diffie-Hellman key, PRK_3e2m = PRK_2e 2106 PRK_3e2m (32 bytes) 2107 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f 2108 d8 2f be b7 99 71 39 4a 2110 The Responder chooses a connection identifier C_R. 2112 Connection identifier chosen by Responder (1 bytes) 2113 13 2115 Data_2 is constructed, as the CBOR Sequence of G_Y and C_R. 2117 data_2 = 2118 ( 2119 h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e', 2120 h'13' 2121 ) 2123 data_2 (CBOR Sequence) (35 bytes) 2124 58 20 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 2125 19 52 81 75 4c 5e bc af 30 1e 13 2127 From data_2 and message_1, compute the input to the transcript hash 2128 TH_2 = H( message_1, data_2 ), as a CBOR Sequence of these 2 data 2129 items. 2131 Input to calculate TH_2 (CBOR Sequence) (72 bytes) 2132 01 00 58 20 89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 2133 ec 07 6b ba 02 59 d9 04 b7 ec 8b 0c 40 58 20 71 a3 d5 99 c2 1d a1 89 02 2134 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52 81 75 4c 5e bc af 30 1e 13 2135 And from there, compute the transcript hash TH_2 = SHA-256( 2136 message_1, data_2 ) 2138 TH_2 (32 bytes) 2139 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 b9 ca fb 60 2140 9d e4 f6 a1 76 0d 6c f7 2142 The Responder's subject name is the empty string: 2144 Responders's subject name (text string) 2145 "" 2147 And because 'x5t' has value certificate are used, ID_CRED_R is the 2148 following: 2150 ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R, and since the 2151 SHA-2 256-bit Hash truncated to 64-bits is used (value -15): 2153 ID_CRED_R = 2154 { 2155 34: [-15, h'FC79990F2431A3F5'] 2156 } 2158 ID_CRED_R (14 bytes) 2159 a1 18 22 82 2e 48 fc 79 99 0f 24 31 a3 f5 2161 CRED_R is the certificate encoded as a byte string: 2163 CRED_R (112 bytes) 2164 58 6e 47 62 4d c9 cd c6 82 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 2165 4b f9 03 15 00 ce e6 86 99 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 2166 5c 50 db 78 97 4c 27 15 79 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 2167 18 0b 5a 6a f3 1e 80 20 9a 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 2168 0f fb 8e 3f 9a 32 a5 08 59 ec d0 bf cf f2 c2 18 2170 Since no unprotected opaque auxiliary data is sent in the message 2171 exchanges: 2173 AD_2 (0 bytes) 2175 The Plaintext is defined as the empty string: 2177 P_2m (0 bytes) 2179 The Enc_structure is defined as follows: [ "Encrypt0", 2180 << ID_CRED_R >>, << TH_2, CRED_R >> ] 2182 A_2m = 2183 [ 2184 "Encrypt0", 2185 h'A11822822E48FC79990F2431A3F5', 2186 h'5820B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF 2187 7586E47624DC9CDC6824B2A4C52E95EC9D6B0534B71C2B49E4BF9031500CEE6869979 2188 C297BB5A8B381E98DB714108415E5C50DB78974C271579B01633A3EF6271BE5C225EB 2189 28F9CF6180B5A6AF31E80209A085CFBF95F3FDCF9B18B693D6C0E0D0FFB8E3F9A32A5 2190 0859ECD0BFCFF2C218' 2191 ] 2193 Which encodes to the following byte string to be used as Additional 2194 Authenticated Data: 2196 A_2m (CBOR-encoded) (173 bytes) 2197 83 68 45 6e 63 72 79 70 74 30 4e a1 18 22 82 2e 48 fc 79 99 0f 24 31 a3 2198 f5 58 92 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 2199 47 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 58 6e 47 62 4d c9 cd c6 82 4b 2a 2200 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9 03 15 00 ce e6 86 99 79 c2 2201 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50 db 78 97 4c 27 15 79 b0 16 2202 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 18 0b 5a 6a f3 1e 80 20 9a 08 5c 2203 fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 0f fb 8e 3f 9a 32 a5 08 59 ec d0 2204 bf cf f2 c2 18 2206 info for K_2m is defined as follows: 2208 info for K_2m = 2209 [ 2210 10, 2211 h'B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF7', 2212 "K_2m", 2213 16 2214 ] 2216 Which as a CBOR encoded data item is: 2218 info for K_2m (CBOR-encoded) (42 bytes) 2219 84 0a 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 2220 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 64 4b 5f 32 6d 10 2222 From these parameters, K_2m is computed. Key K_2m is the output of 2223 HKDF-Expand(PRK_3e2m, info, L), where L is the length of K_2m, so 16 2224 bytes. 2226 K_2m (16 bytes) 2227 b7 48 6a 94 a3 6c f6 9e 67 3f c4 57 55 ee 6b 95 2229 info for IV_2m is defined as follows: 2231 info for K_2m = 2232 [ 2233 10, 2234 h'B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF7', 2235 "IV_2m", 2236 13 2237 ] 2239 Which as a CBOR encoded data item is: 2241 info for IV_2m (CBOR-encoded) (43 bytes) 2242 84 0a 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 2243 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 65 49 56 5f 32 6d 0d 2245 From these parameters, IV_2m is computed. IV_2m is the output of 2246 HKDF-Expand(PRK_3e2m, info, L), where L is the length of IV_2m, so 13 2247 bytes. 2249 IV_2m (13 bytes) 2250 c5 b7 17 0e 65 d5 4f 1a e0 5d 10 af 56 2252 Finally, COSE_Encrypt0 is computed from the parameters above. 2254 o protected header = CBOR-encoded ID_CRED_R 2256 o external_aad = A_2m 2258 o empty plaintext = P_2m 2260 MAC_2 (8 bytes) 2261 cf 99 99 ae 75 9e c0 d8 2263 To compute the Signature_or_MAC_2, the key is the private 2264 authentication key of the Responder and the message M_2 to be signed 2265 = [ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >>, MAC_2 2266 ] 2268 M_2 = 2269 [ 2270 "Signature1", 2271 h'A11822822E48FC79990F2431A3F5', 2272 h'5820B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF 2273 7586E47624DC9CDC6824B2A4C52E95EC9D6B0534B71C2B49E4BF9031500CEE6869979 2274 C297BB5A8B381E98DB714108415E5C50DB78974C271579B01633A3EF6271BE5C225EB 2275 28F9CF6180B5A6AF31E80209A085CFBF95F3FDCF9B18B693D6C0E0D0FFB8E3F9A32A5 2276 0859ECD0BFCFF2C218', 2277 h'CF9999AE759EC0D8' 2278 ] 2279 Which as a CBOR encoded data item is: 2281 M_2 (184 bytes) 2282 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 fc 79 99 0f 24 2283 31 a3 f5 58 92 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 2284 31 1a 47 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 58 6e 47 62 4d c9 cd c6 82 2285 4b 2a 4c 52 e9 5e c9 d6 b0 53 4b 71 c2 b4 9e 4b f9 03 15 00 ce e6 86 99 2286 79 c2 97 bb 5a 8b 38 1e 98 db 71 41 08 41 5e 5c 50 db 78 97 4c 27 15 79 2287 b0 16 33 a3 ef 62 71 be 5c 22 5e b2 8f 9c f6 18 0b 5a 6a f3 1e 80 20 9a 2288 08 5c fb f9 5f 3f dc f9 b1 8b 69 3d 6c 0e 0d 0f fb 8e 3f 9a 32 a5 08 59 2289 ec d0 bf cf f2 c2 18 48 cf 99 99 ae 75 9e c0 d8 2291 From there Signature_or_MAC_2 is a signature (since method = 0): 2293 Signature_or_MAC_2 (64 bytes) 2294 45 47 81 ec ef eb b4 83 e6 90 83 9d 57 83 8d fe 24 a8 cf 3f 66 42 8a a0 2295 16 20 4a 22 61 84 4a f8 4f 98 b8 c6 83 4f 38 7f dd 60 6a 29 41 3a dd e3 2296 a2 07 74 02 13 74 01 19 6f 6a 50 24 06 6f ac 0e 2298 CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a 2299 plaintext constructed from the following parameters and the key K_2e. 2301 o plaintext = CBOR Sequence of the items ID_CRED_R and 2302 Singature_or_MAC_2, in this order. 2304 The plaintext is the following: 2306 P_2e (CBOR Sequence) (80 bytes) 2307 a1 18 22 82 2e 48 fc 79 99 0f 24 31 a3 f5 58 40 45 47 81 ec ef eb b4 83 2308 e6 90 83 9d 57 83 8d fe 24 a8 cf 3f 66 42 8a a0 16 20 4a 22 61 84 4a f8 2309 4f 98 b8 c6 83 4f 38 7f dd 60 6a 29 41 3a dd e3 a2 07 74 02 13 74 01 19 2310 6f 6a 50 24 06 6f ac 0e 2312 K_2e = HKDF-Expand( PRK, info, length ), where length is the length 2313 of the plaintext, so 80. 2315 info for K_2e = 2316 [ 2317 10, 2318 h'B0DC6C1BA0BAE6E2888610FA0B27BFC52E311A47B9CAFB609DE4F6A1760D6CF7', 2319 "K_2e", 2320 80 2321 ] 2323 Which as a CBOR encoded data item is: 2325 info for K_2e (CBOR-encoded) (43 bytes) 2326 84 0a 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 2327 b9 ca fb 60 9d e4 f6 a1 76 0d 6c f7 64 4b 5f 32 65 18 50 2329 From there, K_2e is computed: 2331 K_2e (80 bytes) 2332 38 cd 1a 83 89 6d 43 af 3d e8 39 35 27 42 0d ac 7d 7a 76 96 7e 85 74 58 2333 26 bb 39 e1 76 21 8d 7e 5f e7 97 60 14 c9 ed ba c0 58 ee 18 cd 57 71 80 2334 a4 4d de 0b 83 00 fe 8e 09 66 9a 34 d6 3e 3a e6 10 12 26 ab f8 5c eb 28 2335 05 dc 00 13 d1 78 2a 20 2337 Using the parameters above, the ciphertext CIPHERTEXT_2 can be 2338 computed: 2340 CIPHERTEXT_2 (80 bytes) 2341 99 d5 38 01 a7 25 bf d6 a4 e7 1d 04 84 b7 55 ec 38 3d f7 7a 91 6e c0 db 2342 c0 2b ba 7c 21 a2 00 80 7b 4f 58 5f 72 8b 67 1a d6 78 a4 3a ac d3 3b 78 2343 eb d5 66 cd 00 4f c6 f1 d4 06 f0 1d 97 04 e7 05 b2 15 52 a9 eb 28 ea 31 2344 6a b6 50 37 d7 17 86 2e 2346 message_2 is the CBOR Sequence of data_2 and CIPHERTEXT_2, in this 2347 order: 2349 message_2 = 2350 ( 2351 data_2, 2352 h'99d53801a725bfd6a4e71d0484b755ec383df77a916ec0dbc02bba7c21a200807b4f 2353 585f728b671ad678a43aacd33b78ebd566cd004fc6f1d406f01d9704e705b21552a9eb 2354 28ea316ab65037d717862e' 2355 ) 2357 Which as a CBOR encoded data item is: 2359 message_2 (CBOR Sequence) (117 bytes) 2360 58 20 71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 2361 19 52 81 75 4c 5e bc af 30 1e 13 58 50 99 d5 38 01 a7 25 bf d6 a4 e7 1d 2362 04 84 b7 55 ec 38 3d f7 7a 91 6e c0 db c0 2b ba 7c 21 a2 00 80 7b 4f 58 2363 5f 72 8b 67 1a d6 78 a4 3a ac d3 3b 78 eb d5 66 cd 00 4f c6 f1 d4 06 f0 2364 1d 97 04 e7 05 b2 15 52 a9 eb 28 ea 31 6a b6 50 37 d7 17 86 2e 2366 B.1.3. Message_3 2368 Since corr equals 1, C_R is not omitted from data_3. 2370 SK_I (Initiator's private authentication key) (32 bytes) 2371 2f fc e7 a0 b2 b8 25 d3 97 d0 cb 54 f7 46 e3 da 3f 27 59 6e e0 6b 53 71 2372 48 1d c0 e0 12 bc 34 d7 2373 HKDF SHA-256 is the HKDF used (as defined by cipher suite 0). 2375 PRK_4x3m = HMAC-SHA-256 (PRK_3e2m, G_IY) 2377 PRK_4x3m (32 bytes) 2378 ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f 2379 d8 2f be b7 99 71 39 4a 2381 data 3 is equal to C_R. 2383 data_3 (CBOR Sequence) (1 bytes) 2384 13 2386 From data_3, CIPHERTEXT_2, and TH_2, compute the input to the 2387 transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3), as a CBOR 2388 Sequence of these 3 data items. 2390 Input to calculate TH_3 (CBOR Sequence) (117 bytes) 2391 58 20 b0 dc 6c 1b a0 ba e6 e2 88 86 10 fa 0b 27 bf c5 2e 31 1a 47 b9 ca 2392 fb 60 9d e4 f6 a1 76 0d 6c f7 58 50 99 d5 38 01 a7 25 bf d6 a4 e7 1d 04 2393 84 b7 55 ec 38 3d f7 7a 91 6e c0 db c0 2b ba 7c 21 a2 00 80 7b 4f 58 5f 2394 72 8b 67 1a d6 78 a4 3a ac d3 3b 78 eb d5 66 cd 00 4f c6 f1 d4 06 f0 1d 2395 97 04 e7 05 b2 15 52 a9 eb 28 ea 31 6a b6 50 37 d7 17 86 2e 13 2397 And from there, compute the transcript hash TH_3 = SHA-256(TH_2 , 2398 CIPHERTEXT_2, data_3) 2400 TH_3 (32 bytes) 2401 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd 2402 b3 2e 4a 27 ce 93 58 da 2404 The initiator's subject name is the empty string: 2406 Initiator's subject name (text string) 2407 "" 2409 And its credential is a certificate identified by its 'x5t' hash: 2411 ID_CRED_R = 2412 { 2413 34: [-15, h'FC79990F2431A3F5'] 2414 } 2416 ID_CRED_I (14 bytes) 2417 a1 18 22 82 2e 48 5b 78 69 88 43 9e bc f2 2419 CRED_I is the certificate encoded as a byte string: 2421 CRED_I (103 bytes) 2422 58 65 fa 34 b2 2a 9c a4 a1 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f 2423 fc 79 5f 88 af c4 9c be 8a fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 2424 95 60 1f 6f 0a 08 52 97 8b d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 2425 88 37 00 16 b8 96 5b db 20 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2426 2b 87 ec 3f f2 45 b7 2428 Since no opaque auciliary data is exchanged: 2430 AD_3 (0 bytes) 2432 The Plaintext of the COSE_Encrypt is the empty string: 2434 P_3m (0 bytes) 2436 The external_aad is the CBOR Sequence od CRED_I and TH_3, in this 2437 order: 2439 A_3m (CBOR-encoded) (164 bytes) 2440 83 68 45 6e 63 72 79 70 74 30 4e a1 18 22 82 2e 48 5b 78 69 88 43 9e bc 2441 f2 58 89 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 2442 3e f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 58 65 fa 34 b2 2a 9c a4 a1 e1 29 2443 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79 5f 88 af c4 9c be 8a fd d1 2444 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60 1f 6f 0a 08 52 97 8b d4 3d 2445 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37 00 16 b8 96 5b db 20 74 bf 2446 f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 ec 3f f2 45 b7 2448 Info for K_3m is computed as follows: 2450 info for K_3m = 2451 [ 2452 10, 2453 h'A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358DA', 2454 "K_3m", 2455 16 2456 ] 2458 Which as a CBOR encoded data item is: 2460 info for K_3m (CBOR-encoded) (42 bytes) 2461 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 2462 f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 64 4b 5f 33 6d 10 2464 From these parameters, K_3m is computed. Key K_3m is the output of 2465 HKDF-Expand(PRK_4x3m, info, L), where L is the length of K_2m, so 16 2466 bytes. 2468 K_3m (16 bytes) 2469 3d bb f0 d6 01 03 26 e8 27 3f c6 c6 c3 b0 de cd 2471 Nonce IV_3m is the output of HKDF-Expand(PRK_4x3m, info, L), where L 2472 = 13 bytes. 2474 Info for IV_3m is defined as follows: 2476 info for IV_3m = 2477 [ 2478 10, 2479 h'A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358DA', 2480 "IV_3m", 2481 13 2482 ] 2484 Which as a CBOR encoded data item is: 2486 info for IV_3m (CBOR-encoded) (43 bytes) 2487 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 2488 f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 65 49 56 5f 33 6d 0d 2490 From these parameters, IV_3m is computed: 2492 IV_3m (13 bytes) 2493 10 b6 f4 41 4a 2c 91 3c cd a1 96 42 e3 2495 MAC_3 is the ciphertext of the COSE_Encrypt0: 2497 MAC_3 (8 bytes) 2498 5e ef b8 85 98 3c 22 d9 2500 Since the method = 0, Signature_or_Mac_3 is a signature: 2502 o The message M_3 to be signed = [ "Signature1", << ID_CRED_I >>, 2503 << TH_3, CRED_I >>, MAC_3 ] 2505 o The signing key is the private authentication key of the 2506 Initiator. 2508 M_3 = 2509 [ 2510 "Signature1", 2511 h'A11822822E485B786988439EBCF2', 2512 h'5820A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358D 2513 A5865FA34B22A9CA4A1E12924EAE1D1766088098449CB848FFC795F88AFC49CBE8AFD 2514 D1BA009F21675E8F6C77A4A2C30195601F6F0A0852978BD43D28207D44486502FF7BD 2515 DA632C788370016B8965BDB2074BFF82E5A20E09BEC21F8406E86442B87EC3FF245 2516 B7', 2517 h'5EEFB885983C22D9'] 2519 Which as a CBOR encoded data item is: 2521 M_3 (175 bytes) 2522 84 6a 53 69 67 6e 61 74 75 72 65 31 4e a1 18 22 82 2e 48 5b 78 69 88 43 2523 9e bc f2 58 89 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 2524 6d 39 3e f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 58 65 fa 34 b2 2a 9c a4 a1 2525 e1 29 24 ea e1 d1 76 60 88 09 84 49 cb 84 8f fc 79 5f 88 af c4 9c be 8a 2526 fd d1 ba 00 9f 21 67 5e 8f 6c 77 a4 a2 c3 01 95 60 1f 6f 0a 08 52 97 8b 2527 d4 3d 28 20 7d 44 48 65 02 ff 7b dd a6 32 c7 88 37 00 16 b8 96 5b db 20 2528 74 bf f8 2e 5a 20 e0 9b ec 21 f8 40 6e 86 44 2b 87 ec 3f f2 45 b7 48 5e 2529 ef b8 85 98 3c 22 d9 2531 From there, the signature can be computed: 2533 Signature_or_MAC_3 (64 bytes) 2534 b3 31 76 33 fa eb c7 f4 24 9c f3 ab 95 96 fd ae 2b eb c8 e7 27 5d 39 9f 2535 42 00 04 f3 76 7b 88 d6 0f fe 37 dc f3 90 a0 00 d8 5a b0 ad b0 d7 24 e3 2536 a5 7c 4d fe 24 14 a4 1e 79 78 91 b9 55 35 89 06 2538 Finally, the outer COSE_Encrypt0 is computed. 2540 The Plaintext is the following CBOR Sequence: plaintext = ( ID_CRED_I 2541 , Signature_or_MAC_3 ) 2543 P_3ae (CBOR Sequence) (80 bytes) 2544 a1 18 22 82 2e 48 5b 78 69 88 43 9e bc f2 58 40 b3 31 76 33 fa eb c7 f4 2545 24 9c f3 ab 95 96 fd ae 2b eb c8 e7 27 5d 39 9f 42 00 04 f3 76 7b 88 d6 2546 0f fe 37 dc f3 90 a0 00 d8 5a b0 ad b0 d7 24 e3 a5 7c 4d fe 24 14 a4 1e 2547 79 78 91 b9 55 35 89 06 2549 The Associated data A is the following: Associated data A = [ 2550 "Encrypt0", h'', TH_3 ] 2552 A_3ae (CBOR-encoded) (45 bytes) 2553 83 68 45 6e 63 72 79 70 74 30 40 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 2554 1e c3 92 bf eb 92 6d 39 3e f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 2555 Key K_3ae is the output of HKDF-Expand(PRK_3e2m, info, L). 2557 info is defined as follows: 2559 info for K_3ae = 2560 [ 2561 10, 2562 h'A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358DA', 2563 "K_3ae", 2564 16 2565 ] 2567 Which as a CBOR encoded data item is: 2569 info for K_3ae (CBOR-encoded) (43 bytes) 2570 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 2571 f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 65 4b 5f 33 61 65 10 2573 L is the length of K_3ae, so 16 bytes. 2575 From these parameters, K_3ae is computed: 2577 K_3ae (16 bytes) 2578 58 b5 2f 94 5b 30 9d 85 4c a7 36 cd 06 a9 62 95 2580 Nonce IV_3ae is the output of HKDF-Expand(PRK_3e2m, info, L). 2582 info is defined as follows: 2584 info for IV_3ae = 2585 [ 2586 10, 2587 h'A239A627ADA3802DB8DAE51EC392BFEB926D393EF6EEE4DDB32E4A27CE9358DA', 2588 "IV_3ae", 2589 13 2590 ] 2592 Which as a CBOR encoded data item is: 2594 info for IV_3ae (CBOR-encoded) (44 bytes) 2595 84 0a 58 20 a2 39 a6 27 ad a3 80 2d b8 da e5 1e c3 92 bf eb 92 6d 39 3e 2596 f6 ee e4 dd b3 2e 4a 27 ce 93 58 da 66 49 56 5f 33 61 65 0d 2598 L is the length of IV_3ae, so 13 bytes. 2600 From these parameters, IV_3ae is computed: 2602 IV_3ae (13 bytes) 2603 cf a9 a5 85 58 10 d6 dc e9 74 3c 3b c3 2605 Using the parameters above, the ciphertext CIPHERTEXT_3 can be 2606 computed: 2608 CIPHERTEXT_3 (88 bytes) 2609 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db a4 78 05 2610 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e af 56 e4 2611 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 e4 62 f5 2612 f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a 2614 From the parameter above, message_3 is computed, as the CBOR Sequence 2615 of the following items: (C_R, CIPHERTEXT_3). 2617 message_3 = 2618 ( 2619 h'13', 2620 h'' 2621 ) 2623 Which encodes to the following byte string: 2625 message_3 (CBOR Sequence) (91 bytes) 2626 13 58 58 2d 88 ff 86 da 47 48 2c 0d fa 55 9a c8 24 a4 a7 83 d8 70 c9 db 2627 a4 78 05 e8 aa fb ad 69 74 c4 96 46 58 65 03 fa 9b bf 3e 00 01 2c 03 7e 2628 af 56 e4 5e 30 19 20 83 9b 81 3a 53 f6 d4 c5 57 48 0f 6c 79 7d 5b 76 f0 2629 e4 62 f5 f5 7a 3d b6 d2 b5 0c 32 31 9f 34 0f 4a c5 af 9a 2631 Acknowledgments 2633 The authors want to thank Alessandro Bruni, Karthikeyan Bhargavan, 2634 Martin Disch, Theis Groenbech Petersen, Dan Harkins, Klaus Hartke, 2635 Russ Housley, Alexandros Krontiris, Ilari Liusvaara, Karl Norrman, 2636 Salvador Perez, Eric Rescorla, Michael Richardson, Thorvald Sahl 2637 Joergensen, Jim Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav 2638 Smyshlyaev, Valery Smyslov, Rene Struik, Erik Thormarker, and Michel 2639 Veillette for reviewing and commenting on intermediate versions of 2640 the draft. We are especially indebted to Jim Schaad for his 2641 continuous reviewing and implementation of different versions of the 2642 draft. 2644 Authors' Addresses 2646 Goeran Selander 2647 Ericsson AB 2649 Email: goran.selander@ericsson.com 2650 John Preuss Mattsson 2651 Ericsson AB 2653 Email: john.mattsson@ericsson.com 2655 Francesca Palombini 2656 Ericsson AB 2658 Email: francesca.palombini@ericsson.com