Internet DRAFT - draft-thaler-core-redirect

draft-thaler-core-redirect







Network Working Group                                          D. Thaler
Internet-Draft                                                 Microsoft
Intended status: Informational                          October 31, 2016
Expires: May 4, 2017


                             COAP Redirects
                     draft-thaler-core-redirect-01

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 May 4, 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 May 4, 2017                  [Page 1]

Internet-Draft               COAP Redirects                 October 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.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Alternatives Considered . . . . . . . . . . . . . . . . . . .   4
     2.1.  Just use normal multicast discovery . . . . . . . . . . .   4
     2.2.  Just use a resource directory . . . . . . . . . . . . . .   4
     2.3.  Use Alternative-Address . . . . . . . . . . . . . . . . .   5
   3.  Redirects . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Option Definitions  . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  Location-Scheme and Location-Authority  . . . . . . .   5
     3.2.  Response Codes  . . . . . . . . . . . . . . . . . . . . .   6
       3.2.1.  3.01 Moved Permanently  . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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.





Thaler                     Expires May 4, 2017                  [Page 2]

Internet-Draft               COAP Redirects                 October 2016


   o  Correlation across time: If a COAP server is available
      periodically in the same location over a long time, an attacker in
      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.

1.1.  Example

   Existing clients conforming to the OIC 1.1 Core spec [OIC1.1Core]
   sections 10 and 11.3.5 do discovery by sending a multicast CoAP GET
   for "/oic/res".  Existing servers will respond with links to a set of
   resources, but that information might be privacy-sensitive in some
   cases.  For example, it might contain sufficient a unique identifier



Thaler                     Expires May 4, 2017                  [Page 3]

Internet-Draft               COAP Redirects                 October 2016


   of the server, or information sufficient for an attacker to determine
   what version of what software it runs.  (A sample response can be
   found in section 10.2 of [OIC1.1Core].)  Hence a privacy-sensitive
   server needs a way to be discovered by trusted clients without
   revealing privacy-sensitive information to untrusted observers.  A
   redirect allows a client to send the same request, thus not
   increasing the amount of multicast traffic on the network.

   For example, consider a network with a privacy-sensitive server, and
   a legacy server.  A client wants to efficiently discover both
   servers.  The client can send a single multicast GET for "/oic/res",
   and the legacy server would send a unicast response with the
   requested data, whereas the privacy-sensitive server would respond
   with a unicast redirect to "coaps://<ipaddr>:<port>/oic/res".  The
   client can then generate a unicast GET over coaps to get the actual
   data, if permitted, from the privacy-sensitive server.  This
   mechanism keeps the latency and number of messages to a minimum.

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
   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.







Thaler                     Expires May 4, 2017                  [Page 4]

Internet-Draft               COAP Redirects                 October 2016


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)     |
   +--------+--------------------+--------+--------+------------+

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.




Thaler                     Expires May 4, 2017                  [Page 5]

Internet-Draft               COAP Redirects                 October 2016


   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.

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]:




Thaler                     Expires May 4, 2017                  [Page 6]

Internet-Draft               COAP Redirects                 October 2016


   +------+---------------------------+--------------------------+
   | 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.

   Preventing identifying information from being observed by untrusted
   clients doing multicast discovery is necessary but not sufficient to
   mitigate the privacy issues discussed in Section 1.  That is, one
   must also use an authentication scheme for subsequent unicast
   messages that does not reveal a stable identifier to clients before
   authentication is complete.  Mutual authentication schemes exist
   (e.g., [Balfanz]) that only reveal the identity of both endpoints if
   authentication succeeds, but they may not yet be available in current
   standards and popular code bases.

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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

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,
              <http://www.rfc-editor.org/info/rfc6973>.



Thaler                     Expires May 4, 2017                  [Page 7]

Internet-Draft               COAP Redirects                 October 2016


   [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,
              <http://www.rfc-editor.org/info/rfc7231>.

   [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,
              <http://www.rfc-editor.org/info/rfc7721>.

   [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-05 (work in progress),
              October 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-03
              (work in progress), September 2016.

   [Balfanz]  Balfanz, D., Durfee, G., Shankar, N., Smetters, D.,
              Staddon, J., and H-C. Wong, "Secret Handshakes From
              Pairing-based Key Agreements", May 2003,
              <http://ieeexplore.ieee.org/document/1199336>.

   [ListDiscussion]
              Bormann, C., "Question about Location and redirection",
              Symposium on Security and Privacy 2003, October 2013,
              <https://www.ietf.org/mail-archive/web/core/current/
              msg04867.html>.

   [OIC1.1Core]
              Open Connectivity Foundation, "OIC Core Specification
              V1.1.0", 2016, <https://openconnectivity.org/wp-
              content/uploads/2016/10/OIC_1.1-Specification.zip>.

Author's Address

   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: dthaler@microsoft.com



Thaler                     Expires May 4, 2017                  [Page 8]