idnits 2.17.1 draft-palombini-core-oscore-edhoc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (13 July 2020) is 1381 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 (-16) exists of draft-ietf-cbor-7049bis-14 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-00 ** Downref: Normative reference to an Informational draft: draft-ietf-lake-reqs (ref. 'I-D.ietf-lake-reqs') Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: 14 January 2021 R. Hoeglund 6 RISE AB 7 S. Hristozov 8 Fraunhofer AISEC 9 G. Selander 10 Ericsson 11 13 July 2020 13 Combining EDHOC and OSCORE 14 draft-palombini-core-oscore-edhoc-00 16 Abstract 18 This document defines possible optimization approaches for combining 19 the lightweight authenticated key exchange protocol EDHOC run over 20 CoAP with the first subsequent OSCORE transaction. This combination 21 reduces the number of round trips required to set up an OSCORE 22 Security Context and complete an OSCORE transaction using that 23 context. 25 Discussion Venues 27 This note is to be removed before publishing as an RFC. 29 Source for this draft and an issue tracker can be found at 30 https://github.com/EricssonResearch/oscore-edhoc 31 (https://github.com/EricssonResearch/oscore-edhoc). 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 14 January 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. EDHOC in OSCORE . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Signalling in a New EDHOC Option . . . . . . . . . . . . 6 71 3.2. Signalling in the OSCORE Option . . . . . . . . . . . . . 6 72 4. OSCORE in EDHOC . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Signalling in a New EDHOC+OSCORE Option . . . . . . . . . 8 74 4.2. Signalling Based on the Number of Elements in the 75 Payload . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 This document presents possible optimization approaches to combine 85 the lightweight authenticated key exchange protocol EDHOC 86 [I-D.ietf-lake-edhoc], when running over CoAP [RFC7252], with the 87 first subsequent OSCORE [RFC8613] transaction. 89 This allows for a minimum number of round trips necessary to setup 90 the OSCORE Security Context and complete an OSCORE transaction, for 91 example when an IoT device gets configured in a network for the first 92 time. 94 The number of protocol round trips impacts the minimum number of 95 flights, which can have a substantial impact on performance with 96 certain radio technologies as discussed in Section 2.11 of 97 [I-D.ietf-lake-reqs]. 99 Without this optimization, it is not possible, not even in theory, to 100 achieve the minimum number of flights. This optimization makes it 101 possible also in practice, since the last message of the EDHOC 102 protocol can be made relatively small (see Section 1 of 103 [I-D.ietf-lake-edhoc]), thus allowing additional OSCORE protected 104 CoAP data within target MTU sizes [I-D.ietf-lake-reqs]. 106 The goal of this document is to provide details on different 107 alternatives for transporting and processing the necessary data, 108 gather opinions on the different approaches, and select only one of 109 those. 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 The reader is expected to be familiar with terms and concepts defined 120 in CoAP [RFC7252], CBOR [I-D.ietf-cbor-7049bis], OSCORE [RFC8613] and 121 EDHOC [I-D.ietf-lake-edhoc]. 123 2. Background 125 EDHOC is a 3-message key exchange protocol. Section 7.1 of 126 [I-D.ietf-lake-edhoc] specifies how to transport EDHOC over CoAP: the 127 EDHOC data (referred to as "EDHOC messages") are transported in the 128 payload of CoAP requests and responses. 130 This draft deals with the case of the Initiator acting as CoAP Client 131 and the Responder acting as CoAP Server. (The case of the Initiator 132 acting as CoAP server cannot be optimized in this way.) That is, the 133 CoAP Client sends a POST request containing the EDHOC message 1 to a 134 reserved resource at the CoAP Server. This triggers the EDHOC 135 exchange on the CoAP Server, which replies with a 2.04 (Changed) 136 Response containing the EDHOC message 2. Finally, the EDHOC message 137 3 is sent by the CoAP Client in a CoAP POST request to the same 138 resource used for the EDHOC message 1. The Content-Format of these 139 CoAP messages is set to "application/edhoc". 141 After this exchange takes place, and after successful verifications 142 specified in the EDHOC protocol, the Client and Server derive the 143 OSCORE Security Context, as specified in Section 7.1.1 of 144 [I-D.ietf-lake-edhoc]. Then, they are ready to use OSCORE. 146 This sequential way of running EDHOC and then OSCORE is specified in 147 Figure 1. As shown in the figure, this mechanism is executed in 3 148 round trips. 150 CoAP Client CoAP Server 151 | ------------- EDHOC message_1 ------------> | 152 | | 153 | <------------ EDHOC message_2 ------------- | 154 | | 155 EDHOC verification | 156 | | 157 | ------------- EDHOC message_3 ------------> | 158 | | 159 | EDHOC verification 160 | | 161 OSCORE Sec Ctx OSCORE Sec Ctx 162 Derivation Derivation 163 | | 164 | -------------- OSCORE Request ------------> | 165 | | 166 | <------------ OSCORE Response ------------- | 167 | | 169 Figure 1: EDHOC and OSCORE run sequentially 171 The number of roundtrips can be minimized: after receiving the EDHOC 172 message 2, the CoAP Client has all the information needed to derive 173 the OSCORE Security Context before sending the EDHOC message 3. 175 This means that the Client can potentially send at the same time both 176 the EDHOC message 3 and the subsequent OSCORE Request. On a semantic 177 level, this approach practically requires to send two separate REST 178 requests at the same time. 180 The high level message flow of running EDHOC and OSCORE combined is 181 shown in Figure 2. 183 Defining the specific details of how to transport the data and of 184 their processing order is the goal of this specification. 186 CoAP Client CoAP Server 187 | ------------- EDHOC message_1 ------------> | 188 | | 189 | <------------ EDHOC message_2 ------------- | 190 | | 191 EDHOC verification + | 192 OSCORE Sec Ctx | 193 Derivation | 194 | | 195 | ------------- EDHOC message_3 ------------> | 196 | + OSCORE Request | 197 | | 198 | EDHOC verification + 199 | OSCORE Sec Ctx 200 | Derivation 201 | | 202 | <------------ OSCORE Response ------------- | 203 | | 205 Figure 2: EDHOC and OSCORE combined 207 3. EDHOC in OSCORE 209 The first approach consists in sending the EDHOC message 3 inside an 210 OSCORE message (i.e., an OSCORE protected CoAP message). 212 The request is in practice the OSCORE Request from Figure 1, sent to 213 a protected resource and with the correct CoAP method and options, 214 with the addition that it also transports the EDHOC message 3. 216 As the EDHOC message 3 may be too large to be included in a CoAP 217 Option, e.g. if containing a large public key certificate chain, it 218 would have to be transported in the CoAP payload. 220 The payload of the request is formatted as a CBOR sequence 221 [I-D.ietf-lake-reqs] of two CBOR wrapped items: the EDHOC message 3 222 and the OSCORE ciphertext, in this order. 224 Note that the OSCORE ciphertext is not computed over the EDHOC 225 message 3, which is not protected by OSCORE. That is, the client 226 first prepares the OSCORE Request as in Figure 1. Then, it reformats 227 the payload to include also the EDHOC message 3, as defined above. 229 The usage of this approach is indicated by a signalling information, 230 which can be either a new EDHOC option (see Section 3.1) or the 231 OSCORE option with a particular Flag Bit set (see Section 3.2). 233 When receiving such a request, the Server needs to perform the 234 following processing, in addition to the EDHOC, OSCORE and CoAP 235 processing: 237 1. Check the signalling information to identify that this is an 238 OSCORE + EDHOC request. 240 2. Extract the EDHOC message 3 from the payload. 242 3. Execute the EDHOC processing, including verifications and OSCORE 243 Security Context derivation. 245 4. Decrypt and verify the remaining OSCORE protected CoAP request as 246 defined by OSCORE. 248 5. Process the CoAP request. 250 The following sections expand on the 2 ways of signalling that the 251 EDHOC message is transported in the OSCORE message. 253 3.1. Signalling in a New EDHOC Option 255 One way to signal that the Server is to extract and process the EDHOC 256 message 3 before the OSCORE message is processed is to define a new 257 CoAP Option, called the EDHOC Option. 259 This Option being present means that the message contains EDHOC data 260 in the payload, that must be extracted and processed before the rest 261 of the message can be processed. 263 In particular, the EDHOC message is to be extracted from the CoAP 264 payload, as the CBOR wrapped first element of a CBOR sequence. 266 The Option is critical, Safe-to-Forward, and part of the Cache-Key. 268 The Option value is always empty. If any value is sent, the value is 269 simply discarded. 271 The Option must occur at most once. 273 The Option is of Class U for OSCORE. 275 3.2. Signalling in the OSCORE Option 277 Another way to signal that the EDHOC message is to be extracted from 278 the CoAP payload as the CBOR wrapped first element of a CBOR 279 sequence, and that the processing defined in Section 3 is to be 280 executed, is to use one of the OSCORE Flag Bits. 282 Bit Position: 8 284 Name: EDHOC 286 Description: Set to 1 if the payload is a sequence of EDHOC data and 287 OSCORE payload. 289 Reference: this document 291 4. OSCORE in EDHOC 293 Instead of transporting the EDHOC message inside an OSCORE message, 294 the second approach consists in transporting the OSCORE protected 295 data in an EDHOC message. 297 The request is in practice the CoAP POST Request containing the EDHOC 298 message 3 from Figure 1, sent to the unprotected resource reserved to 299 EDHOC processing, with the addition that it also transports the 300 OSCORE Option and ciphertext of the original OSCORE Request. 302 The OSCORE Option and ciphertext contain all the information to 303 reconstruct the original OSCORE Request, including CoAP method, 304 options and payload. 306 The payload is formatted as a CBOR sequence of three CBOR wrapped 307 items: the EDHOC message 3, the OSCORE Option and the OSCORE 308 ciphertext, in this order. 310 Note that the OSCORE ciphertext is not computed over the EDHOC 311 message 3, which is not protected by OSCORE. That is, the client 312 first prepares the OSCORE protected CoAP Request. Then, it adds the 313 OSCORE option and ciphertext to the payload of the EDHOC request to 314 send, as defined above. 316 The usage of this approach is indicated by a signalling information, 317 which can be either a new EDHOC+OSCORE option (see Section 4.1) or 318 the particular structure of the request payload (see Section 4.2). 320 When receiving such a request, the Server needs to execute the 321 following processing, in addition to the EDHOC, OSCORE and CoAP 322 processing: 324 1. Check the signalling information to identify that this is an 325 EDHOC + OSCORE request. 327 2. Extract the EDHOC message 3 from the payload. 329 3. Execute the EDHOC processing, including verifications and OSCORE 330 Security Context derivation. 332 4. Extract the OSCORE Option value and ciphertext from the payload 333 and reconstruct the OSCORE protected CoAP Request. 335 5. Decrypt and verify the reconstructed OSCORE protected CoAP 336 request as defined by OSCORE. 338 6. Process the CoAP request. 340 Compared to the approach in Section 3, this processing requires one 341 more step, as the Server must build the OSCORE protected CoAP request 342 from the payload before being able to process it. 344 4.1. Signalling in a New EDHOC+OSCORE Option 346 One way to signal that the Server is to build and process the OSCORE 347 protected CoAP request after the EDHOC processing is to define a new 348 CoAP Option, called the EDHOC+OSCORE Option. 350 This Option being present (either in a request or response) means 351 that the message contains an OSCORE option value and ciphertext in 352 the payload, that must be extracted and processed after the EDHOC 353 processing. 355 The OSCORE option and ciphertext are to be extracted from the CoAP 356 payload as the CBOR wrapped second and third element of a CBOR 357 sequence. 359 The Option is critical, Safe-to-Forward, and part of the Cache-Key. 361 The Option value is always empty. If any value is sent, the value is 362 simply discarded. 364 The Option must occur at most once. 366 The Option is of Class U for OSCORE. 368 4.2. Signalling Based on the Number of Elements in the Payload 370 Another way to signal this approach and to mandate that the Server is 371 to build and process the OSCORE protected CoAP request after the 372 EDHOC processing is to set up pre-determined policies on both the 373 Client and Server. 375 A Client may be set up to support at the same time receiving only the 376 EDHOC message 3 or both the EDHOC message 3 and the OSCORE Option and 377 ciphertext in the request. The Client would be able to distinguish 378 the two cases based on the number of CBOR elements in the payload, 379 and process the message accordingly. 381 5. Security Considerations 383 The same security considerations from OSCORE [RFC8613] and EDHOC 384 [I-D.ietf-lake-edhoc] hold for this document. 386 TODO (more considerations) 388 6. IANA Considerations 390 This document has no IANA actions. 392 7. Normative References 394 [I-D.ietf-cbor-7049bis] 395 Bormann, C. and P. Hoffman, "Concise Binary Object 396 Representation (CBOR)", Work in Progress, Internet-Draft, 397 draft-ietf-cbor-7049bis-14, 16 June 2020, 398 . 401 [I-D.ietf-lake-edhoc] 402 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 403 Diffie-Hellman Over COSE (EDHOC)", Work in Progress, 404 Internet-Draft, draft-ietf-lake-edhoc-00, 6 July 2020, 405 . 408 [I-D.ietf-lake-reqs] 409 Vucinic, M., Selander, G., Mattsson, J., and D. Garcia- 410 Carillo, "Requirements for a Lightweight AKE for OSCORE", 411 Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04, 412 8 June 2020, . 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, 417 DOI 10.17487/RFC2119, March 1997, 418 . 420 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 421 Application Protocol (CoAP)", RFC 7252, 422 DOI 10.17487/RFC7252, June 2014, 423 . 425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 427 May 2017, . 429 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 430 "Object Security for Constrained RESTful Environments 431 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 432 . 434 Acknowledgments 436 The authors sincerely thank Christian Amsuess, Klaus Hartke, Jim 437 Schaad and Malisa Vucinic for their feedback and comments in the 438 discussion leading up to this draft. 440 The work on this document has been partly supported by VINNOVA and 441 the Celtic-Next project CRITISEC. 443 Authors' Addresses 445 Francesca Palombini 446 Ericsson 448 Email: francesca.palombini@ericsson.com 450 Marco Tiloca 451 RISE AB 453 Email: marco.tiloca@ri.se 455 Rikard Hoeglund 456 RISE AB 458 Email: rikard.hoglund@ri.se 460 Stefan Hristozov 461 Fraunhofer AISEC 463 Email: stefan.hristozov@aisec.fraunhofer.de 464 Goeran Selander 465 Ericsson 467 Email: goran.selander@ericsson.com