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

[wot-security] minutes - 29 January 2018

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 6 Feb 2018 14:35:42 +0900
Message-ID: <CAJ8iq9UwSdJeTy2htOb+X8GMh76hxQ_OYJiXr5796_i15v96rw@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/01/29-wot-sec-minutes.html

also as text below.

Thnaks,

Kazuyuki

---

   [1]W3C

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

                               - DRAFT -

                              WoT Security

29 Jan 2018

Attendees

   Present
          Barry_Leiba, Zoltan_Kis, Kaz_Ashimura, Michael_McCool,
          Elena_Reshetova, Michael_Koster, Tomoaki_Mizushima

   Regrets

   Chair
          McCool

   Scribe
          kaz

Contents

     * [2]Topics
         1. [3]PlugFest template
         2. [4]Lifecycle
         3. [5]prev minutes
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

PlugFest template

   mccool: welcome back, Elena!
   ... would like to propose a template on how to handle security
   ... focus on particular use case scenarios
   ... and put them together
   ... what is done/should be done
   ... [Goals]
   ... define standard format for plugfest objectives related to
   security and privacy
   ... developers should document a concrete scenario
   ... developers should document both what they ARE doing for
   their plugvest contribution and what they SHOULD be doing for a
   practical deployment
   ... any other agenda items?

   elena: lifecycle PR?
   ... next week there'll be more time
   ... might be good to discuss this during this call because
   there are many attendees today

   mccool: ok
   ... and I'd like to hear people's opinions about these points
   ... [Agents and Roles]
   ... [Topology]
   ... [Confidentiality]
   ... [Integrity]
   ... [Authorization]
   ... integrity is about data
   ... authentication is identifying people

   elena: integrity means the data is not touched by anybody
   ... people may think about different things for those
   terminology

   mccool: need definition
   ... (adds definition to each section)
   ... integrity: information is protected from modification,
   corruption or loss
   ... confidentiality: information can only be read by the
   intended (authorized) party

   elena: what about the scope?

   mccool: the purpose of the template is having one slide for one
   topic

   elena: do we want to think about confidentiality for not only
   devices but also TDs?
   ... data can be lack

   mccool: [Topology]
   ... please indiate the major components of your system and mark
   the security domains and the boundaries between them
   ... give these regions and boundaries names so you can refer o
   them in later slides
   ... identify the types,...
   ... don't forget meta data...
   ... [Authentication]
   ... [Confidentiality]
   ... (adds) Privacy: how is data related to users' identities
   protected from unauthorized disclosure?
   ... [Authorization]
   ... authorization: what rights are given to (authenticated)
   users and how are these managed?
   ... for example, access control lists
   ... [Authentication]
   ... (adds example description)
   ... [Confidentiality]
   ... adds example
   ... how is data protected while at rest (if it is)? Ex:
   Encryption with X
   ... how is data protected while in transit (if it is)? Ex TLS
   ... if encryption...
   ... [Integrity]
   ... how are systems securely updated? Ex: signed updates
   ... [Authentication]
   ... Ex. use certificates, digital signatures
   ... [Integrity and Availability]
   ... how are systems securely updated when security patches are
   requred? Ex. signed updates
   ... how are systems protected from Deniel of Service attacks?
   Ex. limit cost of services provided without authentication
   ... how are compromised systems identified and remedied? Ex.
   IDS and HCF

   elena: any good ideas for testing/validation?

   mccool: [Validation]
   ... (adds description)
   ... validation: ensure correct operation even when under attack
   ... how will the implementation be validated? Ex. Fuzz testing,
   OWASP web penetration testing (for HTTP-based Web APIs)
   ... we can discuss lifecycle as well

   elena: everyone should have wider understanding about lifecycle

   mccool: [Goals]
   ... focus should be on operational phase of "product" but...
   ... [Agents and Roles]
   ... users, owners, maintainers, attackers
   ... [Authentication and Discovery]
   ... authentication: identify of agents can be confirmed
   ... how are agents' identities validated? Ex. use certificates,
   digital signatures
   ... [Authorization]
   ... authrization: what rights are given to (authenticated)
   users and how are these managed?
   ... [Confidentiality and Privacy]

   zoltan: relevant to what we've been discussing for Scripting

   mccool: [Authorization]
   ... who can load scripts into the WoT runtime and define the
   behavior of Things?
   ... Ex. The manufacturer
   ... [Integrity and Availability]
   ... in a multitenant system that supports scripting, how are
   the tenants protected from each other?
   ... [Validation]
   ... [Confidentiality and Privacy]
   ... privacy: how is data related to users' identities
   (personally identifiable information) protected from
   unauthorized disclosure
   ... that's the thing to do now
   ... Elena, do you want to share your screen?

   elena: can do so

Lifecycle

   <McCool> [8]https://github.com/w3c/wot-security/pulls

      [8] https://github.com/w3c/wot-security/pulls

   [9]WoT lifecycle diagram

      [9] https://github.com/w3c/wot-security/pull/63/files#diff-891748290f755794b17216fefa1ba103

   mccool: might be a bit confusing
   ... 2 back loops for installation&commissioning
   ... as discussed during the prev call, this lifecycle
   definition should go not to the security document but to the
   main architecture document

   elena: would make sense to have some discussion during the main
   call?

   mccool: resource for the diagram?

   elena: checks IETF drafts
   ... draft-garcia-core-security-06.txt

   mccool: state machine timeline here

   [10]https://tools.ietf.org/html/draft-garcia-core-security-06#s
   ection-3

     [10] https://tools.ietf.org/html/draft-garcia-core-security-06#section-3

   koster: more about devices
   ... maybe some definition slightly different
   ... security bootstrapping

   elena: (shows the definition)

   [11]https://github.com/w3c/wot-security/pull/63/files#diff-8917
   48290f755794b17216fefa1ba103

     [11] https://github.com/w3c/wot-security/pull/63/files#diff-891748290f755794b17216fefa1ba103

   mccool: let's call this security provisioning here
   ... and add a note saying IETF draft calls it "security
   bootstrapping"
   ... then "installation" vs "commissioning"
   ... let's leave terminology out now
   ... next time we need to clean up the definition
   ... should explain why we chose our terminology

   elena: don't have proper knowledge about the lifecycle
   terminology...

   mccool: will send an email and upload the template
   ... we can have discussion on the github repo as well

prev minutes

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

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

   mccool: don't see anything missing or wrong
   ... accept the minutes?

   (ok)

   minutes accepted

   [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [13]scribe.perl version
    1.152 ([14]CVS log)
    $Date: 2018/02/06 05:35:04 $

     [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [14] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 6 February 2018 05:36:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 February 2018 05:36:59 UTC