idnits 2.17.1 draft-nandakumar-suit-secfu-solution-arch-00.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2017) is 2370 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Nandakumar 3 Internet-Draft C. Jennings 4 Intended status: Standards Track S. Cooley 5 Expires: May 3, 2018 Cisco 6 October 30, 2017 8 Solution Architecture - Secure Firmware Upgrade (SecFU) 9 draft-nandakumar-suit-secfu-solution-arch-00 11 Abstract 13 This specification defines a solution architecture for performing 14 secure firmware upgrade for Internet of Things (IoT). The ulterior 15 motive is to have a framework that is simple, secure, and that uses 16 most common formats and standards in the industry and that works over 17 Internet. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 3, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Device Considerations . . . . . . . . . . . . . . . . . . . . 3 56 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Solution Components . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.2. Manifest Format . . . . . . . . . . . . . . . . . . . . . 6 60 5.3. Manifest Security . . . . . . . . . . . . . . . . . . . . 6 61 5.4. Manifest Optional Extensions . . . . . . . . . . . . . . 6 62 5.5. Firmware Server Discovery . . . . . . . . . . . . . . . . 6 63 5.6. Firmware Download protocol . . . . . . . . . . . . . . . 7 64 5.6.1. Validation Procedures . . . . . . . . . . . . . . . . 7 65 5.6.2. Manifest Download . . . . . . . . . . . . . . . . . . 8 66 5.6.3. Firmware Download . . . . . . . . . . . . . . . . . . 8 67 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Internet of Things (IOT) represents a plethora of devices that come 76 in varying flavors of constrained sizes, computing power, and 77 operating considerations. These devices usually need minimal or no 78 management for their operation. 80 Vulnerabilities within IOT devices have raised serious concerns. 81 There needs to be a way to install or update the firmware on these 82 devices in an automated and secure fashion. A common challenge with 83 the existing firmware update mechanism is they do not work in an 84 automated manner in many environments where IoT devices are deployed. 85 Hence, there is a need to define a firmware update solution that is 86 light weight, secure, can operate in variety of deployment 87 environments, and is built on well established standards. 89 2. Terminology 91 In this document, the key words "MUST", "MUST NOT", "SHOULD", "SHOULD 92 NOT", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 93 2119 [RFC2119] and indicate requirement levels for compliant 94 implementations. 96 3. Device Considerations 98 This draft targets devices that have a boot loader that run in less 99 than 100K bytes of flash and less than 32K bytes of RAM. 101 There are certain types of devices that delete the firmware image, 102 except for the boot-loader, before proceeding with the upgrade. 103 Alternatively, many devices have sufficient storage to completely 104 download a new firmware image before updating. This solution should 105 be naturally applicable to both. 107 4. Solution Overview 109 draft-nandakumar-suit-secfu-requirements captures various 110 requirements that drives the solution defined in this specification. 112 Below is a high-level solution flow for a successful firmware update 113 on a IoT device. 115 Successful Firmware Update Flow 117 on-ready to update 118 firmware 119 | 120 | 121 Can access firmware sever 122 in the local domain ? 123 | 124 | 125 ------------------ 126 Yes | | No 127 | | 128 Download signed Download signed 129 manifest from manifest from 130 local server manufacturer's 131 well-known URL pre-configured URL 132 | | 133 | | 134 Validate manifest via 135 pre-installed public key 136 | 137 | 138 Download the firmware image 139 from the location in manifest 140 | 141 | 142 verify commit hashes 143 on the firmware image 144 | 145 | 146 complete installation 148 5. Solution Components 150 Following several sub-sections define various components that makes 151 up the proposed solution architecture 153 5.1. Manifest 155 A firmware manifest serves as information representation for metadata 156 about the firmware. A manifest file identifies information about the 157 actual firmware image, its location, applicable device(s), and so on. 158 It is cryptographically signed by the provider (usually the 159 manufacturer) of the firmware. 161 Minimal Manifest in JSON format 163 { 164 "manifestVersion" : "1.0", 165 "timestamp": "2017-12-10T15:12:15Z", 166 "manufacturer": "manufacturer.com", 167 "model": "c7960", 168 "firmwareVersion": "10.4.12", 169 "firmwareLocation": "well-known location", 170 "firmwareCryptoInfo": { 171 { 172 "commitHash": [ 173 { 174 "digestAlgo": "sha256", 175 "hash": "..................." 176 }, 177 { 178 "digestAlgo": "sha512", 179 "hash": "..................." 180 } 181 ] 182 } 183 } 184 "key-info": 185 } 187 Above shows example of a minimally defined manifest that identifies 188 the mandatory attributes as explained below 190 o manifestVersion: Version of the manifest 192 o timestamp: Time when the manifest was created. 194 o manufacturer: An identifier of the manufacturer providing the 195 firmware image, represented as String 197 o model: Device Model, a String 199 o firmwareVersion: Firmware Version in the format 200 "major.minor.revision" 202 o firmwareLocation: Location of the firmware images. This can be an 203 absolute URI or a relative URI that is relative to where the 204 manifest was downloaded from. 206 o firmwareCryptoInfo: Commit Hash information 208 5.2. Manifest Format 210 JSON representation is recommended as the default format for 211 describing the manifest. Optionally, formats such as CBOR (see 212 example section) can be used for the same. If more than one format 213 is used, the IoT device can pick one based on its implementation. 214 The firmware download protocol identifies the right format supported 215 by the IoT device. 217 5.3. Manifest Security 219 The Manifest file MUST be cryptographically signed by the private key 220 of the manufacturer or the provider of the firmware. This is to 221 ensure source authenticity and to protect integrity of the manifest 222 and the firmware itself. 224 JWS is the format recommended to store the signed manifest. 226 signed_manifest := JWS(manifest.json) 228 If CBOR is used for describing the manifest, COSE is recommended for 229 signing. 231 Optionally, the proposed solution also recommends hash based 232 signatures (hash-sigs) to sign the manifest. 234 signed_manifest := hash-sigs(manifest.json, private-key) 236 5.4. Manifest Optional Extensions 238 There may be scenarios where the minimalistic manifest defined above 239 may not capture all the requirements for a given deployment setting. 240 In those circumstances, the manifest can be optionally extended to 241 meet the requirements in a extensional specifications. 243 5.5. Firmware Server Discovery 245 When it is time for an IoT device to perform a firmware upgrade, the 246 device performs couple of steps to decide the location to download 247 the needed firmware. A device might need to download the new 248 firmware when it is either booting for the first time after 249 deployment or there is a need to upgrade to a newer firmware. 251 The server discovery procedure starts with the boot-loader attempting 252 to access a server that is local to the domain in which the device 253 operates. The URL to look for a local server is automatically 254 generated using the DHCP domain name. 256 For example, if the domain name was example.com, and the device was a 257 Cisco 7960, the HTTP URL might be 259 http://_firmware.example.com/.wellknown/firmware/cisco.com/c7960/manifest.json 261 In situations where the IoT device cannot access the Internet 262 (factory/enterprise settings, for example), the aforementioned 263 approach might be the only way for the device to perform any kind of 264 firmware or security updates. 266 However, if the local server cannot be reached or not deployed (say 267 home environments), the device proceeds to download the manifest and 268 firmware from the firmware server URL pre-configured in the boot- 269 loader by the manufacturer of the device. For example 271 http://_firmware.cisco.com/.wellknown/firmware/cisco.com/c7960/manifest.json 273 If either of the procedures doesn't work, the IoT device is either 274 unusable or might end up running an old version of the firmware. 276 5.6. Firmware Download protocol 278 One can envision two possibilities while downloading the firmware: 280 o Scenarios where the IoT device downloads firmware directly. This 281 is done in order to minimize number of connections. In this 282 scenario, the firmware image must have a digital signature 283 included within the downloaded firmware. The exact placement of 284 this digital signature (prepended, appended, etc) is up to the 285 device manufacturer, but it MUST provided source and integrity 286 guarantees on the entirety of the firmware image and must be 287 verified by the device prior to upgrade. 289 o Scenarios where a manifest is retrieved and followed by 290 downloading the actual firmware image. 292 5.6.1. Validation Procedures 294 The downloaded manifest and firmware is validated before being used: 296 o Manifest file signature is validated for source and integrity 297 verification. If encrypted, the manifest is decrypted before 298 proceeding with the firmware download. 300 o On successful validation of the manifest, the device verifies the 301 commit hashes for component(s) of the firmware downloaded against 302 the ones provided in the "firmwareCryptoInfo" section of the 303 manifest. 305 5.6.2. Manifest Download 307 Firmware download protocol enables choosing the approach appropriate 308 to the IoT device for downloading the manifest file. 310 For example, on performing the "Firmware Server Discovery", if a 311 local server is chosen, the device forms a query URL by constructing 312 an endpoint at ".well-known/manifest///manifest.json" 315 Then a HTTP GET request is sent to that URL. For example 317 http://_firmware.example.com/.wellknown/manifest/cisco.com/c7960/manifest.json 319 The response would be a JSON result of the manifest file. Similarly, 320 the end-point supporting CBOR parsing can request for the CBOR 321 version of the mannifest. 323 5.6.3. Firmware Download 325 Once the manifest is downloaded and validated, the device proceeds to 326 download the firmware image from the location identified in the 327 firmware manifest. There might be situations where a firmware image 328 is split into multiple files to imply a functional division of the 329 components. This type of firmware can be used by devices that are 330 memory constrained and thus loading the complete image might not be 331 possible. The manifest file may contain the information to indicate 332 the same. 334 Above example shows use of HTTP as the communication protocol to talk 335 to the firmware server. If the end-point is capable of doing COAP or 336 other protocols, a similar process as above can be applied to 337 retrieve the manifest and the firmware from a well-known place on the 338 local server. 340 6. IANA Consideration 342 TODO 344 7. Security Considerations 346 TODO - Talk about roaming IoT Device 348 8. Acknowledgements 349 9. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, . 356 Authors' Addresses 358 Suhas Nandakumar 359 Cisco 361 Email: snandaku@cisco.com 363 Cullen Jennings 364 Cisco 366 Email: fluffy@iii.ca 368 Shaun Cooley 369 Cisco 371 Email: scooley@cisco.com