idnits 2.17.1 draft-richardson-shg-un-quarantine-00.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 (February 13, 2019) is 1898 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-18 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-01 == Outdated reference: A later version (-02) exists of draft-richardson-shg-mud-quarantined-access-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track J. Latour 5 Expires: August 17, 2019 CIRA Labs 6 February 13, 2019 8 A standard process to quarantine and restore IoT Devices 9 draft-richardson-shg-un-quarantine-00 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 August 17, 2019. 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.3. Suspicious . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Suspect . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.5. Device of Interest . . . . . . . . . . . . . . . . . . . 6 67 2.6. Quarantined . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.7. Disabled . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.8. Returning to Service . . . . . . . . . . . . . . . . . . 7 70 2.9. Owned by malicious entity ("p0wned") . . . . . . . . . . 8 71 3. Detailed description of transitions . . . . . . . . . . . . . 8 72 3.1. Initial Enrollment . . . . . . . . . . . . . . . . . . . 8 73 3.2. Re-enrollment . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2.1. factory-default re-enrollment . . . . . . . . . . . . 8 75 3.2.2. simple re-enrollment . . . . . . . . . . . . . . . . 9 76 3.2.3. other kinds? . . . . . . . . . . . . . . . . . . . . 9 77 3.3. Initial suspicion . . . . . . . . . . . . . . . . . . . . 9 78 3.4. Confirmed suspicion . . . . . . . . . . . . . . . . . . . 9 79 3.5. Device identified as attack target . . . . . . . . . . . 9 80 3.6. Suspension of connectivity . . . . . . . . . . . . . . . 9 81 3.7. Re-Installation of valid firmware . . . . . . . . . . . . 9 82 4. An example process . . . . . . . . . . . . . . . . . . . . . 9 83 5. Human Rights Considerations . . . . . . . . . . . . . . . . . 10 84 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 90 10.2. Informative References . . . . . . . . . . . . . . . . . 10 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 [I-D.ietf-opsawg-mud] describes the format of the Manufacturer Usage 96 Description (MUD) files. MUD files provide a set of network Access 97 Control Lists (ACL, pronounced [ak-uhl]) that describes the expected 98 traffic from a device, such as an Internet of Things (IoT) device. 100 MUD files are used in a number of projects, including the CIRALabs' 101 [SecureHomeGateway] (SHG) project. In this project a home gateway 102 ("router") is enhanced to be able to use MUD files to describe the 103 traffic expected from all connected devices. If a device does not 104 have a MUD format description, then the project can provide a broad 105 set of traffic expectations based upon categorization of the device 106 by the home owner. 108 This document is about the process to be followed when a device is 109 observed to be violating the ACLs applied to it. While this document 110 will identify network protocols (and gaps where no protocol exists) 111 as appropriate, the goal of this document is more about the human 112 process. Specifically, who gets called, and in what order. Who 113 makes each call, and how are they identified. 115 In addition, what kind of data needs to be shared among the parties 116 and what are the privacy and human rights implications of sharing the 117 required data. 119 Finally, in the security considerations section of this document some 120 concerns about prevention of so-called "SWAT"ing ({swatting}), where 121 an attempt might be made to take a location or network offline 122 through phony reports. 124 1.1. Terminology 126 This document is not a protocol specification, but rather a Best 127 Current Practices in the area of human operations. While this is 128 sometimes called a "Standard Operating Proceedure" (SOP), this 129 document should not be considered the actual SOP for an organization, 130 but rather be referrenced. 132 The terminology [RFC2119] the key words such as "MUST", "MUST NOT", 133 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 134 "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 135 described in BCP 14, RFC 2119. In the context of this human 136 protocol, they do not describe network protocol interoperability 137 requirements, but rather constraints upon how the humans need to 138 operate in order to avoid unsafe situations. 140 The following terms are used in this document: 142 o owner's network: the network belonging to the owner of the device. 143 In residentical situations, this is typically the home owner. In 144 commercial environments, this may be the owner of the building, or 145 the commercial tenant in the building. 147 o tenant: one or more people who occupy a space in which a network 148 of devices exists which do not belong directly to them. 150 1.2. An overview of the stages of activity 152 This section provides a brief overview of the states that a device 153 may be in. The following section provides a detailed description of 154 the state. This document is primarily about how a device transitions 155 from one state to another, which is covered in {#transitions}. 157 .--------. .---------.<---------.------------. 158 | new |-------->| nominal | | suspicious | 159 | device |\ .----->| | -------->| | 160 '--------' \| '---------' '------------' 161 \ | 162 |\ | | 163 | \ | | 164 | \ v v 165 | \ .------------. .-----------. 166 .------------.| v| p0owned | | suspect | 167 | returning || | | | | 168 | to service | '------------' '-----------' 169 '------------' | | 170 ^ | | 171 | v v 172 .------------. .------------. .-----------. 173 | upgrading | | quarantine | | device-of | 174 | |<-----| |<------| interest | 175 '------------' '------------' '-----------' 177 Figure 1: Device Connectivity States 179 o new device: a device that has just been "connected" to the 180 network. 182 o nominal: a device which is operating correctly. 184 o suspicious: a device which has once gone out of it's MUD profile. 186 o suspect: a device which has repeatedly gone out of it's MUD 187 profile. 189 o device-of-interest: a device that is part of a class of devices 190 which is considered suspect. 192 o quarantined: a device which has been isolated into a network 193 "segment", it may stil be operating locally. 195 o disabled: a device which has been disconnected from the network, 196 and has also had mains power removed. The device is believed to 197 be off. 199 o upgrading: a device which is active for the purpose of having new 200 firmware installed. 202 o returning-to-service: a device which has new firmware, and is 203 going through a re-enrollment process. It may still lack critical 204 configuration, and may be unable to yet perform critical 205 functions. 207 o p0wned: a device which is known to have malicious routines 208 running, but is still connected to the network. It may continue 209 to provide the services the device was designed to do, in 210 additional to performing functions controlled by an unauthorized 211 entity. 213 2. Detailed description of states 215 A device is considered to be on one of the above states. The device 216 is not considered to be aware of it's state, rather this is a 217 characteristic that the network assigns to the device. 219 2.1. New device 221 A device newly installed will have no initial network connectivity. 222 It will be awaiting some kind of enrollment or onboarding process. 223 Examples of enrollment processes include 224 [I-D.ietf-anima-bootstrapping-keyinfra], [dpp], processes defined by 225 The Thread Group and Apple Homekit, as well as a great number of 226 custom and proprietary methods. 228 In many cases the device may provide limited network connectivity 229 (such as by running as an Access Point), and can be reached by 230 attackers. The owner of the device may in fact in unaware that the 231 device is "smart", and it may be possible for a device to become 232 compromised without ever having joined a network. This case is 233 particularly difficult, as having never joined a network, the device 234 will not emit signals on the owner's network that can be detected to 235 notice that the device has been attacked. Also, having never been 236 connected, the device is more likely to have old firmware. 238 2.2. Nominal 240 The device is operating normally and is not suspected to be corrupted 241 or under attack. 243 2.3. Suspicious 245 The device and/or the Internet has attempted a connection which is 246 forbidden by the MUD file. This activity is notable, but 247 particularly in the case where a MUD file was generated by a third 248 party (such as by a period of observation), it may signal that the 249 MUD file is inaccurate rather than that the device is compromised. 251 In the case of connections that originate from the Internet to the 252 device which are forbidden, this may indicate that device is being 253 scanned for, but that the security features of the router are 254 resisting the attack. 256 It is unclear how a device is returned from suspicious state to 257 nominal. A reasonable process might be that after a period of time 258 in which no new unwanted activity occurs it is returned. A clear 259 indication that it should return to nomimal is if a new MUD file is 260 applied to the device. 262 2.4. Suspect 264 The device is repeatedly attempting to connect to core infrastructure 265 which it has reasonably no reason to connect to. Examples of this 266 would include connecting to many IP addresses in a sequential or 267 high-frequency rate, connecting to well-known ports not intended to 268 for end devices (for instance TCP port 22, 23, 25). There might 269 still be a reasonable explanation for this behaviour, including that 270 the "inside" IP address has been reassigned to a different device 271 (such as desktop computer). 273 2.5. Device of Interest 275 A device has become interesting based upon two possible situations: 276 an internal signal that a device has become suspected, and based upon 277 external indications that there are active threats against the 278 device. A device in this state SHOULD go into quarantine upon the 279 next observed attack. 281 If it can be observed that there are DNS spoofing attempts against 282 the device manufacturer's firmware repository, or it's command/ 283 control channel (for devices which have cloud connections), then it 284 would be reasonable to become interested in the device: an attack may 285 be coming. 287 A device under interest would continue to be able to perform it's 288 normal functions. For instance, a furnace would continue to heat the 289 house, and would continue to report it's statistics to it's 290 manufacturer/service-entity, and would continue to respond to 291 thermostat changes. 293 2.6. Quarantined 295 A device in quarantine gets no Internet or owner network access. 297 A device in quarantine MAY do DNS requests to the local recursive DNS 298 resolvers for the IP address of it's firmware repository. This 299 address would be present in the device's MUD file using the 300 [I-D.richardson-shg-mud-quarantined-access]. Access to the firmware 301 repository is important to permit the device to apply new firmware 302 and/or reset itself to factory default. 304 A device in quarantine that performs other functions might continue 305 to be perform those functions. For instance, a fridge would remain 306 cold, but it would not respond to thermostat changes, or communicate 307 with a grocery store. 309 2.7. Disabled 311 A device that is disabled gets no network connectivity at all, 312 including no local network connectivity. 314 A device that is directly mains powered would be disconnected by a 315 human. A device that is powered by Power-over-Ethernet could be 316 disconnected by administratively turning power off on that port. 318 A device that is battery powered or scavanges power would remain on 319 as long as it had power. 321 2.8. Returning to Service 323 A device that is attempting to return to service has installed some 324 "fix" for the issue that lead it to be quarantined. It could also be 325 the case that the device did not need to anything, and that the 326 quarantine was a false positive, and a new MUD file is loaded with 327 the additionally accepted patterns. 329 A device returning to service MAY have erased all it's network 330 settings, and will have to go through some form of network enrollment 331 again. 333 2.9. Owned by malicious entity ("p0wned") 335 A device which is known to be controlled by a malicious entity. It 336 may be impossible to quarantine the device if it performs some 337 critical function and the imposition of quarantine would prevent 338 that. 340 3. Detailed description of transitions 342 This section deals with the transitions between states. These 343 transitions occur as a result of network and/or human signaling. The 344 occurance of these transitions will in most cases cause a signal to 345 be sent. 347 3.1. Initial Enrollment 349 The process of enrollment is out of scope for this document. 351 3.2. Re-enrollment 353 The process of re-enrollment is out of scope for this document. This 354 document does specify when this re-enrollment can take place, and how 355 a human can indicate to a device and to the network infrastructure 356 that re-enrollment can take place. 358 Re-enrollment can occur a number of different ways. 360 3.2.1. factory-default re-enrollment 362 A device can re-enroll in a factory-default state. This means that 363 all settings are lost and any private keys that might have been 364 visible to malicious code/coders who may have had access to the 365 device have are regenerated. 367 Devices that store private keys in Trusted Platform Modules (TPM), or 368 in Trusted Execution Environments (see [I-D.ietf-teep-architecture]) 369 could reasonably assume that private keys may be retained. From an 370 802.1AR perspective, the IDevID may be assumed to be intact, but the 371 integrity of the LDevID may be suspect. 373 As the device is in a factory-default state it will have no user/ 374 owner-specific configuration, and any authorization lists will need 375 to be re-established! 377 3.2.2. simple re-enrollment 379 The device does not return to a factory-default state, and has 380 existing network, owner credentials and configuration intact. A 381 network onboarding will need to be repeated to establish new per- 382 device network keys. 384 An audit of the device authorizations SHOULD be done, as an attacker 385 may have inserted additional authorizations in order to return. 387 3.2.3. other kinds? 389 Are there states in between these two extremes? 391 3.3. Initial suspicion 393 The transition from nomimal to initial suspicion occurs when the MUD 394 firewall detects (and blocks) network not described in the device 395 MUD. There are a number of non-critical reasons why this could 396 occur. 398 The mostly likely situation is that the MUD describes access rules 399 using DNS names, while the firewall is implemented in terms of IP 400 addresses. The name to IP mapping may well have changed, and the 401 firewall has not yet caught up to the new mapping. 403 3.4. Confirmed suspicion 405 TBD 407 3.5. Device identified as attack target 409 TBD 411 3.6. Suspension of connectivity 413 TBD 415 3.7. Re-Installation of valid firmware 417 TBD 419 4. An example process 421 Here will be somes examples of a device. 423 5. Human Rights Considerations 425 TBD 427 6. Privacy Considerations 429 TBD 431 7. Security Considerations 433 TBD 435 8. IANA Considerations 437 No IANA objects are required. 439 9. Acknowledgements 441 10. References 443 10.1. Normative References 445 [I-D.ietf-opsawg-mud] 446 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 447 Description Specification", draft-ietf-opsawg-mud-25 (work 448 in progress), June 2018. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 10.2. Informative References 457 [dpp] "Device Provisioning Protocol Specification", n.d., 458 . 462 [I-D.ietf-anima-bootstrapping-keyinfra] 463 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 464 S., and K. Watsen, "Bootstrapping Remote Secure Key 465 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 466 keyinfra-18 (work in progress), January 2019. 468 [I-D.ietf-teep-architecture] 469 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 470 Liu, "Trusted Execution Environment Provisioning (TEEP) 471 Architecture", draft-ietf-teep-architecture-01 (work in 472 progress), October 2018. 474 [I-D.richardson-shg-mud-quarantined-access] 475 Richardson, M., "Manufacturer Usuage Description for 476 quarantined access to firmware", draft-richardson-shg-mud- 477 quarantined-access-00 (work in progress), January 2019. 479 [looneytunes] 480 "List of Looney Tunes Cartoons", n.d., 481 . 484 [SecureHomeGateway] 485 "CIRALabs Secure Home Gateway", n.d., 486 . 488 [swatting] 489 "Cambridge English Dictionary: swatting", January 2019, 490 . 493 Authors' Addresses 495 Michael Richardson 496 Sandelman Software Works 498 Email: mcr+ietf@sandelman.ca 500 Jacques Latour 501 CIRA Labs 503 Email: Jacques.Latour@cira.ca