CoRE Working Group                                           G. Selander
Internet-Draft                                              F. Palombini
Intended status: Informational                               Ericsson AB
Expires: January 7, 2017                                       K. Hartke
                                                 Universitaet Bremen TZI
                                                            July 6, 2016


               Requirements for CoAP End-To-End Security
                 draft-hartke-core-e2e-security-reqs-01

Abstract

   This document analyses threats to CoAP message exchanges traversing
   proxies and derives the security requirements for mitigating those
   threats.

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 7, 2017.

Copyright Notice

   Copyright (c) 2016 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
   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.



Selander, et al.         Expires January 7, 2017                [Page 1]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Assets and Scope  . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Proxying  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Threats and Security Requirements . . . . . . . . . . . .   7
       2.1.1.  Client-side . . . . . . . . . . . . . . . . . . . . .   7
         2.1.1.1.  Threat 1: Spoofing  . . . . . . . . . . . . . . .   8
         2.1.1.2.  Threat 2: Delaying  . . . . . . . . . . . . . . .   9
         2.1.1.3.  Threat 3: Withholding . . . . . . . . . . . . . .   9
         2.1.1.4.  Threat 4: Flooding  . . . . . . . . . . . . . . .   9
         2.1.1.5.  Threat 5: Eavesdropping . . . . . . . . . . . . .   9
         2.1.1.6.  Threat 6: Traffic Analysis  . . . . . . . . . . .   9
       2.1.2.  Server-side . . . . . . . . . . . . . . . . . . . . .  11
         2.1.2.1.  Threat 1: Spoofing  . . . . . . . . . . . . . . .  12
         2.1.2.2.  Threat 2: Delaying  . . . . . . . . . . . . . . .  12
         2.1.2.3.  Threat 3: Withholding . . . . . . . . . . . . . .  12
         2.1.2.4.  Threat 4: Flooding  . . . . . . . . . . . . . . .  13
         2.1.2.5.  Threat 5: Eavesdropping . . . . . . . . . . . . .  13
         2.1.2.6.  Threat 6: Traffic Analysis  . . . . . . . . . . .  13
     2.2.  Solutions . . . . . . . . . . . . . . . . . . . . . . . .  14
       2.2.1.  Forwarding  . . . . . . . . . . . . . . . . . . . . .  15
         2.2.1.1.  Examples  . . . . . . . . . . . . . . . . . . . .  15
         2.2.1.2.  Functional Requirement  . . . . . . . . . . . . .  17
         2.2.1.3.  Processing Rules  . . . . . . . . . . . . . . . .  17
         2.2.1.4.  Authenticity  . . . . . . . . . . . . . . . . . .  17
         2.2.1.5.  Confidentiality . . . . . . . . . . . . . . . . .  19
       2.2.2.  Caching . . . . . . . . . . . . . . . . . . . . . . .  19
         2.2.2.1.  Examples  . . . . . . . . . . . . . . . . . . . .  19
         2.2.2.2.  Functional Requirements . . . . . . . . . . . . .  21
         2.2.2.3.  Processing Rules  . . . . . . . . . . . . . . . .  21
         2.2.2.4.  Authenticity  . . . . . . . . . . . . . . . . . .  22
         2.2.2.5.  Confidentiality . . . . . . . . . . . . . . . . .  23
   3.  Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . .  24
     3.1.  Threats and Security Requirements . . . . . . . . . . . .  24
       3.1.1.  Subscriber-side . . . . . . . . . . . . . . . . . . .  24
         3.1.1.1.  Threat 1: Spoofing  . . . . . . . . . . . . . . .  26
         3.1.1.2.  Threat 2: Delaying  . . . . . . . . . . . . . . .  27
         3.1.1.3.  Threat 3: Withholding . . . . . . . . . . . . . .  27
         3.1.1.4.  Threat 4: Flooding  . . . . . . . . . . . . . . .  27
         3.1.1.5.  Threat 5: Eavesdropping . . . . . . . . . . . . .  27
         3.1.1.6.  Threat 6: Traffic Analysis  . . . . . . . . . . .  27
       3.1.2.  Publisher-side  . . . . . . . . . . . . . . . . . . .  27
     3.2.  Solutions . . . . . . . . . . . . . . . . . . . . . . . .  28
       3.2.1.  Brokering . . . . . . . . . . . . . . . . . . . . . .  28
         3.2.1.1.  Functional Requirements . . . . . . . . . . . . .  30
         3.2.1.2.  Processing Rules  . . . . . . . . . . . . . . . .  30



Selander, et al.         Expires January 7, 2017                [Page 2]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


         3.2.1.3.  Authenticity  . . . . . . . . . . . . . . . . . .  30
         3.2.1.4.  Confidentiality . . . . . . . . . . . . . . . . .  30
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  31
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  31
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] is a Web
   application protocol designed for constrained nodes and networks
   [RFC7228].  CoAP makes use of Datagram Transport Layer Security
   (DTLS) [RFC6347] for security.  At the same time, CoAP relies on
   proxies for scalability and efficiency; proxies can reduce response
   time and network bandwidth use by serving responses from a cache or
   enable clients to make requests that they otherwise could not make.

   CoAP proxies need to perform a number of operations on requests and
   responses to fulfill their purpose, which requires DTLS to be
   terminated at each proxy.  The proxies therefore do not only have
   access to the data required for performing the desired functionality,
   but are also able to eavesdrop on or manipulate any part of the CoAP
   payload and metadata exchanged between client and server, or inject
   new CoAP messages without being protected or detected by DTLS.

        __________       _________       _________       __________
       |          |     |         |     |         |     |          |
       |          |---->|         |---->|         |---->|          |
       |  Client  |     |  Proxy  |     |  Proxy  |     |  Server  |
       |          |<----|         |<----|         |<----|          |
       |__________|     |_________|     |_________|     |__________|
             :             :   :           :   :             :
             '-------------'   '-----------'   '-------------'
                Security         Security         Security
               Association      Association      Association
                    A                B                C

                       Figure 1: Hop-by-Hop Security

   One way to mitigate this threat is to secure CoAP communication at
   the application layer using an object-based security mechanism such
   as CBOR Encoded Message Syntax [I-D.ietf-cose-msg] instead of or in
   addition to the security mechanisms at the network layer or transport
   layer.  Such a mechanism can provide "end-to-end security" at the




