Involuntary Onwership Transfer of IoT devices: problem statement
draft-richardson-iotops-iot-iot-00

anima Working Group                                        M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Standards Track                             9 July 2021
Expires: 10 January 2022

    Involuntary Onwership Transfer of IoT devices: problem statement
                   draft-richardson-iotops-iot-iot-00

Abstract

   This document details a problem statement relating to ownership of
   IoT devices.

   The problem details is that of changing ownership of a device when
   against the consent of the device and/or manufacturer.

   Examples relating to outer door control are used.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 10 January 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Richardson               Expires 10 January 2022                [Page 1]
Internet-Draft                   iot-iot                       July 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Examples of ownership transfers . . . . . . . . . . . . . . .   3
     2.1.  Homes . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.1.  Death of a Home Owner . . . . . . . . . . . . . . . .   3
       2.1.2.  Multi-person Dwelling: how to kick that that deadbeat
               roomate out?  . . . . . . . . . . . . . . . . . . . .   4
       2.1.3.  Getting rid of the abusive Spouse . . . . . . . . . .   4
     2.2.  Rented Homes  . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Rented Automobiles  . . . . . . . . . . . . . . . . . . .   5
     2.4.  Personal Devices  . . . . . . . . . . . . . . . . . . . .   6
   3.  What is ownership . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Questions and Opportunities . . . . . . . . . . . . . . . . .   8
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Informative References  . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Much has been written about how to secure IoT devices against both
   physical attacks and those that are done through network protocols.
   (Insert survey articles)

   In most cases the goal of the security mechanisms is to make sure
   that the device remains under control its lawful owner.  A definition
   of this control could be to mean that the device accepts command only
   from that owner, and provides information only to destinations that
   the owner specifies.

   This document explores the problem of what happens when the physical
   or legal ownership of the device does not correspond to the logical
   ownership of the device.

Richardson               Expires 10 January 2022                [Page 2]
Internet-Draft                   iot-iot                       July 2021

   There are many ways to explain this problem, but the situation with a
   front-door lock will be used as a reference example of the problem.

2.  Examples of ownership transfers

   A door lock is an item which many people would like to connect to and
   control.  The history of door locks is frequent tussle between lock
   makers who attempt to make locks more resistant to attack, vs thieves
   who use ever more sophisticated methods to attack the locks.  There
   is an obvious relationship to cryptography and cryptoanalysis, and it
   is hardly surprising that many cryptographers are also competent lock
   pickers. [blazepicking]

   In addition to this obvious arms race there are interested third
   parties: Law enforcement, Fire departments.  This was most easily
   demonstrated in the problem with the New York City "master key" which
   was being openly sold in 2012: [huffpostkey] and [fdnymaster].

2.1.  Homes

   Homes and apartments come with a complex set of ownership conditions,
   often via laws established over many centuries.  Door locks are
   therefore an obvious place for conflicts in ownership.

2.1.1.  Death of a Home Owner

   Start from a single freestanding dwelling, owned by a single
   individual, and ask what happens when the individual dies.  How do
   the inheritors (or the executors of the estate) take possession of
   the property?  Prior to electronic door locks, a physical key can be
   used, and if one is not available, then a locksmith can be engaged.
   This may require a legal statement from an appropriate authority, at
   which point the locksmith may make use of a drill, or maybe even some
   other implements such as saws or battering rams.

   The same techniques can probably be used against electronic door
   locks that do not use keys, but can be used against, for instance,
   smart toasters, furnaces or automobiles?

   Repairing a hole in a front door is a nuissance.  Replacing a furnace
   or other large appliances due to a death is unacceptable.

Richardson               Expires 10 January 2022                [Page 3]
Internet-Draft                   iot-iot                       July 2021

   In particular, automobile locks are usually designed to resist
   significant amounts of force as they are often the target for
   thieves.  Any tool or protocol that the locksmith can employ against
   the automobile could also be employed by a malicious attacker.  Any
   mechanism that the automobile maker includes in the system to allow a
   locksmith (or legal court) to open the vehicle would be the target of
   attackers.  This is fundamentally why security protocols do not
   include back doors ([RFC1984]).

2.1.2.  Multi-person Dwelling: how to kick that that deadbeat roomate
        out?

   The situation above was for a single dwelling.  Many dwellings are
   occupied by multiple people, often jointly.

   Should any of the occupants be allowed to change the locks, that is,
   change the entry authorization for other occupants?  Under normal
   circumstances, the answer should probably be no.  Under the situation
   of a legal injunction, the answer may be yes.  How can the door lock
   system know?  How can the party which is asking for the injunction
   know that the door lock has no secret authorization?

   If the legal system must be a party to this activity, how does the
   home owner, not involved in such a process know that the legal
   system's computers haven't itself been compromised?  This is one of
   the major arguments against official escrow: the escrow system is now
   a very high value target.

