idnits 2.17.1 draft-richardson-shg-un-quarantine-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 19, 2019) is 1705 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) == Missing Reference: 'THISDOCUMENT' is mentioned on line 473, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-capport-api-03 == Outdated reference: A later version (-10) exists of draft-ietf-capport-architecture-04 ** Downref: Normative reference to an Informational draft: draft-ietf-capport-architecture (ref. 'I-D.ietf-capport-architecture') ** Obsolete normative reference: RFC 7710 (Obsoleted by RFC 8910) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-24 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-03 == Outdated reference: A later version (-02) exists of draft-richardson-shg-mud-quarantined-access-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RIPE IoT Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Best Current Practice J. Latour 5 Expires: February 20, 2020 CIRA Labs 6 August 19, 2019 8 A standard process to quarantine and restore IoT Devices 9 draft-richardson-shg-un-quarantine-01 11 Abstract 13 The Manufacturer Usage Description (MUD) is a tool to describe the 14 limited access that a single function device such as an Internet of 15 Things device might need. The enforcement of the access control 16 lists described protects the device from attacks from the Internet, 17 and protects the Internets from compromised devices. 19 This document details the process which occurs when a device is 20 detected to have violated the stated policy. The goal of these steps 21 is to ensure that the device is correctly removed from operation, 22 fixed, and if possible, restored to safe operation. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 20, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. An overview of the stages of activity . . . . . . . . . . 4 61 2. Detailed description of states . . . . . . . . . . . . . . . 5 62 2.1. New device . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Nominal . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.2.1. Use of Captive Portal API . . . . . . . . . . . . . . 6 65 2.3. Suspicious . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Suspect . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.5. Device of Interest . . . . . . . . . . . . . . . . . . . 7 68 2.6. Quarantined . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.7. Disabled . . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.8. Returning to Service . . . . . . . . . . . . . . . . . . 8 71 2.9. Owned by malicious entity ("p0wned") . . . . . . . . . . 8 72 3. Detailed description of transitions . . . . . . . . . . . . . 8 73 3.1. Initial Enrollment . . . . . . . . . . . . . . . . . . . 9 74 3.2. Re-enrollment . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2.1. factory-default re-enrollment . . . . . . . . . . . . 9 76 3.2.2. simple re-enrollment . . . . . . . . . . . . . . . . 9 77 3.2.3. other kinds? . . . . . . . . . . . . . . . . . . . . 9 78 3.3. Initial suspicion . . . . . . . . . . . . . . . . . . . . 10 79 3.4. Confirmed suspicion . . . . . . . . . . . . . . . . . . . 10 80 3.5. Device identified as attack target . . . . . . . . . . . 10 81 3.6. Suspension of connectivity . . . . . . . . . . . . . . . 10 82 3.7. Re-Installation of valid firmware . . . . . . . . . . . . 10 83 4. An example process . . . . . . . . . . . . . . . . . . . . . 10 84 5. Human Rights Considerations . . . . . . . . . . . . . . . . . 10 85 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 8.1. Captive Portal API JSON keys . . . . . . . . . . . . . . 11 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 10.2. Informative References . . . . . . . . . . . . . . . . . 11 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 95 1. Introduction 97 [RFC8520] describes the format of the Manufacturer Usage Description 98 (MUD) files. MUD files provide a set of network Access Control Lists 99 (ACL, pronounced [ak-uhl]) that describes the expected traffic from a 100 device, such as an Internet of Things (IoT) device. 102 MUD files are used in a number of projects, including the CIRALabs' 103 [SecureHomeGateway] (SHG) project. In this project a home gateway 104 ("router") is enhanced to be able to use MUD files to describe the 105 traffic expected from all connected devices. If a device does not 106 have a MUD format description, then the project can provide a broad 107 set of traffic expectations based upon categorization of the device 108 by the home owner. 110 This document is about the process to be followed when a device is 111 observed to be violating the ACLs applied to it. While this document 112 will identify network protocols (and gaps where no protocol exists) 113 as appropriate, the goal of this document is more about the human 114 process. Specifically, who gets called, and in what order. Who 115 makes each call, and how are they identified. 117 In addition, what kind of data needs to be shared among the parties 118 and what are the privacy and human rights implications of sharing the 119 required data. 121 Finally, in the security considerations section of this document some 122 concerns about prevention of so-called "SWAT"ing ({swatting}), where 123 an attempt might be made to take a location or network offline 124 through phony reports. 126 1.1. Terminology 128 This document is not a protocol specification, but rather a Best 129 Current Practices in the area of human operations. While this is 130 sometimes called a "Standard Operating Proceedure" (SOP), this 131 document should not be considered the actual SOP for an organization, 132 but rather be referrenced. 134 The terminology [RFC2119] the key words such as "MUST", "MUST NOT", 135 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 136 "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 137 described in BCP 14, RFC 2119. In the context of this human 138 protocol, they do not describe network protocol interoperability 139 requirements, but rather constraints upon how the humans need to 140 operate in order to avoid unsafe situations. 142 The following terms are used in this document: 144 o owner's network: the network belonging to the owner of the device. 145 In residentical situations, this is typically the home owner. In 146 commercial environments, this may be the owner of the building, or 147 the commercial tenant in the building. 149 o tenant: one or more people who occupy a space in which a network 150 of devices exists which do not belong directly to them. 152 1.2. An overview of the stages of activity 154 This section provides a brief overview of the states that a device 155 may be in. The following section provides a detailed description of 156 the state. This document is primarily about how a device transitions 157 from one state to another, which is covered in {#transitions}. 159 .--------. .---------.<---------.------------. 160 | new |-------->| nominal | | suspicious | 161 | device |\ .----->| | -------->| | 162 '--------' \| '---------' '------------' 163 \ | | 164 |\ | | 165 | \ | | 166 | \ v v 167 | \ .------------. .------------. 168 .------------.| v| p0owned | | device-of | 169 | returning || | | | interest | 170 | to service | '------------' '------------' 171 '------------' | | 172 ^ | | 173 | v v 174 .------------. .------------. .-----------. 175 | upgrading | | quarantine | | suspect | 176 | |<-----| |<------| | 177 '------------' '------------' '-----------' 179 Figure 1: Device Connectivity States 181 o new device: a device that has just been "connected" to the 182 network. 184 o nominal: a device which is operating correctly. 186 o suspicious: a device which has once gone out of it's MUD profile. 188 o suspect: a device which has repeatedly gone out of it's MUD 189 profile. 191 o device-of-interest: a device that is part of a class of devices 192 which is considered suspect. 194 o quarantined: a device which has been isolated into a network 195 "segment", it may stil be operating locally. 197 o disabled: a device which has been disconnected from the network, 198 and has also had mains power removed. The device is believed to 199 be off. 201 o upgrading: a device which is active for the purpose of having new 202 firmware installed. 204 o returning-to-service: a device which has new firmware, and is 205 going through a re-enrollment process. It may still lack critical 206 configuration, and may be unable to yet perform critical 207 functions. 209 o p0wned: a device which is known to have malicious routines 210 running, but is still connected to the network. It may continue 211 to provide the services the device was designed to do, in 212 additional to performing functions controlled by an unauthorized 213 entity. 215 2. Detailed description of states 217 A device is considered to be on one of the above states. The device 218 is not considered to be aware of it's state, rather this is a 219 characteristic that the network assigns to the device. 221 2.1. New device 223 A device newly installed will have no initial network connectivity. 224 It will be awaiting some kind of enrollment or onboarding process. 225 Examples of enrollment processes include 226 [I-D.ietf-anima-bootstrapping-keyinfra], [dpp], processes defined by 227 The Thread Group and Apple Homekit, as well as a great number of 228 custom and proprietary methods. 230 In many cases the device may provide limited network connectivity 231 (such as by running as an Access Point), and can be reached by 232 attackers. The owner of the device may in fact in unaware that the 233 device is "smart", and it may be possible for a device to become 234 compromised without ever having joined a network. This case is 235 particularly difficult, as having never joined a network, the device 236 will not emit signals on the owner's network that can be detected to 237 notice that the device has been attacked. Also, having never been 238 connected, the device is more likely to have old firmware. 240 2.2. Nominal 242 The device is operating normally and is not suspected to be corrupted 243 or under attack. 245 2.2.1. Use of Captive Portal API 247 In preperation for possible quarantine, the DHCP and RA options 248 defined in [RFC7710] and referenced by 249 [I-D.ietf-capport-architecture] (section 2.2.1) SHOULD be recorded if 250 present for later use. 252 An additional captive portal API key "quarantine", if having the true 253 value indicates that the device is not connected to the Internet for 254 security reasons. The existing key "captive" ([I-D.ietf-capport-api] 255 section 4.2) SHOULD also be checked, as the device MAY be subject to 256 a captive portal. 258 Based upon policy, it is appropriate for a MUD controller to put a 259 new device into a captive portal state until such time as inclusion 260 into the operational part of the network has been approved by a human 261 operator. The state should be "captive", but not "quarantined". 263 2.3. Suspicious 265 The device and/or the Internet has attempted a connection which is 266 forbidden by the MUD file. This activity is notable, but 267 particularly in the case where a MUD file was generated by a third 268 party (such as by a period of observation), it may signal that the 269 MUD file is inaccurate rather than that the device is compromised. 271 In the case of connections that originate from the Internet to the 272 device which are forbidden, this may indicate that device is being 273 scanned for, but that the security features of the router are 274 resisting the attack. 276 It is unclear how a device is returned from suspicious state to 277 nominal. A reasonable process might be that after a period of time 278 in which no new unwanted activity occurs it is returned. A clear 279 indication that it should return to nomimal is if a new MUD file is 280 applied to the device. 282 2.4. Suspect 284 The device is repeatedly attempting to connect to core infrastructure 285 which it has reasonably no reason to connect to. Examples of this 286 would include connecting to many IP addresses in a sequential or 287 high-frequency rate, connecting to well-known ports not intended to 288 for end devices (for instance TCP port 22, 23, 25). There might 289 still be a reasonable explanation for this behaviour, including that 290 the "inside" IP address has been reassigned to a different device 291 (such as desktop computer). 293 IPFIX is a candidate protocol for a MUD controller to inform an ISP 294 about 296 2.5. Device of Interest 298 A device has become interesting based upon two possible situations: 299 an internal signal that a device has become suspected, and based upon 300 external indications that there are active threats against the 301 device. A device in this state SHOULD go into quarantine upon the 302 next observed attack. 304 If it can be observed that there are DNS spoofing attempts against 305 the device manufacturer's firmware repository, or it's command/ 306 control channel (for devices which have cloud connections), then it 307 would be reasonable to become interested in the device: an attack may 308 be coming. 310 A device under interest would continue to be able to perform it's 311 normal functions. For instance, a furnace would continue to heat the 312 house, and would continue to report it's statistics to it's 313 manufacturer/service-entity, and would continue to respond to 314 thermostat changes. 316 2.6. Quarantined 318 A device in quarantine gets no Internet access. 320 Devices in quarantine MAY use the API defined by 321 [I-D.ietf-capport-architecture] to determine if the device has been 322 quarantined. Devices which can display this information visually 323 SHOULD do so, such as on a status LCD display, or by a unique color 324 scheme for status LEDs. 326 A device in quarantine MAY do DNS requests to the local recursive DNS 327 resolvers for the IP address of it's firmware repository. This 328 address would be present in the device's MUD file using the 329 [I-D.richardson-shg-mud-quarantined-access]. Access to the firmware 330 repository is important to permit the device to apply new firmware 331 and/or reset itself to factory default. 333 A device in quarantine that performs other functions might continue 334 to be perform those functions. For instance, a fridge would remain 335 cold, but it would not respond to thermostat changes, or communicate 336 with a grocery store. 338 2.7. Disabled 340 A device that is disabled gets no network connectivity at all, 341 including no local network connectivity. 343 A device that is directly mains powered would be disconnected by a 344 human. A device that is powered by Power-over-Ethernet could be 345 disconnected by administratively turning power off on that port. 347 A device that is battery powered or scavanges power would remain on 348 as long as it had power. 350 2.8. Returning to Service 352 A device that is attempting to return to service has installed some 353 "fix" for the issue that lead it to be quarantined. It could also be 354 the case that the device did not need to anything, and that the 355 quarantine was a false positive, and a new MUD file is loaded with 356 the additionally accepted patterns. 358 A device returning to service MAY have erased all it's network 359 settings, and will have to go through some form of network enrollment 360 again. 362 2.9. Owned by malicious entity ("p0wned") 364 A device which is known to be controlled by a malicious entity. It 365 may be impossible to quarantine the device if it performs some 366 critical function and the imposition of quarantine would prevent 367 that. 369 3. Detailed description of transitions 371 This section deals with the transitions between states. These 372 transitions occur as a result of network and/or human signaling. The 373 occurance of these transitions will in most cases cause a signal to 374 be sent. 376 3.1. Initial Enrollment 378 The process of enrollment is out of scope for this document. 380 3.2. Re-enrollment 382 The process of re-enrollment is out of scope for this document. This 383 document does specify when this re-enrollment can take place, and how 384 a human can indicate to a device and to the network infrastructure 385 that re-enrollment can take place. 387 Re-enrollment can occur a number of different ways. 389 3.2.1. factory-default re-enrollment 391 A device can re-enroll in a factory-default state. This means that 392 all settings are lost and any private keys that might have been 393 visible to malicious code/coders who may have had access to the 394 device have are regenerated. 396 Devices that store private keys in Trusted Platform Modules (TPM), or 397 in Trusted Execution Environments (see [I-D.ietf-teep-architecture]) 398 could reasonably assume that private keys may be retained. From an 399 802.1AR perspective, the IDevID may be assumed to be intact, but the 400 integrity of the LDevID may be suspect. 402 As the device is in a factory-default state it will have no user/ 403 owner-specific configuration, and any authorization lists will need 404 to be re-established! 406 3.2.2. simple re-enrollment 408 The device does not return to a factory-default state, and has 409 existing network, owner credentials and configuration intact. A 410 network onboarding will need to be repeated to establish new per- 411 device network keys. 413 An audit of the device authorizations SHOULD be done, as an attacker 414 may have inserted additional authorizations in order to return. 416 3.2.3. other kinds? 418 Are there states in between these two extremes? 420 3.3. Initial suspicion 422 The transition from nomimal to initial suspicion occurs when the MUD 423 firewall detects (and blocks) network not described in the device 424 MUD. There are a number of non-critical reasons why this could 425 occur. 427 The mostly likely situation is that the MUD describes access rules 428 using DNS names, while the firewall is implemented in terms of IP 429 addresses. The name to IP mapping may well have changed, and the 430 firewall has not yet caught up to the new mapping. 432 3.4. Confirmed suspicion 434 TBD 436 3.5. Device identified as attack target 438 TBD 440 3.6. Suspension of connectivity 442 TBD 444 3.7. Re-Installation of valid firmware 446 TBD 448 4. An example process 450 Here will be somes examples of a device. 452 5. Human Rights Considerations 454 TBD 456 6. Privacy Considerations 458 TBD 460 7. Security Considerations 462 TBD 464 8. IANA Considerations 466 8.1. Captive Portal API JSON keys 468 A new JSON key for [I-D.ietf-capport-api]'s "Captive Portal API Keys" 469 is to be registred with the following values: 471 key: "quarantine" 472 type: "boolean" 473 description: [THISDOCUMENT] specifies that the quarantine key should be 474 marked true if the device has had its Internet access 475 revoked due to violation of an RFF8520 (MUD) profile. 477 9. Acknowledgements 479 10. References 481 10.1. Normative References 483 [I-D.ietf-capport-api] 484 Pauly, T. and D. Thakore, "Captive Portal API", draft- 485 ietf-capport-api-03 (work in progress), July 2019. 487 [I-D.ietf-capport-architecture] 488 Larose, K. and D. Dolson, "CAPPORT Architecture", draft- 489 ietf-capport-architecture-04 (work in progress), June 490 2019. 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, 494 DOI 10.17487/RFC2119, March 1997, 495 . 497 [RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng, 498 "Captive-Portal Identification Using DHCP or Router 499 Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710, 500 December 2015, . 502 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 503 Description Specification", RFC 8520, 504 DOI 10.17487/RFC8520, March 2019, 505 . 507 10.2. Informative References 509 [dpp] "Device Provisioning Protocol Specification", n.d., 510 . 514 [I-D.ietf-anima-bootstrapping-keyinfra] 515 Pritikin, M., Richardson, M., Behringer, M., and K. 516 Watsen, "Bootstrapping Remote Secure Key Infrastructures 517 (BRSKI)", draft-ietf-anima-bootstrapping-keyinfra-24 (work 518 in progress), July 2019. 520 [I-D.ietf-teep-architecture] 521 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 522 Liu, "Trusted Execution Environment Provisioning (TEEP) 523 Architecture", draft-ietf-teep-architecture-03 (work in 524 progress), July 2019. 526 [I-D.richardson-shg-mud-quarantined-access] 527 Richardson, M. and M. Ranganathan, "Manufacturer Usuage 528 Description for quarantined access to firmware", draft- 529 richardson-shg-mud-quarantined-access-01 (work in 530 progress), July 2019. 532 [looneytunes] 533 "List of Looney Tunes Cartoons", n.d., 534 . 537 [SecureHomeGateway] 538 "CIRALabs Secure Home Gateway", n.d., 539 . 541 [swatting] 542 "Cambridge English Dictionary: swatting", January 2019, 543 . 546 Authors' Addresses 548 Michael Richardson 549 Sandelman Software Works 551 Email: mcr+ietf@sandelman.ca 552 Jacques Latour 553 CIRA Labs 555 Email: Jacques.Latour@cira.ca