w3c / wot-security Goto Github PK

“Thing Provider Data” is defined as an asset to protect but includes “configuration data”. It was not clear if that was the Thing’s manufacturing configuration or user configuration.

“Network Attacker” is a named adversary, but the attacker type doesn’t include a passive observer of network traffic that could try and determine patterns based on network traffic (e.g. https://gizmodo.com/the-house-that-spied-on-me-1822429852).

Should we add support for Interledger payment addresses?

In addition to the address, it is necessary to specify the amount of deposit required, and perhaps the amount per use. Units also need to be specified. This will often be combined with other forms of authentication. While not strictly a security mechanism, it may be used as such (although maybe it's something only used indirectly eg at a "ticket vending" service (authorization service), not at individual IoT devices).

NOTE: We probably should support this, it at all, for prototyping reasons,
as it is not yet fully standards-track.

The note states that unique object identifiers "[c]an be a highly sensitive asset due to privacy implications of tracking” which is a good observation and the recommendation is made to avoid exposing any immutable hardware identifiers”.

Given the privacy risk, is it possible to make it be a WoT requirement (rather than a recommendation) to not expose immutable hardware identifiers?

Need to consider and clearly specify what mechanisms require being online and at what degree, i.e. some pre-setup certificate based authentication might not require 100% online time (apart from checking CRL), but smth like bearer-token based authentication with the authentication server remotely on network cannot work offline at all.

See Issue #347 in w3c/wot

Review Garcia17, in particular the threat model, and align our terminology.

See also #16, where this was done during revision of the threat modelling section (which can be used as a reference for how it should be done...)

Much of the added value for the IoT is in the services rather than the devices. This emphasises the importance of application platforms and the security scenarios around their use to support open markets of services.

Web of Things application platforms host applications that produce things for other applications that consume things, where things are objects that represent abstractions of sensors and actuators. Applications that consume things are decoupled from the IoT protocols and standards used by the sensors and actuators.

IoT devices may connect directly to cloud servers which offer things to applications on their behalf. Resource constrained devices using short range communications technologies, e.g. Bluetooth and Zigbee, require a local gateway. This can host applications that provide things for use by other applications either on the gateway, or in web pages on smart phones on the same wifi network, or they can supply the things to marketplaces on Internet cloud servers.

Whilst there are many IoT communication technologies, the vast majority of use cases for communication with application platforms can be addressed using HTTP and WebSockets in conjunction with transport layer security. One approach focuses on HTTP for discovery and transfer of thing descriptions, together with authentication and access control based upon evolving best practices for the Web.

An example is where a client requests a thing description, and is authenticated by the server and authorised to access the thing via WebSockets using a time limited security permit that is passed over the encrypted WebSocket connection when the client registers the consumed thing with the server. A fresh HTTP request can be made when a new security permit is needed.

Another example is where an app on a gateway is seeking to make a thing accessible on an Internet server. In this case, the HTTP request passes a thing description to the Internet server which then authenticates the app, and authorises it to supply the thing. The security permit is then passed to the Internet server via a registration message exchange over an encrypted WebSocket connection. The security permit is never exposed to the applications.

The HTTP request should identify what needs to be authorised and on behalf of whom, the thing, the application and the user/owner. The details need further scrutiny of specific use cases, and should consider what is needed to balance security and user experience.

For example, Joe finds a new application on a web site and installs it on his home gateway. This allows Joe to access his home security system from a web app or native app on his phone when he is out of the house. For this, Joe has to set up an account with the Internet cloud based app store. The process automatically transfers the associated security credentials to the gateway minimising the effort needed from Joe.

p.s. some further background is available in the scripting task force issue 64

See: w3c/wot-scripting-api#64

There should be a discussion of fingerprinting risks given that a WoT configuration (e.g. what devices are where) is likely unique and can uniquely identify a user. Moreover, fact that two people who have the same WoT configuration are likely in the same physical location.

Fix CSS to format tables in threat model and (perhaps; to discuss) use definitions for threat model names.

The simplest assumption would be that WoT Clients trust Things and want to ensure that TDs really come from the Thing they describe. For this, Things themselves need to sign their TDs.

This limits how Things can be made available beyond NATs and Firewalls. For instance:

Scenario port forwarding (as shown by Intel in PlugFest): When set up independently, the TD must be modified to point to the new endpoint address (IP+port). To make the Thing itself aware of that, it might make sense to configure the "listen addresses" at the Servient.

Scenario forward proxies (as shown by Siemens in PlugFest): The proxy metadata has to be added. Since the proxy usually creates a new trust model (proxying into a trusted network), an entity associated with the proxy can edit the TDs and also sign them. WoT Clients will need to trust this entity.

Scenario reverse proxy (as shown by Fujitsu in PlugFest): Here the reverse proxy looks like the origin Thing to the WoT Client. The proxy is in fact publishing the TD, and hence can also sign it.

Decide whether or not provisioning of security materials (certificates, etc) is in WoT scope.

Make sure that security topics are aligned with summary security section in wot-architecture document.

Define security requirements for next plugfest. See
w3c/wot-scripting-api#82 (comment)
were some security issues have recently been brought up.

In scripting API, there is discussion about whether Things should be Exposed but not Discoverable (and vice versa?). Should coordinate discussion here with that discussion, and also in Security TF and document, discuss use cases/rationale for making Exposing/Consuming and Discoverable/Hidden being separate functions.

To get some progress, I want to quickly document how node-wot currently supports security mechanisms based on TD metadata.

When starting a runtime, commission it with its credentials:

this.addCredentials(this.config.credentials);

When initializing the client-implementation for a new ConsumedThing, configure it with the TD security metadata:

client.setSecurity(this.td.security);

Inside client implementation create a request that applies the available credentials to the required the security mechanism defined in the metadata (actually node-wot only does this once, not for every request):

  if (security.authorization === "Basic") {
    // configure for Basic Auth
  } else if (security.authorization==="Bearer") {
    // configure with Bearer token, maybe contact auth server to get one if not available
  } else if (security.authorization==="Proxy") {
    // configure request to go through a proxy
  }

TD security examples. Note that an identifier is needed for the Thing described. I used @id with a URN. I loosely based that on https://tools.ietf.org/html/draft-arkko-core-dev-urn-05:

    "@id": "urn:dev:wot:fujitsu-beacon",
    "security": {
        "authorization": "Bearer",
        "alg": "ES256",
        "as": "https://plugfest.thingweb.io:8443/"
    },

  "@id": "urn:dev:wot:festo",
  "security": {
    "authorization": "Proxy",
    "proxyAuthorization": "Basic",
    "href": "http://plugfest.thingweb.io:8087"
  },

Runtime configuration example. Note that the key in the credentials object ties it to the Thing's @id:

    "credentials": {
        "urn:dev:wot:fujitsu-beacon": {
            "token": "eyJhjGciUzI1NiJ7OiJF.eyJhdWQiOiJOaWNlUGx1Z2Zlc3RSUyIsInN1YiI6IjA2OTgyMWE4LTlmMwUxM2EwDYtNDJhYS1hYjkyLWQ0ZYTlkZSIIk5pY2VQbHsImlzcyI6VnZmVzdEFTIiwidHlwIjoib3JnOncz0ndvdDpqd3Q6YXM6bWluIiwianRpIjoiNjtZWY3Yy00NmRjYTU0OGMM2LWI3N2MtYWM2OTg4MzBjODIxIn0.TOMCAG-MUVuOJ4LVknfWbmXEQWgLOC2jyRDC-Z1kg6tKngpvflWxJLFMVRS7D9M2sFVOmR3gt00nwN7LZZMn5w"
        },
        "urn:dev:wot:smartspace-couch": {
            "asToken": "yI1NiTsInR5fCI3IkpXeyJhbGciOiJIUVCJ9.I6IjVhexJpZCMmU5ZWMxZMDAxMTNlZDWM3OWMwY0YSIsImlhdCI6MTUxMzE3MTEzMSwiZXhwIjoxNTEzMjU3NTMxfQ.sLjtWu-KSnAZOZN0PvGbF911Sfq5NeiNWYRqlKgx4v4"
        },
        "urn:dev:wot:festo": {
            "username": "user",
            "password": "secret123not"
        }
    }

P.S.: While checking the actual code now, I noticed a gap that might have been caused by merging with the Prague branch. Will work on that...

Intro cites and links to Thing Description, Scripting API, and Binding Templates (broken?), but not Architecture document. Add citation to architecture document, and explain better (one sentence) the role of each document.

Intro should also say a bit more about the role of this document (elaborating on the abstract), perhaps summarizing some of the main points from the document.

Does this even make sense for machine to machine IoT APIs?

need to clean up Threat model definition references and table formatting.

Separate section, main points, even if we mention other privacy things separately in the document. However, this section can refer to issues specifically relevant to privacy, including specific legal requirements.

Dave to create an initial PR - just an Editor's para listing the things we should include.

Need to find a privacy expert - Soumya, perhaps person who presented at last F2F on privacy

The apikey authorization scheme leaves open the format of the API key, so it is assumed opaque. An alternative to an API key is a JWT token, which has similar properties but also includes information about the source, expiry date, and other useful information. We should look at how API keys are used in practice to see if any additional parameters are needed.

Does OpenIDConnect even make sense for IoT devices? It may make sense for authentication servers, but those generally only be referenced by Things, not running on them.

Most of the references (IIC, IETF IoT Security State of the Art, etc) on best practices make reference to a security lifecycle. We should define or refer to a lifecycle, and clarify what parts of the lifecycle the WoT is appropriate for enabling.

The conservative approach would be to say it only applies the "Operational Phase" and not during onboarding, etc. This is a reasonable place to start (see also Issue #15), and if in particular the TD is only provided to already-trusted devices than a certain set of threats will be mitigated. Longer-term, we may want to look at supporting on-boarding.

In particular, in the pattern where a TD is available from somewhere other than the device, or is available via a special channel (eg a URL provided by a bluetooth beacon), then the TD could include information required to authenticate with/to the device and to help onboard it as a trusted device. However, if the TD is provided to untrusted devices to assist pre-onboarding discovery, then it may have to be subsetted.

Define set of requirements and an example for the industrial use case.

Populate initial material for this section, including references to external standards and documents that recommend good security practices for IoT. These references can all be informative as the entire document is meant to be informative.

Define set of requirements and an example for the enterprise use case.

Take a look on opportunities from using blockchains for authentication in WoT

After we get through TPAC, and during, gather feedback on practical security configuration use cases and requirements and include them in the document(s).

Fill in missing material in Security and Privacy Considerations document under the Examples section.

Resolved by pull request #24

Need to get more understanding on what type of scenarios we want to support and what type of security metadata would fit it better. Possible options: nesting, array of independent elements etc.

Is "DOS resistance" a defined term? If so, where are they defined, and do we need links?

@zolkis:
If defined, we should use links. If not defined, we can use the term as a prose, since the WoT group is not required to give a formal, later referenceable definition of 'DOS resistance'.

@ereshetova:
This was actually a comment from Michael that I haven't yet decided how to handle.
We have a standard set of security terms and I haven't seen an example how one would reference such terms from this doc. Do you have an example of referencing outside term form a WoT doc?

The Things Directory, WoT Servient Gateway, and Gateway with Remote Cloud are discussed as Examples of WoT security configurations but they aren’t discussed as privacy risks, e.g.:

• The Thing Directory can amass a profile of the Thing Descriptions that a given client downloads, and, by extension, have knowledge about that user’s home configuration;
• The Thing Gateway is not considered in the risks and seems like it has privacy risk insofar as it would be a mechanism to intercept and amass a user’s interactions with their Things.

There is a lifecycle for TD updates that also interacts with caching, etc. We have to figure out if the TD update lifecycle (when it is better defined) interacts in any important way with security. One issue I can see is that if public keys are published in the TD, then if keys need to be rotated, then these will change and the TD will have to be updated. This may not, however, be a good pattern to distributed public keys.

The following should be considered:

• Amazon AWS IoT
• .....

Need to update section 5 where relevant

This could be where we satisfy the need for a security testing plan, as required by the charter...

CORS is now considered obsolete, having been replaced with Fetch: https://fetch.spec.whatwg.org/
We should leave in the reference to CORS but also mention Fetch.

References to items defined outside the threat model section need to be updated to refer to the new names and ReSpec definitions.

In 4.1.1 Secure Delivery and Storage of Thing Description, the document blurs the uses of authentication (assuring the message came from its intended sender) and integrity-protection (assuring message contents are completely and only what the sender intended). It should mention both.

I'd include a stronger SHOULD for confidentiality everywhere. Even when no sensitive-seeming data is being exchanged, the possibility that sensitive data could be gleaned from the aggregate transmission or by its linkage to other communications is high (see Pervasive monitoring is an attack ).

https://www.w3.org/TR/2017/NOTE-wot-security-20171214/#secure-delivery-and-storage-of-thing-description

Which OAuth2.0 flows are relevant to IoT devices? Do we care about OAuth1.0?
What about versions in general?

Create a PR with a cleaner abstract using full sentences, etc.

This document covers the setup for the Burlingame PlugFest:
https://github.com/w3c/wot/blob/master/plugfest/2017-burlingame/preparation.md#3-plugfest-scenarios

It doesn't really belong here. We just want to refer to it, so it should be in the Architecture document.

Today, devices may be compatible with multiple IoT platforms (e.g. a lightbulb may work with Amazon Alexa, Google Home, Apple HomeKit, and its own Zygbee backed application). The WoT Primary Stakeholders includes Device Manufacturer (OEM), Thing Provider or Thing Integrator, and Thing User, and does not discuss the role of these platforms (although one could argue they are Thing Providers). As a result, the role of platforms aren't addressed elsewhere in the document (e.g. Attackers).

It may be worthwhile to include some notion of platforms in WoT as it seems likely that a WoT Thing may support one or more existing platforms and defenses/attacks should consider such.

TODO: "WoT Interface" is a term for the network API of a Thing
defined in the WoT architecture document. How do we refer to these,
and can we link to their definitions?

@zolkis
Yes, we should link to the WoT Terminology, from the Architecture Document.
https://w3c.github.io/wot-architecture/#terminology
Currently it is in a markdown.

In fact, the WoT Interface is the (network) interface of the WoT Runtime or WoT Servient (although I prefer the former term). The Scripting API is a middle API to help implementing a WoT Runtime. The Protocol Bindings are also a way to implement a WoT Runtime.
I made a relevant comment in this issue:
w3c/wot-architecture#35

Check all http-only reference links and upgrade them to https if possible.

The Thing User has a security goal of "Don't want their data to be exposed to any other thing user, Thing provider or OEM unless intended (Data confidentiality). Don't want their data to be modified unless intended (Data integrity).”

It would be worthwhile to include a goal of consent to ensure not just that the user is aware that their data is being shared but also that they consented to it.

Things directories should have some mechanism to only expose a limited set of TDs to querying parties. Need a discussion on methods to do this.