idnits 2.17.1 draft-moran-suit-manifest-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 02, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 291 == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-01 ** Downref: Normative reference to an Informational draft: draft-ietf-suit-architecture (ref. 'I-D.ietf-suit-architecture') == Outdated reference: A later version (-13) exists of draft-ietf-suit-information-model-00 ** Downref: Normative reference to an Informational draft: draft-ietf-suit-information-model (ref. 'I-D.ietf-suit-information-model') Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft H. Tschofenig 4 Intended status: Standards Track Arm Limited 5 Expires: January 3, 2019 July 02, 2018 7 A CBOR-based Manifest Serialisation Format 8 draft-moran-suit-manifest-02 10 Abstract 12 This specification describes the serialization format of a manifest. 14 A manifest is a bundle of metadata about the firmware for an IoT 15 device, where to find the firmware, the devices to which it applies, 16 and cryptographic information protecting the manifest. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 66 2.1. Manifest Serialization Format . . . . . . . . . . . . . . 3 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 5. Mailing List Information . . . . . . . . . . . . . . . . . . 5 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 A firmware update mechanism is an essential security feature for IoT 79 devices to deal with vulnerabilities. While the transport of 80 firmware images to the devices themselves is important there are 81 already various techniques available. Equally important is the 82 inclusion of meta-data about the conveyed firmware image (in the form 83 of a manifest) and the use of end-to-end security protection to 84 detect modifications and (optionally) to make reverse engineering 85 more difficult. End-to-end security allows the author, who builds 86 the firmware image, to be sure that no other party (including 87 potential adversaries) is able to install firmware updates on IoT 88 devices without adequate privileges. This authorization process is 89 ensured by the use of dedicated credentials and authorization 90 permissions installed on the IoT device. 92 This document is part of larger document set: the architecture 93 document can be found in [I-D.ietf-suit-architecture] and the 94 information model of the manifest is described in 95 [I-D.ietf-suit-information-model]. This document focuses on the 96 serialization format. 98 2. Conventions and Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in RFC 103 2119 [RFC2119]. 105 2.1. Manifest Serialization Format 107 The following CDDL fragment defines the manifest. 109 Wherever enumerations are used, they are started at 1. This allows 110 detection of several common software errors that are caused by 111 uninitialised variables. 113 The processing graph is a mechanism that maps from resources to 114 installed firmware. On one side of the graph are the resources. 115 These are the raw content that a device acquires. Resources can be 116 remote (for example, on a server) or local (for example, an already 117 installed firmware). On the other side of the graph are targets. 118 These are the locations that firmware is installed to. In between 119 these two sides are processors. These are the steps that a device 120 takes to translate raw content into firmware that is installed. In 121 the simplest case, this is a direct mapping; the resource is 122 installed into the target directly. In an example complex case, a 123 device must use decryption, decompression, and differential patching 124 to create the final resource. Differential patching requires that 125 the device refer to an already-installed firmware. In this graph, 126 there are two resources, three processors, and one target. In some 127 cases, one resource may be used by multiple processors, such as a 128 compression table. The nodes of the graph are the resources before 129 or after transformation by a processor and the edges of the graph are 130 the processors themselves. 132 Resources, processors and targets are marked with node identifiers. 133 Resources have an output node. Targets have an input node. 134 Processors have both. 136 AuthenticatedManifest = [ 137 authenticatedManifest: COSE_Mac / COSE_Sign, 138 text: bstr .cbor textMap 139 ] 140 COSE_Mac = any 141 COSE_Sign = any 143 textKeys = ( 144 uninitialised: 0 / 145 manifestDescription: 1 / 146 payloadDescription: 2 / 147 vendorName: 3 / 148 modelName: 4 / 149 payloadVersion: 5 150 ) 152 textMap = { * textKeys / nint => tstr } 154 Manifest = [ 155 manifestVersion : 1, 156 digestInfo : DigestInfo, 158 ; textReference is the digest of the associated 159 ; text map in AuthenticatedManifest 160 textReference : bstr, 161 nonce : bstr, 162 sequence : SequenceNumber, 163 preConditions : [ * PreCondition ], 164 postConditions : [ * PostCondition ], 165 directives : [ * Directive ], 166 resources : [ * ResourceInfo ], 167 processors : [ * ProcessingStep ], 168 targets : [ * TargetInfo ], 169 extensions : { * int => bstr} 170 ] 172 ResourceInfo = [ 173 type: payload:1 / dependency:2 / key:3 / alias:4 174 indicator: UriList, ; where to find the resource 175 size: uint / nil, ; size of the resource 176 ; (nil when alias) 177 digest: bstr, ; digest of the resource 178 onode bstr ; Node of the processing 179 ; graph that the resource feeds 180 ] 182 Processor = [ 183 decrypt: 1 / decompress: 2 / undiff: 3 / 184 relocate: 4 / unrelocate: 5, 185 parameters: bstr ; TBD: more detail needed 186 inode: bstr, ; Node of the processing graph 187 ; that this processor consumes 188 onode: bstr ; Node of the processing graph 189 ; that this processor feeds 190 ] 191 Target = [ 192 componentIdentifier: [ * bstr], 193 storageIdentifier: tstr, ; where to store the resource 194 encoding: bstr / nil, ; the format of the resource 195 ; (nil when alias) 196 inode: bstr ; Node of the processing graph 197 ; that this target consumes 198 ] 200 PreCondition = IdCondition / TimeCondition / 201 ImageCondition / CustomCondition 202 PostCondition = ImageCondition / CustomCondition 203 IdCondition = [vendor: 1 / class: 2 / device: 3, 204 id: Uuid] 205 TimeCondition = [installAfter: 4 / bestBefore: 5, 206 time: Timestamp] 207 ImageCondition = [currentContent: 6 / notCurrentContent: 7, 208 digest: bstr / nil, location: StorageIdentifier] 209 CustomCondition = [nint, parameters: bstr] 210 Directive = [ int => bstr ] 212 SequenceNumber = uint 213 Timestamp = uint .size 8 214 Uuid = bstr .size 16 215 StorageIdentifier = bstr 216 ComponentIdentifier = bstr 217 UriList = { + int => tstr } 218 DigestInfo = [ 219 digestAlgorithm : uint, 220 ? digestParameters : bstr 221 ] 223 3. IANA Considerations 225 TBD: Several registries will be required for: * Standard Conditions * 226 Standard Directives * Standard Processors * Standard text values 228 4. Security Considerations 230 This document is about a manifest format describing and protecting 231 firmware images and as such it is part of a larger solution for 232 offering a standardized way of delivering firmware updates to IoT 233 devices. A more detailed discussion about security can be found in 234 the architecture document [I-D.ietf-suit-architecture] and in the 235 information model document [I-D.ietf-suit-information-model]. 237 5. Mailing List Information 239 The discussion list for this document is located at the e-mail 240 address suit@ietf.org [1]. Information on the group and information 241 on how to subscribe to the list is at 242 https://www1.ietf.org/mailman/listinfo/suit 244 Archives of the list can be found at: https://www.ietf.org/mail- 245 archive/web/suit/current/index.html 247 6. Acknowledgements 249 We would like the following persons for their support in designing 250 this mechanism 252 - Geraint Luff 254 - Amyas Phillips 256 - Dan Ros 258 - Carsten Bormann 260 - David Brown 262 - Markus Gueller 264 - Frank Audun Kvamtro 266 - Oyvind Ronningstad 268 7. References 270 7.1. Normative References 272 [I-D.ietf-suit-architecture] 273 Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A 274 Firmware Update Architecture for Internet of Things 275 Devices", draft-ietf-suit-architecture-01 (work in 276 progress), July 2018. 278 [I-D.ietf-suit-information-model] 279 Moran, B., Tschofenig, H., Birkholz, H., and J. Jimenez, 280 "Firmware Updates for Internet of Things Devices - An 281 Information Model for Manifests", draft-ietf-suit- 282 information-model-00 (work in progress), June 2018. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, . 289 7.2. URIs 291 [1] mailto:suit@ietf.org 293 Authors' Addresses 295 Brendan Moran 296 Arm Limited 298 EMail: Brendan.Moran@arm.com 300 Hannes Tschofenig 301 Arm Limited 303 EMail: hannes.tschofenig@gmx.net