W3C home > Mailing lists > Public > public-wot-ig@w3.org > May 2017

[wot-security] minutes - 5 May 2017

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 5 May 2017 22:49:18 +0900
Message-ID: <CAJ8iq9U13ZsLCPZ5WNO4=gWvTBvack1_u+pFr4TnSzfM9HPsHQ@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>
available at:

also as text below.





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

                               - DRAFT -

                           WoT IG - Security

05 May 2017


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

   See also: [3]IRC log

      [3] http://www.w3.org/2017/05/05-wot-sec-irc


          Michael_McCool, Zoltan_Kis, Elena_Reshetova,
          Daniel_Ibaseta(observer), Kaz_Ashimura, Michael_Koster




     * [4]Topics
         1. [5]WOT Threat model & security objectives
         2. [6]f2f planning
     * [7]Summary of Action Items
     * [8]Summary of Resolutions

   we invite Daniel from CTIC as a guest today

WOT Threat model & security objectives

   Elena's resource is a pullrequest to be merged

   <McCool> [9]https://github.com/w3c/wot/pull/318 Elena's

      [9] https://github.com/w3c/wot/pull/318

   Elena: explains her proposed thread model description
   ... which is to be merged

   McCool: security model provided by the underlining protocols?
   ... or something specific for wot itself?

   Elena: threat model of protocols vs application layer
   ... some messages might be reordered or delayed

   McCool: layering our threat model
   ... on the top of underlying protocols

   Elena: first column is regarding the stakeholders
   ... thing manufacturer (oem), solution provider and solution

   McCool: provider creating new things?
   ... user using things which are created by providers?
   ... possibly both at once

   Elena: you can have flexible definition
   ... there might be a number of solution providers

   McCool: there are similar tables by other SDOs
   ... you might outsource or contract of our systems to 2nd/3rd
   ... factory owners may ask the others to maintain the factories
   based on some contract
   ... issue you need to delegate responsibilities to people

   Elena: ok. but it's important to think about these roles
   ... 3 basic stakeholders

   McCool: can imagine some nested situations
   ... a user can add some additional services
   ... multiple security owners are possible

   Elena: do we have any tree structure or hierarchy?

   McCool: e.g., ISP provides some box for network connection
   ... let's make a list of issues and see which are in/out of

   Elena: bootstrapping

   McCool: let's assume a tree and see if it works

   Elena: there could be a higher tree

   Zoltan: there may be contracts between manufacturers
   ... different deployment mechanism

   McCool: how general setting do we allow here?

   Elena: would explain the detail during the f2f

   Zoltan: where do we want to file the issues for the security

   McCool: I raised an issue about that within the Chairs group
   ... we would raise issues within the IG
   ... let's revisit the detail on how to handle them after the

   Kaz: wondering if "solution provider" means "thing exposer" and
   "solution user" means "thing consumer", because we've been
   using them for discussions on TD/Scripting

   McCool: kind of similar

   Elena: it's similar idea but maybe different
   ... it's not only denoting physical things

   Zoltan: this is related to WoT assets
   ... not stakeholders

   Kaz: let's talk about the relationship during the f2f

   Elena: ok

   <McCool> McCool: let's discuss relationship of thing roles and
   stakeholder types in F2F or in a future meeting... need to
   create issue

   Elena: explains the description on Thing Description (TD)
   ... does not contain any confidential or privacy sensitive
   information. however, its integrity is crucial for the system
   correct operation.
   ... let's go for asset first
   ... who should have access (trust model)
   ... TDs owner: full access
   ... Others: read only
   ... Attack points:
   ... storage on thing itself, cloud storage, in-transfer
   (network) including TD updates
   ... next
   ... solution user data:
   ... different solution users might have different level of
   access to this data based on the use case.
   ... mechanism should be flexible to configure and include also
   ... Others: should have no access unless specifically allowed
   ... storage on thing itself, solution provider storage (remote
   cloud or other), in-transfer (network)

   McCool: things can have actuators, can affect physical world;
   these are also assets

   Elena: good idea to add asset
   ... will modify this table
   ... next
   ... solution provider scripts and their configuration data:

   Elena: solution provider: full access
   ... others: no access
   ... storage on the thing itself, remote storage (if scripts are
   backed up to a remote storage), in-transfer only for initial
   provisioning and scripts updates

   McCool: we should have discussion on how to manage issues

   Kaz: why don't we have a separate repo, wot-security, so that
   both the IG guys and the WG guys can make contribution

   McCool: there are 3 possibilities
   ... under IG, under WG or a separate repo
   ... need to talk with the other co-Chairs

   Elena: would like inputs from the other WoT participants
   ... the more we can get inputs, the better

   Kaz: let's send a proposal to the Chairs list
   ... at the moment, we can record issues here within the minutes

   McCool: let's go through this document
   ... maybe we should categorize the issues into 2 categories
   ... basic model and new things

   Elena: what about updating?

   Zoltan: image-based and script-based

   McCool: good idea to talk about the basic model first

   Elena: will update this table accordingly
   ... btw, do we want to support access model for co-existing
   ... some providers might have relationship with other providers

   McCool: if we assume only one provider, it's simpler as the
   starting point
   ... it is considered by OpenFog
   ... thinking about layered model next would make sense
   ... possibly there could be multiple things within a device
   ... that's one issue
   ... and the other issue is having more than one provider for
   one device
   ... yet another category
   ... we list assets within a physical device

   Elena: agree it would be better to start with a simpler model

   McCool: let's start with normal tendency

   Elena: move forward with the table
   ... Thing's resources, WoT Infrastructure resources...
   ... the last two rows
   ... any behavior information we want to protect?
   ... todo: list all the keys/credentials...
   ... you have to do something extensive to hide information

   McCool: extra APIs for that purpose?
   ... if things exposed information protected?

   Elena: non-directly exposed information

   McCool: only the basic information may be exposed
   ... it's a broader responsibility for the protocol level
   ... get the rest of the group to clarify what to be added
   ... protocol binding may hide information

   Zoltan: if we have multiple authentication capabilities, we can
   choose one of them
   ... we can postpone this point

   McCool: we need to get concrete proposals for protocol binding

   Elena: you might have to communicate with something

   McCool: which form of authentication is used?
   ... should I protect that?
   ... there are 2 levels
   ... we should stop discussion about this for today
   ... will add references