Selander, et al.         Expires January 7, 2017                [Page 3]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   application layer (Figure 2) in contrast to the "hop-by-hop security"
   that DTLS provides (Figure 1).

        __________       _________       _________       __________
       |          |     |         |     |         |     |          |
       |          |---->|         |---->|         |---->|          |
       |  Client  |     |  Proxy  |     |  Proxy  |     |  Server  |
       |          |<----|         |<----|         |<----|          |
       |__________|     |_________|     |_________|     |__________|
             :                                               :
             '-----------------------------------------------'
                           Security Association

                       Figure 2: End-to-End Security

   This document analyses security aspects of sensor and actuator
   communications over CoAP that involve proxies and other similar
   intermediaries.  The analysis is based on the identification of
   assets associated with this communication and considering the
   potential threats posed by proxies to these assets.  The threat
   analysis provides the basis for deriving security requirements that a
   solution for CoAP end-to-end security should meet.

1.1.  Assets and Scope

   In general, there are the following assets that need to be protected:

   o  The devices at the two ends and their (often very constrained)
      system resources such as available memory, storage, processing
      power and energy.

   o  The physical environment of the devices fitted with sensors and
      actuators.  Access to the physical environment is assumed to be
      provided through CoAP resources that allow a remote entity to
      retrieve information about the physical environment (such as the
      current temperature) or to produce an effect on the physical
      environment (such as the activation of a heater).

   o  The communication infrastructure linking the two devices, which
      often contains some very constrained networks.

   o  The data generated and stored in the involved devices.

   An intermediary can directly interfere with the interactions between
   the two ends and thereby have an impact on all these assets.  For
   example, flooding a device with messages has an impact on system
   resources, and the successful manipulation of an actuator command
   (data generated by an involved device) can have a severe impact on



Selander, et al.         Expires January 7, 2017                [Page 4]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   the physical environment.  An intermediary can also affect the
   communication infrastructure, e.g., by dropping messages.

   Even if an intermediary is trustworthy, it may be an attractive
   target for an attack itself, since such nodes are aggregation points
   for message flows and may be an easier target from the Internet than
   the sensor and actuator nodes residing behind them.  An intermediary
   may become subject to intrusion or be infected by malware and perform
   the attacks of a man-in-the-middle.

   The scope of this document is on threats from intermediaries to
   interactions between two CoAP endpoints.

   Since intermediaries may perform a service for the interacting
   endpoints, there is a trade-off between the intermediaries' desired
   functionality and the ability to mitigate threats to the endpoints
   executed through an intermediary.

1.2.  Terminology

   Readers are expected to be familiar with the terms and concepts
   described in [RFC7252] and [RFC7641].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].  The key word "NOT REQUIRED" is interpreted as synonymous
   with the key word "OPTIONAL".























Selander, et al.         Expires January 7, 2017                [Page 5]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.  Proxying

   To assess what impact various threats have to the assets, we need to
   specify and analyse how the proxies operate.

            _ _ __             ___________             __ _ _
                  | Request   |           | Request   |
          Client  |---------->|           |---------->|  Server
            or    |           |   Proxy   |           |    or
          Proxy   |<----------|           |<----------|  Proxy
            _ _ __|  Response |___________|  Response |__ _ _

                             Figure 3: A Proxy

   The proxy receives a request from the client and sends a response
   back to the client.  There are two ways for the proxy to do this:

   o  The proxy constructs and sends a request to the server, receives a
      response from the server and uses the received data to construct
      the response to the client.

   o  The proxy uses cached data to construct the response to the
      client.

   In both cases, the proxy needs to read some parts of the request from
   the client and the response from the server to accomplish its task.

























Selander, et al.         Expires January 7, 2017                [Page 6]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.1.  Threats and Security Requirements

2.1.1.  Client-side

        __________             __ _ _
       |          | Request   |
       |          |---------->|
       |  Client  |           |   Proxy
       |          |<----------|
       |__________|  Response |__ _ _

                         Figure 4: The Client End

   The client sends a request to the proxy and waits for a response.

   From the perspective of the client, there are three possible flows:

   o  The client receives a response.
      Reasons include:

      *  The proxy duly processed the request and returns a response
         based on data it obtained from the origin server.

      *  The proxy encountered an unexpected condition and returns an
         error response according to specification (e.g., 5.02 Bad
         Gateway or 5.04 Gateway Timeout).

      *  (Threat 1:) The proxy spoofs a response.

      *  (Threat 2:) The proxy duly processed the request but delays the
         return of the response.

   o  The client does not receive a response.
      Reasons include:

      *  The client times out too early.

      *  (Threat 3:) The proxy withholds the response.

   o  The client receives too many responses.
      Reasons include:

      *  (Threat 4:) The proxy floods the client with responses.

   Furthermore, there are threats related to privacy:

   o  (Threat 5:) The proxy eavesdrops on the data in the request from
      the client.



