Skip to end of metadata
Go to start of metadata

Q&A Identity & Internet of Things

Version: 0.06


Archives of this paper: http://kantarainitiative.org/confluence/display/IDoT/Q&A+Identity+&+Internet+of+Things

Change history:

    • draft 0.01    Ingo.Friese
    • draft 0.02    Jeff Stollman
    • draft 0.03    Scott Shorter
    • draft 0.04    Ingo.Friese
    • draft 0.05    Jeff Stollman
    • draft 0.06    Ingo Friese

Abstract

The purpose of this page is to describe identity concepts in the Internet of Things. Identity mechanisms in the Internet of Things are different from those in the classic web. (Scott: let's say how)


Furthermore this page proposes a terminology for Identity management in the Internet of Things. This should help to facilitate discussions and work in this area without the need to define basic terms again.

Introduction

The “Internet of Things” (IoT) is evolving and early solutions are now being implemented at a rapid pace. There are implementations in areas like logistics, farming, manufacturing, heavy industry, automotive, home automation and many others. Restrictions and issues arise as we try to connect solutions of different vendors and communities each which support different standards. From a business point of view the IoT enables a plethora of new opportunities, use cases and scenarios. From a technical point of view the IoT consists of devices, sensors, actuators, or simply objects connected to services in the Internet at a scale that is hard to quantify. Today, devices and sensors speak a lot of different network protocols and most do not communicate over the web standard HTTP. This is a leading cause as to why application development in the IoT is so hard to implement, a lack of usable application integration layers. The next logical step is to use common web technologies for the IoT, including Identity and Access Management as one of the most important common principles and technologies. Apart from adapting communication protocols an overarching identity framework is crucial for a growing IoT as it is crucial to know what devices are interacting and on who's behalf they are operating. Today we have many separate solutions and niche standards and there is no overall framework for how to recognize and manage identities across different solutions. This  discussion group called “IDentities of Things” within the Kantara Initiative is formed to discuss the challenges and identify current practices and future opportunities requiring additional work. 

After three years work in this Identity of Things Discussion Group, the analyses of various standards, projects and activities we would like to summarize our thoughts here. Find below a collections of questions that came across during our work, meetings, conferences and discussions.

Question & Answer

What are the challenges of Identity in the Internet of Things?

Do we need a special identifier or is there already an “Identifier" for the Internet of Things”?

When there is no dedicated identifier for the IoT, how can things with different identifier from different standards, protocols and domains communicate with each other?

Does the lack of an IoT identitfier make IoT architectures more complicate?

Is the classic Domain Name Service (DNS) obsolete in the IoT?

Why is privacy a critical topic in IoT?

How to design a privacy ensured IoT system?

How is authentication realized in IoT today?

What are key concepts for Identity already surfaced elsewhere in Kantara Initiative that can be also used in the IoT?

Is the huge address pool of IPv6 a solution for Identities in IoT?

A thing is not always just one thing. Can a thing be composed of other things?

What are the challenges of Identity in the Internet of Things?

The challenges can be grouped in

  • Ownership and identity relationships
  • Object Identifier and Namespace
  • Authentication and Authorization
  • Governance of data and Privacy

See details in our paper published in the proceedings of the IEEE World Forum on Internet of Things (WF-IoT) 2014:  Challenges from the Identities of Things


Do we need a special identitfier or is there already “the Identifier" for the Internet of Things”?

There is no special identifier for IoT. And there won't be one kind of Identifier. Many standards, de facto standards, protocols and solutions already exist in the area of IoT. There are various kinds of identifiers with different characteristics suitable for specific purposes. (for details see our Identifier Survey).

When there is no dedicated identifier for the IoT, how can things with different identifiers from different standards, protocols and domains communicate with each other?

Mapping and discovery become important services in large IoT deployments with different systems, standards and domains. Let's give an example : A street lamp might have a field bus address consisting of 2 bytes. It is connected with a gateway. Within the gateway the lamp is mapped to "lamp 123". A lamp management system can switch on and off "lamp123" intertnally. Via a REST interface the lamp management system exposes the lamp, for example as oneM2M "application entity". So other management systems can switch the lamp on and off by sending messages to a specific oneM2M URL. In this example a thing (lamp) is identified with different identifiers that are mapped to each other (field bus address, internal ID, oneM2M-URL)..

When the authorities of a city want to address all lamp posts in one area they use some kind of mnagement software. Only in very rare situation this kind of software talks direct to lamp posts. There are mostly gateways inbetween the communication path pmapping IDs and mostly also protocols.

Does the lack of an IoT identitfier make IoT architectures more complicated?

It takes more effort to find and map various identifiers but the mapping process also gives the possibility to implement access control mechanisms. Only entitled services or users are able to resolve or discover the identifier of a thing.This way it's possible to control whether an identifier is visible or not or who can "see" a certain thing or not. In our example the policy check could be implemented in the lamp management system or with the REST API.

(see an example of a universal identity mapping and discovery service IMaDS in a paper accepted for publication at the 2017 European Conference on Networks and Communications (EuCNC)

Is the classic Domain Name Service (DNS) obsolete in the IoT?

Absolutely not. In most cases DNS (Domain Name Service) can't be used directly. DNS was designed to map between IP-addresses and human readable domain names. DNS is not able to handle identifier formats from various IoT protocols. It is also not possible to propagate changes in a very short time. But DNS has an outstanding governance process that ensures world-wide unique identifiers. So DNS is at least part of most mapping processes. In our example DNS might be used to find the company domain of the lamp management or the address of the REST API.


Why is privacy a critical topic in IoT?

Privacy and Trust becomes crucial in the Internet of Things because even arbitrary data, like a temperature, might be related to a user when it’s combined with other data like location or is profiled over a period of time. So it is possible to see whether a person is at home or not. One extreme exemplary privacy issue is the ability to determine what kind of TV-Program a user is watching just from measuring the energy consumption with very frequent samples [ 1 ]. 

[1] Ulrich Greveler, Benjamin Justus, Dennis Loehr. Multimedia Content Identification Through Smart Meter Power Usage Profiles. Computer Security Lab Münster University of Applied Sciences D-48565 Steinfurt, Germany. Published on Electronic Privacy Information Center epic.org https://epic.org/privacy/smartgrid/smart_meter.pdf


How to design a privacy ensured IoT system?

The are various design strategies and architecture concepts to ensure privacy in communication and during resource access control. The Identity of Thing Discussion Group supports IEEE P2413 IoT Architecture Working Group in writing a Privacy  and Trust Architecture View Point. This viewpoint is described in an Architecture viewpoint template of ISO/IEC/IEEE 42010:2011. This describes concerns and models to frame the viewpoint. Find here the: current concerns of the Privacy and Trust Architecture Viewpoint. This first draft of the complete P2413 architecture draft is expected to be published late 2017.


How is authentication realized in IoT today?

Different authentication methods are used in IoT today. Let's have an examplary look at authentication in oneM2M. When it comes to communication between 2 systems in the HTTP profile of oneM2M simpe authentication can be used. This means a username and a password iare written to the header of the message. An altrnative is to use authentication tokens. The can send along with a message header or as HTTP-request parameters. A great example are JSON Web Tokens. username (IETF RFC 7519).


What are key concepts for Identity in Kantara Initiative that can be also used in the IoT?

User Managed Access (UMA)

Services or devices miay have access policies describing who may have access and what kind of operation under what conditions are allowed. In oneM2M for example there is a concept of Access Control Policies that are attached to certain resources. A policy object or file is deployed at configuration or at some point in time. This ccncept is rather static because the policy has already regarded user or application names in it. But oneM2M proposes also another way: "dynamic authorization":

Here come UMA into play. In the dynamic authorization...tbd

Identity Relationship Management (tbd)

Ownership and identity relationships

Things or objects in the IoT often have a relationship to real persons. These could be owner(s), manufacturer(s), user(s), administrator(s) or many other functions. A product might be owned by a manufacturer first and subsequently by a user who bought the product. The owner, user or administrator of an object might change over time. Ownership and identity relationships in the IoT have an impact on other identity related processes like e.g. authentication, authorization. The owner of a thing might be challenged for authentication or be asked for authorization policies.

User Consent Receipts

Identity Assurance Framework

Is the huge address pool of IPv6 a solution for Identities in IoT (tbd)?

Public classic IP-addresses (IPv4 addresses) are a rare resource. So the IT industry developed various approaches to deal with this situation. Mechanisms like "Network Address Translation (NAT)" or "Sub-netting" were developed to use address ranges in an optimal way. Access providers use IP-address pools and "re-use" IP-addresses by dynamic assignment. IP-address problem is not new. It has been an issue for many years. Recently the problem seems to get worse because billions of new devices appear with the Internet of Things. Not all, but many of them, also need an IP-Address.

The huge address space of IPv6 seems to solve this problem. And moreover sometimes IPv6 is seen as a universal address for the IoT. So why not give every IoT device a IPv6 address?

Apart from the fact that many IoT devices do not even have an IP stack the idea is not feasible A thing like a sensor or actuator can break, and the device may have a new IP-address. So a software system that wants to communicate with a thing would fail if it uses the IP-address directly. So it needs a mapping and discovery mechanism that translates the hardware address (IPv6 or even something else) to an identifier that is handled by the software system.


A thing is not always just one thing. Can a thing be composed of other things?

Yes! A simple webcam designed to feed video over the internet is clearly an IoT device.  Essentially is it a sensor without intelligence and does not respond to commands.

But if that webcam is part of a smartphone, does it remain a single device?  As a component of a smartphone, it is accompanied by a variety of other sensors (e.g., camera, microphone, touch screen) as well as a processor (the phone's CPU), and several actuators (e.g., speaker, video monitor, radio transmitter).   These various components may be accessed separately or in various groupings to provide disparate services.  Similarly, I may be willing to give the babysitter access to turn the speaker off when my baby goes to sleep, but not to the camera which I want to keep always on. This raises the question, "Does the phone constitute a single device?"  

For purposes of addressability, it likely has only a single IP address. But from the perspective of its functionality, each separate capability can be accessed and used separately.  E.g., I could leave a smartphone at home and access it remotely as a webcam to watch a baby in a crib, as a microphone to listen to the sounds in my house, as a speaker to give a direction to the babysitter, etc.

Protection mechanisms are not new to the internet. Why there is a challenge in IoT?

In 'classic' identity management certain protection methods have been established over the years to protect an identity from fraud and misuse. We have authentication methods to proof identities, secure channels to transmit identity attributes and passwords and other data are stored encrypted.


Security concepts like integrity, availability, authenticity,  non-repudiation are built in classic identity protocols like SAML and OpenID. In the Internet of Things the situation is different. Here, many communication protocols are not based on internet protocol. Many sensors or actuators have just restricted resources in terms of energy, bandwidth, connectivity. Protocols like enOcean[www.enocean.com] or KNX[www.knx.org]  use only few bytes to send commands or receive values. There is no room for encryption, challenge response procedure or other security mechanisms.

 

 

 

 


old content follows - to be revised

 

Authentication

The classic authentication mechanisms (ex.: login /password) may not directly work in the IoT. Objects have to provide some sort of lightweight token or certificate for an authentication where no user (providing a password) is involved. For stronger authentication means of individuals we usually combine two or multiple factors. These factors are based on following proofs:

  • “Something that you have"
  • “Something that you know”
  • “Something that you are” (e.g. biometrics)

In the IoT the last two proofs are not applicable to objects anymore.

How to find/address Things in the IoT? (DNS is not enough)

Various protocols

In the Internet of Things objects will be connected with different technologies and protocols. Many of the protocols are non-HTTP (Web)-based and some are even not IP-based. As a consequence not all objects in the Internet of Things have an IP-address. Different protocols use different kind of identifiers.

The drawback of hardware addresses for routing purpose

Even in case devices have an IP-based address it is not a good idea to code this address hard in an Application. The device or its interface might change and then all the software has to be corrected. That’s why usually a hardware address is mapped to a domain specific identifier.

For example: 

A heater control software will rather access www.example-weather.com instead of 164.12.34.56. That’s due to the fact that the weather forecast service might change his hosting service or simply move to another server infrastructure. In this case the IP address might change from 164.12.34.56 to 146.65.78.123. Thanks to a mapping service the domain name www.example-weather.com will stay the same.  A mapping service (here the Domain Name Service DNS) could be configured to provide the new IP-address for the same domain name. So the software will still work with the domain name while it will fail by using directly the IP address.

What’s the problem?

The weather forecast service in our example has a dedicated domain identifier according to the IETF RFC 1738 called universal resource identifier (URI). Many devices in the IoT don’t have such an identifier others do not have an IP-address. That’s why the classic domain name service (DNS) is not sufficient for the Internet of Tings.

Object Identifiers in the IoT

Object Identifiers are names assigned to things.  The things that are named can include logical or physical objects, and names can be given either to types of things or to the things themselves.  We can call the first a class identifier, since it refers to a class (or type, or category) of things; the latter an instance identifier. These terms come from computer programming, there may be other terms from ontology or elsewhere that are more suitable.  In the case of an automobile, the VIN is the instance identifier, while the make and model would be class identifiers.

On Object Identifiers vs ITU-T OIDs

Note that ITU-T defines a number of specifications pertaining to Object Identifiers (OIDs), but other implementations that are not ITU-T OIDs also can be considered Object Identifiers.  In this document we will use “OID” to refer to ITU-T OIDs, and “Object Identifier” to refer to the concept more broadly.

Types of Identifiers

  • Instances versus Class – does the identifier refer to a thing or to a type of thing?
  • Unique versus non-unique – is every identifier issued to only one object?
  • Synonyms versus no synonyms – are objects permitted multiple synonymous identifiers?
  • Governance options – How are names registered and managed?  Does one authority control the entire namespace, or is there hierarchical management?
  • Human-usable versus machine-usable
  • Global versus local namespace

Types of Objects

The concept of object identification applies to numerous types of objects. Names can identify specific instances of objects or they can refer to classes of object – consider a network device, it is important to identify the specific network interface associated with that device, and it is also important to identify the type of device.

  • Physical versus Logical
  • What else?

Physical Objects

Object Identifiers are applied to any number of things found in the physical world: computing devices, mobile devices, servers, network infrastructure, meters, sensors, cameras, actuators, locks, medical implants, vehicles (and vehicle components) and more.  Each of those things can be referenced by an identifier, and additional identifying information can be conveyed regarding relationships to other objects.  For example a server may have a unique hostname, but also be assigned a number of IP addresses corresponding to its physical network interfaces.  The full identification of the system would include the name of the server, the IP address of each network interface and the association between the server and the network interfaces. 

ITU-T OIDs can be used to refer to physical objects, prominently in the Management Information Base (MIBs) used by the Simple Network Management Protocol (SNMP).

Logical Objects

In addition to physical things, the area of identification of logical objects deserves consideration.  Logical objects include software, services, data and databases, documents and other digital objects, and more.  Identification of software is an area of considerable interest to a number of organizations, and approaches include Software ID Tags and the Common Platform Enumeration.  ITU-T OIDs can be used to refer to a number of logical objects, including (TBD pull from OID flyer).  Web services can be identified by the URL used to access them.  The Digital Object Identifier (DOI) standard is standardized as ISO 26324:2012, and provides a way of directly referencing digital objects as opposed to using a URL to identify how to access the document, which may not remain valid over time.






 

 Governance of object data


Objects in the "Internet of Things" produce data. These data might lead to personally identifiable information (PII). A car for example is able to track GPS positions and to provide a complete movement profile of a certain person.
Transparency
Although these data are mainly used for maintenance or additional services in automotive user information and consent should be mandatory.
Data minimization / data collection (in advance
Complex machines e.g. combine harvesters have hundreds of sensors that are able to produce tons of data. Data should not be collected if they are not used for a specific use-case.
TBD….
Issues

  1. Data Ownership/Control
    1. Who owns/controls data
      1. In a combine harvester or vehicle (truck, automobile, motorcycle), is the data owned by
        1. the manufacturer
        2. dealer
        3. service provider (e.g., maintenance/repair shop)
        4. harvester/vehicle owner
        5. each harvester/vehicle user
          1. employees
          2. clients
          3. prospective buyers
          4. family members
          5. friends
        6. other passengers (e.g., others whose GPS locations also become known)
          1. what happens when you pick up a stranger (hitch-hiker) or give a ride to the airport to an unknown colleague met at a conference
        7. a third-party who provides the sensor to support a service, such as
          1. disseminating aggregated data as a subscription service
          2. collecting driver behavioral data to determine insurance rates?
      2. from a data transaction that requires the interaction of multiple devices owned/controlled by multiple parties?
      3. when a device is sold?
  2. Consent
    1. Whose consent will be required for interactions that involve numerous sensors, controllers, and reporting devices
      1. For example,
        1. If an auto manufacturer owns data collected by a vehicle, will it require consent from the vehicle owner and service provider?
        2. Will each user be required to provide consent for data generated while they are driving?
      2. the same concerns apply to determining
  3. Data Ownership/Control/Consent Contracts
    1. NOTE: While the above issues can be managed by contract law, should there be an default data ownership/control model ?
      1. The rationale for such a model is that current contracts (e.g., privacy policies, web site terms of use) are one-sided that the negotiation asymmetry may be considered unfair.
  4. Identity discovery
    1. What attributes would an identity registry need to maintain to be of use to people or devices seeking sensor or controller devices to integrate into a solution
      1. For example,
        1. weather sensors
        2. traffic sensors
        3. location tracking sensors
        4. security sensors
        5. weather alerts
        6. traffic alerts
        7. location tracking alerts
        8. security alerts
    2. Will owners/users have the ability to prevent their devices from being discovered?
      1. Will they have some selectivity about who can discover their devices?
      2. Will they have some control over who can interrogate their devices?
  5. Identity impersonation
    1. How will devices preclude impersonation of the other devices with which they exchange data?
    2. Will each device that might generate, process, or report on private, sensitive, or confidential data be required to provide its own IAM capabilities to prevent fraudulent use?
    3. Will devices be required to develop usernames and passwords to interact with other devices? (How does my calendar system access a GPS system for my child's school bus, to minimize her waiting in the cold on a snowy day when traffic is behind schedule?)
      1. If so, who sets the username/password or other criteria?
      2. How will this information be stored securely?
      3. How will it be modified/updated?

 

 

References

ISO 19770 Syllabus

 

http://www.sassafras.com/iso/19770Syllabus.pdf 

 

SWID Schema

XML schema for ISO/IEC 19770 Software ID Tags

http://standards.iso.org/iso/19770/-2/2009/schema.xsd 

 

NIST IR 7693

Specification for Asset Identification

http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf 

 

NIST IR 7695

Common Platform Enumeration: Naming Specification Version 2.3

http://csrc.nist.gov/publications/nistir/ir7695/NISTIR-7695-CPE-Naming.pdf 

 

NIST IR 7696

Common Platform Enumeration : Name Matching Specification Version 2.3

http://csrc.nist.gov/publications/nistir/ir7696/NISTIR-7696-CPE-Matching.pdf 

 

NIST IR 7697

Common Platform Enumeration: Dictionary Specification Version 2.3

http://csrc.nist.gov/publications/nistir/ir7697/NISTIR-7697-CPE-Dictionary.pdf 

 

NIST IR 7698

Common Platform Enumeration: Applicability Language Specification Version 2.3

http://csrc.nist.gov/publications/nistir/ir7698/NISTIR-7698-CPE-Language.pdf 

 

NIST Cyber-Physical Systems

Cyber-Physical Systems or “smart” systems are co-engineered interacting networks of physical and computational components

http://www.nist.gov/cps/ 

IETF RFC 2578

Structure of Management Information Version 2 (SMIv2)

http://tools.ietf.org/html/rfc2578 

 

ITU-T X.672

Object identifier resolution system

http://www.itu.int/rec/T-REC-X.672-201008-I 

 

ITU-T X.660

Procedures for the

operation of object identifier registration

authorities: General procedures and top arcs of

the international object identifier tree

http://www.itu.int/rec/T-REC-X.660-199209-S/en 

 

ITU-T OID Flyer

“Object Identifiers and their Registration Authorities: Your Solution to Identification”

http://www.itu.int/dms_pub/itu-t/oth/0B/04/T0B040000482C01PDFE.pdf 

 

ISO 26324:2012

Digital object identifier system

http://www.iso.org/iso/catalogue_detail?csnumber=43506 

 

 

 

 

 

How is authentication realized in IoT today?