idnits 2.17.1 draft-ietf-core-oscore-edhoc-02.txt: -(880): 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 (25 October 2021) is 908 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-02 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: 28 April 2022 R. Hoeglund 6 RISE AB 7 S. Hristozov 8 Fraunhofer AISEC 9 G. Selander 10 Ericsson 11 25 October 2021 13 Profiling EDHOC for CoAP and OSCORE 14 draft-ietf-core-oscore-edhoc-02 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 28 April 2022. 56 Copyright Notice 58 Copyright (c) 2021 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 Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . 6 76 3.1. EDHOC Option . . . . . . . . . . . . . . . . . . . . . . 8 77 3.2. Client Processing . . . . . . . . . . . . . . . . . . . . 9 78 3.3. Server Processing . . . . . . . . . . . . . . . . . . . . 9 79 3.4. Example of EDHOC + OSCORE Request . . . . . . . . . . . . 11 80 4. Conversion from OSCORE to EDHOC Identifiers . . . . . . . . . 12 81 4.1. Conversion Method . . . . . . . . . . . . . . . . . . . . 13 82 4.2. Additional Processing of EDHOC Messages . . . . . . . . . 14 83 4.2.1. Initiator Processing of Message 1 . . . . . . . . . . 14 84 4.2.2. Responder Processing of Message 1 . . . . . . . . . . 14 85 4.2.3. Responder Processing of Message 2 . . . . . . . . . . 15 86 4.2.4. Initiator Processing of Message 2 . . . . . . . . . . 15 87 5. Extension and Consistency of Applicability Statement . . . . 15 88 6. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 8.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 19 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 94 9.2. Informative References . . . . . . . . . . . . . . . . . 21 95 Appendix A. Checking CBOR Encoding of Numeric Values . . . . . . 21 96 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 22 97 B.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 22 98 B.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 22 99 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 102 1. Introduction 104 Ephemeral Diffie-Hellman Over COSE (EDHOC) [I-D.ietf-lake-edhoc] is a 105 lightweight authenticated key exchange protocol, especially intended 106 for use in constrained scenarios. In particular, EDHOC messages can 107 be transported over the Constrained Application Protocol (CoAP) 108 [RFC7252] and used for establishing a Security Context for Object 109 Security for Constrained RESTful Environments (OSCORE) [RFC8613]. 111 This document profiles this use of the EDHOC protocol, and specifies 112 a number of additional and optional mechanisms. These especially 113 include an optimization approach, that combines the EDHOC execution 114 with the first subsequent OSCORE transaction (see Section 3). This 115 allows for a minimum number of round trips necessary to setup the 116 OSCORE Security Context and complete an OSCORE transaction, e.g., 117 when an IoT device gets configured in a network for the first time. 119 This optimization is desirable, since the number of protocol round 120 trips impacts on the minimum number of flights, which in turn can 121 have a substantial impact on the latency of conveying the first 122 OSCORE request, when using certain radio technologies. 124 Without this optimization, it is not possible, not even in theory, to 125 achieve the minimum number of flights. This optimization makes it 126 possible also in practice, since the last message of the EDHOC 127 protocol can be made relatively small (see Section 1.3 of 128 [I-D.ietf-lake-edhoc]), thus allowing additional OSCORE protected 129 CoAP data within target MTU sizes. 131 Furthermore, this document defines: 133 * A method for deterministically converting an OSCORE Sender/ 134 Recipient ID to a corresponding EDHOC connection identifier (see 135 Section 4). While this method is required to be used when using 136 the optimization above, it is recommended in general, since it 137 ensures that an OSCORE Sender/Recipient ID is always converted to 138 the EDHOC identifier with the smallest size. 140 * A number of parameters corresponding to different information 141 elements of an EDHOC applicability statement (see Section 6). 142 These can be specified as target attributes in the link to an 143 EDHOC resource associated to that applicability statement, thus 144 enabling an enhanced discovery of such resource for CoAP clients. 146 1.1. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in 151 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 The reader is expected to be familiar with terms and concepts defined 155 in CoAP [RFC7252], CBOR [RFC8949], CBOR sequences [RFC8742], OSCORE 156 [RFC8613] and EDHOC [I-D.ietf-lake-edhoc]. 158 2. EDHOC Overview 160 The EDHOC protocol allows two peers to agree on a cryptographic 161 secret, in a mutually-authenticated way and by using Diffie-Hellman 162 ephemeral keys to achieve perfect forward secrecy. The two peers are 163 denoted as Initiator and Responder, as the one sending or receiving 164 the initial EDHOC message_1, respectively. 166 After successful processing of EDHOC message_3, both peers agree on a 167 cryptographic secret that can be used to derive further security 168 material, and especially to establish an OSCORE Security Context 169 [RFC8613]. The Responder can also send an optional EDHOC message_4 170 to achieve key confirmation, e.g., in deployments where no protected 171 application message is sent from the Responder to the Initiator. 173 Appendix A.3 of [I-D.ietf-lake-edhoc] specifies how to transfer EDHOC 174 over CoAP. That is, the EDHOC data (referred to as "EDHOC messages") 175 are transported in the payload of CoAP requests and responses. The 176 default message flow consists in the CoAP Client acting as Initiator 177 and the CoAP Server acting as Responder. Alternatively, the two 178 roles can be reversed. In the rest of this document, EDHOC messages 179 are considered to be transferred over CoAP. 181 Figure 1 shows a CoAP Client and Server running EDHOC as Initiator 182 and Responder, respectively. That is, the Client sends a POST 183 request to a reserved EDHOC resource at the Server, by default at the 184 Uri-Path "/.well-known/edhoc". The request payload consists of the 185 CBOR simple value "true" (0xf5) concatenated with EDHOC message_1, 186 which also includes the EDHOC connection identifier C_I of the 187 Client. 189 This triggers the EDHOC exchange at the Server, which replies with a 190 2.04 (Changed) response. The response payload consists of EDHOC 191 message_2, which also includes the EDHOC connection identifier C_R of 192 the Server. The Content-Format of the response may be set to 193 "application/edhoc". 195 Finally, the Client sends a POST request to the same EDHOC resource 196 used earlier to send EDHOC message_1. The request payload consists 197 of the EDHOC connection identifier C_R, concatenated with EDHOC 198 message_3. 200 After this exchange takes place, and after successful verifications 201 as specified in the EDHOC protocol, the Client and Server can derive 202 an OSCORE Security Context, as defined in Appendix A.2 of 203 [I-D.ietf-lake-edhoc]. After that, they can use OSCORE to protect 204 their communications as per [RFC8613]. 206 The Client and Server are required to agree in advance on certain 207 information and parameters describing how they should use EDHOC. 208 These are specified in an applicability statement see Section 3.9 of 209 [I-D.ietf-lake-edhoc], associated to the used EDHOC resource. 211 CoAP Client CoAP Server 212 (EDHOC Initiator) (EDHOC Responder) 213 | | 214 | | 215 | ----------------- EDHOC Request ---------------> | 216 | Header: 0.02 (POST) | 217 | Uri-Path: "/.well-known/edhoc" | 218 | Payload: true, EDHOC message_1 | 219 | | 220 | <---------------- EDHOC Response---------------- | 221 | Header: 2.04 (Changed) | 222 | Content-Format: application/edhoc | 223 | Payload: EDHOC message_2 | 224 | | 225 EDHOC verification | 226 | | 227 | ----------------- EDHOC Request ---------------> | 228 | Header: 0.02 (POST) | 229 | Uri-Path: "/.well-known/edhoc" | 230 | Payload: C_R, EDHOC message_3 | 231 | | 232 | EDHOC verification 233 | + 234 OSCORE Sec Ctx OSCORE Sec Ctx 235 Derivation Derivation 236 | | 237 | ---------------- OSCORE Request ---------------> | 238 | Header: 0.02 (POST) | 239 | | 240 | <--------------- OSCORE Response --------------- | 241 | Header: 2.04 (Changed) | 242 | | 243 Figure 1: EDHOC and OSCORE run sequentially 245 As shown in Figure 1, this purely-sequential flow where EDHOC is run 246 first and then OSCORE is used takes three round trips to complete. 248 Section 3 defines an optimization for combining EDHOC with the first 249 subsequent OSCORE transaction. This reduces the number of round 250 trips required to set up an OSCORE Security Context and to complete 251 an OSCORE transaction using that Security Context. 253 3. EDHOC Combined with OSCORE 255 This section defines an optimization for combining the EDHOC exchange 256 with the first subsequent OSCORE transaction, thus minimizing the 257 number of round trips between the two peers. 259 This approach can be used only if the default EDHOC message flow is 260 used, i.e., when the Client acts as Initiator and the Server acts as 261 Responder, while it cannot be used in the case with reversed roles. 263 When running the purely-sequential flow of Section 2, the Client has 264 all the information to derive the OSCORE Security Context already 265 after receiving EDHOC message_2 and before sending EDHOC message_3. 267 Hence, the Client can potentially send both EDHOC message_3 and the 268 subsequent OSCORE Request at the same time. On a semantic level, 269 this requires sending two REST requests at once, as in Figure 2. 271 CoAP Client CoAP Server 272 (EDHOC Initiator) (EDHOC Responder) 273 | | 274 | ----------------- EDHOC Request ---------------> | 275 | Header: 0.02 (POST) | 276 | Uri-Path: "/.well-known/edhoc" | 277 | Payload: true, EDHOC message_1 | 278 | | 279 | <---------------- EDHOC Response---------------- | 280 | Header: Changed (2.04) | 281 | Content-Format: application/edhoc | 282 | Payload: EDHOC message_2 | 283 | | 284 EDHOC verification | 285 + | 286 OSCORE Sec Ctx | 287 Derivation | 288 | | 289 | ------------ EDHOC + OSCORE Request -----------> | 290 | Header: 0.02 (POST) | 291 | | 292 | EDHOC verification 293 | + 294 | OSCORE Sec Ctx 295 | Derivation 296 | | 297 | <-------------- OSCORE Response ---------------- | 298 | Header: 2.04 (Changed) | 299 | | 301 Figure 2: EDHOC and OSCORE combined 303 To this end, the specific approach defined in this section consists 304 of sending a single EDHOC + OSCORE request, which conveys the pair 305 (C_R, EDHOC message_3) within an OSCORE protected CoAP message. 307 That is, the EDHOC + OSCORE request is in practice the OSCORE Request 308 from Figure 1, as still sent to a protected resource and with the 309 correct CoAP method and options intended for accessing that resource. 310 At the same time, the EDHOC + OSCORE request also transports the pair 311 (C_R, EDHOC message_3) required for completing the EDHOC exchange. 313 As EDHOC message_3 may be too large to be included in a CoAP Option, 314 e.g., if containing a large public key certificate chain, it has to 315 be transported in the CoAP payload of the EDHOC + OSCORE request. 317 The rest of this section specifies how to transport the data in the 318 EDHOC + OSCORE request and their processing order. In particular, 319 the use of this approach is explicitly signalled by including an 320 EDHOC Option (see Section 3.1) in the EDHOC + OSCORE request. The 321 processing of the EDHOC + OSCORE request is specified in Section 3.2 322 for the Client side and in Section 3.3 for the Server side. 324 3.1. EDHOC Option 326 This section defines the EDHOC Option. The option is used in a CoAP 327 request, to signal that the request payload conveys both an EDHOC 328 message_3 and OSCORE protected data, combined together. 330 The EDHOC Option has the properties summarized in Figure 3, which 331 extends Table 4 of [RFC7252]. The option is Critical, Safe-to- 332 Forward, and part of the Cache-Key. The option MUST occur at most 333 once and is always empty. If any value is sent, the value is simply 334 ignored. The option is intended only for CoAP requests and is of 335 Class U for OSCORE [RFC8613]. 337 +-------+---+---+---+---+-------+--------+--------+---------+ 338 | No. | C | U | N | R | Name | Format | Length | Default | 339 +-------+---+---+---+---+-------+--------+--------+---------+ 340 | TBD21 | x | | | | EDHOC | Empty | 0 | (none) | 341 +-------+---+---+---+---+-------+--------+--------+---------+ 342 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 344 Figure 3: The EDHOC Option. 346 The presence of this option means that the message payload contains 347 also EDHOC data, that must be extracted and processed as defined in 348 Section 3.3, before the rest of the message can be processed. 350 Figure 4 shows the format of a CoAP message containing both the EDHOC 351 data and the OSCORE ciphertext, using the newly defined EDHOC option 352 for signalling. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |Ver| T | TKL | Code | Message ID | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Token (if any, TKL bytes) ... 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | OSCORE option | EDHOC option | Other options (if any) ... 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |1 1 1 1 1 1 1 1| Payload 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 4: CoAP message for EDHOC and OSCORE combined - signalled 366 with the EDHOC Option 368 3.2. Client Processing 370 The Client prepares an EDHOC + OSCORE request as follows. 372 1. Compose EDHOC message_3 as per Section 5.4.2 of 373 [I-D.ietf-lake-edhoc]. 375 2. Encrypt the original CoAP request as per Section 8.1 of 376 [RFC8613], using the new OSCORE Security Context established 377 after receiving EDHOC message_2. 379 Note that the OSCORE ciphertext is not computed over EDHOC 380 message_3, which is not protected by OSCORE. That is, the result 381 of this step is the OSCORE Request as in Figure 1. 383 3. Build a CBOR sequence [RFC8742] composed of two CBOR byte strings 384 in the following order. 386 * The first CBOR byte string is the EDHOC message_3 resulting 387 from step 1. 389 * The second CBOR byte string has as value the OSCORE ciphertext 390 of the OSCORE protected CoAP request resulting from step 2. 392 4. Compose the EDHOC + OSCORE request, as the OSCORE protected CoAP 393 request resulting from step 2, where the payload is replaced with 394 the CBOR sequence built at step 3. 396 Note that the new payload includes EDHOC message_3, but it does 397 not include the EDHOC connection identifier C_R. As the Client 398 is the EDHOC Initiator, C_R encodes the OSCORE Sender ID of the 399 Client, which is already specified as 'kid' in the OSCORE Option 400 of the request from step 2, hence of the EDHOC + OSCORE request. 402 5. Signal the usage of this approach, by including the new EDHOC 403 Option defined in Section 3.1 into the EDHOC + OSCORE request. 405 3.3. Server Processing 407 When receiving a request containing the EDHOC option, i.e., an EDHOC 408 + OSCORE request, the Server MUST perform the following steps. 410 1. Check that the payload of the EDHOC + OSCORE request is a CBOR 411 sequence composed of two CBOR byte strings. If this is not the 412 case, the Server MUST stop processing the request and MUST reply 413 with a 4.00 (Bad Request) error response. 415 2. Extract EDHOC message_3 from the payload of the EDHOC + OSCORE 416 request, as the first CBOR byte string in the CBOR sequence. 418 3. Take the value of 'kid' from the OSCORE option of the EDHOC + 419 OSCORE request (i.e., the OSCORE Sender ID of the Client), and 420 use it to rebuild the EDHOC connection identifier C_R, as per 421 Section 4.1. 423 4. Retrieve the correct EDHOC session by using the connection 424 identifier C_R rebuilt at step 3. 426 If the applicability statement used in the EDHOC session 427 specifies that EDHOC message_4 shall be sent, the Server MUST 428 stop the EDHOC processing and consider it failed, as due to a 429 client error. 431 Otherwise, perform the EDHOC processing on the EDHOC message_3 432 extracted at step 2 as per Section 5.4.3 of 433 [I-D.ietf-lake-edhoc], based on the protocol state of the 434 retrieved EDHOC session. 436 The applicability statement used in the EDHOC session is the same 437 one associated to the EDHOC resource where the server received 438 the request conveying EDHOC message_1 that started the session. 439 This is relevant in case the server provides multiple EDHOC 440 resources, which may generally refer to different applicability 441 statements. 443 5. Establish a new OSCORE Security Context associated to the client 444 as per Appendix A.2 of [I-D.ietf-lake-edhoc], using the EDHOC 445 output from step 4. 447 6. Extract the OSCORE ciphertext from the payload of the EDHOC + 448 OSCORE request, as the value of the second CBOR byte string in 449 the CBOR sequence. 451 7. Rebuild the OSCORE protected CoAP request as the EDHOC + OSCORE 452 request, where the payload is replaced with the OSCORE ciphertext 453 extracted at step 6. 455 8. Decrypt and verify the OSCORE protected CoAP request rebuilt at 456 step 7, as per Section 8.2 of [RFC8613], by using the OSCORE 457 Security Context established at step 5. 459 9. Deliver the CoAP request resulting from step 8 to the 460 application. 462 If steps 4 (EDHOC processing) and 8 (OSCORE processing) are both 463 successfully completed, the Server MUST reply with an OSCORE 464 protected response, in order for the Client to achieve key 465 confirmation (see Section 5.4.2 of [I-D.ietf-lake-edhoc]). The usage 466 of EDHOC message_4 as defined in Section 5.5 of [I-D.ietf-lake-edhoc] 467 is not applicable to the approach defined in this document. 469 If step 4 (EDHOC processing) fails, the server discontinues the 470 protocol as per Section 5.4.3 of [I-D.ietf-lake-edhoc] and responds 471 with an EDHOC error message with error code 1, formatted as defined 472 in Section 6.2 of [I-D.ietf-lake-edhoc]. In particular, the CoAP 473 response conveying the EDHOC error message MUST have Content-Format 474 set to application/edhoc defined in Section 9.12 of 475 [I-D.ietf-lake-edhoc]. 477 If step 4 (EDHOC processing) is successfully completed but step 8 478 (OSCORE processing) fails, the same OSCORE error handling as defined 479 in Section 8.2 of [RFC8613] applies. 481 3.4. Example of EDHOC + OSCORE Request 483 Figure 5 shows an example of EDHOC + OSCORE Request. In particular, 484 the example assumes that: 486 * The used OSCORE Partial IV is 0, consistently with the first 487 request protected with the new OSCORE Security Context. 489 * The OSCORE Sender ID of the Client is 0x01. 491 As per Section 4.1, this corresponds to the numeric EDHOC 492 connection identifier C_R with value 1. When using the purely- 493 sequential flow shown in Figure 1, this would be prepended to 494 EDHOC message_3 as the CBOR integer 1 (0x01 in CBOR encoding), in 495 the payload of the second EDHOC request. 497 * The EDHOC option is registered with CoAP option number 21. 499 o OSCORE option value: 0x090001 (3 bytes) 501 o EDHOC option value: - (0 bytes) 503 o EDHOC message_3: 0x52d5535f3147e85f1cfacd9e78abf9e0a81bbf (19 bytes) 505 o OSCORE ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes) 507 From there: 509 o Protected CoAP request (OSCORE message): 511 0x44025d1f ; CoAP 4-byte header 512 00003974 ; Token 513 39 6c6f63616c686f7374 ; Uri-Host Option: "localhost" 514 63 090001 ; OSCORE Option 515 c0 ; EDHOC Option 516 ff 52d5535f3147e85f1cfacd9e78abf9e0a81bbf 517 4d612f1092f1776f1c1668b3825e 518 (57 bytes) 520 Figure 5: Example of CoAP message with EDHOC and OSCORE combined 522 4. Conversion from OSCORE to EDHOC Identifiers 524 Appendix A.1 of [I-D.ietf-lake-edhoc] defines how an EDHOC connection 525 identifier is converted to an OSCORE Sender/Recipient ID. 527 In the following, Section 4.1 defines a method for converting from 528 OSCORE Sender/Recipient ID to EDHOC connection identifier. 530 When running EDHOC through a certain EDHOC resource, the Client and 531 Server MUST both use the conversion method defined in Section 4.1 and 532 MUST perform the additional message processing specified in 533 Section 4.2, if at least one of the following conditions hold. 535 * The applicability statement associated to the EDHOC resource 536 indicates that the server supports the EDHOC + OSCORE request 537 defined in Section 3. 539 * The applicability statement associated to the EDHOC resource 540 indicates that the conversion method defined in Section 4.1 is the 541 one to use. 543 Instead, if none of the above conditions hold, the Client and the 544 Server can independently use any consistent conversion method, such 545 as the one defined in Section 4.1 or different ones defined in 546 separate specifications. In particular, the Client and Server are 547 not required to use the same conversion method. In fact, as per 548 Appendix A.1 of [I-D.ietf-lake-edhoc], it is sufficient that the two 549 connection identifiers C_I and C_R exchanged during an EDHOC 550 execution are different and not "equivalent", hence not convertible 551 to the same OSCORE Sender/Recipient ID. 553 Even in case none of the above conditions hold, it is RECOMMENDED for 554 the Client and Server to use the conversion method defined in 555 Section 4.1, since it ensures that an OSCORE Sender/Recipient ID is 556 always converted to the EDHOC identifier with the smallest size among 557 the two equivalent ones. 559 4.1. Conversion Method 561 The process defined in this section ensures that every OSCORE Sender/ 562 Recipient ID is converted to only one of the two corresponding, 563 equivalent EDHOC connection identifiers, see Appendix A.1 of 564 [I-D.ietf-lake-edhoc]. 566 An OSCORE Sender/Recipient ID, OSCORE_ID, is converted to an EDHOC 567 connection identifier, EDHOC_ID, as follows. 569 * If OSCORE_ID is 0 bytes in size, it is converted to the empty byte 570 string EDHOC_ID (0x40 in CBOR encoding). 572 * If OSCORE_ID has a size in bytes different than 0, 1, 2, 3, 5 or 573 9, it is converted to a byte-valued EDHOC_ID, i.e., a CBOR byte 574 string with value OSCORE_ID. 576 For example, the OSCORE_ID 0x001122334455 is converted to the 577 byte-valued EDHOC_ID 0x001122334455 (0x46001122334455 in CBOR 578 encoding). 580 * If OSCORE_ID has a size in bytes equal to 1, 2, 3, 5 or 9 the 581 following applies. 583 - If OSCORE_ID is a valid CBOR encoding for an integer value 584 (i.e., it can be correctly decoded as a CBOR integer), then it 585 is converted to a numeric EDHOC_ID having OSCORE_ID as its CBOR 586 encoded form. 588 For example, the OSCORE_ID 0x01 is converted to the numeric 589 EDHOC_ID 1 (0x01 in CBOR encoding), while the OSCORE_ID 0x2B is 590 converted to the numeric EDHOC_ID -12 (0x2B in CBOR encoding). 592 - If OSCORE_ID is _not_ a valid CBOR encoding for an integer 593 value (i.e., it _cannot_ be correctly decoded as a CBOR 594 integer), then it is converted to a byte-valued EDHOC_ID having 595 OSCORE_ID as its value. 597 For example, the OSCORE_ID 0xFF is converted to the byte-valued 598 EDHOC_ID 0xFF (0x41FF in CBOR encoding). 600 Implementations can easily determine which case holds for a given 601 OSCORE_ID with no need to try to actually CBOR-decode it, e.g., by 602 using the approach in Appendix A. 604 When performing the conversions above, the two peers MUST always 605 refer to Deterministically Encoded CBOR as specified in Section 4.2.1 606 of [RFC8949], consistently with what is required by the EDHOC 607 protocol [I-D.ietf-lake-edhoc]. 609 4.2. Additional Processing of EDHOC Messages 611 This section specifies additional EDHOC message processing compared 612 to what is specified in Section 5 of [I-D.ietf-lake-edhoc]. 614 4.2.1. Initiator Processing of Message 1 616 The Initiator selects C_I as follows. 618 1. The Initiator initializes a set ID_SET as the empty set. 620 2. The Initiator selects an available OSCORE Recipient ID, ID*, 621 which is not included in ID_SET. 623 3. The Initiator converts ID* to the EDHOC connection identifier 624 C_I, as per Section 4.1. 626 4. If the resulting C_I is already used, the Initiator adds ID* to 627 ID_SET and moves back to step 2. Otherwise, it uses C_I as its 628 EDHOC connection identifier. 630 4.2.2. Responder Processing of Message 1 632 The Responder MUST discontinue the protocol and reply with an EDHOC 633 error message with error code 1, formatted as defined in Section 6.2 634 of [I-D.ietf-lake-edhoc], if C_I is a CBOR byte string and it has as 635 value a valid CBOR encoding of an integer value (e.g., C_I is CBOR 636 encoded as 0x4100). 638 In fact, this would mean that the Initiator has not followed the 639 conversion rule in Section 4.1 when converting its (to be) OSCORE 640 Recipient ID to C_I. 642 4.2.3. Responder Processing of Message 2 644 The Responder selects C_R as follows. 646 1. The Responder initializes a set ID_SET as the empty set. 648 2. The Responder selects an available OSCORE Recipient ID, ID*, 649 which is not included in ID_SET. 651 3. The Responder converts ID* to the EDHOC connection identifier 652 C_R, as per Section 4.1. 654 4. If the resulting C_R is already used or it is equal byte-by-byte 655 to the C_I specified in EDHOC message_1, the Initiator adds ID* 656 to ID_SET and moves back to step 2. Otherwise, it uses C_R as 657 its EDHOC connection identifier. 659 4.2.4. Initiator Processing of Message 2 661 If any of the following conditions holds, the Initiator MUST 662 discontinue the protocol and reply with an EDHOC error message with 663 error code 1, formatted as defined in Section 6.2 of 664 [I-D.ietf-lake-edhoc]. 666 * C_R is equal byte-by-byte to the C_I that was specified in EDHOC 667 message_1. 669 * C_R is a CBOR byte string and it has as value a valid CBOR 670 encoding of an integer value (e.g., C_R is CBOR encoded as 671 0x4100). 673 In fact, this would mean that the Responder has not followed the 674 conversion rule in Section 4.1 when converting its (to be) OSCORE 675 Recipient ID to C_R. 677 5. Extension and Consistency of Applicability Statement 679 The applicability statement referred by the Client and Server can 680 include the information elements introduced below, in accordance with 681 the specified consistency rules. 683 If the Server supports the EDHOC + OSCORE request within an EDHOC 684 execution started at a certain EDHOC resource, then the applicability 685 statement associated to that resource: 687 * MUST NOT specify that EDHOC message_4 shall be sent. 689 * SHOULD explicitly specify support for the EDHOC + OSCORE request. 691 * SHOULD explicitly specify that the method to convert from EDHOC to 692 OSCORE identifiers is the one defined in Section 4 and MUST NOT 693 specify any other method than that. 695 If the support for the EDHOC + OSCORE request is explicitly 696 specified and the method defined in Section 4 is not explicitly 697 specified, then the Client and Server MUST use it as conversion 698 method. 700 If the Server does not support the EDHOC + OSCORE request within an 701 EDHOC execution started at a certain EDHOC resource, then the 702 applicability statement associated to that resource MAY specify a 703 method to convert from EDHOC to OSCORE identifiers. In such a case, 704 the Client and Server MUST use the specified conversion method, which 705 MAY be the one defined in Section 4. 707 6. Web Linking 709 Section 9.13 of [I-D.ietf-lake-edhoc] registers the resource type 710 "core.edhoc", which can be used as target attribute in a web link 711 [RFC8288] to an EDHOC resource, e.g., using a link-format document 712 [RFC6690]. This enables Clients to discover the presence of EDHOC 713 resources at a Server, possibly using the resource type as filter 714 criterion. 716 At the same time, the applicability statement associated to an EDHOC 717 resource provides a number of information describing how the EDHOC 718 protocol can be used through that resource. While a Client may 719 become aware of the applicability statement through several means, it 720 would be convenient to obtain its information elements upon 721 discovering the EDHOC resources at the Server. This might aim at 722 discovering especially the EDHOC resources whose associated 723 applicability statement denotes a way of using EDHOC which is most 724 suitable to the Client, e.g., with EDHOC cipher suites or 725 authentication methods that the Client also supports or prefers. 727 That is, it would be convenient that a Client discovering an EDHOC 728 resource contextually obtains relevant pieces of information from the 729 applicability statement associated to that resource. The resource 730 discovery can occur by means of a direct interaction with the Server, 731 or instead by means of the CoRE Resource Directory 732 [I-D.ietf-core-resource-directory], where the Server may have 733 registered the links to its resources. 735 In order to enable the above, this section defines a number of 736 parameters, each of which can be optionally specified as a target 737 attribute with the same name in the link to the respective EDHOC 738 resource, or as filter criteria in a discovery request from the 739 Client. When specifying these parameters in a link to an EDHOC 740 resource, the target attribute rt="core.edhoc" MUST be included, and 741 the same consistency rules defined in Section 5 for the corresponding 742 information elements of an applicability statement MUST be followed. 744 The following parameters are defined. 746 * 'method', specifying an authentication method supported by the 747 Server. This parameter MUST specify a single value, which is 748 taken from the 'Value' column of the "EDHOC Method Type" registry 749 defined in Section 9.3 of [I-D.ietf-lake-edhoc]. This parameter 750 MAY occur multiple times, with each occurrence specifying a 751 different authentication method. 753 * 'csuite', specifying an EDHOC ciphersuite supported by the Server. 754 This parameter MUST specify a single value, which is taken from 755 the 'Value' column of the "EDHOC Cipher Suites" registry defined 756 in Section 9.2 of [I-D.ietf-lake-edhoc]. This parameter MAY occur 757 multiple times, with each occurrence specifying a different 758 authentication method. 760 * 'cred_t', specifying type of authentication credentials supported 761 by the Server. This parameter MAY occur multiple times, with each 762 occurrence specifying a different authentication credential type. 763 Possible values are: "x509", for X.509 certificate [RFC5280]; 764 "c509", for C509 certificate [I-D.ietf-cose-cbor-encoded-cert]; 765 "cwt" for CWT [RFC8392]; "ccs" for CWT Claims Set (CCS) [RFC8392]. 767 * 'idcred_t', specifying the type of identifiers supported by the 768 Server for identifying authentication credentials. This parameter 769 MUST specify a single value, which is taken from the 'Label' 770 column of the "COSE Headers Parameters" registry 771 [COSE.Header.Parameters]. This parameter MAY occur multiple 772 times, with each occurrence specifying a different type of 773 identifier for authentication credentials. 775 Note that the values in the 'Label' column of the "COSE Headers 776 Parameters" registry are strongly typed. On the contrary, Link 777 Format is weakly typed and thus does not distinguish between, for 778 instance, the string value "-10" and the integer value -10. Thus, 779 if responses in Link Format are returned, string values which look 780 like an integer are not supported. Therefore, such values MUST 781 NOT be used in the 'idcred_t' parameter. 783 * 'ead_1', 'ead_2', 'ead_3' and 'ead_4', specifying if the Server 784 supports the use of external authorization data EAD_1, EAD_2, 785 EAD_3 and EAD_4, respectively (see Section 3.8 of 786 [I-D.ietf-lake-edhoc]). For each of these parameters, the 787 following applies. 789 - It MUST occur at most once, with its presence denoting support 790 from the server for the respective external authorization data. 792 - It MUST specify a single value, which is taken from the 'Label' 793 column of the "EDHOC External Authorization Data" registry 794 defined in Section 9.5 of [I-D.ietf-lake-edhoc]. 796 * 'comb_req', specifying whether the server supports the EDHOC + 797 OSCORE request defined in Section 3, with its presence denoting 798 support from the server. A value MUST NOT be given to this 799 parameter and any present value MUST be ignored by parsers. 801 * 'conv_osc_id', specifying the method used to convert from OSCORE 802 to EDHOC identifiers. If such a method is the one defined in 803 Section 4, this parameter MUST take value 0. 805 The example in Figure 6 shows how a Client discovers one EDHOC 806 resource at a Server, obtaining information elements from the 807 applicability statement. The Link Format notation from Section 5 of 808 [RFC6690] is used. 810 REQ: GET /.well-known/core 812 RES: 2.05 Content 813 ;osc, 814 ;if="sensor", 815 ;rt="core.edhoc";csuite="0";csuite="2"; 816 method="0";cred_t="c509";cred_t="ccs";idcred_t="4";comb_req 818 Figure 6: The Web Link 820 7. Security Considerations 822 The same security considerations from OSCORE [RFC8613] and EDHOC 823 [I-D.ietf-lake-edhoc] hold for this document. 825 TODO: more considerations 827 8. IANA Considerations 829 RFC Editor: Please replace "[[this document]]" with the RFC number of 830 this document and delete this paragraph. 832 This document has the following actions for IANA. 834 8.1. CoAP Option Numbers Registry 836 IANA is asked to enter the following option number to the "CoAP 837 Option Numbers" registry within the "CoRE Parameters" registry group. 839 [ 841 The CoAP option numbers 13 and 21 are both consistent with the 842 properties of the EDHOC Option defined in Section 3.1, and they both 843 allow the EDHOC Option to always result in an overall size of 1 byte. 844 This is because: 846 * The EDHOC option is always empty, i.e., with zero-length value; 847 and 849 * Since the OSCORE option with option number 9 is always present in 850 the CoAP request, the EDHOC option would be encoded with a maximum 851 delta of 4 or 12, depending on its option number being 13 or 21. 853 At the time of writing, the CoAP option numbers 13 and 21 are both 854 unassigned in the "CoAP Option Numbers" registry, as first available 855 and consistent option numbers for the EDHOC option. 857 This document suggests 21 (TBD21) as option number to be assigned to 858 the new EDHOC option, since both 13 and 21 are consistent for the use 859 case in question, but different use cases or protocols may make 860 better use of the option number 13. 862 ] 864 +--------+-------+-------------------+ 865 | Number | Name | Reference | 866 +--------+-------+-------------------+ 867 | TBD21 | EDHOC | [[this document]] | 868 +--------+-------+-------------------+ 870 9. References 872 9.1. Normative References 874 [COSE.Header.Parameters] 875 IANA, "COSE Header Parameters", 876 . 879 [I-D.ietf-core-resource-directory] 880 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 881 D. Stok, "CoRE Resource Directory", Work in Progress, 882 Internet-Draft, draft-ietf-core-resource-directory-28, 7 883 March 2021, . 886 [I-D.ietf-lake-edhoc] 887 Selander, G., Mattsson, J. P., and F. Palombini, 888 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 889 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 890 October 2021, . 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, 895 DOI 10.17487/RFC2119, March 1997, 896 . 898 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 899 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 900 . 902 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 903 Application Protocol (CoAP)", RFC 7252, 904 DOI 10.17487/RFC7252, June 2014, 905 . 907 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 908 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 909 May 2017, . 911 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 912 DOI 10.17487/RFC8288, October 2017, 913 . 915 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 916 "Object Security for Constrained RESTful Environments 917 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 918 . 920 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 921 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 922 . 924 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 925 Representation (CBOR)", STD 94, RFC 8949, 926 DOI 10.17487/RFC8949, December 2020, 927 . 929 9.2. Informative References 931 [I-D.ietf-cose-cbor-encoded-cert] 932 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 933 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 934 Certificates)", Work in Progress, Internet-Draft, draft- 935 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 936 . 939 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 940 Housley, R., and W. Polk, "Internet X.509 Public Key 941 Infrastructure Certificate and Certificate Revocation List 942 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 943 . 945 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 946 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 947 May 2018, . 949 Appendix A. Checking CBOR Encoding of Numeric Values 951 A binary string of N bytes in size is a valid CBOR encoding of an 952 integer value if and only if both the following conditions hold, with 953 reference to the table below. 955 * The size N is one of the values specified in the "Size" column. 957 * The first byte of the binary string is equal to one of the byte 958 values specified in the "First byte" column, exactly for the row 959 having N as value of the "Size" column. 961 +------+-----------------------+ 962 | Size | First byte | 963 +------+-----------------------+ 964 | 1 | 0x00-0x17 , 0x20-0x37 | 965 +------+-----------------------+ 966 | 2 | 0x18 , 0x38 | 967 +------+-----------------------+ 968 | 3 | 0x19 , 0x39 | 969 +------+-----------------------+ 970 | 5 | 0x1A , 0x3A | 971 +------+-----------------------+ 972 | 9 | 0x1B , 0x3B | 973 +------+-----------------------+ 975 Appendix B. Document Updates 977 RFC Editor: Please remove this section. 979 B.1. Version -01 to -02 981 * New title, abstract and introduction. 983 * Restructured table of content. 985 * Alignment with latest format of EDHOC messages. 987 * Guideline on ID conversions based on applicability statement. 989 * Clarifications, extension and consistency on applicability 990 statement. 992 * Section on web-linking. 994 * RFC8126 terminology in IANA considerations. 996 * Revised Appendix "Checking CBOR Encoding of Numeric Values". 998 B.2. Version -00 to -01 1000 * Improved background overview of EDHOC. 1002 * Added explicit rules for converting OSCORE Sender/Recipient IDs to 1003 EDHOC connection identifiers following the removal of 1004 bstr_identifier from EDHOC. 1006 * Revised section organization. 1008 * Recommended number for EDHOC option changed to 21. 1010 * Editorial improvements. 1012 Acknowledgments 1014 The authors sincerely thank Christian Amsuess, Klaus Hartke, Jim 1015 Schaad and Malisa Vucinic for their feedback and comments. 1017 The work on this document has been partly supported by VINNOVA and 1018 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1019 (Grant agreement 952652). 1021 Authors' Addresses 1023 Francesca Palombini 1024 Ericsson 1026 Email: francesca.palombini@ericsson.com 1028 Marco Tiloca 1029 RISE AB 1030 Isafjordsgatan 22 1031 SE-16440 Stockholm Kista 1032 Sweden 1034 Email: marco.tiloca@ri.se 1036 Rikard Hoeglund 1037 RISE AB 1038 Isafjordsgatan 22 1039 SE-16440 Stockholm Kista 1040 Sweden 1042 Email: rikard.hoglund@ri.se 1044 Stefan Hristozov 1045 Fraunhofer AISEC 1047 Email: stefan.hristozov@aisec.fraunhofer.de 1049 Goeran Selander 1050 Ericsson 1052 Email: goran.selander@ericsson.com