Wireless Pers Commun (2008) 45:521–543 DOI 10.1007/s11277-008-9475-4
Virtual Identity Framework for Telecom Infrastructures Amardeo Sarma · Alfredo Matos · João Girão · Rui L. Aguiar
Published online: 29 February 2008 © Springer Science+Business Media, LLC. 2008
Abstract Identity Management has so far been a field mainly applications and Web focused. This paper describes a novel approach to cross layer identity management that extends digital identities to the network, the virtual identity (VID) framework. The VID framework provides strong privacy to the user, while easily supporting personalization crossservice providers. While other identity management solutions are tailored to one specific application and/or protocol domain, the proposed framework extends the use of one’s digital identity to all aspects of the network and services architecture. It is also the first to consider legal constrains, such as ownership of data and legal intercept issues, in such a broad scope. One major aspect reported here is the relevance for operators. Keywords Identity · Virtual identity · Digital identity · Security · Privacy · Telecommunications
1 Introduction The question that concerns most network operators is how they can prevent themselves from becoming a “bit pipe”. A major trend for operators has been a movement from volume or time-based charging to flat-rate schemes, which customers now take for granted. Competition
A. Sarma (B) · J. Girão NEC Laboratories Europe, Kurfürstenanlage 36, 69115 Heidelberg, Germany e-mail:
[email protected] J. Girão e-mail:
[email protected] A. Matos · R. L. Aguiar IT Aveiro Universidade de Aveiro Campus Universitário Santiago, 3810-193 Aveiro, Portugal e-mail:
[email protected] R. L. Aguiar e-mail:
[email protected]
123
522
A. Sarma et al.
is often carried out through lower costs or higher bandwidth, but especially the latter is often something customers will not pay more for. Some other developments give an indication of what customers want and are willing to pay for, mainly related to their experienced service quality, which of course includes their access to the underlying infrastructure. Today’s customers want access everywhere – even while moving – and require this in a seamless fashion. Some companies have tried to address this need, such as operators offering access to WLAN hot spots as part of their flat rate [1], where customers identify themselves with their ISP name and password. Mobile operators offer their customers SIM cards for identification, but these are very much terminal oriented and cannot so far be used much beyond 2G and 3G networks, although some recent efforts on SMS-based payment services. Current operator ambitions rely mainly at going “up the value chain” to offer services, applications or “experiences”. This focus seems to neglect some value added that operators can provide as companies with a very special and often long-standing relationship with their customers, probably their major asset besides their being able to issue millions of bills per month. Network access remains far from “ubiquitous” for the customer. Such ubiquitous access as a service could be far more valuable to customers than just increasing the bit rate. The customer would like to use “fixed” and mobile in basically the same way. At the same time, customers, in particular in Europe and USA, are increasingly unwilling to provide information about themselves under uncertain circumstances. This privacy concern could be a severe impediment to wide deployment of federated access techniques. Besides having a comfortable access, customers need to be able to trust and rely on the system they intend to access, a trust that should be built over time. Operators do retain that trust currently, and can profit from it, but have been unable to solve its customer’s problems. The current situation is that user’s information, the digital representation of their identity as data, is distributed and duplicated among different platforms resulting in: • • • • •
Inconsistent data Multiple sign-on procedures for different services Inability to make use of data across platforms even if that is in the best interest of the user Difficulty for the user to manage and control privacy information across platforms Difficulty of the user to retain control over all his digital information.
Digital Identities, a unifying concept on the representation of the user data in digital formats, have the potential to be a breakthrough and convergence technology that addresses these concerns. The Virtual Identities concept developed in Daidalos [2] adds another dimension of flexibility to digital identities, making privacy and the multiplicity of roles part and parcel of the solution. The VID approach seems especially adequate to be deployed by telecommunication operators, exploiting the trust relationships already existent. The next session covers related work, while Sect. 3 introduces the Virtual Identity framework as such. Section 4 then introduces our virtual identity model, followed by a presentation of the framework architecture and a Sect. 6 discussing framework features. A final section with conclusions finishes the paper.
2 Related Work So far, Identity has been an application level feature, focusing mainly on Internet-based scenarios. Several architectures and protocols follow this approach to user identity, using
123
Virtual Identity Framework for Telecom Infrastructures
523
concepts such as Identity providers and service providers, relying on HTTP/XML based protocols and web services. Liberty alliance [3] is one of such proposed approaches based on an architecture for Federated Identity. It is an Internet-based standard, focusing mostly on web service scenarios, covering the interactions between their main actors: users, identity providers and service providers. It relies on web services to deliver single-sign on (SSO), and further focuses on an interoperable identity provider scheme that provides privacy and security to the end-user. Earlier Internet oriented schemes such as Microsoft Passport [4] also provide a SSO environment for internet based applications. Passport was an SSO mechanism that later evolved into Windows Live ID, which provided a consistent user account across different services along with a single authentication mechanism used across multiple services. This has been stagnating due to the shift towards Microsoft Cardspace [5], which is foremost a metaphor that provides information cards as a tangible identity management concept to the user. Cardspace builds on web services, but aims at being a metasystem, and can be integrated with other identity management solutions, such as OpenID [6], making them complementary solutions. As the other technologies mentioned, Microsoft Cardspace focuses on Internet-based services. With the emergence of the Web 2.0 phenomena, OpenID [6] has gained momentum as widespread user adoption grows. It is also an Internet based Identity Management system, where users are identified by URLs. Using the concept of Users, Relying parties and Identity providers, it enables SSO, secure authentication and attribute exchange. It provides the expected and necessary features for the basis of an identity system, but only tackles application (web) based concepts, extremely biased towards Internet-based services. All of the mentioned technologies are agnostic to lower layers, and fail to address the “network side of things”. At the same time, there is already a large amount of identity information that resides scattered across the network stack. But, on the lower layers, such identities are usually tied to devices and protocols rather than to the user and his digital identity. This is observed in GSM [7] and UMTS [8]. The Subscriber Identity Module (SIM) and the Universal Subscriber Identity Model (USIM) are in fact cards that store the International Mobile Subscriber Identity (IMSI), which is a unique number that identifies the user, and acts as a key for network access. The SIM (or the USIM) can be perceived as the “user”, or a representation of the user. There is a tightly coupled view of the device and the user in this model. If we consider the TCP/IP network stack, we also find identity information. Unique protocol and network identifiers provide simple handles to recognize or identify a specific user. At the link layer, the terminal is identified by its unique MAC addresses. At the network layer, this is achieved by a public IPv4 or a global IPv6 addresses. Mobility bound identifiers, such as the MIPv6 [9] Home Address, are also unique. These addresses identify both the user and terminal, since they are tightly coupled. Furthermore, some addresses are tied to public keys, such as the proposals for Cryptographically Generated Addresses [10]. The key can be bound to the user identity or to the terminal, leading to more information based on identity acting as singleton information pieces, with no real link to the upper layer identity concept. Every piece of information mentioned in the preceding paragraphs identifies the user, or at least some part of the user identity, regardless of its intent to disclose this information. Each of these protocol or network identifiers either uniquely maps to the user or to the device being used by the user. The lower layers are thus a grey zone, where the user is the device, and the device is the user. And no concerns on user privacy, or identity protection, exist. The network stack currently does not support the semantics of several digital identities representing the same user, which may be used for different purposes or actions, or for different
123
524
A. Sarma et al.
roles. While this is simple to address at the application level, the task becomes complex at the network level, where you can have "two personas" representing the same or different users simultaneously in the same device. These problems have been recently addressed in large recent projects. For instance, Privacy and Identity Management for Europe (PRIME) [11] is a European research project that aims to develop and promote Privacy Enhancing Technologies, based on Identity Management Systems. Their primary goal is to enhance user control over the overwhelming amount of data scattered through different networks. They also use the concept of virtual personae, referring to them as “partial identities”. Also, Future of Identity in the Information Society (FIDIS) [12] is another European research project which focuses on privacy and identity management. It aims at supporting interoperability of identity with prevailing security. It supports concepts such as anonymity and pseudonymity under the hat of virtual identities. Both of previous research projects also have a large concern in defining scenarios and requirements for next-generation identity management systems. Their concerns are now reaching mainstream telecommunication. Some of the associated problems are noted in the ITU Internet Report 2006 digital.life [13]. The ITU-T Focus Group on Identity Management [14] has developed use cases and requirements during 2007, often targeting Next Generation Networks (NGN) and specific scenarios, such as IPTV, but also dealing with cross-layer issues. In this work, we aim to complement the above efforts, and present a framework, an Identity Infrastructure, that globally maps all the identifiers (ranging from link to application layers) to the same coherent namespace. This is done with a consistent approach which assures user’s privacy, while retaining all flexibility for service personalization. As our approach pays particular attention to network aspects, it is especially relevant for current telecommunication operators.
3 Virtual Identity Framework Considerations The goals of the virtual identity framework are to overcome the shortcomings described above, and in particular to achieve the following: • • • • •
Link identification to the user, not the device Assure seamless network access, making it ubiquitous Allow access while on the move even across devices (user mobility rather than terminal mobility) - In fact this removes the limitation of owning a device that travels with the user Simplify usage and billing, enabling the user to limit customer relationships to one or a few trusted providers Simplified management and control of private information across platforms, enabling the use of hired or embedded devices
In short, this aims to put the user, not the terminal, at the centre of the communications, and preserve users’ control even towards its network provider. Figure 1 illustrates a user-centric view of the world, realized by a Virtual Identity Framework. The user, in one of several roles (worker, boss, father), uses one of many access possibilities (DSL, Car2Car, ..) to access the digital world, such as at home, in the office or to do shopping. Each such use could correspond to a specific “virtual identity” of the user, and different providers will only perceive the information which the users so desires – regardless of the communication layer that they operate.
123
Virtual Identity Framework for Telecom Infrastructures
525
Fig. 1 The virtual digital world for a user
VID Identifiers may be linked to real person or digital certificate
User
User constructs VIDs for Access VID
VID
....
VID
passport
Registered ID
credentials
driver‘s license
Verify
Government GovernmentID ID++data data (Municipal authority, local office) Association
RegID RegID++data dataof ofID IDprovider provider (Operator, Bank) (Operator, Bank) Contract
Physical Person (DNA, behaviour, Personal attributes) Fig. 2 Virtual identity model
The overall framework links the real and the digital worlds, thereby considering various contractual and contract-like relationships that a user has. These relationships serve to vouch for some aspects of the user’s attributes, such as nationality, driving capability or financial credibility. Nonetheless, the user should remain in control of own sensitive data. In addition, various contractual partners should be able to exchange user data in a controlled way (federation), while respecting both the users’ and the contractual partners’ needs. Figure 2 illustrates the basic approach. To begin with, we note that the Virtual Identify VID reflects a collection of data constructed by the user for a particular purpose. It contains an identifier, called VID Identifier (VIDID), but he VID itself is far more than being an identifier. Though the VID concept is not restricted to persons, we use persons for explanation purposes as the starting point—the extension of this to other entities1 is afterwards immediate. The “Physical Person” on Fig. 2 is the real identity (or uniqueness over time) of the person with all its associated attributes. Some of these attributes may change without affecting the identity. Such uniqueness over time may also be held by legal persons, such as companies or societies, though their uniqueness over time is more easily challenged. Often, in common language and in public debates, “identity” is also used to denote belonging to a specific group, reflected in terms such as “national identity” or “religious identity”. This latter usage is not more than a user attribute or group membership, not different in principle from, e.g., 1 We use the generic notion of entity, in order to avoid a confusion of terms. A physical person is an example
of an entity.
123
526
A. Sarma et al.
the person’s residence. These “common language identities” are dealt in our model us as attributes or properties of a real identity. Already today, many attributes or properties of a physical person are stored by contractual partners and governmental organizations. A birth certificate, a driver’s license or a passport are examples that reflect data stored at an office, and may contain user data, such as date of birth, ability to drive, names of parents or address. These credentials – or issued identities – are then directly used for purposes such as travel to some other countries. A very different type of issued identity is the SIM card, which stores data related to mobile network access rights and a link to the person using it. These issued identities are not only inflexible, because they cannot easily federate across organizations, but they also do not allow the user to control what information is revealed. At the other end, for the web and for applications, we often have names and passwords as the issued identity. This domain is what we term the “Registered ID” (Fig. 2) extended to some issued identities. 3.1 Adding Flexibility to Real-world Schemes The Virtual Identity (VID) Framework builds on such real world schemes, but adds a new dimension of flexibility to enable fulfilling requirements that are difficult or impossible to fulfill otherwise. Credentials that allow the user to make well-defined assertions can be used by the user to construct virtual identities, each of which reflects a specific scope of use, which may be linked to role or persona. The overall data contained in such a virtual identity is under full control of the user, and brings together an intended scope of use, such as reflecting a private person who does not want to reveal any personal information for use in a low cost sector only. It should be noted that the user does not even need to reveal all the data of the VID when accessing a service: the revealed VID data can be filtered to whatever is needed or whatever the user wants to reveal. This Framework presents a new approach in computer communication systems. When access to the Internet and other communication infrastructures and services becomes no longer a privilege of the few, the VID will open the door to your digital identity online. In this new era, we must respect the individuality and privacy of all. The use of a network, such as the Internet, allows for the information about who we are at work and who we are at home to be linked, allowing anyone with the knowledge to ask the right questions too much personal insight. The VID shields user information from other types of information, thus protecting the user’s personal life, e.g. relieving the user from the worry that the bank has access to information about services he paid for. To fulfill such requirements and assumptions, we propose the VID Framework which, bound to the law, presents its users with a range of new and interesting possibilities in the fields of privacy, identity and federation. We expand this paradigm from the relations between banks, operators and service providers to an active role that the digital identity has in the lower layers of transport, link layer and even eventually, the physical layer. The VID Framework contemplates the multitude of identities and roles we take on each time we turn on our computer, mobile phone or PDA. Online, only the required subset of the identity information that is acceptable to the user should be disclosed. Depending on the situation, anonymity and even lying about name, profession, age, etc. should be possible. What is needed widely varies and rarely requires detailed personal information. In some cases, only the ability to pay is required, in other cases proof is needed about being above some age limit or about being citizen of some country. Nevertheless, legal tracking capabilities will need to be supported.
123
Virtual Identity Framework for Telecom Infrastructures
527
Since all these attributes are part of the overall digital identity, the user should have control over what is disclosed when accessing a service, and should have the choice on whether this information is kept private or shared with others. If the information needed by the service provider is more than what the user is willing to provide, the service may fail. Also, legal considerations allow protection overrides. Users are not the only ones with possibly several (virtual or digital) identities. Any entity capable of establishing legal relations with other entities can benefit from this framework. We propose that users, groups, service providers, network operators and even banks all share this identity framework and utilize it to communicate with each other and establish their relations, not based solely on their ‘real’ identity but also on their ‘virtual’ one. 3.2 Guidelines to VID Architecture Design Most of the following objectives have been guidelines to the VID architecture design, as well as defining what is provided by the framework. 3.2.1 Privacy Today, users travel from and in networks with no concern for their privacy or even awareness of privacy threats. Wherever they go and connect their devices, they inform the world of their presence and movement. One of the main objectives of this framework is that the user not only regains control of his data, but also that he can access the network via distinct untraceable “avatars”. The network and service layers, including the operators owning them, cannot link two different avatars to the same user unless he allows it. In addition, the user will control which information is linked to which avatar and can create distinct Virtual Identities (VIDs) to access the network and services. We thus propose a mapping of the users’ multiple identities into multiple network counterparts. This allows us to devise a mechanism that enhances user privacy by maintaining attributes for each of these network counterparts separately, which also separates individual service and network perspectives. 3.2.2 Unification and Uniformity Since our VID concept cuts across layers, we also use it to unify the handles by which users or services represented by the VID’s access data across different layers. This imposes uniformity in protocol design, which simplifies the process by which data is stored, archived, transported and used. The vision is that, in next generation networks, the VID maintains its semantics at all layers and can be accessed, depending on the circumstances, by different network components such as the multimedia services, billing, charging, accounting, metering, authentication or authorization. 3.2.3 Contractual Information Although the access to the network, as well as to services, is restricted to the knowledge of the VID, most of the user’s contractual data still has to be handled in relation to his real identity. Either directly or indirectly, by cross-certification, the entity, which issues the contract, must be ensured that this is a valid person. In most cases this means that she can pay for the services in the contract.
123
528
A. Sarma et al.
All contractual information is then translated to a language the network can understand, verify and account for. This information is then linked to the user’s VID, by the user himself. This information includes all QoS, authorization and authentication to the network information as well as any other contractual binding data. 3.2.4 Context Data Context data or context information characterizes the current situation of an entity. This information can either be relevant for the entity itself or of broader interest. In consequence, two different kinds of context data have to be distinguished: Context data bound to a VID and context data independent of a VID. In the first case, context data is associated to VIDs and represented only in relation to that same VID. The architecture itself has no notion of user. The mechanism by which entities access and provide context has to consider the VID concept. In the second case, context data is considered as a tradable commodity and should be decoupled from the acquiring context source. Furthermore, this context data must not be linked to a VID of the providing entity. Context is also one of the most critical parameters, which can be used to link two or more different VIDs of one entity. Therefore, an entity has to pay special attention to ensure that context data cannot be used to link two or more VIDs. One measure to achieve this is context obfuscation. Nevertheless, this is a grey area in which no solution covers all angles since the concepts of context and VID privacy are somewhat contradictory. In another paper in this issue, the potential for a network to know all relevant data about users is highlighted. 3.2.5 Access Control The rules the user sets on the attributes of his VIDs filter the information a service or operator can see. The user presents only a small part of the information of the VID to a service. Access control provides such a “filtered” VID to limit the view on that identity to the amount needed by the service and desired by the user. Another important concept is that of ownership of the VID and its components. Even though a user may own the VID, it does not mean that he has full control over its parts, such as changing age or physical properties, nor does it mean that he owns all the information contained in it. A VID is composed of information linked to the avatar of the user, which comes from many different places. The nature of the information in the VID also determines who owns it. Information resulting from a contractual right of the user is under the control of the user, to be used as deemed fit. On the other hand, information about contractual obligations of the user will need to be enforced by contracted business entity and thus cannot therefore be under full control of the user. For example, the maximum QoS level the user has a right to use is under his control while related metering information is not, since it represents a contractual obligation. 3.2.6 Billing and Charging Current platform makes a strong distinction between the charging and billing. The user might have a bank account, which he uses to pay a network operator, but at the same time use his network operator account to pay for his services. This means that the services do not know his identity, other than he has a valid network operator account, and the bank does not know which services the user has registered, since it only sees the bill from the network operator.
123
Virtual Identity Framework for Telecom Infrastructures
529
Fig. 3 Virtual identity concept
4 Virtual Identity Model In this section, we describe the virtual identity model, which is a fundament aspect of this framework. One of its core properties is that it is a cross-layer approach (see Fig. 3) which: • • • • • •
Supports uniform namespaces (one ID for all purposes) Is well suited to network identification Allows obtaining information about a user/service/group in a controlled manner Maintains pseudonymity at a higher level Enables a top-down protocol design Is independent of the application, service, interface and even terminal
The following describes the fundamental concepts that constitute this framework. A clear definition of the terms used will help define the target and parameters. Their usage is then described in a later subsection. 4.1 Entity An entity is any actor or “real identity” that is potentially able to establish legal, contractual bindings with other actors. The most common entities are users, service providers, network operators, banks or groups of any of the former. Although network components, software components, etc which act on the behalf of an entity do not have a VID by themselves, they can exploit the identity which owns them. Several types of entities may exist: • User in the VID framework, the user is an abstract entity. The user is not represented directly in the architecture, but rather impacts the architecture by using VIDs, network elements, services, etc., which do have a network representation. A user is able to create legal bindings with other entities, which allow the user to create VIDs and to utilize the services underlying the architecture. • Group A group is a set of entities which also can be represented by a VID. A group can also be seen as an entity with a set of common attributes, and may be treated by the architecture
123
530
A. Sarma et al.
as one. Such a group, in contrast to a legal entity, does not necessarily exhibit the identity properties of being identifiable as the same group over time. For simplification, we often also use the term Service Provider, a user with responsibility for a set of services. This entity is usually linked to an enterprise or to a person (legally responsible and able to establish contracts with others). 4.2 Entity Profile The entity profile (EP) is an abstract concept, which represents all the entity profile parts (EPP), described below, related to an entity, as well as the knowledge possessed only by the entity itself. It contains every piece of information, in the network or otherwise, related to the entity. There is but one EP per entity with all information needed for any purpose in the digital world. This concept will allow us to define how a user builds his Virtual Identities and chooses which information is contained in them. Note that there is probably not a single well-defined place where the EP is stored, but it is the collective set of information, dispersed through multiple databases. 4.3 Entity Profile Part (EPP) The EPP is a system representation of partial information on the entity’s profile. This means that the entity will have a set of attributes, which can be joined together to form an EPP. The rule for creating an EPP is that it should be the minimum consistent and coherent set of data, which can be extracted from the entity’s profile. Although the previous sentence is subject to several interpretations, the following example should clarify its intended usage: If a contract between a user and a network operator ensures the user up to a certain level of QoS and the authorization to use a certain service, this information should not be contained in one EPP but rather two: one for the QoS information and another for the service authorization. This allows the user to compose VIDs which contain one or the other. He can then set access control rules which allow a service to see up to QoS level X, where X is lower or equal to the one in his contract, and another set of independent rules relative to his authorization information. An EPP consists of a set of attributes, which are atomic (cannot be broken into smaller parts). These attributes contain the information, which belongs to the EPP. We can also look at an EPP as a block of data, which exists in a database in the system. This block of data can be read, written into, copied and acted upon. The above QoS example would then read for example as follows: There is one EPP that describes (in an ontological manner) the QoS level. Dependent on the recipient, any combination of the following can be chosen to be appropriate: sustained bandwidth, peak rate, loss rate, mean delay, peak delay, jitter, etc. These are the attributes of the EPP and the selection is done by means of the filtered EPV. 4.4 Entity Profile View (EPV) – The Virtual Identity (VID) The VID represents a user’s avatar or persona in the network. It is a subset of the EPPs that compose the EP. The VIDs are used to reflect different circumstances, and are intended for use such that it is difficult or impossible for an attacker to link them. The Filtered EPV description below illustrates how this is done. It is expected for a user to have, in average, 5–7
123
Virtual Identity Framework for Telecom Infrastructures 0
531
15
Realm
63
Index
Fig. 4 VIDID—The virtual identity identifier
different VIDs. Managing more than this may prove difficult from both a user and network perspective. 4.5 Entity Profile View Handler (EPVH) – The Virtual Identity Identifier (VIDID) The same way the VID represents the information, the VIDID (Fig. 4) is the identifier which allows us to reach the information. It is composed of two parts: a ‘realm’ identifier, which maps to the server responsible for the VID, and a flat identifier, which, while not revealing any information about the owner, uniquely identifies the VID within a certain realm. The length of the VIDID is in direct relation to the diameter of the Internet and the number of expected identities which use it. In fact, a VIDID should uniquely identify a user’s VID in a certain realm (this format allows 248 such users per realm, and 216 realms). 4.6 Filtered Entity Profile View (FEPV) A filtered entity profile view is the subset of data of an EPV (or VID) that is revealed to the outside world, such as to gain access to a particular system. While the use of distinct FEPVs as a subset of the same EPV may be identified as belonging to that particular EPV, two FEPVs representing different VIDs should be completely distinct in all revealed data to make it impossible to link different VIDs. Of course, the owner of the VID has the power to allow this cross-linkage. 4.7 Access Control As previously described the access to a VID’s EPPs is subject to access control. In fact, the user can define access control rules over any of the EPPs up to the EPP attribute granularity. Access control can be applied during the mapping from VIDID to EPP or in the access to the actual data. If the access is only done in the latter, this will always reveal that some information about the queried EPP exists. Also, to perform access control in the accessing of the data, the rule must exist in the point of control (where the EPP is stored). We might not always want to reveal who is accessing the information (other than he is eligible). The VID selection and Access Control paradigms act on different levels. While the VID is a structural partition of the entity’s identity at the architectural level, access control affects the services and network transport plane. 4.8 Data Types The VID Model has to support multiple data types: • Authorization Data and Authentication Data: One of the most important parts of enforcing a contract is that the system knows the entity, and in some cases can even prove a past action or association. This falls onto the security paradigms of authentication and autho-
123
532
• •
•
• •
A. Sarma et al.
rization. It is therefore natural that such information related to a particular entity can be part of an EPP. Quality of Service (QoS) Data: Another parameter which is contractual and relevant to entities (and in particular users) is QoS. These EPPs are particularly important since, much like the previous data type, several deployment aspects depend on them. Metering, Accounting and Charging Data: The entities, which use the network and services, and sometimes entities, which are used by others, must, in the end, follow their contractual obligations and pay for the benefit they took from the system. The information on how much the user must pay is related to metering, accounting and charging, therefore this type of information can also be part of an EPP. Billing Data: As said before, one of the assets of the telecom operators is the relationship with the user, and a user can proxy his billing from a bank to a network operator, to a service provider, etc. In the end, the user’s account must be charged and this information is an EPP which has billing information. It can contain the user’s bank account or credit card or just a pointer to which entity is responsible for payment. The authorization on the charge is, in some cases, also proxied; while in others, such as the pre-paid case, the authorization is pre-established. Context Data: The EPV/VID is bound to the relevant context by means of EPPs. When context information is accessed by an entity in the network, the request must go through the same access control mechanisms as for any other data, which is part of an EPP. Personalization Data: Personalization, just like context, is bound to the EPV/VID. This means that, even though the entity can explicitly copy EPPs, and therefore also preferences and personalization history, each VID has otherwise distinct personalization related EPPs. By copying this information, and thus using the same preferences and personalization history for more than one VID/EPV, an entity is reducing the privacy aspect of the VID framework and makes linking of two different VID/EPV more likely. This should be avoided as much as possible.
4.9 Model Overview Figure 5 shows an overview on the VID model. An “entity” can either be a common user or a group of users. On the left hand side there are several parts of the profile about this entity. These entity profile parts (EPPs) stem from different contracts at different networks and/or services. For example, the data about a user may be stored at Telecom Italia through her Italian subscription, while the profile is stored at Deutsche Telekom from her German subscription. In the middle there is the aggregated logical profile about the entity consisting of all profile parts, called entity profile (EP). It is important to note that the EP is an abstract notion that is not stored anywhere as data. On the right hand side, several views on this overall profile are shown. These so-called entity profile views (EPVs) represent a subset of the EP as seen by the user. This EPV is in fact the VID of the user, and has all the relevant data2 the user would like to use in a particular situation to use the services of a provider. It can be seen that there is a logical profile, the EP. Furthermore, it can be seen that different views, the EPVs, can be opened on this EP. The views are only pointers to the real entity profile parts and implicitly to entity attributes stored in a database, e.g., operated by a provider. This means that if the user changes an attribute in her profile at Deutsche Telekom, it is changed in all views that contain this attribute. To
2 Which part of the EPV can be seen by a correspondent provider entity is covered by the FEPV concept.
123
Virtual Identity Framework for Telecom Infrastructures
533
Fig. 5 VID data model
make one property of the concept of EPV more explicit, the EPV is created by accumulation of references to EPPs and not by copying EPPs. An overall entity profile is to be considered as a pool of entity profile parts and hence implicitly of entity attributes about the respective entity from which pieces can be picked and assembled in a view on this entity. The FEPV is an extract of the EPV that is shown to 3rd parties, for example to access a service. This FEPV, which relates to one EPV (n:1) relation has an identifier, henceforth called VIDID that also identifies the EPV or VID. This VIDID is a pure technical means to manage the concept of EPV inside the platform and does not necessarily serve Human-Machine-Interface purposes.3 Therefore, on top of the VIDID a more human friendly identifier namespace can be setup, which is then to be uniquely mapped to the VIDID namespace. Human friendly identifiers can be, e.g., an email address or a SIP URI. 4.10 Federation of Entity Profile Data Figure 6 shows that an entity profile consists of various entity profile parts, which themselves comprise a set of attributes about the entity. Common (but not exhaustive) examples are: • Preferences of the entity for personalization of resources (services); • Authorizations, which the entity has; • Handles to different accounts, which the entity can include in order to be charged for a resource (service) consumption; • Typical context information related to this entity, e.g., the location. Moreover, the different parts from different subscriptions build a logical entity profile being a result of a data federation across entity profile parts. It is possible that several provider federations exist and that they do not allow a federation of their entity profile data across their domains, as portrayed in Fig. 6. For example, the entity profile part stored at Vodafone is not allowed to be referenced in the same EPV as the entity 3 In other words, machine readability is primary focus whereas human readability is secondary.
123
534
A. Sarma et al.
Logical View (Database Federation)
Physical View EPP @ Deutsche Telekom PP 1 AP 1 HA 1 CT 1
Data Federation Entity Profile Personalization Policies
EPP @ Playboy Inc. A4C Policies PP 2 AP 2 HA 2 CT 2
Handle Accounts Context Information
Privacy Boundary Not allowed
EPP @ Telecom Italia
Entity Profile
PP 3 AP 3 HA 3 CT 3
PP AP HA CT
Fig. 6 Entity profile data with federation constraints
profile part at Deutsche Telekom. As a result, each entity or component acting on behalf of this entity maintains one EP per federation to respect the boundaries of federations.
5 The Virtual Identity Architecture We have so far explored the conceptual aspects of the novel Identity Management model. But, to support such flexible concepts, we define a few core components that provide sustainability for identity oriented operations and functionality. Unified and uniform Namespaces enable the user to be reached despite a very heterogeneous environment and must rely on a common entry point for identity information, which safeguards consistent access to privileged information based on the VIDID resolution and credentials. Therefore, access control, which allows the user and the provider to limit access by others to the user or to user data based on well-defined criteria or rules, must use architectural components. These components need to be tightly coupled with the billing and charging infrastructure, the AAA [15] or A4C backend, enabling charged services to be offered in a flexible way, allowing the user to aggregate billing to one or a few billing entities. Finally, the base components must provide strong privacy policies, enabling the user to protect her data as desired, i.e., to prevent disclosing its own attributes and to limit reachability. The common denominators for all the aforementioned operations are two specific functional pieces: The Identity Manager (ID-Manager) and the Identity Broker (ID-Broker). Here, we present the basic Identity Framework components and how they facilitate identity oriented operations.
123
Virtual Identity Framework for Telecom Infrastructures
535
5.1 Identity Manager The responsibility of the Identity Manager box is to handle VID creation and maintenance. While providing the interface for creating, managing and destroying VIDs, it becomes the repository for context and personalization information, which is not stored on distributed EPPs. It is one of the trusted components on the architecture, since it handles on one side the VID information that the user chooses to store on the network and to the other, it may retain information that is considered sensitive, acting as an EPP repository for specific data, and applying several control policies on the data it stores. The ID Manager has strong relations to the ID Broker. 5.2 Identity Broker The Identity Broker component provides the location of the EPP or proxy to the requester, and forwards the request to the holder of the EPP (the place where it is stored). The Identity Broker thus becomes the main contact point for identity information and the preferred location to set the initial privacy and content access policies. Depending on the operation mode, different amounts of trust are placed at the Identity Broker. If the ID-Broker only redirects requests, the burden of policy control is redirected to the EPP holders and possibly the Identity Manager. But when applying access control rules directly on the mapping and content access, pointing to different locations depending on the requesting entity, it becomes a more crucial architecture component. The ID-Broker must therefore be fluent in handling VIDIDs, since this is the preferred notation to handle the unified namespaces. The process of resolving and accessing information through the identity broker are described below. 5.2.1 Identity Brokerage The ID-Broker is the component that is responsible for mapping the revealed FEPV to the EPPs, and possibly also applying some access control rules and actions. It is called a broker because it redirects requests on EPPs on a certain VID representing the FEPV. It is most likely the component identified by the realm part of the VIDID. The ID broker is the first contact point in a realm, although it may be possible that the requests are forwarded to a different machine. With only the VIDID to resolve information on a certain VID, the requester uses the realm part to contact the right ID Broker and the id part of the VIDID to identify the VID in that realm. More than this, he has to provide which EPP he wants to access, and possibly some credentials, which are to be used in the context of access control. The ID Broker will keep a table of the VIDID, the associated EPPs and their types as well as the place where they are stored. One of the most important functions of the ID-Broker is to perform access control on who accesses information and what information is accessed. For this it is required that several tiers of access control are applied, enabling a consistent, privacy preserving approach to Identity Information. Figure 7 illustrates such usage. Access control on the EPP: This is the simplest form of access control: directly on the data storage place. The broker will always direct the requesting entity to the right storage place (the storage place can already reveal information for linking VIDs, e.g., referring to the same attribute.). Access control is then performed directly as the requesting entity attempts to access the information. The drawback is the requesting entity knows that this information exists for that VID. Also, on the storage place, the identity of the requester is revealed (at least partially) for matching access control rules.
123
536
A. Sarma et al.
Fig. 7 Example of using the identity broker
Access control on the Broker: Before redirecting the request, the broker applies access control rules to tell, or not, the requester that the information exists and where. Optionally, the broker can “hide” the storage place by presenting credentials from the requester and obtaining the information encrypted for the requester in such a way that the requester does not know where the information is stored and the broker does not know the information itself, only the type and the requester. Also, at the same time, the storage entity does not know who requested the information. This depends on the credentials system and whether this is also brokered by the identity broker. Furthermore, the storage place for certain attributes can also facilitate VID-linkage. Access control on the Terminal: As a last resort, access control can be applied by the rules in the terminal itself. The owner of the VID requests the information and filters it before directly giving it to the entity that requested it. This actually means the ID Broker can redirect all requests to a terminal where the entity can then decide what information to give out and how to access it. Although this approach has its drawbacks on performance, it is, from a security perspective, the one which offers the user the most control. 5.2.2 From VIDID to the Information To obtain information on a VID, the entity must first obtain the other entity’s VIDID. Once it has this, it should contact the ID Broker (defined by the realm) to either directly obtain the information or be redirected to the place of storage of this data. We demonstrate an example where the entity trying to reach a particular user has a Fully Qualified Domain Name. The requester first resolves the FQDN, using DNS, of the other entity obtaining the VIDID. It will then use the realm part of this value to contact the correct ID Broker. This connection may depend solely on the protocol being used, for example Diameter for AAA information. The ID Broker, in some cases simply a box that uses the same protocol as the one used to access the information, will use its tables to determine how the information requested can be obtained. To reach the information itself, after the resolution process, we define two mechanisms that can be applied in different situations to enable a requester to access certain parts of the
123
Virtual Identity Framework for Telecom Infrastructures
537
1: EPV handler req. 2: EPV handler rep. 3: Service req. 4: Service param. req. 5: User disclosure req. 6: User disclosure rep. 7: EPV configuration 8: Service param. rep. 9: Service rep. Fig. 8 Identity brokerage and management
resolved VID. We define such mechanisms as push and pull models for VID information access. In Fig 8, both push and pull mechanisms are depicted. The entity A first sets up his EPV (VID) and requests a handler (VIDID) which is then used by B to access information about A. The preparation phase in 1, 2 are consistent with the push mechanism, while the actions 5, 6 are in line with the pull mechanism. Both these mechanisms refer to the way in which the VID is populated with information and access control rules are applied on the VID. The user “pushes” all the information related to the VID before accessing a service. If information required by the service is not in the VID, the access is not allowed. This enforces a preparation action from the user but reduces the amount of communication and protocols. The form by which the information reaches B can be through the identity broker, such as depicted, or directly sent by A. The push reflects the form by which the VID is built. As opposed to the previous model, the service will request the information from the VID and, if this information is not present, the user will be questioned whether he wants to add this information or even just allow the service to access this information which was already in the VID.
5.2.3 Additional features To complement the VID system architecture, we provide a set of additional features that enable the user to manage his digital identities, and may be provided by the network or identity provider. The first of these services is the VID Wallet. Since user’s will have their network identity split into different avatars, it becomes necessary to give the user a way to store and organize his different avatars to allow him to easily use a new terminal. The service should be constructed such that it reveals neither who the user is nor his VIDs to the provider, while remaining reachable to the user regardless of his location (i.e., while roaming). The VID Wallet should provide a VID List that endows the user the option of choosing between his preferred identities. It may be important to store the history of their usage and possibly history related to personalization to instantiate the learning elements in the network and the terminal related to that VID.
123
538
A. Sarma et al.
Finally, it may be prove useful to store keys and credentials together with the VID to facilitate the bootstrapping of the VID in the network or with a service. The VID Wallet service does not force the user to store all of his identities on the network. The model is flexible enough to allow a user to carry some of his Identities along with him, emulating SIM card metaphor, ensuring that the certain identities are never stored on the network, if that is the user’s whish. Given the fact that the user leverages multiple identities, there should be a trusted service, either local or remote, which can alleviate the process of selecting a VID for a particular service, enhancing the privacy protection functions. We accept that the user is error-prone, and such trusted mechanisms should be available to detect and protect undesired privacy leakage.
6 Discussion While the above has presented the VID model and architecture, quite a bit of supporting work has been done towards some of the consequences towards the lower layers. One of these is on how the user perceives a virtual terminal. Another is on how to support anonymity at the lower layers. There is a strong link between this work and issues related to naming and addressing. Some specific issues are discussed in the subsections below, specially focusing on the lower layers aspects. 6.1 Cross Layer Pseudonyms The proposed identity management system provides a singular approach in terms of containment across different virtual identities. In terms of privacy, this containment requires that each Identity uses its own pseudonym at each layer, in order to preserve privacy. Since the identity model is a cross-layer solution, it also provides the architectural requirements to fulfill the multi-pseudonym approach. It enables a vertical control plane that interacts with applications, yielding the input for network stack management, while providing control of seemingly different stacks, through their identity hooks, as shown in Fig. 9. Each VID can leverage its own contained network stack, with multiple pseudonyms, ensuring that different virtual identities are never correlated through their stack identifiers. Each VID receives different link, network and transport pseudonyms, making it impossible to use these identifiers for correlation purposes across different identities. The proposed model is connection oriented: identifiers are generated or used at the pace they are required to connect to the network at different layers. For example, an IP address is generated or assigned at the time the terminal connects to an access router, and is normally used by all upper layer protocols. The proposed approach turns the focus to identity, generating different identifiers when an identity wishes to connect to the point of service. On the Link layer, independent addresses need to be generated for each VID. These addresses do not correspond to the physical address present in every physical device. This is in fact a virtual address that is created for every persona. This is achieved with through a virtual interface manager (VIM) that controls the real interfaces, and supplies the necessary primitives and information to virtual interfaces (VIF) with a Virtual MAC (VMAC) address (e.g., [16]). This can be extended to multiple physical devices, leading to several VIFs under the control of a particular identity. From the network point of view, each VIF/VMAC pair represents a different device, competing among each other for network access.
123
Virtual Identity Framework for Telecom Infrastructures
539
Fig. 9 Use of virtual identities across layers
Since we consider next generation environments, we rely on the mobility solution to provide the binding address to the transport. Since this is already different for each identity, the transport protocols, such as TCP and UDP, establish their bindings with the mobility identifiers, i.e., HoA and implicitly support a pseudonym approach. The application layer is directly dependent on the user interactions. This means that a user already wields different usernames and protocol handles for each service. In our approach, he requires (at least) one per identity. The identity model provides a consistent view over this fragmented model, and associates it with SSO, authentication and authorization mechanisms ([17]). 6.2 Identity Based Mobility Management With the VID namespace, there are several gains regarding mobility. Using the pseudonymity approach shown in Fig. 10, with identifiers bound to the same namespace we can establish a clear line between terminal and user. The different layer identifiers belong in fact to the user and relate to his Identity Management system. We are no longer bound to device mobility, since a user can move across devices, which is in fact supported by the IdM layer. Instead of moving a particular address to another point of attachment, an identity is being moved. Decoupling the mobility procedures from the terminal as an entity to the identity of the user, increases the overall system flexibility ([18]). Furthermore, with this approach, multiple identities of the same or different users can simultaneously coexist in the same terminal, enabling an identity driven shared environment. This is very useful for mobility purposes, since mobility decisions at the application layer can be linked to identity. We have here in fact modularized mobility with access to new broader plane of information. With the proper tools in place, such as VIDID bound protocols, current mobility protocols are simply tools that enable the user or terminal to perform signaling for a particular entity. This signaling is determined not only by loss of connectivity but also by complex user policies that derive from the identity management layer. From the network point of view, since the identifiers linking to the Identity Management plane are the main actor, which can be embedded in the protocols and remain constant, the network is not dependent on the protocols in use for control.
123
540
A. Sarma et al.
Identity Layer
Virtual ID (VID1)
Virtual ID (VID2)
Aplication Layer
Application Identifier VID1
Application Identifier VID2
Transport Layer
Home Address VID1
Home Address VID2
Network Layer
Care-of Address VID1'
Care-of Address VID1'’
Care-of Address P2'
Care-of Address P2'’
MAC Layer
MAC Address VID1'
MAC Address VID1''
MAC Address P2'
MAC Address P2''
VIF Layer
Virtual Interface VID1'
Virtual Interface VID1'’
Virtual Interface VID2'
Virtual Interface VID2'’
Real Interface 1
Real Interface 2
Interface Layer
Fig. 10 Instantiation Scenario
6.3 Personalization and Control Given the VIDs as the user digital representation, the user can set on its EPPs the information that it wants to make visible-controlling thus the degree to which services can be personalized. The service provider creates EPP associated to the information relevant for that VID. On the other hand, the used can define through access control which entities, for example service providers, are permitted to access specific information about him. This process is controlled and supported in an infrastructure which provides VIDID resolution. These restrictions on access control can always be overcome if required by a legal mandate. However, given the distributed nature of the EP with EPPs stored in different network and service providers, it would require the collusion of all involved providers to ultimately break the user’s privacy. 7 Conclusion In this paper, we have presented the Virtual Identity framework. We detailed the model and the basic architecture units required. With the Virtual Identity approach, we believe we can enhance Identity Management towards a potential key convergence technology that uses the user as the integrating entity to bring networks, services and applications together. The approach addresses the main gaps in identity management, which we believe are bringing identity management to the network, the lack of cross-layer support, and enabling privacy across layers. This work has been pursued inside the Daidalos project, and bridges the gap between traditional Identity Management and Telecommunications. Leveraging Virtual Identities and Identity Management for the Network and Telco Services as a Convergence Technology is a challenge that we have only started to address, but which will be essential for operators business, while opening opportunities for a whole range of new players.
123
Virtual Identity Framework for Telecom Infrastructures
541
Acknowledgements This work has been partially sponsored by the EU-funded Daidalos project. The authors thank and acknowledge a lot of the people involved in the Daidalos project who have contributed considerably to the work described here. We mention in particular Christian Hauser, Jochen Koegel, Marc Barisch, Antonio Skarmeta, Pedro Brandão and Kajetan Dolinar who have been involved since many years in contributing to the results of the Virtual Identity work.
References 1. Deutsche Telekom Call & Surf Comfort Plus. http://www.t-home.de/lp/max07/cs_comfortplus. 2. Rui, L., Aguiar, A. S., Bijwaard, D., Marchetti, L., Pacyna, P., Pascotto, R. (2007). Pervasiveness in a competitive multi-operator environment: The Daidalos project. IEEE Communications Magazine, 45(10), 22–26. 3. Liberty Alliance, Liberty Alliance ID-WSF 2.0 Specifications, URL: http://www.projectliberty.org/ resource_center/specifications/liberty_alliance_id_ff_1_2_specifications. 4. Microsoft Passport, Microsoft Developer Network (MSDN), URL: http://msdn.microsoft.com/archive/ en-us/passport25/start_full.asp. 5. Microsoft Cardspace, Microsoft Developer Network (MSDN), URL: http://msdn.microsoft.com/ CardSpace. 6. OpenID, OpenID Specifications, The OpenID Foundation, URL: http://openid.net/developers/specs/. 7. ETSI Standard EN 301 243 V4.0.1: Digital cellular telecommunications system (Phase 2); Enhanced Full Rate (EFR) speech processing functions; General description (GSM 06.51 version 4.0.1), available here: http://www.3gpp.org/ftp/Specs/archive/06_series/06.51/0651--401.zip. 8. For a full list of 3G and UMTS standards, check here: http://www.3gpp.org/specs/specs.htm. 9. Perkins, C., Johnson, D., & Arkko, J. (2004). Mobility support in IPv6. RFC 3775, IETF, June 2004. 10. Aura, T. (2003). Cryptographically Generated Addresses (CGA). 6th Information Security Conference (ISC’03), Bristol, UK, October 2003. 11. WP 15.1, 2005, Privacy and Identity Management for Europe - PRIME White Paper. In M. Hansen & H. Krasemann (ICPP)(Eds.), Reviewers: P. Keller (Swisscom), M. Vanfleteren (KULeuven), http://www. prime-project.eu.org/. 12. Future of Identity in the Information Society (FIDIS), URL: http://www.fidis.net. 13. ITU, digital.life, Chapter 4, http://www.itu.int/osg/spu/publications/digitalife/. 14. ITU-T Focus Group on Identity Management, http://www.itu.int/ITU-T/studygroups/com17/fgidm/. 15. Gomes, D., & Rui, L. (2006). A Privacy through virtual Hording, Globecom 2006, The 49h IEEE GLOBECOM Technical Conference, San francisco, Dec 2006. 16. de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., & Spence, D. (2000). IETF request for comments 2093 (RFC 2903). Generic AAA Architecture August 2000. 17. Matos, A., Sargento, S., Girão, J., & Aguiar, R. L. (2007). Preserving privacy in mobile environments, Globecom 2007. The 50h IEEE GLOBECOM Technical Conference, Washington, Dec 2007. 18. Matos, A., Sargento, S., & Aguiar, R. L. (2007). Embedding identity in mobile environments. The Second International Workshop on Mobility in the Evolving Internet Architecture, Kyoto, Japan, Jul 2007.
123
542
A. Sarma et al.
Author Biographies Amardeo Sarma received his Bachelor of Technology degree from the Indian Institute of Technology, Delhi, in 1977 and his Master’s degree (Diplom-Ingenieur) from the Technical University of Darmstadt in 1980, both in Electrical Engineering. He was at Deutsche Telekom and predecessor from 1981 to 1995, where he participated in several internal and international projects dealing with signalling, protocols, ATM, middleware and specification techniques. In 1995, he joined EURESCOM GmbH in Heidelberg as Project Supervisor, where he supervised international Projects in the area of software technologies, middleware, ATM and IP. In April 2001, he joined NEC Laboratories Europe in Heidelberg, where he is currently responsible for the areas identity management, security for restricted devices, car-to-car communication and heterogeneous network access. Amardeo was Chairman of ITU-T Study Group 10 from 1996–2001 and then Co-Chairman of the combined Study Group 17 on “Data Networks and Teleccommunication Software” until 2004. He is IEEE Senior Member and currently Steering Board member of the WWRF (Wireless World Research Forum) and in charge of the “Global Architecture and Scenario based design” Work Package of the EU IST Integrated Project “Daidalos” and Technical Project Manager of the EU IST “SWIFT” project.
Alfredo Matos received his diploma from University of Aveiro, Portugal in 2005. Since 2005, he has been a research assistant with the Telecommunications Institute of Aveiro at Aveiro, Portugal, while pursuing a Ph.D. with the University of Aveiro, focusing on Privacy in Next generation networks. In the past, he has worked on mobility at the network layer, focusing on hierarchical and fast mobility, along with identifier and locator ambiguities. His current interests focus on providing privacy at the lower layers along with cross-layer identity support in next generation heterogeneous environments.
João Girão received his diploma from the University of Aveiro, Portugal, in 2003. Since 2003, he has been a member of the Mobile Internet group at NEC Europe Ltd. in Heidelberg. From 2004 and on, he has been pursuing, in parallel, a Ph.D. with the University of Bochum in the area of security for wireless sensor networks. In the past he has worked in security topics related to mobility and ad-hoc networks, while his current focus is on how to map identity management concepts in the lower layers. He has participated in several EU projects such as Daidalos and UbiSec&Sens where he has contributed technically and also in the coordination of specific tasks. He is a member of both the IEEE and ACM. He is currently one of the editors of documents being prepared at the ITU-T Focus Group on Identity Management.
123
Virtual Identity Framework for Telecom Infrastructures
543
Rui L. Aguiar received a Ph.D. degree in electrical engineering in 2001 from the University of Aveiro, Portugal. He is currently a professor at the University of Aveiro, and a Guest Professor at Carnegie Mellon Cylab. He is leading a research team at the Institute of Telecommunications, Aveiro, on next-generation network architectures and protocols. His current research interests are centered on the implementation of advanced wireless networks, systems, and circuits, with special emphasis on QoS and mobility aspects. He has more than 200 published papers in those areas. He is member of ACM and Senior Member of IEEE. He has taken chairing responsibilities in several conferences, such as ICNS’05, ICT’06 and ISCC’07.
123
