idnits 2.17.1 draft-moran-suit-mud-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 25, 2021) is 1067 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 216, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-09 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-12 ** Downref: Normative reference to an Informational RFC: RFC 7093 Summary: 1 error (**), 0 flaws (~~), 6 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: November 26, 2021 May 25, 2021 7 Strong Assertions of IoT Network Access Requirements 8 draft-moran-suit-mud-02 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 November 26, 2021. 44 Copyright Notice 46 Copyright (c) 2021 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 76 4. Extensions to SUIT . . . . . . . . . . . . . . . . . . . . . 4 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 79 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 82 1. Introduction 84 Under [RFC8520], devices report a URL to a MUD manager in the 85 network. RFC 8520 envisions different approaches for conveying the 86 information from the device to the network such as: 88 - DHCP, 90 - IEEE802.1AB Link Layer Discovery Protocol (LLDP), and 92 - IEEE 802.1X whereby the URL to the MUD file would be contained in 93 the certificate used in an EAP method. 95 The MUD manager then uses the the URL to fetch the MUD file, which 96 contains access and network functionality required a device to 97 properly function. 99 The MUD manager must trust the service from which the URL is fetched 100 and to return an authentic copy of the MUD file. This concern may be 101 mitigated using the optional signature reference in the MUD file. 102 The MUD manager must also trust the device to report a correct URL. 103 In case of DHCP and LLDP the URL is unprotected. When the URL to the 104 MUD file is included in a certificate then it is authenticated and 105 integrity protected. A certificate created for use with network 106 access authentication is typically not signed by the entity that 107 wrote the software and configured the device, which leads to 108 conflation of local network access rights with rights to assert all 109 network access requirements. 111 There is a need to bind the entity that creates the software and 112 configuration to the MUD file because only that entity can attest the 113 network access requirements of the device. This specification 114 defines an extension to the SUIT manifest to include a MUD file (per 115 reference or by value). When combining a manufacturer usage 116 description with a manifest used for software/firmware updates 117 (potentially augmented with attestation) then a network operator can 118 get more confidence in the description of the access and network 119 functionality required a device to properly function. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. Architecture 131 The intended workflow is as follows: 133 - At the time of onboarding, devices report their manifest in use to 134 the MUD manager. 136 - If the SUIT_MUD_container has been severed, the suit-reference-uri 137 can be used to retrieve the complete manifest. 139 - The manifest authenticity is verified by the MUD manager, which 140 enforces that the MUD file presented is also authentic and as 141 intended by the device software vendor. 143 - Each time a device is updated, rebooted, or otherwise 144 substantially changed, it will execute an attestation. 146 o Among other claims in the Entity Attestation Token (EAT) 147 [I-D.ietf-rats-eat], the device will report its software 148 digest(s), configuration digest(s), primary manifest URI, and 149 primary manifest digest to the MUD manager. 151 o The MUD manager can then validate these attestation reports in 152 order to check that the device is operating with the expected 153 version of software and configuration. 155 o Since the manifest digest is reported, the MUD manager can look 156 up the corresponding manifest. 158 - If the MUD manager does not already have a full copy of the 159 manifest, it can be acquired using the reference URI. 161 - Once a full copy of the manifest is provided, the MUD manager can 162 verify the device attestation report and apply any appropriate 163 policy as described by the MUD file. 165 4. Extensions to SUIT 167 To enable strong assertions about the network access requirements 168 that a device should have for a particular software/configuration 169 pair, we include the ability to add MUD files to the SUIT manifest. 170 However, there are also circumstances in which a device should allow 171 the MUD to be changed without a firmware update. To enable this, we 172 add a MUD url to SUIT along with a subject-key identifier, according 173 to [RFC7093], mechanism 4 (the keyIdentifier is composed of the hash 174 of the DER encoding of the SubjectPublicKeyInfo value). 176 The following CDDL describes the extension to the SUIT_Manifest 177 structure: 179 ? suit-manifest-mud => SUIT_Digest 181 The SUIT_Envelope is also amended: 183 ? suit-manifest-mud => bstr .cbor SUIT_MUD_container 185 SUIT_MUD_container = { 186 ? suit-mud-url => #6.32(tstr), 187 ? suit-mud-ski => SUIT_Digest, 188 ? suit-mud-file => bstr 189 } 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 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 213 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 214 ietf-rats-eat-09 (work in progress), March 2021. 216 [I-D.ietf-suit-manifest] 217 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 218 "A Concise Binary Object Representation (CBOR)-based 219 Serialization Format for the Software Updates for Internet 220 of Things (SUIT) Manifest", draft-ietf-suit-manifest-12 221 (work in progress), February 2021. 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, 225 DOI 10.17487/RFC2119, March 1997, 226 . 228 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 229 for Generating Key Identifiers Values", RFC 7093, 230 DOI 10.17487/RFC7093, December 2013, 231 . 233 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 234 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 235 May 2017, . 237 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 238 Description Specification", RFC 8520, 239 DOI 10.17487/RFC8520, March 2019, 240 . 242 Authors' Addresses 244 Brendan Moran 245 Arm Limited 247 EMail: Brendan.Moran@arm.com 249 Hannes Tschofenig 250 Arm Limited 252 EMail: hannes.tschofenig@arm.com