Conclusions, anyone?

1
Conclusions, anyone?
2
The Problem Definition

• How to prevent Cullen from p0wning all the
  lightbulbs in the city?

3
What We Need to KeepCullen 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,
  crypto agility can be provided, minimize IPR
  cost, on widest range of HW, ...

4
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

5
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 L2some 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

6
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 IETF activity?

7
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

8
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?)

9
Questions That We Didn't Get To...

• What about middleboxes

10
Detailed Notes... unprocessed
11
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.

12
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

13
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 gt 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

14
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-specifi
  c
• 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

15
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.

16
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)

17
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?