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, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . 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, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . 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]