2.1.3.  Getting rid of the abusive Spouse

   The situation where a couple separate under duress requires that
   access to the original home be restricted.  That is, the door locks
   must be rekeyed.  Digitally, this means removing the access to the
   abusive spouse.

   Is this different than the case of roomates?  Not really: multiple
   people had access to the door lock before, and one must be removed.
   For the case of roomates, each had a legal right to access, and no
   roomate should be allowed to revoke access for the other roomate.

   Now, in the case of separation, the remaining "roomate" must now be
   permitted to revoke access for the other "roomate"

2.2.  Rented Homes

   Many people rent their homes.

Richardson               Expires 10 January 2022                [Page 4]
Internet-Draft                   iot-iot                       July 2021

   In many cases the owner (or property manager) of the home has a legal
   right to enter, under certain circumstances.  For instance to effect
   repairs, to show the dwelling to a new potential tenant, and in
   emergencies, to do things like shut off water or gas to avoid damage.

   Notice is often required for most activities, most laws allow a
   landlord to enter without notice during emergencies to do things like
   shut off water when there is a leak.  A landlord can also be
   compelled to open the door for a police warrant, and in cases where
   the police suspect harm, they often will enter without a warrant.

   How can these rights be clearly shared, defined, and audited?

   This situation is even more complex in apartment buildings, even
   where the apartments are owned (and occupied by the owners).  There
   is still a building manager, and there are still water leaks.

   There is additionally, many common areas to which many people should
   get access, but to which people can reserve their time.  Lockers for
   bicycles and parking spaces.

   The French PTT T-10 key specifically allows the mailman to enter an
   apartment building and then put the mail into the mailboxes in the
   apartment.  This is an example of a master key necessary in most
   multi-tenant buildings.

2.3.  Rented Automobiles

   Automobiles are rented in a variety of ways: from hourly rentals by
   car-sharing companies (e.g., [communauto], [zipcar], [tribecar]..),
   to traditional daily rentals by well-known companies, to yearly car
   leasing.

   During the valid period of rental, the motorist needs to be complete
   control of the vehicle.  This is usually done by giving them a key
   which they must insert into the ignition.  Car sharing companies have
   schemes involving lockboxes (with master physical keys!) to share the
   car-specific key.  (This is rather akin to Kerberos tickets: one key
   is used to unlock another key) Increasingly automobiles are going
   "keyless", and it is sometimes sufficient for the "fob" to be just
   near the vehicle, but the fob is essentially still a key.

   Many manufacturers are now using the individual's smartphone to
   unlock the car via Bluetooth or NFC, and once inside the vehicle, the
   phone serves as the "fob", authorizing the vehicle to run.

Richardson               Expires 10 January 2022                [Page 5]
Internet-Draft                   iot-iot                       July 2021

   Integration with the smartphone has a transaction cost to it: the
   phone/car connection must be onboarded in some way, and is therefore
   only suitable for car owners, or longer-term leases.

   Shorter term leases may transition to use of a smartphone, but today,
   they are mostly based upon passive RFID FOBs or physical keys.
   Today, when used via smartphone, there is a satellite or LTE based
   care security system that the drive interacts with via the Internet.
   There are reports of people being stranded in the woods for days,
   because the were too far away from the LTE tower, and the vehicle
   would not unlock or start without authorization.

   At the end of the rental period, the access for the motorist must be
   revoked.  This is akin to getting rid of roomate (Section 2.1.2).
   But there are some caveats: there has to be some kind of grace period
   or interlock with the renting agency, as the vehicle might not yet
   have been returned properly.  They could just be late.  The vehicle
   could stall meters from the proper location and need to be restarted.
   Once at the proper location, the motorist might still need to access
   the trunk or other compartments to retrieve their belongings.

   But, once properly returned, the vehicle should no longer be
   accessible to the original renter.

   The next renter may be standing waiting, particularly if the vehicle
   is late.  The transition from one renter to another needs to have a
   standardized ceremony.

   For long-term leases the process may be more complex at the end.
   While some significant grace period (compared to rental period) is
   appropriate for short-term, for longer term leases, the owner likely
   needs to be able to disable the vehicle some few number of days after
   the end of the lease.  But, never before.

