Meeting minutes
Minutes
McCool: any objections?
(none; approved)
Meeting schedule in August
McCool: vacation in August
… starting with the next week
… and cancel all the Security call in August
(Aug 2-23 Security meetings will be cancelled)
Best Practices
Issue 13
PR 19 - Add Ed Note to Object Security
PR 21 - Add local TLS/DTLS security via Raw Public Keys
McCool: some clean up PRs as above
Issue 13 - Update Secure Local Transport
McCool: how to generate a PR for that?
Oliver: a bit different form of secure transport
McCool: would like to mention some proxy as well
… (adds comments to Issue 13)
… expectations around mutual authentication, etc.
… would be useful to distinguish "key distribution" from "secure transport"
… but we have to decide where certain parts go, e.g., mutual authentication
… also question of managing permissions
Oliver: would look into the NETCONF RFCs
… 6241
more specifically, section 2.2
Oliver: talks about authentication
… meant for network configuration, not specifically for Web
… there is also RESTCONF
McCool: anonymous service for IoT
Oliver: you'd like to learn NETCONF for encryption, etc.
… similar constraints like the ones we have
McCool: original intent of Philipp was to support a secure PKS key distribution
… typically we see the key during the onboarding process
… would assume something like OAuth for tokens
… some kind of mechanism for people to access multiple devices
… but how do you know who to generate the token, and how to get it?
Philipp: also what kind of clients are available
… core issue here is how to distribute the keys
McCool: yeah
… want to be able to target the problem of a larg number of users and devices
… also being able to manage different/dynamic permissions for different users
… want to avoid configuration for each device every time
… we should look into standards on key distribution
… or at least de-facto mechanism
… are there an existing best practices?
… CA is one such system but requries that servers have a public URL
… LDAP is another possibility but that is just a distributed directory; CAN hod keys
Oliver: LDAP is basically a directory and doesn't handle security itself
… but you can run LDAP over TLS
McCool: what we want to do is not recommending something new but unusual
<citrullin> https://
McCool: we'd like to see the existing best practices
… what do people actually use?
… (found a research paper about key management)
Towards Formally Verified Key Management for Industrial Control Systems
McCool: probably should define some terms
… and then some suitable options for different "modules"
… e.g., for secure transport and for key distribution
… problem with TLS 1.2 is can't use raw public keys...
Oliver: raw public key was available before. will check the specification again
McCool: use cases for browsers
… accessing public URLs
… relate to how we deal with proxies, tunnels, etc.
… also reverse/forward proxies
<citrullin> https://
McCool: perhaps we simply say "if you want to access a system though a browser, nee to access system via a public URL secured by a certificate."
… then we simply have to discuss the privacy implications
Philipp: gave some resources above
… the first link above is about Using Raw Public Keys in TLS and DTLS
(which mentions Firefox nightly supports client side TLS 1.3
McCool: (adds another comment to Issue 13)
… some browsers may support import of raw public keys and/or integration with PS systems
… if one exists, then we can give this as an option in environments where putting public URLs for access devices is not desirable.
[adjourned]