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]