Selander, et al.         Expires January 7, 2017                [Page 7]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   o  (Threat 6:) The proxy measures the size, frequency or distribution
      of requests from the client.

   Note that "cache poisoning" -- the case of caching injected incorrect
   responses -- is covered from the point of view of the client: it may
   result in the client receiving a spoofed message, or being flooded,
   or affect other nodes such that the client times out too early.

2.1.1.1.  Threat 1: Spoofing

   With one exception (see below), this threat is REQUIRED to be
   mitigated by the security solution: the client MUST verify that the
   response is an _authentic response_ before processing it.

   The definition of an "authentic response" depends on the desired
   proxy functionality and protection level (Section 2.2), but usually
   means that the client can obtain proof for some or all of the
   following things:

   o  that the requested action was executed by the origin server;

   o  that the data originates from the origin server and has not been
      altered on the way;

   o  that the data matches the specifications of the request (such as
      the target resource);

   o  that the data is fresh (when the data is cacheable);

   o  that the data is in sequence (when observing a resource).

   The proof can, for example, involve a message authentication code
   that the proxy obtains from the origin server and includes in the
   response or an additional challenge-response roundtrip.

   Note that a CoAP proxy is specified to return an error response (such
   as 5.02 Bad Gateway or 5.04 Gateway Timeout) when it encounters an
   error condition.  Since the condition occurs at the proxy and not at
   the origin server, the response will not be an "authentic response"
   according to the above definition.  Thus a client cannot tell if the
   proxy sends the response according to specification or if it spoofs
   the response.  This threat is NOT REQUIRED to be mitigated by the
   security solution.








Selander, et al.         Expires January 7, 2017                [Page 8]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.1.1.2.  Threat 2: Delaying

   This threat is REQUIRED to be mitigated by the security solution.
   Delay attacks are important to mitigate in certain applications,
   e.g., when using CoAP with actuators.  A problem statement and
   candidate solution can be found in
   [I-D.mattsson-core-coap-actuators].

2.1.1.3.  Threat 3: Withholding

   This threat is NOT REQUIRED to be mitigated by the security solution,
   since a client cannot tell if the proxy does not send a response
   because it is hasn't received a response from the origin server yet
   or if it intentionally withholds the response.

2.1.1.4.  Threat 4: Flooding

   A CoAP client is specified to reject any response that it does not
   expect.  This can happen before the client verifies if the response
   is authentic.  Therefore a flood of responses is primarily a threat
   to the system resources of the client, in particular to its energy.
   This threat is NOT REQUIRED to be mitigated by the security solution
   in particular, but a client SHOULD generally defend against flooding
   attacks.

2.1.1.5.  Threat 5: Eavesdropping

   This threat is REQUIRED to be mitigated by the security solution:
   clients MUST confidentiality protect the data in the requests they
   send.

   Note that this requirement is in conflict with the requirement that
   the proxy needs to be able to read some parts of the requests in
   order to accomplish its task.  Section 2.2 analyses which parts can
   be encrypted depending on the desired proxy functionality and
   protection level.  In general, a security solution SHOULD
   confidentiality protect all data that is not needed to be read by the
   proxy to accomplish its task.

   The keys used for confidentiality protection MUST provide forward
   secrecy.

2.1.1.6.  Threat 6: Traffic Analysis

   This threat is NOT REQUIRED to be mitigated by the security solution.

   It is RECOMMENDED that applications analyse the risks associated with
   application information leaking from the messages flow and assess the



Selander, et al.         Expires January 7, 2017                [Page 9]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   feasibility to protect against various threats, e.g., by obfuscating
   parameters transported in plain text, aligning message flow and
   traffic between the different cases, adding padding so different
   messages become indistinguishable, etc.















































Selander, et al.         Expires January 7, 2017               [Page 10]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.1.2.  Server-side

                                    _ _ __             __________
                                          | Request   |          |
                                          |---------->|          |
                                  Proxy   |           |  Server  |
                                          |<----------|          |
                                    _ _ __|  Response |__________|

                         Figure 5: The Server End

   A server listens for a request and returns a response.

   From the perspective of the server, there are three possible flows:

   o  The server receives a request.
      Reasons include:

      *  The proxy makes a request on behalf of a client according to
         specification.

      *  The proxy makes a request (e.g., to validate cached data) on
         its own behalf.

      *  (Threat 1:) The proxy spoofs a request.

      *  (Threat 2:) The proxy sends a request with delay.

   o  The server does not receive a request.
      Reasons include:

      *  The proxy does not need to send a request.

      *  (Threat 3:) The proxy withholds a request.

   o  The server receives too many requests.
      Reasons include:

      *  (Threat 4:) The proxy floods the server with requests.

   A proxy eavesdropping or inferring information from messages it
   operates on has an impact on a server in the same way as on a client
   (Section 2.1.1):

   o  (Threat 5:) The proxy eavesdrops on the data in the response from
      the server.





Selander, et al.         Expires January 7, 2017               [Page 11]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   o  (Threat 6:) The proxy measures the frequency and distribution of
      responses from the server.

