idnits 2.17.1 draft-thaler-core-redirect-01.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 document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2016) is 2727 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 310, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational October 31, 2016 5 Expires: May 4, 2017 7 COAP Redirects 8 draft-thaler-core-redirect-01 10 Abstract 12 This document allows a Constrained Application Protocol (CoAP) server 13 to redirect a client to a new URI. The primary use case is to allow 14 a client using multicast CoAP discovery to learn a COAPS endpoint of 15 the server, without the server revealing privacy-sensitive 16 information. This improves security and privacy in environments with 17 untrusted clients. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Alternatives Considered . . . . . . . . . . . . . . . . . . . 4 56 2.1. Just use normal multicast discovery . . . . . . . . . . . 4 57 2.2. Just use a resource directory . . . . . . . . . . . . . . 4 58 2.3. Use Alternative-Address . . . . . . . . . . . . . . . . . 5 59 3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Option Definitions . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Location-Scheme and Location-Authority . . . . . . . 5 62 3.2. Response Codes . . . . . . . . . . . . . . . . . . . . . 6 63 3.2.1. 3.01 Moved Permanently . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 6.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The Constrained Application Protocol (CoAP) [RFC7252] is a 74 specialized web transfer protocol for use with constrained nodes and 75 constrained networks. When COAP nodes can appear on a network that 76 allows untrusted clients, security and privacy issues can arise, as 77 discussed in Section 11 of [RFC7252]. 79 This document focuses on a solution for a specific use case: 80 preventing privacy-sensitive information from being passed to 81 untrusted clients, especially as part of resource discovery. The 82 resource discovery phase is important because DTLS is not used with 83 multicast COAP. 85 The specific relevant threats are: 87 o Correlation across location: If a COAP server can move between 88 multiple networks in which an attacker has a presence, the 89 attacker can potentially correlate responses from the COAP server 90 across the two locations and determine that the same entity is 91 moving between those two locations. This can even be used to 92 identify individuals, such as when the COAP server is in a 93 wearable device. 95 o Correlation across time: If a COAP server is available 96 periodically in the same location over a long time, an attacker in 97 that location can potentially correlate reponses over time and 98 determine that it is the same entity, even though the IP address 99 and layer-2 address may be different. This can even be used to 100 identify individuals, such as when the COAP server is in a 101 wearable device. 103 o Fingerprinting: Device-specific vulnerability exploitation can be 104 most easily accomplished if an attacker can easily narrow down 105 what software the server runs. Information returned via multicast 106 service discovery can facilitate such fingerprinting. 108 For more discussion of these threats, see Section 5.2 of [RFC6973], 109 Section 3 of [RFC7721], and [I-D.winfaa-intarea-broadcast-consider]. 111 To mitigate these threats, this document defines the ability for a 112 server to redirect a client to another URI. Specifically, the 113 expected use is that in response to an unsecured COAP request, a 114 privacy-sensitive server could be configured to simply respond by 115 redirecting the client to a COAPS endpoint, thus allowing the client 116 to discover a unicast endpoint, but not to discover any privacy- 117 sensitive information without establishing a secured unicast 118 connection. 120 By comparison, HTTP (Section 6.4.2 of [RFC7231]) redirects with 301 121 (Moved Permanently) and a Location header containing the new URI. 122 COAP, on the other hand, defines Location-Path and Location-Query 123 COAP options [RFC7252] for those components of the URI, but did not 124 define options for the other URI components. [ListDiscussion] 125 explains: 127 While early drafts of CoAP did have some forms of redirection, we 128 found that the use cases most people had in mind did not call for 129 redirects. The main reason is that in a CoRE world, URIs are 130 usually found through a discovery process, and these URIs can be 131 made to point to the right place right away. 133 The use case motivating this document, however, is specifically for 134 redirects as part of the discovery process itself. 136 1.1. Example 138 Existing clients conforming to the OIC 1.1 Core spec [OIC1.1Core] 139 sections 10 and 11.3.5 do discovery by sending a multicast CoAP GET 140 for "/oic/res". Existing servers will respond with links to a set of 141 resources, but that information might be privacy-sensitive in some 142 cases. For example, it might contain sufficient a unique identifier 143 of the server, or information sufficient for an attacker to determine 144 what version of what software it runs. (A sample response can be 145 found in section 10.2 of [OIC1.1Core].) Hence a privacy-sensitive 146 server needs a way to be discovered by trusted clients without 147 revealing privacy-sensitive information to untrusted observers. A 148 redirect allows a client to send the same request, thus not 149 increasing the amount of multicast traffic on the network. 151 For example, consider a network with a privacy-sensitive server, and 152 a legacy server. A client wants to efficiently discover both 153 servers. The client can send a single multicast GET for "/oic/res", 154 and the legacy server would send a unicast response with the 155 requested data, whereas the privacy-sensitive server would respond 156 with a unicast redirect to "coaps://:/oic/res". The 157 client can then generate a unicast GET over coaps to get the actual 158 data, if permitted, from the privacy-sensitive server. This 159 mechanism keeps the latency and number of messages to a minimum. 161 2. Alternatives Considered 163 This section discusses why existing alternatives are not sufficient. 165 2.1. Just use normal multicast discovery 167 Normal multicast discovery is susceptible to the threats discussed 168 earlier. Another approach would be for multicast discovery to return 169 only generic information that is the same for every device, and hence 170 does not reveal any privacy related information or allow 171 fingerprinting. This is undesirable since the resource handler would 172 have to return different information based on whether the client is 173 authenticated vs. unauthenticated, and thus is complex and error 174 prone to implement and maintain. 176 2.2. Just use a resource directory 178 A resource directory could be used and only provide data to 179 authenticated clients. However, the same problem still remains as to 180 how to discover the resource directory itself. One could potentially 181 use an alternate discovery protocol such as DNS-SD, but this 182 introduces additional complexity when clients otherwise just use COAP 183 for both discovery and communication. In addition, requiring a 184 resource directory to be implemented, deployed, and maintained in a 185 constrained environment presents an extra deployment burden that is 186 desirable to avoid. 188 2.3. Use Alternative-Address 190 Section 4.5 of [I-D.ietf-core-coap-tcp-tls] provides an Alternative- 191 Address option, which can be used to redirect the client to another 192 transport address. However, it states: 194 The Alternative-Address elective option requests the peer to 195 instead open a connection of the same kind as the present 196 connection to the alternative transport address given. Its value 197 is in the form "authority" as defined in Section 3.2 of [RFC3986]. 199 Thus, Alternative-Address can indicate another authority component, 200 but it explicitly requires the same URI scheme to be used, so it 201 cannot be used to redirect from coap to coaps. 203 3. Redirects 205 3.1. Option Definitions 207 The following additional options are defined. 209 +--------+--------------------+--------+--------+------------+ 210 | Number | Name | Format | Length | Base Value | 211 +--------+--------------------+--------+--------+------------+ 212 | TBD | Location-Scheme | string | 0-255 | (none) | 213 | TBD | Location-Authority | string | 0-255 | (none) | 214 +--------+--------------------+--------+--------+------------+ 216 3.1.1. Location-Scheme and Location-Authority 218 Section 5.10.7 of [RFC7252] states: 220 The options that are used to compute the relative URI-reference 221 are collectively called Location-* options. Beyond Location-Path 222 and Location-Query, more Location-* options may be defined in the 223 future and have been reserved option numbers 128, 132, 136, and 224 140. 226 The Location-Scheme and Location-Authority options are subject to all 227 rules for Location-* options discussed in [RFC7252]. 229 Together with Location-Path and Location-Query, the Location-Scheme 230 and Location-Authority Options indicate a relative URI that contains 231 either of an absolute path, a query string, or both. A combination 232 of these options is included in a 3.01 (Moved Permanently) response 233 to indicate the new location of the requested resource relative to 234 the request URI. 236 If a response with Location-Scheme and/or Location-Authority Options 237 passes through a cache that interprets these options and the implied 238 URI identifies one or more currently stored responses, those entries 239 MUST be marked as not fresh. 241 The Location-Scheme and Location-Authority Option can contain any 242 character sequence conforming to the scheme and authority components 243 defined in [RFC3986]. 245 3.2. Response Codes 247 This specification adds the following response code. 249 3.2.1. 3.01 Moved Permanently 251 This Response Code indicates that the target resource has been 252 assigned a new permanent URI and any future references to this 253 resource ought to use the indicated effective URI. 255 The server MUST include in the response any of the following options 256 whose values differ between the requested URI and the new effective 257 URI: Location-Scheme, Location-Authority, Location-Path, and 258 Location-Query. The client SHOULD use the Location field value for 259 automatic redirection. 261 A 3.01 response is cacheable. Caches can use the Max-Age Option to 262 determine freshness. A 3.01 response cannot be validated. 264 4. IANA Considerations 266 This document adds the following option numbers to the "CoAP Option 267 Numbers" registry defined by [RFC7252]: 269 +--------+---------------------------+--------------------------+ 270 | Number | Name | Reference | 271 +--------+---------------------------+--------------------------+ 272 | TBD | Location-Scheme | I-D.thaler-core-redirect | 273 | | | | 274 | TBD | Location-Authority | I-D.thaler-core-redirect | 275 +--------+---------------------------+--------------------------+ 277 NOTE: Section 5.10.7 of [RFC7252] reserves option numbers 128, 132, 278 136, and 140 for new Location-* options. Thus, the option numbers 279 should be assigned from that set. 281 This document adds the following response codes to the "CoAP Response 282 Codes" registry defined by [RFC7252]: 284 +------+---------------------------+--------------------------+ 285 | Code | Description | Reference | 286 +------+---------------------------+--------------------------+ 287 | 3.01 | Moved Permanently | I-D.thaler-core-redirect | 288 +------+---------------------------+--------------------------+ 290 5. Security Considerations 292 The use case for this document is specifically to mitigate privacy 293 concerns by allowing a request to an unsecured URI to be redirected 294 to a secured URI. 296 Preventing identifying information from being observed by untrusted 297 clients doing multicast discovery is necessary but not sufficient to 298 mitigate the privacy issues discussed in Section 1. That is, one 299 must also use an authentication scheme for subsequent unicast 300 messages that does not reveal a stable identifier to clients before 301 authentication is complete. Mutual authentication schemes exist 302 (e.g., [Balfanz]) that only reveal the identity of both endpoints if 303 authentication succeeds, but they may not yet be available in current 304 standards and popular code bases. 306 6. References 308 6.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 316 Resource Identifier (URI): Generic Syntax", STD 66, 317 RFC 3986, DOI 10.17487/RFC3986, January 2005, 318 . 320 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 321 Application Protocol (CoAP)", RFC 7252, 322 DOI 10.17487/RFC7252, June 2014, 323 . 325 6.2. Informative References 327 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 328 Morris, J., Hansen, M., and R. Smith, "Privacy 329 Considerations for Internet Protocols", RFC 6973, 330 DOI 10.17487/RFC6973, July 2013, 331 . 333 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 334 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 335 DOI 10.17487/RFC7231, June 2014, 336 . 338 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 339 Considerations for IPv6 Address Generation Mechanisms", 340 RFC 7721, DOI 10.17487/RFC7721, March 2016, 341 . 343 [I-D.ietf-core-coap-tcp-tls] 344 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 345 Silverajan, B., and B. Raymor, "CoAP (Constrained 346 Application Protocol) over TCP, TLS, and WebSockets", 347 draft-ietf-core-coap-tcp-tls-05 (work in progress), 348 October 2016. 350 [I-D.winfaa-intarea-broadcast-consider] 351 Winter, R., Faath, M., and F. Weisshaar, "Privacy 352 considerations for IP broadcast and multicast protocol 353 designers", draft-winfaa-intarea-broadcast-consider-03 354 (work in progress), September 2016. 356 [Balfanz] Balfanz, D., Durfee, G., Shankar, N., Smetters, D., 357 Staddon, J., and H-C. Wong, "Secret Handshakes From 358 Pairing-based Key Agreements", May 2003, 359 . 361 [ListDiscussion] 362 Bormann, C., "Question about Location and redirection", 363 Symposium on Security and Privacy 2003, October 2013, 364 . 367 [OIC1.1Core] 368 Open Connectivity Foundation, "OIC Core Specification 369 V1.1.0", 2016, . 372 Author's Address 374 Dave Thaler 375 Microsoft 376 One Microsoft Way 377 Redmond, WA 98052 378 USA 380 Email: dthaler@microsoft.com