[core] Trusting links in .well-known/core

Klaus Hartke <hartke@projectcool.de> Tue, 05 March 2019 12:48 UTC

Return-Path: <hartke@projectcool.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36A513106C for <core@ietfa.amsl.com>; Tue, 5 Mar 2019 04:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEZmEZ0hq8mj for <core@ietfa.amsl.com>; Tue, 5 Mar 2019 04:48:16 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406511310BE for <core@ietf.org>; Tue, 5 Mar 2019 04:48:16 -0800 (PST)
Received: from mail-qk1-f179.google.com ([209.85.222.179]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1h19UT-00046d-7d; Tue, 05 Mar 2019 13:48:13 +0100
Received: by mail-qk1-f179.google.com with SMTP id i5so4664393qkd.13 for <core@ietf.org>; Tue, 05 Mar 2019 04:48:13 -0800 (PST)
X-Gm-Message-State: APjAAAV+2Ofap7zZpy+vezgZ4P7aLLgRDiml8cY7SFUMmshBeCGdpCOS bbsoUM7WOdHWZTfCxaB5U8Y12Q//C7c7AI/O5eA=
X-Google-Smtp-Source: APXvYqwyYmmnmEa2cXhBOCcPLyPQf7lNGH7LdlLjJBFzcHSp41Ca1Yta6bYa+9VAHG+1QdhtB3QA2NGYbXqMc3qraIE=
X-Received: by 2002:a05:620a:12a5:: with SMTP id x5mr1535133qki.291.1551790092200; Tue, 05 Mar 2019 04:48:12 -0800 (PST)
MIME-Version: 1.0
From: Klaus Hartke <hartke@projectcool.de>
Date: Tue, 5 Mar 2019 13:47:36 +0100
X-Gmail-Original-Message-ID: <CAAzbHvZ+6mj6GwywyAxzUf05B9+ArRSDn4XDumR+AF66ATGWzg@mail.gmail.com>
Message-ID: <CAAzbHvZ+6mj6GwywyAxzUf05B9+ArRSDn4XDumR+AF66ATGWzg@mail.gmail.com>
To: "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1551790096; 3de70091;
X-HE-SMSGID: 1h19UT-00046d-7d
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/oVEl3TQO4S9NL4YG-aClMSjmwOk>
Subject: [core] Trusting links in .well-known/core
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 12:48:20 -0000

RFC 6690 defines "CoRE Resource Discovery" as "discovery of resources
hosted by a constrained web server" [1]. The RFC then proceeds to
specify that "resource discovery in CoRE is accomplished through the
use of a well-known resource URI that returns a list of links about
resources hosted by that server" [2].

Let's say a client requests a representation of .well-known/core from
server 'kadse.example' and gets a link to a resource on
'kefer.example':

=>
   GET coap://kadse.example/.well-known/core

<=
   2.05 Content
   Content-Format: application/link-format

   <coap://kefer.example/42/>

Because of Section 2.1 of RFC 6690 [3], the context of this link is
<coap://kefer.example/>. So it's a link from <coap://kefer.example/>
to <coap://kefer.example/42/> with link relation type "hosts".

In other words, the client says it wants to discover the resources
hosted by (coap, kadse.example, 5683) and (coap, kadse.example, 5683)
says that there is a resource hosted by (coap, kefer.example, 5683)
named <coap://kefer.example/42/>. That doesn't seen to make a lot of
sense.

Are such links currently allowed? If yes, should they be forbidden?

Furthermore: RFC 8288, on which RFC 6690 is based, notes that there
are "attack vectors opened by automatically following, trusting, or
otherwise using links" [4] that need to be mitigated. In particular,
links that "associate a link's context with another resource cannot be
trusted since they are effectively assertions by a third party that
could be incorrect or malicious."

Because of Section 2.1 of RFC 6690 [3], essentially *every* link in a
Link Format representation associates the link's context with another
resource.

What's the security model of Link Format? That is, what are the rules
that client should follow for trusting links in .well-known/core
representations in Link Format?

Klaus

[1] https://tools.ietf.org/html/rfc6690#section-1
[2] https://tools.ietf.org/html/rfc6690#section-4
[3] https://tools.ietf.org/html/rfc6690#section-2.1
[4] https://tools.ietf.org/html/rfc8288#section-5