Network Working Group D. Thaler Internet-Draft Microsoft Intended status: Informational September 12, 2016 Expires: March 16, 2017 COAP Redirects draft-thaler-core-redirect-00 Abstract This document allows a Constrained Application Protocol (CoAP) server to redirect a client to a new URI. The primary use case is to allow a client using multicast CoAP discovery to learn a COAPS endpoint of the server, without the server revealing privacy-sensitive information. This improves security and privacy in environments with untrusted clients. 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 March 16, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Thaler Expires March 16, 2017 [Page 1] Internet-Draft COAP Redirects September 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Alternatives Considered . . . . . . . . . . . . . . . . . . . 3 2.1. Just use normal multicast discovery . . . . . . . . . . . 3 2.2. Just use a resource directory . . . . . . . . . . . . . . 4 2.3. Use Alternative-Address . . . . . . . . . . . . . . . . . 4 3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Option Definitions . . . . . . . . . . . . . . . . . . . 4 3.1.1. Location-Scheme and Location-Authority . . . . . . . 5 3.2. Response Codes . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. 3.01 Moved Permanently . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Constrained Application Protocol (CoAP) [RFC7252] is a specialized web transfer protocol for use with constrained nodes and constrained networks. When COAP nodes can appear on a network that allows untrusted clients, security and privacy issues can arise, as discussed in Section 11 of [RFC7252]. This document focuses on a solution for a specific use case: preventing privacy-sensitive information from being passed to untrusted clients, especially as part of resource discovery. The resource discovery phase is important because DTLS is not used with multicast COAP. The specific relevant threats are: o Correlation across location: If a COAP server can move between multiple networks in which an attacker has a presence, the attacker can potentially correlate responses from the COAP server across the two locations and determine that the same entity is moving between those two locations. This can even be used to identify individuals, such as when the COAP server is in a wearable device. o Correlation across time: If a COAP server is available periodically in the same location over a long time, an attacker in Thaler Expires March 16, 2017 [Page 2] Internet-Draft COAP Redirects September 2016 that location can potentially correlate reponses over time and determine that it is the same entity, even though the IP address and layer-2 address may be different. This can even be used to identify individuals, such as when the COAP server is in a wearable device. o Fingerprinting: Device-specific vulnerability exploitation can be most easily accomplished if an attacker can easily narrow down what software the server runs. Information returned via multicast service discovery can facilitate such fingerprinting. For more discussion of these threats, see Section 5.2 of [RFC6973], Section 3 of [RFC7721], and [I-D.winfaa-intarea-broadcast-consider]. To mitigate these threats, this document defines the ability for a server to redirect a client to another URI. Specifically, the expected use is that in response to an unsecured COAP request, a privacy-sensitive server could be configured to simply respond by redirecting the client to a COAPS endpoint, thus allowing the client to discover a unicast endpoint, but not to discover any privacy- sensitive information without establishing a secured unicast connection. By comparison, HTTP (Section 6.4.2 of [RFC7231]) redirects with 301 (Moved Permanently) and a Location header containing the new URI. COAP, on the other hand, defines Location-Path and Location-Query COAP options [RFC7252] for those components of the URI, but did not define options for the other URI components. [ListDiscussion] explains: While early drafts of CoAP did have some forms of redirection, we found that the use cases most people had in mind did not call for redirects. The main reason is that in a CoRE world, URIs are usually found through a discovery process, and these URIs can be made to point to the right place right away. The use case motivating this document, however, is specifically for redirects as part of the discovery process itself. 2. Alternatives Considered This section discusses why existing alternatives are not sufficient. 2.1. Just use normal multicast discovery Normal multicast discovery is susceptible to the threats discussed earlier. Another approach would be for multicast discovery to return only generic information that is the same for every device, and hence Thaler Expires March 16, 2017 [Page 3] Internet-Draft COAP Redirects September 2016 does not reveal any privacy related information or allow fingerprinting. This is undesirable since the resource handler would have to return different information based on whether the client is authenticated vs. unauthenticated, and thus is complex and error prone to implement and maintain. 2.2. Just use a resource directory A resource directory could be used and only provide data to authenticated clients. However, the same problem still remains as to how to discover the resource directory itself. One could potentially use an alternate discovery protocol such as DNS-SD, but this introduces additional complexity when clients otherwise just use COAP for both discovery and communication. In addition, requiring a resource directory to be implemented, deployed, and maintained in a constrained environment presents an extra deployment burden that is desirable to avoid. 2.3. Use Alternative-Address Section 4.5 of [I-D.ietf-core-coap-tcp-tls] provides an Alternative- Address option, which can be used to redirect the client to another transport address. However, it states: The Alternative-Address elective option requests the peer to instead open a connection of the same kind as the present connection to the alternative transport address given. Its value is in the form "authority" as defined in Section 3.2 of [RFC3986]. Thus, Alternative-Address can indicate another authority component, but it explicitly requires the same URI scheme to be used, so it cannot be used to redirect from coap to coaps. 3. Redirects 3.1. Option Definitions The following additional options are defined. +--------+--------------------+--------+--------+------------+ | Number | Name | Format | Length | Base Value | +--------+--------------------+--------+--------+------------+ | TBD | Location-Scheme | string | 0-255 | (none) | | TBD | Location-Authority | string | 0-255 | (none) | +--------+--------------------+--------+--------+------------+ Thaler Expires March 16, 2017 [Page 4] Internet-Draft COAP Redirects September 2016 3.1.1. Location-Scheme and Location-Authority Section 5.10.7 of [RFC7252] states: The options that are used to compute the relative URI-reference are collectively called Location-* options. Beyond Location-Path and Location-Query, more Location-* options may be defined in the future and have been reserved option numbers 128, 132, 136, and 140. The Location-Scheme and Location-Authority options are subject to all rules for Location-* options discussed in [RFC7252]. Together with Location-Path and Location-Query, the Location-Scheme and Location-Authority Options indicate a relative URI that contains either of an absolute path, a query string, or both. A combination of these options is included in a 3.01 (Moved Permanently) response to indicate the new location of the requested resource relative to the request URI. If a response with Location-Scheme and/or Location-Authority Options passes through a cache that interprets these options and the implied URI identifies one or more currently stored responses, those entries MUST be marked as not fresh. The Location-Scheme and Location-Authority Option can contain any character sequence conforming to the scheme and authority components defined in [RFC3986]. 3.2. Response Codes This specification adds the following response code. 3.2.1. 3.01 Moved Permanently This Response Code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use the indicated effective URI. The server MUST include in the response any of the following options whose values differ between the requested URI and the new effective URI: Location-Scheme, Location-Authority, Location-Path, and Location-Query. The client SHOULD use the Location field value for automatic redirection. A 3.01 response is cacheable. Caches can use the Max-Age Option to determine freshness. A 3.01 response cannot be validated. Thaler Expires March 16, 2017 [Page 5] Internet-Draft COAP Redirects September 2016 4. IANA Considerations This document adds the following option numbers to the "CoAP Option Numbers" registry defined by [RFC7252]: +--------+---------------------------+--------------------------+ | Number | Name | Reference | +--------+---------------------------+--------------------------+ | TBD | Location-Scheme | I-D.thaler-core-redirect | | | | | | TBD | Location-Authority | I-D.thaler-core-redirect | +--------+---------------------------+--------------------------+ NOTE: Section 5.10.7 of [RFC7252] reserves option numbers 128, 132, 136, and 140 for new Location-* options. Thus, the option numbers should be assigned from that set. This document adds the following response codes to the "CoAP Response Codes" registry defined by [RFC7252]: +------+---------------------------+--------------------------+ | Code | Description | Reference | +------+---------------------------+--------------------------+ | 3.01 | Moved Permanently | I-D.thaler-core-redirect | +------+---------------------------+--------------------------+ 5. Security Considerations The use case for this document is specifically to mitigate privacy concerns by allowing a request to an unsecured URI to be redirected to a secured URI. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Thaler Expires March 16, 2017 [Page 6] Internet-Draft COAP Redirects September 2016 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . 6.2. Informative References [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [I-D.ietf-core-coap-tcp-tls] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", draft-ietf-core-coap-tcp-tls-04 (work in progress), August 2016. [I-D.winfaa-intarea-broadcast-consider] Winter, R., Faath, M., and F. Weisshaar, "Privacy considerations for IP broadcast and multicast protocol designers", draft-winfaa-intarea-broadcast-consider-02 (work in progress), July 2016. [ListDiscussion] Bormann, C., "Question about Location and redirection", October 2013, . Author's Address Thaler Expires March 16, 2017 [Page 7] Internet-Draft COAP Redirects September 2016 Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA Email: dthaler@microsoft.com Thaler Expires March 16, 2017 [Page 8]