The Problem Definition

How to prevent Cullen from p0wning all the
lightbulbs in the city?
What We Need to Keep
Cullen from Doing This
1) Introduce devices to each other
2) Authorize each participant for allowable actions
3) Secure the communications
4) Enforce that all actions are authorized
5) Implement in a set of nodes (some small)
… while making sure that re-configuration is
possible, user interfaces are usable, you can
switch any participant or operator to another,
Possible Conclusions from the
Requirements & Economics
Discussion
Requirements for each application differ
 Installation by regular people
 Need to add devices, change owners, etc.
 Threats are not just from neighbor's kids
• Also, e.g., taking-the-grid-down attacks
 Individual vs. 1 million device users
 Must worry about business models and partners
 Open interfaces, few regulations are good

Possible Conclusions from the
Implementation Experiences
We think we can use the existing algorithms
 We probably can use the existing protocols
• Data formats, DTLS, TLS, L2 security, (U)SIM, ikev2, … etc but pick

just one per category... but hard to do for L2+some other security
• Hard for other designs to improve significantly
• Some areas may need further clarification
• E.g., using COAP and TLS together
•Network access security not looked at in the WS
Look at the code size of the entire system
• Including provisioning, authorization, config
 Focus on the system!
 Unwanted traffic
 Energy matters more than code size or time
 Wireless reception the most expensive task

Possible Conclusions from the
Authorization Discussion

Important to decide how authorization is decided
•And how it flows to the PEPs
All the above might be application-specific
 Good to separate capabilities from users

•E.g. Oauth
•OAuth is quite browser focused, attribute certs etc were never deployed
•Possible IETF action? (But how to deploy it?)
If you wish to restrict the complexity of your
implementation, you will need to restrict your
deployment environment (e.g. number of peers)
 User interface matters

•Often, devices have no user interface, and all interaction is in the backend

Work on introduction models!
•If we had a taxonomy of introduction, we could provide generic patterns to how
you can do authorization under those introduction models
Possible Conclusions from the
Imprinting Discussion

There is a limited set of solutions
•Based on whether you assume buttons vs. labels vs. LEDs, multicast
discovery, online network availability, ...
Important to separate vendor and user CAs
 Labels given to humans should use a checksum
 A fun area to design protocols in

Possible IETF Actions
Protocol-related:
 Clarifying how to use DTLS with COAP
 Complete the JOSE work
 LWIG-like guidance on security protocol impls.?
 Pairing/imprinting protocols?
•Is this something IETF can provide additional value in? Is the scenario that Cullen
proposed interesting & something that the industry needs?
Certificate compression mechanisms?
 Compression of DTLS over 6Lowpan? (already in RFC?)
 Making 6lowpan hc recognize ESP
 Recommendations on how to use network access protocols
 Security for ROLL/RPL/MANET
Higher-level issues:
 Guidance for introduction models?
Question marks:
 Do we need Oauth-for-IOT? Deployable?

•The model may be usable outside browsers, but the protocol design does not seem
optimized for constrained devices

Rene: not all crypto supported by all protocols?
•Binary curves? (possibly already in DTLS RFC?)
Questions That We Didn't Get To...

What about middleboxes
Detailed Notes 1
Paul Chilton, Lighting
•Has to be installed by the average person
•Initially no internet access, purely local control, get people familiar with the
concept
•Add a gateway, enable applications, web, …
•Challenges: ease of commissioning, discovery, ease of re-configuration, device
authentication, cost, sleeping and energy harvesting, privacy, …
•Questions:

•Then again, these lightbulbs do more than usual ones, so maybe then can be more complex to use.
But that would only give us the techie users, not general public... and there is no margin for running a
helpdesk
•Subir: Why connect e2e to each lightbulb, why not to a switch that controls a group of lightbulbs.
Cullen thinks that its just more practical to replace lighbulbs than central power equipment
•Ekr: there are global attacks, e.g., turning on all devices on at the same time, what does that do the
grid?
•Randy: focus on identity, trust, and authorization, not just the lights example. Fred baker thinks that it
is useful to think about the example to make something really foolproof but also simple
•Ekr: I want to understand the threat model. I only want myself to be able to access my devices,
unless I explicitly configure additional people. Mark Townsley: iTunes
•Cullen thinks that we are going to live in a world where if there is no enrollment attackers can do bad
things. Ekr thinks that not acceptable.
Detailed Notes 2
Rudolf van Berg, economics & competition
•The one million device user
•Lots of discussion about whether sim cards are a good model
•Voip experience said that operators do not want to open up

Detailed Notes 3
Implementation experience
•Carsten:
•Moore's law not going to fix it
•Discover – imprint – configure
•DTLS making COAP more complex, more messages, etc.
•Many ways to use DTLS
•Ekr questions the choice to run DTLS on top of COAP
•Minimal DTLS implementation 13K with symmetric crypto only, AES in hw
•State machine dominates the implementation
•Hannes:
•Communication relationships more important than protocols, crypto
•Lower footprint => fewer functions (PKs, resumption, etc)
•Mohit:
•Public key crypto doable at least in some cases on 8-bit CPUs
•Joules are more important than time or code/time

Detailed Notes 4
Authorization
•Richard Barnes:

•Is imprinting all we need?
•Principals in home: owner, guest, child, neighbor, alarm co, TV, HVAC, smart meter, …
•From simple models to the next generation. E.g., from passwords to Oauth
•OAuth allows separating capabilities from users, e.g., give your TV access to netflix
•Questions:
•Where does identity come from? Hashes and bar codes?
•Who makes authorization decisions? Where is authorization checked?
•Is any of this general, or all application-specific
•Cullen: What do the user interfaces look like?
•Michael: configuration and authorship happens in ”home depot” web site
•Michael: need to get on first to ”guest” network so that it can call home depot
•Carsten: very important to design for choice
•Jan
•Open questions: what protocol to use for attribute-based AC?
•Mapping of credentials to COAP/HTTP requests
•Standardized authorization policy formats have not been deployed
•Other
•Is typing in serial numbers feasible, or are there better approaches?
What We Learned
Challenges
•We need solutions that can be installed by the average person
•Interoperability in a multi-vendor environment
•The 1 million device users
 There are significant grid & local damage attacks that we have to worry
about
 Make it simple and secure. The challenge.
 Implementation sizes:
•DTLS from 13K up
 Useless to discussion protocols alone, have to understand what the
whole system needs to do, incl. provisioning, etc. Then we know code
sizes, ease of use, etc.
 Roundtrips vs. Memory size vs. Message sizes; message sizes are
important
 Sam worries about combining large scale deployments and claims
about knowing how we can restrict to constrained devices. Suggests that
restricting the number of parties that devices need to talk to is going to
be useful.

Working Solutions
Provisioning & authorization
• A box of lightbulbs, configured to work together at the factory
(Paul)
• ”Things” tied to the owner upon purchase time at iTunes shop
etc (Mark)
• Restricting nodes that devices need to talk to (Sam)
Protocols
•
•
•
•
DTLS, TLS
Data-object security
OAuth
Hard to see other designs that would be significantly better
Crypto
• Standard crypto operations
• PK operations, even on 8-bit CPUs (infrequently, with ECC, etc)
Questions to Answer &
Problems to Solve
What is an acceptable level of security?
 How do I add new devices to an existing
network?
 How do I authorize an Android device to control
a home automation setup?
 Can I build a system for my house that does not
require a third party?
 Security and middleboxes?
