WoT Security

16 Apr 2018



Kaz_Ashimura, Michael_McCool, Elena_Reshetova, Michael_Koster, Michael_Lagally, Zoltan_Kis, Kazuaki_Nimura, Tomoaki_Mizushima


<kaz> scribenick: zkis

McCool: sharing status about issues wrt changes to the Security Considerations

last meeting's minutes

<kaz> prev minutes

McCool reviews action points from last meeting

McCool: propose to add details to the actions raised by Barry
... proposed accepting the minutes.

<kaz> add the follwoing action items:
* action for barry to provide information on 2 new IETF WGs
* action for mccool to talk about testing validation timeline with security guys)
[except those 2 additional actions, the minutes have been accepted]/

ER's question about Section 6 of Security and Privacy doc

Elena: add topologies present in the plugfest
... each topology looks like application server and 2 proxies: remote and local
... they are actually gateways

McCool: the diagram is misleading
... some proxies were just tunnels
... some proxies were really proxies (e.g. Fujitsu)
... in this diagram they should be labeled differently

Elena: there is a terminology issue, it still looks like a WoT gateway
... not a network proxy per se

McCool: a proxy is that forges a request to the external network
... the tunnel will forward everything without understanding it
... one difference is that proxies will have their own security interfaces
... e.g. a remote proxy may expose HTTP, translating the protocol

Zoltan: these could be also called gateways

Elena: confused about what nodes are WoT related

McCool: yes, more careful terminology is needed - we should check with each implementation

<kaz> https://github.com/w3c/wot/blob/master/plugfest/2018-prague/preparation.md#user-content-21-4-layered-servients

Kaz: explains proxy servient, device servient and application servient

Elena: showing a picture about her understanding (from the security document) - speaking about WoT client and Wot Server, WoT remote proxy and local proxy
... why do we need remote and local proxies

McCool: the connection between the remote and local proxies may be a 3rd protocol

Elena: that explains

McCool: logically there is one servient.

Elena: we assume the connection between remote and local proxies is secure

McCool: yes

Elena: why local proxy is not exposed (to be connected to directly)

McCool: local proxy may not be exposed externally
... in practice a local proxy will call out to a cloud server and create the channel

Elena: now understood, and will redraw the picture
... another question. Do we ever have a scenario with client, servient behind NAT proxy
... do we have generic proxies as well (e.g. HTTP proxy)

McCool: this picture look like STUN

Elena: what was meant was 2 boxes: a HTTP proxy and a WoT proxy

McCool: in theory an HTTP proxy will work (if the underlying protocol is HTTP)
... but will not work if under there is CoAP

Elena: wondering what the proper description would be

McCool: we do have the scenario with HTTP - proxy - CoAP in the plugfest
... ask Siemens for clarifications about this setup
... as a concept it works, but not aware about implementation (so ask Siemens)

Elena: it would be nice to track the topologies used in plugfests

McCool: well, there is 1) simple tunneling, 2.) proxy for WoT, 3.) HTTP proxy (not specific to Things), 4.) gateway (protocol translation)

McCool: just define terminology and use it consistently

Elena: this would be beneficial not only in the Security document - there is so much overlap

McCool: define them in the Architecture document

Zoltan: just treat these as labels for roles implemented in the proxy

Elena: there is enough input now, but we should consolidate the use of the terms

McCool: create an issue at the architecture repository
... also bring it up in the main call

<kaz> wot-architecture repo

McCool: should use distinct terms for the 4 scenarios listed earlier
... for identifying security implications the definitions should be very clear

Elena: it would be better to create the scenarios in the architecture and just add security considerations on the top

McCool: until the architecture doc is fixed, we should document the scenarios locally in security and refer to them

Elena: by next call will make a PR
... but someone else should define the terms

McCool: who feels confident to pick the right terms. Michael Koster?

Koster: will help

ER will collaborate with MK on this

McCool: should kick off the discussion in the main call

<kaz> PlugFest Summary slides

Kaz: which diagrams should be used for the security discussion, the one from the Burlingame plugfest, or the current
... we should update the latest diagram on the top of the Burlingame diagram

McCool: we should agree about the terms and update the diagrams

security metadata proposal

PR #88

<kaz> wot-security pullrequest 88

McCool: examples updated with the new TD style
... since the TD spec is moving, they will still need to be updated

McCool: can we use dashes in the property names in security metadata (JSON-LD 1.1)?

Koster: probably yes

McCool: using Bearer Tokens now
... changed proxy to proxyUrl etc (similar changes)
... since OpenAPI does them this way
... another change was using "scope" again, added "pop", added "pop+https", "pop+coap"
... should discuss in TD meeting to discuss the "method" definition
... also, should discuss the final shape of "properties"
... also, during the F2F security roles were discuss - decided it was too complex
... a possibility is to use named group configurations
... these should be transparent
... need to check with the TD TF if this is fine
... one problem is the definitions may depend on the protocol
... may need to be specialized for HTTP or CoAP
... should separate security related definitions in a separate file
... to be discussed with the TD TF

issues raised by Jason Novak

* issue #72

McCool: replied quickly to each

issue #72: fingerprinting risks

<kaz> issue 72

McCool: access rights for discovery

* issue #71

issue #71: Thing Directory privacy risks (handing over information to a service)

<kaz> issue 71

McCool: there can be a malicious Thing Directory, or a sloppy one
... TD's should specify to scope of information for a Thing Directory
... but in Scripting we could have that scope

Elena: we have not discussed Thing Directory yet

Zoltan: Thing Directory is currently an application

McCool: yes, it is currently out of scope, but still is a privacy risk

Zoltan: doesn't the responsibility fall to the solution provider that implements Thing Directory?

McCool: the Scripting API does have a way to expose and discover Things; should it include meta-information about the scope of the data?

Zoltan: Scripting cannot support it if TD does not support it

McCool: it pertains to how the TD's are _distributed_

* issue #70

<kaz> issue 70

McCool: Not sure we can require not exposing immutable HW id's
... kind of out of scope
... we can strongly recommend it, but we can't require it

Elena: security is non-normative anyway

McCool: the TD TF should consider this
... the question is who is going to validate it

* issue #69

<kaz> issue 69

Elena: can make a small change to address this

* issue #68

<kaz> issue 68

Elena: can clarify in the document

McCool: the main point is the provider data needs to be protected

Elena: clarify who is the owner (user or provider)

McCool: we stop here
... we will take care and handle these issues
... will assign the issues

<kaz> [adjourned]

Summary of Action Items

[NEW] ACTION: elena to work on issue 68 (Thing Provider Data Specification) and issue 69 (Passive Observers Risk)
[NEW] ACTION: mccool to work on issue 70 (Require Not Exposing Immutable Hardware Identifiers?)
[NEW] ACTION: elena/koster to work on terminology
[ONGOING] ACTION: mccool to talk with security guys about testing/validation timeline

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/04/25 09:16:57 $