idnits 2.17.1 draft-richardson-iotops-iot-iot-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 date (12 July 2021) is 1012 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 12 July 2021 5 Expires: 13 January 2022 7 Involuntary Onwership Transfer of IoT devices: problem statement 8 draft-richardson-iotops-iot-iot-01 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 or possession of a 16 device when against the consent or knowledge of the device and/or 17 manufacturer. 19 Examples relating to outer door control are used to illustrate the 20 problem statement in an intuitive scope. 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 13 January 2022. 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. Door Locks . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Human Relationships to Doors and Door locks . . . . . . . 3 58 2.1.1. Single owner . . . . . . . . . . . . . . . . . . . . 4 59 2.1.2. Family home . . . . . . . . . . . . . . . . . . . . . 4 60 2.1.3. Roomates . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1.4. Apartment building . . . . . . . . . . . . . . . . . 5 62 2.1.5. Rented or Leased Dwellings . . . . . . . . . . . . . 5 63 2.1.6. Hotels . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.2. Rented Automobiles . . . . . . . . . . . . . . . . . . . 6 65 2.3. Additional Third Parties who need access . . . . . . . . 8 66 3. Death of a Home Owner . . . . . . . . . . . . . . . . . . . . 8 67 4. Multi-person Dwelling: how to kick that that deadbeat roomate 68 out? . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Getting rid of the abusive Spouse . . . . . . . . . . . . . . 9 70 6. What is ownership . . . . . . . . . . . . . . . . . . . . . . 10 71 7. Questions and Opportunities . . . . . . . . . . . . . . . . . 10 72 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 76 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 13. Informative References . . . . . . . . . . . . . . . . . . . 12 78 Appendix A. Personal Devices . . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Much has been written about how to secure IoT devices against both 84 physical attacks and those that are done through network protocols. 85 (Insert survey articles) 87 In most cases, the goal of the security mechanisms is to make sure 88 that the device remains under control its lawful or intended owner. 89 One example of such a definition of this control could be to mean 90 that the device accepts commands only from that owner and that the 91 device provides information only to destinations that the owner 92 specifies. 94 This document explores the problem of what happens when the physical 95 or legal ownership of the device does not correspond to the logical 96 ownership of the device. 98 There are many ways to explain, scope, and illustrate the general 99 problem. It is much easier to understand with concrete examples, and 100 in this example the front-door lock scenarios are used an easy to 101 understand way to connect to real life intuition. It is believed 102 that most other IoT authorization and ownership problems are probably 103 subsets of the situations outlined here. 105 2. Door Locks 107 Most people live in some kind of dwelling with at least one door. 108 When there is more one door, one of them is usually the front-door. 109 This is the primary method of entry and exit, and it usually connects 110 to the street and thus to the rest of the world. It is where both 111 strangers and friends arrive and depart, while other doors (side, 112 garage, balcony, basement and back doors) may lead only areas from 113 which further egress may be impossible, difficult, or deadly. 115 The door lock is among the simplest of IoT actuator: after 116 potentially many layers of system, there is a single output pin from 117 the lock microcontroller which operates some kind of solenoid. When 118 the solenoid is operated, the door unlocks. 120 Of course, some doors may be much more complicated with automatic 121 opening or closing motors, sensors to make sure there is clearance 122 before opening, and that the door is clear before closing. Some 123 doors may slide, lift, rotate or perhaps in the future, modulate to 124 alternate dimensions in order to create an opening. None of those 125 details matter to this document. 127 Also irrelevant to this document are the mechanical details of the 128 door lock itself. While the physical characteristics of the lock are 129 terribly important to actual lock design, it is assumed in this 130 document that the mechanical aspects of the lock is of sufficient 131 quality to resist the expected amount of brute force that is 132 anticipated to be applied to it. 134 The history of physical door locks is frequent tussle between lock 135 makers who attempt to make locks more resistant to attack, vs thieves 136 who use ever more sophisticated methods to attack the locks. There 137 is an obvious relationship to cryptography and cryptoanalysts, and it 138 is hardly surprising that many cryptographers and cryptoanalysists 139 are also competent lock pickers. [blazepicking] 141 2.1. Human Relationships to Doors and Door locks 143 Homes and apartments come with a complex set of ownership conditions, 144 often via laws established over many centuries. Many places have 145 very ancient laws about when and how a Hotel may evict people. 147 2.1.1. Single owner 149 The simplest situation is that of a freestanding dwelling, owned by a 150 single individual. 152 2.1.2. Family home 154 To the single individual one adds a spouse, some children of a 155 variety of ages, grandparents, sisters, brothers, neighbours, cat- 156 sitters, etc. 158 Some members of the household may be trusted to open or close the 159 door from the inside only. For instance a younger child might be 160 allowed to open the door when inside, and only when there is someone 161 else in the house. 163 The child would not be allowed to leave the house and lock the door, 164 and preventing such an young child from locking themselves out might 165 a useful feature. 167 Many homes choose to have deadbolts which require a key to lock the 168 door when leaving. Pulling the door shut is insufficient to lock the 169 door. 171 Other owners prefer that the door lock itself when pulled closed, and 172 so might use a spring-bolt lock. 174 Still others have double deadbolts which require a key in the inside 175 in order to lock or unlock the door. People prefer these if they are 176 concerned that a thief will enter their home through a window, and 177 then will go out the front door with their stuff. The double 178 deadbolt requires a key to unlock from the inside. The downside of 179 the double deadbolt is that in the event of a emergency, it is not 180 possible to use the door without the key. As a result, many homes 181 with a double deadbolt will have a key hanging nearby, but not within 182 reach of a window. 184 2.1.3. Roomates 186 One scenario where there are multiple unrelated individuals in a 187 dwelling is when it is shared by roomates. Each roomate will have 188 co-signed the lease and will have an equal right to be in the 189 apartment. It would be inappropriate for any roomate to have the 190 power to lock out the other roomates. 192 This is constrasted with a owner (or renter) who sublets one or two 193 rooms to other people. In that case, this primary owner should have 194 more power over who can enter and exit, subject to some legal 195 restrictions. The degree to which subletter have legal rights varies 196 by jurisdiction. 198 Can any of these individuals give a "key" to girlfriend/boyfriend? 199 This is definitely a complexity of the situation which is usually not 200 seen in the family home. 202 2.1.4. Apartment building 204 An apartment building consists of many dwellings with some common 205 space. (This is distinguished from a multi-tenant building where 206 each tenant has their own front-door.) 208 Residents of an apartment buildings must pass through a common front 209 door. Historically access to such buildings was via a kind of guard, 210 the door-man. This has now been replaced with some kind of master- 211 key on the front-door, which a telephone mediated system that allows 212 visitors to "buzz" up to the appropriate apartment. The resident of 213 that apartment then activates a circuit to unlock the front door. 215 Historically, these telephone systems were hardwired private handsets 216 present in each apartment. This meant that anyone who was in the 217 apartment could let anyone else in. 219 More modern system are tied into the public telephone system, and a 220 DTMF tone is used to unlock the front door. With such a system, if 221 the phone number attached to the apartment is a mobile phone, then a 222 resident can buzz themselves while outside the apartment, and then 223 buzz themselves in. 225 The modern apartment system does not usually provide for multiple 226 numbers to be attached to the system, and a guest in such an 227 apartment would be unable to, for instance, let medical people in, if 228 the primary resident took ill. 230 2.1.5. Rented or Leased Dwellings 232 Many dwellings are owned by one person, but occupied by another 233 person based upon a rental agreement. 235 Historically such agreements were based upon leases of many months to 236 years, but intermediation of the relationship by a number of dotcom 237 companies have reduced the lease time to days, and the same rental 238 systems are expected to accomodate what is more like a Hotel 239 relationship. That situation is handled in the Section 2.1.6 240 section. 242 In many cases the owner (or property manager) of the home has a legal 243 right to enter, under certain circumstances. For instance to effect 244 repairs, to show the dwelling to a new potential tenant, and in 245 emergencies, to do things like shut off water or gas to avoid damage. 247 Notice is often required for most activities, most laws allow a 248 landlord to enter without notice during emergencies to do things like 249 shut off water when there is a leak. A landlord can also be 250 compelled to open the door for a police warrant, and in cases where 251 the police suspect harm, they often will enter without a warrant. 253 This situation is even more complex in apartment buildings, even 254 where the apartments are owned (and occupied by the owners). There 255 is still a building manager, and there are still water leaks. 257 There is additionally, many common areas to which many people should 258 get access. Some areas like common rooms are multi-access, but 259 during a reserved time, are exclusive to the person who made the 260 reservation. 262 Additionally, there are secondary areas that are private to each 263 residents, such lockers for bicycles and parking spaces. 265 2.1.6. Hotels 267 Placeholder. 269 2.2. Rented Automobiles 271 Automobiles have doors, locks, and ignition locks. There are 272 sometimes different keys for the different locks. The valet key for 273 instance, allows the driver door to be opened and the car to be 274 started, but does not provide access to the glove compartment or the 275 trunk. 277 Automobiles are rented in a variety of ways: from hourly rentals by 278 car-sharing companies (e.g., [communauto], [zipcar], [tribecar]..), 279 to traditional daily rentals by well-known companies, to yearly car 280 leasing. 282 During the valid period of rental, the motorist probably needs to 283 have complete control of the vehicle. If any other party had any 284 control of the vehicle, it might significantly change the legal 285 liability for activity done with the vehicle. 287 This is usually done by giving them a key which they must insert into 288 the ignition. 290 Some car sharing companies have schemes involving lockboxes (with 291 master physical keys!) to share the car-specific key. (This is 292 rather akin to Kerberos tickets: one key is used to unlock another 293 key) 295 Increasingly automobiles are going "keyless", and it is sometimes 296 sufficient for the "fob" to be just near the vehicle, but the fob is 297 essentially still a key. 299 Many manufacturers are now using the individual's smartphone to 300 unlock the car via Bluetooth or NFC, and once inside the vehicle, the 301 phone serves as the "fob", authorizing the vehicle to run. 303 Integration with the smartphone has a transaction cost to it: the 304 phone/car connection must be onboarded in some way, and is therefore 305 only suitable for car owners, or longer-term leases. 307 Shorter term leases may transition to use of a smartphone, but today, 308 they are mostly based upon passive RFID FOBs or physical keys. 309 Today, when used via smartphone, there is a satellite or LTE based 310 care security system that the drive interacts with via the Internet. 311 There are reports of people being stranded in the woods for days, 312 because the were too far away from the LTE tower, and the vehicle 313 would not unlock or start without authorization. 315 At the end of the rental period, the access for the motorist must be 316 revoked. This is akin to getting rid of roomate (Section 4). But 317 there are some caveats: there has to be some kind of grace period or 318 interlock with the renting agency, as the vehicle might not yet have 319 been returned properly. They could just be late. The vehicle could 320 stall meters from the proper location and need to be restarted. Once 321 at the proper location, the motorist might still need to access the 322 trunk or other compartments to retrieve their belongings. 324 But, once properly returned, the vehicle should no longer be 325 accessible to the original renter. 327 The next renter may be standing waiting, particularly if the vehicle 328 is late. The transition from one renter to another needs to have a 329 standardized ceremony. 331 For long-term leases the process may be more complex at the end. 332 While some significant grace period (compared to rental period) is 333 appropriate for short-term, for longer term leases, the owner likely 334 needs to be able to disable the vehicle some few number of days after 335 the end of the lease. But, never before. 337 2.3. Additional Third Parties who need access 339 In addition to this obvious arms race, there are specific third 340 parties that bring their own interests to the locks in the front-door 341 lock scenario, e.g. law enforcement or fire departments. 343 In some places there are locks which accept keys carried by fire, 344 police or postal personnel. For instance, the service key in a 345 building allows the fire department to override the elevator 346 controls. The electrical panels and gas systems in the buildings may 347 also be accessible by the fire department in order to cut off 348 electricity or gas during a fire. 350 The mailboxes of an apartment (and the outer door to get to the 351 mailbox) can be opened by the postal carrier in order to deliver the 352 residents mail. The French PTT T-10 key is an example of such a key, 353 and there is a law and regulation around it as well. 355 This is an example of a master key necessary in most multi-tenant 356 buildings. 358 It is hardly surprising that there was significant concern when the 359 fire/police "master key" for the city of New York was being openly 360 sold on ebay. (see [huffpostkey] and [fdnymaster]) 362 A digital door (and elevator control) key that could be safely 363 deployed as a replacement for this physical key would be a 364 significant improvement over the physical keys. It would be easier 365 to add new users and revoke old users, and an audit log of who used 366 what key in which building could be easily generated. 368 3. Death of a Home Owner 370 Start from a single freestanding dwelling, owned by a single 371 individual, and ask what happens when the individual dies. How do 372 the inheritors (or the executors of the estate) take possession of 373 the property? Prior to electronic door locks, a physical key can be 374 used, and if one is not available, then a locksmith can be engaged. 375 This may require a legal statement from an appropriate authority, at 376 which point the locksmith may make use of a drill, or maybe even some 377 other implements such as saws or battering rams. 379 The same techniques can probably be used against electronic door 380 locks that do not use keys, but can this technique be used against, 381 for instance, smart toasters, furnaces or automobiles? 383 Repairing a hole in a front door is a nuisance. Replacing a furnace 384 or other large appliances due to a death is unacceptable. 386 In particular, automobile locks are usually designed to resist 387 significant amounts of force as they are often the target for 388 thieves. The vehicles are left unattended in public parking lots 389 among many other automobiles for many hours at a time, and it is even 390 a common occurance that a person legitimately walks up to the wrong 391 automobile (having forgotten exactly where they parked) an attempts 392 to unlock it. 394 Any tool or protocol that the locksmith can employ against the 395 automobile could also be employed by a malicious attacker. Any 396 mechanism that the automobile maker includes in the system to allow a 397 locksmith (or legal court) to open the vehicle would be the target of 398 attackers. This is fundamentally why security protocols do not 399 include back doors ([RFC1984]). 401 4. Multi-person Dwelling: how to kick that that deadbeat roomate out? 403 The situation above was for a single dwelling. Many dwellings are 404 occupied by multiple people, often jointly. 406 Should any of the occupants be allowed to change the locks, that is, 407 change the entry authorization for other occupants? Under normal 408 circumstances, the answer should probably be no. Under the situation 409 of a legal injunction, the answer may be yes. How can the door lock 410 system know? How can the party which is asking for the injunction 411 know that the door lock has no other secret authorizations? 413 If the legal system must be a party to this activity, how does the 414 home owner, not involved in such a process know that the legal 415 system's computers haven't itself been compromised? This is one of 416 the major arguments against official escrow: the escrow system is now 417 a very high value target. 419 5. Getting rid of the abusive Spouse 421 The situation where a couple separate under duress requires that 422 access to the original home be restricted. That is, the door locks 423 must be rekeyed. Digitally, this means removing the access to the 424 abusive spouse. 426 Is this different than the case of roomates? Not really: multiple 427 people had access to the door lock before, and one must be removed. 428 For the case of roomates, each had a legal right to access, and no 429 roomate should be allowed to revoke access for the other roomate. 431 Now, in the case of separation, the remaining "roomate" must now be 432 permitted to revoke access for the other "roomate" 434 6. What is ownership 436 One technical definition of ownership might be that the device has an 437 identity certificate from the owner. This is a good definition, and 438 it is currently what is used in [RFC8995], [MATTER], and many other 439 similar systems. 441 In the security space, the vernacular term, "p0wned" is often used to 442 refer to a device that is no longer under the control of the 443 legitimate owner. That is, an attacker has taken control of the 444 device, usually through some security vulnerability, and now the 445 attacker controls what code the device will run. 447 So a deeper notion of what it means to own a device is that it could 448 involve control of what software a device runs. Whomever controls 449 the software in a device controls what the device does, and whose 450 commands it obeys. This can generally be expressed in the form of an 451 authorization from a Trust Provisioning Authority (Section 7 of 452 [RFC9019]). 454 Control and access decisions are not usually changed by changes to 455 the firmware of the device. (Not withstanding the dispute between 456 the FBI and Apple: [applefbi]) For good or bad, all devices of a 457 particular type run the same firmware that the manufacturer has 458 provided. The decision as to who is in control of the device is 459 determined by the firmware based upon the identities of the parties. 461 All of the challenges in the previous section boil down to finding a 462 way to express the question as to whether an identity is allowed 463 control. 465 7. Questions and Opportunities 467 While the example of the front door lock was used as an exemplar, 468 essentially the same question applies to pretty much all forms of 469 actuator. Access to some sensors may be significantly simpler, but 470 other sensors will be as complex as any actuator. 472 A primary question is whether the front door problem is a superset of 473 all other problems. If so, then a solution to the front door 474 ownership can provide for all other actuators. 476 Or, if there some other physical world interaction which is more 477 complex, then the front door may be a subnet of it. Alternatively 478 there may be some other master pattern which does not overlap with 479 the front door and it would provide a different model. Some 480 actuators might be a subset of these two models. 482 The various modes of front door interaction need to be named. Based 483 upon the above description, these would include: roomates, spouses, 484 ex-spouses, renter/owners, tenant/superintendant, fire-department, 485 police officer, young-children/parent, adult-children/seniors... 487 The automobile, personal or medical device interactions are mostly 488 variations on the front door. Instead of superintendant, substitude 489 mechanic, leasor or ER doctor. Instead of child, substitute 490 neighbour-who-borrows your tools. 492 The IETF has created a number of authorization systems. This starts 493 with SPKI [RFC2393], OAUTH2 [RFC6749], Authorization in Constrained 494 Environment [RFC7744], SAML ([oasissaml] and [RFC7522]). There are 495 many others: most are based on the providing virtual access to a 496 virtual resource (computer, web resource,etc.) rather than 497 authorizing physical access to a physical resource. 499 Can the required policies be representing in the existing frameworks? 500 If so, are the frameworks we have sufficiently small as to live 501 within a front door lock? Perhaps a better question is: what is the 502 price point that society is willing to pay for a front-door system 503 which satisfies the various needs of the multitude of stakeholders 504 involved? 506 8. Privacy Considerations 508 There is a significant tussle between having policies which are 509 clearly asserted (and auditable) and having privacy for the 510 individuals or groups named. 512 For instance, it may be entirely appropriate for a front door to make 513 it clear who is allowed access in the event of emergency, such that 514 those people can easily be found. On the other hand, it may be 515 inappropriate for the front door to list one's current romantic 516 interests as having access. (Such access might even be 517 "aspirational") 518 A significant mix of abstract identities ("The Superintendant of the 519 Building"), along with pseudonymous identities will be required. 521 9. Security Considerations 523 This entire document is about a proposed set of authorization 524 systems. 526 10. IANA Considerations 528 This documents makes no IANA Requests. 530 11. Acknowledgements 532 Hello. 534 12. Changelog 536 13. Informative References 538 [applefbi] "Apple, Americans, and Security vs. FBI", n.d., 539 . 542 [blazepicking] 543 Blaze, M., "Notes on Picking Pin Tumbler Locks", 7 544 November 2003, 545 . 547 [communauto] 548 "Communauto Car Sharing", n.d., 549 . 551 [fdnymaster] 552 Schneier, B., "Schneier on Security: Master Key", 10 553 January 2012, 554 . 557 [huffpostkey] 558 Huffington Post, "Daniel Ferraris, Retired Locksmith, 559 Sells NYC Master Keys On eBay", 10 January 2012, 560 . 563 [MATTER] Alliance, C.S., "Connected Home over IP Specification", 1 564 July 2021, . 566 [oasissaml] 567 "OASIS Security Services (SAML) TC", n.d., 568 . 571 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 572 Technology and the Internet", BCP 200, RFC 1984, 573 DOI 10.17487/RFC1984, August 1996, 574 . 576 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 577 Payload Compression Protocol (IPComp)", RFC 2393, 578 DOI 10.17487/RFC2393, December 1998, 579 . 581 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 582 RFC 6749, DOI 10.17487/RFC6749, October 2012, 583 . 585 [RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security 586 Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 587 Client Authentication and Authorization Grants", RFC 7522, 588 DOI 10.17487/RFC7522, May 2015, 589 . 591 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 592 and S. Kumar, "Use Cases for Authentication and 593 Authorization in Constrained Environments", RFC 7744, 594 DOI 10.17487/RFC7744, January 2016, 595 . 597 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 598 and K. Watsen, "Bootstrapping Remote Secure Key 599 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 600 May 2021, . 602 [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 603 Firmware Update Architecture for Internet of Things", 604 RFC 9019, DOI 10.17487/RFC9019, April 2021, 605 . 607 [tribecar] "Tribe Car", n.d., . 609 [zipcar] "ZIP Car", n.d., . 611 Appendix A. Personal Devices 613 There is an increasing number of devices that a person might have on 614 their person or around them. The list is endless, and goes from step 615 trackers, to watches, to recreational (exercize) heart monitors, 616 shoes, shirts with displays (for fun or for the disco), to intimate 617 devices that might be worn at unusual times. 619 Some devices may belong only temporarily to a person. For instance, 620 a tread-mill or weight-lifting machine, or even a kitchen appliance. 621 After the user is finished with the device it may need to reset to be 622 ready for the next user. 624 A kitchen appliance (a blender or microwave) might have only a small 625 number of legitimate users (the members of the household), but when 626 one person is using it, it might remain exclusive. 628 The same appliance, however, might also be purchased for use in a 629 workplace kitchen, and so the number of legitimate users might range 630 in the hundreds. The users will want the appliance to remember their 631 personalized settings. 633 The names of the previous users should not be easily divulged, but at 634 the same time, the name of the person who used it should be available 635 to a privileged user (owner), for the case the finding out who broke 636 the device. In this case, it might seem obvious that the device has 637 a privileged owner, and may also have just users. But this 638 interaction may be quite complex, and is subject to a wide variety of 639 locally significant social compacts. 641 In addition, devices get lent. This could be akin to thinking about 642 there being users vs owners, with the owner always being the one 643 responsible for the device. However, passing on a coffee maker to 644 one's child who is moving to another city is not always a loan, and 645 not always a gift. Which one it is may not be obvious to the people 646 involved until later on. The parent may forget about it, thinking 647 they have given it away, while the (adult) child might pass it on to 648 a friend. Only when the friend tries to "own" the device, do they 649 find out that the parent is still the owner. Now what? Does the 650 device have to be returned to the parent to physically give away 651 ownership? 653 If the answer to the above question is no, then does this in essence 654 enable theft? Is this a kind of theft that we need to care about? 655 Does it matter if this is a $50 coffee maker, vs a $600 espresso 656 machine? Or can we even set a meaningful threshold? Theft of a $600 657 espresso machine might not be a problem for some people, while the 658 loss of a $50 coffee machine might be a rather big problem. 660 Author's Address 662 Michael Richardson 663 Sandelman Software Works 665 Email: mcr+ietf@sandelman.ca