draft-iab-iotsu-workshop-00.txt   draft-iab-iotsu-workshop-01.txt 
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft ARM Limited Internet-Draft ARM Limited
Intended status: Informational S. Farrell Intended status: Informational S. Farrell
Expires: April 29, 2017 Trinity College Dublin Expires: August 7, 2017 Trinity College Dublin
October 26, 2016 February 3, 2017
Report from the Internet of Things (IoT) Software Update (IoTSU) Report from the Internet of Things (IoT) Software Update (IoTSU)
Workshop 2016 Workshop 2016
draft-iab-iotsu-workshop-00.txt draft-iab-iotsu-workshop-01.txt
Abstract Abstract
This document provides a summary of the 'Workshop on Internet of This document provides a summary of the 'Workshop on Internet of
Things (IoT) Software Update (IOTSU)' which took place at Trinity Things (IoT) Software Update (IOTSU)' which took place at Trinity
College Dublin, Ireland on the 13th and 14th of June, 2016. The main College Dublin, Ireland on the 13th and 14th of June, 2016. The main
goal of the workshop was to foster a discussion on requirements, goal of the workshop was to foster a discussion on requirements,
challenges and solutions for bringing software and firmware updates challenges and solutions for bringing software and firmware updates
to IoT devices. This report summarizes the discussions and lists to IoT devices. This report summarizes the discussions and lists
recommendations to the standards community. recommendations to the standards community.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 29, 2017. This Internet-Draft will expire on August 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements and Questions Arising . . . . . . . . . . . . . 5
4. Authorizing a Software / Firmware Update . . . . . . . . . . 12 4. Authorizing a Software / Firmware Update . . . . . . . . . . 12
5. End-of-Support . . . . . . . . . . . . . . . . . . . . . . . 12 5. End-of-Support . . . . . . . . . . . . . . . . . . . . . . . 12
6. Incentives . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Incentives . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Measurements and Analysis . . . . . . . . . . . . . . . . . . 14 7. Measurements and Analysis . . . . . . . . . . . . . . . . . . 15
8. Firmware Distribution in Mesh Networks . . . . . . . . . . . 15 8. Firmware Distribution in Mesh Networks . . . . . . . . . . . 16
9. Compromised Devices . . . . . . . . . . . . . . . . . . . . . 16 9. Compromised Devices . . . . . . . . . . . . . . . . . . . . . 16
10. Miscellaneous Points . . . . . . . . . . . . . . . . . . . . 16 10. Miscellaneous Points . . . . . . . . . . . . . . . . . . . . 17
11. Tentative Conclusions and Next Steps . . . . . . . . . . . . 18 11. Tentative Conclusions and Next Steps . . . . . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
15. Appendix A: Program Committee . . . . . . . . . . . . . . . . 19 15. Appendix A: Program Committee . . . . . . . . . . . . . . . . 19
16. Appendix B: Accepted Position Papers . . . . . . . . . . . . 19 16. Appendix B: Accepted Position Papers . . . . . . . . . . . . 19
17. Appendix C: List of Participants . . . . . . . . . . . . . . 21 17. Appendix C: List of Participants . . . . . . . . . . . . . . 21
18. Informative References . . . . . . . . . . . . . . . . . . . 22 18. Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document provides a summary of the 'Workshop on Internet of This document provides a summary of the 'Workshop on Internet of
Things (IoT) Software Update (IOTSU)' [IoTSU], which took place at Things (IoT) Software Update (IOTSU)' [IoTSU], which took place at
Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. Trinity College Dublin, Ireland on the 13th and 14th of June, 2016.
The main goal of the workshop was to foster a discussion on The main goal of the workshop was to foster a discussion on
requirements, challenges and solutions for bringing software and requirements, challenges and solutions for bringing software and
firmware updates to IoT devices. firmware updates to IoT devices.
skipping to change at page 3, line 41 skipping to change at page 3, line 41
example [OS14], example [OS14],
- Operational challenges such as the case of an expired certificate - Operational challenges such as the case of an expired certificate
in a hub device [BB14], in a hub device [BB14],
- Privacy issues if devices "call home" often to check for updates - Privacy issues if devices "call home" often to check for updates
- A lack of incentives to distribute software updates along the - A lack of incentives to distribute software updates along the
value chain value chain
- Who should be able to update devices, and when, e.g., at or after - Who should be able to update device software after normal support
the end-of-support of a product or component. stops? When should an alternate source of software updates take
over?
There are various (often proprietary) software update mechanisms in There are various (often proprietary) software update mechanisms in
use today and the functionality of those varies significantly with use today and the functionality of those varies significantly with
the envisioned use of the IoT devices. More powerful IoT devices, the envisioned use of the IoT devices. More powerful IoT devices,
such as those running general purpose operating systems (like Linux), such as those running general purpose operating systems (like Linux),
can make use of sophisticated software update mechanisms known from can make use of sophisticated software update mechanisms known from
the desktop and the mobile world. This workshop focused on more the desktop and the mobile world. This workshop focused on more
constrained IoT devices that often run dedicated real-time operating constrained IoT devices that often run dedicated real-time operating
systems or potentially no operating system at all. systems or potentially no operating system at all.
skipping to change at page 5, line 39 skipping to change at page 5, line 42
and A-class devices use a combination of firmware and software and A-class devices use a combination of firmware and software
updates (with firmware updates being less frequent operations). updates (with firmware updates being less frequent operations).
Hitless Update: A hitless update implies that the user experience is Hitless Update: A hitless update implies that the user experience is
not "hit", i.e., it is not impacted. It is possible to impact the not "hit", i.e., it is not impacted. It is possible to impact the
user experience when applying an update even when the device does user experience when applying an update even when the device does
not reboot (to obtain or apply said update). If the update is not reboot (to obtain or apply said update). If the update is
applied when a user is not using a product and their service is applied when a user is not using a product and their service is
not impacted, the update is "hitless". not impacted, the update is "hitless".
3. Requirements 3. Requirements and Questions Arising
Workshop participants discussed requirements and several of these Workshop participants discussed requirements and several of these
raised further questions. As with the previous section we aim to raised further questions. As with the previous section we aim to
present the discussion as it was. present the discussion as it was.
- There may be a need to be support partial (differential) updates, - There may be a need to be support partial (differential) updates,
that do not require the entire firmware image to be sent. This that do not require the entire firmware image to be sent. This
may mean that techniques like bsdiff [bsdiff] and courgette may mean that techniques like bsdiff [bsdiff] and courgette
[courgette] are used but might also mean devices supporting [courgette] are used but might also mean devices supporting
download of applications and libraries alone. The latter feature download of applications and libraries alone. The latter feature
skipping to change at page 6, line 34 skipping to change at page 6, line 36
images to the attached micro-controllers within its local realm. images to the attached micro-controllers within its local realm.
The alternative of letting each microcontroller interact with an The alternative of letting each microcontroller interact with an
update service appeared less practical. update service appeared less practical.
- Support may be required for devices with multiple owners/ - Support may be required for devices with multiple owners/
stakeholders where the question arises about who is authorized to stakeholders where the question arises about who is authorized to
push a firmware/software update. push a firmware/software update.
- Data origin authentication (DAO) was agreed to be required for - Data origin authentication (DAO) was agreed to be required for
software updates. Without DAO, updates simply become a perfect software updates. Without DAO, updates simply become a perfect
vulnerability. DAO has most commonly been provided via digital vulnerability. It is however non-trivial to ensure the actual
signature mechanisms, but symmetric schemes could also be
developed. In all cases, it is non-trivial to ensure the actual
trust relationships that exist are modelled by the DAO mechanism. trust relationships that exist are modelled by the DAO mechanism.
For some devices and deployment scenarios, any DAO mechanism is For some devices and deployment scenarios, any DAO mechanism is
onerous, possibly to the point where it may be hard to convince a onerous, possibly to the point where it may be hard to convince a
device-maker to include the functionality. device-maker to include the functionality.
- Should digital signatures and encryption for software updates be - Should digital signatures and encryption for software updates be
recommended as a best current practice? This question recommended as a best current practice? This question
particualrly raises the question about the use of symmetric key particualrly raises the question about the use of symmetric key
cryptography since not all low end IoT devices are currently using cryptography since not all low end IoT devices are currently using
asymmetric crypto. asymmetric crypto.
- DAO is most commonly provided via digital signature mechanisms,
but symmetric schemes could also be developed, though IETF
discussion of such mechanisms (for purposes less sensitive than
software update) has proved significantly controversial. The main
problem seems to be that simple symmetric schemes only ensure that
the sender is a member of a group and do not fully authenticate a
specific sender. And with software update, we do not want any
(possibly compromised) device to be able to be authenticate new
software for all other similar devices.
- What are the firmware update signing key requirements? Since - What are the firmware update signing key requirements? Since
devices have a rather long lifetime there has to be a way to devices have a rather long lifetime there has to be a way to
change the signing key during the lifetime of the device. change the signing key during the lifetime of the device.
- Should a firmware update mechanism support multiple signatures of - Should a firmware update mechanism support multiple signatures of
firmware images? Multiple signatures can come in two different firmware images? Multiple signatures can come in two different
flavours, namely flavours, namely
a single firmware image may be signed by multiple different a single firmware image may be signed by multiple different
parties. In this case one could imagine an environment where parties. In this case one could imagine an environment where
skipping to change at page 10, line 26 skipping to change at page 10, line 37
Which are required? Not all of these are required to achieve Which are required? Not all of these are required to achieve
improvement. What are most important? improvement. What are most important?
Among the participants there was consensus that supporting signatures Among the participants there was consensus that supporting signatures
(for integrity and authentication) of the firmware image itself and (for integrity and authentication) of the firmware image itself and
the need for partial updates was seen as important. the need for partial updates was seen as important.
There were, however, also concerns regarding the performance There were, however, also concerns regarding the performance
implications since certain device categories may not utilize public implications since certain device categories may not utilize public
key cryptography at all and hence only a symmetric key approach seems key cryptography at all and hence only a symmetric key approach seems
viable. This aspect raised concerns and trigger a discussions around viable, unless some other scheme such as hash-based signature become
the use of device management infrastructure, similar to Kerberos, practical (they currently aren't due to signature size). This aspect
that manages keys and distributes them to the appropriate parties. raised concerns and trigger a discussions around the use of device
As such, in this set-up there could be a unique key shared with the management infrastructure, similar to Kerberos, that manages keys and
key distribution center but for use with specific services (such as a distributes them to the appropriate parties. As such, in this set-up
software update service) a fresh and unique secret would be there could be a unique key shared with the key distribution center
distributed. but for use with specific services (such as a software update
service) a fresh and unique secret would be distributed.
In addition to the requirements for the end devices there are also In addition to the requirements for the end devices there are also
infrastructure-related requirements. The infrastructure may consist infrastructure-related requirements. The infrastructure may consist
of servers in the local network and/or various servers deployed on of servers in the local network and/or various servers deployed on
the Internet. It may also consist of some application layer the Internet. It may also consist of some application layer
gateways. The potential benefits of having such a local server might gateways. The potential benefits of having such a local server might
include: include:
- The local server acting for neighbouring nodes. For example, in a - The local server acting for neighbouring nodes. For example, in a
vehicle one micro-controller can process all firmware updates and vehicle one micro-controller can process all firmware updates and
skipping to change at page 17, line 43 skipping to change at page 18, line 9
quantum secure. A post-quantum cryptosystem is a system that is quantum secure. A post-quantum cryptosystem is a system that is
secure against quantum computers that have more than a trivial secure against quantum computers that have more than a trivial
number of quantum bits. It is open to conjecture whether it is number of quantum bits. It is open to conjecture whether it is
feasible to build such a machine but current signature algorithms feasible to build such a machine but current signature algorithms
are known to not be post-quantum secure. This would require are known to not be post-quantum secure. This would require
introducing technologies like the Hash-based Merkle Tree Signature introducing technologies like the Hash-based Merkle Tree Signature
(MTS) [housley-cms-mts-hash-sig], which was presented and (MTS) [housley-cms-mts-hash-sig], which was presented and
discussed at the workshop. The downside of such solutions are, discussed at the workshop. The downside of such solutions are,
their novelty, and for these use-cases, the fairly large signature their novelty, and for these use-cases, the fairly large signature
or key sizes involved, e.g., depending on the parameters a or key sizes involved, e.g., depending on the parameters a
signature could easily have a size of 20-30KiB [hashsig]. While signature could easily have a size of 5-10KiB [hashsig]. While it
it is likely that post-quantum secure signature algorithms will be is likely that post-quantum secure signature algorithms will be
needed for software update at some point in time, it may be the needed for software update at some point in time, it may be the
case that such algorithms will be needed sooner for services case that such algorithms will be needed sooner for services
requiring long term confidentiality, (e.g., using TLS) so it was requiring long term confidentiality, (e.g., using TLS) so it was
not clear that this application would be a first-mover in terms of not clear that this application would be a first-mover in terms of
post-quantum security. post-quantum security.
- Many devices that use certificates do not check the revocation - Many devices that use certificates do not check the revocation
status of certificates, even though extensions like OSCP stapling status of certificates, even though extensions like OSCP stapling
exists [RFC6961] and is increasingly deployed with Web browsers. exists [RFC6961] and is increasingly deployed with Web browsers.
The workshop participants were inconclusive regarding the The workshop participants were inconclusive regarding the
skipping to change at page 22, line 22 skipping to change at page 22, line 40
- Matthias Kovatsch, Siemens - Matthias Kovatsch, Siemens
- Milan Patel, Huawei - Milan Patel, Huawei
- Ned Smith, Intel - Ned Smith, Intel
- Robert Ensink, SpinDance - Robert Ensink, SpinDance
- Robert Sparks, Oracle - Robert Sparks, Oracle
- Russ Housley, Vigilsec - Russ Housley, Vigil Security
- Samita Chakrabarti, Ericsson - Samita Chakrabarti, Ericsson
- Stephen Farrell, Trinity College Dublin - Stephen Farrell, Trinity College Dublin
- Vassilis Prevelakis, TU Braunschweig - Vassilis Prevelakis, TU Braunschweig
- Hannes Tschofenig, ARM Ltd. - Hannes Tschofenig, ARM Ltd.
18. Informative References 18. Informative References
 End of changes. 16 change blocks. 
27 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/