idnits 2.17.1 draft-liu-core-coap-delay-attacks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** The abstract seems to contain references ([I-D.mattsson-core-coap-actuators]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 3, 2017) is 2488 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-04 -- No information found for draft-mattsson-core-copa-actuators - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE Working Group Y. Liu 3 Internet-Draft J. Zhu 4 Intended status: Standards Track Huawei 5 Expires: January 4, 2018 July 3, 2017 7 Mitigating delay attacks on Constrained Application Protocol 8 draft-liu-core-coap-delay-attacks-00 10 Abstract 12 Various attacks including delay attacks have become a topic in the 13 security of Internet of Things (IoT) especially for the constrained 14 nodes utilizing sensors and actuators which connect and interact with 15 the physical world. [I-D.mattsson-core-coap-actuators] describes 16 several serious delay attacks, discusses tougher requirements and 17 then recommends mechanisms to mitigate the attacks. It also 18 specifies some disadvantages with the mechanisms. This document 19 proposes alternative mechanisms that address some of the 20 disadvantages 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 4, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4.1. The Repeat Option . . . . . . . . . . . . . . . . . . . . 3 61 4.2. The Enhanced Options . . . . . . . . . . . . . . . . . . 5 62 4.2.1. Simple Single Action Actuators . . . . . . . . . . . 6 63 4.2.2. Multi-interrelated Actions . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Various attacks including delay attacks have become a topic in the 76 security of Internet of Things (IoT) especially for the resource- 77 constrained nodes [RFC7252] utilizing sensors and actuators which 78 connect and interact with the physical world. It is recommended to 79 use the Constrained Application Protocol (CoAP) [RFC7252], which is 80 designed for resource-constrained nodes, and exchange messages 81 between them. Also, it is required to use security protocols such as 82 TLS [RFC5246], DTLS [RFC6347], TLS/DTLS profiles for the IoT 83 [RFC7925], or OSCOAP [I-D.ietf-core-object-security] to protect CoAP 84 messages due to security and privacy. The security protocols can 85 provide confidentiality, authentication and integrity protection of 86 CoAP messages at both the application layer and the network layer. 88 There are still issues related to delay attacks as descirbed in 89 [I-D.mattsson-core-coap-actuators]. For example, 90 [I-D.mattsson-core-coap-actuators] describes several serious attacks, 91 discusses tougher requirements and then recommends solution to 92 mitigate the attacks. The draft also indicates the disadvantage that 93 CoAP messages need two round trips for the solution. This document 94 will show alternative mechanisms which take CoAP messages only one 95 round trip by utilizing the sending messages containing valid time 96 window(s), Sequence Number and response policies. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this specification are to be interpreted as described 103 in [RFC2119]. 105 This specification requires readers to be familiar with all the terms 106 and concepts that are discussed in [I-D.mattsson-core-coap-actuators] 107 and [RFC7252]. 109 3. Attacks 111 It is assumed that the reader is familiar with the following attacks 112 as described by section 2 of [I-D.mattsson-core-coap-actuators]: 114 o The Block Attack 116 o The Request Delay Attack 118 o The Response Delay and Mismatch Attack 120 o Relay Attack 122 4. Solutions 124 In order to mitigate the attacks as above, 125 [I-D.mattsson-core-coap-actuators] provides a challenge-response 126 mechanism for CoAP using a new CoAP Option "Repeat". This option is 127 described below in section 4.1. It is a copy of section 3 of the 128 [I-D.mattsson-core-coap-actuators]. An editor's note at the end of 129 that section indicates the disadvantage that the mechanism takes two 130 round trips and provides two potential enhancements utilizing time. 132 Section 4.2 in the document describes another method which takes only 133 one round trip CoAP messages which utilizes a "valid time window" , 134 "Sequence Number" and "response policies" on receiving messages to 135 mitigate the delay attacks. 137 4.1. The Repeat Option 139 The Repeat Option is a challenge-response mechanism for CoAP, binding 140 a resent request to an earlier 4.03 forbidden response. The 141 challenge (for the client) is simply to echo the Repeat Option value 142 in a new request. The Repeat Option enables the server to verify the 143 freshness of a request, thus mitigating the Delay Attack. An example 144 message flow is illustrated in Figure: 146 Client Server 147 | | 148 +----->| Code: 0.03 (PUT) 149 | PUT | Token: 0x41 150 | | Uri-Path: lock 151 | | Payload: 0 (Unlock) 152 | | 153 |<-----+ t0 Code: 4.03 (Forbidden) 154 | 4.03 | Token: 0x41 155 | | Repeat: 0x6c880d41167ba807 156 | | 157 +----->| t1 Code: 0.03 (PUT) 158 | PUT | Token: 0x42 159 | | Uri-Path: lock 160 | | Repeat: 0x6c880d41167ba807 161 | | Payload: 0 (Unlock) 162 | | 163 |<-----+ Code: 2.04 (Changed) 164 | 2.04 | Token: 0x42 165 | | 167 Figure 1: The Repeat Option 169 The Repeat Option may be used for all Methods and Response Codes. In 170 responses, the value MUST be a (pseudo-) random bit string with a 171 length of at least 64 bits. A new (pseudo-) random bit string MUST 172 be generated for each response. In requests, the Repeat Option MUST 173 echo the value from a previously received response. 175 The Repeat Option is critical, Safe-to-Forward, not part of the 176 Cache-Key, and not repeatable. 178 Upon receiving a request without the Repeat Option to a resource with 179 freshness requirements, the server sends a 4.03 Forbidden response 180 with a Repeat Option and stores the option value and the response 181 transmit time t0. 183 Upon receiving a 4.03 Forbidden response with the Repeat Option, the 184 client SHOULD resend the request, echoing the Repeat Option value. 186 Upon receiving a request with the Repeat Option, the server verifies 187 that the option value equals the previously sent value; otherwise the 188 request is not processed further. The server calculates the round- 189 trip time RTT = (t1 - t0), where t1 is the request receive time. The 190 server MUST only accept requests with a round-trip time below a 191 certain threshold T, i.e. RTT < T, otherwise the request is not 192 processed further, and an error message MAY be send. The threshold T 193 is application specific. 195 4.2. The Enhanced Options 197 According to the method using a Repeat Option (see Section 4.1), 198 there are still the following potential situations: 200 o If the RTT of the second message or the third message (see 201 Figure 1) is larger than the certain threshold T, the server can 202 determine that the request message from the client is delayed and 203 then discard it. 205 o If the RTT of the second message or the third message (see 206 Figure 1) is large but does not exceed the certain threshold T, 207 the server treats these messages as valid and then processes them 208 normally. But these messages may have become invalid especially 209 in the situation where the request(s) containing actions relevant 210 for actuators are required to be processed in a specific and 211 limited period of time. For example, the actuator with the air 212 conditioning may be required to keep it open in a specific time 213 and temperature, which depends on some reasons such as people's 214 preferences and current weather. In other words, the specific 215 time may be varied, it is possible that the server determines the 216 request is valid by RTT < T but the potential specific time 217 associated with the request is actually past. 219 o If the RTT of the fourth message (see Figure 9) is larger than the 220 certain threshold T, it may cause that the client resends the 221 request message but the actuator's actions associated with the 222 previous message has already been processed. 224 o Regardless of whether the delay exists, the two round-trips 225 increase the delay in overall processing of the original action 226 (e.g. PUT) 228 In fact, the server cannot accurately know whether the messages are 229 delayed in a reasonable period of time or not, because the reasons 230 for the delay may be caused by the network itself and/or some attacks 231 such as man-in-the-middle. In other words, how to set T value 232 depends on many factors. Also, it is not enough to determine whether 233 the delay happens. 235 Due to IoT covering different vertical domains actuators have 236 different delay sensitivity requirements. Simple actuators (such as 237 a smart switch) support a single action and may not be delay 238 sensitive. There are others with complicated capabilities that are 239 able to process multi-interrelated actions especially in Industrial 240 Control and Production Systems. These actuators with multi- 241 interrelated actions are usually associated with strict time 242 requirements. Therefore, it is lack of a mechanism that assures them 243 process multi-continuous actions addressed in different request(s) 244 when the delay attack happens and even causes some mismatch/disorder. 246 4.2.1. Simple Single Action Actuators 248 For simple single action for the actuators, the Time Window Option is 249 introduced as a new CoAP option and is to address the validity period 250 of the request(s) from the client. The Time Window Option including 251 T-start (i.e., a start valid time) and T-duration (i.e., a valid 252 duration) of a request enables the server to accurately know the 253 freshness of a request, determine how to process it, and thus achieve 254 to mitigate the attacks described in Section 3. 256 Client Server 257 | | 258 +----->| Code: 0.03 (PUT) 259 | PUT | Token: 0x41 260 | | Uri-Path: lock 261 | | Payload: 0 (Unlock) 262 | | Valid-Window: T-start, T-duration 263 | | 264 |<-----+T-receive| Code: 0.03 (PUT) 292 | PUT | Token: 0x41 293 | | Uri-Path: lock 294 | | Payload: 0 (Unlock) 295 | | Valid-Window: T-start, T-duration 296 | | 297 |<-----+T-receive in [T-start, T-start + T-duration] Code: 2.05 (Content) 298 | 2.05 | Token: 0x41 299 | | Receipt: OK 300 | | 302 Figure 3: The Time Window Option(2) 304 If T-receive (i.e., a reception time for the server receiving a 305 request) >= T-start and T-receive < (T-start + T-duration) as 306 illustrated in Figure 3, it means that the request is just in the 307 valid period of time. The server should process this request 308 immediately, stores a Receipt Option indicating "OK" in a normal 309 response for the client and returns this response with Code = 2.05. 311 Client Server 312 | | 313 +----->| Code: 0.03 (PUT) 314 | PUT | Token: 0x41 315 | | Uri-Path: lock 316 | | Payload: 0 (Unlock) 317 | | Valid-Window: T-start, T-duration 318 | | 319 |<-----+T-receive > (T-start + T-duration) Code: 4.03 (Forbidden) 320 | 4.03 | Token: 0x41 321 | | Receipt: Delay, Offset (T-receive - T-start) 322 | | 324 Figure 4: The Time Window Option(3) 326 If T-receive (i.e., a reception time for the server receiving a 327 request) > (T-start + T-duration) as illustrated in Figure 12, it 328 means that the request has become invalid. The server discards the 329 request and sends a 4.03 error response to the client with a "Delay" 330 Receipt Option indicating a time offset between T- receive and 331 T-current. The offset helps the client to estimate the RTT between 332 the client and the server, and thus set a more reasonable T-duration 333 for the subsequent messages. 335 4.2.2. Multi-interrelated Actions 337 When some complicated actuators are able to support multi- 338 interrelated actions with different request(s), it is desirable to be 339 required give some indications to the server to make actions 340 especially when there are delay caused by some attacks. 342 This document proposes the use of a Sequence Number CoAP option to 343 address the sending sequence of request(s) in the client side. This 344 document also proposes a new Response Polices CoAP option which is 345 valid with the Sequence Number Option. It is used to provide some 346 corresponding rules when the server recognizes that request(s) are 347 disorder via the Sequence Number Options in these messages. The 348 Response Policies are preemptive mode, sequential mode, and 349 sequential with conditional discard mode. Also, the Response 350 Policies may be pre-configured in the server side or may be specified 351 in the request(s) in the client side. If the server cannot get the 352 Response Policies, the server will default as preemptive mode. 354 Upon receiving a request containing the Sequence Number Option, the 355 server will do the following steps. 357 (1) The server is aware that the largest Sequence Number (SNmax) of 358 all previous request(s) is less than that of the current request 359 (SNcr). If SNmax is adjacent to SNcr and the previous request with 360 the SNmax has already been normally responded, the current request 361 should be responded based on Section 4.2.1. If the previous request 362 with SNmax is still to be lined, the server should respond the 363 current request with SNcr according to the response policies and the 364 validity period of the requests as below: 366 o preemptive mode: if T-start of the current request is coming, the 367 server does it immediately, and then discard the previous 368 request(s) who are in waiting queue and their Sequence Number(s) 369 are less than SNcr. If the later request(s)'s Sequence Number(s) 370 are less than SNcr, the server should discard them and then 371 respond an error indicating delay. 373 o sequential mode: the server should respond to the request(s) 374 orderly based on their Sequence Number(s). Although T-start of 375 the current request is coming, the server does not respond it 376 until the previous and later request(s) with Sequence Number(s) 377 less than SNcr has already been responded. Consequently, it is 378 possible that the current request may not be responded due to 379 expiration. 381 o sequential with conditional discard mode: the server should 382 respond to the request(s) strictly based on their Sequence Number 383 (s) till (T-start + T-duration) of the current request is coming. 384 At this time, the server must respond the current request and then 385 discard the previous and later request(s) with Sequence Number(s) 386 less than SNcr. 388 (2) The server is aware that the largest Sequence Number(SNmax) of 389 all previous request(s) is more than that of the current request 390 (SNcr). 392 o preemptive mode: if the request with SNmax has already been done, 393 the server should discard the current request and then answer an 394 error indicating delay. If the request with SNmax is still in 395 waiting queue, the server should add the current request to the 396 waiting queue and responds these previous requests based on 397 Section 4.2.1 till the T-start of the request with SNmax is 398 coming. 400 o sequential mode: the server should add the current request to the 401 waiting queue till the its' T-start is coming. 403 o sequential with conditional discard mode: the server should add 404 the current request to the waiting queue till the its' T-start is 405 coming. If the (T-start + T-duration) of the request with SNmax 406 is coming earlier than the T-start of the current request, the 407 server should do the request with SNmax and discard the current 408 request. 410 When some complicated actuators are able to support multi- 411 interrelated actions with different request(s), it is desirable to be 412 required give some indications to the server to make actions 413 especially when there are delay caused by some attacks 415 Note: It is to be added figures to illustrate the above examples in 416 the future. 418 5. Security Considerations 420 The whole document can be seen as security considerations for CoAP. 422 6. IANA Considerations 424 This document requests the registration of the following Option 425 Number, whose value have been assigned to the CoAP Option Numbers 426 Registry defined by [RFC7252]. 428 +--------+-------------------+ 429 | Number | Name | 430 +--------+-------------------+ 431 | 30 | Time Window | 432 | | | 433 | 31 | Sequence Number | 434 | | | 435 | 32 | Response Policies | 436 +--------+-------------------+ 438 7. Acknowledgements 440 TBD. 442 8. References 444 8.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 452 (TLS) Protocol Version 1.2", RFC 5246, 453 DOI 10.17487/RFC5246, August 2008, 454 . 456 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 457 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 458 January 2012, . 460 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 461 Application Protocol (CoAP)", RFC 7252, 462 DOI 10.17487/RFC7252, June 2014, 463 . 465 [RFC7925] Tschofenig, H. and T. Fossati, "Transport Layer 466 Security(TLS)/ Datagram Transport Layer Security (DTLS) 467 Profiles for the Internet of Things", RFC 7925, 468 DOI 10.17487/RFC6347, December 2016, 469 . 471 8.2. Informative References 473 [I-D.ietf-core-object-security] 474 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 475 "Object Security of CoAP", draft-ietf-core-object- 476 security-04 (work in progress), July 2017. 478 [I-D.mattsson-core-coap-actuators] 479 Mattsson, J., Fornehed, J., Selander, G., and F. 480 Palombini, "Controlling Actuators with CoAP", draft- 481 mattsson-core-copa-actuators-02 (work in progress), 482 November 2016. 484 Authors' Addresses 486 Yan Liu 487 Huawei 488 P.R.China 490 Email: scarlett.liuyan@huawei.com 492 Jintao Zhu 493 Huawei 494 P.R.China 496 Email: jintao.zhu@huawei.com