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

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<T-start   Code: 2.03 (Valid)
                      | 2.03 |       Token: 0x41
                      |      |      Receipt: lining
                      |      |
                      |<-----+T-start  Code: 2.05 (Content)
                      | 2.05 |       Token: 0x41
                      |      |      Receipt: 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 Receipt
   Option indicating "Lining".  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 Receipt Option indicating "OK".

Liu & Zhu                Expires January 4, 2018                [Page 6]
Internet-Draft           CORE CoAP Delay attack                July 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
                   |      |      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,
              <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 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]