idnits 2.17.1 draft-ietf-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 303: '... The MUD-URL MUST always be an Absolute URI: see [RFC3986] section...' RFC 2119 keyword, line 309: '... in the MUD file SHOULD be a relative ...' RFC 2119 keyword, line 324: '...sulting two strings MUST be identical....' RFC 2119 keyword, line 332: '...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 (1 February 2021) is 1173 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 (-07) exists of draft-richardson-mud-qrcode-00 Summary: 2 errors (**), 0 flaws (~~), 2 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: 5 August 2021 E. Lear 7 Cisco Systems 8 1 February 2021 10 Authorized update to MUD URLs 11 draft-ietf-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 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 5 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 MUD URLs vs Updating MUD files . . . . . . . . . . . 3 57 2.1. Updating the MUD file in place . . . . . . . . . . . . . 3 58 2.1.1. Adding capabilities . . . . . . . . . . . . . . . . . 4 59 2.1.2. Removing capabilities . . . . . . . . . . . . . . . . 4 60 2.1.3. Significant changes to protocols . . . . . . . . . . 5 61 2.2. Motivation for updating MUD URLs . . . . . . . . . . . . 5 62 3. Threat model for MUD URLs . . . . . . . . . . . . . . . . . . 5 63 3.1. Trust on First Use (TOFU): leveraging the manufacturer 64 signature . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Concerns about same-signer mechanism . . . . . . . . . . 6 66 4. Outline of proposed mechanism . . . . . . . . . . . . . . . . 7 67 5. Changes to RFC8520 . . . . . . . . . . . . . . . . . . . . . 7 68 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7.1. Updating files vs Updating MUD URLs . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 11 75 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 [RFC8520] provides a standardized way to describe how a specific 81 purpose device makes use of Internet resources and associated 82 suggested network behavior, which are describled in a MUD file hosted 83 in its manufacture's server. By providing a MUD URL, the network 84 manager can locate this MUD file. MUD URLs can come from a number of 85 sources: 87 * IDevID Extensions 89 * DHCP option 91 * LLDP TLV 93 * [I-D.richardson-mud-qrcode] proposes to scan them from QRcodes. 95 The IDevID mechanism provides a URL that is asserted 96 cryptographically by a manufacturer. However, it is difficult for 97 manufacturers to update the IDevID of a device which is already in a 98 box. 100 The DHCP and LLDP mechanisms are not signed, but are asserted by the 101 device. A firmware update may update what MUD URL is emitted. 102 Sufficiently well targetted malware could also change the MUD URL. 104 The QRcode mechanism is usually done via paper/stickers, and is 105 typically not under the control of the device itself at all. 106 However, being applied by a human and not easily changed, a MUD URL 107 obtained in this fashion is likely trustworthy. (It may not, due to 108 mixups in labelling represent the correct device, but this is a human 109 coordination issue, and is out of scope for this document) 111 While MUD files may include signatures, [RFC8520] does not mandate 112 checking them, and there is not a clear way to connect the entity 113 which signed the MUD file to the device itself. 115 This document limits itself to situations in which the MUD file is 116 signed, and that the MUD controller has been configured to always 117 check the signatures, rejecting files whose signatures do not match. 119 [RFC8520] does not specify how MUD controllers establish their trust 120 in the manufacturers' signing key: there are many possible solutions 121 from manual configuration of trust anchors, some kind of automatic 122 configuration during onboarding, but also including to Trust on First 123 Use (TOFU). How this initial trust is established is not important 124 for this document, it is sufficient that some satisfactory initial 125 trust is established. 127 2. Updating MUD URLs vs Updating MUD files 129 There are two ways in which a manufacturer can change what the is 130 processed by the MUD controller: they can change what is in the MUD 131 file (update-in-place), and or they change which file is processed by 132 the MUD controller by changing the URL (updated-url). 134 2.1. Updating the MUD file in place 136 One option is for the manufacturer to never change the MUD URL due to 137 firmware updates. The published description is updated whenever the 138 behaviour of the firmware changes. 140 2.1.1. Adding capabilities 142 For situations where new capabilities are added to the firmware, the 143 MUD file will detail the new access that the new firmware requires. 144 This may involve new incoming or outgoing connections that should be 145 authorized. Devices which have been upgraded to the new firmware 146 will make use of the new features. Devices which have not been 147 upgraded to the new firmware may have new connections that are 148 authorized, but which the device does not use (outgoing connections), 149 or for which the device is not prepared to respond to (new incoming 150 connections). 152 It is possible that older versions of the firmware have 153 vulnerabilities which were not easily exploitable due to the MUD file 154 preventing particular kinds of access. As an example, an older 155 firmware could have a no credentials required (or default 156 credentials) access via telnet on port 23 or HTTP on port 80. The 157 MUD file protected the device such that it could either not be 158 accessed at all, or access was restricted to connections from a 159 controller only. 161 Useful and needed upgrades to the firmware could add credentials to 162 that service, permitting it to be opened up for more general access. 163 The new MUD file would provide for such access, but when combined 164 with the weak security of the old firmware, results in a compromised 165 device. 167 While there is an argument that old firmware was insecure and should 168 be replaced, it is often the case that the upgrade process involves 169 downtime, or can introduce risks due to needed evaluations not having 170 been completed yet. As an example: moving vehicles (cars, airplanes, 171 etc.) should not perform upgrades while in motion! It is probably 172 undesireable to perform any upgrade to an airplane outside of its 173 service facility. The owner of a vehicle may desire to only perform 174 software upgrades when they are at home, and could make other 175 arrangements for transporation, rather than when parked at a remote 176 cabin. The situation for upgrades of medical devices has even more 177 considerations involving regulatory compliance. 179 2.1.2. Removing capabilities 181 For situations where existing capabilities prove to be a problem and 182 are to be turned off or removed in subsequent versions of the 183 firmware, the MUD file will be updated to disallow connections that 184 previously were allowed. 186 In this case, the new MUD file will forbid some connection which the 187 old firmware still expects to do. As explained in the previous 188 section, upgrades may not always occur immediately upon release of 189 the new firmware. 191 In this case the old device will be performing unwanted connections, 192 and the MUD controller will then send alerts to the network owner 193 that the device is mis-behaving. This causes a false positive 194 situation (see [boycrieswolf]), leading to real security issues being 195 ignored. This is a serious issue as documented also in 196 [boywolfinfosec], and [falsemalware]. 198 2.1.3. Significant changes to protocols 200 [I-D.reddy-opsawg-mud-tls] suggests MUD definitions to allow 201 examination of TLS protocol details. Such a profile may be very 202 specific to the TLS library which is shipped in a device. Changes to 203 the library (including bug fixes) may cause significant changes to 204 the profile, requiring changes to the profile described in the MUD 205 file. Such changes are likely neither forward nor backward 206 compatible with other versions, and in place updates to MUD files are 207 therefore not indicated. 209 2.2. Motivation for updating MUD URLs 211 While many small tweaks to a MUD file can be done in place, the 212 situation described above, particularly when it comes to removing 213 capabilities will suggests that changes to the MUD URL. A strategy 214 for doing this securely is needed, and the rest of this document 215 provides a mechanism to do this securely. 217 3. Threat model for MUD URLs 219 Only the DHCP and LLDP MUD URL mechanisms are sufficiently close to 220 the firmware version that they can be easily updated when the 221 firmware is updated. Because of that sensitivity, they may also be 222 easily changed by malware! 224 There are mitigating mechanisms which may be enough to deal with this 225 problem when MUD files are signed by the manufacturer. 227 While [RFC8520] has established a mechanism for signing of MUD files, 228 the document does not define a way for a MUD controller to determine 229 who should sign the MUD file for a particular device. 231 [RFC8520] leaves this for a local policy. There are any number of 232 processes that could be used, but they require coordination of many 233 players. It is expected that each industrial vertical will work out 234 supply chain arrangements or other heuristics. 236 3.1. Trust on First Use (TOFU): leveraging the manufacturer signature 238 Many MUD controllers currently use a Trust on First Use (TOFU) 239 mechanism. The first time a signature from a particular device-type 240 is verified, the identity of the signing authority is recorded. It 241 is pinned. Subsequent updates to that MUD file must be signed by the 242 same entity in order to be accepted. 244 Based upon this process, an update to the MUD URL would be valid if 245 the new MUD file was signed by the same entity that signed the 246 previous entry. This mechanism permits a replacement URL to be any 247 URL that the same manufacturer can provide. 249 3.2. Concerns about same-signer mechanism 251 There is still a potential threat: a manufacturer which has many 252 products may have a MUD definition for another product that has the 253 privileges that the malware desires. 255 The malware could simply change the expressed MUD URL to that of the 256 other product, and it will be accepted by the MUD controller as 257 valid. 259 This works as long as manufacturers use a single key to sign all 260 products. Some manufacturers could sign each product with a 261 different key. Going logically down this path, if all these product 262 keys are collected into a single PKI, signed by a common 263 certification authority. 265 In this case, the question then becomes whether the MUD controller 266 should pin the end-entity (EE) certificate, or the CA certificate. 268 Pinning the EE certificate defends against malware that changes the 269 product type, but keeps the manufacturer from being able to cycle the 270 validity of the End-Entity Certificate for cryptographic hygiene 271 reasons. 273 Pinning the CA certificate allows the EE certificate to change, but 274 may not defend against product type changes. 276 It is possible to invent policy mechanisms that would link the EE 277 certificate to a value that is in the MUD file. This could be a 278 policy OID, or could involve some content in a subjectAltName. 279 Future work could go in this direction. This document proposes a 280 simpler solution. 282 4. Outline of proposed mechanism 284 The document proposes to limit what MUD URLs are considered valid 285 from the device, limiting new MUD URLs to be variations of the 286 initial (presumed to be secure) URL. 288 5. Changes to RFC8520 290 The first MUD file which is defined for a device can come from an 291 IDevID (which is considered more secure), or via Trust on First Use 292 with DHCP or LLDP or another mechanism. 294 This first, initially trusted, MUD file will be called the "root" MUD 295 file. 297 MUD files contain a self-referential MUD-URL attribute that point to 298 a MUD file located on the vendor's web site. While the IDevID, DHCP 299 and LLDP mechanisms only transmit a URL, there are some newer, not 300 yet standardized proposals that would fetch an entire MUD file from 301 the device, such as [I-D.jimenez-t2trg-mud-coap]. 303 The MUD-URL MUST always be an Absolute URI: see [RFC3986] section 304 4.3. 306 The URL found in the MUD-URL attribute is to be called the canonical 307 MUD URL for the device. 309 The MUD-SIGNATURE attribute in the MUD file SHOULD be a relative URI 310 (see [RFC3986] section 4.2) with the (hierarchical) base URL for this 311 reference being the MUD-URL attribute. 313 Subsequent MUD files are considered valid if: 315 * have the same initial Base-URI as the MUD-URL, but may have a 316 different final part 318 * they are signed by the same End Entity (same trusted CA and same 319 SubjectAltName) as the "root" MUD file. 321 Section 5.2 of [RFC3986] details many cases for calculating the Base- 322 URI. The test is simplified to: remove everything to the right of 323 the last (rightmost) "/" in the URL of "root" MUD file URL, and the 324 proposed new URL. The resulting two strings MUST be identical. 326 For as a simple example, if the "root" mud-url is 327 http://example.com/hello/there/file.json then any URL that starts 328 with http://example.com/hello/there/ would be acceptable, such as 329 http://example.com/hello/there/revision2.json. 331 Once the new MUD file is accepted, then it becomes the new "root" MUD 332 file, and any subsequent updates MUST be relative to the MUD-URL in 333 the new file. 335 This process allows a manufacturer to rework their file structure, to 336 change web server hostnames (such as when there is an acquisition or 337 merger), etc. so long as they retain the old structure long enough 338 for all devices to upgrade at least once. 340 (XXX: how should the trust anchor for the signature be updated when 341 there is Merger&Acquisition) 343 6. Privacy Considerations 345 The MUD URL contains sensitive model and even firmware revision 346 numbers. Thus the MUD URL identifies the make, model and revision of 347 a device. [RFC8520] already identifies this privacy concern, and 348 suggests use of TLS so that the HTTP requests that retrieve the MUD 349 file do not divulge that level of detail. However, it is possible 350 that even observing the traffic to that manufacturer may be 351 revealing, and [RFC8520] goes on to suggest use of a proxy as well. 353 7. Security Considerations 355 Prior to the standardization of the process in this document, if a 356 device was infiltrated by malware, and said malware wished to make 357 accesses beyond what the current MUD file allowed, the the malware 358 would have to: 360 1. arrange for an equivalent MUD file to be visible somewhere on the 361 Internet 363 2. depend upon the MUD controller either not checking signatures, or 365 3. somehow get the manufacturer to sign the alternate MUD 367 4. announce this new URL via DHCP or LLDP, updating the MUD 368 controller with the new permissions. 370 One way to accomplish (3) is to leverage the existence of MUD files 371 created by the manufacturer for different classes of devices. Such 372 files would already be signed by the same manufacturer, eliminating 373 the need to spoof a signature. 375 With the standardization of the process in this document, then the 376 attacker can no longer point to arbitrary MUD files in step 4, but 377 can only make use of MUD files that the manufacturer has already 378 provided for this device. 380 Manufacturers are advised to maintain an orderly layout of MUD files 381 in their web servers, with each unique producting having its own 382 directory/pathname. 384 The process described updates only MUD controllers and the processes 385 that manufacturers use to manage the location of their MUD files. 387 A manufacturer which has not managed their MUD files in the the way 388 described here can deploy new directories of per-product MUD files, 389 and then can update the existing MUD files in place to point to the 390 new URLs using the MUD-URL attribute. 392 There is therefore no significant flag day: MUD managers may 393 implement the new policy without significant concern about backwards 394 compatibility. 396 7.1. Updating files vs Updating MUD URLs 398 Device developers need to consider whether to make a change by 399 updating a MUD file, or updating the MUD URL. 401 MUD URLs can only be updated by shipping a new firmware. It is 402 reasonable to update the MUD URL whenever a new firmware release 403 causes new connectivity to be required. The updated mechanism 404 defined in this document makes this a secure operation, and there is 405 no practical limitation on the number of files that a web server can 406 hold. 408 In place updates to a MUD file should be restricted to cases where it 409 turns out that the description was inaccurate: a missing connection, 410 an inadvertent one authorized, or just incorrect information. 412 Developers should be aware that many enterprise web sites use 413 outsourced content distribution networks, and MUD controllers are 414 likely to cache files for some time. Changes to MUD files will take 415 some time to propogate through the various caches. An updated MUD 416 URL will however, not experience any cache issues, but can not be 417 deployed with a firmware update. 419 8. References 421 8.1. Normative References 423 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 424 Resource Identifier (URI): Generic Syntax", STD 66, 425 RFC 3986, DOI 10.17487/RFC3986, January 2005, 426 . 428 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 429 Description Specification", RFC 8520, 430 DOI 10.17487/RFC8520, March 2019, 431 . 433 8.2. Informative References 435 [boycrieswolf] 436 "The Boy Who Cried Wolf", 18 January 2020, 437 . 439 [boywolfinfosec] 440 "Security Alerts - A Case of the Boy Who Cried Wolf?", 18 441 January 2020, . 444 [falsemalware] 445 "False malware alerts cost organizations $1.27M annually, 446 report says", 18 January 2020, 447 . 451 [I-D.jimenez-t2trg-mud-coap] 452 Jimenez, J., "Using MUD on CoAP environments", Work in 453 Progress, Internet-Draft, draft-jimenez-t2trg-mud-coap-00, 454 9 March 2020, . 457 [I-D.reddy-opsawg-mud-tls] 458 Reddy.K, T., Wing, D., and B. Anderson, "MUD (D)TLS 459 profiles for IoT devices", Work in Progress, Internet- 460 Draft, draft-reddy-opsawg-mud-tls-05, 31 August 2020, 461 . 464 [I-D.richardson-mud-qrcode] 465 Richardson, M., Latour, J., and H. Gharakheili, "On 466 loading MUD URLs from QR codes", Work in Progress, 467 Internet-Draft, draft-richardson-mud-qrcode-00, 17 468 December 2020, . 471 Appendix A. Appendices 473 Contributors 475 Tianqing Tang 477 Email: tangtianqing@huawei.com 479 Authors' Addresses 481 Michael Richardson 482 Sandelman Software Works 484 Email: mcr+ietf@sandelman.ca 486 Wei Pan 487 Huawei Technologies 489 Email: william.panwei@huawei.com 491 Eliot Lear 492 Cisco Systems 494 Email: lear@cisco.com