Chairs: Carsten Bormann & Ari KerŠnen
Note takers: chairs, Dirk Kutscher
Carsten gave intro: https://github.com/t2trg/2017-03-ocf/blob/master/slides/T2TRG-2016-03-ocf-chair-material.pdf
Agenda bashing; we are likely to go longer than in original agenda. We should be breaking around 6PM.
Tomorrow meeting with OCF. Starting at 8AM (see agenda on slides).
Alex: in the OCF meeting is the idea to have info one way or more dialog?
Carsten: two way; both have problems and solutions.
We will continue working (unofficially) tomorrow afternoon after the OCF meeting too. Should be possible to get small groups going on tomorrow afternoon.
Internet Draft DL next Monday. Can get some work done before that and submit it.
Carsten: Reminder on what the T2TRG work really is on. Background on the IoT work @ IETF. The RG is about the work on how the real IoT will happen (as a system, protocols, etc.).
Carsten: on the scope and goals: we want to make sure that low-resource nodes can be ÒattachedÓ to the IoT in some way (not necessarily running the full stack)? At RG doing lots of outreach and meeting tomorrow with OCF is part of that.
Matthias: Meeting Friday/Saturday in Dusseldorf (W3C WoT) right before the IETF. Flights between Dusseldorf and Prague can be weird (expensive) so we should schedule accordingly. WoT meeting starting 9th of July. Full blown start on 10th. Goes on until 13th. 14th and 15th could be joint meeting in Dusseldorf.
Carsten: this meeting would be focusing on joint topics with WoT (REST, TD etc). Perhaps security work too. Also week 39 in Berlin co-located with RIOT and ACM ICN
Alex: relationship between T2TRG and W3C and other groups?
Matthias: W3C meetings are open, can attend without being member for most parts of the meetings. Next meeting: mid of May in Osaka. Can provide input on mailing list or on Github. Web of Things group has a couple of liaisons, e.g., with OCF. Currently looking at overlapping topics with OCF, e.g., device descriptions. Formal collaboration with OPC, industrial automation: information models. Comparing it with Linked Data in thing description
Alex: where can get structured perspective? ItÕs difficult to follow all activities. Would be great if there is someone who can provide a structured overview and point at important events and facilitate communication.
Matthias: this is the point of the joint meetings, e.g., W3C/IETF. Agree good to align efforts. IETF is easy, some others, like OCF bit harder because not as open. If people are interested, can give summaries on roadmaps etc. This year WoT locations are fixed but future meetings can work to have good co-locations.
Carsten: getting a complete map might be too much. So far, we selected some relevant groups, like W3C. OCF has picked up IETF components and build something out of that. There is also OMA and Lightweight M2M. The perception was that they don't need that much help from us because the scope was limited. LwM2M is interesting standard and lots of buzz e.g., at MWC on that.
Bluetooth SIG like OCF, doing a self-contained set of specs. Not used to working with IETF components that much.
Alex: should we present a ÒsocketÓ as an interface for other organization that want to talk to us?
Carsten: IETF has IoT directorate for that. Will make sure that T2TRG is visible in that.
Ari: Yes, good point. Can use Directorate to dispatch relevant topics to the RG and right WGs
Carsten: ICNRG is another type of group which is starting in the area of IoT, where we will be having some common work in the future.
(round of introductions)
Carsten Bormann, Ari KerŠnen, Thorsten Dahm, Steven Rich, Klaus Hartke, Alexander Pelov, Matthias Kovatsch, Oscar Garcia-Morchon, Dirk Kutscher, Jaime Jimenez
Remotely: Rashid Sangi, Gšran Selander ...
Thorsten also gave brief intro into MUD. Planning to have RFCs, one from manufacturer side, one from network operator side. Thinking if should be done in RG or OPS area WG.
Dirk also mentioned the side activity he's been driving at IETF on distributed architecture, using blockchains etc. Also bringing in legal contract community in. Monday evening in Chicago could have a meeting on this.
Carsten gave intro on potential discussion topics for today (see slide 14). A) REST and security has been recently discussed on the list. How to get the right security properties. B) E2E security, e.g., Bluetooth insulin pump to something on the web with components in between. C) identities and endpoints discussed a lot in Ludwigsburg. Lots of notes from that meeting. D). Could continue discussing RESTful design and formats like CoRAL. E) More "out there"; loosely and tightly coupled systems. We've been working on loosely coupled a lot so far, but sometimes maybe want more tightly coupled (e.g., touchscreen events). F) We have now lots of input on self-description. WoT TD, MUD, well-known/core. Where does this take us? Can we use same infra with MUD as with other elements? G) What would you like to see?
Matthias: B&C seem closely related, could be combined: what is the endpoint in end-to-end? Where to put identity? (Things might have multiple components (fridge has thermostat, light, É); each get a certificate or only main Thing (fridge)?
Carsten: composition another word we need here.
Alex: also somehow connected to E. How tightly couple identities. Self description part. Possibility to use YANG to describe things.
Thorsten: MUD is already using YANG. JSON files.
Carsten: area of self description contains semantic interop.
Jaime: another is distributed discovery. Planning to submit draft of distributed RD.
Carsten: part of F
Alex: could also present these tomorrow with OCF
Carsten: maybe not so much of the topics of today but we should spend some time today to discuss what we discuss tomorrow
Carsten: what is the most urgent thing /most interest we should be working on now? Show of hands
Oscar: getting feedback on the security draft would be very useful. For the structure of the doc.
Matthias: could achieve to collect patterns and guidelines for RESTful IoT security
Steve: lots of material online. For RESTful design perspective better understood now than MUD.
Thorsten: getting well known security is already hard. Talk to fridge manufacturers about security. They don't even have proper IP stacks. Makes sense to have well known concepts established.
Matthias: should get the base draft first done though. So would prefer to have B&C addressed by security folks.
Thorsten: B, C and F could be combined. Self-description can be used for describing e2e security.
Carsten: would be a plenary discussion already
Dirk: can use these to structure discussion
Matthias: Thing Description Overview
● W3C ÒWoT Thing DescriptionÓ (Working Group Task Force and Recommendation Track deliverable): https://w3c.github.io/wot-thing-description/
● JSON representation of Linked Data / RDF documents
● Description of interface to use: properties, actions, events
● Interactions: similar to resources. "Forms" that has all the information needed to interact with the Thing
● For data description looking into JSON Schema. Revived Draft at IETF. Trying to combine with JSON-LD in order to annotate semantics to data structure.
● Example 3: for security here using JSON web tokens. First prototype on how to do this. General idea: also describe security properties to securely interact with the Thing
● Metadata describing Thing, security, data, and interaction. That's TD.
● Do not currently cover outgoing requests, what MUD covers. Could be interesting aspect to cover here.
● Using fridge example: want to interact with fridge (what is temp). But also with e.g. light. That is a thing but component of a thing. Does it make sense for each small component to have identity?
● At the moment JSON-LD, but also thinking of more compact presentations. CBOR for instance.
Thorsten: Manufacturer Usage Descriptions (MUD)
Presentation from MUD author Eliot Lear:
● Improving IoT Security: the role of the manufacturer
● Considerations on what happens when company buys another and manufacturer changes
Matthias: do you consider things to serve files?
Thorsten: devices often not having even IP stack. DHCP would probably be standard thing that gets used. Already submitted patches to do that. DHCP option with URL in it.
Matthias: mixed assumptions in end-to-end. Want to open IP connectivity for non-IP device?
Thorsten: if there's no IP stack, don't care about it. For enterprises want to link to ANIMA work. Only cares about IP stack.
Matthias: why cover Zigbee devices?
Thorsten: maybe it's Zigbee in fridge but fridge talks IP on behalf of the device. Acts as GW.
Matthias: would assume MUD starting from GW
Thorsten: yes, e2e can mean philips light bulb. With bluetooth could be GW. Even if thing comes pre-owned from Chinese manufacturer. MUD would allow call back home. But network operator should use common sense. Having MUD in Android would be highly useful.
Alex: in CoRE WG work on YANG for IoT and mapping to CBOR and CoAP (CoMI work). Mapping to compact binary format.
Steve: network infra has received URL from device, check its cache and get from network. Not so much need for compactness since device not serving the file.
Carsten: assumes function of the device being very static. As devices come more dynamic with apps installed on devices this becomes more interesting
(showing the MUD file on slides)
Alex: ACL in YANG here?
Thorsten: the internet draft yes. Manufacturer could put e.g. WLAN ACL like this. Or if channelling all traffic via data center, can express that. Don't want to go too detailed but want to be able to tell network operator what is happening. Would like to make this open config (http://www.openconfig.net/) . Open config in vendor neutral configuration of devices. Any vendor can parse and use.
Matthias: GW could on the fly generate MUD file
Thorsten: don't want to trust the GW. Manufacturer would know the best what the fridge needs to do.
Matthias: works for static things (fridge may not change much). But more ad-hoc things with apps for fridge (e.g., hipster web site).
Thorsten: if fridge can tweet every hour, that would need to be in MUD file. Fridge could install random apps, you can either ignore and let fridge talk to anywhere or ask to update the MUD files. If only few apps possible on fridge can update those.
Carsten: App provider could provide MUD file?
Thorsten: But fridge provides this. App manufacturer would need to change the firmware of the device.
Matthias: that's why it would not work well. On slow cycles could work. But Android for example would need on the fly.
Thorsten: for app stuff, yes
Alex: file or data presentation.
Steve: MUD should not necessarily be used on complex devices with multiple purposes. Better for mass deployment of simple devices. Something you would not like to burn in the device but comfortable burning static URI. For sophisticated device want to have different model likely. Want to understand what goes into lifecycle document. When is MUD the right model?
Carsten: sounds dangerous. Now have hammer called MUD and writing a document that explains difference between nail and screw. People will be using for both. There will be pressure for MUD to have functionality going beyond. Unless can paint whole picture that MUD is for A and here's what you have for X.
Steve: two ways to think about deploying something like Android devices. One where Android is being used as the operating system for a very simple device and for which generic application deployment is not intended. I.e., it can be a single-purpose device that will never run applications. Those instances can be well-suited for MUD as they will have relatively simple network access requirements. Once the device becomes complex enough (in terms of its network access requirements), then it may go beyond a suitable use-case for MUD.
Thorsten: you should never base all security on MUD
Carsten: out of experience: if protocol has something like hard envelope. People will push the envelope. Inevitable that MUD will grow beyond fixed set of devices that covered now.
Thorsten: does it make sense to have a life-cycle management document that explains what you can do and what not?
Carsten: MUD: manufacturer is trusted entity. How could this actually work when pushing the envelope wrt device capabilities?
Thorsten: that's where we need to say as network admin, you need to have security policy. That needs to compliment MUD. Could trust manufacturer for "need to talk to facebook". Want to reduce blast radius.
Carsten: MUD could also help with rate-limiting etc.
Thorsten: one step to right direction. Can't rely just in MUD.
Carsten: MUD is an instance of Òputting things into jailsÓ. There are many research projects for constructing these jails. Maybe here, we can look into broader space, how we could make these jails operate. MUD is covering part of surface here but there are other devices. If I have light switch manufacturer would have hard time telling where the light should talk to. Sometimes, need to add local information to MUD fileÕs information. Interconnecting various pieces of information...
Thorsten: hope that we will end up having ANIMA config for that part. Generate based on all the data confi for firewalls, switches etc.
Carsten: whole thing can be even more dangerous: if any manufacturer can augment your YANG model, they will
Steve: another subject; how the community of users of devices will start to collaborate on various trust models. Users made aware of what devices does. Could build higher semantic layer on top of this. There could be certain trust models. In the absence of MUD we don't have anything. With MUD we have explicit statements we can study. Who is the ODM of the device? Another aspect; device may have vulnerability. In that case MUD file indicates where device should be communicating. To make DoS doable would also need to compromise the MUD file.
Alex: what might be complementary to this is what we are doing in CoRE: device telling what it intends to do (communication). Different aspect: protecting device from the network -- filtering in the other direction. Can we add some parts to the MUD document that generalizes this idea?
MUD is basically YANG. Could use idea of MUD in more general way where a device publishes assumptions/rules. Using Òsomething YANGÓ rather than exactly MUD provides extension points.
Thorsten: one of the ideas discussed; if would like to everything go to cloud. You own robot and light sensor. Motion sensor and light sensor can tell robot not to come to room when baby sleeping. Would not like the light sensor directly talk to robot. But could tell that all needs to go via cloud. Can say "anything in my house can only talk to household.google.com" to go via the dashboard and control
Alex: we are also working on getting some of this intelligence back into the network, i.e., not always having to rely on cloud. Allowing some form of communication within the network. This would be dynamic. This is something we can work on together, in T2TRG, CoRE, etc.
Thorsten: where this could fit is the Identity part. Want to make sure you talk to right thing. Software identities and nice mode for addressing identities. But before that static MUD could at least tell to talk to cloud service only.
Steve: regarding static MUD, if you think about unifying static and dynamic configurations, MUD could become static initial configuration, that is used as a starting point by dynamic SDN/orchestration. Not sure if itÕs MUD that is used for the dynamic configuration or something else.
Carsten: if I go to WallMart and buy Cisco movement sensor. How does the MUD file know I'm using household.google.com?
Steve: meta-variable would describe abstract requirement like Òneed to talk to local controllerÓ. You could have local configuration that defines what that means.
Carsten: have few points where can stitch together policies. In the end communication profile you're trying to setup may have multiple inputs.
Thorsten: Policy Server in MUD spec. Like DHCP option. Policy server would fetch MUD files and craft ACLs that go to your firewalls etc.. Intelligence should go into policy server, not in the Thing.
Carsten: design MUD file from manufacturer needs to have extension points.
Thorsten: and system needs to know what you are using for the control
Matthias: MUD can do, what Android is doing for apps. Can get complex quickly. Just Òdevice-to-cloudÓ is simple. If you introduce notion of local policy augmentation, it can get complicated. There are some limitations that should not be fixed in MUD right now. MUD should first address simple IoT devices.
Alex: ACL draft is basically just router filtering rules for firewall.
Thorsten: why we want to do lifecycle document. To address these issues. When to use MUD and when not. We don't know exactly what we need. Security and thread model very different between manufacturing plant and garden shack. Can't expect to have same security model.
Matthias: in all these scenarios, it would be nice if a device could tell, in a standard way, what it wants to do. Not comfortable with having to rely on external services. Self-contained operation would be valuable for many scenarios.
Steve: what we can do is give classes of cases where MUD makes sense to employ because it can automatically solve use cases because the use cases are the right ones and no requirements for customized policies. Will clarify applicable use cases. Easy to imagine that MUD could be universally applied. But MUD profile saying "allow all" is useless. So use cases important.
Carsten: maybe we can widen discussion to other approaches to security descriptions
Matthias: would like to have some bottom line. Steve wanted to check use cases for example.
Thorsten: the documents we currently have are in Github. But not even -00 drafts yet. Any input welcome.
https://github.com/sr-iot/mud-docs
Steve: want to clarify benefits of MUD in specific use cases,
also saying where it might not be applicable. Question: is this a good way to
talk about MUD research question?
Seems to be useful.
Matthias: We have this central idea of a security concept for IoT: Port the Apps permission requirements list for smartphone users to a machine-readable device permission list for network admins (could be manual in the end or some automatic configuration mechanism).
Would be nice to split the MUD work into a long-term aspect about the idea, and a short-term minimal/narrow release to fix current, static, device-to-cloud-only IoT devices (which is clear about what it does and what it is good for)
Thorsten: majority of devices/scenarios are pretty static, so MUD seems applicable. For the future, more dynamic scenario, additional threat models, we might have to look further. Other companies might prefer other technologies. MUD is addressing the baseline. We should be talking about best practices, not so much specific protocols.
Matthias: want to keep basic idea and have room for thing-to-thing parts. More branding questions perhaps. How to call long-term work and what the short term patching.
Steve: MUD file could also indicate for devices and inform network infra. This device will have dynamic ad-hoc info on policy. Operator could quarantine device.
Alex: What is the research work -- you seem to be publishing an RFC soon?
Thorsten: research topic is not so much MUD protocol itself, but its integration into a whole IoT security stack
Alex: MUD protocol is basically just getting URI and downloading file. Also applying policies to router, cable modem, firewall.
Steve: or, for example: in a building full of building management systems, light bulbs can only talk to managers.
Alex: very useful mechanism and worth looking into. Thinking of file patching in firewall. How to integrate whole thing to NETCONF and YANG world. How to work together.
Thorsten: when you suddenly have a MUD file that does not make sense, this could also trigger an alert (detecting a breach).
Alex: Draft describes how to use this info in DHCP etc. and how to sign this. The research part would be how to use this as a tool for the whole lifecycle? Are open to consider the draft get input from these discussions?
Thorsten: regarding changes to protocol draft, talk to Eliot or send message to list.
Alex: so, MUD would be a basic building block -- can we look at bigger picture and think about additional requirements?
Thorsten: yes, current spec should be taken as ÒMUD-v1Ó. MUD-v2 may come later -- as the ÒfinalÓ solution.
Alex: does not sound very reassuring for vendors
Steve: letÕs get -v1 right, then we donÕt need -v2
Matthias: this is related to Òbranding thingÓ. MUD mainly intended to fix most urgent problems with stupid IoT devices
Thorsten: want Netgear, Juniper, cisco etc. adopt MUD. Things in living rooms and companies could be using this.
Alex: more generic question to chairs: could we structure work on YANG and IoT? Maybe in CORE or somewhere else? Bar BOF in Chicago?
Ari: all for bar BOFs. YANG seems to be popping up in IoT space more. Would be good to increase understanding of that.
Carsten: trying to envision outcome of such a bar BOF. What do we have to coordinate or push forward?
Alex: will find a bar and ping people
Carsten: on July 28th, 2009, we had a bar bof with actual beer -- this spawned a WG, so it can work. :-) But we may need to understand what we actually want to do.
Carsten introducing Concise Software Identifiers (draft-ietf-sacm-coswid)
There's ISO standard for software identifiers. But something more compact is useful. Could also be part of self-description of a node. Or to decide if node wants to talk to this node.
Alex: possible to implement this as a YANG model?
Carsten: this is defined CDDL, so CBOR all the way. Could do the same thing in YANG, but we have to understand the application scope of YANG. Has been created for management, i.e., for describing data at rest. IoT space is more about dynamic interchange, so some YANG concepts do not make sense
Alex: what is the mapping between YANG and CDDL?
Carsten: great question, which came up at the semantic interop workshop. There are many attempts at doing something like a JSON scheme etc.. Also, other schemas can be mapped to JSON. JSON-LD for example is JSON representation of RDF data. And RDF data can be described by RDF. Mapping this whole space and describing what schema makes sense for what application area, would be desirable. Different criteria: 1) how well can you represent the required information, and 2) how much would people working in that field actually want to use it.
Alex: potential interesting research topic how CDDL or YANG answers these challenges? Is there mapping? Intersection?
Carsten: I wrote a translator from JSON schema to CDDL (just the OCF specs), at semantic interop workshop. Need more work/experiments in that space. Besides data modelling, there is also interaction modelling. Would be nice to also have some model translation for that as well. OCF uses RAML to describe interaction model.
Alex: that's way to describe RESTful interfaces, right?
Carsten: yes, also JSON hyper schema. Coming from couple of models and translating that could already give some insights. All self-description part needs modeling languages. We also need map what kind of things we want from the network elements. Jailing is one aspect, but also using self description to have configuration going. That's what WoT TD was originally addressing.
Alex: who is interested in using the spec in the draft?
Carsten: from SACM group. Idea to provide capabilities for network elements to do measurements etc to make it possible to have complete model of the network.
Steve: we thought about automating exposure to CVEs and finding particular version of that
Alex: The SWID can be used in some way with the MUD or with SenML. It is an identifier, which contains information about the firmware and other interesting things which could be relevant to the data / device profile.
Steven: MUD URI don't need to look like this.
Thorsten: approach in the draft looks interesting for useful but not necessarily trusted information, e.g., in case information comes from compromised device
Steve: could do e.g. syntactic analysis. Use fingerprint to get to database.
Thorsten: a little bit like what Apple and Google are doing for app stores.
Carsten: SWID is not replacing attestation, but is subject to. If you want to know what kind of properties thing has, you can use SWID for that.
Thorsten: yes, itÕs a very useful signal, can be added on top of what you already have
Thorsten: depends also implementation. If you put it on read-only chip, it could be more trustable, e.g. TPM.
Carsten: would probably use TPM to sign that ID. Whole area of attestation is quite lively. At least four drafts in that area. Also TCG folks are apparently renovating their protocol infrastructure. We have lot of stuff out there that can be used. Need to educate people.
Thorsten: we are on the same page here. I just see the gap between what we want to do and what is actually out there. If things do not implemented, soon, we might also see some unwanted security regulation.
Oscar: last year was involved in internal project about IoT system. Was talking to folks at NIST. They didn't see folks using those regulations. Some regulation is good though.
Thorsten: regulation would make our job easier. Vendors would be forced to implement some security.
Oscar: someone needs to do the regulation. And they will ask industry for guidance.
Carsten: there are also good ways to do regulation, i,.e., not regulating the content but rather creating the framework that promotes doing good work.
Thorsten: also where industry and government bodies can work nicely together. Can say "this regulation needs to be adhered to talk to our cloud".
Carsten: e.g., increase the Google ranking of compliant sites ;-)
Thorsten: Interested in FUD because if FUD does it right, manufacturer can point to that work and say need to be compliant to "FUD standards". Not need to repeat same stuff over and over again.
Carsten: unfortunately FUD BoF didn't get agreed upon, but we can meet in a bar for the topic.
Potential deliverables for this group that we could create?
Jaime: anyone interested revisiting distributed discovery mechanisms. Wrote a draft a while ago. For hypermedia apps need devices to do certain actions for discovery.
Carsten: we did not discuss discovery yet -- we implied that it would be there.
Ari: in this context or in general?
Carsten: both. If you have all these self descriptions out there, it would be great to have a way to find them. BTW, how do you do this in Ipv6?
Room: NAs
Jaime: Do networks support multicast discovery?
Carsten: MUD -- couple discovery with the process of entering the network. For 6lo trying to avoid multicast because it's expensive.
Jaime: also OCF, are they going to implement full drafts or lock use to what they have?
Carsten: most likely they only use what they need
Jaime: if you make the protocols open and fair and companies implement what they want, it does not work they way it was meant to be
Jaime: e.g. LwM2M you can implement it as distributed system where devices can find each other. But that's considered as a risk currently.
Carsten: 3GPP approach: centralization. Advantage: you have control points. Disadvantage: control points can become choke points
Thorsten: stateless DHCP :-)
Carsten: don't think OMA is in business on how to use CoAP but how to build their specific flavor using CoAP. That flavor can be combined with other methods provides to do more.
Jaime: the way that is being built is that you have a series of hierarchies.
Carsten: there's strong economic benefit but people don't know how to build business model out of it
Jaime: what about social benefit?
Carsten: similarly MUD increases the power of manufacturer. And people who like to use devices in different ways than they were intended to dislike. We are not in position to say one way or the other, but we should be aware of this.
Jaime: with things like blockchains, you could build systems that are open. Not sure itÕs possible.
Carsten: definitely would be research
Thorsten: in the past, we marked packets in protocols and threw them away if they did not comply
Jaime: but can just not implement that feature. Would it make difference if in RFC if you would say MUST implement such features.
Carsten: how to RFCs get their power? Mostly: company that want to buy products, mention RFCs in RFQs and RFPs. In the end, itÕs cheaper for vendors to just implement stuff than explaining why they did not.
Jaime: it's the same 30-40 people everywhere in standardization. We can agree here that we hum against anything that doesn't follow this idea.
Carsten: Path MTU discovery good example of something that doesn't work if people don't implement properly. Now it doesn't work.
Thorsten: the other way to make people things, is to make it really cheap to implement something. For example, MUD is like this. Heavy lifting would be Policy serverÕs job -- that would be provided by bigger vendors.
Carsten: also powerful threat if device doesn't implement MUD, policy server will switch it off
Thorsten: yes.
Jaime: usually we don't leverage the position we have. But have economics driving the discussions. Many people in discussions don't even know how the protocols at hand work.
Matthias: regarding previous topic, i.e., requiring MUD: need to have something better than firewall port filters.
Thorsten: we can publish slide decks, but it won't change anything overnight. Like in EU you need 50 stamps before you can change IP address. For more dynamic network admins you can at least make an argument with this.
Alex: for the sake of controversial discussion: need to have huge infrastructure, just in order to automate things for people who do not really need it. Seems like a huge effort for a thing, which you could also do with some ML that observes malicious behavior.
Thorsten: Not bad. That would still help us.
Alex: For example, I am not sure that Android security is that helpful -- people tend to accept everything.
Thorsten: If infra will be provided by Amazon/Google/FB. Everything sold in our shop uses MUD of what we need. If you can't convince Amazon guys doing that, who knows, but worth trying.
Alex: we should check with the clients of the technology. Would people really like to write/check MUD descriptions?
Thorsten: not necessarily, but they don't have to. We can help with lifecycle management. They can ignore it, but they know what to do.
Matthias: if it doesn't hurt manufacturers to add things, but it improves the product, they probably adopt it (e.g., MUD).
Alex: but in this case, itÕs not going to be the device that provides the MUD file
Matthias: This relates to what should MUD cover. If it is a simple building block that just provides information about the expected behavior, people can make use of it. If it has a long tail of implications on how to design the system architecture, people will most likely not use it.
Alex: re CarstenÕs question on Òhow to make the world a better placeÓ, survey of different languages and mapping would be needed. Also: how do we work with external SDOs that take IETF tech? How to send them a message to use IETF specs correctly?
Carsten: not sure that is a research question.
Jaime: research question would be how to make it from tech PoV really hard if you don't do it the way we meant to. Use some already distributed tech. Not sure how to do it, but DHTs, Blockchains etc could help.
Alex: suggestion: include critical mechanisms in all examples.
Jaime: actually since we are participating in all these orgs, maybe the kind of lobbying is not nonsense. We have more open perspective of the world. Other orgs like their clusters. Can convince that things can be done in certain kind of way.
Alex: agree; if you consistently tell that you should keep things open, they will get interested and understand.
Jaime: say, tie things together that need to be open
Thorsten: maybe far beyond scope of this group. But what could do. Companies business models depending on proprietary solutions. Have to go to companies one by one and tell if you change you can get access to sources you did not have. "You can save 20 M dollars every month by doing maintenance when it's needed and not by every year just because". That can make understand that IP and CoAP is better.
Matthias: few companies have started to use open source, not yet contributing. Then maintenance becomes costly and give it out because it's not their core. Small building blocks like Docker. Node.js another example. Lots of companies adopted and using in some ways. Once you get to believe where it's a benefit, can develop from there.
Steve: can either implement themself, or use commodity components. Need to make it obvious the benefits.
Jaime: for innovation to happen, we need open systems. Should be ethical and push for open solutions.
Steve: let's not miss the opportunity to get in front of companies to make it clear there are solutions for this
Carsten: wrapping up in order to have another session too.
Carsten: Social dinner gathering tonight 19:30 at MAX Amsterdam. Herenstraat 14
Carsten: have not yet addressed "what is the end" of end-to-end. Is car a thing, Bluetooth headset, something else?
Carsten: Thing is often part of a thing. Is the identity ID of the thing or the stack? Components of a car: some coupled tightly with a car (like engine). On the other hand, headset of a driver becomes part of a car during person driving, but not when person leaves the car. Or in ABLP calculus; that tries to formalize devices/components talking to each other. Need to evaluate "speaks for" relationships.
ÒSpeaks-forÓ Calculus that tries to formalize situation that you have devices, processes etc. that try to delegate functions between them: ABLP (e.g., see https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/acrobat-8.pdf).
Attestation identity keys (AIK) as temporary or directed identity for a specific purpose
Thorsten: would it make sense to explicitly mention here that folks should not invent new crypto, but use e.g. TLS.
Alex: great question, not sure whether itÕs well-formed.
Francesca: can this question even be answered in general case? In specific case can be one sensor or whole host. Or resource, or set of resources on host. For trying to say something general, can we even do it?
Carsten: maybe itÕs more productive to point out pitfalls instead of thinking of solutions. Example: finding out temperature in my bathroom. ItÕs hard to do e2e measurement of the temperature in the bathroom.
Thorsten: one of the concept to counter this: combining things you know and things you discover. You could have pretty good guarantees that you're talking to right thing.
Alex: boils down to how you define security. Need to decide what your endpoints are and what the security model should look like.
Thorsten: depends on your threat model. Would not want to walk to bathroom and steal it. But could want access to know if someone is home. In this case the data in cloud is way more valuable than sensor itself.
Alex: what the endpoint is, depends on the use case
Thorsten: first you should look at threat model
Matthias: discussion seems to be on wrong level -- too many unknowns. There are some things we could nail down, e.g., bound to physics.
Matthias: what can you physically connect to each other make ends. Can model each component individually and have the computing power to check this, but does this make sense.
Oscar: can divide problem to subsystems so that you can analyze it. Maybe need methodology because systems can be very different.
Thorsten: question is can you even have something for so different systems
Matthias: sometimes, it is also obvious: ZigBee and web-based technology domains can never talk end-to-end.
Thorsten: what you probably want to do is to give generic way to analyze how many unknowns you have.
Alex: have ways and methodologies to analyze that (ISO standard of some sort). On the question what is the endpoint; depends on the protocol and protection mechanism. For example IP address and endpoint.
Alex: for example military system with biometric scans etc.
Matthias: misunderstanding about e2e security. Need to define what that means.
Ari: need to clarify and qualify our endpoints. There is no unambiguous "end-point".
Matthias: need to specify what ÒendsÓ are in your application
Francesca: interesting discussion. Leads to many additional questions.
Jaime: seems to be related to identity discussion
Carsten: THE DEFINITION of End-to-End Security. You have it if you donÕt have an unnecessary different intermediate system that you can attack to compromise security.
Thorsten: when you talk end to end, do you include privacy?
Carsten: several reasons for confidentiality, and privacy one of them. Security properties confidentiality and integrity.
Dirk: part of the discussions stems from the fact that we're used to equating endpoint identity with IP address. If you talk about e2e security in IoT you don't achieve it if you have to translate between Zigbee and other protocols. If you have functionality in endpoint that is related É Have had lot of this discussion in ICN context. There we don't distinguish between endpoints but names for data. Only ultimate receiver is responsible for checking integrity.
Carsten: point that trying to make: there is no positive end to end security. Can only by defining by avoiding stuff.
Jaime: why defining marketing concepts? End to end security is marketing term to me.
Carsten: it is being used as a marketing term -- has become fuzzy
Jaime: for example, for some at CoRE, if you don't have DTLS you don't have end-to-end security.
Alex: Security is ambiguous -- different objectives can be implemented in different ways
Matthias: maybe I'm fine if it's only Integrity. We are looking at what is the endpoint. That entity I want to have information from.
Jaime: using terms that are vague.
Matthias: "endpoint to endpoint security"
Carsten: two applications talking to each other. App layer security used for communication. But even though we already have e2e security; we may need DTLS below to protect traffic information confidentiality.
Matthias: but only if we need it.
Thorsten: endpoint is something that you expect to do something for you
Matthias: and I would trust. Maybe I'm happy to get something from hub that represents the room, I'm happy with that. If I want from specific device, I go to that. If I talk to car, and the whole thing is trusted, I don't need to address specific parts of car. Aware that there are unknowns, but they come with an instance. What are the security goals.
Francesca: can we say that protocol stack in the device is not unknown? When you assume that you know the protocol stack, then you can talk to the different layers.
Matthias: hope that we get abstract model to discuss what should be there. The model can be filled with details and build a system on that. Person with requirements should fill in e.g. what are the security goals.
Jaime: going other way around. Here's what we have and see how you can apply techs here. Taking OSI model and would secure on each layer.
Francesca: even on application layer (or any) can be multiple endpoints.
Jaime: easier to go layer by layer and abstract from there
Oscar: have system and divide it to parts. Identify the risks you want to mitigate.
Matthias: need to see here's overall model of what could happen and start plugging in your knowns, and becoming more clear
Francesca: these two ways are complementing each other. Have something practical and want to apply security. Identity, threat analysis, security requirementsÉ
Matthias: threat analysis you can do only for a system you have filled unknowns. What was not covered is that if we have intermediaries -- can't cover with OSI model.
Jaime: there's limited set of technologies. For communication (protocols). Access control, confidentiality.
Oscar: There are lots of things that are not about security as such, DoS protection with MUD for example.
Matthias: need also new security mechanisms. Need to identify what is not currently possible.
Thorsten: don't want to call security mechanism, but discovery
Matthias: we don't know yet what we have; have rough idea. Maybe I have multiple applications running on host and IP address is no longer endpoint. Then proxy in between that is allowed to alter the data.
Alex: good idea: ZigBee example, if it's not IP it's not end to end (secure). Laziness. Important in IETF to say that there are difficult problems and we don't want to build silos. What if IETF says if you don't do IP you're not end to end secure.
Dirk: maybe we don't need to be obsessed on OSI layers. Many things in Internet not applicable to IoT. Necessary to think what are really the requirements. Maybe need to deviate a bit from the holy grail of IETF.
Jaime: not security expert so need to work with something that exists. If not something like IP, how to find the caveats?
Francesca: when working at the application layer solution needed to define what kind of end to end. What we did was took CoAP and considered different intermediaries. Analyzed the threats in those. Security association between endpoints. Did this only for CoAP.
Alex: what is end to end security? End to end security is underspecified.
Ari: exactly; need to qualify endpoints and security
Matthias: for this what end to end means; proxies in CoAP. Tomorrow at OCF they have mobile device and OCF cloud. Smart home and devices, smart phone, all trusted. Talk to cloud. Want to create trusted channel. But trust the cloud not to be evil. Design space needs to be modular. For example on mailing list Hannes pointed out that the proposed security not working. Need clarify design space.
Thorsten: in some part of design process discover need to use CoAP for example. Without defining endpoints and trust model can't have end to end security.
Matthias: take your tools, CoAP and OSCOAP for example, and then do analysis based on those pieces.
Alex: everything we say here confirms that end to end is ambiguous.
Thorsten: what could do here is take principle from SW; make test case first and then see if your system address that. "You need to be secure against these threats".
Matthias: toolset defined in REST does not address all we are addressing here. Process of Fielding could be used but not perhaps the results.
Alex: In OCF software component endpoints. Want your security between software components.
Ari summarizing:
● E2E is ambiguous
● Security is ambiguous
● We need to qualify when talking of these
Francesca: security solution should define
● What are the endpoints
● What needs to be protected
● For each thing that needs to be protected, you need to define security goals / threats
Matthias: threats come later, when you have a system
Alex: we agree that itÕs ambiguous
Matthias: need define what are the endpoints, what are security goals
Jaime: need to qualify ÒendpointÓ -- specific to layer
(long discussion on conclusions and right wording; the result shown below)
Conclusions:
● To remove ambiguity of "end to end" on security. Need to qualify what kind of "end"
○ Examples: "IP endpoint", "application on host"
● Likewise for "security": Need to define what are the security objectives (confidentiality, integrity, availability, ...).
You have to consider intermediaries as long as you havenÕt achieved e2e security — as soon as you have, you no longer need to consider them. Security objective of availability is different, here you really have to consider the intermediaries.
There is a trap here: For full security, need to still consider full system (e.g., including hardware, endpoint security) — this is then not an argument against Òend-to-endÓ security.
Klaus:
● We work with abstractions; use term e2e when there are things in between.
● ÒE2e securityÓ: handling threats that are related to these intermediaries
Matthias: You have to consider intermediaries as long as you havenÕt achieved e2e security — as soon as you have, you no longer need to consider them.
Oscar: Security objective of availability is different, here you really have to consider the intermediaries.