[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

CoRE Working Group                                                Y. Liu
Internet-Draft                                                    J. Zhu
Intended status: Standards Track                                  Huawei
Expires: May 3, 2018                                    October 30, 2017


      Mitigating delay attacks on Constrained Application Protocol
                  draft-liu-core-coap-delay-attacks-01

Abstract

   Various attacks including delay attack 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 to 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 https://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 May 3, 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
   (https://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
   to this document.  Code Components extracted from this document must



Liu & Zhu                  Expires May 3, 2018                  [Page 1]


Internet-Draft           CORE CoAP Delay attack             October 2017


   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  . . . . . . . . . . . . . . . . . .   4
       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 attack 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 message exchange between
   them.  Also, it is required to use security protocols such as TLS
   [RFC5246], DTLS [RFC6347], TLS/DTLS profiles for the IoT [RFC7925],
   or OSCORE [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 transport 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 Policy.




Liu & Zhu                  Expires May 3, 2018                  [Page 2]


Internet-Draft           CORE CoAP Delay attack             October 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 specified in 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, which is originally specified in
   section 3 of the [I-D.mattsson-core-coap-actuators].  An editor's
   note indicates the disadvantages that the mechanism takes two round
   trips and provides two potential enhancements utilizing time.

   Section 4.2 in this document describes another method which takes
   only one round trip CoAP messages which utilizes a "Valid Time
   Window" , "Sequence Number" and "Response Policy" on receiving
   messages to mitigate the delay attacks.

4.1.  The Repeat Option

   The Repeat Option is a challenge-response mechanism for CoAP, which
   is generated by the server and binded to an 4.03 forbidden response.
   The client bind the same Repeat Option value into a new request to
   echo the challenge.  Then the server verifies the freshness of the
   original request.  An example message flow is illustrated in Figure 1





Liu & Zhu                  Expires May 3, 2018                  [Page 3]


Internet-Draft           CORE CoAP Delay attack             October 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

   1) The client sends the original request without the Repeat Option to
   a resource on a server with freshness requirements.  E.g. the client
   wants to unlock the door.

   2) After receiving the original request, the server sends a 4.03
   Forbidden response with a Repeat Option to challenge the client.  The
   repeat Option value and the response transmit time 't0' are stored on
   the server.

   3) The client SHOULD resend the original request with the same Repeat
   Option value contained in the previous response to echo the
   challenge.  The server SHOULD store the request receive time 't1'.

   4) The server firstly verifies that the Repeat Option value equals
   the previously sent one.  Then the server calculates the round-trip
   time RTT = (t1 - t0).  The server MUST only accept requests with a
   round-trip time below a certain threshold T, i.e. RTT < T.  The
   threshold T is application specific.

4.2.  The Enhanced Options

   According to the method using a Repeat Option (see Section 4.1),
   there are still the following potential situations:





Liu & Zhu                  Expires May 3, 2018                  [Page 4]


Internet-Draft           CORE CoAP Delay attack             October 2017


   o  If the RTT of the second message to 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 to 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 user's
      preference and current room temperature.  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 third message to the fourth message (see
      Figure 1) 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
   process multi-continuous actions addressed in different request(s)
   when the delay attack happens and even causes some mismatch/disorder.





Liu & Zhu                  Expires May 3, 2018                  [Page 5]


Internet-Draft           CORE CoAP Delay attack             October 2017


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<T-start
             | 2.03 |            Code: 2.03 (Valid)
             |      |           Token: 0x41
             |      |         Payload: queueing
             |      |
             |<-----+ T-start
             | 2.05 |            Code: 2.05 (Content)
             |      |           Token: 0x41
             |      |         Payload: OK
             |      |

                    Figure 2: The Time Window Option(1)

   Upon receiving a request containing the Time Window Option, the
   server extracts the T-start and T-duration from the first request
   from the client.

   If T-receive (a reception time for the server receiving a request) <
   T-start as illustrated in Figure 2, it means that the server SHOULD
   not do the actions carried in the request until T-start is coming.
   The server SHOULD add this request to a waiting queue, and issues a
   temporarily response (e.g. 2.03) to the client with the payload
   indicating "queueing".  When T-start is coming, the server gets the
   corresponding request from the processing buffer, executes the
   actions carried in the request, and sends a response 2.05 containing
   a payload indicating "OK".







