< draft-ietf-suit-information-model-05.txt   draft-ietf-suit-information-model-06.txt >
SUIT B. Moran SUIT B. Moran
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Standards Track Arm Limited Intended status: Informational Arm Limited
Expires: July 23, 2020 H. Birkholz Expires: December 3, 2020 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
January 20, 2020 June 01, 2020
An Information Model for Firmware Updates in IoT Devices An Information Model for Firmware Updates in IoT Devices
draft-ietf-suit-information-model-05 draft-ietf-suit-information-model-06
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. Ensuring that devices function and suitable for constrained devices. Ensuring that devices function and
remain secure over their service life requires such an update remain secure over their service life requires such an update
mechanism to fix vulnerabilities, to update configuration settings, mechanism to fix vulnerabilities, to update configuration settings,
as well as adding new functionality as well as adding new functionality
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 23, 2020. This Internet-Draft will expire on December 3, 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
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6
3.1. Manifest Element: Version ID of the manifest structure . 6 3.1. Manifest Element: Version ID of the manifest structure . 6
3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6 3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6
3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 7 3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 6
3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7 3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7
3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7 3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7
3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8
3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 8
3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9
3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 9 3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 9
3.5. Manifest Element: Precursor Image Digest Condition . . . 10 3.5. Manifest Element: Precursor Image Digest Condition . . . 10
3.6. Manifest Element: Required Image Version List . . . . . . 10 3.6. Manifest Element: Required Image Version List . . . . . . 10
3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10 3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10
3.8. Manifest Element: Payload Format . . . . . . . . . . . . 11 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 10
3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11 3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11
3.10. Manifest Element: Storage Location . . . . . . . . . . . 11 3.10. Manifest Element: Storage Location . . . . . . . . . . . 11
3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 12 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 11
3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12
3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12
3.11. Manifest Element: Component Identifier . . . . . . . . . 12 3.11. Manifest Element: Component Identifier . . . . . . . . . 12
3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12 3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12
3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 13 3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 13
3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13
3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13 3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13
3.16. Manifest Element: Additional installation instructions . 14 3.16. Manifest Element: Additional installation instructions . 14
3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14 3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14
3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 14 3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 14
3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 15 3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14
3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 15 3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 15
3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15 3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15
3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 15 3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 15
3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 16 3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15
3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 16 3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16
4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 17 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16
4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old
Firmware . . . . . . . . . . . . . . . . . . . . . . 17 Firmware . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17
4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets
the type of payload . . . . . . . . . . . . . . . . . 18 the type of payload . . . . . . . . . . . . . . . . . 18
4.2.5. THREAT.IMG.LOCATION: The target device installs the 4.2.5. THREAT.IMG.LOCATION: The target device installs the
payload to the wrong location . . . . . . . . . . . . 18 payload to the wrong location . . . . . . . . . . . . 18
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic
payload hosting . . . . . . . . . . . . . . . . . . . 19 payload hosting . . . . . . . . . . . . . . . . . . . 18
4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 19 4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 18
4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19
4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 20 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 19
4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
images . . . . . . . . . . . . . . . . . . . . . . . 20 images . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20
4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of
Firmware Image for Vulnerability Analysis . . . . . . 22 Firmware Image for Vulnerability Analysis . . . . . . 22
4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 22 Elements . . . . . . . . . . . . . . . . . . . . . . 22
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
Exposure . . . . . . . . . . . . . . . . . . . . . . 23 Exposure . . . . . . . . . . . . . . . . . . . . . . 22
4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 23 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 22
4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 23 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 23
4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or
payload prior to signing . . . . . . . . . . . . . . 23 payload prior to signing . . . . . . . . . . . . . . 23
4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between
authentication and use . . . . . . . . . . . . . . . 24 authentication and use . . . . . . . . . . . . . . . 23
4.3. Security Requirements . . . . . . . . . . . . . . . . . . 24 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 24
4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 24 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 24
4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 25 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 24
4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 25 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 25
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 25 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 25
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25
4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC:
Authenticated Storage Location . . . . . . . . . . . 26 Authenticated Storage Location . . . . . . . . . . . 25
4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote
Resource Location . . . . . . . . . . . . . . . . . . 26 Resource Location . . . . . . . . . . . . . . . . . . 26
4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 26 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 26
4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor
images . . . . . . . . . . . . . . . . . . . . . . . 26 images . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and
Class IDs . . . . . . . . . . . . . . . . . . . . . . 27 Class IDs . . . . . . . . . . . . . . . . . . . . . . 26
4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 27 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 26
4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 27 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 27
4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 28 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 27
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 28 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 28
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 28 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 28
4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 29 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 28
4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing
keys . . . . . . . . . . . . . . . . . . . . . . . . 29 keys . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to
deployment . . . . . . . . . . . . . . . . . . . . . 29 deployment . . . . . . . . . . . . . . . . . . . . . 29
4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a
trusted environment . . . . . . . . . . . . . . . . . 29 trusted environment . . . . . . . . . . . . . . . . . 29
4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between
check and use . . . . . . . . . . . . . . . . . . . . 29 check and use . . . . . . . . . . . . . . . . . . . . 29
4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 30 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 29
4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
Instructions . . . . . . . . . . . . . . . . . . . . 30 Instructions . . . . . . . . . . . . . . . . . . . . 29
4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 30 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 30
4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 31 Elements . . . . . . . . . . . . . . . . . . . . . . 30
4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 31 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 31
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 31 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 31
4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 32 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 31
4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
Information Disclosures . . . . . . . . . . . . . . . 32 Information Disclosures . . . . . . . . . . . . . . . 31
4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from
Unpacking Unknown Formats . . . . . . . . . . . . . . 32 Unpacking Unknown Formats . . . . . . . . . . . . . . 31
4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version
Numbers of Target Firmware . . . . . . . . . . . . . 32 Numbers of Target Firmware . . . . . . . . . . . . . 32
4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose
Between Images . . . . . . . . . . . . . . . . . . . 33 Between Images . . . . . . . . . . . . . . . . . . . 32
4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
Manifests . . . . . . . . . . . . . . . . . . . . . . 33 Manifests . . . . . . . . . . . . . . . . . . . . . . 32
4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 33 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 32
4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 33 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 33
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 33 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 33
4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 34 Manifest . . . . . . . . . . . . . . . . . . . . . . 33
4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 33
4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 34 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 33
4.5. Usability Requirements . . . . . . . . . . . . . . . . . 34 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 33
4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 34
4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
Resource Location . . . . . . . . . . . . . . . . . . 34 Resource Location . . . . . . . . . . . . . . . . . . 34
4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 35 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 34
4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 36 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 35
4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 36 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 35
4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 36 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 36
4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 37 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 36
4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 37 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 36
4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 37 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 36
4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 37 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 37
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 38 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 37
4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 39 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 38
4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 39 Manifest . . . . . . . . . . . . . . . . . . . . . . 38
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1. Normative References . . . . . . . . . . . . . . . . . . 40 7.1. Normative References . . . . . . . . . . . . . . . . . . 39
7.2. Informative References . . . . . . . . . . . . . . . . . 40 7.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Mailing List Information . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The information model describes all the information elements required The information model describes all the information elements required
to secure firmware updates of IoT devices from the threats described to secure firmware updates of IoT devices from the threats described
in Section 4.1 and enables the user stories captured in Section 4.4. in Section 4.1 and enables the user stories captured in Section 4.4.
These threats and user stories are not intended to be an exhaustive These threats and user stories are not intended to be an exhaustive
list of the threats against IoT devices, nor of the possible user list of the threats against IoT devices, nor of the possible user
stories that describe how to conduct a firmware update. Instead they stories that describe how to conduct a firmware update. Instead they
are intended to describe the threats against firmware updates in are intended to describe the threats against firmware updates in
skipping to change at page 14, line 14 skipping to change at page 13, line 50
This element is REQUIRED in non-dependency manifests and represents This element is REQUIRED in non-dependency manifests and represents
the foundation of all security properties of the manifest. Manifests the foundation of all security properties of the manifest. Manifests
which are included as dependencies by another manifest SHOULD include which are included as dependencies by another manifest SHOULD include
a signature so that the recipient can distinguish between different a signature so that the recipient can distinguish between different
actors with different permissions. actors with different permissions.
A manifest MUST NOT be considered authenticated by channel security A manifest MUST NOT be considered authenticated by channel security
even if it contains only channel information (such as URIs). If the even if it contains only channel information (such as URIs). If the
authenticated remote or channel were compromised, the threat actor authenticated remote or channel were compromised, the threat actor
could induce recipients to queries traffic over any accessible could induce recipients to query traffic over any accessible network.
network. Lightweight authentication with pre-existing relationships Lightweight authentication with pre-existing relationships SHOULD be
SHOULD be done with MAC. done with MAC.
Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS
(Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4)
3.16. Manifest Element: Additional installation instructions 3.16. Manifest Element: Additional installation instructions
Instructions that the device should execute when processing the Instructions that the device should execute when processing the
manifest. This information is distinct from the information manifest. This information is distinct from the information
necessary to process a payload. Additional installation instructions necessary to process a payload. Additional installation instructions
include information such as update timing (for example, install only include information such as update timing (for example, install only
skipping to change at page 36, line 26 skipping to change at page 35, line 47
4.5.5. REQ.USE.IMG.FORMAT: Format Usability 4.5.5. REQ.USE.IMG.FORMAT: Format Usability
The manifest serialisation MUST accommodate any payload format that The manifest serialisation MUST accommodate any payload format that
an Operator wishes to use. This enables the recipient to detect an Operator wishes to use. This enables the recipient to detect
which format the Operator has chosen. Some examples of payload which format the Operator has chosen. Some examples of payload
format are: format are:
o Binary o Binary
o Elf o Executable and Linkable Format (ELF)
o Differential o Differential
o Compressed o Compressed
o Packed configuration o Packed configuration
o Intel HEX o Intel HEX
o S-Record o Motorola S-Record
Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6)
USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8)
Implemented by: Payload Format (Section 3.8) Implemented by: Payload Format (Section 3.8)
4.5.6. REQ.USE.IMG.NESTED: Nested Formats 4.5.6. REQ.USE.IMG.NESTED: Nested Formats
The manifest serialisation MUST accommodate nested formats, The manifest serialisation MUST accommodate nested formats,
announcing to the target device all the nesting steps and any announcing to the target device all the nesting steps and any
skipping to change at page 38, line 12 skipping to change at page 37, line 30
Implemented by: Load-time metadata (Section 3.21) Implemented by: Load-time metadata (Section 3.21)
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure
It MUST be possible to place a payload in the same structure as the It MUST be possible to place a payload in the same structure as the
manifest. This MAY place the payload in the same packet as the manifest. This MAY place the payload in the same packet as the
manifest. manifest.
Integrated payloads may include, for example, wrapped encryption Integrated payloads may include, for example, wrapped encryption
keys, encoded configuration, public keys, [RFC8392] CBOR Web Tokens, keys, configuration data, public keys, CBOR Web Tokens [RFC8392], or
or X.509 certificates. X.509 certificates.
When an integrated payload is provided, this increases the size of When an integrated payload is provided, this increases the size of
the manifest. Manifest size can cause several processing and storage the manifest. Manifest size can cause several processing and storage
concerns that require careful consideration. The payload can prevent concerns that require careful consideration. The payload can prevent
the whole manifest from being contained in a single network packet, the whole manifest from being contained in a single network packet,
which can cause fragmentation and the loss of portions of the which can cause fragmentation and the loss of portions of the
manifest in lossy networks. This causes the need for reassembly and manifest in lossy networks. This causes the need for reassembly and
retransmission logic. The manifest must be held immutable between retransmission logic. The manifest must be held immutable between
verification and processing (see REQ.SEC.MFST.CONST verification and processing (see REQ.SEC.MFST.CONST
(Section 4.3.20)), so a larger manifest will consume more memory with (Section 4.3.20)), so a larger manifest will consume more memory with
skipping to change at page 40, line 12 skipping to change at page 39, line 22
Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary
Thomson. Thomson.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-suit-architecture] [I-D.ietf-suit-architecture]
Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things", Firmware Update Architecture for Internet of Things",
draft-ietf-suit-architecture-08 (work in progress), draft-ietf-suit-architecture-11 (work in progress), May
November 2019. 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
skipping to change at page 40, line 47 skipping to change at page 40, line 9
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018,
<https://msdn.microsoft.com/en-us/library/ <https://msdn.microsoft.com/en-us/library/
ee823878(v=cs.20).aspx>. ee823878(v=cs.20).aspx>.
7.3. URIs
[1] mailto:suit@ietf.org
[2] https://www1.ietf.org/mailman/listinfo/suit
[3] https://www.ietf.org/mail-archive/web/suit/current/index.html
Appendix A. Mailing List Information
The discussion list for this document is located at the e-mail
address suit@ietf.org [1]. Information on the group and information
on how to subscribe to the list is at
https://www1.ietf.org/mailman/listinfo/suit [2]
Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/suit/current/index.html [3]
Authors' Addresses Authors' Addresses
Brendan Moran Brendan Moran
Arm Limited Arm Limited
EMail: Brendan.Moran@arm.com EMail: Brendan.Moran@arm.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Arm Limited
 End of changes. 44 change blocks. 
99 lines changed or deleted 67 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/