2.1.2.1.  Threat 1: Spoofing

   With one exception (see below), this threat is REQUIRED to be
   mitigated by the security solution: the server MUST verify that the
   request is an _authentic request_ before processing it.

   The definition of an "authentic request" depends on the desired proxy
   functionality and protection level (Section 2.2), but usually means
   that the server can obtain proof for some or all of the following
   things:

   o  that the proxy acts on behalf of a client;

   o  that the data originates from the client and has not been altered
      on the way;

   o  that the request has not been received previously.

   The proof can, for example, involve a message authentication code
   that the proxy obtains from the client and includes in the request or
   a challenge-response roundtrip.

   Note that a CoAP proxy may make certain requests (e.g., to validate
   cached data) without acting on behalf of a client.  Since such a
   request does not originate from a client, the server cannot tell if
   the proxy sends the request according to specification or if it
   spoofs the request.  It is up to the security solution how this issue
   is addressed.

2.1.2.2.  Threat 2: Delaying

   This threat is REQUIRED to be mitigated by the security solution; see
   Section 2.1.1.2.

2.1.2.3.  Threat 3: Withholding

   This threat is NOT REQUIRED to be mitigated by the security solution,
   since a server cannot tell if the proxy does not send a request
   because it has no work to do or if it intentionally withholds a
   request.








Selander, et al.         Expires January 7, 2017               [Page 12]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.1.2.4.  Threat 4: Flooding

   This threat is NOT REQUIRED to be mitigated by the security solution
   in particular, but a server SHOULD generally defend against flooding
   attacks.

2.1.2.5.  Threat 5: Eavesdropping

   This threat is REQUIRED to be mitigated by the security solution; see
   Section 2.1.1.5.

2.1.2.6.  Threat 6: Traffic Analysis

   This threat is NOT REQUIRED to be mitigated by the security solution;
   see Section 2.1.1.6.




































Selander, et al.         Expires January 7, 2017               [Page 13]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.2.  Solutions

   A security solution has to find a trade-off between desired proxy
   functionality (such as caching) and the provided level of protection.
   From this trade-off results the definition of what constitutes an
   authentic request or response and when a request or response is
   considered confidentiality protected.

   This section presents two exemplary choices of trade-offs:

   o  The first case focuses on a high protection level by tying
      requests and responses uniquely together and confidentiality
      protecting as much as possible, at the cost of reduced proxy
      functionality.

   o  The second case aims to preserve proxy functionality as much as
      possible, at the cost of reduced confidentiality protection.

   For both cases, this section presents an overview of the
   functionality and processing rules of the proxy and analyses the
   required authenticity and confidentiality properties of requests and
   responses.  Due to space constraints, the analysis is limited to the
   CoAP header fields, the payload, and the request and response options
   shown in Table 1.

                    +----------------+----------------+
                    | Requests       | Responses      |
                    +----------------+----------------+
                    | Accept         | Content-Format |
                    | Content-Format | ETag           |
                    | ETag           | Location-Path  |
                    | If-Match       | Location-Query |
                    | If-None-Match  | Max-Age        |
                    | Observe        | Observe        |
                    | Proxy-Scheme   |                |
                    | Proxy-Uri      |                |
                    | Uri-Host       |                |
                    | Uri-Port       |                |
                    | Uri-Path       |                |
                    | Uri-Query      |                |
                    +----------------+----------------+

                      Table 1: Analysed CoAP Options

   Note that, since CoAP was not designed with end-to-end security in
   mind, a security solution extends the applicability of CoAP beyond
   its original scope.




Selander, et al.         Expires January 7, 2017               [Page 14]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.2.1.  Forwarding

   In this case we study forwarding functionality of a CoAP forward
   proxy, and assume that caching is disabled.  This is applicable to
   many security critical use cases where a response needs to be
   securely linked to a unique request from a client and cannot be re-
   used with another request.

   There may be a unique response for each request (see Figure 6) or
   multiple responses for each request (see Figure 7).

2.2.1.1.  Examples

   Examples of the need for unique response for each request include
   alarm status retrieval and actuator command confirmation.

                  Client          Proxy          Server
                    |               |               |
                    |    Request    |    Request    |
                    |-------------->|-------------->|--.
                    |               |               |  |
                    |<--------------|<--------------|<-'
                    |    Response   |    Response   |
                    |               |               |

      Figure 6: Message Flow with a Unique Response for Each Request

   Example: Alarm status retrieval

      Figure 6 can be seen as an illustration of a message exchange for
      a client requesting the alarm status (e.g., GET /alarm_status)
      from a server.  Since the client wants to ensure that the alarm
      status received is reflecting the current alarm status and not a
      cached or spoofed response to the same resource, it must be able
      to verify that the received response is a response to this
      particular request made by the client.  Therefore the response
      must be securely linked to the request.

   Example: Actuation confirmation

      Another example for which Figure 6 serves as illustration is the
      confirmation of an actuator request.  In this case a client, say
      in an industrial control system, requests a server that a valve
      should be turned to a certain level, e.g.  PUT /valve_42/level
      with payload "3".  In order for the client to correctly evaluate
      the result of a potential changed valve level, it is important
      that the client gets a confirmation how the server responded to
      the requested change, e.g., whether the request was performed or



