Cross-domain identity of things

Thomas Weidenfeller and Claudia Bausch, ericsson.com – 23 November, 2016 – The rapid expansion of the Internet of Things (IoT) calls for a clearer common understanding of how identities function in the digital world. The numerous domains that make up the IoT result in single entities having multiple overlapping identities. In order to operate successfully in this environment, a company must be able to manage related identities across domains in an efficient manner. To do so, it needs to determine which cross-domain identity management solution best meets its own specific requirements.

Identity is a concept used in fields ranging from philosophy to mathematics, with a variety of definitions. Even within the fields of ICT and IoT, the interpretation of the terms identity and identity management can vary widely, depending on the specific application and particular school of thought.

For many, identity management involves nothing more than giving a thing a traceable name or number, and perhaps adding a password or a public key certificate. For others, it means applying a consistent naming scheme or using a particular protocol to provide a computer with a host name, or a system user with a convenient sign-in experience.

According to ISO/IEC 24760-1:2011, an identity is “a set of attributes related to an entity”, and an entity is defined as “an item … that has a recognizably distinct existence” [1]. These definitions are very broad, and clearly cover more than just devices and people. For example, not only is an IoT device an entity according to this definition; all of its physical and virtual components are also entities, as are all of the actors that interact with them. The definition also covers parts and groups of such items, as long as they have a recognizably distinct existence.

From this perspective, even a small IoT device consists of many entities. Not every entity needs to have one or more identities, however; nor do all established identities need to be managed throughout the complete lifetime of the device. Defining the set of identities that need to be established, and working out how to manage them, are the result of decisions made on multiple levels at different times. For example, some identities are the result of design decisions about communication technologies or hardware component selection for a particular device.

It is also important to note that an identity does not necessarily have to be unique. For example, an identity can refer to a group of devices, such as in multicasting. An entity can also have – and typically has – more than one identity.

Entities, identities and domains

The application and validity of an identity tend to be finite, and are often dictated by technical limitations. For example, a private IP address has no global meaning; it only has meaning in a private network, and cannot be used on the internet. It is also possible to limit the applicability of an identity even further by design. The resulting domain of applicability describes where an identity may be used.

A car is an example of an entity that has multiple identities that are valid in different, partly overlapping, domains. A car receives its vehicle identification number (VIN) during the manufacturing process. The VIN is used by government agencies to track the car throughout its lifetime. The VIN’s domain of applicability is typically limited to administrative purposes. However, at some point the vehicle will also receive a license plate number, which is used to identify it in public. Its domain of applicability is the public realm. Both the VIN and the license plate number identify the same entity: a particular vehicle. Both should be registered to the same owner. Depending on the type of operation to be performed, a particular one of the two identities or identifiers will be used. In some cases, both might be required. However, rarely can one identity be provided in place of the other. Although they are separate, identities in different domains are related. In the car example, the relevant identity management systems (IDMSs) are designed to make it possible for government authorities to find out the license plate number from the VIN, and the VIN from the license plate number. When a license plate number is issued, identity management activities affect both domains to ensure traceability.

Understanding identity management

The term identity management is defined in ISO/IEC 24760–1:2011 as “the processes and policies involved in managing the lifecycle and values, type and optional metadata of attributes in identities known in a particular domain” [1].

The car example clearly illustrates that identity management is not about managing the entity itself (that is, performing operations on the entity). Rather, it is about managing “a set of attributes related to an entity” – data that describes or identifies the entity. Identity management is fundamentally a security technique – not an entity management one. As such, identity management supports the identity-based decisions [1] that must be made to ensure security.

Typical identity-based decisions that are related to security include device authentication, controlling authorizations (typical authentication, authorization and accounting functions) and the categorization of data. For example, identity based decisions can be used to ensure that the data returned by an IoT sensor (such as a temperature measurement) is associated with the correct entity (the machine from which the temperature was taken). In general, the routing of input and output data to and from an IoT device is based on identities.

The distinction between managing an entity and managing an entity’s identity is important. Managing identities can have side effects that impact the entity, but won’t necessarily. For instance, an attempt to manage an entity via identity management will at best be indirect, and at worst a complete failure.

For example, in geolocation applications, an entity’s location might be one of its identities. The entity might even be addressed (identified) by its location. Performing a particular identity management activity could affect the location data attribute in the identity register. But this change would have no effect on the entity’s actual position. In the best-case scenario, there would be additional mechanisms in place to take the identity management data and translate it into action that would in turn affect the entity itself, such as commanding it to move to the new location. This could work if the entity was a mobile machine, but would obviously fail if it were a factory building (the worst-case scenario).

