idnits 2.17.1 draft-ietf-core-oscore-edhoc-03.txt: -(973): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (7 March 2022) is 775 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) == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-12 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group F. Palombini 3 Internet-Draft Ericsson 4 Intended status: Standards Track M. Tiloca 5 Expires: 8 September 2022 R. Hoeglund 6 RISE AB 7 S. Hristozov 8 Fraunhofer AISEC 9 G. Selander 10 Ericsson 11 7 March 2022 13 Profiling EDHOC for CoAP and OSCORE 14 draft-ietf-core-oscore-edhoc-03 16 Abstract 18 The lightweight authenticated key exchange protocol EDHOC can be run 19 over CoAP and used by two peers to establish an OSCORE Security 20 Context. This document further profiles this use of the EDHOC 21 protocol, by specifying a number of additional and optional 22 mechanisms. These especially include an optimization approach for 23 combining the execution of EDHOC with the first subsequent OSCORE 24 transaction. This combination reduces the number of round trips 25 required to set up an OSCORE Security Context and to complete an 26 OSCORE transaction using that Security Context. 28 Discussion Venues 30 This note is to be removed before publishing as an RFC. 32 Discussion of this document takes place on the Constrained RESTful 33 Environments Working Group mailing list (core@ietf.org), which is 34 archived at https://mailarchive.ietf.org/arch/browse/core/. 36 Source for this draft and an issue tracker can be found at 37 https://github.com/core-wg/oscore-edhoc. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 8 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. EDHOC Combined with OSCORE . . . . . . . . . . . . . . . . . 7 76 3.1. EDHOC Option . . . . . . . . . . . . . . . . . . . . . . 9 77 3.2. Client Processing . . . . . . . . . . . . . . . . . . . . 10 78 3.2.1. Supporting Block-wise . . . . . . . . . . . . . . . . 11 79 3.3. Server Processing . . . . . . . . . . . . . . . . . . . . 12 80 3.3.1. Supporting Block-wise . . . . . . . . . . . . . . . . 13 81 3.4. Example of EDHOC + OSCORE Request . . . . . . . . . . . . 13 82 4. Conversion from OSCORE to EDHOC Identifiers . . . . . . . . . 14 83 4.1. Conversion Method . . . . . . . . . . . . . . . . . . . . 15 84 4.2. Additional Processing of EDHOC Messages . . . . . . . . . 16 85 4.2.1. Initiator Processing of Message 1 . . . . . . . . . . 16 86 4.2.2. Responder Processing of Message 1 . . . . . . . . . . 17 87 4.2.3. Responder Processing of Message 2 . . . . . . . . . . 17 88 4.2.4. Initiator Processing of Message 2 . . . . . . . . . . 18 89 5. Extension and Consistency of Applicability Statement . . . . 18 90 6. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 93 8.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 21 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 96 9.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Appendix A. Checking CBOR Encoding of Numeric Values . . . . . . 24 99 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 24 100 B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 25 101 B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 25 102 B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 25 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 106 1. Introduction 108 Ephemeral Diffie-Hellman Over COSE (EDHOC) [I-D.ietf-lake-edhoc] is a 109 lightweight authenticated key exchange protocol, especially intended 110 for use in constrained scenarios. In particular, EDHOC messages can 111 be transported over the Constrained Application Protocol (CoAP) 112 [RFC7252] and used for establishing a Security Context for Object 113 Security for Constrained RESTful Environments (OSCORE) [RFC8613]. 115 This document profiles this use of the EDHOC protocol, and specifies 116 a number of additional and optional mechanisms. These especially 117 include an optimization approach, that combines the EDHOC execution 118 with the first subsequent OSCORE transaction (see Section 3). This 119 allows for a minimum number of round trips necessary to setup the 120 OSCORE Security Context and complete an OSCORE transaction, e.g., 121 when an IoT device gets configured in a network for the first time. 123 This optimization is desirable, since the number of protocol round 124 trips impacts on the minimum number of flights, which in turn can 125 have a substantial impact on the latency of conveying the first 126 OSCORE request, when using certain radio technologies. 128 Without this optimization, it is not possible, not even in theory, to 129 achieve the minimum number of flights. This optimization makes it 130 possible also in practice, since the last message of the EDHOC 131 protocol can be made relatively small (see Section 1.3 of 132 [I-D.ietf-lake-edhoc]), thus allowing additional OSCORE-protected 133 CoAP data within target MTU sizes. 135 Furthermore, this document defines: 137 * A method for deterministically converting an OSCORE Sender/ 138 Recipient ID to a corresponding EDHOC connection identifier (see 139 Section 4). While this method is required to be used when using 140 the optimization above, it is recommended in general, since it 141 ensures that an OSCORE Sender/Recipient ID is always converted to 142 the EDHOC identifier with the smallest size. 144 * A number of parameters corresponding to different information 145 elements of an EDHOC applicability statement (see Section 6). 146 These can be specified as target attributes in the link to an 147 EDHOC resource associated with that applicability statement, thus 148 enabling an enhanced discovery of such resource for CoAP clients. 150 1.1. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 The reader is expected to be familiar with terms and concepts defined 159 in CoAP [RFC7252], CBOR [RFC8949], CBOR sequences [RFC8742], OSCORE 160 [RFC8613] and EDHOC [I-D.ietf-lake-edhoc]. 162 2. EDHOC Overview 164 The EDHOC protocol allows two peers to agree on a cryptographic 165 secret, in a mutually-authenticated way and by using Diffie-Hellman 166 ephemeral keys to achieve forward secrecy. The two peers are denoted 167 as Initiator and Responder, as the one sending or receiving the 168 initial EDHOC message_1, respectively. 170 After successful processing of EDHOC message_3, both peers agree on a 171 cryptographic secret that can be used to derive further security 172 material, and especially to establish an OSCORE Security Context 173 [RFC8613]. The Responder can also send an optional EDHOC message_4 174 to achieve key confirmation, e.g., in deployments where no protected 175 application message is sent from the Responder to the Initiator. 177 Appendix A.3 of [I-D.ietf-lake-edhoc] specifies how to transfer EDHOC 178 over CoAP. That is, the EDHOC data (referred to as "EDHOC messages") 179 are transported in the payload of CoAP requests and responses. The 180 default message flow consists in the CoAP Client acting as Initiator 181 and the CoAP Server acting as Responder. Alternatively, the two 182 roles can be reversed. In the rest of this document, EDHOC messages 183 are considered to be transferred over CoAP. 185 Figure 1 shows a CoAP Client and Server running EDHOC as Initiator 186 and Responder, respectively. That is, the Client sends a POST 187 request to a reserved EDHOC resource at the Server, by default at the 188 Uri-Path "/.well-known/edhoc". The request payload consists of the 189 CBOR simple value "true" (0xf5) concatenated with EDHOC message_1, 190 which also includes the EDHOC connection identifier C_I of the 191 Client. 193 This triggers the EDHOC exchange at the Server, which replies with a 194 2.04 (Changed) response. The response payload consists of EDHOC 195 message_2, which also includes the EDHOC connection identifier C_R of 196 the Server. The Content-Format of the response may be set to 197 "application/edhoc". 199 Finally, the Client sends a POST request to the same EDHOC resource 200 used earlier to send EDHOC message_1. The request payload consists 201 of the EDHOC connection identifier C_R, concatenated with EDHOC 202 message_3. 204 After this exchange takes place, and after successful verifications 205 as specified in the EDHOC protocol, the Client and Server can derive 206 an OSCORE Security Context, as defined in Appendix A.2 of 207 [I-D.ietf-lake-edhoc]. After that, they can use OSCORE to protect 208 their communications as per [RFC8613]. 210 The Client and Server are required to agree in advance on certain 211 information and parameters describing how they should use EDHOC. 212 These are specified in an applicability statement see Section 3.9 of 213 [I-D.ietf-lake-edhoc], associated with the used EDHOC resource. 215 CoAP Client CoAP Server 216 (EDHOC Initiator) (EDHOC Responder) 217 | | 218 | | 219 | ----------------- EDHOC Request ---------------> | 220 | Header: 0.02 (POST) | 221 | Uri-Path: "/.well-known/edhoc" | 222 | Payload: true, EDHOC message_1 | 223 | | 224 | <---------------- EDHOC Response---------------- | 225 | Header: 2.04 (Changed) | 226 | Content-Format: application/edhoc | 227 | Payload: EDHOC message_2 | 228 | | 229 EDHOC verification | 230 | | 231 | ----------------- EDHOC Request ---------------> | 232 | Header: 0.02 (POST) | 233 | Uri-Path: "/.well-known/edhoc" | 234 | Payload: C_R, EDHOC message_3 | 235 | | 236 | EDHOC verification 237 | + 238 OSCORE Sec Ctx OSCORE Sec Ctx 239 Derivation Derivation 240 | | 241 | ---------------- OSCORE Request ---------------> | 242 | Header: 0.02 (POST) | 243 | Payload: OSCORE-protected data | 244 | | 245 | <--------------- OSCORE Response --------------- | 246 | Header: 2.04 (Changed) | 247 | Payload: OSCORE-protected data | 248 | | 250 Figure 1: EDHOC and OSCORE run sequentially 252 As shown in Figure 1, this purely-sequential flow where EDHOC is run 253 first and then OSCORE is used takes three round trips to complete. 255 Section 3 defines an optimization for combining EDHOC with the first 256 subsequent OSCORE transaction. This reduces the number of round 257 trips required to set up an OSCORE Security Context and to complete 258 an OSCORE transaction using that Security Context. 260 3. EDHOC Combined with OSCORE 262 This section defines an optimization for combining the EDHOC exchange 263 with the first subsequent OSCORE transaction, thus minimizing the 264 number of round trips between the two peers. 266 This approach can be used only if the default EDHOC message flow is 267 used, i.e., when the Client acts as Initiator and the Server acts as 268 Responder, while it cannot be used in the case with reversed roles. 270 When running the purely-sequential flow of Section 2, the Client has 271 all the information to derive the OSCORE Security Context already 272 after receiving EDHOC message_2 and before sending EDHOC message_3. 274 Hence, the Client can potentially send both EDHOC message_3 and the 275 subsequent OSCORE Request at the same time. On a semantic level, 276 this requires sending two REST requests at once, as in Figure 2. 278 CoAP Client CoAP Server 279 (EDHOC Initiator) (EDHOC Responder) 280 | | 281 | ------------------ EDHOC Request -----------------> | 282 | Header: 0.02 (POST) | 283 | Uri-Path: "/.well-known/edhoc" | 284 | Payload: true, EDHOC message_1 | 285 | | 286 | <----------------- EDHOC Response------------------ | 287 | Header: Changed (2.04) | 288 | Content-Format: application/edhoc | 289 | Payload: EDHOC message_2 | 290 | | 291 EDHOC verification | 292 + | 293 OSCORE Sec Ctx | 294 Derivation | 295 | | 296 | ------------- EDHOC + OSCORE Request -------------> | 297 | Header: 0.02 (POST) | 298 | Payload: EDHOC message_3 + OSCORE-protected data | 299 | | 300 | EDHOC verification 301 | + 302 | OSCORE Sec Ctx 303 | Derivation 304 | | 305 | <--------------- OSCORE Response ------------------ | 306 | Header: 2.04 (Changed) | 307 | Payload: OSCORE-protected data | 308 | | 310 Figure 2: EDHOC and OSCORE combined 312 To this end, the specific approach defined in this section consists 313 of sending a single EDHOC + OSCORE request, which conveys the pair 314 (C_R, EDHOC message_3) within an OSCORE-protected CoAP message. 316 That is, the EDHOC + OSCORE request is in practice the OSCORE Request 317 from Figure 1, as still sent to a protected resource and with the 318 correct CoAP method and options intended for accessing that resource. 319 At the same time, the EDHOC + OSCORE request also transports the pair 320 (C_R, EDHOC message_3) required for completing the EDHOC exchange. 321 Note that C_R is not transported precisely in the request payload. 323 Since EDHOC message_3 may be too large to be included in a CoAP 324 Option, e.g., if conveying a protected large public key certificate 325 chain as ID_CRED_I (see Section 3.5.4 of [I-D.ietf-lake-edhoc]) or if 326 conveying protected External Authorization Data as EAD_3 (see 327 Section 3.8 of [I-D.ietf-lake-edhoc]), EDHOC message_3 has to be 328 transported in the CoAP payload of the EDHOC + OSCORE request. 330 The rest of this section specifies how to transport the data in the 331 EDHOC + OSCORE request and their processing order. In particular, 332 the use of this approach is explicitly signalled by including an 333 EDHOC Option (see Section 3.1) in the EDHOC + OSCORE request. The 334 processing of the EDHOC + OSCORE request is specified in Section 3.2 335 for the Client side and in Section 3.3 for the Server side. 337 3.1. EDHOC Option 339 This section defines the EDHOC Option. The option is used in a CoAP 340 request, to signal that the request payload conveys both an EDHOC 341 message_3 and OSCORE-protected data, combined together. 343 The EDHOC Option has the properties summarized in Figure 3, which 344 extends Table 4 of [RFC7252]. The option is Critical, Safe-to- 345 Forward, and part of the Cache-Key. The option MUST occur at most 346 once and is always empty. If any value is sent, the value is simply 347 ignored. The option is intended only for CoAP requests and is of 348 Class U for OSCORE [RFC8613]. 350 +-------+---+---+---+---+-------+--------+--------+---------+ 351 | No. | C | U | N | R | Name | Format | Length | Default | 352 +-------+---+---+---+---+-------+--------+--------+---------+ 353 | TBD21 | x | | | | EDHOC | Empty | 0 | (none) | 354 +-------+---+---+---+---+-------+--------+--------+---------+ 355 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 357 Figure 3: The EDHOC Option. 359 The presence of this option means that the message payload contains 360 also EDHOC data, that must be extracted and processed as defined in 361 Section 3.3, before the rest of the message can be processed. 363 Figure 4 shows the format of a CoAP message containing both the EDHOC 364 data and the OSCORE ciphertext, using the newly defined EDHOC option 365 for signalling. 367 0 1 2 3 368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |Ver| T | TKL | Code | Message ID | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Token (if any, TKL bytes) ... 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | OSCORE option | EDHOC option | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Other options (if any) ... 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |1 1 1 1 1 1 1 1| Payload 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 4: CoAP message for EDHOC and OSCORE combined - signalled 382 with the EDHOC Option 384 3.2. Client Processing 386 The Client prepares an EDHOC + OSCORE request as follows. 388 1. Compose EDHOC message_3 as per Section 5.4.2 of 389 [I-D.ietf-lake-edhoc]. 391 2. Encrypt the original CoAP request as per Section 8.1 of 392 [RFC8613], using the new OSCORE Security Context established 393 after receiving EDHOC message_2. 395 Note that the OSCORE ciphertext is not computed over EDHOC 396 message_3, which is not protected by OSCORE. That is, the result 397 of this step is the OSCORE Request as in Figure 1. 399 3. Build a CBOR sequence [RFC8742] composed of two CBOR byte strings 400 in the following order. 402 * The first CBOR byte string is the EDHOC message_3 resulting 403 from step 1. 405 * The second CBOR byte string has as value the OSCORE ciphertext 406 of the OSCORE-protected CoAP request resulting from step 2. 408 4. Compose the EDHOC + OSCORE request, as the OSCORE-protected CoAP 409 request resulting from step 2, where the payload is replaced with 410 the CBOR sequence built at step 3. 412 Note that the new payload includes EDHOC message_3, but it does 413 not include the EDHOC connection identifier C_R. As the Client 414 is the EDHOC Initiator, C_R encodes the OSCORE Sender ID of the 415 Client, which is already specified as 'kid' in the OSCORE Option 416 of the request from step 2, hence of the EDHOC + OSCORE request. 418 5. Signal the usage of this approach, by including the new EDHOC 419 Option defined in Section 3.1 into the EDHOC + OSCORE request. 421 6. Send the EDHOC + OSCORE request to the server. 423 With the same Server, the Client MUST NOT have more than one 424 simultaneous outstanding interaction (see Section 4.7 of [RFC7252]) 425 consisting of an EDHOC + OSCORE request and whose EDHOC data are 426 intended to the EDHOC session with the same connection identifier 427 C_R. 429 3.2.1. Supporting Block-wise 431 If Block-wise [RFC7959] is supported, the Client may fragment the 432 original CoAP request before protecting it with OSCORE, as defined in 433 Section 4.1.3.4.1 of [RFC8613]. In such a case, the OSCORE 434 processing in step 2 of Section 3.2 is performed on each inner block 435 of the original CoAP request, and the following also applies. 437 The Client takes the additional following step between steps 2 and 3 438 of Section 3.2. 440 A. If the OSCORE-protected request from step 2 conveys a non-first 441 inner block of the original CoAP request (i.e., the Block1 Option 442 processed at step 2 had NUM different than 0), then the Client skips 443 the following steps and sends the OSCORE-protected request to the 444 Server. In particular, the Client MUST NOT include the EDHOC Option 445 in the OSCORE-protected request. 447 The Client takes the additional following step between steps 3 and 4 448 of Section 3.2. 450 B. If the size of the built CBOR sequence exceeds 451 MAX_UNFRAGMENTED_SIZE (see Section 4.1.3.4.2 of [RFC8613]), the 452 Client MUST stop processing the request and MUST abort the Block-wise 453 tranfer. The Client can switch to the purely sequential workflow in 454 Figure 1, hence separately sending first EDHOC message_3 and then the 455 OSCORE-protected CoAP request once the EDHOC execution is completed. 457 3.3. Server Processing 459 In order to process a request containing the EDHOC option, i.e., an 460 EDHOC + OSCORE request, the Server MUST perform the following steps. 462 1. Check that the EDHOC + OSCORE request includes the OSCORE option 463 and that the request payload is a CBOR sequence composed of two 464 CBOR byte strings. If this is not the case, the Server MUST stop 465 processing the request and MUST reply with a 4.00 (Bad Request) 466 error response. 468 2. Extract EDHOC message_3 from the payload of the EDHOC + OSCORE 469 request, as the first CBOR byte string in the CBOR sequence. 471 3. Take the value of 'kid' from the OSCORE option of the EDHOC + 472 OSCORE request (i.e., the OSCORE Sender ID of the Client), and 473 use it to rebuild the EDHOC connection identifier C_R, as per 474 Section 4.1. 476 4. Retrieve the correct EDHOC session by using the connection 477 identifier C_R rebuilt at step 3. 479 If the applicability statement used in the EDHOC session 480 specifies that EDHOC message_4 shall be sent, the Server MUST 481 stop the EDHOC processing and consider it failed, as due to a 482 client error. 484 Otherwise, perform the EDHOC processing on the EDHOC message_3 485 extracted at step 2 as per Section 5.4.3 of 486 [I-D.ietf-lake-edhoc], based on the protocol state of the 487 retrieved EDHOC session. 489 The applicability statement used in the EDHOC session is the same 490 one associated with the EDHOC resource where the server received 491 the request conveying EDHOC message_1 that started the session. 492 This is relevant in case the server provides multiple EDHOC 493 resources, which may generally refer to different applicability 494 statements. 496 5. Establish a new OSCORE Security Context associated with the 497 client as per Appendix A.2 of [I-D.ietf-lake-edhoc], using the 498 EDHOC output from step 4. 500 6. Extract the OSCORE ciphertext from the payload of the EDHOC + 501 OSCORE request, as the value of the second CBOR byte string in 502 the CBOR sequence. 504 7. Rebuild the OSCORE-protected CoAP request, as the EDHOC + OSCORE 505 request where the payload is replaced with the OSCORE ciphertext 506 extracted at step 6. Then, remove the EDHOC option. 508 8. Decrypt and verify the OSCORE-protected CoAP request rebuilt at 509 step 7, as per Section 8.2 of [RFC8613], by using the OSCORE 510 Security Context established at step 5. 512 If the decrypted request includes an EDHOC option but it does not 513 include an OSCORE option, the Server MUST stop processing the 514 request and MUST reply with a 4.00 (Bad Request) error response. 516 9. Deliver the CoAP request resulting from step 8 to the 517 application. 519 If steps 4 (EDHOC processing) and 8 (OSCORE processing) are both 520 successfully completed, the Server MUST reply with an OSCORE- 521 protected response, in order for the Client to achieve key 522 confirmation (see Section 5.4.2 of [I-D.ietf-lake-edhoc]). The usage 523 of EDHOC message_4 as defined in Section 5.5 of [I-D.ietf-lake-edhoc] 524 is not applicable to the approach defined in this document. 526 If step 4 (EDHOC processing) fails, the server discontinues the 527 protocol as per Section 5.4.3 of [I-D.ietf-lake-edhoc] and responds 528 with an EDHOC error message with error code 1, formatted as defined 529 in Section 6.2 of [I-D.ietf-lake-edhoc]. In particular, the CoAP 530 response conveying the EDHOC error message MUST have Content-Format 531 set to application/edhoc defined in Section 9.12 of 532 [I-D.ietf-lake-edhoc]. 534 If step 4 (EDHOC processing) is successfully completed but step 8 535 (OSCORE processing) fails, the same OSCORE error handling as defined 536 in Section 8.2 of [RFC8613] applies. 538 3.3.1. Supporting Block-wise 540 If Block-wise [RFC7959] is supported, the following applies, the 541 Server takes the additional following step before any other in 542 Section 3.3. 544 A. If Block-wise is present in the request, then process the Outer 545 Block options according to [RFC7959], until all blocks of the request 546 have been received (see Section 4.1.3.4 of [RFC8613]). 548 3.4. Example of EDHOC + OSCORE Request 550 Figure 5 shows an example of EDHOC + OSCORE Request. In particular, 551 the example assumes that: 553 * The used OSCORE Partial IV is 0, consistently with the first 554 request protected with the new OSCORE Security Context. 556 * The OSCORE Sender ID of the Client is 0x01. 558 As per Section 4.1, this corresponds to the numeric EDHOC 559 connection identifier C_R with value 1. When using the purely- 560 sequential flow shown in Figure 1, this would be prepended to 561 EDHOC message_3 as the CBOR integer 1 (0x01 in CBOR encoding), in 562 the payload of the second EDHOC request. 564 * The EDHOC option is registered with CoAP option number 21. 566 o OSCORE option value: 0x090001 (3 bytes) 568 o EDHOC option value: - (0 bytes) 570 o EDHOC message_3: 0x52d5535f3147e85f1cfacd9e78abf9e0a81bbf (19 bytes) 572 o OSCORE ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes) 574 From there: 576 o Protected CoAP request (OSCORE message): 578 0x44025d1f ; CoAP 4-byte header 579 00003974 ; Token 580 39 6c6f63616c686f7374 ; Uri-Host Option: "localhost" 581 63 090001 ; OSCORE Option 582 c0 ; EDHOC Option 583 ff 52d5535f3147e85f1cfacd9e78abf9e0a81bbf 584 4d612f1092f1776f1c1668b3825e 585 (57 bytes) 587 Figure 5: Example of CoAP message with EDHOC and OSCORE combined 589 4. Conversion from OSCORE to EDHOC Identifiers 591 Appendix A.1 of [I-D.ietf-lake-edhoc] defines how an EDHOC connection 592 identifier is converted to an OSCORE Sender/Recipient ID. 594 In the following, Section 4.1 defines a method for converting from 595 OSCORE Sender/Recipient ID to EDHOC connection identifier. 597 When running EDHOC through a certain EDHOC resource, the Client and 598 Server MUST both use the conversion method defined in Section 4.1 and 599 MUST perform the additional message processing specified in 600 Section 4.2, if at least one of the following conditions hold. 602 * The applicability statement associated with the EDHOC resource 603 indicates that the server supports the EDHOC + OSCORE request 604 defined in Section 3. 606 * The applicability statement associated with the EDHOC resource 607 indicates that the conversion method defined in Section 4.1 is the 608 one to use. 610 Instead, if none of the above conditions hold, the Client and the 611 Server can independently use any consistent conversion method, such 612 as the one defined in Section 4.1 or different ones defined in 613 separate specifications. In particular, the Client and Server are 614 not required to use the same conversion method. In fact, as per 615 Appendix A.1 of [I-D.ietf-lake-edhoc], it is sufficient that the two 616 connection identifiers C_I and C_R exchanged during an EDHOC 617 execution are different and not "equivalent", hence not convertible 618 to the same OSCORE Sender/Recipient ID. 620 Even in case none of the above conditions hold, it is RECOMMENDED for 621 the Client and Server to use the conversion method defined in 622 Section 4.1, since it ensures that an OSCORE Sender/Recipient ID is 623 always converted to the EDHOC identifier with the smallest size among 624 the two equivalent ones. 626 4.1. Conversion Method 628 The process defined in this section ensures that every OSCORE Sender/ 629 Recipient ID is converted to only one of the two corresponding, 630 equivalent EDHOC connection identifiers, see Appendix A.1 of 631 [I-D.ietf-lake-edhoc]. 633 An OSCORE Sender/Recipient ID, OSCORE_ID, is converted to an EDHOC 634 connection identifier, EDHOC_ID, as follows. 636 * If OSCORE_ID is 0 bytes in size, it is converted to the empty byte 637 string EDHOC_ID (0x40 in CBOR encoding). 639 * If OSCORE_ID has a size in bytes different than 0, 1, 2, 3, 5 or 640 9, it is converted to a byte-valued EDHOC_ID, i.e., a CBOR byte 641 string with value OSCORE_ID. 643 For example, the OSCORE_ID 0x001122334455 is converted to the 644 byte-valued EDHOC_ID 0x001122334455 (0x46001122334455 in CBOR 645 encoding). 647 * If OSCORE_ID has a size in bytes equal to 1, 2, 3, 5 or 9 the 648 following applies. 650 - If OSCORE_ID is a valid CBOR encoding for an integer value 651 (i.e., it can be correctly decoded as a CBOR integer), then it 652 is converted to a numeric EDHOC_ID having OSCORE_ID as its CBOR 653 encoded form. 655 For example, the OSCORE_ID 0x01 is converted to the numeric 656 EDHOC_ID 1 (0x01 in CBOR encoding), while the OSCORE_ID 0x2B is 657 converted to the numeric EDHOC_ID -12 (0x2B in CBOR encoding). 659 - If OSCORE_ID is _not_ a valid CBOR encoding for an integer 660 value (i.e., it _cannot_ be correctly decoded as a CBOR 661 integer), then it is converted to a byte-valued EDHOC_ID having 662 OSCORE_ID as its value. 664 For example, the OSCORE_ID 0xFF is converted to the byte-valued 665 EDHOC_ID 0xFF (0x41FF in CBOR encoding). 667 Implementations can easily determine which case holds for a given 668 OSCORE_ID with no need to try to actually CBOR-decode it, e.g., by 669 using the approach in Appendix A. 671 When performing the conversions above, the two peers MUST always 672 refer to Deterministically Encoded CBOR as specified in Section 4.2.1 673 of [RFC8949], consistently with what is required by the EDHOC 674 protocol [I-D.ietf-lake-edhoc]. 676 4.2. Additional Processing of EDHOC Messages 678 This section specifies additional EDHOC message processing compared 679 to what is specified in Section 5 of [I-D.ietf-lake-edhoc]. 681 4.2.1. Initiator Processing of Message 1 683 The Initiator selects C_I as follows. 685 1. The Initiator initializes a set ID_SET as the empty set. 687 2. The Initiator selects an available OSCORE Recipient ID, namely 688 ID*, which is not included in ID_SET. Consistently with the 689 requirements in Section 3.3 of [RFC8613], when selecting ID*: 691 * The Initiator SHOULD select ID* only among the Recipient IDs 692 which are currently not used in the sets of all its Recipient 693 Contexts. 695 * The Initiator MUST NOT select a Recipient ID as ID* if this is 696 currently used in a Recipient Context within a Security 697 Context where the ID Context has zero-length. 699 3. The Initiator converts ID* to the EDHOC connection identifier 700 C_I, as per Section 4.1. 702 4. If the resulting C_I is already used, the Initiator adds ID* to 703 ID_SET and moves back to step 2. Otherwise, it uses C_I as its 704 EDHOC connection identifier. 706 4.2.2. Responder Processing of Message 1 708 The Responder MUST discontinue the protocol and reply with an EDHOC 709 error message with error code 1, formatted as defined in Section 6.2 710 of [I-D.ietf-lake-edhoc], if C_I is a CBOR byte string and it has as 711 value a valid CBOR encoding of an integer value (e.g., C_I is CBOR 712 encoded as 0x4100). 714 In fact, this would mean that the Initiator has not followed the 715 conversion rule in Section 4.1 when converting its (to be) OSCORE 716 Recipient ID to C_I. 718 4.2.3. Responder Processing of Message 2 720 The Responder selects C_R as follows. 722 1. The Responder initializes a set ID_SET as the empty set. 724 2. The Responder selects an available OSCORE Recipient ID, ID*, 725 which is not included in ID_SET. Consistently with the 726 requirements in Section 3.3 of [RFC8613], when selecting ID*: 728 * The Responder SHOULD select ID* only among the Recipient IDs 729 which are currently not used in the sets of all its Recipient 730 Contexts. 732 * The Responder MUST NOT select a Recipient ID as ID* if this is 733 currently used in a Recipient Context within a Security 734 Context where the ID Context has zero-length. 736 3. The Responder converts ID* to the EDHOC connection identifier 737 C_R, as per Section 4.1. 739 4. If the resulting C_R is already used or it is equal byte-by-byte 740 to the C_I specified in EDHOC message_1, the Initiator adds ID* 741 to ID_SET and moves back to step 2. Otherwise, it uses C_R as 742 its EDHOC connection identifier. 744 4.2.4. Initiator Processing of Message 2 746 If any of the following conditions holds, the Initiator MUST 747 discontinue the protocol and reply with an EDHOC error message with 748 error code 1, formatted as defined in Section 6.2 of 749 [I-D.ietf-lake-edhoc]. 751 * C_R is equal byte-by-byte to the C_I that was specified in EDHOC 752 message_1. 754 * C_R is a CBOR byte string and it has as value a valid CBOR 755 encoding of an integer value (e.g., C_R is CBOR encoded as 756 0x4100). 758 In fact, this would mean that the Responder has not followed the 759 conversion rule in Section 4.1 when converting its (to be) OSCORE 760 Recipient ID to C_R. 762 5. Extension and Consistency of Applicability Statement 764 The applicability statement referred by the Client and Server can 765 include the information elements introduced below, in accordance with 766 the specified consistency rules. 768 If the Server supports the EDHOC + OSCORE request within an EDHOC 769 execution started at a certain EDHOC resource, then the applicability 770 statement associated with that resource: 772 * MUST NOT specify that EDHOC message_4 shall be sent. 774 * SHOULD explicitly specify support for the EDHOC + OSCORE request. 776 * SHOULD explicitly specify that the method to convert from EDHOC to 777 OSCORE identifiers is the one defined in Section 4 and MUST NOT 778 specify any other method than that. 780 If the support for the EDHOC + OSCORE request is explicitly 781 specified and the method defined in Section 4 is not explicitly 782 specified, then the Client and Server MUST use it as conversion 783 method. 785 If the Server does not support the EDHOC + OSCORE request within an 786 EDHOC execution started at a certain EDHOC resource, then the 787 applicability statement associated with that resource MAY specify a 788 method to convert from EDHOC to OSCORE identifiers. In such a case, 789 the Client and Server MUST use the specified conversion method, which 790 MAY be the one defined in Section 4. 792 6. Web Linking 794 Section 9.13 of [I-D.ietf-lake-edhoc] registers the resource type 795 "core.edhoc", which can be used as target attribute in a web link 796 [RFC8288] to an EDHOC resource, e.g., using a link-format document 797 [RFC6690]. This enables Clients to discover the presence of EDHOC 798 resources at a Server, possibly using the resource type as filter 799 criterion. 801 At the same time, the applicability statement associated with an 802 EDHOC resource provides a number of information describing how the 803 EDHOC protocol can be used through that resource. While a Client may 804 become aware of the applicability statement through several means, it 805 would be convenient to obtain its information elements upon 806 discovering the EDHOC resources at the Server. This might aim at 807 discovering especially the EDHOC resources whose associated 808 applicability statement denotes a way of using EDHOC which is most 809 suitable to the Client, e.g., with EDHOC cipher suites or 810 authentication methods that the Client also supports or prefers. 812 That is, it would be convenient that a Client discovering an EDHOC 813 resource contextually obtains relevant pieces of information from the 814 applicability statement associated with that resource. The resource 815 discovery can occur by means of a direct interaction with the Server, 816 or instead by means of the CoRE Resource Directory 817 [I-D.ietf-core-resource-directory], where the Server may have 818 registered the links to its resources. 820 In order to enable the above, this section defines a number of 821 parameters, each of which can be optionally specified as a target 822 attribute with the same name in the link to the respective EDHOC 823 resource, or as filter criteria in a discovery request from the 824 Client. When specifying these parameters in a link to an EDHOC 825 resource, the target attribute rt="core.edhoc" MUST be included, and 826 the same consistency rules defined in Section 5 for the corresponding 827 information elements of an applicability statement MUST be followed. 829 The following parameters are defined. 831 * 'method', specifying an authentication method supported by the 832 Server. This parameter MUST specify a single value, which is 833 taken from the 'Value' column of the "EDHOC Method Type" registry 834 defined in Section 9.3 of [I-D.ietf-lake-edhoc]. This parameter 835 MAY occur multiple times, with each occurrence specifying a 836 different authentication method. 838 * 'csuite', specifying an EDHOC cipher suite supported by the 839 Server. This parameter MUST specify a single value, which is 840 taken from the 'Value' column of the "EDHOC Cipher Suites" 841 registry defined in Section 9.2 of [I-D.ietf-lake-edhoc]. This 842 parameter MAY occur multiple times, with each occurrence 843 specifying a different cipher suite. 845 * 'cred_t', specifying a type of authentication credential supported 846 by the Server. This parameter MAY occur multiple times, with each 847 occurrence specifying a different authentication credential type. 848 Possible values are: "x509", for X.509 certificate [RFC5280]; 849 "c509", for C509 certificate [I-D.ietf-cose-cbor-encoded-cert]; 850 "cwt" for CWT [RFC8392]; "ccs" for CWT Claims Set (CCS) [RFC8392]. 852 * 'idcred_t', specifying the type of identifiers supported by the 853 Server for identifying authentication credentials. This parameter 854 MUST specify a single value, which is taken from the 'Label' 855 column of the "COSE Headers Parameters" registry 856 [COSE.Header.Parameters]. This parameter MAY occur multiple 857 times, with each occurrence specifying a different type of 858 identifier for authentication credentials. 860 Note that the values in the 'Label' column of the "COSE Headers 861 Parameters" registry are strongly typed. On the contrary, Link 862 Format is weakly typed and thus does not distinguish between, for 863 instance, the string value "-10" and the integer value -10. Thus, 864 if responses in Link Format are returned, string values which look 865 like an integer are not supported. Therefore, such values MUST 866 NOT be used in the 'idcred_t' parameter. 868 * 'ead_1', 'ead_2', 'ead_3' and 'ead_4', specifying, if present, 869 that the Server supports the use of External Authorization Data 870 EAD_1, EAD_2, EAD_3 and EAD_4, respectively (see Section 3.8 of 871 [I-D.ietf-lake-edhoc]). For each of these parameters, the 872 following applies. 874 - It MUST occur at most once, with its presence denoting support 875 from the server for the respective external authorization data. 877 - It MUST specify a single value, which is taken from the 'Label' 878 column of the "EDHOC External Authorization Data" registry 879 defined in Section 9.5 of [I-D.ietf-lake-edhoc]. 881 * 'comb_req', specifying, if present, that the server supports the 882 EDHOC + OSCORE request defined in Section 3. A value MUST NOT be 883 given to this parameter and any present value MUST be ignored by 884 parsers. 886 * 'osc_id_conv', specifying, if present, that the method to convert 887 from OSCORE to EDHOC identifiers defined in Section 4 is used. A 888 value MUST NOT be given to this parameter and any present value 889 MUST be ignored by parsers. 891 The absence of this parameter does not mean that the method 892 defined in Section 4 is not used. Also, consistently with 893 Section 5, the presence of the 'comb_req' parameter implies the 894 use of the method defined in Section 4, and thus makes the 895 additional presence of the 'osc_id_conv' parameter unnecessary. 897 The example in Figure 6 shows how a Client discovers two EDHOC 898 resources at a Server, obtaining information elements from the 899 respective applicability statements. The Link Format notation from 900 Section 5 of [RFC6690] is used. 902 REQ: GET /.well-known/core 904 RES: 2.05 Content 905 ;osc, 906 ;if="sensor", 907 ;rt="core.edhoc";csuite="0";csuite="2";method="0"; 908 cred_t="c509";cred_t="ccs";idcred_t="4";comb_req, 909 ;rt="core.edhoc";csuite="0";csuite="2";method="0"; 910 method="3";cred_t="c509";cred_t="x509";idcred_t="34";osc_id_conv 912 Figure 6: The Web Link 914 7. Security Considerations 916 The same security considerations from OSCORE [RFC8613] and EDHOC 917 [I-D.ietf-lake-edhoc] hold for this document. 919 TODO: more considerations 921 8. IANA Considerations 923 RFC Editor: Please replace "[[this document]]" with the RFC number of 924 this document and delete this paragraph. 926 This document has the following actions for IANA. 928 8.1. CoAP Option Numbers Registry 930 IANA is asked to enter the following option number to the "CoAP 931 Option Numbers" registry within the "CoRE Parameters" registry group. 933 [ 934 The CoAP option numbers 13 and 21 are both consistent with the 935 properties of the EDHOC Option defined in Section 3.1, and they both 936 allow the EDHOC Option to always result in an overall size of 1 byte. 937 This is because: 939 * The EDHOC option is always empty, i.e., with zero-length value; 940 and 942 * Since the OSCORE option with option number 9 is always present in 943 the CoAP request, the EDHOC option would be encoded with a maximum 944 delta of 4 or 12, depending on its option number being 13 or 21. 946 At the time of writing, the CoAP option numbers 13 and 21 are both 947 unassigned in the "CoAP Option Numbers" registry, as first available 948 and consistent option numbers for the EDHOC option. 950 This document suggests 21 (TBD21) as option number to be assigned to 951 the new EDHOC option, since both 13 and 21 are consistent for the use 952 case in question, but different use cases or protocols may make 953 better use of the option number 13. 955 ] 957 +--------+-------+-------------------+ 958 | Number | Name | Reference | 959 +--------+-------+-------------------+ 960 | TBD21 | EDHOC | [[this document]] | 961 +--------+-------+-------------------+ 963 9. References 965 9.1. Normative References 967 [COSE.Header.Parameters] 968 IANA, "COSE Header Parameters", 969 . 972 [I-D.ietf-core-resource-directory] 973 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 974 D. Stok, "CoRE Resource Directory", Work in Progress, 975 Internet-Draft, draft-ietf-core-resource-directory-28, 7 976 March 2021, . 979 [I-D.ietf-lake-edhoc] 980 Selander, G., Mattsson, J. P., and F. Palombini, 981 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 982 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 983 October 2021, . 986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 987 Requirement Levels", BCP 14, RFC 2119, 988 DOI 10.17487/RFC2119, March 1997, 989 . 991 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 992 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 993 . 995 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 996 Application Protocol (CoAP)", RFC 7252, 997 DOI 10.17487/RFC7252, June 2014, 998 . 1000 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1001 the Constrained Application Protocol (CoAP)", RFC 7959, 1002 DOI 10.17487/RFC7959, August 2016, 1003 . 1005 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1006 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1007 May 2017, . 1009 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 1010 DOI 10.17487/RFC8288, October 2017, 1011 . 1013 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1014 "Object Security for Constrained RESTful Environments 1015 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1016 . 1018 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1019 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1020 . 1022 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1023 Representation (CBOR)", STD 94, RFC 8949, 1024 DOI 10.17487/RFC8949, December 2020, 1025 . 1027 9.2. Informative References 1029 [I-D.ietf-cose-cbor-encoded-cert] 1030 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 1031 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 1032 Certificates)", Work in Progress, Internet-Draft, draft- 1033 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 1034 . 1037 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1038 Housley, R., and W. Polk, "Internet X.509 Public Key 1039 Infrastructure Certificate and Certificate Revocation List 1040 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1041 . 1043 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1044 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1045 May 2018, . 1047 Appendix A. Checking CBOR Encoding of Numeric Values 1049 A binary string of N bytes in size is a valid CBOR encoding of an 1050 integer value if and only if both the following conditions hold, with 1051 reference to the table below. 1053 * The size N is one of the values specified in the "Size" column. 1055 * The first byte of the binary string is equal to one of the byte 1056 values specified in the "First byte" column, exactly for the row 1057 having N as value of the "Size" column. 1059 +------+-----------------------+ 1060 | Size | First byte | 1061 +------+-----------------------+ 1062 | 1 | 0x00-0x17 , 0x20-0x37 | 1063 +------+-----------------------+ 1064 | 2 | 0x18 , 0x38 | 1065 +------+-----------------------+ 1066 | 3 | 0x19 , 0x39 | 1067 +------+-----------------------+ 1068 | 5 | 0x1A , 0x3A | 1069 +------+-----------------------+ 1070 | 9 | 0x1B , 0x3B | 1071 +------+-----------------------+ 1073 Appendix B. Document Updates 1075 RFC Editor: Please remove this section. 1077 B.1. Version -02 to -03 1079 * Clarifications on transporting EDHOC message_3 in the CoAP 1080 payload. 1082 * At most one simultaneous outstanding interaction as an EDHOC + 1083 OSCORE request with the same server for the same session with 1084 connection identifier C_R. 1086 * The EDHOC option is removed from the EDHOC + OSCORE request after 1087 processing the EDHOC data. 1089 * Added explicit constraints when selecting a Recipient ID as C_X. 1091 * Added processing steps for when Block-wise is used. 1093 * Improved error handling on the Server. 1095 * Improved section on Web Linking. 1097 * Updated figures; editorial improvements. 1099 B.2. Version -01 to -02 1101 * New title, abstract and introduction. 1103 * Restructured table of content. 1105 * Alignment with latest format of EDHOC messages. 1107 * Guideline on ID conversions based on applicability statement. 1109 * Clarifications, extension and consistency on applicability 1110 statement. 1112 * Section on web-linking. 1114 * RFC8126 terminology in IANA considerations. 1116 * Revised Appendix "Checking CBOR Encoding of Numeric Values". 1118 B.3. Version -00 to -01 1120 * Improved background overview of EDHOC. 1122 * Added explicit rules for converting OSCORE Sender/Recipient IDs to 1123 EDHOC connection identifiers following the removal of 1124 bstr_identifier from EDHOC. 1126 * Revised section organization. 1128 * Recommended number for EDHOC option changed to 21. 1130 * Editorial improvements. 1132 Acknowledgments 1134 The authors sincerely thank Christian Amsuess, Esko Dijk, Klaus 1135 Hartke, Jim Schaad and Malisa Vucinic for their feedback and 1136 comments. 1138 The work on this document has been partly supported by VINNOVA and 1139 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1140 (Grant agreement 952652). 1142 Authors' Addresses 1144 Francesca Palombini 1145 Ericsson 1146 Email: francesca.palombini@ericsson.com 1148 Marco Tiloca 1149 RISE AB 1150 Isafjordsgatan 22 1151 SE-16440 Stockholm Kista 1152 Sweden 1153 Email: marco.tiloca@ri.se 1155 Rikard Hoeglund 1156 RISE AB 1157 Isafjordsgatan 22 1158 SE-16440 Stockholm Kista 1159 Sweden 1160 Email: rikard.hoglund@ri.se 1162 Stefan Hristozov 1163 Fraunhofer AISEC 1164 Email: stefan.hristozov@eriptic.com 1166 Goeran Selander 1167 Ericsson 1168 Email: goran.selander@ericsson.com