Selander, et al.         Expires January 7, 2017               [Page 15]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


      not.  Again, the client wants to ensure that the response is
      reflecting the result of this particular actuation request made by
      the client and not a cached or spoofed response.  Therefore the
      response must be securely linked to the request.

   An example of the use of multiple responses for each request is in
   security critical monitoring scenarios where time synchronization
   cannot be guaranteed.  By avoiding repeated requests from the same
   client to the same resource, constrained node resources and bandwidth
   is saved.

                  Client          Proxy          Server
                    |               |               |
                    |    Request    |    Request    |
                    |-------------->|-------------->|--.
                    |               |               |  |
                    |<--------------|<--------------|<-'
                    |  Notification |  Notification |
                    |               |               |
                    |<--------------|<--------------|
                    |  Notification |  Notification |
                    |               |               |
                    |<--------------|<--------------|
                    |  Notification |  Notification |
                    |               |               |

   Figure 7: Message Flow of Notifications of Linked to a Unique Request

   Example: Secure parameter monitoring

      Figure 7 can be seen as an illustration of a message exchange for
      a client monitoring an important parameter measured by the server,
      e.g., in a medical or process industry application.  The client
      makes a subscription request for a resource and the server
      responds with notifications, e.g. providing updates to the
      parameter on regular time intervals.

      The client wants to ensure that the first received notification
      reflects the current parameter value and that subsequent
      notifications are timely updates of the initial request.  Since
      notifications may be lost or reordered, the client needs to be
      able to verify the order of the messages, as sent by the server.
      By monitoring the received messages and the time they are
      received, the client can detect missing notifications and take
      appropriate action.






Selander, et al.         Expires January 7, 2017               [Page 16]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.2.1.2.  Functional Requirement

   FR1.1  The caching functionality MUST be inhibited; the CoAP option
          Max-Age of the responses SHALL be 0 (see Section 5.7.1 of
          [RFC7252]).

   FR1.2  To limit information leaking about the resource (see
          Section 2.2.1.5) the Proxy-Uri does not contain Uri-Path or
          Uri-Query.

2.2.1.3.  Processing Rules

   In this case, the desired proxy functionality is to forward a
   translated request to the determined destination.  There are two
   modes of operation for requests: Either using the Proxy-Uri option
   (PR1.1) or using the Proxy-Scheme option together with the Uri-Host,
   Uri-Port, Uri-Path and Uri-Query options (PR1.2).

   PR1.1  The Proxy-Uri option contains the request URI including
          request scheme (e.g. "coaps://"); the Proxy-Scheme and Uri-*
          options are not present.

          If the proxy is configured to forward requests to another
          proxy, then it keeps the Proxy-Uri option; otherwise, it
          splits the option into its components, adds the corresponding
          Uri-* options and removes the Proxy-Uri option.  Then it makes
          the request using the request scheme indicated in the Proxy-
          Uri.

   PR1.2  The Proxy-Scheme option and the Uri-* options together contain
          the request URI; the Proxy-Uri option is not present.

          If the proxy is configured to forward requests to another
          forwarding proxy, then it keeps the Proxy-Scheme and Uri-*
          options; otherwise, it removes the Proxy-Scheme option.  Then
          it makes the request using the request scheme indicated in the
          removed Proxy-Scheme option.

   PR1.3  Responses are forwarded by the proxy, without any
          modification.

2.2.1.4.  Authenticity

   A request is considered authentic by the server (Section 2.1.2.1) if
   the server can obtain proof for all of the following things:

   A1.1  that the proxy acts on behalf of a client;




Selander, et al.         Expires January 7, 2017               [Page 17]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   A1.2  that the following parts of the request originate from the
         client and have not been altered on the way:

         *  the CoAP version,

         *  the request method,

         *  all options except Proxy-Uri, Proxy-Scheme, Uri-Host, Uri-
            Port, Uri-Path and Uri-Query, and

         *  the payload, if any.

   A1.3  that the effective request URI originates from the client and
         has not been altered on the way;

   A1.4  that the request has not been received previously;

   A1.5  that the request from the client to the proxy was sent
         recently.

   A response is considered authentic by the client (Section 2.1.1.1) if
   the client can obtain proof for all of the following things:

   A1.6  that the following parts of the response originate from the
         server and have not been altered on the way:

         *  the CoAP version,

         *  the response code,

         *  all options, and

         *  the payload, if any.

   A1.7  that the response corresponds uniquely to the request sent by
         the client.

   A1.8  that the response has not been received previously;

   A1.9  that the response from the server to the proxy was sent
         recently;

   A1.10 that the response is in sequence if there are multiple
         responses.







Selander, et al.         Expires January 7, 2017               [Page 18]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


2.2.1.5.  Confidentiality

   The following parts of the message are confidentiality protected
   (Section 2.1.1.5):

   o  all options except Proxy-Uri, Proxy-Scheme, Uri-Host and Uri-Port;

   o  the payload, if any.

2.2.2.  Caching

   In this case we study caching: how a proxy may serve the same cached
   response to multiple clients requesting the same resource.

   The caching functionality protects communication-constrained servers
   from repeated requests for the same resources, possibly originating
   from different clients.  This saves system resources, bandwidth, and
   round-trip time.

   There may be one response for each request (see Figure 8) or multiple
   responses for each request (see Figure 9).

2.2.2.1.  Examples

   The first example is a simple case of caching.

                  Client A         Proxy           Server
                     |               |               |
                     |    Request    |    Request    |
                     |-------------->|-------------->|--.
                     |               |               |  |
                     |<--------------|<--------------|<-'
                     |    Response   |    Response   |
                     |               |               |
                                     |               |
                  Client B           |               |
                     |               |               |
                     |    Request    |               |
                     |-------------->|--.            |
                     |               |  | from cache |
                     |<--------------|<-'            |
                     |    Response   |               |
                     |               |               |

                Figure 8: Message Flow for Cached Responses

   Example: Caching




