idnits 2.17.00 (12 Aug 2021) /tmp/idnits3283/draft-ietf-suit-mud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (23 March 2022) is 52 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-suit-manifest' is defined on line 218, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-16 ** Downref: Normative reference to an Informational RFC: RFC 7093 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft H. Tschofenig 4 Intended status: Standards Track Arm Limited 5 Expires: 24 September 2022 23 March 2022 7 Strong Assertions of IoT Network Access Requirements 8 draft-ietf-suit-mud-00 10 Abstract 12 The Manufacturer Usage Description (MUD) specification describes the 13 access and network functionality required a device to properly 14 function. The MUD description has to reflect the software running on 15 the device and its configuration. Because of this, the most 16 appropriate entity for describing device network access requirements 17 is the same as the entity developing the software and its 18 configuration. 20 A network presented with a MUD file by a device allows detection of 21 misbehavior by the device software and configuration of access 22 control. 24 This document defines a way to link a SUIT manifest to a MUD file 25 offering a stronger binding between the two. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 24 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 75 4. Extensions to SUIT . . . . . . . . . . . . . . . . . . . . . 4 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 Under [RFC8520], devices report a URL to a MUD manager in the 84 network. RFC 8520 envisions different approaches for conveying the 85 information from the device to the network such as: 87 * DHCP, 89 * IEEE802.1AB Link Layer Discovery Protocol (LLDP), and 91 * IEEE 802.1X whereby the URL to the MUD file would be contained in 92 the certificate used in an EAP method. 94 The MUD manager then uses the the URL to fetch the MUD file, which 95 contains access and network functionality required a device to 96 properly function. 98 The MUD manager must trust the service from which the URL is fetched 99 and to return an authentic copy of the MUD file. This concern may be 100 mitigated using the optional signature reference in the MUD file. 101 The MUD manager must also trust the device to report a correct URL. 102 In case of DHCP and LLDP the URL is unprotected. When the URL to the 103 MUD file is included in a certificate then it is authenticated and 104 integrity protected. A certificate created for use with network 105 access authentication is typically not signed by the entity that 106 wrote the software and configured the device, which leads to 107 conflation of local network access rights with rights to assert all 108 network access requirements. 110 There is a need to bind the entity that creates the software and 111 configuration to the MUD file because only that entity can attest the 112 network access requirements of the device. This specification 113 defines an extension to the SUIT manifest to include a MUD file (per 114 reference or by value). When combining a manufacturer usage 115 description with a manifest used for software/firmware updates 116 (potentially augmented with attestation) then a network operator can 117 get more confidence in the description of the access and network 118 functionality required a device to properly function. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 3. Architecture 130 The intended workflow is as follows: 132 * At the time of onboarding, devices report their manifest in use to 133 the MUD manager. 135 * If the SUIT_MUD_container has been severed, the suit-reference-uri 136 can be used to retrieve the complete manifest. 138 * The manifest authenticity is verified by the MUD manager, which 139 enforces that the MUD file presented is also authentic and as 140 intended by the device software vendor. 142 * Each time a device is updated, rebooted, or otherwise 143 substantially changed, it will execute an attestation. 145 - Among other claims in the Entity Attestation Token (EAT) 146 [I-D.ietf-rats-eat], the device will report its software 147 digest(s), configuration digest(s), primary manifest URI, and 148 primary manifest digest to the MUD manager. 150 - The MUD manager can then validate these attestation reports in 151 order to check that the device is operating with the expected 152 version of software and configuration. 154 - Since the manifest digest is reported, the MUD manager can look 155 up the corresponding manifest. 157 * If the MUD manager does not already have a full copy of the 158 manifest, it can be acquired using the reference URI. 160 * Once a full copy of the manifest is provided, the MUD manager can 161 verify the device attestation report and apply any appropriate 162 policy as described by the MUD file. 164 4. Extensions to SUIT 166 To enable strong assertions about the network access requirements 167 that a device should have for a particular software/configuration 168 pair, we include the ability to add MUD files to the SUIT manifest. 169 However, there are also circumstances in which a device should allow 170 the MUD to be changed without a firmware update. To enable this, we 171 add a MUD url to SUIT along with a subject-key identifier, according 172 to [RFC7093], mechanism 4 (the keyIdentifier is composed of the hash 173 of the DER encoding of the SubjectPublicKeyInfo value). 175 The following CDDL describes the extension to the SUIT_Manifest 176 structure: 178 ? suit-manifest-mud => SUIT_Digest 180 The SUIT_Envelope is also amended: 182 ? suit-manifest-mud => bstr .cbor SUIT_MUD_container 184 SUIT_MUD_container = { 185 ? suit-mud-url => #6.32(tstr), 186 ? suit-mud-ski => SUIT_Digest, 187 ? suit-mud-file => bstr 188 } 190 The MUD file is included verbatim within the bstr. No limits are 191 placed on the MUD file: it may be any RFC8520-compliant file. 193 5. Security Considerations 195 This specification links MUD files to other IETF technologies, 196 particularly to SUIT manifests, for improving security protection and 197 ease of use. By including MUD files (per reference or by value) in 198 SUIT manifests an extra layer of protection has been created and 199 synchronization risks can be minimized. If the MUD file and the 200 software/firmware loaded onto the device gets out-of-sync a device 201 may be firewalled and, with firewalling by networks in place, the 202 device may stop functioning. 204 6. IANA Considerations 206 suit-manifest-mud must be added as an extension point to the SUIT 207 manifest registry. 209 7. Normative References 211 [I-D.ietf-rats-eat] 212 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 213 Attestation Token (EAT)", Work in Progress, Internet- 214 Draft, draft-ietf-rats-eat-12, 24 February 2022, 215 . 218 [I-D.ietf-suit-manifest] 219 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 220 "A Concise Binary Object Representation (CBOR)-based 221 Serialization Format for the Software Updates for Internet 222 of Things (SUIT) Manifest", Work in Progress, Internet- 223 Draft, draft-ietf-suit-manifest-16, 25 October 2021, 224 . 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, 229 DOI 10.17487/RFC2119, March 1997, 230 . 232 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 233 for Generating Key Identifiers Values", RFC 7093, 234 DOI 10.17487/RFC7093, December 2013, 235 . 237 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 238 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 239 May 2017, . 241 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 242 Description Specification", RFC 8520, 243 DOI 10.17487/RFC8520, March 2019, 244 . 246 Authors' Addresses 248 Brendan Moran 249 Arm Limited 250 Email: Brendan.Moran@arm.com 252 Hannes Tschofenig 253 Arm Limited 254 Email: hannes.tschofenig@arm.com