- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 5 May 2017 22:49:18 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>
available at: https://www.w3.org/2017/05/05-wot-sec-minutes.html also as text below. Thanks, Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT IG - Security 05 May 2017 [2]Agenda [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 Attendees Present Michael_McCool, Zoltan_Kis, Elena_Reshetova, Daniel_Ibaseta(observer), Kaz_Ashimura, Michael_Koster Regrets Chair McCool Scribe kaz Contents * [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 pullrequest [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 user 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 parties ... 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 scope 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 work? 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 f2f 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 RBAC ... 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 (AssetsThreatModelSecurityObjectives.md) ... 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 providers? ... 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 digest ... 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 well ... 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 wiki: [11]https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda ... 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