The limitations of identity management are particularly significant for IoT devices. Identity management is no substitute for proper device management; rather, the two need to work in parallel. Device lifecycle changes must be supported by identity management activities.

The identity management lifecycle

Figure 1 provides an example of the lifecycle of an identity in terms of states and state transitions. This example is a modified version of the reference lifecycle model in ISO/IEC 24760–1:2011 [1]. Other lifecycle models may also be used, depending on the specific purpose of the particular identity. An IDMS supports the creation, provisioning, maintenance and decommissioning of identities throughout the lifecycle of a particular type of identity [1] following its lifecycle model. The lifecycle example in Figure 1 manages an identity within a specific domain. However, we know an entity can have more than one related identity within the same domain, or multiple identities spread over several domains. As a result, the requirements for a real-world IDMS extend beyond merely transitioning through the states for an identity.

Figure 1: Example of an identity lifecycle

The scenario involving multiple identities that is easiest to manage is when the related identities are within the same domain and under the control of the same authority. At the other end of the spectrum are scenarios in which the identities are in different domains, and are controlled by different authorities, and the relevant IDMSs are not able to communicate with each other.

Figure 2 illustrates the relationship between IDMS coupling and domains, and its impact on the relative difficulty of managing identity data. In cases where there is no communication between IDMSs, manual intervention and handling are mandatory. Such cases are therefore best avoided.

Figure 2: Relative difficulty of managing related identity data

Cross-domain management architectures

Two common cross-domain identity management architectures are particularly relevant to IoT identity management. The first, shown in Figure 3, uses one IDMS for coordination, giving it special authority among its peers.

Figure 3: Centrally coordinated IDMSs

The architecture shown in Figure 3 is similar to an architecture used in network management, in which individual element managers are each responsible for managing a particular network element, and a network management system coordinates network-wide issues above the element management layer. The architecture can be enhanced by adding hierarchy levels with intermediate coordinating IDMSs.

Figure 4 shows the second common architecture, in which the various IDMSs coordinate with other IDMSs on a peer-to-peer basis. Note that not every IDMS coordinates with every other IDMS; this depends on whether there is any need for them to coordinate, as well as technical or administrative limitations.

There are no hard and fast rules dictating which architecture is preferable. Other architectures also exist, including hybrid versions of the architectures presented in Figure 3 and 4. Practitioners need to consider their existing systems and any administrative barriers they may have, and make compromises, adapting their integrations to suit their particular circumstances. Ideally, they should establish one of the architecture options as the primary one and add diverging IDMS and management subsystems as satellite systems in isolated areas.

Figure 4: Peer-to-peer coordination

Techniques to build a coordinating system

There are technical and administrative issues to overcome when building a coordinating system. The technical issues begin with the communication layer. The individual IDMSs that should take part in cross-domain identity management as shown in Figure 3 and 4 need to communicate in some way – typically via the TCP/IP suite. When faced with legacy protocols on the network layer [2], an adaptation to IP should be considered. Which protocols to use on layers above the transport layer (particularly the application layer) is both a technical and an administrative decision.

Administration of cross-domain identity management includes the creation of an identity federation: “[an] agreement between two or more domains specifying how identity information will be exchanged and managed for cross-domain identification purposes.” [1] The system that is subsequently built according to this agreement is typically also known as an identity federation.

Single sign-on identity federation

One highly sought-after feature when building identity federations – especially when humans are involved – is single sign-on (SSO). With SSO, the identity of an entity in one domain can be used for authentication of the same entity in another domain. The purpose of SSO is to avoid having to perform identity management in two or more domains in parallel. This is achieved by having fully automated protocols and processes in the identity federation agreement for handling the data processing and exchange between the domains.

Enterprise and cloud system architectures are good examples of how cryptography-based identity federations can be used to provide SSO services. SAML, OpenID and OAuth 2.0 (with or without additional application programming interfaces like OpenID Connect) are typical protocols used to build SSO identity federations for authentication or authorization purposes in this context. Essentially, these protocols are used to exchange trust in an identity – and by association, an entity or groups of entities – between domains.

For humans, SSO is a highly valued convenience feature that removes tasks like remembering user login credentials. But for non-human IoT entities, which connect to a rather limited number of services, the use of identities and identity-based decisions in IoT device communication does not necessarily require SSO.

A typical IoT device might, for example, make use of the following services:

• a network service that provides basic communication
• a device management service provided via the Lightweight M2M (LWM2M) management protocol [3]
• a service management service provided via LWM2M, either separate from or in cooperation with the device management service
• a payload or application service to which the IoT device delivers data and from which it receives application information.

