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]