Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider how to support object security #185

Open
mmccool opened this issue Sep 14, 2020 · 6 comments
Open

Consider how to support object security #185

mmccool opened this issue Sep 14, 2020 · 6 comments

Comments

@mmccool
Copy link
Contributor

mmccool commented Sep 14, 2020

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
Copy link
Contributor Author

mmccool commented Sep 14, 2020

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

@mmccool
Copy link
Contributor Author

mmccool commented Nov 16, 2020

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
Copy link
Contributor Author

mmccool commented Apr 12, 2021

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
Copy link
Member

benfrancis commented Apr 13, 2021

WebThings Gateway currently relies on:

  • TLS for encryption
  • JWT for authentication
  • OAuth for authorisation

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
Copy link
Contributor Author

mmccool commented Apr 20, 2021

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants