[core] (not only) RD: Authorized servers

["Christian M. Amsüss" <[e-mail]>]

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