W3C home > Mailing lists > Public > public-wot-ig@w3.org > April 2018

[wot-security] minutes - 16 April 2018

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 25 Apr 2018 18:22:12 +0900
Message-ID: <CAJ8iq9WYGZWfmzt_=PrANtuNCVBENRYsqg--s7HwZZzn3YuVRQ@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
  https://www.w3.org/2018/04/16-wot-sec-minutes.html

also as text below.

Thanks a lot for taking these minutes, Zoltan!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                              WoT Security

16 Apr 2018

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda

Attendees

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

   Regrets

   Chair
          McCool

   Scribe
          zkis

Contents

     * [3]Topics
         1. [4]last meeting's minutes
         2. [5]ER's question about Section 6 of Security and
            Privacy doc
         3. [6]security metadata proposal
         4. [7]issues raised by Jason Novak
               o [8]issue #72
               o [9]issue #71
               o [10]issue #70
               o [11]issue #69
               o [12]issue #68
     * [13]Summary of Action Items
     * [14]Summary of Resolutions
     __________________________________________________________

   <kaz> scribenick: zkis

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

last meeting's minutes

   <kaz> [15]prev minutes

     [15] https://www.w3.org/2018/04/09-wot-sec-minutes.html

   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>
   [16]https://github.com/w3c/wot/blob/master/plugfest/2018-prague
   /preparation.md#user-content-21-4-layered-servients

     [16] 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> [17]wot-architecture repo

     [17] https://github.com/w3c/wot-architecture

   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> [18]PlugFest Summary slides

     [18] https://github.com/w3c/wot/blob/master/plugfest/2018-prague/docs/PlugfestSummary180326a.pdf

   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> [19]wot-security pullrequest 88

     [19] https://github.com/w3c/wot-security/pull/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> [20]issue 72

     [20] https://github.com/w3c/wot-security/issues/72

   McCool: access rights for discovery

* issue #71

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

   <kaz> [21]issue 71

     [21] https://github.com/w3c/wot-security/issues/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> [22]issue 70

     [22] https://github.com/w3c/wot-security/issues/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> [23]issue 69

     [23] https://github.com/w3c/wot-security/issues/69

   Elena: can make a small change to address this

* issue #68

   <kaz> [24]issue 68

     [24] https://github.com/w3c/wot-security/issues/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 [25]issue 68 (Thing Provider
   Data Specification) and [26]issue 69 (Passive Observers Risk)
   [NEW] ACTION: mccool to work on [27]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

     [25] https://github.com/w3c/wot-security/issues/68
     [26] https://github.com/w3c/wot-security/issues/69
     [27] https://github.com/w3c/wot-security/issues/70

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


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

     [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [29] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 25 April 2018 09:23:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 25 April 2018 09:23:23 UTC