idnits 2.17.1 draft-ietf-opsawg-mud-acceptable-urls-03.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 313: '... The MUD-URL MUST always be an Absolute URI: see [RFC3986] section...' RFC 2119 keyword, line 319: '... in the MUD file SHOULD be a relative ...' RFC 2119 keyword, line 334: '...sulting two strings MUST be identical....' RFC 2119 keyword, line 342: '...bsequent updates MUST be relative to t...' -- 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 (19 February 2021) is 1161 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 (-14) exists of draft-ietf-opsawg-mud-tls-04 == Outdated reference: A later version (-07) exists of draft-richardson-mud-qrcode-00 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: 23 August 2021 E. Lear 7 Cisco Systems 8 19 February 2021 10 Authorized update to MUD URLs 11 draft-ietf-opsawg-mud-acceptable-urls-03 13 Abstract 15 This document provides a way for an RFC8520 Manufacturer Usage 16 Description (MUD) definitions to declare what are acceptable 17 replacement MUD URLs for a device. 19 RFCEDITOR-please-remove: this document is being worked on at: 20 https://github.com/mcr/iot-mud-acceptable-urls 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 23 August 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Updating the MUD files in place . . . . . . . . . . . . . . . 3 57 2.1. Adding capabilities . . . . . . . . . . . . . . . . . . . 3 58 2.2. Removing capabilities . . . . . . . . . . . . . . . . . . 4 59 2.3. Significant changes to protocols . . . . . . . . . . . . 4 60 2.4. Motivation for updating MUD URLs . . . . . . . . . . . . 5 61 3. Updating the MUD URLs . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Leveraging the manufacturer signature . . . . . . . . . . 6 63 3.2. Concerns about same-signer mechanism . . . . . . . . . . 6 64 4. Proposed mechanism . . . . . . . . . . . . . . . . . . . . . 7 65 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6.1. Updating files vs Updating MUD URLs . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 7.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 11 72 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 [RFC8520] provides a standardized way to describe how a specific 78 purpose device makes use of Internet resources and associated 79 suggested network behavior, which are described in a MUD file hosted 80 in its manufacturer's server. By providing a MUD URL by the device, 81 the network manager can locate this MUD file and determine the 82 required network authorization of the device. 84 In some cases, e.g., the firmware update, the network behaviors of 85 the device may change, and the description in the original MUD file 86 will no longer apply. To solve this problem, there are two common 87 ways which the manufacturer can use. 89 One is to change what is in the MUD file, i.e., update the MUD file 90 in place, whenever the behavior of the firmware changes. Section 2 91 discusses three scenarios for updating the MUD file and the 92 corresponding potential issues. 94 The other is to change which MUD file is processed by changing the 95 MUD URL. Section 3 describes the common sources of MUD URLs and the 96 problems and threats faced by each type of source when updating the 97 MUD URL. This document proposes an enhanced mechanism of how to 98 securely update the MUD URL in Section 4. 100 There are also some assumptions and prerequisites in this document. 102 While MUD files may include signatures, [RFC8520] does not mandate 103 checking them, and there is not a clear way to connect the entity 104 which signed the MUD file to the device itself. This document limits 105 itself to situations in which the MUD file is signed, and that the 106 MUD controller has been configured to always check the signatures, 107 rejecting files whose signatures do not match. 109 [RFC8520] does not specify how MUD controllers establish their trust 110 in the manufacturers' signing key: there are many possible solutions 111 from manual configuration of trust anchors, some kind of automatic 112 configuration during onboarding, but also including to Trust on First 113 Use (TOFU). How this initial trust is established is not important 114 for this document, it is sufficient that some satisfactory initial 115 trust is established. 117 2. Updating the MUD files in place 119 Three scenarios for updating the MUD file and the corresponding 120 potential issues are discussed below. 122 2.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 that have been upgraded to the new firmware will 128 make use of the new features. Devices that have not been upgraded to 129 the new firmware may have new connections that are authorized, but 130 which the device does not use (outgoing connections), or which the 131 device is not prepared to respond to (new incoming connections). 133 It is possible that older versions of the firmware have 134 vulnerabilities that were not easily exploitable due to the MUD file 135 preventing particular kinds of access. For example, an older 136 firmware could have no credentials required (or default credentials) 137 access via telnet on port 23 or HTTP on port 80. The MUD file 138 protected the device such that it could either not be accessed at 139 all, or access was restricted to connections from a controller only. 141 Useful and needed upgrades to the firmware could add credentials to 142 that service, allowing it to be opened up for more general access. 143 The new MUD file would provide for such access, but when combined 144 with the weak security of the old firmware, it results in a 145 compromised device. 147 While there is an argument that old firmware was insecure and should 148 be replaced, it is often the case that the upgrade process involves 149 downtime, or can introduce risks due to needed evaluations not having 150 been completed yet. As an example: moving vehicles (cars, airplanes, 151 etc.) should not perform upgrades while in motion! It is probably 152 undesirable to perform any upgrade to an airplane outside of its 153 service facility. The vehicle owner may desire only to perform 154 software upgrades when they are at home, and could make other 155 arrangements for transportation, rather than when parked at a remote 156 cabin. The situation for upgrades of medical devices has even more 157 considerations involving regulatory compliance. 159 2.2. Removing capabilities 161 For situations where existing capabilities prove to be a problem and 162 are to be turned off or removed in subsequent versions of the 163 firmware, the MUD file will be updated to disallow connections that 164 previously were allowed. 166 In this case, the new MUD file will forbid some connections, which 167 the old firmware still expects to do. As explained in the previous 168 section, upgrades may not always occur immediately upon releasing the 169 new firmware. 171 In this case, the old device will be performing unwanted connections, 172 and the MUD controller will be alerting the network owner that the 173 device is misbehaving rather than not upgraded. This causes a false- 174 positive situation (see [boycrieswolf]), leading to real security 175 issues being ignored. This is a serious issue as documented also in 176 [boywolfinfosec], and [falsemalware]. 178 2.3. Significant changes to protocols 180 [I-D.ietf-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 in a device. Changes to 183 the library (including bug fixes) may cause significant changes to 184 the profile, requiring changes to the profile described in the MUD 185 file. Such changes are likely neither forward nor backward 186 compatible with other versions, and in place updates to MUD files are 187 therefore not indicated. 189 2.4. 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 suggest that changes to the MUD URL. A strategy 194 for doing this securely is needed, and the rest of this document 195 provides a mechanism to do this securely. 197 3. Updating the MUD URLs 199 MUD URLs can come from a number of sources: 201 * IDevID Extensions 203 * DHCP option 205 * LLDP TLV 207 * [I-D.richardson-mud-qrcode] proposes to scan them from QRcodes. 209 The IDevID mechanism provides a URL that is asserted 210 cryptographically by a manufacturer. However, it is difficult for 211 manufacturers to update the IDevID of a device which is already in a 212 box. 214 The DHCP and LLDP mechanisms are not signed, but are asserted by the 215 device. A firmware update may update what MUD URL is emitted. 216 Sufficiently well targeted malware could also change the MUD URL. 218 The QRcode mechanism is usually done via paper/stickers, and is 219 typically not under the control of the device itself at all. 220 However, being applied by a human and not easily changed, a MUD URL 221 obtained in this fashion is likely trustworthy. (It may not, due to 222 mixups in labeling represent the correct device, but this is a human 223 coordination issue, and is out of scope for this document.) 225 The manufacturer can use all the four mechanisms above when 226 manufacturing the device. But when considering updating the 227 firmware, it seems like only the DHCP and LLDP mechanisms are 228 sufficiently easy to send the new MUD URL. Because of that 229 sensitivity, they may also be easily changed by malware! 231 There are mitigating mechanisms which may be enough to deal with this 232 problem when MUD files are signed by the manufacturer. 234 While [RFC8520] has established a mechanism for signing of MUD files, 235 the document does not define a way for a MUD controller to determine 236 who should sign the MUD file for a particular device. 238 [RFC8520] leaves this for a local policy. There are a number of 239 processes that could be used, but they require coordination of many 240 players. It is expected that each industrial vertical will work out 241 supply chain arrangements or other heuristics. 243 3.1. Leveraging the manufacturer signature 245 When the first time a signature of the MUD file related to a 246 particular device-type is verified by the MUD controller, the 247 identity of the signing authority is recorded. It is pinned. 248 Subsequent MUD files must be signed by the same entity in order to be 249 accepted. 251 The trust and acceptance of the first signer may come from many 252 sources, for example, it could be manual configured to trust which 253 signer, or using the IDevID mechanism for the first MUD URL and the 254 signer of the corresponding MUD file is more trustworthy, or the MUD 255 controller can use a Trust on First Use (TOFU) mechanism and trusts 256 the first signer by default. 258 Based upon this process, an update to the MUD URL would be valid if 259 the new MUD file was signed by the same entity that signed the 260 previous entry. This mechanism permits a replacement URL to be any 261 URL that the same manufacturer can provide. 263 3.2. Concerns about same-signer mechanism 265 There is still a potential threat: a manufacturer which has many 266 products may have a MUD definition for another product that has the 267 privileges that the malware desires. 269 The malware could simply change the expressed MUD URL to that of the 270 other product, and it will be accepted by the MUD controller as 271 valid. 273 This works as long as manufacturers use a single key to sign all 274 products. Some manufacturers could sign each product with a 275 different key. Going logically down this path, if all these product 276 keys are collected into a single PKI, signed by a common 277 certification authority. 279 In this case, the question then becomes whether the MUD controller 280 should pin the End-Entity (EE) certificate, or the CA certificate. 282 Pinning the End-Entity (EE) certificate defends against malware that 283 changes the product type, but keeps the manufacturer from being able 284 to cycle the validity of the End-Entity certificate for cryptographic 285 hygiene reasons. 287 Pinning the CA certificate allows the EE certificate to change, but 288 may not defend against product type changes. 290 It is possible to invent policy mechanisms that would link the EE 291 certificate to a value that is in the MUD file. This could be a 292 policy OID, or could involve some content in a subjectAltName. 293 Future work could go in this direction. This document proposes a 294 simpler solution. 296 4. Proposed mechanism 298 The document proposes to limit what MUD URLs are considered valid 299 from the device, limiting new MUD URLs to be variations of the 300 initial (presumed to be secure) URL. 302 The first MUD file which is defined for a device can come from an 303 IDevID (which is considered more secure), or via Trust on First Use 304 with DHCP or LLDP or other mechanisms. This first, initially 305 trusted, MUD file will be called the "root" MUD file. 307 A MUD file contains a self-referential MUD-URL attribute that points 308 to the MUD file itself located on the vendor's website. While the 309 IDevID, DHCP and LLDP mechanisms only transmit a URL, there are some 310 newer, not yet standardized proposals that would fetch an entire MUD 311 file from the device, such as [I-D.jimenez-t2trg-mud-coap]. 313 The MUD-URL MUST always be an Absolute URI: see [RFC3986] section 314 4.3. 316 The URL found in the MUD-URL attribute is to be called the canonical 317 MUD URL for the device. 319 The MUD-SIGNATURE attribute in the MUD file SHOULD be a relative URI 320 (see [RFC3986] section 4.2) with the (hierarchical) base URI for this 321 reference being the MUD-URL attribute. 323 Subsequent MUD files are considered valid if: 325 * they have the same initial Base-URI as the MUD-URL, but may have a 326 different final part 328 * they are signed by the same End Entity (same trusted CA and same 329 subjectAltName) as the "root" MUD file. 331 Section 5.2 of [RFC3986] details many cases for calculating the Base- 332 URI. The test is simplified to: remove everything to the right of 333 the last (rightmost) "/" in the URL of "root" MUD file URL, and the 334 proposed new URL. The resulting two strings MUST be identical. 336 For a simple example, if the "root" MUD-URL is 337 http://example.com/hello/there/file.json then any URL that starts 338 with http://example.com/hello/there/ would be acceptable, such as 339 http://example.com/hello/there/revision2.json. 341 Once the new MUD file is accepted, then it becomes the new "root" MUD 342 file, and any subsequent updates MUST be relative to the MUD-URL in 343 the new file. 345 This process allows a manufacturer to rework its file structure, to 346 change web server host names (such as when there is an acquisition or 347 merger), etc. so long as they retain the old structure long enough 348 for all devices to upgrade at least once. 350 (XXX: how should the trust anchor for the signature be updated when 351 there is Merger&Acquisition) 353 5. Privacy Considerations 355 The MUD URL contains sensitive model and even firmware revision 356 numbers. Thus the MUD URL identifies the make, model and revision of 357 a device. [RFC8520] already identifies this privacy concern, and 358 suggests use of TLS so that the HTTP requests that retrieve the MUD 359 file do not divulge that level of detail. However, it is possible 360 that even observing the traffic to that manufacturer may be 361 revealing, and [RFC8520] goes on to suggest use of a proxy as well. 363 6. Security Considerations 365 Prior to the standardization of the process in this document, if a 366 device was infiltrated by malware, and said malware wished to make 367 accesses beyond what the current MUD file allowed, the the malware 368 would have to: 370 1. arrange for an equivalent MUD file to be visible somewhere on the 371 Internet 373 2. depend upon the MUD controller either not checking signatures, or 375 3. somehow get the manufacturer to sign the alternate MUD 377 4. announce this new URL via DHCP or LLDP, updating the MUD 378 controller with the new permissions. 380 One way to accomplish (3) is to leverage the existence of MUD files 381 created by the manufacturer for different classes of devices. Such 382 files would already be signed by the same manufacturer, eliminating 383 the need to spoof a signature. 385 With the standardization of the process in this document, then the 386 attacker can no longer point to arbitrary MUD files in step 4, but 387 can only make use of MUD files that the manufacturer has already 388 provided for this device. 390 Manufacturers are advised to maintain an orderly layout of MUD files 391 in their web servers, with each unique product having its own 392 directory/pathname. 394 The process described updates only MUD controllers and the processes 395 that manufacturers use to manage the location of their MUD files. 397 A manufacturer which has not managed their MUD files in the the way 398 described here can deploy new directories of per-product MUD files, 399 and then can update the existing MUD files in place to point to the 400 new URLs using the MUD-URL attribute. 402 There is therefore no significant flag day: MUD controllers may 403 implement the new policy without significant concern about backwards 404 compatibility. 406 6.1. Updating files vs Updating MUD URLs 408 Device developers need to consider whether to make a change by 409 updating a MUD file, or updating the MUD URL. 411 MUD URLs can only be updated by shipping a new firmware. It is 412 reasonable to update the MUD URL whenever a new firmware release 413 causes new connectivity to be required. The updated mechanism 414 defined in this document makes this a secure operation, and there is 415 no practical limitation on the number of files that a web server can 416 hold. 418 In place updates to a MUD file should be restricted to cases where it 419 turns out that the description was inaccurate: a missing connection, 420 an inadvertent one authorized, or just incorrect information. 422 Developers should be aware that many enterprise web sites use 423 outsourced content distribution networks, and MUD controllers are 424 likely to cache files for some time. Changes to MUD files will take 425 some time to propagate through the various caches. An updated MUD 426 URL will however, not experience any cache issues, but can not be 427 deployed with a firmware update. 429 7. References 431 7.1. Normative References 433 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 434 Resource Identifier (URI): Generic Syntax", STD 66, 435 RFC 3986, DOI 10.17487/RFC3986, January 2005, 436 . 438 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 439 Description Specification", RFC 8520, 440 DOI 10.17487/RFC8520, March 2019, 441 . 443 7.2. Informative References 445 [boycrieswolf] 446 "The Boy Who Cried Wolf", 18 January 2020, 447 . 449 [boywolfinfosec] 450 "Security Alerts - A Case of the Boy Who Cried Wolf?", 18 451 January 2020, . 454 [falsemalware] 455 "False malware alerts cost organizations $1.27M annually, 456 report says", 18 January 2020, 457 . 461 [I-D.ietf-opsawg-mud-tls] 462 Reddy.K, T., Wing, D., and B. Anderson, "Manufacturer 463 Usage Description (MUD) (D)TLS Profiles for IoT Devices", 464 Work in Progress, Internet-Draft, draft-ietf-opsawg-mud- 465 tls-04, 17 January 2021, . 468 [I-D.jimenez-t2trg-mud-coap] 469 Jimenez, J., "Using MUD on CoAP environments", Work in 470 Progress, Internet-Draft, draft-jimenez-t2trg-mud-coap-00, 471 9 March 2020, . 474 [I-D.richardson-mud-qrcode] 475 Richardson, M., Latour, J., and H. Gharakheili, "On 476 loading MUD URLs from QR codes", Work in Progress, 477 Internet-Draft, draft-richardson-mud-qrcode-00, 17 478 December 2020, . 481 Appendix A. Appendices 483 Contributors 485 Jie Yang 487 Email: jay.yang@huawei.com 489 Tianqing Tang 491 Email: tangtianqing@huawei.com 493 Authors' Addresses 495 Michael Richardson 496 Sandelman Software Works 498 Email: mcr+ietf@sandelman.ca 500 Wei Pan 501 Huawei Technologies 503 Email: william.panwei@huawei.com 505 Eliot Lear 506 Cisco Systems 508 Email: lear@cisco.com