< draft-ietf-suit-architecture-03.txt		draft-ietf-suit-architecture-04.txt >
	SUIT B. Moran		SUIT B. Moran
	Internet-Draft Arm Limited		Internet-Draft Arm Limited
	Intended status: Informational M. Meriac		Intended status: Informational M. Meriac
	Expires: September 12, 2019 Consultant		Expires: September 28, 2019 Consultant
	H. Tschofenig		H. Tschofenig
	Arm Limited		Arm Limited
	D. Brown		D. Brown
	Linaro		Linaro
	March 11, 2019		March 27, 2019
	A Firmware Update Architecture for Internet of Things Devices		A Firmware Update Architecture for Internet of Things Devices
	draft-ietf-suit-architecture-03		draft-ietf-suit-architecture-04
	Abstract		Abstract
	Vulnerabilities with Internet of Things (IoT) devices have raised the		Vulnerabilities with Internet of Things (IoT) devices have raised the
	need for a solid and secure firmware update mechanism that is also		need for a solid and secure firmware update mechanism that is also
	suitable for constrained devices. Incorporating such update		suitable for constrained devices. Incorporating such update
	mechanism to fix vulnerabilities, to update configuration settings as		mechanism to fix vulnerabilities, to update configuration settings as
	well as adding new functionality is recommended by security experts.		well as adding new functionality is recommended by security experts.
	This document lists requirements and describes an architecture for a		This document lists requirements and describes an architecture for a
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 September 12, 2019.		This Internet-Draft will expire on September 28, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 30 ¶
	- Device: A device refers to the entire IoT product, which consists		- Device: A device refers to the entire IoT product, which consists
	of one or many MCUs, sensors and/or actuators. Many IoT devices		of one or many MCUs, sensors and/or actuators. Many IoT devices
	sold today contain multiple MCUs and therefore a single device may		sold today contain multiple MCUs and therefore a single device may
	need to obtain more than one firmware image and manifest to		need to obtain more than one firmware image and manifest to
	succesfully perform an update. The terms device and firmware		succesfully perform an update. The terms device and firmware
	consumer are used interchangably since the firmware consumer is		consumer are used interchangably since the firmware consumer is
	one software component running on an MCU on the device.		one software component running on an MCU on the device.
	- Status Tracker: The status tracker offers device management		- Status Tracker: The status tracker offers device management
	functionality that includes keep track of the firmware update		functionality to monitor the firmware update process. A status
	process. This includes fine-grained monitoring of changes at the		tracker may, for example, want to know what state of the firmware
	device, for example, what state of the firmware update cycle the		update cycle the device is currently in.
	device is currently in.
	- Firmware Server: The firmware server stores firmware images and		- Firmware Server: The firmware server stores firmware images and
	manifests and distributes them to IoT devices. Some deployments		manifests and distributes them to IoT devices. Some deployments
	may require a store-and-forward concept, which requires storing		may require a store-and-forward concept, which requires storing
	the firmware images/manifests on more than one entity before		the firmware images/manifests on more than one entity before
	they reach the device.		they reach the device.
	- Device Operator: The actor responsible for the day-to-day		- Device Operator: The actor responsible for the day-to-day
	operation of a fleet of IoT devices.		operation of a fleet of IoT devices.
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 20 ¶
	The terms 'trust anchor' and 'trust anchor store' are defined in		The terms 'trust anchor' and 'trust anchor store' are defined in
	[RFC6024]:		[RFC6024]:
	- "A trust anchor represents an authoritative entity via a public		- "A trust anchor represents an authoritative entity via a public
	key and associated data. The public key is used to verify digital		key and associated data. The public key is used to verify digital
	signatures, and the associated data is used to constrain the types		signatures, and the associated data is used to constrain the types
	of information for which the trust anchor is authoritative."		of information for which the trust anchor is authoritative."
	- "A trust anchor store is a set of one or more trust anchors stored		- "A trust anchor store is a set of one or more trust anchors stored
	in a device. A device may have more than one trust anchor store,		in a device. A device may have more than one trust anchor store,
	each of which may be used by one or more applications."		each of which may be used by one or more applications." A trust
			anchor store must resist modification against unauthorized
			insertion, deletion, and modification.
	3. Requirements		3. Requirements
	The firmware update mechanism described in this specification was		The firmware update mechanism described in this specification was
	designed with the following requirements in mind:		designed with the following requirements in mind:
	- Agnostic to how firmware images are distributed		- Agnostic to how firmware images are distributed
	- Friendly to broadcast delivery		- Friendly to broadcast delivery
	skipping to change at page 25, line 12 ¶		skipping to change at page 25, line 12 ¶
	EMail: Brendan.Moran@arm.com		EMail: Brendan.Moran@arm.com
	Milosch Meriac		Milosch Meriac
	Consultant		Consultant
	EMail: milosch@meriac.com		EMail: milosch@meriac.com
	Hannes Tschofenig		Hannes Tschofenig
	Arm Limited		Arm Limited
	EMail: hannes.tschofenig@gmx.net		EMail: hannes.tschofenig@arm.com
	David Brown		David Brown
	Linaro		Linaro
	EMail: david.brown@linaro.org		EMail: david.brown@linaro.org
End of changes. 7 change blocks.
	10 lines changed or deleted		11 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/