T2TRG Discovery meeting at IETF 98. Chicago, IL, US
Chairs: Carsten Bormann & Ari Keränen
1300-1500 Afternoon Session I: Vevey 1/2
| time | topic |
|---|---|
| 13:00 | Intro, RG status |
| 13:10 | Intro to breakout #1 |
| 13:15 | Breakout #1 |
| 13:50 | Intro to breakout #2 |
| 13:55 | Roll call of breakout #1 results |
| 14:05 | Breakout #2 |
| 14:40 | Meeting planning |
| 14:50 | Roll call of breakout #2 results |
| 15:00 | Beverage Break |
Carsten started by giving a short overview of the research group status, as collected in https://www.ietf.org/proceedings/98/slides/slides-98-t2trg-slides-01.pdf
The main objective of the meeting, however, was to conduct two groups of four breakouts each, each conducted by a facilitator, and summarized to the whole group in two brief roll calls.
The rest of these meetings proceedings provides summaries of these breakout groups. The facilitators did not have detailed instructions on how to document the breakout, so the styles of the next eight sections differ significantly. The summary here gives the facilitator’s name, the loose “topic” given, what it apparently turned into in the discussion, and whatever documentation is available today from the breakout. Thank you to the facilitators and to the note takers!
“What needs to be done to make systems interoperate that employ different kinds of data models in their components”
➔ How to Deal with Different Kinds of Data Models?
Please put your name here (e.g., pull request or mail to the list)
“What are the problems that need to be solved before I can reasonably transfer authority to access a bunch of IoT devices to a new owner when I sell my house”
Report from t2trg breakout session, 2017-03-27.
Thanks to Dominique Barthel for taking notes.
Topic: What problems need to be solved before I can transfer ownership of IoT devices when I sell my house?
Summary/Conclusions:
IoT devices exist in a web of relationships and interconnections. Some devices will be part of systems that stay with the house and, therefore, must be transferred to the new owner, while other devices will go with the old owner to a new residence. Any configuration state that links devices that will stay with the home with devices that will leave must be cleared. Similarly, any configuration state that represents confidential information about the old owner must be cleared. There may be some parallels between the process for IoT devices and familiar processes for transfer of utilities accounts, but the scale of the interconnections will complicate the transfer process for IoT devices.
The relationships among IoT devices may be mitigated by controllers, where ownership and control of a set of IoT devices may be managed through a single controller. Similarly, cloud services may allow transfer of ownership of an entire system of IoT devices through a single interface. The relationships may change dynamically; for example, the IoT devices in an automobile may have a relationship with devices in a home while parked at home, but then have a different relationship while away from home.
The transfer can take place in one of two ways: as a direct transfer from the old owner to the new owner or through a trusted third party. The transfer process must ensure that the new owner has complete and exclusive authority over the devices. Authority to access the devices from external sources like a personal smart phone must be revoked. There may be parallels between transferring ownership between owners and an initial transfer from manufacturer to the first owner.
Other events, such as home rental, providing access to service personnel or allowing one-time access for a delivery, will have similar considerations.
Barry Leiba also provided the following notes:
Topic: How do we handle ownership turnover of IoT devices when, for example, someone sells his house?
It quickly becomes clear that this is a really difficult question — more so than it seems on the surface. The discussion mostly went around what the challenges are, rather than about solutions. Major challenges circle around the complexity of the inter-device relationships and the difficulty of figuring out automatically how to handle each device. Consider selling a house that has connected light bulbs, refrigerator, alarm clocks, and a coffee maker: the new owner will (probably) get the bulbs and the refrigerator, but has to be confident that the alarm clocks and coffee maker, which went with the former owner, are fully disconnected and can’t get back in. Similarly for any smartphones that might be able to open door locks: the door locks stay, but the smart phones go, and have to be securely removed.
But the refrigerator can also be sold by itself at any time, and even in a house sale it might be taken by the former owners, so its status isn’t automatically known. Also, consider a child going off to college: her alarm clock should no longer be part of the system, and her smart phone’s calendar should no longer affect the house operation, but her smart phone should still operate the door locks.
Barry has prepared some slides that elaborate on this discussion for follow-on in W3C WoT, which are available at: https://github.com/t2trg/2017-ietf98/blob/master/slides/IoT-WoT-T2T%20transfer%20of%20ownership.pdf
“What if Alice is evil and Bob doesn’t get a chance to scream?”
(Notes by Ing-Wher Chen)
Different devices, how each protects itself? What happens when a device is under attack? Carol attacks. How to protect against Carol but still communicate? Bob and Alice still want to communicate. Second class: Good actor turns bad. Bob becomes compromised and turns into a bad actor. Third class: Bob and Alice are a system, what if they join forces and attack?
Methodologies to break down these scenarios. Identities as a start? Need mechanism to attach trust to them? Identity and trust model; trust and identity are two topics to consider.
Not limited to IP.
Fault tolerant models. Passive things.
What are the big challenges?
How to grow trust organically? Emulate people? Living breathing? Does histroy matter? Reputation? What about passive objects? Trust anchor, not just remote trust anchor. Can the history be verified?
Privacy? How do Bob and alice establish trust to protect data being communicated? “Crowded room” problem, can make contact but …?
Policy establishment/management? Who manages access control? Verify that policy has been adhered to. E.g. coonfidentiality of data should stay with data.
Group security privacy and trust, large scale? This is a problem that the ACE WG is working on.
Locality of security decision? Proximity or autonomy? Can local decision be valid?
What is the role of the oracle?
Protection and detection, vs privacy?
What are the dimensions of distributed systems? Numbers, capabilities, dynmaics/changes/non-static (group membership changes), cyber physical (real world dangers)? Constrained system. Quantity of devices. Heterogeneity (protocols, ownership, vendors, etc). Amount of data that comme out of “things”.
Augmented reality are passive objects, which might be tampered with. Vehicle breaking, etc. Dumb things and smart things co-exist.
“Converging network on-boarding with application layer setup? How can I use application credentials to join the network or v.v. Can we reduce TCO in the process?”
➔ Topic: Use of application credentials for enabling network access (and vice-versa).
Participants (15 active): Erik Nordmark (note taker), Mohit Sethi (breakout leader), Thorsten Dahm, Donald Eastlake, Behcet Sarikaya, Demir Rakanovic, Phillip Hallam-Baker, Grace Lewis, Ludwig Seitz, Muhhamad Sajjad, Jari Arkko, Laurent Toutain, Hitoshi Asaeda, Francesca Palombini, Stephen Kraiman.
It can be useful to enable network access for IoT devices using application credentials: This leads to less configuration work for the user of a new IoT device which is especially beneficial since the devices often have limited UI. Think of a new IoT toothbrush that you have just purchased. You bring it home and register it with the manufacturer (by reading a serial number/public key/scanning QR code etc.). It would be nice if the manufacturer can then tell the Access Point (AP) at the users home to enable limited Internet connectivity for the device.
Interesting to investigate if we can reverse the direction of enabling network-access: Instead of adding software and hardware complexity in the devices itself, it would make sense to simply put the dumb IoT devices at the desired location and then enable access from a server which is more resourceful.
Isolation: It would also be smart to put the IoT devices in separate VLANs. When the device is authenticated as an IoT device it should be put in its separate VLAN so that it has limited connectivity to only a couple of services (such as calling home for software update etc).
Scaling this to 1000s or 10k devices can be a challenge. This also relates to the fact that enterprise scenarios are very different from the home scenarios. Enterprises may not want to delegate network access authentication to an external third party (such as the IoT device manufacturer).
Revoking network access should be secure and simple. For example, if one of the IoT devices is lost or sold, it shouldn’t require you to change the network-access credentials for all the devices.
Possible Research work: Can we use existing protocols (802.1x/RADIUS/DIAMETER) for enabling such network access based on application credentials.
[Note that this breakout report then triggered a discussion thread on the T2TRG list: https://mailarchive.ietf.org/arch/search/?email_list=t2trg&q=breakout+on+using+application+credentials]
“Edge computing issues”
This section is documented by Dirk Kutscher and Eve Schooler in https://github.com/t2trg/2017-ietf98/blob/master/slides/T2TRGEdgeComputing.pdf, which see.
“What would it mean to configure some remote certificates on a device which then sits in a drawer for 2 years and will then be expected to be deployed for 10 years, when the lifetime of that certificate is 1 year?”
Report from t2trg breakout session, 2017-03-27.
Topic: Breakout on certificate lifetimes for long-lived devices
Thanks to Mohit Sethi for taking notes.
Participants who wrote their name: Erik Nordmark (lead), Mohit Sethi (note taker), Robert Sparks, Anorow Auow (sp?), Barry Leiba, Alper Yegin, Dominique Barthel, Thorsten Dahm, Elliot Lear, Phillip Hallam-Baker
The questions we asked ourselves was examplified by “What would it mean to configure some remote certificates on a device which then sits in a drawer for 2 years and will then be expected to be deployed for 10 years, when the lifetime of that certificate is 1 year?”
From that starting point the group explored different aspects of security for long-lived devices.
One question was whether the device lifetime be the same as device certificate lifetime, and folks seemed to say that if the certificate expires the device would be likely to be bricked.
What does it mean to have a device lifetime? The lifetime of the local state vs. the state in the cloud could be different. Would the cloud forget about the existence of the device after the lifetime? Or can we assume that the state in the cloud lives forever?
One question was around the purpose of the device certificate. If you only use it for saying the device was manufactured by X and it doesn’t give you access to the network, then its OK to never revoke.
But can you update the device cert if the curve is compromised? And would such an attack give access to a single device vs. all of them?
For the device that sits in the drawer for 2 years, an observation when it connects it might find that it has out-of-date software, hence need to update itself before proceeding. Might want to get a notification that an old device is being turned on. But there could also be deployment keys in that old device that have been compromised while it was in the drawer.
Research/hard questions:
“Early discovery: DHCP, Multicast, Anycast, ND, … What is the preferred tool (for any particular space) and why? (Does it have the properties we need)”
Dave Thaler captured the discussion into one text slide, which is reproduced as text here:
“What problems are we running into by running different kinds of systems on the same networks? What could be done to increase coexistence?”
What do we know about the different systems that are on the same networks now?
Historically, multiple systems have been arising based on perceived or real constraints. Observe that implementation constraints tend to be temporary (not all constraints, but many, such as the view that crypto requires too many cycles). Is there a continuum on which multiple constraint-designed systems could designed so that they coexist or synergize more? Perhaps T2TRG research can address extensible design patterns that address this case of constraints becoming obsolete and new environments presenting new challenges.
Types of difference at the lowest physical layer - should be ignored (below the narrow waist).
Types of difference - same sensor functions, heterogeneous devices - application issue?
Other categories of difference in systems affecting discussion:
Make sure to be aware of Core WG drafts that cover some of this ground
Potential high-level architecture from discussion:
NOTE: several of the group members spoke up and said they hadn’t realized they had contributions they could make til they were in this small group. There was in particular a small follow-on discussion from someone who works with cognitive radio.