idnits 2.17.1 draft-hartke-core-e2e-security-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (January 6, 2017) is 2666 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-00 == Outdated reference: A later version (-06) exists of draft-mattsson-core-coap-actuators-02 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group G. Selander 3 Internet-Draft F. Palombini 4 Intended status: Informational Ericsson AB 5 Expires: July 10, 2017 K. Hartke 6 Universitaet Bremen TZI 7 January 6, 2017 9 Requirements for CoAP End-To-End Security 10 draft-hartke-core-e2e-security-reqs-02 12 Abstract 14 This document analyses threats to CoAP message exchanges traversing 15 proxies and derives the security requirements for mitigating those 16 threats. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 10, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Assets and Scope . . . . . . . . . . . . . . . . . . . . 4 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1. Threats and Security Requirements . . . . . . . . . . . . 7 57 2.1.1. Client-side . . . . . . . . . . . . . . . . . . . . . 7 58 2.1.1.1. Threat 1: Spoofing . . . . . . . . . . . . . . . 8 59 2.1.1.2. Threat 2: Delaying . . . . . . . . . . . . . . . 9 60 2.1.1.3. Threat 3: Withholding . . . . . . . . . . . . . . 9 61 2.1.1.4. Threat 4: Flooding . . . . . . . . . . . . . . . 9 62 2.1.1.5. Threat 5: Eavesdropping . . . . . . . . . . . . . 9 63 2.1.1.6. Threat 6: Traffic Analysis . . . . . . . . . . . 9 64 2.1.2. Server-side . . . . . . . . . . . . . . . . . . . . . 11 65 2.1.2.1. Threat 1: Spoofing . . . . . . . . . . . . . . . 12 66 2.1.2.2. Threat 2: Delaying . . . . . . . . . . . . . . . 12 67 2.1.2.3. Threat 3: Withholding . . . . . . . . . . . . . . 12 68 2.1.2.4. Threat 4: Flooding . . . . . . . . . . . . . . . 12 69 2.1.2.5. Threat 5: Eavesdropping . . . . . . . . . . . . . 13 70 2.1.2.6. Threat 6: Traffic Analysis . . . . . . . . . . . 13 71 2.2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . 14 72 2.2.1. Forwarding . . . . . . . . . . . . . . . . . . . . . 15 73 2.2.1.1. Examples . . . . . . . . . . . . . . . . . . . . 15 74 2.2.1.2. Functional Requirements . . . . . . . . . . . . . 17 75 2.2.1.3. Processing Rules . . . . . . . . . . . . . . . . 17 76 2.2.1.4. Authenticity . . . . . . . . . . . . . . . . . . 17 77 2.2.1.5. Confidentiality . . . . . . . . . . . . . . . . . 19 78 2.2.2. Caching . . . . . . . . . . . . . . . . . . . . . . . 19 79 2.2.2.1. Examples . . . . . . . . . . . . . . . . . . . . 19 80 2.2.2.2. Functional Requirements . . . . . . . . . . . . . 21 81 2.2.2.3. Processing Rules . . . . . . . . . . . . . . . . 21 82 2.2.2.4. Authenticity . . . . . . . . . . . . . . . . . . 22 83 2.2.2.5. Confidentiality . . . . . . . . . . . . . . . . . 23 84 3. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . 24 85 3.1. Threats and Security Requirements . . . . . . . . . . . . 24 86 3.1.1. Subscriber-side . . . . . . . . . . . . . . . . . . . 24 87 3.1.1.1. Threat 1: Spoofing . . . . . . . . . . . . . . . 26 88 3.1.1.2. Threat 2: Delaying . . . . . . . . . . . . . . . 27 89 3.1.1.3. Threat 3: Withholding . . . . . . . . . . . . . . 27 90 3.1.1.4. Threat 4: Flooding . . . . . . . . . . . . . . . 27 91 3.1.1.5. Threat 5: Eavesdropping . . . . . . . . . . . . . 27 92 3.1.1.6. Threat 6: Traffic Analysis . . . . . . . . . . . 27 93 3.1.2. Publisher-side . . . . . . . . . . . . . . . . . . . 27 94 3.2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . 28 95 3.2.1. Brokering . . . . . . . . . . . . . . . . . . . . . . 28 96 3.2.1.1. Functional Requirements . . . . . . . . . . . . . 30 97 3.2.1.2. Processing Rules . . . . . . . . . . . . . . . . 30 98 3.2.1.3. Authenticity . . . . . . . . . . . . . . . . . . 30 99 3.2.1.4. Confidentiality . . . . . . . . . . . . . . . . . 30 100 4. Security Considerations . . . . . . . . . . . . . . . . . . . 30 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 102 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 6.1. Normative References . . . . . . . . . . . . . . . . . . 31 104 6.2. Informative References . . . . . . . . . . . . . . . . . 31 105 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 108 1. Introduction 110 The Constrained Application Protocol (CoAP) [RFC7252] is a Web 111 application protocol designed for constrained nodes and networks 112 [RFC7228]. CoAP makes use of Datagram Transport Layer Security 113 (DTLS) [RFC6347] for security. At the same time, CoAP relies on 114 proxies for scalability and efficiency. Proxies reduce response time 115 and network bandwidth use by serving responses from a shared cache or 116 enable clients to make requests that these otherwise could not make. 118 CoAP proxies need to perform a number of operations on requests and 119 responses to fulfill their purpose, which requires the DTLS security 120 associations to be terminated at each proxy. The proxies therefore 121 do not only have access to the data required for performing the 122 desired functionality, but are also able to eavesdrop on or 123 manipulate any part of the CoAP payload and metadata exchanged 124 between client and server, or inject new CoAP messages without being 125 protected or detected by DTLS. 127 __________ _________ _________ __________ 128 | | | | | | | | 129 | |---->| |---->| |---->| | 130 | Client | | Proxy | | Proxy | | Server | 131 | |<----| |<----| |<----| | 132 |__________| |_________| |_________| |__________| 133 : : : : : : 134 '-------------' '-----------' '-------------' 135 Security Security Security 136 Association Association Association 137 A B C 139 Figure 1: Hop-by-Hop Security 141 One way to mitigate this threat is to secure CoAP communication at 142 the application layer using an object-based security mechanism such 143 as CBOR Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] 144 instead of or in addition to the security mechanisms at the network 145 layer or transport layer. Such a mechanism can provide "end-to-end 146 security" at the application layer (Figure 2) in contrast to the 147 "hop-by-hop security" that DTLS provides (Figure 1). 149 __________ _________ _________ __________ 150 | | | | | | | | 151 | |---->| |---->| |---->| | 152 | Client | | Proxy | | Proxy | | Server | 153 | |<----| |<----| |<----| | 154 |__________| |_________| |_________| |__________| 155 : : 156 '-----------------------------------------------' 157 Security Association 159 Figure 2: End-to-End Security 161 This document analyses security aspects of sensor and actuator 162 communications over CoAP that involve proxies (Section 2) and 163 publish-subscribe brokers (Section 3). The analysis is based on the 164 identification of assets associated with these communications and 165 considering the potential threats posed by proxies to these assets. 166 The threat analysis provides the basis for deriving security 167 requirements that a solution for CoAP end-to-end security should 168 meet. 170 1.1. Assets and Scope 172 In general, there are the following assets that need to be protected: 174 o The devices at the two ends and their (often very constrained) 175 system resources such as available memory, storage, processing 176 power and energy. 178 o The physical environment of the devices fitted with sensors and 179 actuators. Access to the physical environment is assumed to be 180 provided through CoAP resources that allow a remote entity to 181 retrieve information about the physical environment (such as the 182 current temperature) or to produce an effect on the physical 183 environment (such as the activation of a heater). 185 o The communication infrastructure linking the two devices, which 186 often contains some very constrained networks. 188 o The data generated and stored in the involved devices. 190 An intermediary can directly interfere with the interactions between 191 the two ends and thereby have an impact on all these assets. For 192 example, flooding a device with messages has an impact on system 193 resources, and the successful manipulation of an actuator command 194 (data generated by an involved device) can have a severe impact on 195 the physical environment. An intermediary can also affect the 196 communication infrastructure, e.g., by dropping messages. 198 Even if an intermediary is trustworthy, it may be an attractive 199 target for an attack, since such nodes are aggregation points for 200 message flows and may be an easier target from the Internet than the 201 sensor and actuator nodes residing behind them. An intermediary may 202 become subject to intrusion or be infected by malware and perform the 203 attacks of a man-in-the-middle. 205 The focus of this document is on threats from intermediaries to 206 interactions between two CoAP endpoints. Other types of threats, for 207 example, attacks involving physical access to the CoAP-speaking 208 devices, are out of scope of this document. 210 Since intermediaries may perform a service for the interacting 211 endpoints, there is a trade-off between the intermediaries' desired 212 functionality and the ability to mitigate threats to the endpoints 213 executed through an intermediary. 215 1.2. Terminology 217 Readers are expected to be familiar with the terms and concepts 218 described in [RFC7252] and [RFC7641]. 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 222 "OPTIONAL" in this document are to be interpreted as described in 223 [RFC2119]. The key word "NOT REQUIRED" is interpreted as synonymous 224 with the key word "OPTIONAL". 226 2. Proxying 228 To assess what impact various threats have to the assets, we need to 229 specify and analyse how the proxies operate. 231 _ _ __ ___________ __ _ _ 232 | Request | | Request | 233 Client |---------->| |---------->| Server 234 or | | Proxy | | or 235 Proxy |<----------| |<----------| Proxy 236 _ _ __| Response |___________| Response |__ _ _ 238 Figure 3: A Proxy 240 Generally speaking, the functionality of a proxy is to receive a 241 request from a client and to send a response back to that client. 242 There are two ways for the proxy to satisfy the request: 244 o The proxy constructs and sends a request to the server indicated 245 in the client's request, receives a response from that server and 246 uses the received data to construct the response to the client. 248 o The proxy uses cached data to construct the response to the 249 client. 251 In both cases, the proxy needs to read some parts both of the request 252 from the client and the response from the server to accomplish its 253 task. 255 The following subsections analyse the threats posed by a proxy from 256 the perspective of the client on the one hand (Section 2.1.1) and the 257 perspective of the server on the other hand (Section 2.1.2). 258 Section 2.2 then presents the design space for possible security 259 solutions to mitigate the threats. 261 2.1. Threats and Security Requirements 263 2.1.1. Client-side 265 __________ __ _ _ 266 | | Request | 267 | |---------->| 268 | Client | | Proxy 269 | |<----------| 270 |__________| Response |__ _ _ 272 Figure 4: The Client End 274 The client sends a request to the proxy and waits for a response. 276 From the perspective of the client, there are three possible flows: 278 o The client receives a response. 279 Reasons include: 281 * The proxy duly processed the request and returns a response 282 based on data it obtained from the origin server. 284 * The proxy encountered an unexpected condition and returns an 285 error response according to specification (e.g., 5.02 Bad 286 Gateway or 5.04 Gateway Timeout). 288 * (Threat 1:) The proxy spoofs a response. For example, the 289 proxy could return a stale or outdated response based on data 290 it previously obtained from the server or some fourth party, or 291 could craft an illicit response itself. 293 * (Threat 2:) The proxy duly processed the request but delays the 294 return of the response. 296 o The client does not receive a response. 297 Reasons include: 299 * The client times out too early. 301 * (Threat 3:) The proxy withholds the response. 303 o The client receives too many responses. 304 Reasons include: 306 * (Threat 4:) The proxy floods the client with responses. 308 Furthermore, there are threats related to privacy: 310 o (Threat 5:) The proxy eavesdrops on the data in the request from 311 the client. 313 o (Threat 6:) The proxy measures the size, frequency or distribution 314 of requests from the client. 316 Note that "cache poisoning" -- the case of caching injected incorrect 317 responses -- is covered from the point of view of the client: it may 318 result in the client receiving a spoofed message, or being flooded, 319 or affect other nodes such that the client times out too early. 321 2.1.1.1. Threat 1: Spoofing 323 With one exception (see below), this threat is REQUIRED to be 324 mitigated by the security solution: the client MUST verify that the 325 response is an "authentic response" before processing it. 327 The definition of an "authentic response" depends on the desired 328 proxy functionality and protection level (see Section 2.2), but 329 usually means that the client can obtain proof for some or all of the 330 following things: 332 o that the requested action was executed by the origin server; 334 o that the data originates from the origin server and has not been 335 altered on the way; 337 o that the data matches the specifications of the request (such as 338 the target resource); 340 o that the data is fresh (when the data is cacheable); 342 o that the data is in sequence (when observing a resource). 344 The proof can, for example, include a message authentication code 345 that the proxy obtains from the origin server and includes in the 346 response or an additional challenge-response roundtrip. 348 Exception: A CoAP proxy is specified to return an error response 349 (such as 5.02 Bad Gateway or 5.04 Gateway Timeout) when it 350 encounters an error condition. Since the condition occurs at the 351 proxy and not at the origin server, the response will not be an 352 "authentic response" according to the above definition. (A proxy 353 cannot obtain a proof that the server is unreachable from an 354 unreachable server.) Thus, a client cannot tell if the proxy 355 sends the response according to specification or if it spoofs the 356 response. This threat is NOT REQUIRED to be mitigated by the 357 security solution. 359 2.1.1.2. Threat 2: Delaying 361 This threat is REQUIRED to be mitigated by the security solution. 362 Delay attacks are important to mitigate in certain applications, 363 e.g., when using CoAP with actuators. A problem statement and 364 candidate solution can be found in 365 [I-D.mattsson-core-coap-actuators]. 367 2.1.1.3. Threat 3: Withholding 369 This threat is NOT REQUIRED to be mitigated by the security solution, 370 since a client cannot tell if the proxy does not send a response 371 because it is hasn't received a response from the origin server yet 372 or if it intentionally withholds the response. 374 2.1.1.4. Threat 4: Flooding 376 A CoAP client is specified to reject any response that it does not 377 expect. This can happen before the client verifies whether the 378 response is authentic. Therefore, a flood of responses is primarily 379 a threat to the system resources of the client, in particular to its 380 energy. This threat is NOT REQUIRED to be mitigated by the security 381 solution, but a client SHOULD generally defend against flooding 382 attacks. 384 2.1.1.5. Threat 5: Eavesdropping 386 This threat is REQUIRED to be mitigated by the security solution: 387 clients MUST confidentiality protect the data in the requests they 388 send. 390 Note that this requirement is in conflict with the requirement that 391 the proxy needs to be able to read some parts of the requests in 392 order to accomplish its task. Section 2.2 analyses which parts can 393 be encrypted depending on the desired proxy functionality and 394 protection level. In general, a security solution SHOULD 395 confidentiality protect all data that is not needed by the proxy to 396 accomplish its task. 398 The keys used for confidentiality protection MUST provide forward 399 secrecy. 401 2.1.1.6. Threat 6: Traffic Analysis 403 This threat is NOT REQUIRED to be mitigated by the security solution. 405 It is RECOMMENDED that applications analyse the risks associated with 406 application information leaking from the messages flow and assess the 407 feasibility to protect against various threats, e.g., by obfuscating 408 parameters transported in plain text, aligning message flow and 409 traffic between the different cases, adding padding so different 410 messages become indistinguishable, etc. 412 2.1.2. Server-side 414 _ _ __ __________ 415 | Request | | 416 |---------->| | 417 Proxy | | Server | 418 |<----------| | 419 _ _ __| Response |__________| 421 Figure 5: The Server End 423 A server listens for a request and returns a response. 425 From the perspective of the server, there are three possible flows: 427 o The server receives a request. 428 Reasons include: 430 * The proxy makes a request on behalf of a client according to 431 specification. 433 * The proxy makes a request (e.g., to validate cached data) on 434 its own behalf. 436 * (Threat 1:) The proxy spoofs a request. 438 * (Threat 2:) The proxy sends a request with delay. 440 o The server does not receive a request. 441 Reasons include: 443 * The proxy does not need to send a request. 445 * (Threat 3:) The proxy withholds a request. 447 o The server receives too many requests. 448 Reasons include: 450 * (Threat 4:) The proxy floods the server with requests. 452 A proxy eavesdropping or inferring information from messages it 453 operates on has an impact on a server in the same way as on a client: 455 o (Threat 5:) The proxy eavesdrops on the data in the response from 456 the server. 458 o (Threat 6:) The proxy measures the frequency and distribution of 459 responses from the server. 461 2.1.2.1. Threat 1: Spoofing 463 With one exception (see below), this threat is REQUIRED to be 464 mitigated by the security solution: the server MUST verify that the 465 request is an _authentic request_ before processing it. 467 The definition of an "authentic request" depends on the desired proxy 468 functionality and protection level (Section 2.2), but usually means 469 that the server can obtain proof for some or all of the following 470 things: 472 o that the proxy acts on behalf of a client; 474 o that the data originates from the client and has not been altered 475 on the way; 477 o that the request has not been received previously. 479 The proof can, for example, include a message authentication code 480 that the proxy obtains from the client and includes in the request or 481 a challenge-response roundtrip. 483 Exception: A CoAP proxy may make certain requests without acting on 484 behalf of a client (e.g., to validate cached data). Since such a 485 request does not originate from a client, the server cannot tell 486 if the proxy sends the request according to specification or if it 487 spoofs the request. It is up to the security solution how this 488 issue is addressed. 490 2.1.2.2. Threat 2: Delaying 492 This threat is REQUIRED to be mitigated by the security solution; see 493 Section 2.1.1.2. 495 2.1.2.3. Threat 3: Withholding 497 This threat is NOT REQUIRED to be mitigated by the security solution, 498 since a server cannot tell if the proxy does not send a request 499 because it has no work to do or if it intentionally withholds a 500 request. 502 2.1.2.4. Threat 4: Flooding 504 This threat is NOT REQUIRED to be mitigated by the security solution 505 in particular, but a server SHOULD generally defend against flooding 506 attacks. 508 2.1.2.5. Threat 5: Eavesdropping 510 This threat is REQUIRED to be mitigated by the security solution; see 511 Section 2.1.1.5. 513 2.1.2.6. Threat 6: Traffic Analysis 515 This threat is NOT REQUIRED to be mitigated by the security solution; 516 see Section 2.1.1.6. 518 2.2. Solutions 520 A security solution has to find a trade-off between desired proxy 521 functionality (such as caching) and the provided level of protection. 522 From this trade-off results the definition of what constitutes an 523 "authentic request" or "authentic response" and when a request or 524 response is considered confidentiality protected. 526 This section presents two exemplary choices of trade-offs: 528 o The first case focuses on a high protection level by tying 529 requests and responses uniquely together and confidentiality 530 protecting as much as possible, at the cost of reduced proxy 531 functionality. 533 o The second case aims to preserve proxy functionality as much as 534 possible, at the cost of reduced confidentiality protection. 536 For both cases, this section presents an overview of the 537 functionality and processing rules of the proxy and analyses the 538 required authenticity and confidentiality properties of requests and 539 responses. Due to space constraints, the analysis is limited to the 540 CoAP header fields, the payload and the request and response options 541 shown in Table 1. 543 +----------------+----------------+ 544 | Requests | Responses | 545 +----------------+----------------+ 546 | Accept | Content-Format | 547 | Content-Format | ETag | 548 | ETag | Location-Path | 549 | If-Match | Location-Query | 550 | If-None-Match | Max-Age | 551 | Observe | Observe | 552 | Proxy-Scheme | | 553 | Proxy-Uri | | 554 | Uri-Host | | 555 | Uri-Port | | 556 | Uri-Path | | 557 | Uri-Query | | 558 +----------------+----------------+ 560 Table 1: Analysed CoAP Options 562 Note that, since CoAP was not designed with end-to-end security in 563 mind, a security solution extends the applicability of CoAP beyond 564 its original scope. 566 2.2.1. Forwarding 568 In this case we study forwarding functionality of a CoAP forward 569 proxy, and assume that caching is disabled. This is applicable to 570 many security critical use cases where a response needs to be 571 securely linked to a unique request from a client and cannot be re- 572 used with another request. 574 There may be a unique response for each request (see Figure 6) or 575 multiple responses for each request (see Figure 7). 577 2.2.1.1. Examples 579 Examples of the need for unique response for each request include 580 alarm status retrieval and actuator command confirmation. 582 Client Proxy Server 583 | | | 584 | Request | Request | 585 |-------------->|-------------->|--. 586 | | | | 587 |<--------------|<--------------|<-' 588 | Response | Response | 589 | | | 591 Figure 6: Message Flow with a Unique Response for Each Request 593 Example: Alarm status retrieval 595 Figure 6 can be seen as an illustration of a message exchange for 596 a client requesting the alarm status (e.g., GET /alarm_status) 597 from a server. Since the client wants to ensure that the alarm 598 status received is reflecting the current alarm status and not a 599 cached or spoofed response to the same resource, it must be able 600 to verify that the received response is a response to this 601 particular request made by the client. Therefore, the response 602 must be securely linked to the request. 604 Example: Actuation confirmation 606 Another example for which Figure 6 serves as illustration is the 607 confirmation of an actuator request. In this case a client, say 608 in an industrial control system, requests a server that a valve 609 should be turned to a certain level, e.g. PUT /valve_42/level 610 with payload "3". In order for the client to correctly evaluate 611 the result of a potential changed valve level, it is important 612 that the client gets a confirmation how the server responded to 613 the requested change, e.g., whether the request was performed or 614 not. Again, the client wants to ensure that the response is 615 reflecting the result of this particular actuation request made by 616 the client and not a cached or spoofed response. Therefore, the 617 response must be securely linked to the request. 619 An example of the use of multiple responses for each request is in 620 security critical monitoring scenarios where time synchronization 621 cannot be guaranteed. By avoiding repeated requests from the same 622 client to the same resource, constrained node resources and bandwidth 623 is saved. 625 Client Proxy Server 626 | | | 627 | Request | Request | 628 |-------------->|-------------->|--. 629 | | | | 630 |<--------------|<--------------|<-' 631 | Notification | Notification | 632 | | | 633 |<--------------|<--------------| 634 | Notification | Notification | 635 | | | 636 |<--------------|<--------------| 637 | Notification | Notification | 638 | | | 640 Figure 7: Message Flow of Notifications of Linked to a Unique Request 642 Example: Secure parameter monitoring 644 Figure 7 can be seen as an illustration of a message exchange for 645 a client monitoring an important parameter measured by the server, 646 e.g., in a medical or process industry application. The client 647 makes a subscription request for a resource and the server 648 responds with notifications, e.g. providing updates to the 649 parameter on regular time intervals. 651 The client wants to ensure that the first received notification 652 reflects the current parameter value and that subsequent 653 notifications are timely updates of the initial request. Since 654 notifications may be lost or reordered, the client needs to be 655 able to verify the order of the messages, as sent by the server. 656 By monitoring the received messages and the time they are 657 received, the client can detect missing notifications and take 658 appropriate action. 660 2.2.1.2. Functional Requirements 662 FR1.1 The caching functionality MUST be inhibited; the CoAP option 663 Max-Age of the responses SHALL be 0 (see Section 5.7.1 of 664 [RFC7252]). 666 FR1.2 To limit information leaking about the resource (see 667 Section 2.2.1.5) the Proxy-Uri does not contain Uri-Path or 668 Uri-Query. 670 2.2.1.3. Processing Rules 672 In this case, the desired proxy functionality is to forward a 673 translated request to the determined destination. There are two 674 modes of operation for requests: Either using the Proxy-Uri option 675 (PR1.1) or using the Proxy-Scheme option together with the Uri-Host, 676 Uri-Port, Uri-Path and Uri-Query options (PR1.2). 678 PR1.1 The Proxy-Uri option contains the request URI including 679 request scheme (e.g. "coaps://"); the Proxy-Scheme and Uri-* 680 options are not present. 682 If the proxy is configured to forward requests to another 683 proxy, then it keeps the Proxy-Uri option; otherwise, it 684 splits the option into its components, adds the corresponding 685 Uri-* options and removes the Proxy-Uri option. Then it makes 686 the request using the request scheme indicated in the Proxy- 687 Uri. 689 PR1.2 The Proxy-Scheme option and the Uri-* options together contain 690 the request URI; the Proxy-Uri option is not present. 692 If the proxy is configured to forward requests to another 693 forwarding proxy, then it keeps the Proxy-Scheme and Uri-* 694 options; otherwise, it removes the Proxy-Scheme option. Then 695 it makes the request using the request scheme indicated in the 696 removed Proxy-Scheme option. 698 PR1.3 Responses are forwarded by the proxy, without any 699 modification. 701 2.2.1.4. Authenticity 703 A request is considered authentic by the server (Section 2.1.2.1) if 704 the server can obtain proof for all of the following things: 706 A1.1 that the proxy acts on behalf of a client; 707 A1.2 that the following parts of the request originate from the 708 client and have not been altered on the way: 710 * the CoAP version, 712 * the request method, 714 * all options except Proxy-Uri, Proxy-Scheme, Uri-Host, Uri- 715 Port, Uri-Path and Uri-Query, and 717 * the payload, if any. 719 A1.3 that the effective request URI originates from the client and 720 has not been altered on the way; 722 A1.4 that the request has not been received previously; 724 A1.5 that the request from the client to the proxy was sent 725 recently. 727 A response is considered authentic by the client (Section 2.1.1.1) if 728 the client can obtain proof for all of the following things: 730 A1.6 that the following parts of the response originate from the 731 server and have not been altered on the way: 733 * the CoAP version, 735 * the response code, 737 * all options, and 739 * the payload, if any. 741 A1.7 that the response corresponds uniquely to the request sent by 742 the client. 744 A1.8 that the response has not been received previously; 746 A1.9 that the response from the server to the proxy was sent 747 recently; 749 A1.10 that the response is in sequence if there are multiple 750 responses. 752 2.2.1.5. Confidentiality 754 The following parts of the message are confidentiality protected 755 (Section 2.1.1.5): 757 o all options except Proxy-Uri, Proxy-Scheme, Uri-Host and Uri-Port; 759 o the payload, if any. 761 2.2.2. Caching 763 In this case we study caching: how a proxy may serve the same cached 764 response to multiple clients requesting the same resource. 766 The caching functionality protects communication-constrained servers 767 from repeated requests for the same resources, possibly originating 768 from different clients. This saves system resources, bandwidth, and 769 round-trip time. 771 There may be one response for each request (see Figure 8) or multiple 772 responses for each request (see Figure 9). 774 2.2.2.1. Examples 776 The first example is a simple case of caching. 778 Client A Proxy Server 779 | | | 780 | Request | Request | 781 |-------------->|-------------->|--. 782 | | | | 783 |<--------------|<--------------|<-' 784 | Response | Response | 785 | | | 786 | | 787 Client B | | 788 | | | 789 | Request | | 790 |-------------->|--. | 791 | | | from cache | 792 |<--------------|<-' | 793 | Response | | 794 | | | 796 Figure 8: Message Flow for Cached Responses 798 Example: Caching 799 In Figure 8, client A requests the proxy to make a certain request 800 to the server and to return the server's response. The proxy 801 services the request by making a request message to the server 802 according to the processing rules. If the server returns a 803 cacheable response, then the proxy stores the response in its 804 cache, performs any necessary translations, and forwards it to the 805 client. Later, client B makes an equivalent request to the proxy 806 that the proxy services by returning the response from its cache. 807 Both client A and B want to verify that the response is valid. 809 In addition to multiple clients' requests being served by one 810 response, each request may result in multiple responses. The 811 difference compared to Section 2.2.1 is that in this example multiple 812 clients may be served with the same response, further saving server 813 resources. 815 Client A Proxy Server 816 | | | 817 | Request | Request | 818 |-------------->|-------------->|--. 819 | | | | 820 |<--------------|<--------------|<-' 821 | Notification | Notification | 822 | | | 823 | | 824 Client B | | 825 | | | 826 | Request | | 827 |-------------->|--. | 828 | | | from cache | 829 |<--------------|<-' | 830 | Notification | | 831 | | | 832 |<--------------|<--------------| 833 | Notification | Notification | 834 | | | 835 | | 836 Client A | | 837 | | | 838 |<--------------| | 839 | Notification | | 840 | | | 842 Figure 9: Message Flow for Observe with Multiple Observers 844 Example: Observe with caching 845 In Figure 9, the server exposes an observable resource (e.g., the 846 current reading of a temperature sensor). Multiple clients are 847 interested in the current state of the resource and observe it 848 using the CoAP resource observation mechanism [RFC7641]. The goal 849 is to keep the state observed by the clients closely in sync with 850 the actual state of the resource at the server. Another goal is 851 to minimize the burden on the server by moving the task to fan out 852 notifications to multiple clients from the server to the proxy. 854 2.2.2.2. Functional Requirements 856 The security solution SHOULD protect requests and responses in a way 857 that a proxy can perform the following tasks: 859 FR2.1 Storing a cacheable response in a cache. This requires that 860 the proxy is able to calculate the cache-key of the request. 861 Cacheable responses include 2.05 (Content) responses and all 862 error responses. 864 FR2.2 Returning a fresh response from its cache without contacting 865 the server. 867 FR2.3 Performing validation of a response cached by the proxy as 868 well as validation of a response cached by the client. 870 FR2.4 Observing a resource on behalf of one or more clients. 872 2.2.2.3. Processing Rules 874 The proxy complies with the forwarding rules PR1.1 - 1.3 875 (Section 2.2.1.3) and the rules below. The rules below have 876 priority. 878 PR2.1 If the proxy receives a request where the cache key matches 879 that of a cached fresh response, then the proxy discards the 880 request and replies with that response, else it makes a 881 translated request. 883 PR2.2 The proxy caches and forwards cacheable responses. If there 884 is already a response in the cache with the cache key of the 885 corresponding request, then the old response in the cache is 886 marked as stale. 888 PR2.3 If the proxy receives a request that contains an ETag option 889 and the proxy has a fresh response with the same cache key and 890 ETag, then the proxy replies to the request with a 2.03 891 (Valid) response without payload, else it forwards a 892 translated request. 894 PR2.4 The proxy updates the Max-Age option according to the Max-Age 895 associated with the resource representation it receives, 896 decreasing its value to reflect the time spent in the cache. 898 PR2.5 If the request contains an Accept option and if there is a 899 fresh response that matches the cache key for the 900 corresponding request except for the Accept option, and if the 901 Content-Format of the response matches that of the Accept 902 option, then the proxy forwards the cached response to the 903 requesting client. 905 2.2.2.4. Authenticity 907 A request is considered authentic by the server (Section 2.1.2.1) if 908 the server can obtain proof for all of the following things: 910 A2.1 that the following parts of the request originate from the 911 client and have not been altered on the way: 913 * the CoAP version, 915 * the request method, 917 * all options except ETag, Observe, Proxy-Uri, Proxy-Scheme, 918 Uri-Host, Uri-Port, Uri-Path and Uri-Query, and 920 * the payload, if any. 922 A2.2 that the effective request URI originates from the client and 923 has not been altered on the way; 925 A response is considered authentic by the client (Section 2.1.1.1) if 926 the client can obtain proof for all of the following things: 928 A2.3 that the following parts of the response originate from the 929 server and have not been altered on the way: 931 * the CoAP version, 933 * the response code, 935 * all options except Max-Age and Observe, and 937 * the payload, if any. 939 A2.4 that the response matches the specifications of the request; 941 A2.5 that the data is fresh (when the response is cacheable); 942 A2.6 that the response is in sequence (when observing a resource). 944 2.2.2.5. Confidentiality 946 No parts of a request are confidentiality protected 947 (Section 2.1.2.5). 949 A response is considered confidentiality protected (Section 2.1.2.5) 950 if the payload of the response is confidentiality protected. 952 3. Publish-Subscribe 954 Much of the concerns about proxies as described previously in this 955 document also applies to other kinds of intermediary nodes. In this 956 section we study brokers in a publish-subscribe setting 957 [I-D.ietf-core-coap-pubsub]. The case of combining brokers and 958 proxies is out of scope for this version of the document. 960 There are different ways for a pub-sub broker to operate. We 961 consider the following broker operations: 963 o The broker receives a request for a topic from a subscriber. 965 o The broker receives a request for a publication to a topic from a 966 publisher and forwards the request to the subscribers of the 967 topic. 969 We consider the setting where there is a security association between 970 publisher and subscriber such that the publications can be protected 971 during transfer, see Figure 10. 973 ____________ __________ ___________ 974 | | | | | | 975 | |----->| |<------| | 976 | Subscriber | | Broker | | Publisher | 977 | |<-----| |------>| | 978 |____________| |__________| |___________| 979 : : 980 '--------------------------------------' 981 Security Association 983 Figure 10: Publisher-to-Subscriber Security 985 Since there is no security association with the broker, we only 986 consider the subscribe and publish functionality of the broker. Note 987 that the broker needs to read the topic to accomplish this task. 989 3.1. Threats and Security Requirements 991 3.1.1. Subscriber-side 992 __________ __ _ _ 993 | | Request | 994 | Sub- |---------->| 995 | scriber | | Broker 996 | |<----------| 997 |__________| Response |__ _ _ 999 Figure 11: The Subscriber End 1001 The subscriber sends a subscription request to the broker and waits 1002 for a response. 1004 From the perspective of the subscriber, there are three possible 1005 flows: 1007 o The subscriber receives a response. 1008 Reasons include: 1010 * The broker duly processed the request and returns a response 1011 based on data it obtained from a publisher. 1013 * The subscriber made a bad request and the broker returns an 1014 error response accordingly (e.g., 4.04 Not Found). 1016 * The broker encountered an unexpected condition and returns an 1017 error response accordingly (e.g., 5.03 Service Unavailable). 1019 * (Threat 1:) The broker spoofs a response. 1021 * (Threat 2:) The broker duly processed the request but delays 1022 the return of a response. 1024 o The subscriber does not receive a response. 1025 Reasons include: 1027 * The subscriber times out too early. 1029 * (Threat 3:) The broker withholds a response. 1031 o The subscriber receives too many responses. 1032 Reasons include: 1034 * (Threat 4:) The broker floods the subscriber with responses. 1036 Furthermore, there are threats related to privacy: 1038 o (Threat 5:) The broker eavesdrops on the data in the request from 1039 the subscriber. 1041 o (Threat 6:) The broker measures the size, frequency or 1042 distribution of requests from the subscriber. 1044 Note that "topic poisoning" -- the case of storing injected incorrect 1045 publications -- is covered from the point of view of the subscriber: 1046 it may result in the subscriber receiving a spoofed message, or being 1047 flooded, or affect other nodes such that the subscriber times out too 1048 early. 1050 3.1.1.1. Threat 1: Spoofing 1052 With one exception (see below), this threat is REQUIRED to be 1053 mitigated by the security solution: the subscriber MUST verify that a 1054 response is an "authentic publication" before processing it. 1056 The definition of an "authentic publication" depends on the setting 1057 (Section 3.2), but usually means that the subscriber can obtain proof 1058 for some or all of the following things: 1060 o that the data matches the specifications of the request (such as 1061 the topic); 1063 o that the data originates from a publisher that is authorized to 1064 publish to the topic; 1066 o that the data has not been altered on the way between publisher 1067 and subscriber; 1069 o that the data is fresh (when the data is cacheable); 1071 o that the data is in sequence (when observing a topic). 1073 The proof can, for example, include a message authentication code 1074 that the proxy obtains from the origin server and includes in the 1075 response or an additional challenge-response roundtrip. 1077 Exception: A CoAP server like the broker is specified to return an 1078 error response (such as 4.04 Not Found or 5.03 Service 1079 Unavailable) when it encounters an error condition. Since the 1080 condition occurs at the broker and not at the publisher, the 1081 response will not be an "authentic response" according to the 1082 above definition. Thus, a subscriber cannot tell if the broker 1083 sends the error response according to specification or if it 1084 spoofs the response. This threat is NOT REQUIRED to be mitigated 1085 by the security solution. 1087 3.1.1.2. Threat 2: Delaying 1089 This threat is NOT REQUIRED to be mitigated by the security solution. 1091 3.1.1.3. Threat 3: Withholding 1093 This threat is NOT REQUIRED to be mitigated by the security solution, 1094 since a subscriber cannot tell if the broker does not send a response 1095 because it is hasn't received a publication from the publisher yet or 1096 if it intentionally withholds the response. 1098 3.1.1.4. Threat 4: Flooding 1100 A CoAP client like the subscriber is specified to reject any response 1101 that it does not expect. This can happen before the subscriber 1102 verifies if the response is authentic. Therefore, a flood of 1103 responses is primarily a threat to the system resources of the 1104 client, in particular to its energy. This threat is NOT REQUIRED to 1105 be mitigated by the security solution, but a subscriber SHOULD 1106 generally defend against flooding attacks. 1108 3.1.1.5. Threat 5: Eavesdropping 1110 This threat is NOT REQUIRED to be mitigated: The broker needs to read 1111 all parts of the request from the subscriber to accomplish its task. 1113 It is RECOMMENDED that applications analyse the risks associated with 1114 application information leaking from the messages flow and assess the 1115 feasibility to protect against various threats, e.g., by obfuscating 1116 topic content. 1118 3.1.1.6. Threat 6: Traffic Analysis 1120 This threat is NOT REQUIRED to be mitigated by the security solution. 1122 It is RECOMMENDED that applications analyse the risks associated with 1123 application information leaking from the messages flow and assess the 1124 feasibility to protect against various threats, e.g., by obfuscating 1125 parameters transported in plain text, aligning message flow and 1126 traffic between the different cases, adding padding so different 1127 messages become indistinguishable, etc. 1129 3.1.2. Publisher-side 1130 _ _ __ __________ 1131 | Request | | 1132 |<----------| Pub- | 1133 Broker | | lisher | 1134 |---------->| | 1135 _ _ __| Response |__________| 1137 Figure 12: The Publisher End 1139 The publisher sends a publication request to the broker and waits for 1140 a response. 1142 The threat of the broker eavesdropping on the data in the publication 1143 request is REQUIRED to be mitigated by the security solution: 1144 publishers MUST confidentiality protect the data in the requests they 1145 send. This excludes parts that the broker needs to read to perform 1146 its job, e.g., the topic. 1148 The threat of the broker measuring the size, frequency or 1149 distribution of publication requests is NOT REQUIRED to be mitigated 1150 by the security solution; see Section 3.1.1.6. 1152 The broker is in full control of the response and may therefore 1153 arbitrarily spoof, delay, or withhold it. This threat is NOT 1154 REQUIRED to be mitigated. For example, a proof that the broker has 1155 notified all subscribers is NOT REQUIRED. 1157 3.2. Solutions 1159 3.2.1. Brokering 1161 In this case we study brokering: how a broker may serve the same 1162 publication to multiple subscribers observing the same topic. 1164 The brokering functionality protects communication-constrained 1165 publishers from repeated requests for the same resources, possibly 1166 originating from different subscribers. This saves system resources, 1167 bandwidth, and round-trip time. 1169 Subscriber A Broker Publisher 1170 | | | 1171 | | Request | 1172 | .--|<--------------| 1173 | | | | 1174 | '->|-------------->| 1175 | | Response | 1176 | | | 1177 | Request | | 1178 |-------------->|--. | 1179 | | | from store | 1180 |<--------------|<-' | 1181 | Notification | | 1182 | | | 1183 | | 1184 Subscriber B | | 1185 | | | 1186 | Request | | 1187 |-------------->|--. | 1188 | | | from store | 1189 |<--------------|<-' | 1190 | Notification | | 1191 | | | 1192 | | Request | 1193 |<--------------|<--------------| 1194 | Notification | | 1195 | |-------------->| 1196 | | Response | 1197 | | 1198 Subscriber A | | 1199 | | | 1200 |<--------------| | 1201 | Notification | | 1202 | | | 1204 Figure 13: Message Flow for Publish Subscribe 1206 Example 1208 In Figure 13, the publisher publishes to a topic (e.g., the 1209 current reading of a temperature sensor). Multiple subscribers 1210 are interested in the current state of the topic and observe the 1211 topic as specified in [I-D.ietf-core-coap-pubsub]. The goal is to 1212 keep the state observed by the subscribers closely in sync with 1213 the actual state of the resource at the publisher. Another goal 1214 is to minimize the burden on the publisher by moving the task to 1215 fan out notifications to multiple subscribers from the publisher 1216 to the broker. 1218 3.2.1.1. Functional Requirements 1220 The security solution SHOULD protect subscription and publication 1221 requests in a way that a broker can perform the following tasks: 1223 FR3.1 Storing publications. This requires that the broker is able 1224 to read the topic of the request. 1226 FR3.2 Returning a stored publication without contacting the 1227 publisher. 1229 3.2.1.2. Processing Rules 1231 The broker complies with the following rules: 1233 PR3.1 If the broker receives a request where the topic matches that 1234 of a cached publication, then the broker responds with that 1235 publication. 1237 PR3.2 The broker caches and forwards publication notifications. 1239 3.2.1.3. Authenticity 1241 A publication is considered authentic by the subscriber if the 1242 subscriber can obtain proof for all all of the following things: 1244 A3.1 that the payload is associated to the topic; 1246 A3.2 that the payload has not been altered since published; 1248 A3.3 that the publication is in sequence. 1250 3.2.1.4. Confidentiality 1252 The payload of a publication request is confidentiality protected. 1254 4. Security Considerations 1256 This document is about security; as such, there are no additional 1257 security considerations. 1259 5. IANA Considerations 1261 This document includes no request to IANA. 1263 6. References 1265 6.1. Normative References 1267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1268 Requirement Levels", BCP 14, RFC 2119, 1269 DOI 10.17487/RFC2119, March 1997, 1270 . 1272 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1273 Application Protocol (CoAP)", RFC 7252, 1274 DOI 10.17487/RFC7252, June 2014, 1275 . 1277 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1278 Application Protocol (CoAP)", RFC 7641, 1279 DOI 10.17487/RFC7641, September 2015, 1280 . 1282 6.2. Informative References 1284 [I-D.ietf-core-coap-pubsub] 1285 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1286 Subscribe Broker for the Constrained Application Protocol 1287 (CoAP)", draft-ietf-core-coap-pubsub-00 (work in 1288 progress), October 2016. 1290 [I-D.ietf-cose-msg] 1291 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1292 draft-ietf-cose-msg-24 (work in progress), November 2016. 1294 [I-D.mattsson-core-coap-actuators] 1295 Mattsson, J., Fornehed, J., Selander, G., and F. 1296 Palombini, "Controlling Actuators with CoAP", draft- 1297 mattsson-core-coap-actuators-02 (work in progress), 1298 November 2016. 1300 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1301 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1302 January 2012, . 1304 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1305 Constrained-Node Networks", RFC 7228, 1306 DOI 10.17487/RFC7228, May 2014, 1307 . 1309 Acknowledgments 1311 Thanks to Ari Keranen, John Mattsson, Jim Schaad and Ludwig Seitz for 1312 helpful comments and discussions that have shaped the document. 1314 Authors' Addresses 1316 Goeran Selander 1317 Ericsson AB 1318 SE-164 80 Stockholm 1319 Sweden 1321 Email: goran.selander@ericsson.com 1323 Francesca Palombini 1324 Ericsson AB 1325 SE-164 80 Stockholm 1326 Sweden 1328 Email: francesca.palombini@ericsson.com 1330 Klaus Hartke 1331 Universitaet Bremen TZI 1332 Postfach 330440 1333 Bremen 28359 1334 Germany 1336 Phone: +49-421-218-63905 1337 Email: hartke@tzi.org