Subject: [core] (not only) RD: Authorized servers

From: Christian M. Amsüss <[email-masked]>
Date: Wed, 21 Oct 2020 02:03:27 +0200

Hello CoRE,

one of the outstanding issues in RD is server authorization with respect
to operations on particular paths. This continues an ACE thread[1] I
regrettably missed to follow up on, but simplifies the examples based on
the recent interims. While originally phrased as the attacker tricking
the server into using the client's good credentials for something the
client did not intend, here they are phrased now in terms of server
authorization as relevant for RD discovery and RD security policies.

For two examples, a client needs to trust a server to provide a service,
but has received misleading hints that cause disagreement between the
client and the server about the performed operation.

Example 1
=========

An RD with a "links are confidential" policy also operates a bulletin
board at `/bb`. During the unprotected discovery phase, the endpoint is
fed a link `<coap://rd.example.com/bb>;rt=core.rd`.

The client connects to rd.example.com, verifies that its server
credentials are good for an RD that will reveal links posted to it only
to authorized lookup clients.

It then posts all its links to /bb, where anyone who knows to use a
bulletin board can read them.

Example 2
=========

A time server also exposes its current core temperature as
`/monitoring/temp`.

A malicious RD operator modifies the time server's registration to read
`<coap://time.example.com/monitoring/temp>;rt=unixtime`.

A starting device in the network asks the RD for any rt=unixtime,
verifies that time.example.com is indeed authorized to give the right
time, and wakes up on the morning of January 1st, 1970.

Problem summary
===============

The client has an abstract intention with an operation, which it checks
against the server's authorization. Then it forms that intention, with
additional unverified knowledge about the server, into a request, which
it protects. The server then reconstructs that intention with its
authoritative knowledge of itself, and uses any client provided
credentials to act on it.

If the client's knowledge about the server is erroneous, the intentions
are misaligned. Neither is the intention protected, nor does the client
point out the claims it wants to hold the server to in its request (or,
in the original examples from the ACE thread, express the precise claims
about itself it intends the server to assess).

Solution approaches
===================

In the ACE thread back then, Jim said that he'd expect the client to use
different keys (originally in talking to the AS, and thus different keys
in talking to the RS). Doing that to the end would probably result in
the devices having to handle a lot more keys, something like one for any
operation that could be mixed up with any other?

Michael in the last interim mentioned that in OAuth it's common to only
run one service on one host for the very same reason. Kind of boils down
to the same thing, as virtual-hosting these services would create
multiple keys.

My approach in the -25 RD Section 7.2 is to (losely, there; would
need stronger and more precise wording) say that any information that
any information using which intention is encoded in the request in a
lossy way is to be rechecked from the origin server. That'd be more or
less straightforward for example 1, but incur an additional costly
recheck with the origin server about many things that could be learned
efficiently from the RD.

Does any of that solve the issues?

Can we do any better?

How do we put that into RD to satisfy the small comment about Section
7.2 that opens this can of worms? Is there anything quotable on OAuth's
best practices on multiple services on the same host?

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/ace/TLIbCfU0unm1el99Kjo2eoB37Qw/

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Christian M. Amsüss <[email-masked]>
Date: Wed, 21 Oct 2020 02:10:15 +0200

... and I missed to capture Carsten's input from the interim:

> Solution approaches

Carsten suggested that the server's claims should be more precise about
its paths, promising to keep links confidential *when posted in RD
registrations to /rd* and to serve time *when requested from /time*.

For example 2, this would roughly mean that the information that would
need to be obtained in the "verify again with origin server" model is
contained in the certificate, or more generally in the sets of claims
exchanged about the server at some point.

KR
Christian

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Oct 2020 18:21:55 -0400

Hi, I'm not very well informed about the RD document.
I have skimmed the document at various intervals.
And these comments are rather late, I agree.

It seems to me that a fundamental problem with the whole RD concept is that
it must make the secure identities part of the result.

It's not really interested to say that 2001:db8:3::127 has a oic.d.sensor.
What's interesting is to say that principal X, (who was seen at address 2001:db8:3::127),
has an oic.d.sensor.

Section 7.1 has placed the RD in the place of trying to be a gate keeper for
accurate information, which is just can't do in a general way for arbitrary
clients with abitrary policies.

I think that it would be much simpler and more secure if we restarted and did
the security first rather than last.  That does mean that one has to pick one
(or a very small number) of security systems to work with.  This is not a
place were we can or should attempt to generalize.

I'm sorry if this is a rather depressing suggestion.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Esko Dijk <[email-masked]>
Date: Mon, 26 Oct 2020 16:21:56 +0000

"principal X" maybe does not need to be explicitly named. Or maybe it could name itself as currently done using the 'ep' endpoint name.
For reference how such security could be accomplished, see https://tools.ietf.org/html/draft-ietf-dnssd-srp-04

This is the DNS-SD equivalent of CoRE RD and it uses a public/private key signing solution to prevent other devices modifying a device's entries. The registration is on a first-come-first-served naming principle.
Not sure if this would fit with CoRE-RD, which may need to deal with multiple CoRE security solutions out there, but at least the advantage of what DNS-SD SRP proposes is a single security method that all devices can use, so interoperability becomes far easier to achieve.

Esko