idnits 2.17.1 draft-richardson-opsawg-mud-acceptable-urls-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 : ---------------------------------------------------------------------------- ** 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 280: '... The MUD-URL MUST always be an Absolute URI: see [RFC3986] section...' RFC 2119 keyword, line 286: '... in the MUD file SHOULD be a relative ...' RFC 2119 keyword, line 301: '...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 (September 22, 2020) is 1312 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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) J. Yang 5 Intended status: Best Current Practice Huawei Technologies Co., Ltd. 6 Expires: March 26, 2021 E. Lear 7 Cisco Systems 8 September 22, 2020 10 Authorized update to MUD URLs 11 draft-richardson-opsawg-mud-acceptable-urls-02 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 March 26, 2021. 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. Trust on First Use (TOFU): leveraging the manufacturer 62 signature . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Concerns about same-signer mechanism . . . . . . . . . . 5 64 4. Outline of proposed mechanism . . . . . . . . . . . . . . . . 6 65 5. Changes to RFC8520 . . . . . . . . . . . . . . . . . . . . . 6 66 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 [RFC8520] provides a standardized way to describe how a specific 77 purpose device makes use of Internet resources. Access Control Lists 78 (ACLs) can be defined in an RFC8520 Manufacturer Usage Description 79 (MUD) file that permit a device to access Internet resources by DNS 80 name. 82 MUD URLs can come from a number of sources: 84 o IDevID Extensions 86 o DHCP 88 o LLDP 90 o [I-D.richardson-opsawg-securehomegateway-mud] proposes to scan 91 them from QRcodes. 93 The IDevID mechanism provides a URL that is asserted 94 cryptographically by a manufacturer. However, it is difficult for 95 manufacturers to update the IDevID of a device which is already in a 96 box. 98 The DHCP and LLDP mechanisms are not signed, but are asserted by the 99 device. A firmware update may update what MUD URL is emitted. 100 Sufficiently well targetted malware could also change the MUD URL. 102 The QRcode mechanism is usually done via paper/stickers, and is 103 typically not under the control of the device itself at all. 105 While MUD files may include signatures, it is not mandatory to check 106 them, and there is not a clear way to connect the entity which signed 107 the MUD file to the device itself. A malicious device does not need 108 to make up a MUD file if there is already an available, and already 109 trusted MUD file which it can use to impersonate the device. 111 One defense against this is to not trust MUD URLs which are different 112 from the one that was placed in an IDevID. Or if the initial MUD URL 113 was not taken from an IDevID, it could be trusted on first use. But, 114 if the MUD controller has locked down the URL, then updates to the 115 URL are difficult to do. 117 2. Updating MUD URLs vs Updating MUD files 119 2.1. Updating the MUD file in place 121 One option is for the manufacturer to never change the MUD URL due to 122 firmware updates. The published description is updated whenever the 123 behaviour of the firmware changes. 125 2.1.1. Adding capabilities 127 For situations where new capabilities are added to the firmware, the 128 MUD file will detail the new access that the new firmware requires. 129 This may involve new incoming or outgoing connections that should be 130 authorized. Devices which have been upgraded to the new firmware 131 will make use of the new features. Devices which have not been 132 upgraded to the new firmware may have new connections that are 133 authorized, but which the device does not use (outgoing connections), 134 or for which the device is not prepared to respond to (new incoming 135 connections). 137 It is possible that older versions of the firmware have 138 vulnerabilities which were not easily exploitable due to the MUD file 139 preventing particular kinds of access. As an example, an older 140 firmware could have a no credentials required (or default 141 credentials) access via telnet on port 23 or HTTP on port 80. The 142 MUD file protected the device such that it could either not be 143 accessed at all, or access was restricted to connections from a 144 controller only. 146 Useful and needed upgrades to the firmware could add credentials to 147 that service, permitting it to be opened up for more general access. 148 The new MUD file would provide for such access, but when combined 149 with the weak security of the old firmware, results in a compromised 150 device. 152 While there is an argument that old firmware was insecure and should 153 be replaced, it is often the case that the upgrade process involves 154 downttime, or can introduce risks due to needed evaluations not 155 having been completed yet. As an example: moving vehicles (cars, 156 airplanes, etc.) should not perform upgrades while in motion! It is 157 probably undesireable to perform any upgrade to an airplane outside 158 of its service facility. The owner of a vehicle may desire to only 159 perform software upgrades when they are at home, and could make other 160 arrangements for transporation, rather than when parked at a remote 161 cabin. The situation for upgrades of medical devices has even more 162 considerations involving regulatory compliance. 164 2.1.2. Removing capabilities 166 For situations where existing capabilities prove to be a problem and 167 are to be turned off or removed in subsequent versions of the 168 firmware, the MUD file will be updated to disallow connections that 169 previously were allowed. 171 In this case, the new MUD file will forbid some connection which the 172 old firmware still expects to do. As explained in the previous 173 section, upgrades may not always occur immediately upon release of 174 the new firmware. 176 In this case the old device will be performing unwanted connections, 177 and the MUD controller when be alerting the device owner that the 178 device is mis-behaving. This causes a false positive situation (see 179 [boycrieswolf]), leading to real security issues being ignored. This 180 is a serious issue as documented also in [boywolfinfosec], and 181 [falsemalware]. 183 2.1.3. Significant changes to protocols 185 [I-D.reddy-opsawg-mud-tls] suggests MUD definitions to allow 186 examination of TLS protocol details. Such a profile may be very 187 specific to the TLS library which is shipped in a device. Changes to 188 the library (including bug fixes) may cause significant changes to 189 the profile, requiring changes to the profile described in the MUD 190 file. Such changes are likely neither forward nor backward 191 compatible with other versions, and in place updates to MUD files are 192 therefore not indicated. 194 2.2. Motivation for updating MUD URLs 196 While many small tweaks to a MUD file can be done in place, the 197 situation described above, particularly when it comes to removing 198 capabilities will suggests that changes to the MUD URL. A strategy 199 is do this securely is needed, and the rest of this document provides 200 a mechanism to do this securely. 202 3. Threat model for MUD URLs 204 Only the DHCP and LLDP MUD URL mechanisms are sufficiently close to 205 the firmware version that they can be easily updated when the 206 firmware is updated. Because of that sensitivity, they may also be 207 easily changed by malware! 209 There are mitigating mechanisms which may be enough to deal with this 210 problem when MUD files are signed by the manufacturer. 212 It should be noted that [RFC8520] has not established a trust model 213 for MUD controllers to determine whether a signature from a specific 214 entity is legitimate as a signature for a particular device. 215 [RFC8520] leaves this to the industry to work out through supply 216 chain arrangements or other heuristics. 218 3.1. Trust on First Use (TOFU): leveraging the manufacturer signature 220 Many MUD controllers currently use a Trust on First Use (TOFU) 221 mechanism. The first time a signature from a particular device-type 222 is verified, the identity of the signing authority is recorded. It 223 is pinned. Subsequent updates to that MUD file must be signed by the 224 same entity in order to be accepted. 226 Based upon this process, an update to the MUD URL would be valid if 227 the new MUD file was signed by the same entity that signed the 228 previous entry. This mechanism permits a replacement URL to be any 229 URL that the same manufacturer can provide. 231 3.2. Concerns about same-signer mechanism 233 There is still a potential threat: a manufacturer which has many 234 products may have a MUD definition for another product that has the 235 privileges that the malware desires. 237 The malware could simply change the expressed MUD URL to that of the 238 other product, and it will be accepted by the MUD controller as 239 valid. 241 This works as long as manufacturers use a single key to sign all 242 products. Some manufacturers could sign each product with a 243 different key. Possibly, all the keys are collected into a single 244 PKI, signed by a common certification authority. In this case, the 245 question as to whether the MUD controller should pin the end-entity 246 (EE) certificate, or the CA certificate. Pinning the EE certificate 247 defends against malware that changes the product type, but keeps the 248 manufacturer from being able to cycle the validity of the End-Entity 249 Certificate for cryptographic hygiene reasons. Pinning the CA 250 certificate allows the EE certificate to change, but may not defend 251 against product type changes. 253 It is possible to invent policy mechanisms that would link the EE 254 certificate to a value that is in the MUD file. This could be a 255 policy OID, or could involve some content in a subjectAltName. 256 Future work could go in this direction. This document proposes a 257 simpler solution. 259 4. Outline of proposed mechanism 261 The document proposes to limit what MUD URLs are considered valid 262 from the device, limiting new MUD URLs to be variations of the 263 initial (presumed to be secure) URL. 265 5. Changes to RFC8520 267 The first MUD file which is defined for a device can come from an 268 IDevID (which is considered more secure), or via Trust on First Use 269 with DHCP or LLDP or another mechanism. 271 This first, initially trusted, MUD file will be called the "root" MUD 272 file. 274 MUD files contain a self-referential MUD-URL attribute that point to 275 a MUD file located on the vendor's web site. While the IDevID, DHCP 276 and LLDP mechanisms only transmit a URL, there are some newer, not 277 yet standardized proposals that would fetch an entire MUD file from 278 the device, such as [I-D.jimenez-t2trg-mud-coap]. 280 The MUD-URL MUST always be an Absolute URI: see [RFC3986] section 281 4.3. 283 The URL found in the MUD-URL attribute is to be called the canonical 284 MUD URL for the device. 286 The MUD-SIGNATURE attribute in the MUD file SHOULD be a relative URI 287 (see [RFC3986] section 4.2) with the (hierarchical) base URL for this 288 reference being the MUD-URL attribute. 290 Subsequent MUD files are considered valid if: 292 o have the same initial Base-URI as the MUD-URL, but may have a 293 different final part 295 o they are signed by the same End Entity (same trusted CA and same 296 SubjectAltName) as the "root" MUD file. 298 Section 5.2 of [RFC3986] details many cases for calculating the Base- 299 URI. The test is simplified to: remove everything to the right of 300 the last (rightmost) "/" in the URL of "root" MUD file URL, and the 301 proposed new URL. The resulting two strings MUST be identical. 303 For as a simple example, if the "root" mud-url is 304 http://example.com/hello/there/file.json then any URL that starts 305 with http://example.com/hello/there/ would be acceptable, such as 306 http://example.com/hello/there/revision2.json. 308 Once the new MUD file is accepted, then it becomes the new "root" MUD 309 file, and any subsequent updates must be relative to the MUD-URL in 310 the new file. 312 This process allows a manufacturer to rework their file structure, to 313 change web server hostnames (such as when there is an acquisition or 314 merger), etc. so long as they retain the old structure long enough 315 for all devices to upgrade at least once. 317 (XXX: how should the trust anchor for the signature be updated when 318 there is Merger&Acquisition) 320 6. Privacy Considerations 322 The MUD URL contains sensitive model and even firmware revision 323 numbers. Thus the MUD URL identifies the make, model and revision of 324 a device. [RFC8520] already identifies this privacy concern, and 325 suggests use of TLS so that the HTTP requests that retrieve the MUD 326 file do not divulge that level of detail. However, it is possible 327 that even observing the traffic to that manufacturer may be 328 revealing, and [RFC8520] goes on to suggest use of a proxy as well. 330 7. Security Considerations 332 Prior to the standardization of the process in this document, if a 333 device was infiltrated by malware, and said malware wished to make 334 accesses beyond what the current MUD file allowed, the the malware 335 would have to: 1. arrange for an equivalent MUD file to be visible 336 somewhere on the Internet 2. depend upon the MUD-manager either not 337 checking signatures, or 3. somehow get the manufacturer to sign the 338 alternate MUD 4. announce this new URL via DHCP or LLDP, updating the 339 MUD-manager with the new permissions. 341 One way to accomplish (3) is to leverage the existence of MUD files 342 created by the manufacturer for different classes of devices. Such 343 files would already be signed by the same manufacturer, eliminating 344 the need to spoof a signature. 346 With the standardization of the process in this document, then the 347 attacker can no longer point to arbitrary MUD files in step 4, but 348 can only make use of MUD files that the manufacturer has already 349 provided for this device. 351 Manufacturers are advised to maintain an orderly layout of MUD files 352 in their web servers, with each unique producting having its own 353 directory/pathname. 355 The process described updates only MUD-managers and the processes 356 that manufacturers use to manage the location of their MUD files. 358 A manufacturer which has not managed their MUD files in the the way 359 described here can deploy new directories of per-product MUD files, 360 and then can update the existing MUD files in place to point to the 361 new URLs using the MUD-URL attribute. 363 There is therefore no significant flag day: MUD managers may 364 implement the new policy without significant concern about backwards 365 compatibility. 367 8. References 369 8.1. Normative References 371 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 372 Resource Identifier (URI): Generic Syntax", STD 66, 373 RFC 3986, DOI 10.17487/RFC3986, January 2005, 374 . 376 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 377 Description Specification", RFC 8520, 378 DOI 10.17487/RFC8520, March 2019, 379 . 381 8.2. Informative References 383 [boycrieswolf] 384 "The Boy Who Cried Wolf", January 2020, 385 . 387 [boywolfinfosec] 388 "Security Alerts - A Case of the Boy Who Cried Wolf?", 389 January 2020, . 392 [falsemalware] 393 "False malware alerts cost organizations $1.27M annually, 394 report says", January 2020, 395 . 399 [I-D.jimenez-t2trg-mud-coap] 400 Jimenez, J., "Using MUD on CoAP environments", draft- 401 jimenez-t2trg-mud-coap-00 (work in progress), March 2020. 403 [I-D.reddy-opsawg-mud-tls] 404 Reddy.K, T., Wing, D., and B. Anderson, "MUD (D)TLS 405 profiles for IoT devices", draft-reddy-opsawg-mud-tls-05 406 (work in progress), August 2020. 408 [I-D.richardson-opsawg-securehomegateway-mud] 409 Richardson, M., Latour, J., and H. Gharakheili, "On 410 loading MUD URLs from QR codes", draft-richardson-opsawg- 411 securehomegateway-mud-05 (work in progress), September 412 2020. 414 Appendix A. Appendices 416 Authors' Addresses 418 Michael Richardson 419 Sandelman Software Works 421 Email: mcr+ietf@sandelman.ca 422 Jie Yang 423 Huawei Technologies Co., Ltd. 425 Email: jay.yang@huawei.com 427 Eliot Lear 428 Cisco Systems 430 Email: lear@cisco.com