search

w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT
https://w3c.github.io/wot-security/
18 stars 22 forks source link

Consider how to support object security #185

Open mmccool opened 3 years ago

mmccool commented 3 years ago

Does object security (eg JOSE/COSE) need additional security schemes? Is contentType enough? Do we need more than one object security scheme? How do object security schemes combine with other schemes, eg OAuth flows? Do we have just one object security scheme (differentiated by contentType) or multiple ones? How do we document how these contribute to end-to-end security (eg should the schemes define the endpoints?)

mmccool commented 3 years ago

Maybe the first step here is to make a list of existing object security schemes and review them. Here is a start:

mmccool commented 3 years ago

I'm thinking some next steps here would be to...

  1. find existing systems that use object security and consider how to model them (OCF 2.x?).
  2. build and experiment with some prototypes in a plugfest

Before doing 2, though, we would have to justify the effort with use cases, etc. This could be the case if some major ecosystem we want to integrate with WoT requires object security (and ecosystem could be a platform/standard, e.g. OCF, or it could be a domain, eg Smart Cities).

mmccool commented 3 years ago

This is also mentioned in the Best Practices document but we may want to clean it up and provide specific guidance. It also relates to TD signing (a signed TD is basically object-level security on a TD, and a directory providing signed TDs is doing object-level security on them, and a Directory is ALSO a Thing, so...).

Some use cases would be helpful (e.g. controlling a lock via a gateway providing a shadow...). Could also ask WebThings. Also there is a problem using TLS on .local domains (e.g. in a smart home), so object security might be... better than nothing.

@benfrancis any thoughts on this?

benfrancis commented 3 years ago

WebThings Gateway currently relies on:

We have never really explored signing Thing Descriptions. The assumption is basically that the client trusts the origin (e.g. a self-hosted gateway at https://example.webthings.io hosting a directory of web things, or a web thing hosting its own Thing Description at its own host) and TLS provides encryption in transit to guarantee the integrity of both metadata and data communicated with that origin.

Finding a way to extend this level of trust to local networks has been an open issue since 2017. We have experimented with numerous approaches including Service Workers, WebRTC, Alt-Svc HTTP headers (RFC 7838), and even building a WoT gateway into a home router in order to have control over the DNS configuration of the network. Ultimately none of these approaches worked.

Since this appears to be a fundamental limitation of the web rather than something WoT-specific, we have been waiting to see what comes out of the HTTPS in Local Network Community Group. Mozilla's Martin Thomson had one proposal but so far the Community Group hasn't reached any conclusions.

Signing Thing Descriptions is an interesting idea, but that only really solves the metadata part, not the (arguably more sensitive) data exchanged with a device via interaction affordances.

Note: As I understand it Apple solved this problem in the Wi-Fi version of their HomeKit specification by inventing a proprietary encryption scheme used for resources exchanged over HTTP. This is something we wanted to avoid, since all clients would need to support the encryption scheme (including web browsers using fetch()).

So in conclusion, for a thing or thing directory with a fully qualified domain on the internet we have found TLS to be sufficient. We haven't found a good solution for local networks, but the integrity of the metadata in Thing Descriptions is only one piece of the puzzle.

mmccool commented 3 years ago

Object security would apply to data returned by a Thing as well, directories are just a special case. Unfortunately the approach has big holes since headers and URLs are not protected, so (for example) in the case of a directory JSON Path queries in URLs would be visible (queries in bodies could be protected, but this implies we need to define ways to put queries in bodies for all forms of query...).

I am grasping at straws here since what we REALLY REALLY want is just a way to use TLS in a LAN... however, I was thinking object security might be better than nothing. DID is one possible solution here if it provides a way to securely distribute certificates in a way that browsers will trust (but I'm not holding my breath).

Citrullin commented 3 years ago

CoAP has some out of band methods in order to enable DTLS. https://datatracker.ietf.org/doc/html/rfc7252#section-9