idnits 2.17.1 draft-richardson-iotops-iot-iot-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 date (9 July 2021) is 1015 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) -- Obsolete informational reference (is this intentional?): RFC 2393 (Obsoleted by RFC 3173) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track 9 July 2021 5 Expires: 10 January 2022 7 Involuntary Onwership Transfer of IoT devices: problem statement 8 draft-richardson-iotops-iot-iot-00 10 Abstract 12 This document details a problem statement relating to ownership of 13 IoT devices. 15 The problem details is that of changing ownership of a device when 16 against the consent of the device and/or manufacturer. 18 Examples relating to outer door control are used. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 10 January 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Examples of ownership transfers . . . . . . . . . . . . . . . 3 55 2.1. Homes . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1.1. Death of a Home Owner . . . . . . . . . . . . . . . . 3 57 2.1.2. Multi-person Dwelling: how to kick that that deadbeat 58 roomate out? . . . . . . . . . . . . . . . . . . . . 4 59 2.1.3. Getting rid of the abusive Spouse . . . . . . . . . . 4 60 2.2. Rented Homes . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Rented Automobiles . . . . . . . . . . . . . . . . . . . 5 62 2.4. Personal Devices . . . . . . . . . . . . . . . . . . . . 6 63 3. What is ownership . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Questions and Opportunities . . . . . . . . . . . . . . . . . 8 65 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 10. Informative References . . . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Much has been written about how to secure IoT devices against both 76 physical attacks and those that are done through network protocols. 77 (Insert survey articles) 79 In most cases the goal of the security mechanisms is to make sure 80 that the device remains under control its lawful owner. A definition 81 of this control could be to mean that the device accepts command only 82 from that owner, and provides information only to destinations that 83 the owner specifies. 85 This document explores the problem of what happens when the physical 86 or legal ownership of the device does not correspond to the logical 87 ownership of the device. 89 There are many ways to explain this problem, but the situation with a 90 front-door lock will be used as a reference example of the problem. 92 2. Examples of ownership transfers 94 A door lock is an item which many people would like to connect to and 95 control. The history of door locks is frequent tussle between lock 96 makers who attempt to make locks more resistant to attack, vs thieves 97 who use ever more sophisticated methods to attack the locks. There 98 is an obvious relationship to cryptography and cryptoanalysis, and it 99 is hardly surprising that many cryptographers are also competent lock 100 pickers. [blazepicking] 102 In addition to this obvious arms race there are interested third 103 parties: Law enforcement, Fire departments. This was most easily 104 demonstrated in the problem with the New York City "master key" which 105 was being openly sold in 2012: [huffpostkey] and [fdnymaster]. 107 2.1. Homes 109 Homes and apartments come with a complex set of ownership conditions, 110 often via laws established over many centuries. Door locks are 111 therefore an obvious place for conflicts in ownership. 113 2.1.1. Death of a Home Owner 115 Start from a single freestanding dwelling, owned by a single 116 individual, and ask what happens when the individual dies. How do 117 the inheritors (or the executors of the estate) take possession of 118 the property? Prior to electronic door locks, a physical key can be 119 used, and if one is not available, then a locksmith can be engaged. 120 This may require a legal statement from an appropriate authority, at 121 which point the locksmith may make use of a drill, or maybe even some 122 other implements such as saws or battering rams. 124 The same techniques can probably be used against electronic door 125 locks that do not use keys, but can be used against, for instance, 126 smart toasters, furnaces or automobiles? 128 Repairing a hole in a front door is a nuissance. Replacing a furnace 129 or other large appliances due to a death is unacceptable. 131 In particular, automobile locks are usually designed to resist 132 significant amounts of force as they are often the target for 133 thieves. Any tool or protocol that the locksmith can employ against 134 the automobile could also be employed by a malicious attacker. Any 135 mechanism that the automobile maker includes in the system to allow a 136 locksmith (or legal court) to open the vehicle would be the target of 137 attackers. This is fundamentally why security protocols do not 138 include back doors ([RFC1984]). 140 2.1.2. Multi-person Dwelling: how to kick that that deadbeat roomate 141 out? 143 The situation above was for a single dwelling. Many dwellings are 144 occupied by multiple people, often jointly. 146 Should any of the occupants be allowed to change the locks, that is, 147 change the entry authorization for other occupants? Under normal 148 circumstances, the answer should probably be no. Under the situation 149 of a legal injunction, the answer may be yes. How can the door lock 150 system know? How can the party which is asking for the injunction 151 know that the door lock has no secret authorization? 153 If the legal system must be a party to this activity, how does the 154 home owner, not involved in such a process know that the legal 155 system's computers haven't itself been compromised? This is one of 156 the major arguments against official escrow: the escrow system is now 157 a very high value target. 159 2.1.3. Getting rid of the abusive Spouse 161 The situation where a couple separate under duress requires that 162 access to the original home be restricted. That is, the door locks 163 must be rekeyed. Digitally, this means removing the access to the 164 abusive spouse. 166 Is this different than the case of roomates? Not really: multiple 167 people had access to the door lock before, and one must be removed. 168 For the case of roomates, each had a legal right to access, and no 169 roomate should be allowed to revoke access for the other roomate. 171 Now, in the case of separation, the remaining "roomate" must now be 172 permitted to revoke access for the other "roomate" 174 2.2. Rented Homes 176 Many people rent their homes. 178 In many cases the owner (or property manager) of the home has a legal 179 right to enter, under certain circumstances. For instance to effect 180 repairs, to show the dwelling to a new potential tenant, and in 181 emergencies, to do things like shut off water or gas to avoid damage. 183 Notice is often required for most activities, most laws allow a 184 landlord to enter without notice during emergencies to do things like 185 shut off water when there is a leak. A landlord can also be 186 compelled to open the door for a police warrant, and in cases where 187 the police suspect harm, they often will enter without a warrant. 189 How can these rights be clearly shared, defined, and audited? 191 This situation is even more complex in apartment buildings, even 192 where the apartments are owned (and occupied by the owners). There 193 is still a building manager, and there are still water leaks. 195 There is additionally, many common areas to which many people should 196 get access, but to which people can reserve their time. Lockers for 197 bicycles and parking spaces. 199 The French PTT T-10 key specifically allows the mailman to enter an 200 apartment building and then put the mail into the mailboxes in the 201 apartment. This is an example of a master key necessary in most 202 multi-tenant buildings. 204 2.3. Rented Automobiles 206 Automobiles are rented in a variety of ways: from hourly rentals by 207 car-sharing companies (e.g., [communauto], [zipcar], [tribecar]..), 208 to traditional daily rentals by well-known companies, to yearly car 209 leasing. 211 During the valid period of rental, the motorist needs to be complete 212 control of the vehicle. This is usually done by giving them a key 213 which they must insert into the ignition. Car sharing companies have 214 schemes involving lockboxes (with master physical keys!) to share the 215 car-specific key. (This is rather akin to Kerberos tickets: one key 216 is used to unlock another key) Increasingly automobiles are going 217 "keyless", and it is sometimes sufficient for the "fob" to be just 218 near the vehicle, but the fob is essentially still a key. 220 Many manufacturers are now using the individual's smartphone to 221 unlock the car via Bluetooth or NFC, and once inside the vehicle, the 222 phone serves as the "fob", authorizing the vehicle to run. 224 Integration with the smartphone has a transaction cost to it: the 225 phone/car connection must be onboarded in some way, and is therefore 226 only suitable for car owners, or longer-term leases. 228 Shorter term leases may transition to use of a smartphone, but today, 229 they are mostly based upon passive RFID FOBs or physical keys. 230 Today, when used via smartphone, there is a satellite or LTE based 231 care security system that the drive interacts with via the Internet. 232 There are reports of people being stranded in the woods for days, 233 because the were too far away from the LTE tower, and the vehicle 234 would not unlock or start without authorization. 236 At the end of the rental period, the access for the motorist must be 237 revoked. This is akin to getting rid of roomate (Section 2.1.2). 238 But there are some caveats: there has to be some kind of grace period 239 or interlock with the renting agency, as the vehicle might not yet 240 have been returned properly. They could just be late. The vehicle 241 could stall meters from the proper location and need to be restarted. 242 Once at the proper location, the motorist might still need to access 243 the trunk or other compartments to retrieve their belongings. 245 But, once properly returned, the vehicle should no longer be 246 accessible to the original renter. 248 The next renter may be standing waiting, particularly if the vehicle 249 is late. The transition from one renter to another needs to have a 250 standardized ceremony. 252 For long-term leases the process may be more complex at the end. 253 While some significant grace period (compared to rental period) is 254 appropriate for short-term, for longer term leases, the owner likely 255 needs to be able to disable the vehicle some few number of days after 256 the end of the lease. But, never before. 258 2.4. Personal Devices 260 There is an increasing number of devices that a person might have on 261 their person or around them. The list is endless, and goes from step 262 trackers, to watches, to recreational (exercize) heart monitors, 263 shoes, shirts with displays (for fun or for the disco), to intimate 264 devices that might be worn at unusual times. 266 Some devices may belong only temporarily to a person. For instance, 267 a tread-mill or weight-lifting machine, or even a kitchen appliance. 268 After the user is finished with the device it may need to reset to be 269 ready for the next user. 271 A kitchen appliance (a blender or microwave) might have only a small 272 number of legitimate users (the members of the household), but when 273 one person is using it, it might remain exclusive. 275 The same appliance, however, might also be purchased for use in a 276 workplace kitchen, and so the number of legitimate users might range 277 in the hundreds. The users will want the appliance to remember their 278 personalized settings. 280 The names of the previous users should not be easily divulged, but at 281 the same time, the name of the person person who used it should be 282 available to a priviledged (owner) user, for the case the finding out 283 who broke the device. In this case, it might seem obvious that the 284 device has a priviledged owner, and may also have just users. But 285 this interaction may be quite complex, and is subject to a wide 286 variety of locally significant social compacts. 288 In addition, devices get lent. This could be akin to thinking about 289 there being users vs owners, with the owner always being the one 290 responsible for the device. However, passing on a coffee maker to 291 one's child who is moving to another city is not always a loan, and 292 not always a gift. Which one it is may not be obvious to the people 293 involved until later on. The parent may forget about it, thinking 294 they have given it away, while the (adult) child might pass it on to 295 a friend. Only when the friend tries to "own" the device, do they 296 find out that the parent is still the owner. Now what? Does the 297 device have to be returned to the parent to physically give away 298 ownership? 300 If the answer to the above question is no, then does this in essence 301 enable theft? Is this a kind of theft that we need to care about? 302 Does it matter if this is a $50 coffee maker, vs a $600 espresso 303 machine? Or can we even set a meaningful threshold? Theft of a $600 304 espresso machine might not be a problem for some people, while the 305 loss of a $50 coffee machine might be a rather big problem. 307 3. What is ownership 309 One technical definition of ownership might be that the device has an 310 identity certificate from the owner. This is a good definition, and 311 it is currently what is used in [RFC8995], [MATTER], and many other 312 similar systems. 314 In the security space, the venacular term, "p0wned" is often used to 315 refer to a device that is no longer under the control of the 316 legitimate owner. That is, an attacker has taken control of the 317 device, usually through some security vulnerability, and now the 318 attacker controls what code the device will run. 320 So a deeper notion of what it means to own a device is that it could 321 involve control of what software a device runs. Whomever controls 322 the software in a device controls what the device does, and whose 323 commands it obeys. This can generally be expressed in the form of an 324 authorization from a Trust Provisioning Authority (Section 7 of 325 [RFC9019]). 327 Control and access decisions are not usually changed by changes to 328 the firmware of the device. (Not withstanding the dispute between 329 the FBI and Apple: [applefbi]) For good or bad, all devices of a 330 particular type run the same firmware that the manufacturer has 331 provided. The decision as to who is in control of the device is 332 determined by the firmware based upon the identities of the parties. 334 All of the challenges in the previous section boil down to finding a 335 way to express the question as to whether an identity is allowed 336 control. 338 4. Questions and Opportunities 340 While the example of the front door lock was used as an exemplar, 341 essentially the same question applies to pretty much all forms of 342 actuator. Access to some sensors may be significantly simpler, but 343 other sensors will be as complex as any actuator. 345 A primary question is whether the front door problem is a superset of 346 all other problems. If so, then a solution to the front door 347 ownership can provide for all other actuators. 349 Or, if there some other physical world interaction which is more 350 complex, then the front door may be a subnet of it. Alternatively 351 there may be some other master pattern which does not overlap with 352 the front door and it would provide a different model. Some 353 actuators might be a subset of these two models. 355 The various modes of front door interaction need to be named. Based 356 upon the above description, these would include: roomates, spouses, 357 ex-spouses, renter/owners, tenant/superintendant, fire-department, 358 police officer, young-children/parent, adult-children/seniors... 360 The automobile, personal or medical device interactions are mostly 361 variations on the front door. Instead of superintendant, substitude 362 mechanic, leasor or ER doctor. Instead of child, substitute 363 neighbour-who-borrows your tools. 365 The IETF has created a number of authorization systems. This starts 366 with SPKI [RFC2393], OAUTH2 [RFC6749], Authorization in Constrained 367 Environment [RFC7744], SAML ([oasissaml] and [RFC7522]). There are 368 many others: most are based on the providing virtual access to a 369 virtual resource (computer, web resource,etc.) rather than 370 authorizing physical access to a physical resource. 372 Can the required policies be representing in the existing frameworks? 373 If so, are the frameworks we have sufficiently small as to live 374 within a front door lock? Perhaps a better question is: what is the 375 price point which society is willing to pay for a front-door system 376 which satisfies the various needs of the multitude of stakeholders 377 involved? 379 5. Privacy Considerations 381 There is a significant tussle between having policies which are 382 clearly asserted (and auditable) and having privacy for the 383 individuals or groups named. 385 For instance, it may be entirely approriate for a front door to make 386 it clear who is allowed access in the event of emergency, such that 387 those people can easily be found. On the other hand, it may be 388 inappropriate for the front door to list one's current romantic 389 interests as having access. (Such access might even be 390 "aspirational") 392 A significant mix of abstract identities ("The Superintendant of the 393 Building"), along with pseudonomynous identities will be required. 395 6. Security Considerations 397 This entire document is about a proposed set of authorization 398 systems. 400 7. IANA Considerations 402 This documents makes no IANA Requests. 404 8. Acknowledgements 406 Hello. 408 9. Changelog 410 10. Informative References 412 [applefbi] "Apple, Americans, and Security vs. FBI", n.d., 413 . 416 [blazepicking] 417 Blaze, M., "Notes on Picking Pin Tumbler Locks", 7 418 November 2003, 419 . 421 [communauto] 422 "Communauto Car Sharing", n.d., 423 . 425 [fdnymaster] 426 Schneier, B., "Schneier on Security: Master Key", 10 427 January 2012, 428 . 431 [huffpostkey] 432 Huffington Post, "Daniel Ferraris, Retired Locksmith, 433 Sells NYC Master Keys On eBay", 10 January 2012, 434 . 437 [MATTER] Alliance, C.S., "Connected Home over IP Specification", 1 438 July 2021, . 440 [oasissaml] 441 "OASIS Security Services (SAML) TC", n.d., 442 . 445 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 446 Technology and the Internet", BCP 200, RFC 1984, 447 DOI 10.17487/RFC1984, August 1996, 448 . 450 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 451 Payload Compression Protocol (IPComp)", RFC 2393, 452 DOI 10.17487/RFC2393, December 1998, 453 . 455 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 456 RFC 6749, DOI 10.17487/RFC6749, October 2012, 457 . 459 [RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security 460 Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 461 Client Authentication and Authorization Grants", RFC 7522, 462 DOI 10.17487/RFC7522, May 2015, 463 . 465 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 466 and S. Kumar, "Use Cases for Authentication and 467 Authorization in Constrained Environments", RFC 7744, 468 DOI 10.17487/RFC7744, January 2016, 469 . 471 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 472 and K. Watsen, "Bootstrapping Remote Secure Key 473 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 474 May 2021, . 476 [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 477 Firmware Update Architecture for Internet of Things", 478 RFC 9019, DOI 10.17487/RFC9019, April 2021, 479 . 481 [tribecar] "Tribe Car", n.d., . 483 [zipcar] "ZIP Car", n.d., . 485 Author's Address 487 Michael Richardson 488 Sandelman Software Works 490 Email: mcr+ietf@sandelman.ca