idnits 2.17.1 draft-mattsson-core-coap-actuators-03.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 (October 30, 2017) is 2363 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 (-11) exists of draft-ietf-core-coap-tcp-tls-09 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-00 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-07 -- 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: Standards Track G. Selander 5 Expires: May 3, 2018 F. Palombini 6 Ericsson 7 C. Amsuess 8 Energy Harvesting Solutions 9 October 30, 2017 11 Controlling Actuators with CoAP 12 draft-mattsson-core-coap-actuators-03 14 Abstract 16 Being able to trust information from sensors and to securely control 17 actuators is 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 OSCOAP 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, one of the 23 attacks applies equally well to sensors using DTLS. 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 May 3, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. The Block Attack . . . . . . . . . . . . . . . . . . . . 3 63 2.2. The Request Delay Attack . . . . . . . . . . . . . . . . 4 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 74 6.2. Informative References . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 Being able to trust information from sensors and to securely control 80 actuators is 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 OSCOAP 86 [I-D.selander-ace-object-security] to protect CoAP, where the choice 87 of security protocol depends on the transport protocol and the 88 presence of intermediaries. The use of CoAP over UDP and DTLS is 89 specified in [RFC6347] and the use of CoAP over TCP and TLS is 90 specified in [I-D.ietf-core-coap-tcp-tls]. OSCOAP protects CoAP end- 91 to-end with the use of COSE [RFC8152] and the CoAP Object-Security 92 option [I-D.selander-ace-object-security], and can therefore be used 93 over any transport. In this document we show that protecting CoAP 94 with a security protocol is not enough to securely control actuators. 95 We describe several serious attacks any on-path attacker (i.e. not 96 only "trusted" intermediaries) can do, and discusses tougher 97 requirements and mechanisms to mitigate the attacks. The request 98 delay attack (valid for DTLS, TLS, and OSCOAP and described in 99 Section 2.2) lets an attacker control an actuator at a much later 100 time than the client anticipated. The response delay and mismatch 101 attack (valid for DTLS and described in Section 2.3) lets an attacker 102 respond to a client with a response meant for an older request. In 103 Section 3, a new CoAP Option, the Repeat Option, mitigating the delay 104 attack in specified. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 2. Attacks 116 Internet-of-Things (IoT) deployments valuing security and privacy, 117 MUST use a security protocol such as DTLS, TLS, or OSCOAP to protect 118 CoAP. This is especially true for deployments of actuators where 119 attacks often (but not always) have serious consequences. The 120 attacks described in this section are made under the assumption that 121 CoAP is already protected with a security protocol such as DTLS, TLS, 122 or OSCOAP, as an attacker otherwise can easily forge false requests 123 and responses. 125 2.1. The Block Attack 127 An on-path attacker can block the delivery of any number of requests 128 or responses. The attack can also be performed by an attacker 129 jamming the lower layer radio protocol. This is true even if a 130 security protocol like DTLS, TLS, or OSCOAP is used. Encryption 131 makes selective blocking of messages harder, but not impossible or 132 even infeasible. With DTLS and TLS, proxies have access to the 133 complete CoAP message, and with OSCOAP, the CoAP header and several 134 CoAP options are not encrypted. In both security protocols, the IP- 135 addresses, ports, and CoAP message lengths are available to all on- 136 path attackers, which may be enough to determine the server, 137 resource, and command. The block attack is illustrated in Figure 1 138 and 2. 140 Client Foe Server 141 | | | 142 +----->X | Code: 0.03 (PUT) 143 | PUT | | Token: 0x47 144 | | | Uri-Path: lock 145 | | | Payload: 1 (Lock) 146 | | | 148 Figure 1: Blocking a Request 150 Where 'X' means the attacker is blocking delivery of the message. 152 Client Foe Server 153 | | | 154 +------------>| Code: 0.03 (PUT) 155 | | PUT | Token: 0x47 156 | | | Uri-Path: lock 157 | | | Payload: 1 (Lock) 158 | | | 159 | X<-----+ Code: 2.04 (Changed) 160 | | 2.04 | Token: 0x47 161 | | | 163 Figure 2: Blocking a Response 165 While blocking requests to, or responses from, a sensor is just a 166 denial of service attack, blocking a request to, or a response from, 167 an actuator results in the client losing information about the 168 server's status. If the actuator e.g. is a lock (door, car, etc.), 169 the attack results in the client not knowing (except by using out-of- 170 band information) whether the lock is unlocked or locked, just like 171 the observer in the famous Schrodinger's cat thought experiment. Due 172 to the nature of the attack, the client cannot distinguish the attack 173 from connectivity problems, offline servers, or unexpected behavior 174 from middle boxes such as NATs and firewalls. 176 Remedy: Any IoT deployment of actuators where confirmation is 177 important MUST notify the user upon reception of the response, or 178 warn the user when a response is not received. 180 2.2. The Request Delay Attack 182 An on-path attacker may not only block packets, but can also delay 183 the delivery of any packet (request or response) by a chosen amount 184 of time. If CoAP is used over a reliable and ordered transport such 185 as TCP with TLS or OSCOAP, no messages can be delivered before the 186 delayed message. If CoAP is used over an unreliable and unordered 187 transport such as UDP with DTLS, or OSCOAP, other messages can be 188 delivered before the delayed message as long as the delayed packet is 189 delivered inside the replay window. When CoAP is used over UDP, both 190 DTLS and OSCOAP allow out-of-order delivery and uses sequence numbers 191 together with a replay window to protect against replay attacks. The 192 replay window has a default length of 64 in both DTLS and OSCOAP. 193 The attacker can control the replay window by blocking some or all 194 other packets. By first delaying a request, and then later, after 195 delivery, blocking the response to the request, the client is not 196 made aware of the delayed delivery except by the missing response. 197 The server has in general, no way of knowing that the request was 198 delayed and will therefore happily process the request. 200 If some wireless low-level protocol is used, the attack can also be 201 performed by the attacker simultaneously recording what the client 202 transmits while at the same time jamming the server. The request 203 delay attack is illustrated in Figure 3. 205 Client Foe Server 206 | | | 207 +----->@ | Code: 0.03 (PUT) 208 | PUT | | Token: 0x9c 209 | | | Uri-Path: lock 210 | | | Payload: 0 (Unlock) 211 | | | 212 .... .... 213 | | | 214 | @----->| Code: 0.03 (PUT) 215 | | PUT | Token: 0x9c 216 | | | Uri-Path: lock 217 | | | Payload: 0 (Unlock) 218 | | | 219 | X<-----+ Code: 2.04 (Changed) 220 | | 2.04 | Token: 0x9c 221 | | | 223 Figure 3: Delaying a Request 225 Where '@' means the attacker is storing and later forwarding the 226 message (@ may alternatively be seen as a wormhole connecting two 227 points in time). 229 While an attacker delaying a request to a sensor is often not a 230 security problem, an attacker delaying a request to an actuator 231 performing an action is often a serious problem. A request to an 232 actuator (for example a request to unlock a lock) is often only meant 233 to be valid for a short time frame, and if the request does not reach 234 the actuator during this short timeframe, the request should not be 235 fulfilled. In the unlock example, if the client does not get any 236 response and does not physically see the lock opening, the user is 237 likely to walk away, calling the locksmith (or the IT-support). 239 If a non-zero replay window is used (the default when CoAP is used 240 over UDP), the attacker can let the client interact with the actuator 241 before delivering the delayed request to the server (illustrated in 242 Figure 4). In the lock example, the attacker may store the first 243 "unlock" request for later use. The client will likely resend the 244 request with the same token. If DTLS is used, the resent packet will 245 have a different sequence number and the attacker can forward it. If 246 OSCOAP is used, resent packets will have the same sequence number and 247 the attacker must block them all until the client sends a new message 248 with a new sequence number (not shown in Figure 4). After a while 249 when the client has locked the door again, the attacker can deliver 250 the delayed "unlock" message to the door, a very serious attack. 252 Client Foe Server 253 | | | 254 +----->@ | Code: 0.03 (PUT) 255 | PUT | | Token: 0x9c 256 | | | Uri-Path: lock 257 | | | Payload: 0 (Unlock) 258 | | | 259 +------------>| Code: 0.03 (PUT) 260 | PUT | | Token: 0x9c 261 | | | Uri-Path: lock 262 | | | Payload: 0 (Unlock) 263 | | | 264 <-------------+ Code: 2.04 (Changed) 265 | | 2.04 | Token: 0x9c 266 | | | 267 .... .... 268 | | | 269 +------------>| Code: 0.03 (PUT) 270 | PUT | | Token: 0x7a 271 | | | Uri-Path: lock 272 | | | Payload: 1 (Lock) 273 | | | 274 <-------------+ Code: 2.04 (Changed) 275 | | 2.04 | Token: 0x7a 276 | | | 277 | @----->| Code: 0.03 (PUT) 278 | | PUT | Token: 0x9c 279 | | | Uri-Path: lock 280 | | | Payload: 0 (Unlock) 281 | | | 282 | X<-----+ Code: 2.04 (Changed) 283 | | 2.04 | Token: 0x9c 284 | | | 286 Figure 4: Delaying Request with Reordering 288 While the second attack (Figure 4) can be mitigated by using a replay 289 window of length zero, the first attack (Figure 3) cannot. A 290 solution must enable the server to verify that the request was 291 received within a certain time frame after it was sent. This can be 292 accomplished with either a challenge-response pattern, by exchanging 293 timestamps, or by only allowing requests a short period after client 294 authentication. Requiring a fresh client authentication (such as a 295 new TLS/DTLS handshake or an EDHOC key exchange 296 [I-D.selander-ace-cose-ecdhe]) mitigates the problem, but requires 297 larger messages and more processing than a dedicated solution. 298 Security solutions based on timestamps require exactly synchronized 299 time, and this is hard to control with complications such as time 300 zones and daylight saving. Even if the clocks are synchronized at 301 one point in time, they may easily get out-of-sync and an attacker 302 may even be able to affect the client or the server time in various 303 ways such as setting up a fake NTP server, broadcasting false time 304 signals to radio controlled clocks, or expose one of them to a strong 305 gravity field. As soon as client falsely believes it is time 306 synchronized with the server, delay attacks are possible. A 307 challenge response mechanism is much more failure proof and easy to 308 analyze. The challenge and response may be sent in a CoAP option or 309 in the CoAP payload. One such mechanism, the CoAP Replay Option, is 310 specified in Section 3. 312 Remedy: The CoAP Replay Option specified in Section 3 SHALL be used 313 for controlling actuators unless another application specific 314 challenge-response or timestamp mechanism is used. 316 2.3. The Response Delay and Mismatch Attack 318 The following attack can be performed if CoAP is protected by a 319 security protocol where the response is not bound to the request in 320 any way except by the CoAP token. This would include most general 321 security protocols, such as DTLS and IPsec, but not OSCOAP. The 322 attacker performs the attack by delaying delivery of a response until 323 the client sends a request with the same token. As long as the 324 response is inside the replay window (which the attacker can make 325 sure by blocking later responses), the response will be accepted by 326 the client as a valid response to the later request. CoAP [RFC7252] 327 uses a client generated token that the server echoes to match 328 responses to request, but does not give any guidelines for the use of 329 token with DTLS, except that the tokens currently "in use" SHOULD 330 (not SHALL) be unique. 332 The attack can be performed by an attacker on the wire, or an 333 attacker simultaneously recording what the server transmits while at 334 the same time jamming the client. The response delay and mismatch 335 attack is illustrated in Figure 5. 337 Client Foe Server 338 | | | 339 +------------>| Code: 0.03 (PUT) 340 | PUT | | Token: 0x77 341 | | | Uri-Path: lock 342 | | | Payload: 0 (Unlock) 343 | | | 344 | @<-----+ Code: 2.04 (Changed) 345 | | 2.04 | Token: 0x77 346 | | | 347 .... .... 348 | | | 349 +----->X | Code: 0.03 (PUT) 350 | PUT | | Token: 0x77 351 | | | Uri-Path: lock 352 | | | Payload: 0 (Lock) 353 | | | 354 <------@ | Code: 2.04 (Changed) 355 | 2.04 | | Token: 0x77 356 | | | 358 Figure 5: Delaying and Mismatching Response to PUT 360 If we once again take a lock as an example, the security consequences 361 may be severe as the client receives a response message likely to be 362 interpreted as confirmation of a locked door, while the received 363 response message is in fact confirming an earlier unlock of the door. 364 As the client is likely to leave the (believed to be locked) door 365 unattended, the attacker may enter the home, enterprise, or car 366 protected by the lock. 368 The same attack may be performed on sensors, also this with serious 369 consequences. As illustrated in Figure 6, an attacker may convince 370 the client that the lock is locked, when it in fact is not. The 371 "Unlock" request may be also be sent by another client authorized to 372 control the lock. 374 Client Foe Server 375 | | | 376 +------------>| Code: 0.01 (GET) 377 | GET | | Token: 0x77 378 | | | Uri-Path: lock 379 | | | 380 | @<-----+ Code: 2.05 (Content) 381 | | 2.05 | Token: 0x77 382 | | | Payload: 1 (Locked) 383 | | | 384 +------------>| Code: 0.03 (PUT) 385 | PUT | | Token: 0x34 386 | | | Uri-Path: lock 387 | | | Payload: 1 (Unlock) 388 | | | 389 | X<-----+ Code: 2.04 (Changed) 390 | | 2.04 | Token: 0x34 391 | | | 392 +----->X | Code: 0.01 (GET) 393 | GET | | Token: 0x77 394 | | | Uri-Path: lock 395 | | | 396 <------@ | Code: 2.05 (Content) 397 | 2.05 | | Token: 0x77 398 | | | Payload: 1 (Locked) 399 | | | 401 Figure 6: Delaying and Mismatching Response to GET 403 As illustrated in Figure 7, an attacker may even mix responses from 404 different resources as long as the two resources share the same DTLS 405 connection on some part of the path towards the client. This can 406 happen if the resources are located behind a common gateway, or are 407 served by the same CoAP proxy. An on-path attacker (not necessarily 408 a DTLS endpoint such as a proxy) may e.g. deceive a client that the 409 living room is on fire by responding with an earlier delayed response 410 from the oven (temperatures in degree Celsius). 412 Client Foe Server 413 | | | 414 +------------>| Code: 0.01 (GET) 415 | GET | | Token: 0x77 416 | | | Uri-Path: oven/temperature 417 | | | 418 | @<-----+ Code: 2.05 (Content) 419 | | 2.05 | Token: 0x77 420 | | | Payload: 225 421 | | | 422 .... .... 423 | | | 424 +----->X | Code: 0.01 (GET) 425 | GET | | Token: 0x77 426 | | | Uri-Path: livingroom/temperature 427 | | | 428 <------@ | Code: 2.05 (Content) 429 | 2.05 | | Token: 0x77 430 | | | Payload: 225 431 | | | 433 Figure 7: Delaying and Mismatching Response from other resource 435 Remedy: If CoAP is protected with a security protocol not providing 436 bindings between requests and responses (e.g. DTLS) the client MUST 437 NOT reuse any tokens for a given source/destination which the client 438 has not received responses to. The easiest way to accomplish this is 439 to implement the token as a counter and never reuse any tokens at 440 all, this approach SHOULD be followed. 442 2.4. The Relay Attack 444 Yet another type of attack can be performed in deployments where 445 actuator actions are triggered automatically based on proximity and 446 without any user interaction, e.g. a car (the client) constantly 447 polling for the car key (the server) and unlocking both doors and 448 engine as soon as the car key responds. An attacker (or pair of 449 attackers) may simply relay the CoAP messages out-of-band, using for 450 examples some other radio technology. By doing this, the actuator 451 (i.e. the car) believes that the client is close by and performs 452 actions based on that false assumption. The attack is illustrated in 453 Figure 8. In this example the car is using an application specific 454 challenge-response mechanism transferred as CoAP payloads. 456 Client Foe Foe Server 457 | | | | 458 +----->| ......... +----->| Code: 0.02 (POST) 459 | POST | | POST | Token: 0x3a 460 | | | | Uri-Path: lock 461 | | | | Payload: JwePR2iCe8b0ux (Challenge) 462 | | | | 463 |<-----+ ......... |<-----+ Code: 2.04 (Changed) 464 | 2.04 | | 2.04 | Token: 0x3a 465 | | | | Payload: RM8i13G8D5vfXK (Response) 466 | | | | 468 Figure 8: Relay Attack (the client is the actuator) 470 The consequences may be severe, and in the case of a car, lead to the 471 attacker unlocking and driving away with the car, an attack that 472 unfortunately is happening in practice. 474 Remedy: Getting a response over a short-range radio MUST NOT be taken 475 as proof of proximity and therefore MUST NOT be used to take actions 476 based on such proximity. Any automatically triggered mechanisms 477 relying on proximity MUST use other stronger mechanisms to guarantee 478 proximity. Mechanisms that MAY be used are: measuring the round-trip 479 time and calculate the maximum possible distance based on the speed 480 of light, or using radio with an extremely short range like NFC 481 (centimeters instead of meters). Another option is to including 482 geographical coordinates (from e.g. GPS) in the messages and 483 calculate proximity based on these, but in this case the location 484 measurements MUST be very precise and the system MUST make sure that 485 an attacker cannot influence the location estimation, something that 486 is very hard in practice. 488 2.5. The Request Fragment Rearrangement Attack 490 These attack scenarios show that the Request Delay and Block Attacks 491 can be used against blockwise transfers to cause unauthorized 492 operations to be performed on the server, and responses to 493 unauthorized operations to be mistaken for responses to authorized 494 operations. The combination of these attacks is described as a 495 separate attack because it makes the Request Delay Attack relevant to 496 systems that are otherwise not time-dependent, which means that they 497 could disregard the Request Delay Attack. 499 This attack works even if the individual request/response pairs are 500 encrypted, authenticated and protected against the Response Delay and 501 Mismatch Attack, provided the attacker is on the network path and can 502 correctly guess which operations the respective packages belong to. 504 2.5.1. Completing an operation with an earlier final block 506 In this scenario, blocks from two operations on a POST-accepting 507 resource are combined to make the server execute an action that was 508 not intended by the authorized client. This works only if the client 509 attempts a second operation after the first operation failed (due to 510 what the attacker made appear like a network outage) within the 511 replay window. The client does not receive a confirmation on the 512 second operation either, but, by the time the client acts on it, the 513 server has already executed the unauthorized action. 515 Client Foe Server 516 | | | 517 +-------------> POST "incarcerate" (Block1: 0, more to come) 518 | | | 519 <-------------+ 2.31 Continue (Block1: 0 received, send more) 520 | | | 521 +----->@ | POST "valjean" (Block1: 1, last block) 522 | | | 523 +----->X | All retransmissions dropped 524 | | | 526 (Client: Odd, but let's go on and promote Javert) 528 | | | 529 +-------------> POST "promote" (Block1: 0, more to come) 530 | | | 531 | X<-----+ 2.31 Continue (Block1: 0 received, send more) 532 | | | 533 | @------> POST "valjean" (Block1: 1, last block) 534 | | | 535 | X<-----+ 2.04 Valjean Promoted 537 Figure 1: Attack example 539 Remedy: If a client starts new blockwise operations on a security 540 context that has lost packages, it needs to label the fragments in 541 such a way that the server will not mix them up. 543 A mechanism to that effect is described as Request-Tag 544 [I-D.ietf-core-echo-request-tag]. Had it been in place in the 545 example and used for body integrity protection, the client would have 546 set the Request-Tag option in the "promote" request. Depending on 547 the server's capabilities and setup, either of four outcomes could 548 have occurred: 550 1. The server could have processed the reinjected POST "valjean" as 551 belonging to the original "incarcerate" block; that's the 552 expected case when the server can handle simultaneous block 553 transfers. 555 2. The server could respond 5.03 Service Unavailable, including a 556 Max-Age option indicating how long it prefers not to take any 557 requests that force it to overwrite the state kept for the 558 "incarcerate" request. 560 3. The server could decide to drop the state kept for the 561 "incarcerate" request's state, and process the "promote" request. 562 The reinjected POST "valjean" will then fail with 4.08 Request 563 Entity incomplete, indicating that the server does not have the 564 start of the operation any more. 566 2.5.2. Injecting a withheld first block 568 If the first block of a request is withheld by the attacker for later 569 use, it can be used to have the server process a different request 570 body than intended by the client. Unlike in the previous scenario, 571 it will return a response based on that body to the client. 573 Again, a first operation (that would go like "Homeless stole apples. 574 What shall we do with him?" - "Set him free.") is aborted by the 575 proxy, and a part of that operation is later used in a different 576 operation to prime the server for responding leniently to another 577 operation that would originally have been "Hitman killed someone. 578 What shall we do with him?" - "Hang him.". 580 Client Foe Server 581 | | | 582 +----->@ | POST "Homeless stole apples. Wh" 583 | | | (Block1: 0, more to come) 585 (Client: We'll try that one later again; for now, we have something 586 more urgent:) 588 | | | 589 +-------------> POST "Hitman killed someone. Wh" 590 | | | (Block1: 0, more to come) 591 | | | 592 | @<-----+ 2.31 Continue (Block1: 0 received, send more) 593 | | | 594 | @------> POST "Homeless stole apples. Wh" 595 | | | (Block1: 0, more to come) 596 | | | 597 | X<-----+ 2.31 Continue (Block1: 0 received, send more) 598 | | | 599 <------@ | 2.31 Continue (Block1: 0 received, send more) 600 | | | 601 +-------------> POST "at shall we do with him?" 602 | | | (Block1: 1, last block) 603 | | | 604 <-------------+ 2.05 "Set him free." 605 (Block1: 1 received and this is the result) 607 Figure 2: Attack example 609 3. Security Considerations 611 The whole document can be seen as security considerations for CoAP. 613 4. IANA Considerations 615 This document has no actions for IANA. 617 5. Acknowledgements 619 The authors would like to thank Carsten Bormann, Klaus Hartke, Ari 620 Keranen, Matthias Kovatsch, Sandeep Kumar, and Andras Mehes for their 621 valuable comments and feedback. 623 6. References 624 6.1. Normative References 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, 628 DOI 10.17487/RFC2119, March 1997, 629 . 631 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 632 Application Protocol (CoAP)", RFC 7252, 633 DOI 10.17487/RFC7252, June 2014, 634 . 636 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 637 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 638 May 2017, . 640 6.2. Informative References 642 [I-D.ietf-core-coap-tcp-tls] 643 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 644 Silverajan, B., and B. Raymor, "CoAP (Constrained 645 Application Protocol) over TCP, TLS, and WebSockets", 646 draft-ietf-core-coap-tcp-tls-09 (work in progress), May 647 2017. 649 [I-D.ietf-core-echo-request-tag] 650 Amsuess, C., Mattsson, J., and G. Selander, "Echo and 651 Request-Tag", draft-ietf-core-echo-request-tag-00 (work in 652 progress), October 2017. 654 [I-D.selander-ace-cose-ecdhe] 655 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 656 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 657 cose-ecdhe-07 (work in progress), July 2017. 659 [I-D.selander-ace-object-security] 660 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 661 "Object Security of CoAP (OSCOAP)", draft-selander-ace- 662 object-security-06 (work in progress), October 2016. 664 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 665 (TLS) Protocol Version 1.2", RFC 5246, 666 DOI 10.17487/RFC5246, August 2008, 667 . 669 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 670 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 671 January 2012, . 673 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 674 RFC 8152, DOI 10.17487/RFC8152, July 2017, 675 . 677 Authors' Addresses 679 John Mattsson 680 Ericsson AB 681 SE-164 80 Stockholm 682 Sweden 684 Email: john.mattsson@ericsson.com 686 John Fornehed 687 Ericsson AB 688 SE-164 80 Stockholm 689 Sweden 691 Email: john.fornehed@ericsson.com 693 Goran Selander 694 Ericsson AB 695 SE-164 80 Stockholm 696 Sweden 698 Email: goran.selander@ericsson.com 700 Francesca Palombini 701 Ericsson AB 702 SE-164 80 Stockholm 703 Sweden 705 Email: francesca.palombini@ericsson.com 707 Christian Amsuess 708 Energy Harvesting Solutions 710 Email: c.amsuess@energyharvesting.at