2.4.  Personal Devices

   There is an increasing number of devices that a person might have on
   their person or around them.  The list is endless, and goes from step
   trackers, to watches, to recreational (exercize) heart monitors,
   shoes, shirts with displays (for fun or for the disco), to intimate
   devices that might be worn at unusual times.

   Some devices may belong only temporarily to a person.  For instance,
   a tread-mill or weight-lifting machine, or even a kitchen appliance.
   After the user is finished with the device it may need to reset to be
   ready for the next user.

Richardson               Expires 10 January 2022                [Page 6]
Internet-Draft                   iot-iot                       July 2021

   A kitchen appliance (a blender or microwave) might have only a small
   number of legitimate users (the members of the household), but when
   one person is using it, it might remain exclusive.

   The same appliance, however, might also be purchased for use in a
   workplace kitchen, and so the number of legitimate users might range
   in the hundreds.  The users will want the appliance to remember their
   personalized settings.

   The names of the previous users should not be easily divulged, but at
   the same time, the name of the person person who used it should be
   available to a priviledged (owner) user, for the case the finding out
   who broke the device.  In this case, it might seem obvious that the
   device has a priviledged owner, and may also have just users.  But
   this interaction may be quite complex, and is subject to a wide
   variety of locally significant social compacts.

   In addition, devices get lent.  This could be akin to thinking about
   there being users vs owners, with the owner always being the one
   responsible for the device.  However, passing on a coffee maker to
   one's child who is moving to another city is not always a loan, and
   not always a gift.  Which one it is may not be obvious to the people
   involved until later on.  The parent may forget about it, thinking
   they have given it away, while the (adult) child might pass it on to
   a friend.  Only when the friend tries to "own" the device, do they
   find out that the parent is still the owner.  Now what?  Does the
   device have to be returned to the parent to physically give away
   ownership?

   If the answer to the above question is no, then does this in essence
   enable theft?  Is this a kind of theft that we need to care about?
   Does it matter if this is a $50 coffee maker, vs a $600 espresso
   machine?  Or can we even set a meaningful threshold?  Theft of a $600
   espresso machine might not be a problem for some people, while the
   loss of a $50 coffee machine might be a rather big problem.

3.  What is ownership

   One technical definition of ownership might be that the device has an
   identity certificate from the owner.  This is a good definition, and
   it is currently what is used in [RFC8995], [MATTER], and many other
   similar systems.

   In the security space, the venacular term, "p0wned" is often used to
   refer to a device that is no longer under the control of the
   legitimate owner.  That is, an attacker has taken control of the
   device, usually through some security vulnerability, and now the
   attacker controls what code the device will run.

Richardson               Expires 10 January 2022                [Page 7]
Internet-Draft                   iot-iot                       July 2021

   So a deeper notion of what it means to own a device is that it could
   involve control of what software a device runs.  Whomever controls
   the software in a device controls what the device does, and whose
   commands it obeys.  This can generally be expressed in the form of an
   authorization from a Trust Provisioning Authority (Section 7 of
   [RFC9019]).

   Control and access decisions are not usually changed by changes to
   the firmware of the device.  (Not withstanding the dispute between
   the FBI and Apple: [applefbi]) For good or bad, all devices of a
   particular type run the same firmware that the manufacturer has
   provided.  The decision as to who is in control of the device is
   determined by the firmware based upon the identities of the parties.

   All of the challenges in the previous section boil down to finding a
   way to express the question as to whether an identity is allowed
   control.

4.  Questions and Opportunities

   While the example of the front door lock was used as an exemplar,
   essentially the same question applies to pretty much all forms of
   actuator.  Access to some sensors may be significantly simpler, but
   other sensors will be as complex as any actuator.

   A primary question is whether the front door problem is a superset of
   all other problems.  If so, then a solution to the front door
   ownership can provide for all other actuators.

   Or, if there some other physical world interaction which is more
   complex, then the front door may be a subnet of it.  Alternatively
   there may be some other master pattern which does not overlap with
   the front door and it would provide a different model.  Some
   actuators might be a subset of these two models.

   The various modes of front door interaction need to be named.  Based
   upon the above description, these would include: roomates, spouses,
   ex-spouses, renter/owners, tenant/superintendant, fire-department,
   police officer, young-children/parent, adult-children/seniors...

   The automobile, personal or medical device interactions are mostly
   variations on the front door.  Instead of superintendant, substitude
   mechanic, leasor or ER doctor.  Instead of child, substitute
   neighbour-who-borrows your tools.

   The IETF has created a number of authorization systems.  This starts
   with SPKI [RFC2393], OAUTH2 [RFC6749], Authorization in Constrained
   Environment [RFC7744], SAML ([oasissaml] and [RFC7522]).  There are

