we invite Daniel from CTIC as a guest today

WOT Threat model & security objectives

Elena's resource is a pullrequest to be merged

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

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

Osaka f2f

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: 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

[ adjourned ]