< draft-ietf-suit-information-model-07.txt   draft-ietf-suit-information-model-08.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: December 4, 2020 H. Birkholz Expires: May 1, 2021 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
June 02, 2020 October 28, 2020
An Information Model for Firmware Updates in IoT Devices An Information Model for Firmware Updates in IoT Devices
draft-ietf-suit-information-model-07 draft-ietf-suit-information-model-08
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 reliable 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.
One component of such a firmware update is a concise and machine- One component of such a firmware update is a concise and machine-
processable meta-data document, or manifest, that describes the processable meta-data document, or manifest, that describes the
firmware image(s) and offers appropriate protection. This document firmware image(s) and offers appropriate protection. This document
describes the information that must be present in the manifest. describes the information that must be present in the manifest.
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 December 4, 2020. This Internet-Draft will expire on May 1, 2021.
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 2, line 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . 6 3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . 8 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9
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 . . . . . . . . . . . . 10 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 11
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 . . . . . . . . . . 11 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 12
3.10.2. Example 2: File System . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . 12 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 Envelope Element: Signature . . . . . . . . . . 13
3.16. Manifest Element: Additional installation instructions . 13 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 . . . . . . . . . . . . . 15
3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14 3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 15
3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . 16
3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15 3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 16
3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15 3.24. Manifest Envelope Element: Delegation Chain . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17
4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 17
4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old
Firmware . . . . . . . . . . . . . . . . . . . . . . 16 Firmware . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 18
4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets
the type of payload . . . . . . . . . . . . . . . . . 17 the type of payload . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . 19
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic
payload hosting . . . . . . . . . . . . . . . . . . . 18 payload hosting . . . . . . . . . . . . . . . . . . . 20
4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 18 4.2.7. THREAT.NET.ONPATH: Traffic interception . . . . . . . 20
4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 20
4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 19 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 21
4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
images . . . . . . . . . . . . . . . . . . . . . . . 19 images . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 21
4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of
Firmware Image for Vulnerability Analysis . . . . . . 21 Firmware Image for Vulnerability Analysis . . . . . . 23
4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 22 Elements . . . . . . . . . . . . . . . . . . . . . . 23
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
Exposure . . . . . . . . . . . . . . . . . . . . . . 22 Exposure . . . . . . . . . . . . . . . . . . . . . . 24
4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 22 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 24
4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 22 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 24
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 . . . . . . . . . . . . . . 24
4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between
authentication and use . . . . . . . . . . . . . . . 23 authentication and use . . . . . . . . . . . . . . . 25
4.3. Security Requirements . . . . . . . . . . . . . . . . . . 24 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 25
4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 24 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 25
4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 24 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 26
4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 24 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 26
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 25 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 26
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 27
4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC:
Authenticated Storage Location . . . . . . . . . . . 25 Authenticated Storage Location . . . . . . . . . . . 27
4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote
Resource Location . . . . . . . . . . . . . . . . . . 25 Resource Location . . . . . . . . . . . . . . . . . . 27
4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 26 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 27
4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor
images . . . . . . . . . . . . . . . . . . . . . . . 26 images . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and
Class IDs . . . . . . . . . . . . . . . . . . . . . . 26 Class IDs . . . . . . . . . . . . . . . . . . . . . . 28
4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 26 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 28
4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 27 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 28
4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 27 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 29
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 27 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 29
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 28 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 29
4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 28 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 30
4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing
keys . . . . . . . . . . . . . . . . . . . . . . . . 28 keys . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to
deployment . . . . . . . . . . . . . . . . . . . . . 28 deployment . . . . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . . 30
4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 29 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 31
4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
Instructions . . . . . . . . . . . . . . . . . . . . 29 Instructions . . . . . . . . . . . . . . . . . . . . 31
4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 30 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 31
4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 30 Elements . . . . . . . . . . . . . . . . . . . . . . 32
4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 31 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 32
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 31 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 32
4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 31 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 33
4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
Information Disclosures . . . . . . . . . . . . . . . 31 Information Disclosures . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . . 31 Unpacking Unknown Formats . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . 33
4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose
Between Images . . . . . . . . . . . . . . . . . . . 32 Between Images . . . . . . . . . . . . . . . . . . . 34
4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
Manifests . . . . . . . . . . . . . . . . . . . . . . 32 Manifests . . . . . . . . . . . . . . . . . . . . . . 34
4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 32 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 34
4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 32 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 34
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 33 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 34
4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 33 Manifest . . . . . . . . . . . . . . . . . . . . . . 35
4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 33 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 35
4.5. Usability Requirements . . . . . . . . . . . . . . . . . 33 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 35
4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 33 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 35
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 . . . . . . . . . . . . . . . . . . 35
4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 34 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 36
4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 35 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 37
4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 35 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 37
4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 36 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 37
4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 36 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 38
4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 36 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 38
4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 36 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 38
4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 37 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 38
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 37 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 39
4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 38 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 40
4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 38 Manifest . . . . . . . . . . . . . . . . . . . . . . 40
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . 39 7.1. Normative References . . . . . . . . . . . . . . . . . . 41
7.2. Informative References . . . . . . . . . . . . . . . . . 39 7.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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 6, line 5 skipping to change at page 6, line 5
properties that are useful in some applications. properties that are useful in some applications.
The definition of some of the information elements include examples The definition of some of the information elements include examples
that illustrate their semantics and how they are intended to be used. that illustrate their semantics and how they are intended to be used.
2. Conventions and Terminology 2. Conventions and Terminology
This document uses terms defined in [I-D.ietf-suit-architecture]. This document uses terms defined in [I-D.ietf-suit-architecture].
The term 'Operator' refers to both Device and Network Operator. The term 'Operator' refers to both Device and Network Operator.
This document treats devices with a homogeneous storage architecture Secure time and secure clock refer to a set of requirements on time
as devices with a heterogeneous storage architecture, but with a sources. For local time sources, this primarily means that the clock
single storage subsystem. must be monotonically increasing, including across power cycles,
firmware updates, etc. For remote time sources, the provided time
must be guaranteed to be correct to within some predetermined bounds,
whenever the time source is accessible.
The term Envelope is used to describe an encoding that allows the
bundling of a manifest with related information elements that are not
directly contained within the manifest.
The term Payload is used to describe the data that is delivered to a
device during an update. This is distinct from a "firmware image" as
described in [I-D.ietf-suit-architecture] because the payload is
often in an intermediate state, such as being encrypted, compressed
and/or encoded as a differential update. The payload, taken in
isolation, is often not the final firmware image.
2.1. Requirements Notation 2.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Manifest Information Elements 3. Manifest Information Elements
skipping to change at page 6, line 36 skipping to change at page 6, line 50
is contained in the structure. is contained in the structure.
This element is REQUIRED in order to allow devices to identify the This element is REQUIRED in order to allow devices to identify the
version of the manifest data model that is in use. version of the manifest data model that is in use.
3.2. Manifest Element: Monotonic Sequence Number 3.2. Manifest Element: Monotonic Sequence Number
A monotonically increasing sequence number. For convenience, the A monotonically increasing sequence number. For convenience, the
monotonic sequence number MAY be a UTC timestamp. This allows global monotonic sequence number MAY be a UTC timestamp. This allows global
synchronisation of sequence numbers without any additional synchronisation of sequence numbers without any additional
management. This number MUST be easily accessible so that code management. This number MUST be possible to extract with a simple,
choosing one out of several manifests can choose which is the latest. minimal parser so that code choosing one out of several manifests can
choose which is the latest without fully parsing a complex structure.
This element is REQUIRED and is necessary to prevent malicious actors This element is REQUIRED and is necessary to prevent malicious actors
from reverting a firmware update against the policies of the relevant from reverting a firmware update against the policies of the relevant
authority. authority.
Implements: REQ.SEC.SEQUENCE (Section 4.3.1) Implements: REQ.SEC.SEQUENCE (Section 4.3.1)
3.3. Manifest Element: Vendor ID 3.3. Manifest Element: Vendor ID
Vendor IDs must be unique. This is to prevent similarly, or Vendor IDs must be unique. This is to prevent similarly, or
skipping to change at page 8, line 4 skipping to change at page 8, line 20
o model name or number o model name or number
o hardware revision o hardware revision
o runtime library version o runtime library version
o bootloader version o bootloader version
o ROM revision o ROM revision
o silicon batch number o silicon batch number
The Class Identifier UUID SHOULD use the Vendor ID as the name space The Class Identifier UUID SHOULD use the Vendor ID as the name space
ID. Other options include version 1 and 4 UUIDs. Classes MAY be ID. Other options include version 1 and 4 UUIDs. Classes MAY be
more granular than is required to identify firmware compatibility. more granular than is required to identify firmware compatibility.
Classes MUST NOT be less granular than is required to identify Classes MUST NOT be less granular than is required to identify
firmware compatibility. Devices MAY have multiple Class IDs. firmware compatibility. Devices MAY have multiple Class IDs.
Class ID is not intended to be a human-readable element. It is Class ID is not intended to be a human-readable element. It is
intended for binary match/mismatch comparison only. intended for binary match/mismatch comparison only.
The use of Class ID is RECOMMENDED. It allows devices to determine The use of Class ID is RECOMMENDED. It allows devices to determine
applicability of a firmware in an unambiguous way. applicability of a firmware in an unambiguous way.
If Class ID is not implemented, then each logical device class MUST If Class ID is not implemented, then each logical device class MUST
use a unique trust anchor for authorisation. use a unique trust anchor for authorization.
Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2),
REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10).
3.4.1. Example 1: Different Classes 3.4.1. Example 1: Different Classes
Vendor A creates product Z and product Y. The firmware images of Vendor A creates product Z and product Y. The firmware images of
products Z and Y are not interchangeable. Vendor A creates UUIDs as products Z and Y are not interchangeable. Vendor A creates UUIDs as
follows: follows:
skipping to change at page 10, line 7 skipping to change at page 10, line 22
The product will match against each of these class IDs. If Vendor A The product will match against each of these class IDs. If Vendor A
and Vendor B provide different components for the device, the and Vendor B provide different components for the device, the
implementor MAY choose to make ID matching scoped to each component. implementor MAY choose to make ID matching scoped to each component.
Then, the vendorIdA, classIdA match the component ID supplied by Then, the vendorIdA, classIdA match the component ID supplied by
Vendor A, and the vendorIdB, classIdB match the component ID supplied Vendor A, and the vendorIdB, classIdB match the component ID supplied
by Vendor B. by Vendor B.
3.5. Manifest Element: Precursor Image Digest Condition 3.5. Manifest Element: Precursor Image Digest Condition
When a precursor image is required by the payload format, a precursor When a precursor image is required by the payload format (for
image digest condition MUST be present in the conditions list. The example, differential updates), a precursor image digest condition
precursor image may be installed or stored as a candidate. MUST be present. The precursor image MAY be installed or stored as a
candidate.
This element is OPTIONAL to implement. This element is OPTIONAL to implement.
Enables feature: differential updates.
Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)
3.6. Manifest Element: Required Image Version List 3.6. Manifest Element: Required Image Version List
When a payload applies to multiple versions of a firmware, the When a payload applies to multiple versions of a firmware, the
required image version list specifies which versions must be present required image version list specifies which versions must be present
for the update to be applied. This allows the update author to for the update to be applied. This allows the update author to
target specific versions of firmware for an update, while excluding target specific versions of firmware for an update, while excluding
those to which it should not be applied. those to which it should not be applied.
Where an update can only be applied over specific predecessor Where an update can only be applied over specific predecessor
versions, that version MUST be specified by the Required Image versions, that version MUST be specified by the Required Image
Version List. Version List.
This element is OPTIONAL. This element is OPTIONAL to implement.
Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7)
3.7. Manifest Element: Expiration Time 3.7. Manifest Element: Expiration Time
This element tells a device the time at which the manifest expires This element tells a device the time at which the manifest expires
and should no longer be used. This is only usable in conjunction and should no longer be used. This element SHOULD be used where a
with a secure source of time. secure source of time is provided and firmware is intended to expire
predictably. This element may also be displayed (e.g. via an app)
for user confirmation since users typically have a reliable knowledge
of the date.
This element is OPTIONAL and may enable user stories where a secure Special consideration is required for end-of-life: if a firmware will
source of time is provided and firmware is intended to expire not be updated again, for example if a business stops issuing updates
predictably. to a device. The last valid firmware should not have an expiration
time.
This element is OPTIONAL to implement.
Implements: REQ.SEC.EXP (Section 4.3.3) Implements: REQ.SEC.EXP (Section 4.3.3)
3.8. Manifest Element: Payload Format 3.8. Manifest Element: Payload Format
The format of the payload MUST be indicated to devices in an The format of the payload MUST be indicated to devices in an
unambiguous way. This element provides a mechanism to describe the unambiguous way. This element provides a mechanism to describe the
payload format, within the signed metadata. payload format, within the signed metadata.
This element is REQUIRED and MUST be present to enable devices to This element is REQUIRED and MUST be present to enable devices to
decode payloads correctly. decode payloads correctly.
Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT
(Section 4.5.5) (Section 4.5.5)
3.9. Manifest Element: Processing Steps 3.9. Manifest Element: Processing Steps
A representation of the Processing Steps required to decode a A representation of the Processing Steps required to decode a
payload. The representation MUST describe which algorithm(s) is used payload, in particular those that are compressed, packed, or
and any additional parameters required by the algorithm(s). The encrypted. The representation MUST describe which algorithm(s) is
used and any additional parameters required by the algorithm(s). The
representation MAY group Processing Steps together in predefined representation MAY group Processing Steps together in predefined
combinations. combinations.
A Processing Step MAY indicate the expected digest of the payload A Processing Step MAY indicate the expected digest of the payload
after the processing is complete. after the processing is complete.
Processing steps are RECOMMENDED to implement. Processing steps are RECOMMENDED to implement.
Enables feature: Encrypted, compressed, packed formats
Implements: REQ.USE.IMG.NESTED (Section 4.5.6) Implements: REQ.USE.IMG.NESTED (Section 4.5.6)
3.10. Manifest Element: Storage Location 3.10. Manifest Element: Storage Location
This element tells the device where to store a payload within a given This element tells the device where to store a payload within a given
component. The device can use this to establish which permissions component. The device can use this to establish which permissions
are necessary and the physical storage location to use. are necessary and the physical storage location to use.
This element is REQUIRED and MUST be present to enable devices to This element is REQUIRED and MUST be present to enable devices to
store payloads to the correct location. store payloads to the correct location.
skipping to change at page 12, line 12 skipping to change at page 12, line 32
payload may be a tarball, in which case, it unpacks the tarball into payload may be a tarball, in which case, it unpacks the tarball into
the specified path. the specified path.
3.10.3. Example 3: Flash Memory 3.10.3. Example 3: Flash Memory
A device supports flash memory. The Author chooses to make the A device supports flash memory. The Author chooses to make the
storage identifier the offset where the image should be written. storage identifier the offset where the image should be written.
3.11. Manifest Element: Component Identifier 3.11. Manifest Element: Component Identifier
In a heterogeneous storage architecture, a storage identifier is In a device with more than one storage subsystem, a storage
insufficient to identify where and how to store a payload. To identifier is insufficient to identify where and how to store a
resolve this, a component identifier indicates which part of the payload. To resolve this, a component identifier indicates which
storage architecture is targeted by the payload. In a homogeneous part of the storage architecture is targeted by the payload.
storage architecture, this element is unnecessary.
This element is OPTIONAL and only necessary in heterogeneous storage This element is OPTIONAL and only necessary in devices with multiple
architecture devices. storage subsystems.
N.B. A manifest format MAY choose to combine Component Identifier N.B. A serialization MAY choose to combine Component Identifier and
and Storage Location (Section 3.10) Storage Location (Section 3.10)
Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)
3.12. Manifest Element: Resource Indicator 3.12. Manifest Element: Resource Indicator
This element provides the information required for the device to This element provides the information required for the device to
acquire the resource. This can be encoded in several ways: acquire the resource. This can be encoded in several ways:
o One URI o One URI
skipping to change at page 13, line 25 skipping to change at page 13, line 43
Variable-size storage locations MUST be set to exactly the size Variable-size storage locations MUST be set to exactly the size
listed in this element. listed in this element.
This element is REQUIRED and informs the target device how big of a This element is REQUIRED and informs the target device how big of a
payload to expect. Without it, devices are exposed to some classes payload to expect. Without it, devices are exposed to some classes
of denial of service attack. of denial of service attack.
Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8)
3.15. Manifest Element: Signature 3.15. Manifest Envelope Element: Signature
This is not strictly a manifest element. Instead, the manifest is The Signature element MUST contain all the information necessary to
wrapped by a standardised authentication container. The cryptographically verify the contents of the manifest against a root
authentication container MUST support multiple signers and multiple of trust. Because the Signature element authenticates the manifest,
signature algorithms. it cannot be contained within the manifest. Instead, the manifest is
either contained within the signature element, or the signature
element is a member of the Manifest Envelope and bundled with the
manifest.
This element MAY be provided either by the manifest envelope
serialization or by another serialization of authentication objects,
such as a COSE ([RFC8152]) or CMS ([RFC5652]) signature object. The
Signature element MUST support multiple actors and multiple
authentication methods. It is NOT REQUIRED for a serialization to
authenticate multiple manifests with a single Signature element.
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 query traffic over any accessible network. could induce recipients to execute queries over any accessible
Lightweight authentication with pre-existing relationships SHOULD be network. Where public key operations require too many resources, the
done with MAC. recommended authentication mechanism is MAC with a per-device pre-
shared key.
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
on Sunday, at 0200), procedural considerations (for example, shut on Sunday, at 0200), procedural considerations (for example, shut
down the equipment under control before executing the update), pre- down the equipment under control before executing the update), pre-
and post-installation steps (for example, run a script). and post-installation steps (for example, run a script). Other
installation instructions could include requesting user confirmation
before installing.
This element is OPTIONAL. This element is OPTIONAL.
Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
3.17. Manifest Element: Aliases 3.17. Manifest Element: Aliases
A mechanism for a manifest to augment or replace URIs or URI lists A mechanism for a manifest to augment or replace URIs or URI lists
defined by one or more of its dependencies. defined by one or more of its dependencies.
skipping to change at page 15, line 7 skipping to change at page 15, line 38
In order to support XIP systems with multiple possible base In order to support XIP systems with multiple possible base
addresses, it is necessary to specify which address the payload is addresses, it is necessary to specify which address the payload is
linked for. linked for.
For example a microcontroller may have a simple bootloader that For example a microcontroller may have a simple bootloader that
chooses one of two images to boot. That microcontroller then needs chooses one of two images to boot. That microcontroller then needs
to choose one of two firmware images to install, based on which of to choose one of two firmware images to install, based on which of
its two images is older. its two images is older.
This element is OPTIONAL to implement.
Implements: REQ.USE.IMG.SELECT (Section 4.5.8) Implements: REQ.USE.IMG.SELECT (Section 4.5.8)
3.21. Manifest Element: Load-time metadata 3.21. Manifest Element: Load-time metadata
Load-time metadata provides the device with information that it needs Load-time metadata provides the device with information that it needs
in order to load one or more images. This is effectively a copy in order to load one or more images. This metadata MAY include any
operation from the permanent storage location of an image into the of:
active use location of that image. The metadata contains the source
and destination of the image as well as any operations that are o the source
performed on the image.
o the destination
o the destination address
o cryptographic information
o decompression information
o unpacking information
Typically, loading is done by copying an image from its permanent
storage location into its active use location. The metadata allows
operations such as decryption, decompression, and unpacking to be
performed during that copy.
This element is OPTIONAL to implement.
Implements: REQ.USE.LOAD (Section 4.5.10) Implements: REQ.USE.LOAD (Section 4.5.10)
3.22. Manifest Element: Run-time metadata 3.22. Manifest Element: Run-time metadata
Run-time metadata provides the device with any extra information Run-time metadata provides the device with any extra information
needed to boot the device. This may include information such as the needed to boot the device. This may include information such as the
entry-point of an XIP image or the kernel command-line of a Linux entry-point of an XIP image or the kernel command-line of a Linux
image. image.
This element is OPTIONAL to implement.
Implements: REQ.USE.EXEC (Section 4.5.9) Implements: REQ.USE.EXEC (Section 4.5.9)
3.23. Manifest Element: Payload 3.23. Manifest Element: Payload
The Payload element provides a recipient device with the whole The Payload element is contained within the manifest or manifest
payload, contained within the manifest superstructure. This enables envelope. This enables the manifest and payload to be delivered
the manifest and payload to be delivered simultaneously. simultaneously. Typically this is used for delivering small payloads
such as cryptographic keys, or configuration data.
This element is OPTIONAL to implement.
Implements: REQ.USE.PAYLOAD (Section 4.5.11) Implements: REQ.USE.PAYLOAD (Section 4.5.11)
3.24. Manifest Element: Key Claims 3.24. Manifest Envelope Element: Delegation Chain
The Key Claims element is not authenticated by the Signature The Signature (Section 3.15) is NOT REQUIRED to cover the delegation
(Section 3.15), instead, it provides a chain of key delegations (or chain. The delegation chain offers enhanced authorization
references to them) for the device to follow in order to verify the functionality via authorization tokens. Each token itself is
key that authenticated the manifest using a trusted key. protected and does not require another layer of protection and
because the delegation chain is needed to verify the signature, it
must be placed in the Manifest Envelope, rather than the Manifest.
This element is OPTIONAL to implement.
Implements: REQ.USE.DELEGATION (Section 4.5.13) Implements: REQ.USE.DELEGATION (Section 4.5.13)
4. Security Considerations 4. Security Considerations
The following sub-sections describe the threat model, user stories, The following sub-sections describe the threat model, user stories,
security requirements, and usability requirements. This section also security requirements, and usability requirements. This section also
provides the motivations for each of the manifest information provides the motivations for each of the manifest information
elements. elements.
skipping to change at page 16, line 46 skipping to change at page 18, line 7
An attacker sends an old, but valid manifest with an old, but valid An attacker sends an old, but valid manifest with an old, but valid
firmware image to a device. If there is a known vulnerability in the firmware image to a device. If there is a known vulnerability in the
provided firmware image, this may allow an attacker to exploit the provided firmware image, this may allow an attacker to exploit the
vulnerability and gain control of the device. vulnerability and gain control of the device.
Threat Escalation: If the attacker is able to exploit the known Threat Escalation: If the attacker is able to exploit the known
vulnerability, then this threat can be escalated to ALL TYPES. vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1)
4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old Firmware 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old Firmware
Classification: Elevation of Privilege Classification: Elevation of Privilege
An attacker targets a device that has been offline for a long time An attacker targets a device that has been offline for a long time
and runs an old firmware version. The attacker sends an old, but and runs an old firmware version. The attacker sends an old, but
valid manifest to a device with an old, but valid firmware image. valid manifest to a device with an old, but valid firmware image.
The attacker-provided firmware is newer than the installed one but The attacker-provided firmware is newer than the installed one but
older than the most recently available firmware. If there is a known older than the most recently available firmware. If there is a known
vulnerability in the provided firmware image then this may allow an vulnerability in the provided firmware image then this may allow an
attacker to gain control of a device. Because the device has been attacker to gain control of a device. Because the device has been
offline for a long time, it is unaware of any new updates. As such offline for a long time, it is unaware of any new updates. As such
it will treat the old manifest as the most current. it will treat the old manifest as the most current.
The exact mitigation for this threat depends on where the threat
comes from. This requires careful consideration by the implementor.
If the threat is from a network actor, including an on-path attacker,
or an intruder into a management system, then a user confirmation can
mitigate this attack, simply by displaying an expiration date and
requesting confirmation. On the other hand, if the user is the
attacker, then an online confirmation system (for example a trusted
timestamp server) can be used as a mitigation system.
Threat Escalation: If the attacker is able to exploit the known Threat Escalation: If the attacker is able to exploit the known
vulnerability, then this threat can be escalated to ALL TYPES. vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: REQ.SEC.EXP (Section 4.3.3) Mitigated by: REQ.SEC.EXP (Section 4.3.3), REQ.USE.MFST.PRE_CHECK
(Section 4.5.1),
4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware
Classification: Denial of Service Classification: Denial of Service
An attacker sends a valid firmware image, for the wrong type of An attacker sends a valid firmware image, for the wrong type of
device, signed by an actor with firmware installation permission on device, signed by an actor with firmware installation permission on
both types of device. The firmware is verified by the device both types of device. The firmware is verified by the device
positively because it is signed by an actor with the appropriate positively because it is signed by an actor with the appropriate
permission. This could have wide-ranging consequences. For devices permission. This could have wide-ranging consequences. For devices
skipping to change at page 18, line 27 skipping to change at page 19, line 48
If a device installs a firmware image to the wrong location on the If a device installs a firmware image to the wrong location on the
device, then it is likely to break. For example, a firmware image device, then it is likely to break. For example, a firmware image
installed as an application could cause a device and/or an installed as an application could cause a device and/or an
application to stop functioning. application to stop functioning.
Threat Escalation: An attacker that can cause a device to Threat Escalation: An attacker that can cause a device to
misinterpret the received code may gain elevation of privilege and misinterpret the received code may gain elevation of privilege and
potentially expand this to all types of threat. potentially expand this to all types of threat.
Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.5) Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting
Classification: Denial of Service Classification: Denial of Service
If a device does not know where to obtain the payload for an update, If a device does not know where to obtain the payload for an update,
it may be redirected to an attacker's server. This would allow an it may be redirected to an attacker's server. This would allow an
attacker to provide broken payloads to devices. attacker to provide broken payloads to devices.
Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
4.2.7. THREAT.NET.MITM: Traffic interception 4.2.7. THREAT.NET.ONPATH: Traffic interception
Classification: Spoofing Identity, Tampering with Data Classification: Spoofing Identity, Tampering with Data
An attacker intercepts all traffic to and from a device. The An attacker intercepts all traffic to and from a device. The
attacker can monitor or modify any data sent to or received from the attacker can monitor or modify any data sent to or received from the
device. This can take the form of: manifests, payloads, status device. This can take the form of: manifests, payloads, status
reports, and capability reports being modified or not delivered to reports, and capability reports being modified or not delivered to
the intended recipient. It can also take the form of analysis of the intended recipient. It can also take the form of analysis of
data sent to or from the device, either in content, size, or data sent to or from the device, either in content, size, or
frequency. frequency.
skipping to change at page 22, line 13 skipping to change at page 23, line 39
the attack he or she retrieves the provided firmware image and the attack he or she retrieves the provided firmware image and
performs reverse engineering of the firmware image to analyze it for performs reverse engineering of the firmware image to analyze it for
specific vulnerabilities. specific vulnerabilities.
Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements
Classification: Elevation of Privilege Classification: Elevation of Privilege
An authorised actor, but not the Author, uses an override mechanism An authorized actor, but not the Author, uses an override mechanism
(USER_STORY.OVERRIDE (Section 4.4.3)) to change an information (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information
element in a manifest signed by the Author. For example, if the element in a manifest signed by the Author. For example, if the
authorised actor overrides the digest and URI of the payload, the authorized actor overrides the digest and URI of the payload, the
actor can replace the entire payload with a payload of their choice. actor can replace the entire payload with a payload of their choice.
Threat Escalation: By overriding elements such as payload Threat Escalation: By overriding elements such as payload
installation instructions or firmware digest, this threat can be installation instructions or firmware digest, this threat can be
escalated to all types. escalated to all types.
Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure
skipping to change at page 24, line 51 skipping to change at page 26, line 26
(Section 3.4) (Section 3.4)
4.3.3. REQ.SEC.EXP: Expiration Time 4.3.3. REQ.SEC.EXP: Expiration Time
A firmware manifest MAY expire after a given time. Devices MAY A firmware manifest MAY expire after a given time. Devices MAY
provide a secure clock (local or remote). If a secure clock is provide a secure clock (local or remote). If a secure clock is
provided and the Firmware manifest has an expiration timestamp, the provided and the Firmware manifest has an expiration timestamp, the
device MUST reject the manifest if current time is later than the device MUST reject the manifest if current time is later than the
expiration time. expiration time.
Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2) Special consideration is required for end-of-life: if a firmware will
not be updated again, for example if a business stops issuing updates
to a device. The last valid firmware should not have an expiration
time.
Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2)
Implemented by: Expiration Time (Section 3.7) Implemented by: Expiration Time (Section 3.7)
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity
The authenticity of an update MUST be demonstrable. Typically, this The authenticity of an update MUST be demonstrable. Typically, this
means that updates must be digitally authenticated. Because the means that updates must be digitally authenticated. Because the
manifest contains information about how to install the update, the manifest contains information about how to install the update, the
manifest's authenticity MUST also be demonstrable. To reduce the manifest's authenticity MUST also be demonstrable. To reduce the
overhead required for validation, the manifest contains the digest of overhead required for validation, the manifest contains the digest of
the firmware image, rather than a second digital signature. The the firmware image, rather than a second digital signature. The
authenticity of the manifest can be verified with a digital signature authenticity of the manifest can be verified with a digital signature
or Message Authentication Code. The authenticity of the firmware or Message Authentication Code. The authenticity of the firmware
image is tied to the manifest by the use of a digest of the firmware image is tied to the manifest by the use of a digest of the firmware
image. image.
Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.MITM Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH
(Section 4.2.7) (Section 4.2.7)
Implemented by: Signature (Section 3.15), Payload Digest Implemented by: Signature (Section 3.15), Payload Digest
(Section 3.13) (Section 3.13)
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type
The type of payload (which may be independent of format) MUST be The type of payload (which may be independent of format) MUST be
authenticated. For example, the target must know whether the payload authenticated. For example, the target must know whether the payload
is XIP firmware, a loadable module, or configuration data. is XIP firmware, a loadable module, or configuration data.
skipping to change at page 26, line 5 skipping to change at page 27, line 31
Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) Mitigates: THREAT.IMG.LOCATION (Section 4.2.5)
Implemented by: Storage Location (Section 3.10) Implemented by: Storage Location (Section 3.10)
4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location
The location where a target should find a payload MUST be The location where a target should find a payload MUST be
authenticated. authenticated.
Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.MITM Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH
(Section 4.2.7) (Section 4.2.7)
Implemented by: Resource Indicator (Section 3.12) Implemented by: Resource Indicator (Section 3.12)
4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution
The target SHOULD verify firmware at time of boot. This requires The target SHOULD verify firmware at time of boot. This requires
authenticated payload size, and digest. authenticated payload size, and digest.
Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) Mitigates: THREAT.IMG.REPLACE (Section 4.2.8)
skipping to change at page 27, line 21 skipping to change at page 28, line 46
4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption
The manifest information model MUST enable encrypted payloads. The manifest information model MUST enable encrypted payloads.
Encryption helps to prevent third parties, including attackers, from Encryption helps to prevent third parties, including attackers, from
reading the content of the firmware image. This can protect against reading the content of the firmware image. This can protect against
confidential information disclosures and discovery of vulnerabilities confidential information disclosures and discovery of vulnerabilities
through reverse engineering. Therefore the manifest must convey the through reverse engineering. Therefore the manifest must convey the
information required to allow an intended recipient to decrypt an information required to allow an intended recipient to decrypt an
encrypted payload. encrypted payload.
Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.MITM Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.ONPATH
(Section 4.2.7) (Section 4.2.7)
Implemented by: Encryption Wrapper (Section 3.19) Implemented by: Encryption Wrapper (Section 3.19)
4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control
If a device grants different rights to different actors, then an If a device grants different rights to different actors, then an
exercise of those rights MUST be validated against a list of rights exercise of those rights MUST be validated against a list of rights
for the actor. This typically takes the form of an Access Control for the actor. This typically takes the form of an Access Control
List (ACL). ACLs are applied to two scenarios: List (ACL). ACLs are applied to two scenarios:
skipping to change at page 27, line 50 skipping to change at page 29, line 29
THREAT.UPD.UNAPPROVED (Section 4.2.11) THREAT.UPD.UNAPPROVED (Section 4.2.11)
Implemented by: Client-side code, not specified in manifest. Implemented by: Client-side code, not specified in manifest.
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests
It MUST be possible to encrypt part or all of the manifest. This may It MUST be possible to encrypt part or all of the manifest. This may
be accomplished with either transport encryption or with at-rest be accomplished with either transport encryption or with at-rest
encryption. encryption.
Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.MITM Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH
(Section 4.2.7) (Section 4.2.7)
Implemented by: External Encryption Wrapper / Transport Security Implemented by: External Encryption Wrapper / Transport Security
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest
The digest SHOULD cover all available space in a fixed-size storage The digest SHOULD cover all available space in a fixed-size storage
location. Variable-size storage locations MUST be restricted to location. Variable-size storage locations MUST be restricted to
exactly the size of deployed payload. This prevents any data from exactly the size of deployed payload. This prevents any data from
being distributed without being covered by the digest. For example, being distributed without being covered by the digest. For example,
XIP microcontrollers typically have fixed-size storage. These XIP microcontrollers typically have fixed-size storage. These
devices should deploy a digest that covers the deployed firmware devices should deploy a digest that covers the deployed firmware
skipping to change at page 28, line 27 skipping to change at page 30, line 11
Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) Mitigates: THREAT.IMG.EXTRA (Section 4.2.15)
Implemented by: Payload Digests (Section 3.13) Implemented by: Payload Digests (Section 3.13)
4.3.16. REQ.SEC.REPORTING: Secure Reporting 4.3.16. REQ.SEC.REPORTING: Secure Reporting
Status reports from the device to any remote system SHOULD be Status reports from the device to any remote system SHOULD be
performed over an authenticated, confidential channel in order to performed over an authenticated, confidential channel in order to
prevent modification or spoofing of the reports. prevent modification or spoofing of the reports.
Mitigates: THREAT.NET.MITM (Section 4.2.7) Mitigates: THREAT.NET.ONPATH (Section 4.2.7)
4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys
Cryptographic keys for signing/authenticating manifests SHOULD be Cryptographic keys for signing/authenticating manifests SHOULD be
stored in a manner that is inaccessible to networked devices, for stored in a manner that is inaccessible to networked devices, for
example in an HSM, or an air-gapped computer. This protects against example in an HSM, or an air-gapped computer. This protects against
an attacker obtaining the keys. an attacker obtaining the keys.
Keys SHOULD be stored in a way that limits the risk of a legitimate, Keys SHOULD be stored in a way that limits the risk of a legitimate,
but compromised, entity (such as a server or developer computer) but compromised, entity (such as a server or developer computer)
skipping to change at page 31, line 14 skipping to change at page 32, line 43
4.4.4. USER_STORY.COMPONENT: Component Update 4.4.4. USER_STORY.COMPONENT: Component Update
As a Device Operator, I want to divide my firmware into components, As a Device Operator, I want to divide my firmware into components,
so that I can reduce the size of updates, make different parties so that I can reduce the size of updates, make different parties
responsible for different components, and divide my firmware into responsible for different components, and divide my firmware into
frequently updated and infrequently updated components. frequently updated and infrequently updated components.
Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3)
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations
As a Device Operator, I want to ensure the quality of a firmware As a Device Operator, I want to ensure the quality of a firmware
update before installing it, so that I can ensure interoperability of update before installing it, so that I can ensure interoperability of
all devices in my product family. I want to restrict the ability to all devices in my product family. I want to restrict the ability to
make changes to my devices to require my express approval. make changes to my devices to require my express approval.
Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4),
REQ.SEC.ACCESS_CONTROL (Section 4.3.13) REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats
skipping to change at page 33, line 51 skipping to change at page 35, line 37
4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks
It MUST be possible for a manifest author to place ALL information It MUST be possible for a manifest author to place ALL information
required to process an update in the manifest. required to process an update in the manifest.
For example: Information about which precursor image is required for For example: Information about which precursor image is required for
a differential update MUST be placed in the manifest, not in the a differential update MUST be placed in the manifest, not in the
differential compression header. differential compression header.
For example: Information about an installation-time confirmation
system that must be used to allow the installation to proceed.
Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check),
USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1)
Implemented by: Additional installation instructions (Section 3.16) Implemented by: Additional installation instructions (Section 3.16)
4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location
It MUST be possible to redirect payload fetches. This applies where It MUST be possible to redirect payload fetches. This applies where
two manifests are used in conjunction. For example, a Device two manifests are used in conjunction. For example, a Device
Operator creates a manifest specifying a payload and signs it, and Operator creates a manifest specifying a payload and signs it, and
provides a URI for that payload. A Network Operator creates a second provides a URI for that payload. A Network Operator creates a second
manifest, with a dependency on the first. They use this second manifest, with a dependency on the first. They use this second
manifest to override the URIs provided by the Device Operator, manifest to override the URIs provided by the Device Operator,
skipping to change at page 35, line 25 skipping to change at page 37, line 16
A firmware image can be divided into multiple functional blocks for A firmware image can be divided into multiple functional blocks for
separate testing and distribution. This means that code would need separate testing and distribution. This means that code would need
to be distributed in multiple payloads. For example, this might be to be distributed in multiple payloads. For example, this might be
desirable in order to ensure that common code between devices is desirable in order to ensure that common code between devices is
identical in order to reduce distribution bandwidth. identical in order to reduce distribution bandwidth.
4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications
It MUST be possible to authenticate a manifest multiple times so that It MUST be possible to authenticate a manifest multiple times so that
authorisations from multiple parties with different permissions can authorizations from multiple parties with different permissions can
be required in order to authorise installation of a manifest. be required in order to authorize installation of a manifest.
Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5)
Implemented by: Signature (Section 3.15) Implemented by: Signature (Section 3.15)
4.5.5. REQ.USE.IMG.FORMAT: Format Usability 4.5.5. REQ.USE.IMG.FORMAT: Format Usability
The manifest format MUST accommodate any payload format that an The manifest format MUST accommodate any payload format that an
Operator wishes to use. This enables the recipient to detect which Operator wishes to use. This enables the recipient to detect which
format the Operator has chosen. Some examples of payload format are: format the Operator has chosen. Some examples of payload format are:
skipping to change at page 37, line 17 skipping to change at page 39, line 5
It MUST be possible to specify additional metadata for load time It MUST be possible to specify additional metadata for load time
processing of a payload, such as cryptographic information, load- processing of a payload, such as cryptographic information, load-
address, and compression algorithm. address, and compression algorithm.
N.B. load comes before exec/boot. N.B. load comes before exec/boot.
Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12)
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 Envelope
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, configuration information, public keys, authorization tokens, keys, configuration information, public keys, authorization tokens,
or X.509 certificates. or 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
skipping to change at page 38, line 30 skipping to change at page 40, line 22
Implemented by: N/A Implemented by: N/A
4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest
Any manifest format MUST enable the delivery of a key claim with, but Any manifest format MUST enable the delivery of a key claim with, but
not authenticated by, a manifest. This key claim delivers a new key not authenticated by, a manifest. This key claim delivers a new key
with which the recipient can verify the manifest. with which the recipient can verify the manifest.
Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15)
Implemented by: Key Claims (Section 3.24) Implemented by: Delegation Chain (Section 3.24)
5. IANA Considerations 5. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
6. Acknowledgements 6. Acknowledgements
We would like to thank our working group chairs, Dave Thaler, Russ We would like to thank our working group chairs, Dave Thaler, Russ
Housley and David Waltermire, for their review comments and their Housley and David Waltermire, for their review comments and their
support. support.
skipping to change at page 39, line 17 skipping to change at page 41, line 12
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-11 (work in progress), May draft-ietf-suit-architecture-14 (work in progress),
2020. October 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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[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>.
 End of changes. 88 change blocks. 
171 lines changed or deleted 257 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/