idnits 2.17.1 draft-mattsson-core-coap-actuators-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2018) is 2041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-02 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-09 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mattsson 3 Internet-Draft J. Fornehed 4 Intended status: Informational G. Selander 5 Expires: March 21, 2019 F. Palombini 6 Ericsson 7 C. Amsuess 8 Energy Harvesting Solutions 9 September 17, 2018 11 Controlling Actuators with CoAP 12 draft-mattsson-core-coap-actuators-06 14 Abstract 16 Being able to trust information from sensors and to securely control 17 actuators are essential in a world of connected and networking things 18 interacting with the physical world. In this memo we show that just 19 using COAP with a security protocol like DTLS, TLS, or OSCORE is not 20 enough. We describe several serious attacks any on-path attacker can 21 do, and discusses tougher requirements and mechanisms to mitigate the 22 attacks. While this document is focused on actuators, some of the 23 attacks apply equally well to sensors. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 21, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. The Block Attack . . . . . . . . . . . . . . . . . . . . 4 63 2.2. The Request Delay Attack . . . . . . . . . . . . . . . . 5 64 2.3. The Response Delay and Mismatch Attack . . . . . . . . . 8 65 2.4. The Relay Attack . . . . . . . . . . . . . . . . . . . . 11 66 2.5. The Request Fragment Rearrangement Attack . . . . . . . . 12 67 2.5.1. Completing an Operation with an Earlier Final Block . 13 68 2.5.2. Injecting a Withheld First Block . . . . . . . . . . 14 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 5.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 5.2. Informative References . . . . . . . . . . . . . . . . . 16 74 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 Being able to trust information from sensors and to securely control 80 actuators are essential in a world of connected and networking things 81 interacting with the physical world. One protocol used to interact 82 with sensors and actuators is the Constrained Application Protocol 83 (CoAP) [RFC7252]. Any Internet-of-Things (IoT) deployment valuing 84 security and privacy would use a security protocol such as DTLS 85 [RFC6347], TLS [RFC5246], or OSCORE [I-D.ietf-core-object-security] 86 to protect CoAP, where the choice of security protocol depends on the 87 transport protocol and the presence of intermediaries. The use of 88 CoAP over UDP and DTLS is specified in [RFC6347] and the use of CoAP 89 over TCP and TLS is specified in [RFC8323]. OSCORE protects CoAP 90 end-to-end with the use of COSE [RFC8152] and the CoAP Object- 91 Security option [I-D.ietf-core-object-security], and can therefore be 92 used over any transport. 94 The Constrained Application Protocol (CoAP) [RFC7252] was designed 95 with the assumption that security could be provided on a separate 96 layer, in particular by using DTLS [RFC6347]. The four properties 97 traditionally provided by security protocols are: 99 o Data confidentiality 101 o Data origin authentication 103 o Data integrity checking 105 o Replay protection 107 In this document we show that protecting CoAP with a security 108 protocol on another layer is not nearly enough to securely control 109 actuators (and in many cases sensors) and that secure operation often 110 demands far more than the four properties traditionally provided by 111 security protocols. We describe several serious attacks any on-path 112 attacker (i.e. not only "trusted intermediaries) can do and discusses 113 tougher requirements and mechanisms to mitigate the attacks. In 114 general, secure operation of actuators also requires the three 115 properties: 117 o Data-to-Data binding 119 o Data-to-space binding 121 o Data-to-time binding 123 "Data-to-Data binding" is e.g. binding of responses to a request or 124 binding of data fragments to each other. "Data-to-space binding" is 125 the binding of data to an absolute or relative point in space (i.e. a 126 location) and may in the relative case be referred to as proximity. 127 "Data-to-time binding" is the binding of data to an absolute or 128 relative point in time and may in the relative case be referred to as 129 freshness. The two last properties may be bundled together as "Data- 130 to-spacetime binding". 132 The request delay attack (valid for DTLS, TLS, and OSCORE and 133 described in Section 2.2) lets an attacker control an actuator at a 134 much later time than the client anticipated. The response delay and 135 mismatch attack (valid for DTLS and TLS and described in Section 2.3) 136 lets an attacker respond to a client with a response meant for an 137 older request. The request fragment rearrangement attack (valid for 138 DTLS, TLS, and OSCORE and described in Section 2.5) lets an attacker 139 cause unauthorized operations to be performed on the server, and 140 responses to unauthorized operations to be mistaken for responses to 141 authorized operations. 143 Mechanisms mitigating some of the attacks discussed in this document 144 can be found in [I-D.ietf-core-echo-request-tag] and 145 [I-D.liu-core-coap-delay-attacks] 147 1.1. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 2. Attacks 157 Internet-of-Things (IoT) deployments valuing security and privacy, 158 MUST use a security protocol such as DTLS, TLS, or OSCORE to protect 159 CoAP. This is especially true for deployments of actuators where 160 attacks often (but not always) have serious consequences. The 161 attacks described in this section are made under the assumption that 162 CoAP is already protected with a security protocol such as DTLS, TLS, 163 or OSCORE, as an attacker otherwise can easily forge false requests 164 and responses. 166 2.1. The Block Attack 168 An on-path attacker can block the delivery of any number of requests 169 or responses. The attack can also be performed by an attacker 170 jamming the lower layer radio protocol. This is true even if a 171 security protocol like DTLS, TLS, or OSCORE is used. Encryption 172 makes selective blocking of messages harder, but not impossible or 173 even infeasible. With DTLS and TLS, proxies have access to the 174 complete CoAP message, and with OSCORE, the CoAP header and several 175 CoAP options are not encrypted. In both security protocols, the IP- 176 addresses, ports, and CoAP message lengths are available to all on- 177 path attackers, which may be enough to determine the server, 178 resource, and command. The block attack is illustrated in Figures 1 179 and 2. 181 Client Foe Server 182 | | | 183 +----->X | Code: 0.03 (PUT) 184 | PUT | | Token: 0x47 185 | | | Uri-Path: lock 186 | | | Payload: 1 (Lock) 187 | | | 189 Figure 1: Blocking a request 191 Where 'X' means the attacker is blocking delivery of the message. 193 Client Foe Server 194 | | | 195 +------------>| Code: 0.03 (PUT) 196 | | PUT | Token: 0x47 197 | | | Uri-Path: lock 198 | | | Payload: 1 (Lock) 199 | | | 200 | X<-----+ Code: 2.04 (Changed) 201 | | 2.04 | Token: 0x47 202 | | | 204 Figure 2: Blocking a response 206 While blocking requests to, or responses from, a sensor is just a 207 denial of service attack, blocking a request to, or a response from, 208 an actuator results in the client losing information about the 209 server's status. If the actuator e.g. is a lock (door, car, etc.), 210 the attack results in the client not knowing (except by using out-of- 211 band information) whether the lock is unlocked or locked, just like 212 the observer in the famous Schrodinger's cat thought experiment. Due 213 to the nature of the attack, the client cannot distinguish the attack 214 from connectivity problems, offline servers, or unexpected behavior 215 from middle boxes such as NATs and firewalls. 217 Remedy: Any IoT deployment of actuators where confirmation is 218 important MUST notify the user upon reception of the response, or 219 warn the user when a response is not received. 221 2.2. The Request Delay Attack 223 An on-path attacker may not only block packets, but can also delay 224 the delivery of any packet (request or response) by a chosen amount 225 of time. If CoAP is used over a reliable and ordered transport such 226 as TCP with TLS or OSCORE, no messages can be delivered before the 227 delayed message. If CoAP is used over an unreliable and unordered 228 transport such as UDP with DTLS, or OSCORE, other messages can be 229 delivered before the delayed message as long as the delayed packet is 230 delivered inside the replay window. When CoAP is used over UDP, both 231 DTLS and OSCORE allow out-of-order delivery and uses sequence numbers 232 together with a replay window to protect against replay attacks. The 233 replay window has a default length of 64 in DTLS and 32 in OSCORE. 234 The attacker can control the replay window by blocking some or all 235 other packets. By first delaying a request, and then later, after 236 delivery, blocking the response to the request, the client is not 237 made aware of the delayed delivery except by the missing response. 238 The server has in general, no way of knowing that the request was 239 delayed and will therefore happily process the request. Note that 240 delays can also happen for other reasons than a malicious attacker. 242 If some wireless low-level protocol is used, the attack can also be 243 performed by the attacker simultaneously recording what the client 244 transmits while at the same time jamming the server. The request 245 delay attack is illustrated in Figure 3. 247 Client Foe Server 248 | | | 249 +----->@ | Code: 0.03 (PUT) 250 | PUT | | Token: 0x9c 251 | | | Uri-Path: lock 252 | | | Payload: 0 (Unlock) 253 | | | 254 .... .... 255 | | | 256 | @----->| Code: 0.03 (PUT) 257 | | PUT | Token: 0x9c 258 | | | Uri-Path: lock 259 | | | Payload: 0 (Unlock) 260 | | | 261 | X<-----+ Code: 2.04 (Changed) 262 | | 2.04 | Token: 0x9c 263 | | | 265 Figure 3: Delaying a request 267 Where '@' means the attacker is storing and later forwarding the 268 message (@ may alternatively be seen as a wormhole connecting two 269 points in time). 271 While an attacker delaying a request to a sensor is often not a 272 security problem, an attacker delaying a request to an actuator 273 performing an action is often a serious problem. A request to an 274 actuator (for example a request to unlock a lock) is often only meant 275 to be valid for a short time frame, and if the request does not reach 276 the actuator during this short timeframe, the request should not be 277 fulfilled. In the unlock example, if the client does not get any 278 response and does not physically see the lock opening, the user is 279 likely to walk away, calling the locksmith (or the IT-support). 281 If a non-zero replay window is used (the default when CoAP is used 282 over UDP), the attacker can let the client interact with the actuator 283 before delivering the delayed request to the server (illustrated in 284 Figure 4). In the lock example, the attacker may store the first 285 "unlock" request for later use. The client will likely resend the 286 request with the same token. If DTLS is used, the resent packet will 287 have a different sequence number and the attacker can forward it. If 288 OSCORE is used, resent packets will have the same sequence number and 289 the attacker must block them all until the client sends a new message 290 with a new sequence number (not shown in Figure 4). After a while 291 when the client has locked the door again, the attacker can deliver 292 the delayed "unlock" message to the door, a very serious attack. 294 Client Foe Server 295 | | | 296 +----->@ | Code: 0.03 (PUT) 297 | PUT | | Token: 0x9c 298 | | | Uri-Path: lock 299 | | | Payload: 0 (Unlock) 300 | | | 301 +------------>| Code: 0.03 (PUT) 302 | PUT | | Token: 0x9c 303 | | | Uri-Path: lock 304 | | | Payload: 0 (Unlock) 305 | | | 306 <-------------+ Code: 2.04 (Changed) 307 | | 2.04 | Token: 0x9c 308 | | | 309 .... .... 310 | | | 311 +------------>| Code: 0.03 (PUT) 312 | PUT | | Token: 0x7a 313 | | | Uri-Path: lock 314 | | | Payload: 1 (Lock) 315 | | | 316 <-------------+ Code: 2.04 (Changed) 317 | | 2.04 | Token: 0x7a 318 | | | 319 | @----->| Code: 0.03 (PUT) 320 | | PUT | Token: 0x9c 321 | | | Uri-Path: lock 322 | | | Payload: 0 (Unlock) 323 | | | 324 | X<-----+ Code: 2.04 (Changed) 325 | | 2.04 | Token: 0x9c 326 | | | 328 Figure 4: Delaying request with reordering 330 While the second attack (Figure 4) can be mitigated by using a replay 331 window of length zero, the first attack (Figure 3) cannot. A 332 solution must enable the server to verify that the request was 333 received within a certain time frame after it was sent or enable the 334 server to securely determine an absolute point in time when the 335 request is to be executed. This can be accomplished with either a 336 challenge-response pattern, by exchanging timestamps between client 337 and server, or by only allowing requests a short period after client 338 authentication. 340 Requiring a fresh client authentication (such as a new TLS/DTLS 341 handshake or an EDHOC key exchange [I-D.selander-ace-cose-ecdhe]) 342 mitigates the problem, but requires larger messages and more 343 processing than a dedicated solution. Security solutions based on 344 exchanging timestamps require exactly synchronized time between 345 client and server, and this may be hard to control with complications 346 such as time zones and daylight saving. Wall clock time SHOULD NOT 347 be used as it is not monotonic, may reveal that the endpoints will 348 accept expired certificates, or reveal the endpoint's location. Use 349 of non-monotonic clocks is not secure as the server will accept 350 requests if the clock is moved backward and reject requests if the 351 clock is moved forward. Even if the clocks are synchronized at one 352 point in time, they may easily get out-of-sync and an attacker may 353 even be able to affect the client or the server time in various ways 354 such as setting up a fake NTP server, broadcasting false time signals 355 to radio controlled clocks, or expose one of them to a strong gravity 356 field. As soon as client falsely believes it is time synchronized 357 with the server, delay attacks are possible. A challenge response 358 mechanism where the server does not need to synchronize its time with 359 the client is easier to analyze but require more roundtrips. The 360 challenges, responses, and timestamps may be sent in a CoAP option or 361 in the CoAP payload. 363 Remedy: The mechanisms specified in [I-D.ietf-core-echo-request-tag] 364 or [I-D.liu-core-coap-delay-attacks] SHALL be used for controlling 365 actuators unless another application specific challenge-response or 366 timestamp mechanism is used. 368 2.3. The Response Delay and Mismatch Attack 370 The following attack can be performed if CoAP is protected by a 371 security protocol where the response is not bound to the request in 372 any way except by the CoAP token. This would include most general 373 security protocols, such as DTLS, TLS, and IPsec, but not OSCORE. 374 CoAP [RFC7252] uses a client generated token that the server echoes 375 to match responses to request, but does not give any guidelines for 376 the use of token with DTLS and TLS, except that the tokens currently 377 "in use" SHOULD (not SHALL) be unique. The attacker performs the 378 attack by delaying delivery of a response until the client sends a 379 request with the same token, the response will be accepted by the 380 client as a valid response to the later request. If CoAP is used 381 over a reliable and ordered transport such as TCP with TLS, no 382 messages can be delivered before the delayed message. If CoAP is 383 used over an unreliable and unordered transport such as UDP with 384 DTLS, other messages can be delivered before the delayed message as 385 long as the delayed packet is delivered inside the replay window. 386 Note that mismatches can also happen for other reasons than a 387 malicious attacker, e.g. delayed delivery or a server sending 388 notifications to an uninterested client. 390 The attack can be performed by an attacker on the wire, or an 391 attacker simultaneously recording what the server transmits while at 392 the same time jamming the client. The response delay and mismatch 393 attack is illustrated in Figure 5. 395 Client Foe Server 396 | | | 397 +------------>| Code: 0.03 (PUT) 398 | PUT | | Token: 0x77 399 | | | Uri-Path: lock 400 | | | Payload: 0 (Unlock) 401 | | | 402 | @<-----+ Code: 2.04 (Changed) 403 | | 2.04 | Token: 0x77 404 | | | 405 .... .... 406 | | | 407 +----->X | Code: 0.03 (PUT) 408 | PUT | | Token: 0x77 409 | | | Uri-Path: lock 410 | | | Payload: 0 (Lock) 411 | | | 412 <------@ | Code: 2.04 (Changed) 413 | 2.04 | | Token: 0x77 414 | | | 416 Figure 5: Delaying and mismatching response to PUT 418 If we once again take a lock as an example, the security consequences 419 may be severe as the client receives a response message likely to be 420 interpreted as confirmation of a locked door, while the received 421 response message is in fact confirming an earlier unlock of the door. 422 As the client is likely to leave the (believed to be locked) door 423 unattended, the attacker may enter the home, enterprise, or car 424 protected by the lock. 426 The same attack may be performed on sensors, also this with serious 427 consequences. As illustrated in Figure 6, an attacker may convince 428 the client that the lock is locked, when it in fact is not. The 429 "Unlock" request may be also be sent by another client authorized to 430 control the lock. 432 Client Foe Server 433 | | | 434 +------------>| Code: 0.01 (GET) 435 | GET | | Token: 0x77 436 | | | Uri-Path: lock 437 | | | 438 | @<-----+ Code: 2.05 (Content) 439 | | 2.05 | Token: 0x77 440 | | | Payload: 1 (Locked) 441 | | | 442 +------------>| Code: 0.03 (PUT) 443 | PUT | | Token: 0x34 444 | | | Uri-Path: lock 445 | | | Payload: 1 (Unlock) 446 | | | 447 | X<-----+ Code: 2.04 (Changed) 448 | | 2.04 | Token: 0x34 449 | | | 450 +----->X | Code: 0.01 (GET) 451 | GET | | Token: 0x77 452 | | | Uri-Path: lock 453 | | | 454 <------@ | Code: 2.05 (Content) 455 | 2.05 | | Token: 0x77 456 | | | Payload: 1 (Locked) 457 | | | 459 Figure 6: Delaying and mismatching response to GET 461 As illustrated in Figure 7, an attacker may even mix responses from 462 different resources as long as the two resources share the same 463 (D)TLS connection on some part of the path towards the client. This 464 can happen if the resources are located behind a common gateway, or 465 are served by the same CoAP proxy. An on-path attacker (not 466 necessarily a (D)TLS endpoint such as a proxy) may e.g. deceive a 467 client that the living room is on fire by responding with an earlier 468 delayed response from the oven (temperatures in degree Celsius). 470 Client Foe Server 471 | | | 472 +------------>| Code: 0.01 (GET) 473 | GET | | Token: 0x77 474 | | | Uri-Path: oven/temperature 475 | | | 476 | @<-----+ Code: 2.05 (Content) 477 | | 2.05 | Token: 0x77 478 | | | Payload: 225 479 | | | 480 .... .... 481 | | | 482 +----->X | Code: 0.01 (GET) 483 | GET | | Token: 0x77 484 | | | Uri-Path: livingroom/temperature 485 | | | 486 <------@ | Code: 2.05 (Content) 487 | 2.05 | | Token: 0x77 488 | | | Payload: 225 489 | | | 491 Figure 7: Delaying and mismatching response from other resource 493 Remedy: If CoAP is protected with a security protocol not providing 494 bindings between requests and responses (e.g. DTLS and TLS) the 495 client MUST NOT reuse any tokens until the traffic keys have been 496 replaced. The easiest way to accomplish this is to implement the 497 Token as a counter, this approach SHOULD be followed. 499 2.4. The Relay Attack 501 Yet another type of attack can be performed in deployments where 502 actuator actions are triggered automatically based on proximity and 503 without any user interaction, e.g. a car (the client) constantly 504 polling for the car key (the server) and unlocking both doors and 505 engine as soon as the car key responds. An attacker (or pair of 506 attackers) may simply relay the CoAP messages out-of-band, using for 507 examples some other radio technology. By doing this, the actuator 508 (i.e. the car) believes that the client is close by and performs 509 actions based on that false assumption. The attack is illustrated in 510 Figure 8. In this example the car is using an application specific 511 challenge-response mechanism transferred as CoAP payloads. 513 Client Foe Foe Server 514 | | | | 515 +----->| ......... +----->| Code: 0.02 (POST) 516 | POST | | POST | Token: 0x3a 517 | | | | Uri-Path: lock 518 | | | | Payload: JwePR2iCe8b0ux (Challenge) 519 | | | | 520 |<-----+ ......... |<-----+ Code: 2.04 (Changed) 521 | 2.04 | | 2.04 | Token: 0x3a 522 | | | | Payload: RM8i13G8D5vfXK (Response) 523 | | | | 525 Figure 8: Relay attack (the client is the actuator) 527 The consequences may be severe, and in the case of a car, lead to the 528 attacker unlocking and driving away with the car, an attack that 529 unfortunately is happening in practice. 531 Remedy: Getting a response over a short-range radio MUST NOT be taken 532 as proof of proximity and therefore MUST NOT be used to take actions 533 based on such proximity. Any automatically triggered mechanisms 534 relying on proximity MUST use other stronger mechanisms to guarantee 535 proximity. Mechanisms that MAY be used are: measuring the round-trip 536 time and calculate the maximum possible distance based on the speed 537 of light, or using radio with an extremely short range like NFC 538 (centimeters instead of meters) that cannot be relayed through e.g. 539 clothes. Another option is to including geographical coordinates 540 (from e.g. GPS) in the messages and calculate proximity based on 541 these, but in this case the location measurements MUST be very 542 precise and the system MUST make sure that an attacker cannot 543 influence the location estimation, something that is very hard in 544 practice. 546 2.5. The Request Fragment Rearrangement Attack 548 These attack scenarios show that the Request Delay and Block Attacks 549 can be used against blockwise transfers to cause unauthorized 550 operations to be performed on the server, and responses to 551 unauthorized operations to be mistaken for responses to authorized 552 operations. The combination of these attacks is described as a 553 separate attack because it makes the Request Delay Attack relevant to 554 systems that are otherwise not time-dependent, which means that they 555 could disregard the Request Delay Attack. 557 This attack works even if the individual request/response pairs are 558 encrypted, authenticated and protected against the Response Delay and 559 Mismatch Attack, provided the attacker is on the network path and can 560 correctly guess which operations the respective packages belong to. 562 2.5.1. Completing an Operation with an Earlier Final Block 564 In this scenario (illustrated in Figure 9), blocks from two 565 operations on a POST-accepting resource are combined to make the 566 server execute an action that was not intended by the authorized 567 client. This works only if the client attempts a second operation 568 after the first operation failed (due to what the attacker made 569 appear like a network outage) within the replay window. The client 570 does not receive a confirmation on the second operation either, but, 571 by the time the client acts on it, the server has already executed 572 the unauthorized action. 574 Client Foe Server 575 | | | 576 +-------------> POST "incarcerate" (Block1: 0, more to come) 577 | | | 578 <-------------+ 2.31 Continue (Block1: 0 received, send more) 579 | | | 580 +----->@ | POST "valjean" (Block1: 1, last block) 581 | | | 582 +----->X | All retransmissions dropped 583 | | | 585 (Client: Odd, but let's go on and promote Javert) 587 | | | 588 +-------------> POST "promote" (Block1: 0, more to come) 589 | | | 590 | X<-----+ 2.31 Continue (Block1: 0 received, send more) 591 | | | 592 | @------> POST "valjean" (Block1: 1, last block) 593 | | | 594 | X<-----+ 2.04 Valjean Promoted 595 | | | 597 Figure 9: Completing an operation with an earlier final block 599 Remedy: If a client starts new blockwise operations on a security 600 context that has lost packages, it needs to label the fragments in 601 such a way that the server will not mix them up. 603 A mechanism to that effect is described as Request-Tag 604 [I-D.ietf-core-echo-request-tag]. Had it been in place in the 605 example and used for body integrity protection, the client would have 606 set the Request-Tag option in the "promote" request. Depending on 607 the server's capabilities and setup, either of four outcomes could 608 have occurred: 610 1. The server could have processed the reinjected POST "valjean" as 611 belonging to the original "incarcerate" block; that's the 612 expected case when the server can handle simultaneous block 613 transfers. 615 2. The server could respond 5.03 Service Unavailable, including a 616 Max-Age option indicating how long it prefers not to take any 617 requests that force it to overwrite the state kept for the 618 "incarcerate" request. 620 3. The server could decide to drop the state kept for the 621 "incarcerate" request's state, and process the "promote" request. 622 The reinjected POST "valjean" will then fail with 4.08 Request 623 Entity incomplete, indicating that the server does not have the 624 start of the operation any more. 626 2.5.2. Injecting a Withheld First Block 628 If the first block of a request is withheld by the attacker for later 629 use, it can be used to have the server process a different request 630 body than intended by the client. Unlike in the previous scenario, 631 it will return a response based on that body to the client. 633 Again, a first operation (that would go like "Homeless stole apples. 634 What shall we do with him?" - "Set him free.") is aborted by the 635 proxy, and a part of that operation is later used in a different 636 operation to prime the server for responding leniently to another 637 operation that would originally have been "Hitman killed someone. 638 What shall we do with him?" - "Hang him.". The attack is illustrated 639 in Figure 10. 641 Client Foe Server 642 | | | 643 +----->@ | POST "Homeless stole apples. Wh" 644 | | | (Block1: 0, more to come) 646 (Client: We'll try that one later again; for now, we have something 647 more urgent:) 649 | | | 650 +-------------> POST "Hitman killed someone. Wh" 651 | | | (Block1: 0, more to come) 652 | | | 653 | @<-----+ 2.31 Continue (Block1: 0 received, send more) 654 | | | 655 | @------> POST "Homeless stole apples. Wh" 656 | | | (Block1: 0, more to come) 657 | | | 658 | X<-----+ 2.31 Continue (Block1: 0 received, send more) 659 | | | 660 <------@ | 2.31 Continue (Block1: 0 received, send more) 661 | | | 662 +-------------> POST "at shall we do with him?" 663 | | | (Block1: 1, last block) 664 | | | 665 <-------------+ 2.05 "Set him free." 666 | | | (Block1: 1 received and this is the result) 668 Figure 10: Injecting a withheld first block 670 3. Security Considerations 672 The whole document can be seen as security considerations for CoAP. 674 4. IANA Considerations 676 This document has no actions for IANA. 678 5. References 680 5.1. Normative References 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, 684 DOI 10.17487/RFC2119, March 1997, 685 . 687 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 688 Application Protocol (CoAP)", RFC 7252, 689 DOI 10.17487/RFC7252, June 2014, 690 . 692 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 693 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 694 May 2017, . 696 5.2. Informative References 698 [I-D.ietf-core-echo-request-tag] 699 Amsuess, C., Mattsson, J., and G. Selander, "Echo and 700 Request-Tag", draft-ietf-core-echo-request-tag-02 (work in 701 progress), June 2018. 703 [I-D.ietf-core-object-security] 704 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 705 "Object Security for Constrained RESTful Environments 706 (OSCORE)", draft-ietf-core-object-security-15 (work in 707 progress), August 2018. 709 [I-D.liu-core-coap-delay-attacks] 710 Liu, Y. and J. Zhu, "Mitigating delay attacks on 711 Constrained Application Protocol", draft-liu-core-coap- 712 delay-attacks-01 (work in progress), October 2017. 714 [I-D.selander-ace-cose-ecdhe] 715 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 716 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 717 cose-ecdhe-09 (work in progress), July 2018. 719 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 720 (TLS) Protocol Version 1.2", RFC 5246, 721 DOI 10.17487/RFC5246, August 2008, 722 . 724 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 725 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 726 January 2012, . 728 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 729 RFC 8152, DOI 10.17487/RFC8152, July 2017, 730 . 732 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 733 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 734 Application Protocol) over TCP, TLS, and WebSockets", 735 RFC 8323, DOI 10.17487/RFC8323, February 2018, 736 . 738 Acknowledgements 740 The authors would like to thank Carsten Bormann, Klaus Hartke, Ari 741 Keraenen, Matthias Kovatsch, Sandeep Kumar, and Andras Mehes for 742 their valuable comments and feedback. 744 Authors' Addresses 746 John Mattsson 747 Ericsson AB 748 SE-164 80 Stockholm 749 Sweden 751 Email: john.mattsson@ericsson.com 753 John Fornehed 754 Ericsson AB 755 SE-164 80 Stockholm 756 Sweden 758 Email: john.fornehed@ericsson.com 760 Goeran Selander 761 Ericsson AB 762 SE-164 80 Stockholm 763 Sweden 765 Email: goran.selander@ericsson.com 767 Francesca Palombini 768 Ericsson AB 769 SE-164 80 Stockholm 770 Sweden 772 Email: francesca.palombini@ericsson.com 773 Christian Amsuess 774 Energy Harvesting Solutions 776 Email: c.amsuess@energyharvesting.at