Since the number of services used is relatively static over the lifetime of the IoT device, and there is no human convenience advantage, an SSO-capable identity federation is not absolutely necessary in this type of case. In fact, for small IoT devices, the use of enterprise SSO protocols adds considerable overhead to the device firmware. When SSO is needed on an IoT device, lightweight SSO protocols should be considered instead.

The Generic Bootstrapping Architecture (GBA) [4] is a mobile network technology that makes it possible to reuse an identity from within the mobile network domain in other domains.

Solutions based on the GBA architecture make use of mobile network subscribers’ identities, associated cryptographic key material and cryptographic algorithms to establish a temporary, cryptographically-secured security association between an IoT device and a service in the application layer, for example. The security association can then be used for tasks such as authenticating the IoT device before granting access to the service. One promising realization of an identity management solution using GBA as a federation technique is a trial project for agricultural applications known as the Connected Vineyards project [5].

GBA uses well-known mobile network identity information providers (IIPS). A UICC/eUICC with a SIM application suitable for GBA is used in the IoT device, while the corresponding identity information on the mobile network side is provided by the Home Location Register/Home Subscriber Server.

Note that, although the 3GPP identity and GBA are currently associated with cellular networks, this technology can also be used for devices connected to a network using other, non-3GPP technologies. The identity credential (shared secret) and associated software may in this case be protected by hardware-specific isolation and protection mechanisms to avoid the extra cost of (e)UICC in IoT devices. GBA can also be used to extend the federation beyond SSO – for example, to provide cryptographically derived, temporary pre-shared keys to secure communication.

It is important to recognize that setting up an identity federation, for SSO purposes or otherwise, requires effort. The need to manage identities in multiple domains is replaced with the need to manage the federation. More importantly, an identity federation requires trust. An enrollment in one domain affects all federated domains, which means that improper identity proofing in one domain creates a potential security risk in all federated domains. However, in some cases – such as GBA – a mobile network operator with an established track record of managing signup and access to network services is in a good position to provide the necessary trust.

Mapping

The SSO identity federation protocols presented above all rely on sound cryptographic principles. The original identity data, including passwords and cryptographic material, are not copied between the domains. Only the trust in some identity – an identity assertion [1] – is exchanged, enabling a federated domain to authenticate an entity, and, if desired, bootstrap its own cryptographic material. This is not the only way to build an identity federation, however.

Another common way to build an identity federation is by mapping. Identity data valid in one domain is mapped to some other identity data in another domain. The mapping can be 1:1 (the data is copied as is) or with some adaptations. For example, the mapping could include adding supplementary identity data, or adding an identifier as an attribute to one’s own identity data.

One way to perform mapping is to synchronize at regular intervals. At certain points in time, the contents of two or more IIPS are compared with each other. Algorithms are then used to resolve any detected discrepancies and generate a consistent state across domains.

Tracking changes is another way to perform mapping. When this method is used, each of the state transitions shown in Figure 1 is communicated to the federated IDMSs. The IDMSs then map the received event data and add the result to their identity registers. A message bus is one possible software architecture that can be used for communication and exchange of events between the IDMSs.

Regardless of which of these two mapping methods is chosen, it is vital to address the issue of concurrent changes to the mapped data in the federated domains. This can be dealt with by considering one domain to be the master for particular identity data. That is, one domain always has precedence, or may even be the only domain in which the data is allowed to actively be changed. If this solution is not possible in a particular case, operational transformation techniques can be used to handle issues of concurrent changes, especially in the case of tracking changes. Three-way merge or differential synchronization are other techniques for resolving issues when tracking changes or synchronizing.

Identity management domains in the IoT

The selection criteria for identity domains in an IoT IDMS are largely technical, but they are also influenced by organizational factors and sometimes even individual preferences. Domains can be quite small or rather broad, containing only a few or many different types of identity data. Figure 5 illustrates four identity management domains that capture the technical and organizational properties of an IoT system at a high level:

• service user domain – where the IoT system is exploited for benefits. Services on top of the IoT device(s) are provided here. They supply a machine or a human with accumulated data and value-added services.
• service management domain – where the application(s) and/or service(s) running on the IoT device are managed, along with their association with enterprise application servers responsible for dealing with the payload data. A service delivery platform would work in this domain, for example.
• device management domain – where basic device functions are managed, including the device lifecycle and firmware (operating system). Services based on the LWM2M protocol would run here, for example.
• network domain – the “I” in IoT, where the communication happens, such as a cellular network or another type of WAN, or a LAN