< draft-ietf-suit-architecture-09.txt		draft-ietf-suit-architecture-10.txt >
	SUIT B. Moran		SUIT B. Moran
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Intended status: Informational Arm Limited		Intended status: Informational Arm Limited
	Expires: November 23, 2020 D. Brown		Expires: November 28, 2020 D. Brown
	Linaro		Linaro
	M. Meriac		M. Meriac
	Consultant		Consultant
	May 22, 2020		May 27, 2020
	A Firmware Update Architecture for Internet of Things		A Firmware Update Architecture for Internet of Things
	draft-ietf-suit-architecture-09		draft-ietf-suit-architecture-10
	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 43 ¶		skipping to change at page 1, line 43 ¶
	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 November 23, 2020.		This Internet-Draft will expire on November 28, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 3, line 49 ¶		skipping to change at page 3, line 49 ¶
	This version of the document assumes asymmetric cryptography and a		This version of the document assumes asymmetric cryptography and a
	public key infrastructure. Future versions may also describe a		public key infrastructure. Future versions may also describe a
	symmetric key approach for very constrained devices.		symmetric key approach for very constrained devices.
	While the standardization work has been informed by and optimised for		While the standardization work has been informed by and optimised for
	firmware update use cases of Class 1 (as defined in RFC 7228		firmware update use cases of Class 1 (as defined in RFC 7228
	[RFC7228]) devices, there is nothing in the architecture that		[RFC7228]) devices, there is nothing in the architecture that
	restricts its use to only these constrained IoT devices. Software		restricts its use to only these constrained IoT devices. Software
	update and delivery of arbitrary data, such as configuration		update and delivery of arbitrary data, such as configuration
	information and keys, can equally be managed by manifests. The		information and keys, can equally be managed by manifests.
	solution therefore applies to more capable devices, such as network
	storage devices, set top boxes, and IP-based cameras as well.
	More details about the security goals are discussed in Section 5 and		More details about the security goals are discussed in Section 5 and
	requirements are described in Section 3.		requirements are described in Section 3.
	2. Conventions and Terminology		2. Conventions and Terminology
	This document uses the following terms:		This document uses the following terms:
	- Manifest: The manifest contains meta-data about the firmware		- Manifest: The manifest contains meta-data about the firmware
	image. The manifest is protected against modification and		image. The manifest is protected against modification and
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 8 ¶
	- Robust permissions		- Robust permissions
	- Diverse modes of operation		- Diverse modes of operation
	- Suitability to software and personalization data		- Suitability to software and personalization data
	3.1. Agnostic to how firmware images are distributed		3.1. Agnostic to how firmware images are distributed
	Firmware images can be conveyed to devices in a variety of ways,		Firmware images can be conveyed to devices in a variety of ways,
	including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and		including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and
	use different protocols (e.g., CoAP, HTTP). The specified mechanism		use different protocols (e.g., CoAP, HTTP). The specified mechanism
	needs to be agnostic to the distribution of the firmware images and		needs to be agnostic to the distribution of the firmware images and
	manifests.		manifests.
	3.2. Friendly to broadcast delivery		3.2. Friendly to broadcast delivery
	This architecture does not specify any specific broadcast protocol.		This architecture does not specify any specific broadcast protocol.
	However, given that broadcast may be desirable for some networks,		However, given that broadcast may be desirable for some networks,
	updates must cause the least disruption possible both in metadata and		updates must cause the least disruption possible both in metadata and
	firmware transmission.		firmware transmission.
End of changes. 6 change blocks.
	8 lines changed or deleted		6 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/