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 indicate 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
<McCool> https://github.com/w3c/wot-security/pulls
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
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)
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
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]