Selander, et al.         Expires January 7, 2017               [Page 19]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


      In Figure 8, client A requests the proxy to make a certain request
      to the server and to return the server's response.  The proxy
      services the request by making a request message to the server
      according to the processing rules.  If the server returns a
      cacheable response, then the proxy stores the response in its
      cache, performs any necessary translations, and forwards it to the
      client.  Later, client B makes an equivalent request to the proxy
      that the proxy services by returning the response from its cache.
      Both client A and B want to verify that the response is valid.

   In addition to multiple clients' requests being served by one
   response, each request may result in multiple responses.  The
   difference compared to Section 2.2.1 is that in this example multiple
   clients may be served with the same response, further saving server
   resources.

                  Client A         Proxy          Server
                     |               |               |
                     |    Request    |    Request    |
                     |-------------->|-------------->|--.
                     |               |               |  |
                     |<--------------|<--------------|<-'
                     |  Notification |  Notification |
                     |               |               |
                                     |               |
                  Client B           |               |
                     |               |               |
                     |    Request    |               |
                     |-------------->|--.            |
                     |               |  | from cache |
                     |<--------------|<-'            |
                     |  Notification |               |
                     |               |               |
                     |<--------------|<--------------|
                     |  Notification |  Notification |
                     |               |               |
                                     |               |
                  Client A           |               |
                     |               |               |
                     |<--------------|               |
                     |  Notification |               |
                     |               |               |

        Figure 9: Message Flow for Observe with Multiple Observers

   Example: Observe with caching





Selander, et al.         Expires January 7, 2017               [Page 20]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


      In Figure 9, the server exposes an observable resource (e.g., the
      current reading of a temperature sensor).  Multiple clients are
      interested in the current state of the resource and observe it
      using the CoAP resource observation mechanism [RFC7641].  The goal
      is to keep the state observed by the clients closely in sync with
      the actual state of the resource at the server.  Another goal is
      to minimize the burden on the server by moving the task to fan out
      notifications to multiple clients from the server to the proxy.

2.2.2.2.  Functional Requirements

   The security solution SHOULD protect requests and responses in a way
   that a proxy can perform the following tasks:

   FR2.1  Storing a cacheable response in a cache.  This requires that
          the proxy is able to calculate the cache-key of the request.
          Cacheable responses include 2.05 (Content) responses and all
          error responses.

   FR2.2  Returning a fresh response from its cache without contacting
          the server.

   FR2.3  Performing validation of a response cached by the proxy as
          well as validation of a response cached by the client.

   FR2.4  Observing a resource on behalf of one or more clients.

2.2.2.3.  Processing Rules

   The proxy complies with the forwarding rules PR1.1 - 1.3
   (Section 2.2.1.3) and the rules below.  The rules below have
   priority.

   PR2.1  If the proxy receives a request where the cache key matches
          that of a cached fresh response, then the proxy discards the
          request and replies with that response, else it makes a
          translated request.

   PR2.2  The proxy caches and forwards cacheable responses.  If there
          is already a response in the cache with the cache key of the
          corresponding request, then the old response in the cache is
          marked as stale.

   PR2.3  If the proxy receives a request that contains an ETag option
          and the proxy has a fresh response with the same cache key and
          ETag, then the proxy replies to the request with a 2.03
          (Valid) response without payload, else it forwards a
          translated request.



Selander, et al.         Expires January 7, 2017               [Page 21]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   PR2.4  The proxy updates the Max-Age option according to the Max-Age
          associated with the resource representation it receives,
          decreasing its value to reflect the time spent in the cache.

   PR2.5  If the request contains an Accept option and if there is a
          fresh response that matches the cache key for the
          corresponding request except for the Accept option, and if the
          Content-Format of the response matches that of the Accept
          option, then the proxy forwards the cached response to the
          requesting client.

2.2.2.4.  Authenticity

   A request is considered authentic by the server (Section 2.1.2.1) if
   the server can obtain proof for all of the following things:

   A2.1  that the following parts of the request originate from the
         client and have not been altered on the way:

         *  the CoAP version,

         *  the request method,

         *  all options except ETag, Observe, Proxy-Uri, Proxy-Scheme,
            Uri-Host, Uri-Port, Uri-Path and Uri-Query, and

         *  the payload, if any.

   A2.2  that the effective request URI originates from the client and
         has not been altered on the way;

   A response is considered authentic by the client (Section 2.1.1.1) if
   the client can obtain proof for all of the following things:

   A2.3  that the following parts of the response originate from the
         server and have not been altered on the way:

         *  the CoAP version,

         *  the response code,

         *  all options except Max-Age and Observe, and

         *  the payload, if any.

   A2.4  that the response matches the specifications of the request;

   A2.5  that the data is fresh (when the response is cacheable);



Selander, et al.         Expires January 7, 2017               [Page 22]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   A2.6  that the response is in sequence (when observing a resource).

2.2.2.5.  Confidentiality

   No parts of a request are confidentiality protected
   (Section 2.1.2.5).

   A response is considered confidentiality protected (Section 2.1.2.5)
   if the payload of the response is confidentiality protected.










































Selander, et al.         Expires January 7, 2017               [Page 23]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


