CORE Working Group Y. Liu Internet-Draft J. Zhu Intended status: Standards Track Huawei Expires: January 4, 2018 July 3, 2017 Mitigating delay attacks on Constrained Application Protocol draft-liu-core-coap-delay-attacks-00 Abstract Various attacks including delay attacks have become a topic in the security of Internet of Things (IoT) especially for the constrained nodes utilizing sensors and actuators which connect and interact with the physical world. [I-D.mattsson-core-coap-actuators] describes several serious delay attacks, discusses tougher requirements and then recommends mechanisms to mitigate the attacks. It also specifies some disadvantages with the mechanisms. This document proposes alternative mechanisms that address some of the disadvantages Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Liu & Zhu Expires January 4, 2018 [Page 1] Internet-Draft CORE CoAP Delay attack July 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. The Repeat Option . . . . . . . . . . . . . . . . . . . . 3 4.2. The Enhanced Options . . . . . . . . . . . . . . . . . . 5 4.2.1. Simple Single Action Actuators . . . . . . . . . . . 6 4.2.2. Multi-interrelated Actions . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Various attacks including delay attacks have become a topic in the security of Internet of Things (IoT) especially for the resource- constrained nodes [RFC7252] utilizing sensors and actuators which connect and interact with the physical world. It is recommended to use the Constrained Application Protocol (CoAP) [RFC7252], which is designed for resource-constrained nodes, and exchange messages between them. Also, it is required to use security protocols such as TLS [RFC5246], DTLS [RFC6347], TLS/DTLS profiles for the IoT [RFC7925], or OSCOAP [I-D.ietf-core-object-security] to protect CoAP messages due to security and privacy. The security protocols can provide confidentiality, authentication and integrity protection of CoAP messages at both the application layer and the network layer. There are still issues related to delay attacks as descirbed in [I-D.mattsson-core-coap-actuators]. For example, [I-D.mattsson-core-coap-actuators] describes several serious attacks, discusses tougher requirements and then recommends solution to mitigate the attacks. The draft also indicates the disadvantage that CoAP messages need two round trips for the solution. This document will show alternative mechanisms which take CoAP messages only one round trip by utilizing the sending messages containing valid time window(s), Sequence Number and response policies. Liu & Zhu Expires January 4, 2018 [Page 2] Internet-Draft CORE CoAP Delay attack July 2017 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119]. This specification requires readers to be familiar with all the terms and concepts that are discussed in [I-D.mattsson-core-coap-actuators] and [RFC7252]. 3. Attacks It is assumed that the reader is familiar with the following attacks as described by section 2 of [I-D.mattsson-core-coap-actuators]: o The Block Attack o The Request Delay Attack o The Response Delay and Mismatch Attack o Relay Attack 4. Solutions In order to mitigate the attacks as above, [I-D.mattsson-core-coap-actuators] provides a challenge-response mechanism for CoAP using a new CoAP Option "Repeat". This option is described below in section 4.1. It is a copy of section 3 of the [I-D.mattsson-core-coap-actuators]. An editor's note at the end of that section indicates the disadvantage that the mechanism takes two round trips and provides two potential enhancements utilizing time. Section 4.2 in the document describes another method which takes only one round trip CoAP messages which utilizes a "valid time window" , "Sequence Number" and "response policies" on receiving messages to mitigate the delay attacks. 4.1. The Repeat Option The Repeat Option is a challenge-response mechanism for CoAP, binding a resent request to an earlier 4.03 forbidden response. The challenge (for the client) is simply to echo the Repeat Option value in a new request. The Repeat Option enables the server to verify the freshness of a request, thus mitigating the Delay Attack. An example message flow is illustrated in Figure: Liu & Zhu Expires January 4, 2018 [Page 3] Internet-Draft CORE CoAP Delay attack July 2017 Client Server | | +----->| Code: 0.03 (PUT) | PUT | Token: 0x41 | | Uri-Path: lock | | Payload: 0 (Unlock) | | |<-----+ t0 Code: 4.03 (Forbidden) | 4.03 | Token: 0x41 | | Repeat: 0x6c880d41167ba807 | | +----->| t1 Code: 0.03 (PUT) | PUT | Token: 0x42 | | Uri-Path: lock | | Repeat: 0x6c880d41167ba807 | | Payload: 0 (Unlock) | | |<-----+ Code: 2.04 (Changed) | 2.04 | Token: 0x42 | | Figure 1: The Repeat Option The Repeat Option may be used for all Methods and Response Codes. In responses, the value MUST be a (pseudo-) random bit string with a length of at least 64 bits. A new (pseudo-) random bit string MUST be generated for each response. In requests, the Repeat Option MUST echo the value from a previously received response. The Repeat Option is critical, Safe-to-Forward, not part of the Cache-Key, and not repeatable. Upon receiving a request without the Repeat Option to a resource with freshness requirements, the server sends a 4.03 Forbidden response with a Repeat Option and stores the option value and the response transmit time t0. Upon receiving a 4.03 Forbidden response with the Repeat Option, the client SHOULD resend the request, echoing the Repeat Option value. Upon receiving a request with the Repeat Option, the server verifies that the option value equals the previously sent value; otherwise the request is not processed further. The server calculates the round- trip time RTT = (t1 - t0), where t1 is the request receive time. The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be send. The threshold T is application specific. Liu & Zhu Expires January 4, 2018 [Page 4] Internet-Draft CORE CoAP Delay attack July 2017 4.2. The Enhanced Options According to the method using a Repeat Option (see Section 4.1), there are still the following potential situations: o If the RTT of the second message or the third message (see Figure 1) is larger than the certain threshold T, the server can determine that the request message from the client is delayed and then discard it. o If the RTT of the second message or the third message (see Figure 1) is large but does not exceed the certain threshold T, the server treats these messages as valid and then processes them normally. But these messages may have become invalid especially in the situation where the request(s) containing actions relevant for actuators are required to be processed in a specific and limited period of time. For example, the actuator with the air conditioning may be required to keep it open in a specific time and temperature, which depends on some reasons such as people's preferences and current weather. In other words, the specific time may be varied, it is possible that the server determines the request is valid by RTT < T but the potential specific time associated with the request is actually past. o If the RTT of the fourth message (see Figure 9) is larger than the certain threshold T, it may cause that the client resends the request message but the actuator's actions associated with the previous message has already been processed. o Regardless of whether the delay exists, the two round-trips increase the delay in overall processing of the original action (e.g. PUT) In fact, the server cannot accurately know whether the messages are delayed in a reasonable period of time or not, because the reasons for the delay may be caused by the network itself and/or some attacks such as man-in-the-middle. In other words, how to set T value depends on many factors. Also, it is not enough to determine whether the delay happens. Due to IoT covering different vertical domains actuators have different delay sensitivity requirements. Simple actuators (such as a smart switch) support a single action and may not be delay sensitive. There are others with complicated capabilities that are able to process multi-interrelated actions especially in Industrial Control and Production Systems. These actuators with multi- interrelated actions are usually associated with strict time requirements. Therefore, it is lack of a mechanism that assures them Liu & Zhu Expires January 4, 2018 [Page 5] Internet-Draft CORE CoAP Delay attack July 2017 process multi-continuous actions addressed in different request(s) when the delay attack happens and even causes some mismatch/disorder. 4.2.1. Simple Single Action Actuators For simple single action for the actuators, the Time Window Option is introduced as a new CoAP option and is to address the validity period of the request(s) from the client. The Time Window Option including T-start (i.e., a start valid time) and T-duration (i.e., a valid duration) of a request enables the server to accurately know the freshness of a request, determine how to process it, and thus achieve to mitigate the attacks described in Section 3. Client Server | | +----->| Code: 0.03 (PUT) | PUT | Token: 0x41 | | Uri-Path: lock | | Payload: 0 (Unlock) | | Valid-Window: T-start, T-duration | | |<-----+T-receive| Code: 0.03 (PUT) | PUT | Token: 0x41 | | Uri-Path: lock | | Payload: 0 (Unlock) | | Valid-Window: T-start, T-duration | | |<-----+T-receive in [T-start, T-start + T-duration] Code: 2.05 (Content) | 2.05 | Token: 0x41 | | Receipt: OK | | Figure 3: The Time Window Option(2) If T-receive (i.e., a reception time for the server receiving a request) >= T-start and T-receive < (T-start + T-duration) as illustrated in Figure 3, it means that the request is just in the valid period of time. The server should process this request immediately, stores a Receipt Option indicating "OK" in a normal response for the client and returns this response with Code = 2.05. Client Server | | +----->| Code: 0.03 (PUT) | PUT | Token: 0x41 | | Uri-Path: lock | | Payload: 0 (Unlock) | | Valid-Window: T-start, T-duration | | |<-----+T-receive > (T-start + T-duration) Code: 4.03 (Forbidden) | 4.03 | Token: 0x41 | | Receipt: Delay, Offset (T-receive - T-start) | | Figure 4: The Time Window Option(3) If T-receive (i.e., a reception time for the server receiving a request) > (T-start + T-duration) as illustrated in Figure 12, it means that the request has become invalid. The server discards the request and sends a 4.03 error response to the client with a "Delay" Receipt Option indicating a time offset between T- receive and T-current. The offset helps the client to estimate the RTT between the client and the server, and thus set a more reasonable T-duration for the subsequent messages. Liu & Zhu Expires January 4, 2018 [Page 7] Internet-Draft CORE CoAP Delay attack July 2017 4.2.2. Multi-interrelated Actions When some complicated actuators are able to support multi- interrelated actions with different request(s), it is desirable to be required give some indications to the server to make actions especially when there are delay caused by some attacks. This document proposes the use of a Sequence Number CoAP option to address the sending sequence of request(s) in the client side. This document also proposes a new Response Polices CoAP option which is valid with the Sequence Number Option. It is used to provide some corresponding rules when the server recognizes that request(s) are disorder via the Sequence Number Options in these messages. The Response Policies are preemptive mode, sequential mode, and sequential with conditional discard mode. Also, the Response Policies may be pre-configured in the server side or may be specified in the request(s) in the client side. If the server cannot get the Response Policies, the server will default as preemptive mode. Upon receiving a request containing the Sequence Number Option, the server will do the following steps. (1) The server is aware that the largest Sequence Number (SNmax) of all previous request(s) is less than that of the current request (SNcr). If SNmax is adjacent to SNcr and the previous request with the SNmax has already been normally responded, the current request should be responded based on Section 4.2.1. If the previous request with SNmax is still to be lined, the server should respond the current request with SNcr according to the response policies and the validity period of the requests as below: o preemptive mode: if T-start of the current request is coming, the server does it immediately, and then discard the previous request(s) who are in waiting queue and their Sequence Number(s) are less than SNcr. If the later request(s)'s Sequence Number(s) are less than SNcr, the server should discard them and then respond an error indicating delay. o sequential mode: the server should respond to the request(s) orderly based on their Sequence Number(s). Although T-start of the current request is coming, the server does not respond it until the previous and later request(s) with Sequence Number(s) less than SNcr has already been responded. Consequently, it is possible that the current request may not be responded due to expiration. o sequential with conditional discard mode: the server should respond to the request(s) strictly based on their Sequence Number Liu & Zhu Expires January 4, 2018 [Page 8] Internet-Draft CORE CoAP Delay attack July 2017 (s) till (T-start + T-duration) of the current request is coming. At this time, the server must respond the current request and then discard the previous and later request(s) with Sequence Number(s) less than SNcr. (2) The server is aware that the largest Sequence Number(SNmax) of all previous request(s) is more than that of the current request (SNcr). o preemptive mode: if the request with SNmax has already been done, the server should discard the current request and then answer an error indicating delay. If the request with SNmax is still in waiting queue, the server should add the current request to the waiting queue and responds these previous requests based on Section 4.2.1 till the T-start of the request with SNmax is coming. o sequential mode: the server should add the current request to the waiting queue till the its' T-start is coming. o sequential with conditional discard mode: the server should add the current request to the waiting queue till the its' T-start is coming. If the (T-start + T-duration) of the request with SNmax is coming earlier than the T-start of the current request, the server should do the request with SNmax and discard the current request. When some complicated actuators are able to support multi- interrelated actions with different request(s), it is desirable to be required give some indications to the server to make actions especially when there are delay caused by some attacks Note: It is to be added figures to illustrate the above examples in the future. 5. Security Considerations The whole document can be seen as security considerations for CoAP. 6. IANA Considerations This document requests the registration of the following Option Number, whose value have been assigned to the CoAP Option Numbers Registry defined by [RFC7252]. Liu & Zhu Expires January 4, 2018 [Page 9] Internet-Draft CORE CoAP Delay attack July 2017 +--------+-------------------+ | Number | Name | +--------+-------------------+ | 30 | Time Window | | | | | 31 | Sequence Number | | | | | 32 | Response Policies | +--------+-------------------+ 7. Acknowledgements TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7925] Tschofenig, H. and T. Fossati, "Transport Layer Security(TLS)/ Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC6347, December 2016, . Liu & Zhu Expires January 4, 2018 [Page 10] Internet-Draft CORE CoAP Delay attack July 2017 8.2. Informative References [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security of CoAP", draft-ietf-core-object- security-04 (work in progress), July 2017. [I-D.mattsson-core-coap-actuators] Mattsson, J., Fornehed, J., Selander, G., and F. Palombini, "Controlling Actuators with CoAP", draft- mattsson-core-copa-actuators-02 (work in progress), November 2016. Authors' Addresses Yan Liu Huawei P.R.China Email: scarlett.liuyan@huawei.com Jintao Zhu Huawei P.R.China Email: jintao.zhu@huawei.com Liu & Zhu Expires January 4, 2018 [Page 11]