idnits 2.17.1 draft-richardson-opsawg-mud-acceptable-urls-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 214: '...quent updates to that MUD file MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2020) is 1557 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8499' is defined on line 267, but no explicit reference was found in the text ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-05) exists of draft-reddy-opsawg-mud-tls-02 == Outdated reference: A later version (-05) exists of draft-richardson-opsawg-securehomegateway-mud-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Best Current Practice January 21, 2020 5 Expires: July 24, 2020 7 Authorized update to MUD URLs 8 draft-richardson-opsawg-mud-acceptable-urls-00 10 Abstract 12 This document provides a way for an RFC8520 Manufacturer Usage 13 Description (MUD) definitions to declare what are acceptable 14 replacement URLs for a device. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 24, 2020. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Updating MUD URLs vs Updating MUD files . . . . . . . . . . . 3 52 2.1. Updating the MUD file in place . . . . . . . . . . . . . 3 53 2.1.1. Adding capabilities . . . . . . . . . . . . . . . . . 3 54 2.1.2. Removing capabilities . . . . . . . . . . . . . . . . 4 55 2.1.3. Significant changes to protocols . . . . . . . . . . 4 56 2.2. Motivation for updating MUD URLs . . . . . . . . . . . . 5 57 3. Threat model for MUD URLs . . . . . . . . . . . . . . . . . . 5 58 3.1. leveraging the manufacturer signature . . . . . . . . . . 5 59 3.2. Concerns about same-signer mechanism . . . . . . . . . . 5 60 4. Proposed possible Extension . . . . . . . . . . . . . . . . . 5 61 4.1. Semantic changes only . . . . . . . . . . . . . . . . . . 6 62 4.2. Add an extension . . . . . . . . . . . . . . . . . . . . 6 63 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 7.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 [RFC8520] provides a standardized way to describe how a specific 74 purpose device makes use of Internet resources. Access Control Lists 75 (ACLs) can be defined in an RFC8520 Manufacturer Usage Description 76 (MUD) file that permit a device to access Internet resources by DNS 77 name. 79 MUD URLs can come from a number of sources: 81 o IDevID Extensions 83 o DHCP 85 o LLDP 87 o [I-D.richardson-opsawg-securehomegateway-mud] proposes to scan 88 them from QRcodes. 90 The IDevID mechanism provides a URL that is asserted 91 cryptographically by a manufacturer. However, it is difficult for 92 manufacturers to update the IDevID of a device which is already in a 93 box. 95 The DHCP and LLDP mechanisms are not signed, but are asserted by the 96 device. A firmware update may update what MUD URL is emitted. 97 Sufficiently well targetted malware could also change the MUD URL. 99 The QRcode mechanism is usually done via paper/stickers, and is 100 typically not under the control of the device itself at all. 102 While MUD files may include signatures, it is not mandatory to check 103 them, and there is not a clear way to connect the entity which signed 104 the MUD file to the device itself. A malicious device does not need 105 to make up a MUD file if there is already an available, and already 106 trusted MUD file which it can use to impersonate the device. 108 One defense against this is to not trust MUD URLs which are different 109 from the one that was placed in an IDevID. Or if the initial MUD URL 110 was not taken from an IDevID, it could be trusted on first use. But, 111 if the MUD controller has locked down the URL, then updates to the 112 URL are difficult to do. 114 2. Updating MUD URLs vs Updating MUD files 116 2.1. Updating the MUD file in place 118 One option is for the manufacturer to never change the MUD URL due to 119 firmware updates. The published description is updated whenever the 120 behaviour of the firmware changes. 122 2.1.1. Adding capabilities 124 For situations where new capabilities are added to the firmware, the 125 MUD file will detail the new access that the new firmware requires. 126 This may involve new incoming or outgoing connections that should be 127 authorized. Devices which have been upgraded to the new firmware 128 will make use of the new features. Devices which have not been 129 upgraded to the new firmware may have new connections that are 130 authorized, but which the device does not use (outgoing connections), 131 or for which the device is not prepared to respond to (new incoming 132 connections). 134 It is possible that older versions of the firmware have 135 vulnerabilities which were not easily exploitable due to the MUD file 136 preventing particular kinds of access. As an example, an older 137 firmware could have a no credentials required (or default 138 credentials) access via telnet on port 23 or HTTP on port 80. The 139 MUD file protected the device such that it could either not be 140 accessed at all, or access was restricted to connections from a 141 controller only. 143 Useful and needed upgrades to the firmware could add credentials to 144 that service, permitting it to be opened up for more general access. 145 The new MUD file would provide for such access, but when combined 146 with the weak security of the old firmware, results in a compromised 147 device. 149 While there is an argument that old firmware was insecure and should 150 be replaced, it is often the case that the upgrade process involves 151 downtown, or can introduce risks due to needed evaluations not having 152 been completed yet. As an example: moving vehicles (cars, airplanes, 153 etc.) should not perform upgrades while in motion. It is probably 154 undesireable to perform any upgrade to an airplane outside of its 155 service facility. The owner of a vehicle may desire to only perform 156 software upgrades when they are at home, and could make other 157 arrangements for transporation, rather than when parked at a remote 158 cabin. The situation for medical devices is even more complex. 160 2.1.2. Removing capabilities 162 For situations where existing capabilities prove to be a problem and 163 are to be turned off or removed in subsequent versions of the 164 firmware, the MUD file will be updated to disallow connections that 165 previously were allowed. 167 In this case, the new MUD file will forbid some connection which the 168 old firmware still expects to do. As explained in the previous 169 section, upgrades may not always occur immediately upon release of 170 the new firmware. 172 In this case the old device will be performing unwanted connections, 173 and the MUD controller when be alerting the device owner that the 174 device is mis-behaving. This causes a [boycrieswolf] situation, 175 leading to real security issues being ignored. This is a serious 176 issue as documented also in [boywolfinfosec], and [falsemalware]. 178 2.1.3. Significant changes to protocols 180 [I-D.reddy-opsawg-mud-tls] suggests MUD definitions to allow 181 examination of TLS protocol details. Such a profile may be very 182 specific to the TLS library which is shipped. Changes to the library 183 (including bug fixes) may cause significant changes to the profile, 184 requiring changes to the profile described in the MUD file. Such 185 changes are likely neither forward nor backward compatible with other 186 versions, and in place updates to MUD files is not indicated. 188 2.2. Motivation for updating MUD URLs 190 While many small tweaks to a MUD file can be done in place, the 191 situation described above, particularly when it comes to removing 192 capabilities will require updates to the MUD URL. A strategy is do 193 this securely is needed, and the rest of this document provides a 194 mechanism to do this securely. 196 3. Threat model for MUD URLs 198 Only the DHCP and LLDP MUD URL mechanisms are sufficiently close to 199 the firmware version that they can be easily updated when the 200 firmware is updated. Because of that sensitivity, they are also 201 easily changed by malware. 203 There are mitigating mechanisms which may be enough. The MUD files 204 are signed by the manufacturer. 205 [RFC8520] has not established a trust model for MUD controllers to 206 determine whether a signature from a specific entity is legitimate as 207 a signature for a particular device. [RFC8520] leaves this to the 208 industry to work out. 210 3.1. leveraging the manufacturer signature 212 Many MUD controllers currently use a Trust on First Use mechanism 213 where the first time a signature from a device is verified, the 214 signatory is recorded. Subsequent updates to that MUD file MUST be 215 signed by the same entity to be accepted. 217 Based upon this process, an update to the MUD URL would be valid if 218 the new MUD file was signed by the same entity that signed the 219 previous entry. This mechanism permits a replacement URL to be any 220 URL that the same manufacturer can provide. 222 3.2. Concerns about same-signer mechanism 224 There is still a potential threat: a manufacturer which has many 225 products may have a MUD definition for another product that has the 226 privileges that the malware desires. 228 4. Proposed possible Extension 230 The first MUD file which is defined for a device can come from an 231 IDevID, or via Trust on First Use with DHCP. 232 This initial, initially trusted, MUD file will be called the "root" 233 file. 235 MUD files start with a self-referential MUD-URL attribute. 237 4.1. Semantic changes only 239 Proposal 1 involves no changes to the definition. It is instead a 240 semantic change: updates to the MUD URL for a device must come from a 241 URL that is identical to the mud-URL in the root file, but may have a 242 different basename component. 244 That is, if the mud-url is http://example.com/hello/there/file.json 245 then any URL that starts with http://example.com/hello/there/ would 246 be acceptable. Note: the new URLs are not relative. 248 4.2. Add an extension 250 Proposal 2 involves an extension to the MUD definition. A new 251 extension, _mud-base-url_ would be created that would contain the 252 value http://example.com/hello/there/ rather than being implied from 253 the mud-url. 255 5. Privacy Considerations 257 TBD 259 6. Security Considerations 261 TBD 263 7. References 265 7.1. Normative References 267 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 268 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 269 January 2019, . 271 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 272 Description Specification", RFC 8520, 273 DOI 10.17487/RFC8520, March 2019, 274 . 276 7.2. Informative References 278 [boycrieswolf] 279 "The Boy Who Cried Wolf", January 2020, 280 . 282 [boywolfinfosec] 283 "Security Alerts - A Case of the Boy Who Cried Wolf?", 284 January 2020, . 287 [falsemalware] 288 "False malware alerts cost organizations $1.27M annually, 289 report says", January 2020, 290 . 294 [I-D.reddy-opsawg-mud-tls] 295 Reddy.K, T., Wing, D., and B. Anderson, "MUD (D)TLS 296 profiles for IoT devices", draft-reddy-opsawg-mud-tls-02 297 (work in progress), January 2020. 299 [I-D.richardson-opsawg-securehomegateway-mud] 300 Richardson, M. and J. Latour, "Loading MUD URLs from QR 301 codes", draft-richardson-opsawg-securehomegateway-mud-02 302 (work in progress), December 2019. 304 Appendix A. Appendices 306 Author's Address 308 Michael Richardson 309 Sandelman Software Works 311 Email: mcr+ietf@sandelman.ca