3.  Publish-Subscribe

   Much of the concerns about proxies as described previously in this
   document also applies to other kind of intermediary nodes.  In this
   section we study brokers in a publish-subscribe setting
   [I-D.koster-core-coap-pubsub].  The case of combining brokers and
   proxies is out of scope for this version of the document.

   There are different ways for a pub-sub broker to operate.  We
   consider the following broker operations:

   o  The broker receives a request for a topic from the subscriber.

   o  The broker receives a request for a publication to a topic from
      the publisher and forwards the request to the subscribers of the
      topic.

   We consider the setting where there is a security association between
   publisher and subscriber such that the publications can be protected
   during transfer, see Figure 10.

            ____________        __________         ___________
           |            |      |          |       |           |
           |            |----->|          |<------|           |
           | Subscriber |      |  Broker  |       | Publisher |
           |            |<-----|          |------>|           |
           |____________|      |__________|       |___________|
                 :                                      :
                 '--------------------------------------'
                           Security Association

                Figure 10: Publisher-to-Subscriber Security

   Since there is no security association with the broker, we only
   consider the subscribe and publish functionality of the broker.  Note
   that the broker needs to read the topic to accomplish this task.

3.1.  Threats and Security Requirements

3.1.1.  Subscriber-side











Selander, et al.         Expires January 7, 2017               [Page 24]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


        __________             __ _ _
       |          | Request   |
       |  Sub-    |---------->|
       |  scriber |           |   Broker
       |          |<----------|
       |__________|  Response |__ _ _

                       Figure 11: The Subscriber End

   The subscriber sends a subscription request to the broker and waits
   for a response.

   From the perspective of the subscriber, there are three possible
   flows:

   o  The subscriber receives a response.
      Reasons include:

      *  The broker duly processed the request and returns a response
         based on data it obtained from a publisher.

      *  The subscriber made a bad request and the broker returns an
         error response accordingly (e.g., 4.04 Not Found).

      *  The broker encountered an unexpected condition and returns an
         error response accordingly (e.g., 5.03 Service Unavailable).

      *  (Threat 1:) The broker spoofs a response.

      *  (Threat 2:) The broker duly processed the request but delays
         the return of a response.

   o  The subscriber does not receive a response.
      Reasons include:

      *  The subscriber times out too early.

      *  (Threat 3:) The broker withholds a response.

   o  The subscriber receives too many responses.
      Reasons include:

      *  (Threat 4:) The broker floods the subscriber with responses.

   Furthermore, there are threats related to privacy:

   o  (Threat 5:) The broker eavesdrops on the data in the request from
      the subscriber.



Selander, et al.         Expires January 7, 2017               [Page 25]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


   o  (Threat 6:) The broker measures the size, frequency or
      distribution of requests from the subscriber.

   Note that "topic poisoning" -- the case of storing injected incorrect
   publications -- is covered from the point of view of the subscriber:
   it may result in the subscriber receiving a spoofed message, or being
   flooded, or affect other nodes such that the subscriber times out too
   early.

3.1.1.1.  Threat 1: Spoofing

   With one exception (see below), this threat is REQUIRED to be
   mitigated by the security solution: the subscriber MUST verify that a
   response is an _authentic publication_ before processing it.

   The definition of an "authentic publication" depends on the setting
   (Section 3.2), but usually means that the subscriber can obtain proof
   for some or all of the following things:

   o  that the data matches the specifications of the request (such as
      the topic);

   o  that the data originates from a publisher that is authorized to
      publish to the topic;

   o  that the data has not been altered on the way between publisher
      and subscriber;

   o  that the data is fresh (when the data is cacheable);

   o  that the data is in sequence (when observing a topic).

   The proof can, for example, involve a message authentication code
   that the proxy obtains from the origin server and includes in the
   response or an additional challenge-response roundtrip.

   Note that a CoAP server like the broker is specified to return an
   error response (such as 4.04 Not Found or 5.03 Service Unavailable)
   when it encounters an error condition.  Since the condition occurs at
   the broker and not at the publisher, the response will not be an
   "authentic response" according to the above definition.  Thus a
   subscriber cannot tell if the broker sends the error response
   according to specification or if it spoofs the response.  This threat
   is NOT REQUIRED to be mitigated by the security solution.







Selander, et al.         Expires January 7, 2017               [Page 26]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


3.1.1.2.  Threat 2: Delaying

   This threat is NOT REQUIRED to be mitigated by the security solution.

3.1.1.3.  Threat 3: Withholding

   This threat is NOT REQUIRED to be mitigated by the security solution,
   since a subscriber cannot tell if the broker does not send a response
   because it is hasn't received a publication from the publisher yet or
   if it intentionally withholds the response.

3.1.1.4.  Threat 4: Flooding

   A CoAP client like the subscriber is specified to reject any response
   that it does not expect.  This can happen before the subscriber
   verifies if the response is authentic.  Therefore a flood of
   responses is primarily a threat to the system resources of the
   client, in particular to its energy.  This threat is NOT REQUIRED to
   be mitigated by the security solution in particular, but a subscriber
   SHOULD generally defend against flooding attacks.

3.1.1.5.  Threat 5: Eavesdropping

   This threat is NOT REQUIRED to be mitigated: The broker needs to read
   all parts of the request from the subscriber to accomplish its task.

   It is RECOMMENDED that applications analyse the risks associated with
   application information leaking from the messages flow and assess the
   feasibility to protect against various threats, e.g., by obfuscating
   topic content.

3.1.1.6.  Threat 6: Traffic Analysis

   This threat is NOT REQUIRED to be mitigated by the security solution.

   It is RECOMMENDED that applications analyse the risks associated with
   application information leaking from the messages flow and assess the
   feasibility to protect against various threats, e.g., by obfuscating
   parameters transported in plain text, aligning message flow and
   traffic between the different cases, adding padding so different
   messages become indistinguishable, etc.

3.1.2.  Publisher-side








