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

From: Klaus Hartke <[email-masked]>
Date: Tue, 5 Mar 2019 13:47:36 +0100

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Mar 2019 16:09:13 +0100

On Mar 5, 2019, at 13:47, Klaus Hartke <[email-masked]> wrote:
> to <coap://kefer.example/42/> with link relation type “hosts".

Right.

> named <coap://kefer.example/42/>. That doesn't seen to make a lot of

Sense-making is a complex function.
In most environment, we can’t forbid everything that doesn’t make sense.

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

Well, there is a statement in there: “If you want to discover information about kadse, it may be of interest that kefer hosts that resource over there.”  Without additional context, that may be nonsensical, but with an RT, it might point to any kind of resource that is of interest in conjunction with knowing about the current server.

E.g., a CoAP server could point to a data backup server (and, probably, hope that that one over there indeed backs up this server, but it doesn’t know!).

> otherwise using links” [4]

Then don’t do that.

> that need to be mitigated. In particular,
> links that “associate a link’s context with another resource cannot be
> trusted

This is a nice example of a misuse of the word “trust”.  How do you “trust a link”?
It is obvious that the device exhibiting this link wants you to know it, and (assuming some form of integrity, which is missing in the example), you can “trust that”, but that’s all you can trust.
Whether that has influence on what you do next depends on your authorization policies.

> since they are effectively assertions by a third party that
> could be incorrect or malicious.”

Right.  In CoAP we have much less of “automatically following” (we don’t even have redirects!).

> Link Format representation associates the link's context with another

I can’t parse this sentence.  Links associate “contexts” (bad name for the source of a link) to target resources.  Section 2.1 only helps you find out what the “context” is (and I agree, it exhibits some weirdness).

> What’s the security model of Link Format?

6690 pretty much punts to 5988 here.
And that already has above’s “then don’t do it”.
(And reminds people that you need integrity protection/authentication if you want to do something grave based on the information.)

> That is, what are the rules
> that client should follow for trusting links

Don’t “trust”, except in the sense of “this device wanted to give you that information”.
We don’t treat discovery information as signed claims, right?
But claims they are.

> in .well-known/core

I think an even more interesting problem is that a link-format can contain coaps:// links without any indication on the kind of security that goes with that.  That is a discovery problem we haven’t solved very well yet.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 5 Mar 2019 17:57:35 +0100

> Well, there is a statement in there: “If you want to discover information about kadse, it may be of interest that kefer hosts that resource over there.”  Without additional context, that may be non…

There is a difference between kadse.example saying e.g. "my billing
server is located at <coap://kefer.example/42/>" and "kefer.example
hosts a billing server at <coap://kefer.example/42/>".

> This is a nice example of a misuse of the word “trust”.  How do you “trust a link”? [...]

That sounds like a very good definition for "trust". You trust a link
if your authorization policies allow you to do something next.

> I can’t parse this sentence.  Links associate “contexts” (bad name for the source of a link) to target resources.  Section 2.1 only helps you find out what the “context” is (and I agree, it exhibit…

RFC 8288 suggests that a client discards any link where the actual
link context is overridden. This is the case for every link in Link
Format. (Because if there is no anchor attribute that overrides it,
Section 2.1 overrides it with the "origin" of the link target.)

Klaus