idnits 2.17.1 draft-mattsson-core-coap-actuators-02.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 : ---------------------------------------------------------------------------- ** 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 104: '... MUST use a security protocol such a...' RFC 2119 keyword, line 164: '... important MUST notify the user upon...' RFC 2119 keyword, line 300: '...n specified in Section 3 SHALL be used...' RFC 2119 keyword, line 317: '...t the tokens currently "in use" SHOULD...' RFC 2119 keyword, line 424: '...responses (e.g. DTLS) the client MUST...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 27, 2016) is 2678 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-05 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-04 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) 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. Mattsson 3 Internet-Draft J. Fornehed 4 Intended status: Standards Track G. Selander 5 Expires: May 31, 2017 F. Palombini 6 Ericsson 7 November 27, 2016 9 Controlling Actuators with CoAP 10 draft-mattsson-core-coap-actuators-02 12 Abstract 14 Being able to trust information from sensors and to securely control 15 actuators is essential in a world of connected and networking things 16 interacting with the physical world. In this memo we show that just 17 using COAP with a security protocol like DTLS, TLS, or OSCOAP is not 18 enough. We describe several serious attacks any on-path attacker can 19 do, and discusses tougher requirements and mechanisms to mitigate the 20 attacks. While this document is focused on actuators, one of the 21 attacks applies equally well to sensors using DTLS. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 31, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. The Block Attack . . . . . . . . . . . . . . . . . . . . 3 60 2.2. The Request Delay Attack . . . . . . . . . . . . . . . . 4 61 2.3. The Response Delay and Mismatch Attack . . . . . . . . . 7 62 2.4. The Relay Attack . . . . . . . . . . . . . . . . . . . . 10 63 3. The Repeat Option . . . . . . . . . . . . . . . . . . . . . . 11 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 69 7.2. Informative References . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 Being able to trust information from sensors and to securely control 75 actuators is essential in a world of connected and networking things 76 interacting with the physical world. One protocol used to interact 77 with sensors and actuators is the Constrained Application Protocol 78 (CoAP) [RFC7252]. Any Internet-of-Things (IoT) deployment valuing 79 security and privacy would use a security protocol such as DTLS 80 [RFC6347], TLS [RFC5246], or OSCOAP 81 [I-D.selander-ace-object-security] to protect CoAP, where the choice 82 of security protocol depends on the transport protocol and the 83 presence of intermediaries. The use of CoAP over UDP and DTLS is 84 specified in [RFC6347] and the use of CoAP over TCP and TLS is 85 specified in [I-D.ietf-core-coap-tcp-tls]. OSCOAP protects CoAP end- 86 to-end with the use of COSE [I-D.ietf-cose-msg] and the CoAP Object- 87 Security option [I-D.selander-ace-object-security], and can therefore 88 be used over any transport. In this document we show that protecting 89 CoAP with a security protocol is not enough to securely control 90 actuators. We describe several serious attacks any on-path attacker 91 (i.e. not only "trusted" intermediaries) can do, and discusses 92 tougher requirements and mechanisms to mitigate the attacks. The 93 request delay attack (valid for DTLS, TLS, and OSCOAP and described 94 in Section 2.2) lets an attacker control an actuator at a much later 95 time than the client anticipated. The response delay and mismatch 96 attack (valid for DTLS and described in Section 2.3) lets an attacker 97 respond to a client with a response meant for an older request. In 98 Section 3, a new CoAP Option, the Repeat Option, mitigating the delay 99 attack in specified. 101 2. Attacks 103 Internet-of-Things (IoT) deployments valuing security and privacy, 104 MUST use a security protocol such as DTLS, TLS, or OSCOAP to protect 105 CoAP. This is especially true for deployments of actuators where 106 attacks often (but not always) have serious consequences. The 107 attacks described in this section are made under the assumption that 108 CoAP is already protected with a security protocol such as DTLS, TLS, 109 or OSCOAP, as an attacker otherwise can easily forge false requests 110 and responses. 112 2.1. The Block Attack 114 An on-path attacker can block the delivery of any number of requests 115 or responses. The attack can also be performed by an attacker 116 jamming the lower layer radio protocol. This is true even if a 117 security protocol like DTLS, TLS, or OSCOAP is used. Encryption 118 makes selective blocking of messages harder, but not impossible or 119 even infeasible. With DTLS and TLS, proxies have access to the 120 complete CoAP message, and with OSCOAP, the CoAP header and several 121 CoAP options are not encrypted. In both security protocols, the IP- 122 addresses, ports, and CoAP message lengths are available to all on- 123 path attackers, which may be enough to determine the server, 124 resource, and command. The block attack is illustrated in Figure 1 125 and 2. 127 Client Foe Server 128 | | | 129 +----->X | Code: 0.03 (PUT) 130 | PUT | | Token: 0x47 131 | | | Uri-Path: lock 132 | | | Payload: 1 (Lock) 133 | | | 135 Figure 1: Blocking a Request 137 Where 'X' means the attacker is blocking delivery of the message. 139 Client Foe Server 140 | | | 141 +------------>| Code: 0.03 (PUT) 142 | | PUT | Token: 0x47 143 | | | Uri-Path: lock 144 | | | Payload: 1 (Lock) 145 | | | 146 | X<-----+ Code: 2.04 (Changed) 147 | | 2.04 | Token: 0x47 148 | | | 150 Figure 2: Blocking a Response 152 While blocking requests to, or responses from, a sensor is just a 153 denial of service attack, blocking a request to, or a response from, 154 an actuator results in the client losing information about the 155 server's status. If the actuator e.g. is a lock (door, car, etc.), 156 the attack results in the client not knowing (except by using out-of- 157 band information) whether the lock is unlocked or locked, just like 158 the observer in the famous Schrodinger's cat thought experiment. Due 159 to the nature of the attack, the client cannot distinguish the attack 160 from connectivity problems, offline servers, or unexpected behavior 161 from middle boxes such as NATs and firewalls. 163 Remedy: Any IoT deployment of actuators where confirmation is 164 important MUST notify the user upon reception of the response, or 165 warn the user when a response is not received. 167 2.2. The Request Delay Attack 169 An on-path attacker may not only block packets, but can also delay 170 the delivery of any packet (request or response) by a chosen amount 171 of time. If CoAP is used over a reliable and ordered transport such 172 as TCP with TLS or OSCOAP, no messages can be delivered before the 173 delayed message. If CoAP is used over an unreliable and unordered 174 transport such as UDP with DTLS, or OSCOAP, other messages can be 175 delivered before the delayed message as long as the delayed packet is 176 delivered inside the replay window. When CoAP is used over UDP, both 177 DTLS and OSCOAP allow out-of-order delivery and uses sequence numbers 178 together with a replay window to protect against replay attacks. The 179 replay window has a default length of 64 in both DTLS and OSCOAP. 180 The attacker can control the replay window by blocking some or all 181 other packets. By first delaying a request, and then later, after 182 delivery, blocking the response to the request, the client is not 183 made aware of the delayed delivery except by the missing response. 184 The server has in general, no way of knowing that the request was 185 delayed and will therefore happily process the request. 187 If some wireless low-level protocol is used, the attack can also be 188 performed by the attacker simultaneously recording what the client 189 transmits while at the same time jamming the server. The request 190 delay attack is illustrated in Figure 3. 192 Client Foe Server 193 | | | 194 +----->@ | Code: 0.03 (PUT) 195 | PUT | | Token: 0x9c 196 | | | Uri-Path: lock 197 | | | Payload: 0 (Unlock) 198 | | | 199 .... .... 200 | | | 201 | @----->| Code: 0.03 (PUT) 202 | | PUT | Token: 0x9c 203 | | | Uri-Path: lock 204 | | | Payload: 0 (Unlock) 205 | | | 206 | X<-----+ Code: 2.04 (Changed) 207 | | 2.04 | Token: 0x9c 208 | | | 210 Figure 3: Delaying a Request 212 Where '@' means the attacker is storing and later forwarding the 213 message (@ may alternatively be seen as a wormhole connecting two 214 points in time). 216 While an attacker delaying a request to a sensor is often not a 217 security problem, an attacker delaying a request to an actuator 218 performing an action is often a serious problem. A request to an 219 actuator (for example a request to unlock a lock) is often only meant 220 to be valid for a short time frame, and if the request does not reach 221 the actuator during this short timeframe, the request should not be 222 fulfilled. In the unlock example, if the client does not get any 223 response and does not physically see the lock opening, the user is 224 likely to walk away, calling the locksmith (or the IT-support). 226 If a non-zero replay window is used (the default when CoAP is used 227 over UDP), the attacker can let the client interact with the actuator 228 before delivering the delayed request to the server (illustrated in 229 Figure 4). In the lock example, the attacker may store the first 230 "unlock" request for later use. The client will likely resend the 231 request with the same token. If DTLS is used, the resent packet will 232 have a different sequence number and the attacker can forward it. If 233 OSCOAP is used, resent packets will have the same sequence number and 234 the attacker must block them all until the client sends a new message 235 with a new sequence number (not shown in Figure 4). After a while 236 when the client has locked the door again, the attacker can deliver 237 the delayed "unlock" message to the door, a very serious attack. 239 Client Foe Server 240 | | | 241 +----->@ | Code: 0.03 (PUT) 242 | PUT | | Token: 0x9c 243 | | | Uri-Path: lock 244 | | | Payload: 0 (Unlock) 245 | | | 246 +------------>| Code: 0.03 (PUT) 247 | PUT | | Token: 0x9c 248 | | | Uri-Path: lock 249 | | | Payload: 0 (Unlock) 250 | | | 251 <-------------+ Code: 2.04 (Changed) 252 | | 2.04 | Token: 0x9c 253 | | | 254 .... .... 255 | | | 256 +------------>| Code: 0.03 (PUT) 257 | PUT | | Token: 0x7a 258 | | | Uri-Path: lock 259 | | | Payload: 1 (Lock) 260 | | | 261 <-------------+ Code: 2.04 (Changed) 262 | | 2.04 | Token: 0x7a 263 | | | 264 | @----->| Code: 0.03 (PUT) 265 | | PUT | Token: 0x9c 266 | | | Uri-Path: lock 267 | | | Payload: 0 (Unlock) 268 | | | 269 | X<-----+ Code: 2.04 (Changed) 270 | | 2.04 | Token: 0x9c 271 | | | 273 Figure 4: Delaying Request with Reordering 275 While the second attack (Figure 4) can be mitigated by using a replay 276 window of length zero, the first attack (Figure 3) cannot. A 277 solution must enable the server to verify that the request was 278 received within a certain time frame after it was sent. This can be 279 accomplished with either a challenge-response pattern, by exchanging 280 timestamps, or by only allowing requests a short period after client 281 authentication. Requiring a fresh client authentication (such as a 282 new TLS/DTLS handshake or an EDHOC key exchange 284 [I-D.selander-ace-cose-ecdhe]) mitigates the problem, but requires 285 larger messages and more processing than a dedicated solution. 286 Security solutions based on timestamps require exactly synchronized 287 time, and this is hard to control with complications such as time 288 zones and daylight saving. Even if the clocks are synchronized at 289 one point in time, they may easily get out-of-sync and an attacker 290 may even be able to affect the client or the server time in various 291 ways such as setting up a fake NTP server, broadcasting false time 292 signals to radio controlled clocks, or expose one of them to a strong 293 gravity field. As soon as client falsely believes it is time 294 synchronized with the server, delay attacks are possible. A 295 challenge response mechanism is much more failure proof and easy to 296 analyze. The challenge and response may be sent in a CoAP option or 297 in the CoAP payload. One such mechanism, the CoAP Replay Option, is 298 specified in Section 3. 300 Remedy: The CoAP Replay Option specified in Section 3 SHALL be used 301 for controlling actuators unless another application specific 302 challenge-response or timestamp mechanism is used. 304 2.3. The Response Delay and Mismatch Attack 306 The following attack can be performed if CoAP is protected by a 307 security protocol where the response is not bound to the request in 308 any way except by the CoAP token. This would include most general 309 security protocols, such as DTLS and IPsec, but not OSCOAP. The 310 attacker performs the attack by delaying delivery of a response until 311 the client sends a request with the same token. As long as the 312 response is inside the replay window (which the attacker can make 313 sure by blocking later responses), the response will be accepted by 314 the client as a valid response to the later request. CoAP [RFC7252] 315 uses a client generated token that the server echoes to match 316 responses to request, but does not give any guidelines for the use of 317 token with DTLS, except that the tokens currently "in use" SHOULD 318 (not SHALL) be unique. 320 The attack can be performed by an attacker on the wire, or an 321 attacker simultaneously recording what the server transmits while at 322 the same time jamming the client. The response delay and mismatch 323 attack is illustrated in Figure 5. 325 Client Foe Server 326 | | | 327 +------------>| Code: 0.03 (PUT) 328 | PUT | | Token: 0x77 329 | | | Uri-Path: lock 330 | | | Payload: 0 (Unlock) 331 | | | 332 | @<-----+ Code: 2.04 (Changed) 333 | | 2.04 | Token: 0x77 334 | | | 335 .... .... 336 | | | 337 +----->X | Code: 0.03 (PUT) 338 | PUT | | Token: 0x77 339 | | | Uri-Path: lock 340 | | | Payload: 0 (Lock) 341 | | | 342 <------@ | Code: 2.04 (Changed) 343 | 2.04 | | Token: 0x77 344 | | | 346 Figure 5: Delaying and Mismatching Response to PUT 348 If we once again take a lock as an example, the security consequences 349 may be severe as the client receives a response message likely to be 350 interpreted as confirmation of a locked door, while the received 351 response message is in fact confirming an earlier unlock of the door. 352 As the client is likely to leave the (believed to be locked) door 353 unattended, the attacker may enter the home, enterprise, or car 354 protected by the lock. 356 The same attack may be performed on sensors, also this with serious 357 consequences. As illustrated in Figure 6, an attacker may convince 358 the client that the lock is locked, when it in fact is not. The 359 "Unlock" request may be also be sent by another client authorized to 360 control the lock. 362 Client Foe Server 363 | | | 364 +------------>| Code: 0.01 (GET) 365 | GET | | Token: 0x77 366 | | | Uri-Path: lock 367 | | | 368 | @<-----+ Code: 2.05 (Content) 369 | | 2.05 | Token: 0x77 370 | | | Payload: 1 (Locked) 371 | | | 372 +------------>| Code: 0.03 (PUT) 373 | PUT | | Token: 0x34 374 | | | Uri-Path: lock 375 | | | Payload: 1 (Unlock) 376 | | | 377 | X<-----+ Code: 2.04 (Changed) 378 | | 2.04 | Token: 0x34 379 | | | 380 +----->X | Code: 0.01 (GET) 381 | GET | | Token: 0x77 382 | | | Uri-Path: lock 383 | | | 384 <------@ | Code: 2.05 (Content) 385 | 2.05 | | Token: 0x77 386 | | | Payload: 1 (Locked) 387 | | | 389 Figure 6: Delaying and Mismatching Response to GET 391 As illustrated in Figure 7, an attacker may even mix responses from 392 different resources as long as the two resources share the same DTLS 393 connection on some part of the path towards the client. This can 394 happen if the resources are located behind a common gateway, or are 395 served by the same CoAP proxy. An on-path attacker (not necessarily 396 a DTLS endpoint such as a proxy) may e.g. deceive a client that the 397 living room is on fire by responding with an earlier delayed response 398 from the oven (temperatures in degree Celsius). 400 Client Foe Server 401 | | | 402 +------------>| Code: 0.01 (GET) 403 | GET | | Token: 0x77 404 | | | Uri-Path: oven/temperature 405 | | | 406 | @<-----+ Code: 2.05 (Content) 407 | | 2.05 | Token: 0x77 408 | | | Payload: 225 409 | | | 410 .... .... 411 | | | 412 +----->X | Code: 0.01 (GET) 413 | GET | | Token: 0x77 414 | | | Uri-Path: livingroom/temperature 415 | | | 416 <------@ | Code: 2.05 (Content) 417 | 2.05 | | Token: 0x77 418 | | | Payload: 225 419 | | | 421 Figure 7: Delaying and Mismatching Response from other resource 423 Remedy: If CoAP is protected with a security protocol not providing 424 bindings between requests and responses (e.g. DTLS) the client MUST 425 NOT reuse any tokens for a given source/destination which the client 426 has not received responses to. The easiest way to accomplish this is 427 to implement the token as a counter and never reuse any tokens at 428 all, this approach SHOULD be followed. 430 2.4. The Relay Attack 432 Yet another type of attack can be performed in deployments where 433 actuator actions are triggered automatically based on proximity and 434 without any user interaction, e.g. a car (the client) constantly 435 polling for the car key (the server) and unlocking both doors and 436 engine as soon as the car key responds. An attacker (or pair of 437 attackers) may simply relay the CoAP messages out-of-band, using for 438 examples some other radio technology. By doing this, the actuator 439 (i.e. the car) believes that the client is close by and performs 440 actions based on that false assumption. The attack is illustrated in 441 Figure 8. In this example the car is using an application specific 442 challenge-response mechanism transferred as CoAP payloads. 444 Client Foe Foe Server 445 | | | | 446 +----->| ......... +----->| Code: 0.02 (POST) 447 | POST | | POST | Token: 0x3a 448 | | | | Uri-Path: lock 449 | | | | Payload: JwePR2iCe8b0ux (Challenge) 450 | | | | 451 |<-----+ ......... |<-----+ Code: 2.04 (Changed) 452 | 2.04 | | 2.04 | Token: 0x3a 453 | | | | Payload: RM8i13G8D5vfXK (Response) 454 | | | | 456 Figure 8: Relay Attack (the client is the actuator) 458 The consequences may be severe, and in the case of a car, lead to the 459 attacker unlocking and driving away with the car, an attack that 460 unfortunately is happening in practice. 462 Remedy: Getting a response over a short-range radio MUST NOT be taken 463 as proof of proximity and therefore MUST NOT be used to take actions 464 based on such proximity. Any automatically triggered mechanisms 465 relying on proximity MUST use other stronger mechanisms to guarantee 466 proximity. Mechanisms that MAY be used are: measuring the round-trip 467 time and calculate the maximum possible distance based on the speed 468 of light, or using radio with an extremely short range like NFC 469 (centimeters instead of meters). Another option is to including 470 geographical coordinates (from e.g. GPS) in the messages and 471 calculate proximity based on these, but in this case the location 472 measurements MUST be very precise and the system MUST make sure that 473 an attacker cannot influence the location estimation, something that 474 is very hard in practice. 476 3. The Repeat Option 478 The Repeat Option is a challenge-response mechanism for CoAP, binding 479 a resent request to an earlier 4.03 forbidden response. The 480 challenge (for the client) is simply to echo the Repeat Option value 481 in a new request. The Repeat Option enables the server to verify the 482 freshness of a request, thus mitigating the Delay Attack described in 483 Section 2.2. An example message flow is illustrated in Figure 9. 485 Client Server 486 | | 487 +----->| Code: 0.03 (PUT) 488 | PUT | Token: 0x41 489 | | Uri-Path: lock 490 | | Payload: 0 (Unlock) 491 | | 492 |<-----+ t0 Code: 4.03 (Forbidden) 493 | 4.03 | Token: 0x41 494 | | Repeat: 0x6c880d41167ba807 495 | | 496 +----->| t1 Code: 0.03 (PUT) 497 | PUT | Token: 0x42 498 | | Uri-Path: lock 499 | | Repeat: 0x6c880d41167ba807 500 | | Payload: 0 (Unlock) 501 | | 502 |<-----+ Code: 2.04 (Changed) 503 | 2.04 | Token: 0x42 504 | | 506 Figure 9: The Repeat Option 508 The Repeat Option may be used for all Methods and Response Codes. In 509 responses, the value MUST be a (pseudo-)random bit string with a 510 length of at least 64 bits. A new (pseudo-)random bit string MUST be 511 generated for each response. In requests, the Repeat Option MUST 512 echo the value from a previously received response. 514 The Repeat Option is critical, Safe-to-Forward, not part of the 515 Cache-Key, and not repeatable. 517 Upon receiving a request without the Repeat Option to a resource with 518 freshness requirements, the server sends a 4.03 Forbidden response 519 with a Repeat Option and stores the option value and the response 520 transmit time t0. 522 Upon receiving a 4.03 Forbidden response with the Repeat Option, the 523 client SHOULD resend the request, echoing the Repeat Option value. 525 Upon receiving a request with the Repeat Option, the server verifies 526 that the option value equals the previously sent value; otherwise the 527 request is not processed further. The server calculates the round- 528 trip time RTT = (t1 - t0), where t1 is the request receive time. The 529 server MUST only accept requests with a round-trip time below a 530 certain threshold T, i.e. RTT < T, otherwise the request is not 531 processed further, and an error message MAY be send. The threshold T 532 is application specific. 534 EDITORS NOTE: The mechanism described above is secure and gives the 535 server freshness guarantee independently of what the client does. 536 The disadvantages are that the mechanism always takes two round-trips 537 and that the server has to save the option value and the time t0. 538 Two different solutions involving time overcomes these disadvantages: 540 o The server may simply send the client the current time in its 541 timescale, i.e. a timestamp (option value = t0). The client may 542 then use this timestamp to estimate the current time in the 543 servers timescale when sending future requests (i.e. not echoing). 544 This approach has the benefit of reducing round-trips and server 545 state, but has the security problems discussed in Section 2.2. 547 o The server may instead of a pseudorandom value send an encrypted 548 timestamp (option value = E(k, t0)). CTR-mode would from a 549 security point be like sending (value = t0). ECB-mode or CCM-mode 550 would work, but would expand the value length. With CCM, the 551 server might also bind the option value to request (value = 552 AEAD(k, t0, parts of request)). This approach does not reduce the 553 number of round-trips but eliminates server state. 555 TODO: Update the Repeat Option to use a combination of these two 556 solutions instead. 558 4. IANA Considerations 560 This document defines the following Option Number, whose value have 561 been assigned to the CoAP Option Numbers Registry defined by 562 [RFC7252]. 564 +--------+------------------+ 565 | Number | Name | 566 +--------+------------------+ 567 | 29 | Repeat | 568 +--------+------------------+ 570 5. Security Considerations 572 The whole document can be seen as security considerations for CoAP. 574 6. Acknowledgements 576 The authors would like to thank Carsten Bormann, Klaus Hartke, Ari 577 Keranen, Matthias Kovatsch, Sandeep Kumar, and Andras Mehes for their 578 valuable comments and feedback. 580 7. References 582 7.1. Normative References 584 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 585 Application Protocol (CoAP)", RFC 7252, 586 DOI 10.17487/RFC7252, June 2014, 587 . 589 7.2. Informative References 591 [I-D.ietf-core-coap-tcp-tls] 592 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 593 Silverajan, B., and B. Raymor, "CoAP (Constrained 594 Application Protocol) over TCP, TLS, and WebSockets", 595 draft-ietf-core-coap-tcp-tls-05 (work in progress), 596 October 2016. 598 [I-D.ietf-cose-msg] 599 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 600 draft-ietf-cose-msg-24 (work in progress), November 2016. 602 [I-D.selander-ace-cose-ecdhe] 603 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 604 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 605 cose-ecdhe-04 (work in progress), October 2016. 607 [I-D.selander-ace-object-security] 608 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 609 "Object Security of CoAP (OSCOAP)", draft-selander-ace- 610 object-security-06 (work in progress), October 2016. 612 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 613 (TLS) Protocol Version 1.2", RFC 5246, 614 DOI 10.17487/RFC5246, August 2008, 615 . 617 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 618 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 619 January 2012, . 621 Authors' Addresses 622 John Mattsson 623 Ericsson AB 624 SE-164 80 Stockholm 625 Sweden 627 Email: john.mattsson@ericsson.com 629 John Fornehed 630 Ericsson AB 631 SE-164 80 Stockholm 632 Sweden 634 Email: john.fornehed@ericsson.com 636 Goran Selander 637 Ericsson AB 638 SE-164 80 Stockholm 639 Sweden 641 Email: goran.selander@ericsson.com 643 Francesca Palombini 644 Ericsson AB 645 SE-164 80 Stockholm 646 Sweden 648 Email: francesca.palombini@ericsson.com