<McCool> Review PRs Continue with Threat model (Elena) Smart Home scenario definition Discussion of container types and implications

Continue with threat model (Elena)

elena: goes through her GH page
... Objectives.md

WoT Threat Model & Security Objectives

mccool: runtime should take care of it

elena: will change the name

barry: somebody makes something to attack on things

mccool: attack from another thing

elena: have to prevision malicious things

barry: somebody design some WoT things which possibly infect others' things

elena: how to distribute/transfer scripts?
... related to malicious scripts

zoltan: if it's not distributed, it's still malicious

elena: related to how malicious scripts would be distributed
... where the malicious scripts are installed

barry: we need to split threats

mccool: scripting protection is the main issue

elena: what if manufactures manage to substitute scripts?

barry: somebody gets a temperature sensor
... what kind of attacks are possible?

elena: let's go through the threat table

(goes through it)

mccool: WoT API or Web API
... external non-WoT external devices are out of scope
... we go through the protocols
... protocol binding would reduce the category

kaz: which category?

mccool: for WoT User Interface
... we have to have certain access permission to access scripts

zoltan: agree most of this would be covered by scripting

mccool: there is a case that an app is a back door
... would prefer servients talking with external world only via the protocol binding

elena: having less protocols would be better

mccool: having only the front door (=protocol binding)

elena: (WoT Protocol Bindings)

mccool: if dynamically loadable, could be malicious
... recommend don't do that

elena: (WoT API)
... getting compromising Thing instance and getting access/control
... (WoT API - Unauthorized API access)
... unautorized access to an asset provided via WoT API

zoltan: WoT API is REST API
... possible mitigation for attacks

elena: discovering ports, etc.?

zoltan: yes
... e.g., ssh ports

mccool: if I was skimming the port, maybe would be scanning generic CoAP ports, etc.
... identify type of devices, etc.
... maybe related to privacy threats
... who accesses what using which protocol

elena: depending how the device/software is implemented
... we can make recommendations, though
... but not sure if we can cover everything
... (WoT Protocol - TD Integrity)
... Integrity and confidentiality in transfer
... do we have notion for re-play?

oliver: integrity is one aspect of authenticity

elena: can rename it

mccool: I distribute some TD
... and distribute an updated new TD
... certain kind of attacks

oliver: regarding user data...
... would that be considered as what?
... user data?

mccool: sensor data is user data?

oliver: there is no actual "user"

elena: what's the purpose

mccool: definition of users?
... TD here
... about metadata
... next is solution
... over the protocols themselves

elena: physical user or non physical

oliver: solution data would help
... like normal data

elena: will change the term

mccool: previous point on re-play
... something would happen again
... network may have "repeat things"
... sequence, freshness and uniqueness

kaz: would suggest we think about some concrete use case and risk scenario when we discuss these stakeholders/components of the threat model

elena: there is a section later

kaz: yeah, we should look at the use case as well when we discus each component

elena: (Scenario 1 - Home environment)

[[

In this scenario we assume a standard home environment with a WoT network running behind a firewall that separates it from the rest of the Internet. However the WoT network is shared with the standard user home network that contains other non-WoT devices that have high chances of being compromised. This results on viewing these non-WoT devices as network attackers with access to WoT network and its APIs/Protocol Bindings. WoT scripts and protocol bindings are considered trusted, single solution provider exists on physical WoT devices, no dynamic installation of WoT scripts are possible.

]]

elena: WoT scripts and protocol bindings are considered as trusted.
... implies the following WoT Security objectives

- WoT Protocol Bindings
- WoT API
- WoT API - Unauthorized API access
- WoT Protocol - TD Integrity
- WoT Protocol - TD Confidentiality
- WoT Protocol - Solution User Data Integrity
- WoT Protocol - Solution User Data Confidentiality
- WoT DoS ????

mccool: each threat needs example use case
... clarify the impacts

elena: can give examples

mccool: gives some example use case

elena: ok
... will give examples

mccool: how to deal with mitigation?
... depending on protocols?
... which capability is available with which protocols?
... some of the mitigations are depending on underlying protocols
... others have to be described

elena: we have to discuss "mitigation"
... sometimes underlying protocol doesn't guarantee it
... and we ourselves need to handle that

mccool: should list which protocols support what
... security properties
... our recommendation and non-recommendation

elena: there are already protocols that WoT is expected to support
... we have to provide end-to-end security

mccool: there is a list under the TD section and the binding section
... CoAP, bluetooth, etc.
... let's add concrete examples for threats

elena: can do that
... anyone can send your ideas as well

kaz: whan/how to move this document on Elena's repo to the W3C repo?

elena: there is a pullrequest

kaz: let's approve the pullrequest and make this the starting point

[ adjourned ]