idnits 2.17.1 draft-richardson-opsawg-mud-acceptable-urls-01.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...' RFC 2119 keyword, line 242: '... The MUD-URL MUST always be an Absolute URI: see [RFC3986] section...' RFC 2119 keyword, line 248: '... in the MUD file SHOULD be a relative ...' RFC 2119 keyword, line 263: '...sulting two strings MUST be identical....' -- The draft header indicates that this document updates RFC8520, but the abstract doesn't seem to directly say this. It does mention RFC8520 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 15, 2020) is 1411 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) == Outdated reference: A later version (-05) exists of draft-reddy-opsawg-mud-tls-03 == Outdated reference: A later version (-05) exists of draft-richardson-opsawg-securehomegateway-mud-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 Updates: 8520 (if approved) W. Pan 5 Intended status: Best Current Practice Huawei Technologies 6 Expires: December 17, 2020 E. Lear 7 Cisco Systems 8 June 15, 2020 10 Authorized update to MUD URLs 11 draft-richardson-opsawg-mud-acceptable-urls-01 13 Abstract 15 This document provides a way for an RFC8520 Manufacturer Usage 16 Description (MUD) definitions to declare what are acceptable 17 replacement URLs for a device. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 17, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Updating MUD URLs vs Updating MUD files . . . . . . . . . . . 3 55 2.1. Updating the MUD file in place . . . . . . . . . . . . . 3 56 2.1.1. Adding capabilities . . . . . . . . . . . . . . . . . 3 57 2.1.2. Removing capabilities . . . . . . . . . . . . . . . . 4 58 2.1.3. Significant changes to protocols . . . . . . . . . . 4 59 2.2. Motivation for updating MUD URLs . . . . . . . . . . . . 5 60 3. Threat model for MUD URLs . . . . . . . . . . . . . . . . . . 5 61 3.1. leveraging the manufacturer signature . . . . . . . . . . 5 62 3.2. Concerns about same-signer mechanism . . . . . . . . . . 5 63 4. Changes to RFC8520 . . . . . . . . . . . . . . . . . . . . . 5 64 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 [RFC8520] provides a standardized way to describe how a specific 75 purpose device makes use of Internet resources. Access Control Lists 76 (ACLs) can be defined in an RFC8520 Manufacturer Usage Description 77 (MUD) file that permit a device to access Internet resources by DNS 78 name. 80 MUD URLs can come from a number of sources: 82 o IDevID Extensions 84 o DHCP 86 o LLDP 88 o [I-D.richardson-opsawg-securehomegateway-mud] proposes to scan 89 them from QRcodes. 91 The IDevID mechanism provides a URL that is asserted 92 cryptographically by a manufacturer. However, it is difficult for 93 manufacturers to update the IDevID of a device which is already in a 94 box. 96 The DHCP and LLDP mechanisms are not signed, but are asserted by the 97 device. A firmware update may update what MUD URL is emitted. 98 Sufficiently well targetted malware could also change the MUD URL. 100 The QRcode mechanism is usually done via paper/stickers, and is 101 typically not under the control of the device itself at all. 103 While MUD files may include signatures, it is not mandatory to check 104 them, and there is not a clear way to connect the entity which signed 105 the MUD file to the device itself. A malicious device does not need 106 to make up a MUD file if there is already an available, and already 107 trusted MUD file which it can use to impersonate the device. 109 One defense against this is to not trust MUD URLs which are different 110 from the one that was placed in an IDevID. Or if the initial MUD URL 111 was not taken from an IDevID, it could be trusted on first use. But, 112 if the MUD controller has locked down the URL, then updates to the 113 URL are difficult to do. 115 2. Updating MUD URLs vs Updating MUD files 117 2.1. Updating the MUD file in place 119 One option is for the manufacturer to never change the MUD URL due to 120 firmware updates. The published description is updated whenever the 121 behaviour of the firmware changes. 123 2.1.1. Adding capabilities 125 For situations where new capabilities are added to the firmware, the 126 MUD file will detail the new access that the new firmware requires. 127 This may involve new incoming or outgoing connections that should be 128 authorized. Devices which have been upgraded to the new firmware 129 will make use of the new features. Devices which have not been 130 upgraded to the new firmware may have new connections that are 131 authorized, but which the device does not use (outgoing connections), 132 or for which the device is not prepared to respond to (new incoming 133 connections). 135 It is possible that older versions of the firmware have 136 vulnerabilities which were not easily exploitable due to the MUD file 137 preventing particular kinds of access. As an example, an older 138 firmware could have a no credentials required (or default 139 credentials) access via telnet on port 23 or HTTP on port 80. The 140 MUD file protected the device such that it could either not be 141 accessed at all, or access was restricted to connections from a 142 controller only. 144 Useful and needed upgrades to the firmware could add credentials to 145 that service, permitting it to be opened up for more general access. 146 The new MUD file would provide for such access, but when combined 147 with the weak security of the old firmware, results in a compromised 148 device. 150 While there is an argument that old firmware was insecure and should 151 be replaced, it is often the case that the upgrade process involves 152 downtown, or can introduce risks due to needed evaluations not having 153 been completed yet. As an example: moving vehicles (cars, airplanes, 154 etc.) should not perform upgrades while in motion. It is probably 155 undesireable to perform any upgrade to an airplane outside of its 156 service facility. The owner of a vehicle may desire to only perform 157 software upgrades when they are at home, and could make other 158 arrangements for transporation, rather than when parked at a remote 159 cabin. The situation for medical devices is even more complex. 161 2.1.2. Removing capabilities 163 For situations where existing capabilities prove to be a problem and 164 are to be turned off or removed in subsequent versions of the 165 firmware, the MUD file will be updated to disallow connections that 166 previously were allowed. 168 In this case, the new MUD file will forbid some connection which the 169 old firmware still expects to do. As explained in the previous 170 section, upgrades may not always occur immediately upon release of 171 the new firmware. 173 In this case the old device will be performing unwanted connections, 174 and the MUD controller when be alerting the device owner that the 175 device is mis-behaving. This causes a [boycrieswolf] situation, 176 leading to real security issues being ignored. This is a serious 177 issue as documented also in [boywolfinfosec], and [falsemalware]. 179 2.1.3. Significant changes to protocols 181 [I-D.reddy-opsawg-mud-tls] suggests MUD definitions to allow 182 examination of TLS protocol details. Such a profile may be very 183 specific to the TLS library which is shipped. Changes to the library 184 (including bug fixes) may cause significant changes to the profile, 185 requiring changes to the profile described in the MUD file. Such 186 changes are likely neither forward nor backward compatible with other 187 versions, and in place updates to MUD files is not indicated. 189 2.2. Motivation for updating MUD URLs 191 While many small tweaks to a MUD file can be done in place, the 192 situation described above, particularly when it comes to removing 193 capabilities will require updates to the MUD URL. A strategy is do 194 this securely is needed, and the rest of this document provides a 195 mechanism to do this securely. 197 3. Threat model for MUD URLs 199 Only the DHCP and LLDP MUD URL mechanisms are sufficiently close to 200 the firmware version that they can be easily updated when the 201 firmware is updated. Because of that sensitivity, they are also 202 easily changed by malware. 204 There are mitigating mechanisms which may be enough. The MUD files 205 are signed by the manufacturer. [RFC8520] has not established a 206 trust model for MUD controllers to determine whether a signature from 207 a specific entity is legitimate as a signature for a particular 208 device. [RFC8520] leaves this to the 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. Changes to RFC8520 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 or LLDP or another 232 mechanism. 234 This first, initially trusted, MUD file will be called the "root" MUD 235 file. 237 MUD files contain a self-referential MUD-URL attribute that point to 238 a MUD file located on the vendor's web site. While the IDevID, DHCP 239 and LLDP mechanisms only transmit a URL, there are some newer, not 240 yet standardized proposals that would transmit an entire MUD file. 242 The MUD-URL MUST always be an Absolute URI: see [RFC3986] section 243 4.3. 245 The URL found in the MUD-URL attribute is to be called the canonical 246 MUD URL for the device. 248 The MUD-SIGNATURE attribute in the MUD file SHOULD be a relative URI 249 (see [RFC3986] section 4.2) with the (hierarchical) base URL for this 250 reference being the MUD-URL attribute. 252 Subsequent MUD files are considered valid if: 254 o have the same initial Base-URI as the MUD-URL, but may have a 255 different final part 257 o they are signed by the same End Entity (same trusted CA and same 258 SubjectAltName) as the "root" MUD file 260 Section 5.2 of [RFC3986] details many cases for calculating the Base- 261 URI. The test is simplified to: remove everything to the right of 262 the last (rightmost) "/" in the URL of "root" MUD file URL, and the 263 proposed new URL. The resulting two strings MUST be identical. 265 For as a simple example, if the "root" mud-url is 266 http://example.com/hello/there/file.json then any URL that starts 267 with http://example.com/hello/there/ would be acceptable, such as 268 http://example.com/hello/there/revision2.json. 270 Once the new MUD file is accepted, then it becomes the new "root" MUD 271 file, and any subsequent updates must be relative to the MUD-URL in 272 that file. This process allows a manufacturer to rework their file 273 structure, to change web server hostnames (such as when there is an 274 acquisition or merger), etc. so long as they retain the old structure 275 long enough for all devices to upgrade at least once. 277 5. Privacy Considerations 279 The MUD URL contains sensitive model and even firmware revision 280 numbers. Thus the MUD URL identifies the make, model and revision of 281 a device. [RFC8520] already identifies this privacy concern, and 282 suggests use of TLS so that the HTTP requests that retrieve the MUD 283 file do not divulge that level of detail. However, it is possible 284 that even observing the traffic to that manufacturer may be 285 revealing, and [RFC8520] goes on to suggest use of a proxy as well. 287 6. Security Considerations 289 Prior to the standardization of the process in this document, if a 290 device was infiltrated by malware, and said malware wished to make 291 accesses beyond what the current MUD file allowed, the the malware 292 would have to: 1. arrange for an equivalent MUD file to be visible 293 somewhere on the Internet 2. depend upon the MUD-manager either not 294 checking signatures, or 3. somehow get the manufacturer to sign the 295 alternate MUD 4. announce this new URL via DHCP or LLDP, updating the 296 MUD-manager with the new permissions. 298 One way to accomplish (3) is to leverage the existence of MUD files 299 created by the manufacturer for different classes of devices. Such 300 files would already be signed by the same manufacturer, eliminating 301 the need to spoof a signature. 303 With the standardization of the process in this document, then the 304 attacker can no longer point to arbitrary MUD files in step 4, but 305 can only make use of MUD files that the manufacturer has already 306 provided for this device. 308 Manufacturers are advised to maintain an orderly layout of MUD files 309 in their web servers, with each unique producting having its own 310 directory/pathname. 312 The process described updates only MUD-managers and the processes 313 that manufacturers use to manage the location of their MUD files. 315 A manufacturer which has not managed their MUD files in the the way 316 described here can deploy new directories of per-product MUD files, 317 and then can update the existing MUD files in place to point to the 318 new URLs using the MUD-URL attribute. 320 There is therefore no significant flag day: MUD managers may 321 implement the new policy without significant concern about backwards 322 compatibility. 324 7. References 326 7.1. Normative References 328 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 329 Resource Identifier (URI): Generic Syntax", STD 66, 330 RFC 3986, DOI 10.17487/RFC3986, January 2005, 331 . 333 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 334 Description Specification", RFC 8520, 335 DOI 10.17487/RFC8520, March 2019, 336 . 338 7.2. Informative References 340 [boycrieswolf] 341 "The Boy Who Cried Wolf", January 2020, 342 . 344 [boywolfinfosec] 345 "Security Alerts - A Case of the Boy Who Cried Wolf?", 346 January 2020, . 349 [falsemalware] 350 "False malware alerts cost organizations $1.27M annually, 351 report says", January 2020, 352 . 356 [I-D.reddy-opsawg-mud-tls] 357 Reddy.K, T., Wing, D., and B. Anderson, "MUD (D)TLS 358 profiles for IoT devices", draft-reddy-opsawg-mud-tls-03 359 (work in progress), January 2020. 361 [I-D.richardson-opsawg-securehomegateway-mud] 362 Richardson, M., Latour, J., and H. Gharakheili, "Loading 363 MUD URLs from QR codes", draft-richardson-opsawg- 364 securehomegateway-mud-03 (work in progress), March 2020. 366 Appendix A. Appendices 368 Authors' Addresses 370 Michael Richardson 371 Sandelman Software Works 373 Email: mcr+ietf@sandelman.ca 375 Wei Pan 376 Huawei Technologies 378 Email: william.panwei@huawei.com 379 Eliot Lear 380 Cisco Systems 382 Email: lear@cisco.com