idnits 2.17.1 draft-ietf-core-attacks-on-coap-00.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(7): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(832): 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 9 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 401: '... "in use" SHOULD (not SHALL) be uniq...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 May 2022) is 717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-13 -- 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: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Preuß Mattsson 3 Internet-Draft J. Fornehed 4 Intended status: Informational G. Selander 5 Expires: 10 November 2022 F. Palombini 6 Ericsson 7 C. Amsüss 8 Energy Harvesting Solutions 9 9 May 2022 11 Attacks on the Constrained Application Protocol (CoAP) 12 draft-ietf-core-attacks-on-coap-00 14 Abstract 16 Being able to securely read information from sensors, to securely 17 control actuators, and to not enable distributed denial-of-service 18 attacks are essential in a world of connected and networking things 19 interacting with the physical world. This document summarizes a 20 number of known attacks on CoAP and show that just using CoAP with a 21 security protocol like DTLS, TLS, or OSCORE is not enough for secure 22 operation. Several of the discussed attacks can be mitigated with 23 the solutions in draft-ietf-core-echo-request-tag. 25 About This Document 27 This note is to be removed before publishing as an RFC. 29 Status information for this document may be found at 30 https://datatracker.ietf.org/doc/draft-ietf-core-attacks-on-coap/. 32 Discussion of this document takes place on the Constrained RESTful 33 Environments (CoRE) Working Group mailing list 34 (mailto:core@ietf.org), which is archived at 35 https://mailarchive.ietf.org/arch/browse/core/. 37 Source for this draft and an issue tracker can be found at 38 https://github.com/EricssonResearch/coap-actuators. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 10 November 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Attacks on CoAP . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.1. The Block Attack . . . . . . . . . . . . . . . . . . . . 5 76 2.2. The Request Delay Attack . . . . . . . . . . . . . . . . 6 77 2.3. The Response Delay and Mismatch Attack . . . . . . . . . 9 78 2.4. The Request Fragment Rearrangement Attack . . . . . . . . 12 79 2.4.1. Completing an Operation with an Earlier Final 80 Block . . . . . . . . . . . . . . . . . . . . . . . . 13 81 2.4.2. Injecting a Withheld First Block . . . . . . . . . . 14 82 2.4.3. Attack difficulty . . . . . . . . . . . . . . . . . . 15 83 2.5. The Relay Attack . . . . . . . . . . . . . . . . . . . . 16 84 3. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 5. Informative References . . . . . . . . . . . . . . . . . . . 17 87 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 Being able to securely read information from sensors and to securely 93 control actuators are essential in a world of connected and 94 networking things interacting with the physical world. One protocol 95 used to interact with sensors and actuators is the Constrained 96 Application Protocol (CoAP) [RFC7252]. Any Internet-of-Things (IoT) 97 deployment valuing security and privacy would use a security protocol 98 such as DTLS [RFC9147], TLS [RFC8446], or OSCORE [RFC8613] to protect 99 CoAP, where the choice of security protocol depends on the transport 100 protocol and the presence of intermediaries. The use of CoAP over 101 UDP and DTLS is specified in [RFC7252] and the use of CoAP over TCP 102 and TLS is specified in [RFC8323]. OSCORE protects CoAP end-to-end 103 with the use of COSE [RFC8152] and the CoAP Object-Security option 104 [RFC8613], and can therefore be used over any transport. 106 The Constrained Application Protocol (CoAP) [RFC7252] was designed 107 with the assumption that security could be provided on a separate 108 layer, in particular by using DTLS [RFC6347]. The four properties 109 traditionally provided by security protocols are: 111 * Data confidentiality 113 * Data origin authentication 115 * Data integrity checking 117 * Replay protection 119 In this document we show that protecting CoAP with a security 120 protocol on another layer is not nearly enough to securely control 121 actuators (and in many cases sensors) and that secure operation often 122 demands far more than the four properties traditionally provided by 123 security protocols. We describe several serious attacks any on-path 124 attacker (i.e., not only "trusted intermediaries") can do and 125 discusses tougher requirements and mechanisms to mitigate the 126 attacks. In general, secure operation of actuators also requires the 127 three properties: 129 * Data-to-data binding 131 * Data-to-space binding 133 * Data-to-time binding 135 "Data-to-data binding" is e.g., binding of responses to a request or 136 binding of data fragments to each other. "Data-to-space binding" is 137 the binding of data to an absolute or relative point in space (i.e., 138 a location) and may in the relative case be referred to as proximity. 139 "Data-to-time binding" is the binding of data to an absolute or 140 relative point in time and may in the relative case be referred to as 141 freshness. The two last properties may be bundled together as "Data- 142 to-spacetime binding". 144 Freshness is a measure of when a message was sent on a timescale of 145 the recipient. A client or server that receives a message can either 146 verify that the message is fresh or determine that it cannot be 147 verified that the message is fresh. What is considered fresh is 148 application dependent. Freshness is completely different from replay 149 protection, but most replay protection mechanism use a sequence 150 number. Assuming the client is well-behaving, such a sequence number 151 that can be used by the server as a relative measure of when a 152 message was sent on a timescale of the sender. Replay protection is 153 mandatory in TLS and OSCORE and optional in DTLS. DTLS and TLS use 154 sequence numbers for both requests and responses. In TLS the 155 sequence numbers are implicit and not sent in the record. OSCORE use 156 sequence numbers for requests and some responses. Most OSCORE 157 responses are bound to the request and therefore, enable the client 158 to determine if the response is fresh or not. 160 The request delay attack (valid for DTLS, TLS, and OSCORE and 161 described in Section 2.2) lets an attacker control an actuator at a 162 much later time than the client anticipated. The response delay and 163 mismatch attack (valid for DTLS and TLS and described in Section 2.3) 164 lets an attacker respond to a client with a response meant for an 165 older request. The request fragment rearrangement attack (valid for 166 DTLS, TLS, and OSCORE and described in Section 2.4) lets an attacker 167 cause unauthorized operations to be performed on the server, and 168 responses to unauthorized operations to be mistaken for responses to 169 authorized operations. 171 The goal with this document is motivating generic and protocol- 172 specific recommendations on the usage of CoAP. Mechanisms mitigating 173 some of the attacks discussed in this document can be found in 174 [RFC9175]. This document is a companion document to [RFC9175] giving 175 more information on the attacks motivating the mechanisms. 177 2. Attacks on CoAP 179 Internet-of-Things (IoT) deployments valuing security and privacy, 180 need to use a security protocol such as DTLS, TLS, or OSCORE to 181 protect CoAP. This is especially true for deployments of actuators 182 where attacks often (but not always) have serious consequences. The 183 attacks described in this section are made under the assumption that 184 CoAP is already protected with a security protocol such as DTLS, TLS, 185 or OSCORE, as an attacker otherwise can easily forge false requests 186 and responses. 188 2.1. The Block Attack 190 An on-path attacker can block the delivery of any number of requests 191 or responses. The attack can also be performed by an attacker 192 jamming the lower layer radio protocol. This is true even if a 193 security protocol like DTLS, TLS, or OSCORE is used. Encryption 194 makes selective blocking of messages harder, but not impossible or 195 even infeasible. With DTLS and TLS, proxies can read the complete 196 CoAP message, and with OSCORE, the CoAP header and several CoAP 197 options are not encrypted. In all three security protocols, the IP- 198 addresses, ports, and CoAP message lengths are available to all on- 199 path attackers, which may be enough to determine the server, 200 resource, and command. The block attack is illustrated in Figures 1 201 and 2. 203 Client Foe Server 204 | | | 205 +----->X | Code: 0.03 (PUT) 206 | PUT | | Token: 0x47 207 | | | Uri-Path: lock 208 | | | Payload: 1 (Lock) 209 | | | 211 Figure 1: Blocking a request 213 Where 'X' means the attacker is blocking delivery of the message. 215 Client Foe Server 216 | | | 217 +------------>| Code: 0.03 (PUT) 218 | | PUT | Token: 0x47 219 | | | Uri-Path: lock 220 | | | Payload: 1 (Lock) 221 | | | 222 | X<-----+ Code: 2.04 (Changed) 223 | | 2.04 | Token: 0x47 224 | | | 226 Figure 2: Blocking a response 228 While blocking requests to, or responses from, a sensor is just a 229 denial-of-service attack, blocking a request to, or a response from, 230 an actuator results in the client losing information about the 231 server's status. If the actuator e.g., is a lock (door, car, etc.), 232 the attack results in the client not knowing (except by using out-of- 233 band information) whether the lock is unlocked or locked, just like 234 the observer in the famous Schrödinger’s cat thought experiment. Due 235 to the nature of the attack, the client cannot distinguish the attack 236 from connectivity problems, offline servers, or unexpected behavior 237 from middle boxes such as NATs and firewalls. 239 Remedy: Any IoT deployment of actuators where synchronized state is 240 important need to use confirmable messages and the client need to 241 take appropriate actions when a response is not received and it 242 therefore loses information about the server's status. 244 2.2. The Request Delay Attack 246 An on-path attacker may not only block packets, but can also delay 247 the delivery of any packet (request or response) by a chosen amount 248 of time. If CoAP is used over a reliable and ordered transport such 249 as TCP with TLS or OSCORE (with TLS-like sequence number handling), 250 no messages can be delivered before the delayed message. If CoAP is 251 used over an unreliable and unordered transport such as UDP with DTLS 252 or OSCORE, other messages can be delivered before the delayed message 253 as long as the delayed packet is delivered inside the replay window. 254 When CoAP is used over UDP, both DTLS and OSCORE allow out-of-order 255 delivery and uses sequence numbers together with a replay window to 256 protect against replay attacks against requests. The replay window 257 has a default length of 64 in DTLS and 32 in OSCORE. The attacker 258 can influence the replay window state by blocking and delaying 259 packets. By first delaying a request, and then later, after 260 delivery, blocking the response to the request, the client is not 261 made aware of the delayed delivery except by the missing response. 262 In general, the server has no way of knowing that the request was 263 delayed and will therefore happily process the request. Note that 264 delays can also happen for other reasons than a malicious attacker. 266 If some wireless low-level protocol is used, the attack can also be 267 performed by the attacker simultaneously recording what the client 268 transmits while at the same time jamming the server. The request 269 delay attack is illustrated in Figure 3. 271 Client Foe Server 272 | | | 273 +----->@ | Code: 0.03 (PUT) 274 | PUT | | Token: 0x9c 275 | | | Uri-Path: lock 276 | | | Payload: 0 (Unlock) 277 | | | 278 .... .... 279 | | | 280 | @----->| Code: 0.03 (PUT) 281 | | PUT | Token: 0x9c 282 | | | Uri-Path: lock 283 | | | Payload: 0 (Unlock) 284 | | | 285 | X<-----+ Code: 2.04 (Changed) 286 | | 2.04 | Token: 0x9c 287 | | | 289 Figure 3: Delaying a request 291 Where '@' means the attacker is storing and later forwarding the 292 message (@ may alternatively be seen as a wormhole connecting two 293 points in time). 295 While an attacker delaying a request to a sensor is often not a 296 security problem, an attacker delaying a request to an actuator 297 performing an action is often a serious problem. A request to an 298 actuator (for example a request to unlock a lock) is often only meant 299 to be valid for a short time frame, and if the request does not reach 300 the actuator during this short timeframe, the request should not be 301 fulfilled. In the unlock example, if the client does not get any 302 response and does not physically see the lock opening, the user is 303 likely to walk away, calling the locksmith (or the IT-support). 305 If a non-zero replay window is used (the default when CoAP is used 306 over UDP), the attacker can let the client interact with the actuator 307 before delivering the delayed request to the server (illustrated in 308 Figure 4). In the lock example, the attacker may store the first 309 "unlock" request for later use. The client will likely resend the 310 request with the same token. If DTLS is used, the resent packet will 311 have a different sequence number and the attacker can forward it. If 312 OSCORE is used, resent packets will have the same sequence number and 313 the attacker must block them all until the client sends a new message 314 with a new sequence number (not shown in Figure 4). After a while 315 when the client has locked the door again, the attacker can deliver 316 the delayed "unlock" message to the door, a very serious attack. 318 Client Foe Server 319 | | | 320 +----->@ | Code: 0.03 (PUT) 321 | PUT | | Token: 0x9c 322 | | | Uri-Path: lock 323 | | | Payload: 0 (Unlock) 324 | | | 325 +------------>| Code: 0.03 (PUT) 326 | PUT | | Token: 0x9c 327 | | | Uri-Path: lock 328 | | | Payload: 0 (Unlock) 329 | | | 330 <-------------+ Code: 2.04 (Changed) 331 | | 2.04 | Token: 0x9c 332 | | | 333 .... .... 334 | | | 335 +------------>| Code: 0.03 (PUT) 336 | PUT | | Token: 0x7a 337 | | | Uri-Path: lock 338 | | | Payload: 1 (Lock) 339 | | | 340 <-------------+ Code: 2.04 (Changed) 341 | | 2.04 | Token: 0x7a 342 | | | 343 | @----->| Code: 0.03 (PUT) 344 | | PUT | Token: 0x9c 345 | | | Uri-Path: lock 346 | | | Payload: 0 (Unlock) 347 | | | 348 | X<-----+ Code: 2.04 (Changed) 349 | | 2.04 | Token: 0x9c 350 | | | 352 Figure 4: Delaying request with reordering 354 While the second attack (Figure 4) can be mitigated by using a replay 355 window of length zero, the first attack (Figure 3) cannot. A 356 solution must enable the server to verify that the request was 357 received within a certain time frame after it was sent or enable the 358 server to securely determine an absolute point in time when the 359 request is to be executed. This can be accomplished with either a 360 challenge-response pattern, by exchanging timestamps between client 361 and server, or by only allowing requests a short period after client 362 authentication. 364 Requiring a fresh client authentication (such as a new TLS/DTLS 365 handshake or an EDHOC key exchange [I-D.ietf-lake-edhoc]) mitigates 366 the problem, but requires larger messages and more processing than a 367 dedicated solution. Security solutions based on exchanging 368 timestamps require exactly synchronized time between client and 369 server, and this may be hard to control with complications such as 370 time zones and daylight saving. Wall clock time is not monotonic, 371 may reveal that the endpoints will accept expired certificates, or 372 reveal the endpoint's location. Use of non-monotonic clocks is 373 problematic as the server will accept requests if the clock is moved 374 backward and reject requests if the clock is moved forward. Even if 375 the clocks are synchronized at one point in time, they may easily get 376 out-of-sync and an attacker may even be able to affect the client or 377 the server time in various ways such as setting up a fake NTP server, 378 broadcasting false time signals to radio-controlled clocks, or 379 exposing one of them to a strong gravity field. As soon as client 380 falsely believes it is time synchronized with the server, delay 381 attacks are possible. A challenge response mechanism where the 382 server does not need to synchronize its time with the client is 383 easier to analyze but require more roundtrips. The challenges, 384 responses, and timestamps may be sent in a CoAP option or in the CoAP 385 payload. 387 Remedy: Any IoT deployment of actuators where freshness is important 388 should use the mechanisms specified in [RFC9175] unless another 389 application specific challenge-response or timestamp mechanism is 390 used. 392 2.3. The Response Delay and Mismatch Attack 394 The following attack can be performed if CoAP is protected by a 395 security protocol where the response is not bound to the request in 396 any way except by the CoAP token. This would include most general 397 security protocols, such as DTLS, TLS, and IPsec, but not OSCORE. 398 CoAP [RFC7252] uses a client generated token that the server echoes 399 to match responses to request, but does not give any guidelines for 400 the use of token with DTLS and TLS, except that the tokens currently 401 "in use" SHOULD (not SHALL) be unique. In HTTPS, this type of 402 binding is always assured by the ordered and reliable delivery, as 403 well as mandating that the server sends responses in the same order 404 that the requests were received. 406 The attacker performs the attack by delaying delivery of a response 407 until the client sends a request with the same token, the response 408 will be accepted by the client as a valid response to the later 409 request. If CoAP is used over a reliable and ordered transport such 410 as TCP with TLS, no messages can be delivered before the delayed 411 message. If CoAP is used over an unreliable and unordered transport 412 such as UDP with DTLS, other messages can be delivered before the 413 delayed message as long as the delayed packet is delivered inside the 414 replay window. Note that mismatches can also happen for other 415 reasons than a malicious attacker, e.g., delayed delivery or a server 416 sending notifications to an uninterested client. 418 The attack can be performed by an attacker on the wire, or an 419 attacker simultaneously recording what the server transmits while at 420 the same time jamming the client. As (D)TLS encrypts the Token, the 421 attacker needs to predict when the Token is resused. How hard that 422 is depends on the CoAP library, but some implementations are known to 423 omit the Token as much as possible and others lets the application 424 chose the Token. If the response is a "piggybacked response", the 425 client may additionally check the Message ID and drop it on mismatch. 426 That doesn't make the attack impossible, but lowers the probability. 428 The response delay and mismatch attack is illustrated in Figure 5. 430 Client Foe Server 431 | | | 432 +------------>| Code: 0.03 (PUT) 433 | PUT | | Token: 0x77 434 | | | Uri-Path: lock 435 | | | Payload: 0 (Unlock) 436 | | | 437 | @<-----+ Code: 2.04 (Changed) 438 | | 2.04 | Token: 0x77 439 | | | 440 .... .... 441 | | | 442 +----->X | Code: 0.03 (PUT) 443 | PUT | | Token: 0x77 444 | | | Uri-Path: lock 445 | | | Payload: 0 (Lock) 446 | | | 447 <------@ | Code: 2.04 (Changed) 448 | 2.04 | | Token: 0x77 449 | | | 451 Figure 5: Delaying and mismatching response to PUT 453 If we once again take a lock as an example, the security consequences 454 may be severe as the client receives a response message likely to be 455 interpreted as confirmation of a locked door, while the received 456 response message is in fact confirming an earlier unlock of the door. 457 As the client is likely to leave the (believed to be locked) door 458 unattended, the attacker may enter the home, enterprise, or car 459 protected by the lock. 461 The same attack may be performed on sensors. As illustrated in 462 Figure 6, an attacker may convince the client that the lock is 463 locked, when it in fact is not. The "Unlock" request may be also be 464 sent by another client authorized to control the lock. 466 Client Foe Server 467 | | | 468 +------------>| Code: 0.01 (GET) 469 | GET | | Token: 0x77 470 | | | Uri-Path: lock 471 | | | 472 | @<-----+ Code: 2.05 (Content) 473 | | 2.05 | Token: 0x77 474 | | | Payload: 1 (Locked) 475 | | | 476 +------------>| Code: 0.03 (PUT) 477 | PUT | | Token: 0x34 478 | | | Uri-Path: lock 479 | | | Payload: 1 (Unlock) 480 | | | 481 | X<-----+ Code: 2.04 (Changed) 482 | | 2.04 | Token: 0x34 483 | | | 484 +----->X | Code: 0.01 (GET) 485 | GET | | Token: 0x77 486 | | | Uri-Path: lock 487 | | | 488 <------@ | Code: 2.05 (Content) 489 | 2.05 | | Token: 0x77 490 | | | Payload: 1 (Locked) 491 | | | 493 Figure 6: Delaying and mismatching response to GET 495 As illustrated in Figure 7, an attacker may even mix responses from 496 different resources as long as the two resources share the same 497 (D)TLS connection on some part of the path towards the client. This 498 can happen if the resources are located behind a common gateway, or 499 are served by the same CoAP proxy. An on-path attacker (not 500 necessarily a (D)TLS endpoint such as a proxy) may e.g., deceive a 501 client that the living room is on fire by responding with an earlier 502 delayed response from the oven (temperatures in degree Celsius). 504 Client Foe Server 505 | | | 506 +------------>| Code: 0.01 (GET) 507 | GET | | Token: 0x77 508 | | | Uri-Path: oven/temperature 509 | | | 510 | @<-----+ Code: 2.05 (Content) 511 | | 2.05 | Token: 0x77 512 | | | Payload: 225 513 | | | 514 .... .... 515 | | | 516 +----->X | Code: 0.01 (GET) 517 | GET | | Token: 0x77 518 | | | Uri-Path: livingroom/temperature 519 | | | 520 <------@ | Code: 2.05 (Content) 521 | 2.05 | | Token: 0x77 522 | | | Payload: 225 523 | | | 525 Figure 7: Delaying and mismatching response from other resource 527 Remedy: Section 4.2 of [RFC9175] formally updates the client token 528 processing for CoAP [RFC7252]. Following this updated processing 529 mitigates the attack. 531 2.4. The Request Fragment Rearrangement Attack 533 These attack scenarios show that the Request Delay and Block Attacks 534 can be used against block-wise transfers to cause unauthorized 535 operations to be performed on the server, and responses to 536 unauthorized operations to be mistaken for responses to authorized 537 operations. The combination of these attacks is described as a 538 separate attack because it makes the Request Delay Attack relevant to 539 systems that are otherwise not time-dependent, which means that they 540 could disregard the Request Delay Attack. 542 This attack works even if the individual request/response pairs are 543 encrypted, authenticated and protected against the Response Delay and 544 Mismatch Attack, provided the attacker is on the network path and can 545 correctly guess which operations the respective packages belong to. 547 The attacks can be performed on any security protocol where the 548 attacker can delay the delivery of a message unnoticed. This 549 incluses DTLS, IPsec, and most OSCORE configurations. The attacks 550 does not work on TCP with TLS or OSCORE (with TLS-like sequence 551 number handling) as in these cases no messages can be delivered 552 before the delayed message. 554 2.4.1. Completing an Operation with an Earlier Final Block 556 In this scenario (illustrated in Figure 8), blocks from two 557 operations on a POST-accepting resource are combined to make the 558 server execute an action that was not intended by the authorized 559 client. This works only if the client attempts a second operation 560 after the first operation failed (due to what the attacker made 561 appear like a network outage) within the replay window. The client 562 does not receive a confirmation on the second operation either, but, 563 by the time the client acts on it, the server has already executed 564 the unauthorized action. 566 Client Foe Server 567 | | | 568 +-------------> POST "incarcerate" (Block1: 0, more to come) 569 | | | 570 <-------------+ 2.31 Continue (Block1: 0 received, send more) 571 | | | 572 +----->@ | POST "valjean" (Block1: 1, last block) 573 | | | 574 +----->X | All retransmissions dropped 575 | | | 577 (Client: Odd, but let's go on and promote Javert) 579 | | | 580 +-------------> POST "promote" (Block1: 0, more to come) 581 | | | 582 | X<-----+ 2.31 Continue (Block1: 0 received, send more) 583 | | | 584 | @------> POST "valjean" (Block1: 1, last block) 585 | | | 586 | X<-----+ 2.04 Valjean Promoted 587 | | | 589 Figure 8: Completing an operation with an earlier final block 591 Remedy: If a client starts new block-wise operations on a security 592 context that has lost packets, it needs to label the fragments in 593 such a way that the server will not mix them up. 595 A mechanism to that effect is described as Request-Tag [RFC9175]. 596 Had it been in place in the example and used for body integrity 597 protection, the client would have set the Request-Tag option in the 598 "promote" request. Depending on the server's capabilities and setup, 599 either of four outcomes could have occurred: 601 1. The server could have processed the reinjected POST "valjean" as 602 belonging to the original "incarcerate" block; that's the 603 expected case when the server can handle simultaneous block 604 transfers. 606 2. The server could respond 5.03 Service Unavailable, including a 607 Max-Age option indicating how long it prefers not to take any 608 requests that force it to overwrite the state kept for the 609 "incarcerate" request. 611 3. The server could decide to drop the state kept for the 612 "incarcerate" request's state, and process the "promote" request. 613 The reinjected POST "valjean" will then fail with 4.08 Request 614 Entity incomplete, indicating that the server does not have the 615 start of the operation any more. 617 2.4.2. Injecting a Withheld First Block 619 If the first block of a request is withheld by the attacker for later 620 use, it can be used to have the server process a different request 621 body than intended by the client. Unlike in the previous scenario, 622 it will return a response based on that body to the client. 624 Again, a first operation (that would go like "Girl stole apple. What 625 shall we do with her?" - "Set her free.") is aborted by the proxy, 626 and a part of that operation is later used in a different operation 627 to prime the server for responding leniently to another operation 628 that would originally have been "Evil Queen poisoned apple. What 629 shall we do with her?" - "Lock her up.". The attack is illustrated 630 in Figure 9. 632 Client Foe Server 633 | | | 634 +----->@ | POST "Girl stole apple. Wh" 635 | | | (Block1: 0, more to come) 637 (Client: We'll try that one later again; for now, we have something 638 more urgent:) 640 | | | 641 +-------------> POST "Evil Queen poisened apple. Wh" 642 | | | (Block1: 0, more to come) 643 | | | 644 | @<-----+ 2.31 Continue (Block1: 0 received, send more) 645 | | | 646 | @------> POST "Girl stole apple. Wh" 647 | | | (Block1: 0, more to come) 648 | | | 649 | X<-----+ 2.31 Continue (Block1: 0 received, send more) 650 | | | 651 <------@ | 2.31 Continue (Block1: 0 received, send more) 652 | | | 653 +-------------> POST "at shall we do with her?" 654 | | | (Block1: 1, last block) 655 | | | 656 <-------------+ 2.05 "Set her free." 657 | | | (Block1: 1 received and this is the result) 659 Figure 9: Injecting a withheld first block 661 The remedy described in Section 2.4.1 works also for this case. Note 662 that merely requiring that blocks of an operation should have 663 incrementing sequence numbers would be insufficient to remedy this 664 attack. 666 2.4.3. Attack difficulty 668 The success of any fragment rearrangement attack has multiple 669 prerequisites: 671 * A client sends different block-wise requests that are only 672 distinguished by their content. 674 This is generally rare in typical CoRE applications, but can 675 happen when the bodies of FETCH requests exceed the fragmentation 676 threshold, or when SOAP patterns are emulated. 678 * A client starts later block-wise operations after an earlier one 679 has failed. 681 This happens regularly as a consequence of operating in a low- 682 power and lossy network: Losses can cause failed operation 683 (especially when the network is unavailable for time exceeding the 684 "few expected round-trips" they may be limited to per [RFC7959]), 685 and the cost of reestablishing a security context. 687 * The attacker needs to be able to determine which packets contain 688 which fragments. 690 This can be achieved by an on-path attacker by observing request 691 timing, or simply by observing request sizes in the case when a 692 body is split into precisely two blocks. 694 It is _not_ a prerequisite that the resulting misassembled request 695 body is syntactically correct: As the server erroneously expects the 696 body to be integrity protected from an authorized source, it might be 697 using a parser not suitable for untrusted input. Such a parser might 698 crash the server in extreme cases, but might also produce a valid but 699 incorrect response to the request the client associates the response 700 with. Note that many constrained applications aim to minimize 701 traffic and thus employ compact data formats; that compactness leaves 702 little room for syntactically invalid messages. 704 The attack is easier if the attacker has control over the request 705 bodies (which would be the case when a trusted proxy validates the 706 attacker's authorization to perform two given requests, and an attack 707 on the path between the proxy and the server recombines the blocks to 708 a semantically different request). Attacks of that shape can easily 709 result in reassembled bodies chosen by the attacker, but no services 710 are currently known that operate in this way. 712 Summarizing, it is unlikely that an attacker can perform any of the 713 fragment rearrangement attacks on any given system -- but given the 714 diversity of applications built on CoAP, it is easily to imagine that 715 single applications would be vulnerable. As block-wise transfer is a 716 basic feature of CoAP and its details are sometimes hidden behind 717 abstractions or proxies, application authors can not be expected to 718 design their applications with these attacks in mind, and mitigation 719 on the protocol level is prudent. 721 2.5. The Relay Attack 723 Yet another type of attack can be performed in deployments where 724 actuator actions are triggered automatically based on proximity and 725 without any user interaction, e.g., a car (the client) constantly 726 polling for the car key (the server) and unlocking both doors and 727 engine as soon as the car key responds. An attacker (or pair of 728 attackers) may simply relay the CoAP messages out-of-band, using for 729 examples some other radio technology. By doing this, the actuator 730 (i.e., the car) believes that the client is close by and performs 731 actions based on that false assumption. The attack is illustrated in 732 Figure 10. In this example the car is using an application specific 733 challenge-response mechanism transferred as CoAP payloads. 735 Client Foe Foe Server 736 | | | | 737 +----->| ......... +----->| Code: 0.02 (POST) 738 | POST | | POST | Token: 0x3a 739 | | | | Uri-Path: lock 740 | | | | Payload: JwePR2iCe8b0ux (Challenge) 741 | | | | 742 |<-----+ ......... |<-----+ Code: 2.04 (Changed) 743 | 2.04 | | 2.04 | Token: 0x3a 744 | | | | Payload: RM8i13G8D5vfXK (Response) 745 | | | | 747 Figure 10: Relay attack (the client is the actuator) 749 The consequences may be severe, and in the case of a car, lead to the 750 attacker unlocking and driving away with the car, an attack that 751 unfortunately is happening in practice. 753 Remedy: Getting a response over a short-range radio cannot be taken 754 as proof of proximity and can therefore not be used to take actions 755 based on such proximity. Any automatically triggered mechanisms 756 relying on proximity need to use other stronger mechanisms to 757 establish proximity. Mechanisms that can be used are: measuring the 758 round-trip time and calculating the maximum possible distance based 759 on the speed of light, or using radio with an extremely short range 760 like NFC (centimeters instead of meters). Another option is to 761 include geographical coordinates (from e.g., GPS) in the messages and 762 calculate proximity based on these, but in this case the location 763 measurements need to be very precise and the system need to make sure 764 that an attacker cannot influence the location estimation. Some 765 types of global navigation satellite systems (GNSS) receivers are 766 vulnerable to spoofing attacks. 768 3. Security Considerations 770 The whole document can be seen as security considerations for CoAP. 772 4. IANA Considerations 774 This document has no actions for IANA. 776 5. Informative References 778 [I-D.ietf-lake-edhoc] 779 Selander, G., Mattsson, J. P., and F. Palombini, 780 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 781 Progress, Internet-Draft, draft-ietf-lake-edhoc-13, 18 782 April 2022, . 785 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 786 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 787 January 2012, . 789 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 790 Application Protocol (CoAP)", RFC 7252, 791 DOI 10.17487/RFC7252, June 2014, 792 . 794 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 795 the Constrained Application Protocol (CoAP)", RFC 7959, 796 DOI 10.17487/RFC7959, August 2016, 797 . 799 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 800 RFC 8152, DOI 10.17487/RFC8152, July 2017, 801 . 803 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 804 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 805 Application Protocol) over TCP, TLS, and WebSockets", 806 RFC 8323, DOI 10.17487/RFC8323, February 2018, 807 . 809 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 810 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 811 . 813 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 814 "Object Security for Constrained RESTful Environments 815 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 816 . 818 [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 819 Datagram Transport Layer Security (DTLS) Protocol Version 820 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 821 . 823 [RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander, 824 "Constrained Application Protocol (CoAP): Echo, Request- 825 Tag, and Token Processing", RFC 9175, 826 DOI 10.17487/RFC9175, February 2022, 827 . 829 Acknowledgements 831 The authors would like to thank Carsten Bormann, Klaus Hartke, Jaime 832 Jiménez, Ari Keränen, Matthias Kovatsch, Achim Kraus, Sandeep Kumar, 833 and András Méhes for their valuable comments and feedback. 835 Authors' Addresses 837 John Preuß Mattsson 838 Ericsson AB 839 SE-164 80 Stockholm 840 Sweden 841 Email: john.mattsson@ericsson.com 843 John Fornehed 844 Ericsson AB 845 SE-164 80 Stockholm 846 Sweden 847 Email: john.fornehed@ericsson.com 849 Göran Selander 850 Ericsson AB 851 SE-164 80 Stockholm 852 Sweden 853 Email: goran.selander@ericsson.com 855 Francesca Palombini 856 Ericsson AB 857 SE-164 80 Stockholm 858 Sweden 859 Email: francesca.palombini@ericsson.com 861 Christian Amsüss 862 Energy Harvesting Solutions 863 Email: c.amsuess@energyharvesting.at