Richardson               Expires 10 January 2022                [Page 8]
Internet-Draft                   iot-iot                       July 2021

   many others: most are based on the providing virtual access to a
   virtual resource (computer, web resource,etc.) rather than
   authorizing physical access to a physical resource.

   Can the required policies be representing in the existing frameworks?
   If so, are the frameworks we have sufficiently small as to live
   within a front door lock?  Perhaps a better question is: what is the
   price point which society is willing to pay for a front-door system
   which satisfies the various needs of the multitude of stakeholders
   involved?

5.  Privacy Considerations

   There is a significant tussle between having policies which are
   clearly asserted (and auditable) and having privacy for the
   individuals or groups named.

   For instance, it may be entirely approriate for a front door to make
   it clear who is allowed access in the event of emergency, such that
   those people can easily be found.  On the other hand, it may be
   inappropriate for the front door to list one's current romantic
   interests as having access.  (Such access might even be
   "aspirational")

   A significant mix of abstract identities ("The Superintendant of the
   Building"), along with pseudonomynous identities will be required.

6.  Security Considerations

   This entire document is about a proposed set of authorization
   systems.

7.  IANA Considerations

   This documents makes no IANA Requests.

8.  Acknowledgements

   Hello.

9.  Changelog

10.  Informative References

   [applefbi] "Apple, Americans, and Security vs. FBI", n.d.,
              <https://www.eff.org/deeplinks/2016/02/apple-americans-
              and-security-vs-fbi>.

Richardson               Expires 10 January 2022                [Page 9]
Internet-Draft                   iot-iot                       July 2021

   [blazepicking]
              Blaze, M., "Notes on Picking Pin Tumbler Locks", 7
              November 2003,
              <https://www.mattblaze.org/papers/notes/picking/>.

   [communauto]
              "Communauto Car Sharing", n.d.,
              <https://www.communauto.ca/>.

   [fdnymaster]
              Schneier, B., "Schneier on Security: Master Key", 10
              January 2012,
              <https://www.schneier.com/blog/archives/2012/10/
              master_keys.html>.

   [huffpostkey]
              Huffington Post, "Daniel Ferraris, Retired Locksmith,
              Sells NYC Master Keys On eBay", 10 January 2012,
              <https://www.huffpost.com/entry/daniel-ferraris-new-york-
              master-keys_n_1928826>.

   [MATTER]   Alliance, C.S., "Connected Home over IP Specification", 1
              July 2021, <https://buildwithmatter.com/>.

   [oasissaml]
              "OASIS Security Services (SAML) TC", n.d.,
              <https://www.oasis-open.org/committees/
              tc_home.php?wg_abbrev=security>.

   [RFC1984]  IAB and IESG, "IAB and IESG Statement on Cryptographic
              Technology and the Internet", BCP 200, RFC 1984,
              DOI 10.17487/RFC1984, August 1996,
              <https://www.rfc-editor.org/info/rfc1984>.

   [RFC2393]  Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
              Payload Compression Protocol (IPComp)", RFC 2393,
              DOI 10.17487/RFC2393, December 1998,
              <https://www.rfc-editor.org/info/rfc2393>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7522]  Campbell, B., Mortimore, C., and M. Jones, "Security
              Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0
              Client Authentication and Authorization Grants", RFC 7522,
              DOI 10.17487/RFC7522, May 2015,
              <https://www.rfc-editor.org/info/rfc7522>.

Richardson               Expires 10 January 2022               [Page 10]
Internet-Draft                   iot-iot                       July 2021

   [RFC7744]  Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M.,
              and S. Kumar, "Use Cases for Authentication and
              Authorization in Constrained Environments", RFC 7744,
              DOI 10.17487/RFC7744, January 2016,
              <https://www.rfc-editor.org/info/rfc7744>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

   [RFC9019]  Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
              Firmware Update Architecture for Internet of Things",
              RFC 9019, DOI 10.17487/RFC9019, April 2021,
              <https://www.rfc-editor.org/info/rfc9019>.

   [tribecar] "Tribe Car", n.d., <https://www.tribecar.com/>.

   [zipcar]   "ZIP Car", n.d., <https://zipcar.com/>.

Author's Address

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca

Richardson               Expires 10 January 2022               [Page 11]