CoRE Working Group G. Selander
Internet-Draft F. Palombini
Intended status: Informational Ericsson AB
Expires: September 20, 2016 K. Hartke
Universitaet Bremen TZI
L. Seitz
SICS Swedish ICT AB
March 19, 2016
Requirements for CoAP End-To-End Security
draft-hartke-core-e2e-security-reqs-00
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 September 20, 2016.
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
Selander, et al. Expires September 20, 2016 [Page 1]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios, Threats and Security Requirements . . . . . . . . 6
3.1. One Request - One Response . . . . . . . . . . . . . . . 7
3.1.1. Processing Rules . . . . . . . . . . . . . . . . . . 8
3.1.2. Security Objectives . . . . . . . . . . . . . . . . . 9
3.1.3. Threat Analysis and Mitigation . . . . . . . . . . . 10
3.1.4. Security Requirements . . . . . . . . . . . . . . . . 13
3.2. One Request - Multiple Responses . . . . . . . . . . . . 14
3.2.1. Processing Rules . . . . . . . . . . . . . . . . . . 15
3.2.2. Security Objectives . . . . . . . . . . . . . . . . . 16
3.2.3. Threat Analysis and Mitigation . . . . . . . . . . . 16
3.2.4. Security Requirements . . . . . . . . . . . . . . . . 17
3.3. Multiple Requests - One Response . . . . . . . . . . . . 17
3.3.1. Processing Rules . . . . . . . . . . . . . . . . . . 19
3.3.2. Security Objectives . . . . . . . . . . . . . . . . . 19
3.3.3. Threat Analysis and Mitigation . . . . . . . . . . . 20
3.3.4. Security Requirements . . . . . . . . . . . . . . . . 24
3.4. Multiple Requests - Multiple Responses: Observe . . . . . 25
3.4.1. Processing Rules . . . . . . . . . . . . . . . . . . 27
3.4.2. Security Objectives . . . . . . . . . . . . . . . . . 27
3.4.3. Threat Analysis and Mitigation . . . . . . . . . . . 27
3.4.4. Security Requirements . . . . . . . . . . . . . . . . 28
3.5. Multiple Requests - Multiple Responses: Publish-Subscribe 28
3.5.1. Processing Rules . . . . . . . . . . . . . . . . . . 30
3.5.2. Security Objectives . . . . . . . . . . . . . . . . . 30
3.5.3. Threat Analysis and Mitigation . . . . . . . . . . . 30
3.5.4. Security Requirements . . . . . . . . . . . . . . . . 33
4. Security Considerations . . . . . . . . . . . . . . . . . . . 34
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Normative References . . . . . . . . . . . . . . . . . . 35
6.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] is a Web
application protocol designed for constrained nodes and networks
[RFC7228].
Selander, et al. Expires September 20, 2016 [Page 2]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
CoAP uses Datagram Transport Layer Security (DTLS) [RFC6347] for
security. At the same time, CoAP relies on proxies for scalability
and efficiency. These proxies are specified to perform a number of
operations on CoAP messages which requires DTLS to be terminated at
the proxy. The proxy therefore not only has access to the data
required for performing the desired proxy functionality, but is also
able to eavesdrop on or manipulate any part of the CoAP payload and
metadata in transit between client and server or inject new CoAP
messages without being protected or detected by DTLS.
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
application layer in contrast to the "hop-by-hop security" provided
by DTLS.
This document analyses security requirements for CoAP requests and
responses of sensor and actuator deployments involving proxies and
other similar intermediaries. The analysis is based on identifying
the assets associated to sensor- and actuator-based communication
patterns and considering the potential threats executed through
proxies to these assets. The threat analysis provides the basis for
defining the security requirements that an end-to-end security
mechanism for CoAP needs to meet.
1.1. Terminology
Readers are expected to be familiar with the terms and concepts
described in [RFC7252].
2. Scope and Assumptions
This document presents a number of scenarios involving sensor and
actuator communications over CoAP. Common to all scenarios is the
presence of at least one CoAP intermediary, typically in the form of
a proxy between a client requesting a resource and a server hosting a
resource (see Figure 1). The proxy is responsible, for example, for
reducing response time and network bandwidth use by serving responses
from a cache or for enabling the client to make requests that it
otherwise could not make.
Selander, et al. Expires September 20, 2016 [Page 3]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
__________ Request _________ __________
| | ---------> | | Request | |
| | | | ---------> | |
| Client | | Proxy | | Server |
| | | | <--------- | |
|__________| <--------- |_________| Response |__________|
Response
Figure 1: CoAP Message Exchanges Through A Proxy
The basic function of a proxy is to forward translated messages
according to certain processing rules. For example:
o Forward a message to the next proxy when the link is up
o Only forward a request if there is no fresh cached response
o Forward a new publication to all subscribing clients
In order to perform its function, a proxy may be required to read or
change certain parts of a CoAP message as defined in [RFC7252]. For
example, a forward proxy is defined to transform the Proxy-Uri option
to Uri-Host, Uri-Port, Uri-Path and Uri-Query options. A proxy
caching responses needs to read the Cache Key and is required to
change the Max-Age option in the responses.
Since a proxy might not be fully trusted, a security solution is
needed that protects the client, the server and the message exchanges
against certain threats while still allowing the proxy to assume its
normal functionality. The client and server are assumed to have a
security association, but the proxy is neither assumed to have a
security association with the client nor with the server.
__________ ___________ __________
| | > | | Requests > | |
| Client |___| Forward |___________________| Origin |
| | | Proxy | | Server |
|__________| < |___________| < Responses |__________|
: :
'---------------------------------------------'
Security Association
Figure 2: Security Association Between Client and Server
For a start, this document considers the following two cases: Forward
proxies (as specified in [RFC7252]; Figure 2) and publish-subscribe
brokers (as specified in [I-D.koster-core-coap-pubsub]; Figure 3).
Selander, et al. Expires September 20, 2016 [Page 4]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
The functionality assumed by these nodes is summarized in the
respective scenarios analyzed in this document (Section 3).
___________ __________ ____________
| | > | | < | |
| Publisher |__________| Broker |__________| Subscriber |
| (Client) | | (Server) | | (Client) |
|___________| < |__________| > |____________|
: :
'----------------------------------------------'
Security Association
Figure 3: Security Association Between Publisher and Subscriber
[TODO: Reverse proxy and cross-protocol proxies will be added in a
future version of this document.]
To identify the threats in scope, we first consider what assets need
to be protected. In general, there are the following types of assets
to protect:
A1: The devices at the two ends, the data generated and stored in
these devices, and their (often very constrained) system
resources such as available memory, storage, processing
capacity, and energy.
A2: The physical environment of the devices fitted with sensors and
actuators. Access to the physical environment is 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).
A3: The communication infrastructure linking the two devices (which
often contains some very constrained parts) and the data stored
in the message processing devices.
The scope of this document is to analyze threats executed through
proxies and brokers, and this is only directly affecting the assets
of type A3, e.g., if a proxy is dropping all messages.
However, the intermediary node may manipulate the messages exchanged
between the endpoints and thereby have an impact also on the assets
A1 and A2, for example: flooding a device with messages has impact on
its system resources, and successful manipulation of an actuator
command, carried in a message, has an impact on the physical
environment. We therefore add a fourth asset, which is the main
target being evaluated in this document:
Selander, et al. Expires September 20, 2016 [Page 5]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
A4: The messages exchanged between a client and a server, through
the proxy. This includes the CoAP header and options in request
and response messages (such as the requested method or the
target URI) and the CoAP resource representations, encapsulated
in the message payload.
A fully trusted proxy, handling unprotected messages, is an
attractive target, since proxies are aggregation points for message
flows (see Section 4) and they may be an easier target from the
Internet than the sensors/actuators residing behind them. A proxy
may become subject to intrusion or become infected by malware and
perform the attacks of a man-in-the-middle. The attack vectors for
compromising a proxy and the associated risks are out of scope for
this document.
The scope of the threat analysis is restricted to threats from
proxies to single client to server interactions. Threats resulting
from collusion between multiple proxies are also out of scope (see
Section 4).
On a high level, there are the following threats from proxies to
consider:
T1: The proxy illegitimately modifies a message.
T2: The proxy illegitimately sends a message, including replay,
flooding, etc.
T3: The proxy illegitimately inhibits sending of a message,
including delay, reordering, etc.
T4: The proxy illegitimately reads part of a message.
To assess how such threats impact the assets, we need to specify the
processing rules of the intermediary nodes in different scenarios and
define the associated security objectives.
3. Scenarios, Threats and Security Requirements
In this section we consider a set of scenarios involving proxies and
brokers, with different processing rules and security objectives. We
study the associated threats and derive the security requirements for
message transfer between client and server, in the different
scenarios.
Note that, since CoAP was not designed for end-to-end security,
solutions complying with these security requirements extend the
applicability of CoAP beyond its original scope.
Selander, et al. Expires September 20, 2016 [Page 6]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
To simplify the analysis, the scenarios are structured according to
how requests and responses are related to each other:
One Request - One Response
There is a one-to-one relation between request and response.
One Request - Multiple Responses
A request may have multiple responses, but each response is
securely linked to a unique request.
Multiple Requests - One Response
One response may serve multiple requests, but each request has a
single response.
Multiple Requests - Multiple Responses
One response may serve multiple requests, and each request may
have multiple responses.
3.1. One Request - One Response
In this scenario we study use cases where it is important that a
response sent from one endpoint is the response to a particular
request to that endpoint. Many security critical use cases require
that responses are in this way "securely linked" to requests, such as
alarm status retrieval and actuator command confirmation.
In this scenario there must be a unique response for each request.
Client Proxy Server
| | |
| Request | Request |
|-------------->|-------------->|--.
| | | |
|<--------------|<--------------|<-'
| Response | Response |
| | |
Figure 4: Message Flow with a Unique Response for Each Request
Example: Alarm status retrieval
Figure 4 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
Selander, et al. Expires September 20, 2016 [Page 7]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
particular request made by the client. Therefore the response
must be securely linked to the request.
Example: Actuation confirmation
Another example for which Figure 4 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
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.
Functional Requirement:
o Since each response is intended to be securely linked to a
particular request, the response must not be used with any other
request. Hence, as much as possible of the caching functionality
must be inhibited. Therefore the CoAP option Max-Age of the
responses is set to 0 (see Section 5.7.1 of [RFC7252]).
3.1.1. Processing Rules
In this scenario, 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.
Selander, et al. Expires September 20, 2016 [Page 8]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
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.
3.1.2. Security Objectives
In this scenario there is a unique response for each request, so the
client should be able to verify that a certain response is made in
response to a specific request sent by the client.
The server should be able to verify that the proxy only has performed
the message modifications intended by the client according to the
processing rules.
The proxy should be prevented from reading or making modifications to
messages apart from what is necessary to perform the processing rules
(cf. [RFC7258]).
The security objectives are:
SO1.1 The server is able to verify that a received request
originates from a client with which it has a security
association, and that the request has not been received
before.
SO1.2 The server is able to verify that the received request either
has not been altered in transfer, or that the request is
modified according to the processing rule PR1.1 or PR1.2
(Section 3.1.1).
SO1.3 The server is able to protect the response such that only
authorized clients can read the response.
SO1.4 The client is able to verify that the received response
originates from the requested server and resource, that it has
not been altered in transfer, and that it was generated as the
unique response to the request.
SO1.5 The proxy is only able to read data needed to perform the
processing rules.
Selander, et al. Expires September 20, 2016 [Page 9]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
3.1.3. Threat Analysis and Mitigation
We now list potential threats and discuss candidate mitigation
mechanisms.
3.1.3.1. T1:The proxy illegitimately modifies a message
T1:1.1 The proxy forwards a request with modified payload
This threat can be mitigated with integrity protection of
payload.
T1:1.2 The proxy forwards a response with modified payload
This threat can be mitigated with integrity protection of
payload.
T1:1.3 The proxy forwards a request with modified CoAP option
Note that the proxy is entitled to change certain options by
processing rules PR1.1 and PR1.2. Since the change is
predictable, the effective request URI can be integrity
protected by the client and verified by the server. The
other CoAP options in the request can be integrity protected.
T1:1.4 The proxy forwards a response with modified CoAP option
This threat can be mitigated with integrity protection of
CoAP options. Since Max-Age is set to 0 the proxy is not
entitled to change any options in the response so they can
all be integrity protected.
T1:1.5 The proxy forwards a request with changed CoAP header fields
The proxy is entitled to change certain header fields (e.g.,
the token) as part of its normal operations. Malicious
changes to message layer parameters may cause a denial-of-
service, equivalent of dropping a message or sending spoofed
messages. This is difficult to mitigate. However, changing
the CoAP header Code (e.g., from GET to DELETE) may result in
an error or wrong interpretation of the request which can
have other security implications. A change to the Version
header field may result in security errors in the interaction
between different versions of CoAP. These threats can be
mitigated by integrity protecting the Code and Version header
fields.
T1:1.6 The proxy forwards a response with changed CoAP header fields
Selander, et al. Expires September 20, 2016 [Page 10]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
Similar to previous threat. Some aspects of this threat can
be mitigated by integrity protecting the Code and Version
header fields.
T1:1.7 The proxy forwards a different request
If the forwarded request is from another client it can be
mitigated by having different security associations with
different clients. If the forwarded request is from the same
client but with differences in payload, options or header,
then this coincides with previously listed threats. A proxy
sending old requests (or reordering requests) from the same
client to the same server resource can be mitigated by
integrity protecting a freshness parameter (timestamp,
counter, etc.) from which the order of requests can be
deduced (replay/reordering protection).
T1:1.8 The proxy forwards a different response
By integrity protecting uniquely identifying information of
the request in the response, the client can verify that the
response was generated in reply to a particular request.
3.1.3.2. T2:The proxy illegitimately sends a message
T2:1.1 The proxy sends a request to the server without a previous
request from the client
This threat may be mitigated with integrity- and replay
protection.
T2:1.2 The proxy sends a response to the client without a previous
response from the server
Error messages from the proxy such as 5.02 (Bad Gateway)
originate from the proxy. A proxy maliciously sending error
messages is a denial-of-service attack similar to not
forwarding a message (T3:1.1) and is difficult to mitigate.
However, responses claiming to be from the server may be
mitigated with integrity protection uniquely identifying
information of the request.
T2:1.3 A proxy sends a number of messages for the purpose of
flooding client or server
By verifying the integrity, the client and server may
mitigate certain flooding attacks. The server can use the
replay/reordering protection to verify which messages are
Selander, et al. Expires September 20, 2016 [Page 11]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
legitimate and the client can verify if a message is a
response to a previously sent request.
3.1.3.3. T3:The proxy illegitimately inhibits sending of a message
T3:1.1 The proxy does not forward a message
This is a denial-of-service attack. While these kind of
threats may be difficult to mitigate, applications should
have a readiness for this kind of issues and a client is able
to detect a missing response.
T3:1.2 The proxy delays forwarding of a received message
Delayed forwarding may be a denial-of-service attack, similar
to not forwarding. Certain delays may be legitimate, so they
may be difficult to detect and mitigate. However, delayed
requests and responses can also be used in attacks against
actuators; see [I-D.mattsson-core-coap-actuators]. These
attacks can be performed by an on-path attacker and are not
restricted to proxies. The proposed mitigation is based on
verifying the timeliness of the request, for example, by
using time stamps or with an additional round-trip. These
mitigations can be supported by a new CoAP option containing
time stamp or binding the response in a first round-trip to a
request of the second, as specified in
[I-D.mattsson-core-coap-actuators]. By integrity protecting
that new CoAP option, the threat can be mitigated.
T3:1.3 The proxy reorders the requests
This threat may be mitigated with the server integrity
protecting a freshness parameter from which the order of
requests can be deduced.
T3:1.4 The proxy reorders the responses
This threat may be mitigated with the server integrity
protecting information specifying to which request a response
belongs.
3.1.3.4. T4:The proxy illegitimately reads part of a message
T4:1.1 The proxy reads a representation/payload
This threat can be mitigated with encryption of the payload.
Selander, et al. Expires September 20, 2016 [Page 12]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
T4:1.2 The proxy infers information about the nature and state of
the resource request/response from CoAP options
The proxy only needs to read the Uri-Host/Uri-Port and Proxy-
Uri/Proxy-Scheme options of a request. The information
revealed by these parameters is public on network layer. The
proxy only needs to read Max-Age of the response, which is
set to 0 as indicated in the functional requirements. This
threat can be mitigated by encrypting all other options.
T4:1.3 The proxy infers information about the nature and state of
the resource request/response from CoAP header fields
The header fields needs to be transferred in plain text to
allow normal CoAP operations. The Code parameter reveals
information about what RESTful action is requested. This
information leakage is difficult to mitigate.
T4:1.4 The proxy reads and stores all message exchanges and can
deduce information about the entire history of the
corresponding interactions
This threat can be mitigated with encrypting as much as
possible of the data transferred between client and server.
The case of long term key compromise can be mitigated with
forward secrecy.
3.1.4. Security Requirements
This section contains the security requirements and non-requirements
for this scenario. For each requirement and non-requirement the
associated threats are listed. The security requirements are:
R1.1 The server must authenticate a message coming from a
requesting client (T1:1.1, T1:1.3, T1:1.5, T2:1.1).
R1.2 The server must verify that it has not received this request
previously (T1:1.7, T3:1.3).
R1.3 The client must verify that the received response originates
from the requested server (T1:1.2, T1:1.4, T1:1.6, T2:1.2).
R1.4 The client must verify that a response corresponds uniquely to
a previous request that the client has made (T1:1.8, T3:1.4).
R1.5 The payload must be integrity protected and encrypted between
client and server (T1:1.1-6,T4:1.1, T2:1.3, T4:1.1,
[RFC7258]).
Selander, et al. Expires September 20, 2016 [Page 13]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
R1.6 The CoAP options except Uri-* and Proxy-* must be integrity
protected in the request. The effective request URI must be
integrity protected in the request (T1:1.3).
R1.7 All CoAP options in the response must be integrity protected.
Max-Age must be set to 0 (T1:1.4).
R1.8 The CoAP options Uri-Host/Port and Proxy-Uri/Scheme of the
request must not be encrypted. The Max-Age option of the
response must not be encrypted. All other options must be
encrypted (T4:1.2).
R1.9 The CoAP header fields Version and Code must be integrity
protected in requests and responses. All other header fields
must not be integrity protected. The header fields must not
be encrypted (T1:1.5, T4:1.3).
R1.10 The communication protocol must provide forward secrecy
(T4:1.4).
The security non-requirements of this scenario are:
NR1.1 The proxy may drop messages without the endpoint being able to
infer that the message is lost due to the proxy (T3:1.1).
NR1.2 The proxy may delay messages without being detected (T3:1.1,
T3:1.2).
NR1.3 The proxy may read the CoAP header including message layer
parameters and Code, revealing the kind of RESTful action
being requested and the response code (T4:1.3).
3.2. One Request - Multiple Responses
In this scenario we study use cases where it is important that a
response is securely linked to a request as in the previous scenario,
but where there may be multiple responses for each request. This
functionality protects communication-constrained servers from
repeated requests from the same client and thus saves system
resources and bandwidth. This is useful in security critical
monitoring scenarios where time synchronization cannot be guaranteed.
Selander, et al. Expires September 20, 2016 [Page 14]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
Client Proxy Server
| | |
| Request | Request |
|-------------->|-------------->|--.
| | | |
|<--------------|<--------------|<-'
| Notification | Notification |
| | |
|<--------------|<--------------|
| Notification | Notification |
| | |
|<--------------|<--------------|
| Notification | Notification |
| | |
Figure 5: Message Flow of a Notification
Example: Secure parameter monitoring
Figure 5 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, thereby providing updates to the
parameter in regular time intervals.
The client wants to ensure that 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.
Functional Requirement:
o The same functional requirement apply as in the previous scenario
(Section 3.1).
3.2.1. Processing Rules
The processing rules are identical to PR 1.1 - 1.3 of the previous
scenario (Section 3.1.1).
Selander, et al. Expires September 20, 2016 [Page 15]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
3.2.2. Security Objectives
The security objectives are similar to the previous scenario. Each
response maps to a unique request, but there may be multiple
responses to one request. By ordering the responses, each message in
this exchange can be made unique.
The security objectives of the previous scenario (Section 3.1.2) are
valid except for SO1.4 which is replaced by the following objectives:
SO2.1 The client is able to verify that the received response
originates from the requested server and resource, that it has
not been altered in transfer, and that it was generated as one
in a sequence of responses to the request.
SO2.2 The client is able to verify the order of the responses and if
a response is missing.
3.2.3. Threat Analysis and Mitigation
The threat analysis from the previous scenario carries over with a
few exceptions.
3.2.3.1. T1:The proxy illegitimately modifies a message
Similar conclusions apply as in the previous scenario
(Section 3.1.3.1). However, note that in T1:1.8, a proxy may
maliciously reorder the responses to the same request without being
detected. The mitigation specified in the previous scenario (that
the client verifies the response is linked to the request) is not
sufficient since there may be multiple responses.
However, analogous to how requests are protected against replay/
reordering in the previous scenario, by additionally integrity
protecting a parameter from which the order of responses can be
deduced, this threat can be mitigated.
3.2.3.2. T2:The proxy illegitimately sends a message
Similar conclusions apply as in the previous scenario
(Section 3.1.3.2). T2:1.3 can be mitigated with the additional
replay/reordering protection of responses as mentioned in
Section 3.2.3.1.
Selander, et al. Expires September 20, 2016 [Page 16]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
3.2.3.3. T3:The proxy illegitimately inhibits sending of a message
Similar conclusions apply as in the previous scenario
(Section 3.1.3.3). T3:1.4 can be mitigated with the additional
replay/reordering protection of responses as mentioned in
Section 3.2.3.1.
3.2.3.4. T4:The proxy illegitimately reads part of a message
The same conclusions apply as in the previous scenario
(Section 3.1.3.4).
3.2.4. Security Requirements
The security requirements of the previous scenario (Section 3.1.4)
are valid except for R1.4 which is replaced by the following
requirements:
R2.1 The client must verify that a response corresponds to a
previous request that the client has made (T1:1.8, T3:1.4).
R2.2 The client must verify that it has not received this response
previously and whether responses for the same request are
received in the wrong order (T1:1.8, T3:1.3).
3.3. Multiple Requests - One Response
In this scenario 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.
Selander, et al. Expires September 20, 2016 [Page 17]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
Client A Proxy Server
| | |
| Request | Request |
|-------------->|-------------->|--.
| | | |
|<--------------|<--------------|<-'
| Response | Response |
| | |
| |
Client B | |
| | |
| Request | |
|-------------->|--. |
| | | from cache |
|<--------------|<-' |
| Response | |
| | |
Figure 6: Message Flow for Cached Responses
In Figure 6, 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.
Cacheable responses are 2.05 (Content) responses and all error
responses.
Functional Requirements:
o The proxy must be able to store cacheable responses in a cache.
This requires the proxy to read the CoAP header, options, and
payload and to compute the cache key for a request.
o The proxy must be able to return a fresh response from its cache
without contacting the server.
o The proxy must be able to perform validation on a request by a
client and a request validation to the server (see Section 5.6.2
of [RFC7252]).
Selander, et al. Expires September 20, 2016 [Page 18]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
3.3.1. Processing Rules
The proxy complies with the forwarding rules PR1.1 - 1.3
(Section 3.1.1) and the rules below. The rules below have priority.
PR3.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.
PR3.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.
PR3.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.
PR3.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.
PR3.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.
3.3.2. Security Objectives
A caching proxy has an active role in the resource request/response
procedure, so it is not surprising that it is necessary to make a
trade-off between caching functionality and the protection of client-
server interaction. Comparing with the scenario in Section 3.1, most
of the security objectives in Section 3.1.2 cannot be met:
o The caching functionality decouples responses from requests. This
implies that a client is not able to verify that a received
response is generated by the server in response to a specific
request.
o A client may receive a response without the server being aware
that the client has made a request. A proxy could proactively
generate requests or observe resources in order to keep the cache
Selander, et al. Expires September 20, 2016 [Page 19]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
up-to-date. Thus the server cannot in general verify that a
request originates from a client as a precondition to provide a
response.
Since a proxy can autonomously make requests for resource
representations and there is no security association between proxy
and server, the server cannot verify those requests. If a request
needs to be verified then the solution to the scenario in Section 3.1
can be re-used. Therefore we do not consider the protection of
requests and focus here on enabling the caching functionality and
providing security to cacheable resource representations.
The security objectives for this scenario are:
SO3.1 The client is able to verify that a received response contains
a resource representation to a requested server and resource,
and that it has not been altered between server and client.
SO3.2 The client is able to verify that a received resource
representation is fresh.
SO3.3 The server is able to protect a resource representation such
that only authorized clients can read the representation.
3.3.3. Threat Analysis and Mitigation
We now list potential threats and discuss candidate mitigation
mechanisms.
3.3.3.1. T1:The proxy illegitimately modifies a message
T1:3.1 The proxy forwards a request with modified payload
Out of scope of the security objectives.
T1:3.2 The proxy forwards a response with modified payload
This threat that may be mitigated with integrity protection
of resource representation.
T1:3.3 The proxy forwards a request with modified CoAP options
Out of scope of the security objectives.
T1:3.4 The proxy forwards a response with modified CoAP options
This is not necessarily a threat. For example, a proxy is
entitled to change Max-Age. However, changing Content-
Selander, et al. Expires September 20, 2016 [Page 20]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
Format may result in an error or the wrong interpretation of
a representation. That kind of threat may be mitigated by
securely associating resource information (such as Content-
Format) to the representation in the response.
T1:3.5 The proxy forwards a request with changed CoAP header fields
As mentioned in Section 3.1, this is not necessarily a
threat and it is not in scope of the security objectives to
mitigate.
T1:3.6 The proxy forwards a response with changed CoAP header
fields
This is not necessarily a threat, since message layer
parameters may be changed by a proxy. A change of Code in
the response may be misinterpreted. But as long as the
responses allow verification of resource information, such a
change will be detected. Thus this threat is mainly a
denial-of-service. Threats arising from modification of
Version are difficult to predict. A future version of CoAP
must consider security implications of a proxy manipulating
the version number.
T1:3.7 The proxy forwards a request different from the translated
request
Out of scope of the security objectives.
T1:3.8 The proxy forwards a response to a non-equivalent request
If the response is from another server, then it can be
mitigated by having different security associations with
different servers. If the response is that of another
resource of the same server, it can be mitigated by having
different security associations of different resources, or
by securely associating a resource identifier to the
representation in the response. If the response is from the
right server and resource, then the modifications of
payload, options and header are considered previously.
T1:3.9 The proxy forwards an old response to the same resource
This is not necessarily a threat. The proxy is supposed to
send a cached response, if fresh. However, if the proxy
serves a stale response and manipulates the Max-Age option,
then it may trick the client into believing that this is a
fresh response. Since the proxy is entitled to make such
Selander, et al. Expires September 20, 2016 [Page 21]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
changes, this is not possible to prevent. The server may
however provide other freshness information (timestamp,
counter, etc.) integrity protected together with the
resource representation and associated resource information
from which the client may infer that Max-Age is not correct.
Note that in case time synchronization cannot be assumed the
information about age is limited to the order of the
responses.
T1:3.10 The proxy maliciously serves a 2.03 (Valid) response to a
request with an ETag option
This is not possible to prevent, since the proxy is entitled
to perform such operation without involving the server.
[TODO: Since the response must not include a payload (see
Section 5.9.1.3 of RFC 7252), it is not clear how a server
could enforce the proxy to include any integrity protected
freshness information unless we define new proxy processing
rules.]
T1:3.11 The proxy colludes with a legitimate client having access to
the key used to generate and verify Message Authentication
Codes (MAC) of responses/resource representations to
generate a valid MAC.
This threat applies to responses containing a message
authentication code (MAC) for integrity protecting the
resource representation. The threat may be mitigated by the
server digitally signing the representation with its private
key instead of using a MAC.
3.3.3.2. T2:The proxy illegitimately sends a message
T2:3.1 The proxy sends a request to the server without a previous
request from the client
This is not necessarily a threat, since the proxy may want to
keep the cache updated with fresh representations to allow
short round-trip time. A proxy maliciously making requests
for the purpose of gaining information about the resources
may to some extent be mitigated by encryption, but encrypting
data in the cache key has an impact on how the cache can
perform its legitimate operation. This is out of scope for
the security objectives.
T2:3.2 The proxy sends a response to the client without a previous
response from the server
Selander, et al. Expires September 20, 2016 [Page 22]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
This is not necessarily a threat, since the proxy is allowed
to respond with a fresh, cached response. Other cases of
responding inappropriately to a client request are covered in
the previous section. The client can detect the case of
receiving a response without having sent a request.
T2:3.3 A proxy sends a number of messages for the purpose of
flooding client or server
Considering that a proxy is entitled to make resource
requests, it may be difficult to protect the server against
this kind of denial-of-service attacks. As for responses, by
verifying the integrity and freshness of requested
information, the client may mitigate certain flooding
attacks.
3.3.3.3. T3:The proxy illegitimately inhibits sending of a message
T3:3.1 The proxy does not forward a message
This is not necessarily a threat. According to the
processing rule, the proxy must not forward a request if
there is a fresh cached response. If the proxy does not
forward a request although there is no valid cache response
or if the proxy does not propagate a response, then this is a
denial-of-service attack. While these threats may be
difficult to mitigate, missing messages are common in lossy
environments so applications should be prepared for this kind
of issue.
T3:3.2 The proxy delays forwarding of a received message
Delayed forwarding may be a denial-of-service attack, similar
to not forwarding. Certain delays may be legitimate, so it
is difficult to detect and mitigate this. Delayed requests
and responses can also be used in attacks against actuators
as is discussed in Section 3.1, but that is out of scope for
this scenario.
T3:3.3 The proxy reorders the requests
Out of scope of the security objectives.
T3:3.4 The proxy reorders the responses
This threat may be mitigated with the server integrity
protecting a freshness parameter together with the response.
Selander, et al. Expires September 20, 2016 [Page 23]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
3.3.3.4. T4:The proxy illegitimately reads part of a message
T4:3.1 The proxy reads a representation/payload
This threat can be mitigated with encryption of the
representation, and other potential payload data.
T4:3.2 The proxy infers information about the nature and state of
the resource request/response from CoAP options and header
fields.
The proxy needs to read the cache key for performing caching
operations. Information leaking that can be inferred from
such data cannot be prevented.
T4:3.3 The proxy reads and stores all message exchanges and can
deduce information about the entire history of resource
access.
Since the cache key and other metadata is not in scope of the
security objectives, the mitigation is restricted to
encrypting the resource representations. The case of long
term key compromise would nevertheless reveal the history of
the resource, but this can be mitigated with forward secrecy.
3.3.4. Security Requirements
This section contains the security requirements and non-requirements
for the caching scenario. For each requirement and non-requirement
the associated threats are listed. The security requirements are:
R3.1 The client must be able to verify that a received resource
representation originates from the requested server (T1:3.2,
T1:3.8).
R3.2 The client must be able to verify that a received
representation is a representation of the resource requested by
the client (T1:3.2, T1:3.4, T1:3.8).
R3.3 The client must be able to verify the content format of the
representation (T1:3.4).
R3.4 The client must be able to detect that a received
representation is fresh (T1:3.9, T3:3.4).
R3.5 The representation must be integrity protected and encrypted
from the server to the client (T1:3.2, T1:3.11, T2:3.3,
T4:3.1).
Selander, et al. Expires September 20, 2016 [Page 24]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
R3.6 To protect against the proxy colluding with an authorized
client, asymmetric cryptography must be used (T1:3.11).
R3.7 The communication protocol must provide forward secrecy
(T4:3.3).
The security non-requirements of the caching scenario are:
NR3.1 The request is not protected (see Security Objectives).
NR3.2 The header and options of the response are not protected (see
Security Objectives, compare R3.3).
NR3.3 The proxy may eavesdrop on metadata (including the cache key)
or by making requests on behalf of alleged clients (T2:3.1,
T4:3.2).
NR3.4 The proxy may drop messages without the endpoint being able to
infer that the message is lost due to the proxy (T3:3.1).
NR3.5 The proxy may delay messages without being detected (T3:3.2).
NR3.6 The client may not be able to verify validity information
provided by proxy when using ETag (T1:3.10).
3.4. Multiple Requests - Multiple Responses: Observe
This scenario is about replicating a resource state from a server to
a client. The client observes a resource and receives notifications
which may be cached. The difference compared to the previous
scenario (Section 3.3) is the capability to send multiple responses
in reply to a single request. The difference compared to Section 3.2
is that in this scenario multiple clients may be served with the same
response.
This functionality protects communication-constrained servers from
repeated requests, which may come from different clients, when the
resource is unchanged. This saves system resources and bandwidth.
In addition to multiple clients' requests being served by one
response, each request may result in multiple responses.
Selander, et al. Expires September 20, 2016 [Page 25]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
Client A Proxy Server
| | |
| Request | Request |
|-------------->|-------------->|--.
| | | |
|<--------------|<--------------|<-'
| Notification | Notification |
| | |
| |
Client B | |
| | |
| Request | |
|-------------->|--. |
| | | from cache |
|<--------------|<-' |
| Notification | |
| | |
|<--------------|<--------------|
| Notification | Notification |
| | |
| |
Client A | |
| | |
|<--------------| |
| Notification | |
| | |
Figure 7: Message Flow for Observe with Multiple Observers
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.
Functional Requirements:
The functional requirements of the previous scenario (Section 3.3)
apply, and additionally:
o The proxy must be able to observe a resource on behalf of one or
more clients.
Selander, et al. Expires September 20, 2016 [Page 26]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
o When a client registers interest in a resource with the proxy, the
proxy must be able to return a response containing the current
state of the resource without contacting the server.
3.4.1. Processing Rules
The proxy complies with the processing rules PR3.1 - 3.5 of the
previous scenario (Section 3.3.1). In addition, the following
processing rules apply:
PR4.1 If the proxy receives a notification from the server that is
out of sequence (as indicated by the Observe option), then the
proxy discards the notification. Otherwise, the proxy
proceeds to notify the registered observers.
PR4.2 When notifying an observer, the proxy modifies the Observe
option to indicate the sequence of notifications from the
proxy to the observer.
3.4.2. Security Objectives
The security objectives are identical to the previous scenario.
3.4.3. Threat Analysis and Mitigation
The threat analysis from the previous scenario carries over to this
scenario.
3.4.3.1. T1:The proxy illegitimately modifies a message
The same conclusions apply as in the previous scenario
(Section 3.3.3.1). For example in T1:3.4, a proxy may maliciously
modify the Observe option to indicate a different order of
notifications without being detected. However, the mitigation
specified in the previous scenario applies: the server integrity
protects a freshness parameter with the response.
3.4.3.2. T2:The proxy illegitimately sends a message
The same conclusions apply as in the previous scenario
(Section 3.3.3.2).
3.4.3.3. T3:The proxy illegitimately inhibits sending of a message
The same conclusions apply as in the previous scenario
(Section 3.3.3.3). The threat in T3:3.4 may be combined with
manipulation of the Observe option, but the same mitigation as
mentioned in (Section 3.4.3.1) applies.
Selander, et al. Expires September 20, 2016 [Page 27]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
3.4.3.4. T4:The proxy illegitimately reads part of a message
The same conclusions apply as in the previous scenario
(Section 3.3.3.4).
3.4.4. Security Requirements
Since the security objectives and threat mitigations carry over from
the previous scenario (Section 3.3), the same security requirements
are valid (Section 3.3.4).
3.5. Multiple Requests - Multiple Responses: Publish-Subscribe
The intermediary node in the publish-subscribe scenario is a broker
for messages from a publisher to subscriber. A subscriber subscribes
to a "topic" and receives a publication. The broker fans out
subsequent publications on that topic to all subscribers.
In this scenario a single request may result in multiple responses
and a single response may reach multiple clients.
Selander, et al. Expires September 20, 2016 [Page 28]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
Publisher Broker Subscriber
(Client) (Server) (Client A)
| | |
| Publish | |
|-------------->|--. |
| | | to store |
|<--------------|--' |
| | |
| | Subscribe |
| .--|<--------------|
| from store | | |
| '->|-------------->|
| | Notification |
| |
| | (Client B)
| | |
| | Subscribe |
| .--|<--------------|
| from store | | |
| '->|-------------->|
| | Notification |
| | |
| Publish | |
|-------------->|--. |
| | | to store |
|<--------------|--' |
| | |
| |-------------->|
| | Notification |
| |
| | (Client A)
| | |
| |-------------->|
| | Notification |
| | |
Figure 8: Message Flow for Publish-Subscribe
The broker maintains a number of topics that a publisher can publish
to and a subscriber subscribe to. Topics are represented as URIs at
the broker. Figure 8 illustrates the publication to a topic,
implemented as a PUT request of a representation to a resource at the
broker.
Subscribers can make a GET request with the Observe option to the
topic URI at the broker in order to initiate the subscription on the
topic. The broker provides a notification in the form of a stored
representation as response to the request. Further publications of
Selander, et al. Expires September 20, 2016 [Page 29]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
representations to this URI are provided as notification responses to
the subscription request.
Functional Requirement:
o The publication must be able to be transferred in a PUT request
from the publisher and in a GET response to the subscriber.
3.5.1. Processing Rules
PR5.1 If the broker receives a subscription request to one of its
resources, then the broker associates the requesting
subscriber to the topic and responds with the current
representation.
PR5.2 If the broker receives a publication request to one of its
resources, then the broker stores the received representation
on the topic and responds with the representation to the
associated subscribers of that topic.
Since we are focusing on end-to-end security between publisher and
subscriber, the creation and deletion of topics and other endpoint-
to-broker operations are out of scope.
3.5.2. Security Objectives
The security objectives for this scenario are:
SO5.1 A subscriber is able to verify that a received response
contains a resource representation of a requested topic, that
the publisher is authorized to publish to that topic, and that
it has not been altered between publisher and subscriber.
SO5.2 A subscriber is able to verify that a received resource
representation is fresh.
SO5.3 The publisher is able to protect a resource representation
such that only authorized subscribers can read the
representation.
3.5.3. Threat Analysis and Mitigation
We now analyze the potential threats relevant to this scenario.
Selander, et al. Expires September 20, 2016 [Page 30]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
3.5.3.1. T1:The broker illegitimately modifies a message
T1:5.1 The broker responds to a subscriber request with a
publication containing a modified payload
This threat may be mitigated with integrity protection of
payload.
T1:5.2 The broker responds to a subscriber request with a
publication containing a modified CoAP option
Since the security objective is to protect the resource
representation, only options in the GET response that
influence the interpretation of the resource representations
have an impact. A broker is entitled to change Max-Age and
may do so maliciously. The broker is not entitled to change
Content-Format, but may anyway do so maliciously. To
mitigate these, the subscriber needs to be able to verify
information about freshness and content format provided by
the publisher.
T1:5.3 The broker responds to a subscriber request with modified
CoAP header fields
Since the security objective is to protect the resource
representation, only header fields in the GET response that
influence the interpretation of the resource representations
have an impact. Changing of Code such as e.g. 2.05 (Content)
to some error code is a denial-of-service.
T1:5.4 The broker modifies the publication before or during storage
This threat is analogous to the previous threats and is
mitigated in the same way.
T1:5.5 The broker responds to a subscriber request with the wrong
message
Modifications of payload, options, and header are considered
previously. To mitigate wrong a interpretation of a response
resulting from a broker sending old messages or reordering
messages from the same publisher to the same subscriber, the
message may integrity protect a freshness parameter
(timestamp, counter, etc.) from which the age/order can be
deduced (replay/reordering protection).
T1:5.6 The broker colludes with a legitimate subscriber having
access to the key used to create Message Authentication Codes
Selander, et al. Expires September 20, 2016 [Page 31]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
(MAC) of publications in order to generate a valid MAC of a
modified publication
This threat applies to publications containing a message
authentication code (MAC) for integrity protecting the
resource representation. The threat may be mitigated by the
publisher digitally signing the representation with a private
key instead of using a MAC.
3.5.3.2. T2:The broker illegitimately sends a message
T2:5.1 The broker sends a response to a subscriber request without a
previous publication from the publisher
Most cases of responding inappropriately to a subscriber
request are covered in the previous section. In general,
authentication of publisher in combination with replay/
reordering protection will mitigate this threat.
T2:5.2 A broker sends a number of messages for the purpose of
flooding the subscriber
By verifying the integrity and freshness information, the
subscriber may mitigate certain flooding attacks.
3.5.3.3. T3:The broker illegitimately inhibits sending of a message
T3:5.1 The broker does not store or forward a publication
This is a denial-of-service attack. While these threats may
be difficult to mitigate, missing messages are common in
lossy environments so applications should have a readiness
for this kind of issue.
T3:5.2 The broker does not respond to a publication request
This may be a denial-of-service attack on the publisher.
While such a threat may be difficult to mitigate, missing
messages are common in lossy environments so applications
should have a readiness for this kind of issue.
T3:5.3 The broker delays forwarding of a received publication
Delayed forwarding may be a denial-of-service attack, similar
to not forwarding. Certain delays may be legitimate, so it
may be difficult to detect and mitigate.
T3:5.4 The broker reorders the publications
Selander, et al. Expires September 20, 2016 [Page 32]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
This threat may be mitigated by the publisher integrity
protecting the message and including a freshness parameter.
3.5.3.4. T4:The broker illegitimately reads part of a message
T4:5.1 The broker reads a representation/payload
This threat can be mitigated with encryption of the
representation and other potential payload data
T4:5.2 The broker infers information about the nature and state of
the publication from CoAP options and header fields.
This metadata is not in scope of confidentiality.
Information leaking that can be inferred from such data
cannot be prevented.
T4:5.3 The broker reads and stores all publications and can deduce
information about the entire history of the publications and
subscriptions
Since the protection of metadata related to subscription and
publication is not in scope of the security objectives, the
mitigation is restricted to encrypting the resource
representations. The case of long term key compromise would
nevertheless reveal the history of a publication, but this
can be mitigated with forward secrecy.
3.5.4. Security Requirements
This section contains the security requirements and non-requirements
for the publish-subscribe scenario. For each requirement and non-
requirement the associated threats are listed. The security
requirements are:
R5.1 The subscriber must be able to verify that a received resource
representation originates from an authorized publisher (T1:5.1,
T2:5.1).
R5.2 The subscriber must be able to verify that a received
representation is a representation of the resource requested by
the subscriber (T1:5.1, T1:5.4, T1:5.5, T1:5.6).
R5.3 The subscriber must be able to verify the content format of the
representation (T1:5.2)
Selander, et al. Expires September 20, 2016 [Page 33]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
R5.4 The subscriber must be able to detect that the received
resource representation is older than a previously received
representation of this resource (T1:5.5, T2:5.1, T3:5.4).
R5.5 The representation must be integrity protected and encrypted
from publisher to subscriber (T1:5.1, T1:5.5, T2:5.2, T4:5.1).
R5.6 To protect against the proxy colluding with an authorized
subscriber, asymmetric cryptography must be used (T1:5.6).
R5.7 The communication protocol must provide forward secrecy
(T4:5.3).
The security non-requirements of the pub-sub scenario are:
NR5.1 The subscription request is not protected (see Security
Objectives).
NR5.2 The header and options of the notification response are not
protected (see Security Objectives, compare R5.3).
NR5.3 The broker may change and eavesdrop on certain metadata
without being detected (T1:5.2, T1:5.3, T4:5.2).
NR5.4 The broker may drop messages without being detected (T3:5.1,
T3:5.2).
NR5.5 The broker may delay messages without being detected (T3:5.3).
4. Security Considerations
A proxy or intermediary may be an aggregation point for message
flows. Therefore it is an attractive target, both from a security
and privacy point of view.
Unless the security mechanisms provide forward secrecy, a compromise
of long term keying material means that an attacker can decrypt all
previously sent information and can be directly used for any kind of
manipulation of the cyber-physical system.
Therefore the key exchange mechanism used for establish keys to use
with application layer security must provide forward secrecy.
Intermediary nodes are aggregation points also for metadata and
therefore valuable targets for signal intelligence agencies.
Pervasive monitoring is an attack [RFC7258] and the effect of
collecting and correlating information from multitude of proxies must
be mitigated.
Selander, et al. Expires September 20, 2016 [Page 34]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
Related to this, it is needed to delete all historical information
from all nodes handling the plaintext data and metadata, in order to
avoid information leakage. The impact of this on the intermediary
nodes can be limited by confidentiality protecting as much as
possible between the endpoints.
5. IANA Considerations
This document includes no request to IANA.
6. References
6.1. Normative References
[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>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[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 Encoded Message Syntax", draft-ietf-
cose-msg-10 (work in progress), February 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-00 (work in progress),
October 2015.
Selander, et al. Expires September 20, 2016 [Page 35]
Internet-Draft Requirements for CoAP End-To-End Security 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>.
Acknowledgments
The authors wish to thank John Mattsson and Ari Keranen for reviewing
early versions of the draft.
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 September 20, 2016 [Page 36]
Internet-Draft Requirements for CoAP End-To-End Security March 2016
Ludwig Seitz
SICS Swedish ICT AB
Scheelevaegen 17
Lund 223 70
Sweden
Email: ludwig@sics.se
Selander, et al. Expires September 20, 2016 [Page 37]