Selander, et al.         Expires January 7, 2017               [Page 27]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


                                    _ _ __             __________
                                          | Request   |          |
                                          |<----------|  Pub-    |
                                  Broker  |           |  lisher  |
                                          |---------->|          |
                                    _ _ __|  Response |__________|

                       Figure 12: The Publisher End

   The publisher sends a publication request to the broker and waits for
   a response.

   The threat of the broker eavesdropping on the data in the publication
   request is REQUIRED to be mitigated by the security solution:
   publishers MUST confidentiality protect the data in the requests they
   send.  This excludes parts that the broker needs to read to perform
   its job, e.g., the topic.

   The threat of the broker measuring the size, frequency or
   distribution of publication requests is NOT REQUIRED to be mitigated
   by the security solution; see Section 3.1.1.6.

   The broker is in full control of the response and may therefore
   arbitrarily spoof, delay, or withhold it.  This threat is NOT
   REQUIRED to be mitigated.  A proof that the broker has notified all
   subscribers is NOT REQUIRED.

3.2.  Solutions

3.2.1.  Brokering

   In this case we study brokering: how a broker may serve the same
   publication to multiple subscribers observing the same topic.

   The brokering functionality protects communication-constrained
   publishers from repeated requests for the same resources, possibly
   originating from different subscribers.  This saves system resources,
   bandwidth, and round-trip time.













Selander, et al.         Expires January 7, 2017               [Page 28]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


                Subscriber A       Broker         Publisher
                     |               |               |
                     |               |    Request    |
                     |            .--|<--------------|
                     |            |  |               |
                     |            '->|-------------->|
                     |               |   Response    |
                     |               |               |
                     |    Request    |               |
                     |-------------->|--.            |
                     |               |  | from store |
                     |<--------------|<-'            |
                     |  Notification |               |
                     |               |               |
                                     |               |
                Subscriber B         |               |
                     |               |               |
                     |    Request    |               |
                     |-------------->|--.            |
                     |               |  | from store |
                     |<--------------|<-'            |
                     |  Notification |               |
                     |               |               |
                     |               |    Request    |
                     |<--------------|<--------------|
                     |  Notification |               |
                     |               |-------------->|
                     |               |   Response    |
                                     |               |
                Subscriber A         |               |
                     |               |               |
                     |<--------------|               |
                     |  Notification |               |
                     |               |               |

               Figure 13: Message Flow for Publish Subscribe

   Example

      In Figure 13, the publisher publishes to a topic (e.g., the
      current reading of a temperature sensor).  Multiple subscribers
      are interested in the current state of the topic and observe the
      topic as specified in [I-D.koster-core-coap-pubsub].  The goal is
      to keep the state observed by the subscribers closely in sync with
      the actual state of the resource at the publisher.  Another goal
      is to minimize the burden on the publisher by moving the task to
      fan out notifications to multiple subscribers from the publisher
      to the broker.



Selander, et al.         Expires January 7, 2017               [Page 29]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


3.2.1.1.  Functional Requirements

   The security solution SHOULD protect subscription and publication
   requests in a way that a broker can perform the following tasks:

   FR3.1  Storing publications.  This requires that the broker is able
          to read the topic of the request.

   FR3.2  Returning a stored publication without contacting the
          publisher.

3.2.1.2.  Processing Rules

   The broker complies with the following rules:

   PR3.1  If the broker receives a request where the topic matches that
          of a cached publication, then the broker responds with that
          publication.

   PR3.2  The broker caches and forwards publication notifications.

3.2.1.3.  Authenticity

   A publication is considered authentic by the subscriber if the
   subscriber can obtain proof for all all of the following things:

   A3.1  that the payload is associated to the topic;

   A3.2  that the payload has not been altered since published;

   A3.3  that the publication is in sequence.

3.2.1.4.  Confidentiality

   The payload of a publication request is confidentiality protected.

4.  Security Considerations

   This document is about security; as such, there are no additional
   security considerations.

5.  IANA Considerations

   This document includes no request to IANA.







Selander, et al.         Expires January 7, 2017               [Page 30]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


6.  References

6.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>.

   [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>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <http://www.rfc-editor.org/info/rfc7641>.

6.2.  Informative References

   [I-D.ietf-cose-msg]
              Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              draft-ietf-cose-msg-14 (work in progress), June 2016.

   [I-D.koster-core-coap-pubsub]
              Koster, M., Keranen, A., and J. Jimenez, "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)", draft-koster-core-coap-pubsub-04 (work in
              progress), November 2015.

   [I-D.mattsson-core-coap-actuators]
              Mattsson, J., Fornehed, J., Selander, G., and F.
              Palombini, "Controlling Actuators with CoAP", draft-
              mattsson-core-coap-actuators-01 (work in progress), March
              2016.

   [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>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <http://www.rfc-editor.org/info/rfc7228>.






Selander, et al.         Expires January 7, 2017               [Page 31]


Internet-Draft  Requirements for CoAP End-To-End Security      July 2016


Acknowledgments

   Thanks to Ari Keranen, John Mattsson, Jim Schaad, and Ludwig Seitz
   for helpful comments and discussions that have shaped the document.

Authors' Addresses

   Goeran Selander
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Email: goran.selander@ericsson.com


   Francesca Palombini
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Email: francesca.palombini@ericsson.com


   Klaus Hartke
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  28359
   Germany

   Phone: +49-421-218-63905
   Email: hartke@tzi.org




















Selander, et al.         Expires January 7, 2017               [Page 32]