f2f planning

   [10]Osaka f2f

     [10] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_May_2017,_Osaka,_Japan

   McCool: make sure the agenda makes sense
   ... I proposed this:

   [McCool] Security [afternoon, remote participants from Europe]
   [Elena] Threat and Asset models
   Review of related models, i.e. from IETF

   McCool: and will cover OCF security model and IIC one as well
   ... 1 hour for Elena's Threat and Asset model
   ... having a 2-hour session would be difficult for people to
   ... so maybe we should have 2 separate 1h sessions?
   ... 1. stakeholders, assets, threats, attack surfaces (1h)
   ... 2. discussion (1h)
   ... or discussion separately on the topics

   Zoltan: we need input from participants

   (discussion on the plan)

   Kaz: maybe it would make sense to have a breakout discussion as
   ... and wrap-up as a plenary session as well

   Zoltan: security is important for everybody, so all the talks
   should be plenary

   Kaz: right
   ... plenary talks, breakout discussion and then plenary wrap-up

   (some more discussion)

   Zoltan: the security process talk could be given as part of the
   keynote session

   [Proposed agenda on security]:
   1. security process (15m, keynote day)
   2. stakeholders, assets (45m, plenary)
   3. threats, attack surfaces (45m, plenary)
   4. classification and prioritization (45m, breakout)
   5. summary and next steps (30m, plenary)

   Elena: wondering about the timing

   Kaz: I think we'll start the afternoon session at 2pm in Japan,
   and it's 7am in Europe

   Elena: perfect

   McCool: updates the "Future Agenda Items" on the Security TF
   ... presentation materials for f2f
   ... review of IETF-ACE and IIC-SF and CoAP and others

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

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [12]scribe.perl version
    1.152 ([13]CVS log)
    $Date: 2017/05/05 13:46:25 $

     [12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [13] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 5 May 2017 13:50:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:12 UTC