Liu & Zhu                  Expires May 3, 2018                  [Page 6]


Internet-Draft           CORE CoAP Delay attack             October 2017


          Client  Server
             |      |
             +----->|            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
             |      |         Payload: 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 payload 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)
           | 4.03 |            Code: 4.03 (Forbidden)
           |      |           Token: 0x41
           |      |         Payload: 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 4, 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"
   payload 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 May 3, 2018                  [Page 7]


Internet-Draft           CORE CoAP Delay attack             October 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) at the client side.  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.

   This document also proposes a new Response Policy CoAP Option which
   is valid with the Sequence Number Option.  The Response Policy
   includes 3 modes - preemptive mode, sequential mode, and sequential
   with conditional discard mode.  Also, the Response Policy may be pre-
   configured at the server side or may be specified in the requests at
   the client side.  If the server cannot get the Response Policy, the
   server will select preemptive mode by default.

   Upon receiving a request containing the Sequence Number Option, the
   server will do the following steps:

   1) The server is aware that the Sequence Number value in current
   request (SNcur) is larger than the largest Sequence Number (SNmax) of
   all previous requests.

   a.  If the previous request with SNmax has already been normally
   responded and SNcur = (SNmax + 1) , the current request SHOULD be
   responded as specified in Section 4.2.1.

   b.  If the previous request with SNmax is still being queued, the
   server SHOULD respond the current request with SNcur according to the
   Response Policy and the validity period of the requests as below:

   o  Preemptive mode: If T-start of the current request is expired, the
      server SHOULD process the current request immediately, and then
      discard all the previous requests in the queue since SNcur >
      SNmax.

   o  Sequential mode: The server SHOULD respond to the requests orderly
      based on their Sequence Numbers.  Although T-start of the current
      request is expired, the server SHOULD not respond to it until all
      the requests with Sequence Numbers less than SNcur have been
      responded, even if the request with a sequence number less than
      the SNcur has not been received by the server.  Consequently,
      there is a possibility that the current request MAY not be



Liu & Zhu                  Expires May 3, 2018                  [Page 8]


Internet-Draft           CORE CoAP Delay attack             October 2017


      responded due to its Valid Time Window (T-start + T-duration)
      expiration.

   o  Sequential with conditional discard mode: The server SHOULD
      respond to the requests based on their Sequence Numbers as well as
      the Valid Time Window (T-start + T-duration) of the requests.
      Once the Valid Time Window of the current request expires, the
      sever SHOULD respond to the current request immediately, then
      discard all the requests with Sequence Numbers less than SNcur.

   2) The server is aware that the Sequence Number value in current
   request (SNcur) is smaller than the largest Sequence Number(SNmax) of
   all previous requests.

   o  Preemptive mode: If the request with SNmax has already been
      processed, the server SHOULD discard the current request and
      respond an error indicating the delay.  Otherwise, if the request
      with SNmax is still being queued, the server SHOULD add the
      current request to the queue and respond these queued requests in
      order based on Section 4.2.1 till the T-start of the request with
      SNmax.

   o  Sequential mode: The server SHOULD add the current request to the
      queue till its T-start.

   o  Sequential with conditional discard mode: The server SHOULD add
      the current request to the queue till its T-start.  If the Valid
      Time Window (T-start + T-duration) of the SNmax request expires
      earlier than the T-start of the current request, the server SHOULD
      process the request with SNmax and discard the current request.

   When some complicated actuators are able to support multi-
   interrelated actions with different requests, it is desirable to be
   required give some indications to the server to process actions,
   especially when there are delays caused by 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 May 3, 2018                  [Page 9]


Internet-Draft           CORE CoAP Delay attack             October 2017


6.1.  Tables

                       +--------+-----------------+
                       | Number |       Name      |
                       +--------+-----------------+
                       |   30   |   Time Window   |
                       |        |                 |
                       |   31   | Sequence Number |
                       |        |                 |
                       |   32   | Response Policy |
                       +--------+-----------------+

                                  Table 1

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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [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,
              <http://www.rfc-editor.org/info/rfc7925>.





Liu & Zhu                  Expires May 3, 2018                 [Page 10]


Internet-Draft           CORE CoAP Delay attack             October 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-06 (work in progress), October 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 May 3, 2018                 [Page 11]

Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/