Identity Use Cases in IDEAS
draft-ccm-ideas-identity-use-cases-02

Abstract

IDentity-EnAbled networkS (IDEAS) introduce the concept of Identity (IDy) into networking. An IDy represents a high-level identifier representing a collection of identifiers of a device, node, or process used for communication purposes. It is used for authentication purposes and never revealed in data plane packets. This document summarizes some conceptual use cases to illustrate the usefulness of IDEAS.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Status of This Memo

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

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

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

This Internet-Draft will expire on April 13, 2018.

Copyright Notice

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

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

Table of Contents

• 1. Introduction
• 2. Acronyms
• 3. Uses for IDy
• 4. IDy in IDEAS
• 5. IDy Use Cases
• 5.1. Privacy
• 5.2. Unified Policies
• 5.2.1. Access Restriction Policies
• 5.3. Uses of Metadata
• 5.4. Access Security and Manageability
• 5.5. Delay-Tolerant Networking (DTN)
• 6. Acknowledgements
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

An Internet Protocol (IP) [RFC0791] address signifies both a Communications Entity's (Section 2) Location and its Identification. Location and Identification separation protocols, for example HIP and LISP, introduced the concept of Identifier and separated this information from the Locator (IP address in this case).

The Location/Identifier split separates Location and Identification function for a specific networking device, i.e., the Identifier denotes a device while the Locator denotes a routable network interface. With Location/Identifier split, multiple benefits in networking can be realized, e.g., in the areas of mobility, network virtualization, traffic engineering, security, software-defined networking, and others.

IDEAS goes one step further and makes a distinction between IDy and Identifier, and introduces an IDy/Identifier split. The abstraction of an IDy and the corresponding split from Identifiers can bring additional benefits that can be combined with Location/Identifier separation. The abstraction applies at the network layer, like Locator/Identifier, and is not related to transport or application Identities. Any use of identifiers in the data plane is governed by the respective ID/Locator protocols, such as LISP and HIP.

An IDy serves as a collection of identifiers that are associated with the same endpoint. It is used to identify and authenticate the communications entity, but not revealed in packet headers. It is not to be confused with a personal identity, does not represent human-identifiable information, and does not imply an exclusive nor long-lived binding with an endpoint. Its potential benefits are in the areas of privacy i.e., the ability to have multiple identifiers for the same communications entity which can be used for anonymous communication, access controls at the Mapping System (MS) to expose mapping information only to authorized requestors, and application of various policies uniformly across Identifiers pertaining to the same IDy. IDy also enables easier and more efficient management of various aspects at the mapping system, as related Identifiers can be referred to in groups.

2. Acronyms

Communications Entity: A device, node, or software process used for IP-based (in some case Layer-2 based) data communication

GRIDS: GeneRic Identity Services - a mapping and Identity services system that will be defined in the context of IDEAS. This goes beyond traditional mapping of Location/Identifier and can include Identity based services(e.g. policy/metadata/grouping service).

HIP: Host Identity Protocol

IDf: Identifier - denotes information to unambiguously identify a communications entity within a given scope. Examples HIP HIT [RFC7401] and LISP EID [RFC6830]. There is no constraint on the format, obfuscation or routability of an Identifier.

IDy: Identity - an identifier for a communications entity that MAY be assigned by the GRIDS-provider and that is used by the provider to identify and authenticate the communications entity, but that is not revealed in the packet headers.

LOC: Locator, for example, IPv4/IPv6 based

LISP: The Locator/ID Separation Protocol

Metadata: Metadata is network-related data about an IDy. The metadata may contain information such as the type of the communications entity.

MS: Traditional Mapping Server for LOC/IDf protocols (e.g. HIP RVS, LISP-DDT)

3. Uses for IDy

A communications entity can use multiple Identifiers for anonymous communication in the data plane [I-D.ietf-lisp-eid-anonymity] or for other reasons, for example to representing different locators simultaneously. When multiple Identifiers are in use, the notion of Layer-3 IDy helps in the following ways.

1. IDy representing the communications entity enables authentication (AUTH) with the mapping and Identity services infrastructure. While it is possible to do AUTH on Identifiers those are NOT permanently associated to the communications entity. Moreover, AUTH operation is a relatively expensive and inefficient procedure (compared to LOC resolution for example) and can cause excessive startup delays for many applications.
2. Data plane anonymization allows entities to communicate anonymously from the outside observers. IDy provides de-anonymization for various data plane ephemeral Identifiers, if required, and enables resolution of which communications entity is behind these identifiers for legitimate users (entities itself in some cases).
3. IDy enables managing access restriction policies and metadata in simplified and more efficient manner. An example of metadata is the type of communications entity, such as whether it is an IoT device, a connected vehicle, a server, an end user device. Managing the association between metadata or policy on the basis of IDy (that represents a collection of identifiers used by the communications entity) is greatly simplified and reduces the chances of error and inconsistencies compared to having to enumerate each identifier individually and having to update policies and metadata whenever identifiers are changed. It also allows certain policies (e.g. metadata-based policies) to be applied regardless of which of an IDy's Identifiers happens to be used in data plane communication by the communications entity. Without IDy, any access restrictions kept on Identifiers would be easily defeated if the peer communications entity simply changes the Identifier.

The above requirements for having a stable network layer IDy is further detailed in Section 5. Section 5 also shows how another abstraction of IDy from Identifiers help to enable various services in the data communication with in IDEAS.

4. IDy in IDEAS

An IDy identifies a Communications Entity. IDy MAY be unicoded or an ASCII string, which MAY have a partial structure (depends on the authentication method selected) and MAY be given by the provider of the IDy services. Typically, an IDy SHOULD NOT be revealed unencrypted on the wire or shared with other entities to make IDy a private enclave.

IDy is used for authentication of the Communications Entity and it MAY be represented by multiple Identifiers (IDf's) in the data plane. IDy can be seen as a 'first order Identifier' of a communications entity with certain properties (for example not used in data plane) and with certain additional attributes which are common to all Identifiers of a communications entity. In that sense, an IDf can be seen as a 'second order identifier' that is anchored in, and refers to, a first-order identifier.

Access to the [IDy, IDf] mapping information may be restricted to a defined set of communication entities. Even when access is authorized, IDy information is not exposed directly but information about the collection of IDfs grouped under the same IDy. For example, given an IDf, a requestor that is authorized to do so (for example, a communications peer) may look up a designated well-known IDf that belongs to the same communications entity. Likewise, using the mapping, given an IDf, policies and metadata associated with IDf's IDy can be accessed. These communication patterns leverage GeneRic ID Services (GRIDS), in which locator/identifier mappings are maintained along with IDf, IDy, and locator associations, and which provide various services associated with those mappings. In the following (Section 5) various IDy use cases point out benefits of IDy in IDEAS.

The following diagram Figure 1 illustrates a simplified relation of Identity , Identifier, and Locator [IDy, IDf, LOC].

   +---------------------------------------------------------------+
   | Identity (IDy)       | Policy           | Metadata |   MI     |
   +---------------------------------------------------------------+
            |
            +---------------------+--------------------+
            |                  	  |	               |
            V                     V                    V 
   +------------------------+ +--------------+   +-------------------+
   |Identifier(IDf)-1 | LOC1| | IDf-2 | LOC2 |...| IDf-n| LOC1..LOCm |  
   |(long-lived)            | | (ephemeral)  |   |                   |
   +------------------------+ +--------------+   +-------------------+

	MI -  Management and Security Information
	      

Figure 1: Identity, Identifier, Locator Relationship

5. IDy Use Cases

The uses for the IDy concept can be described by a few simple use cases, as specified below.

5.1. Privacy

To communicate with a device on a network, a LOC is needed. In current [IDf, LOC] protocols, a Mapping Server (MS) stores the [IDf,LOC] mapping. The resolution request or lookup of an IDf to the MS will return the LOC.

Generally, a communications entity with a certain IDy may use various Identifiers for communication. Only the Identifier is visible on the wire. Changing the IDf frequently makes it hard to track the communications entity by outside observers and thus improves privacy of the communication entities.

While it may be desirable to change the IDf every now and then for privacy purposes, the notion of IDy in addition to IDf can be important for several reasons. For example, it allows to apply the same policy for a communications entity of a given IDy regardless which of IDfs that are associated with the IDy are used. It allows senders to use anonymized and fast-changing identifiers over the wire that make tracking difficult, while still allowing a receiver to look up a known or long-lived identifier or metadata of the same communications entity, if authorized by the sender.

It should be noted that a communications entity will never be allowed to look up another communication entity's IDy. However, depending on authorization policy, it may be able to look up another IDf that is designated as a "well known" IDf and associated with the same IDy. This allows a communications entity to reveal "who it is" to the receiver if it chooses to do so, while obfuscating this information to observers.

5.2. Unified Policies

Networks today treat traffic differently depending on properties such as source or destination. E.g., certain traffic may access the network directly, other traffic may need to pass a firewall, or other traffic is entirely blocked. Likewise, some traffic may be treated with different Quality of Service.

Similarly, the use of alternative IDfs for the same system may allow for different treatment of traffic for the same system depending on how the system is referred to, whereas in other cases, the same policy should be applied regardless which of a set of IDfs (related through a common IDy) is used. This can be leveraged by combining the enforcement of network policies with policies that guide selective mapping responses. E.g., some requesting groups may receive an empty response from GRIDS Infrastructure for IDfs referring to a certain IDy, others receive an IDf resulting in strict security treatment of future traffic, and trusted groups receive an IDf resulting in rather loose security treatment.

5.2.1. Access Restriction Policies

A communications entity may define that it wants to communicate only with certain other entities. To achieve this, a communications entity MAY define a rule regarding who can request and obtain its IDf. The GRIDS Infrastructure will send a negative or empty response when it detects that the combination of resolution query and its initiator does not pass the rule validation test. One example of this policy is, restriction of LOC resolution and hence allowing data traffic from only from the dealer/manufacturer of a vehicular node.

Moreover, network-based access control may filter based on IDfs which are visible in the traffic, but this can be done simply through an association related to the IDy, which allows to check (proper authorization assumed) whether an IDf is associated with the same IDy as another, well-known IDf. (The IDy itself is never revealed.) By basing access control on the notion of IDy, respectively an IDy's collection of IDfs, enforcement and maintainability of access control rules is greatly simplified as there is no need to track IDf changes or the introduction of new IDfs for the same IDy.

5.3. Uses of Metadata

The GRIDS Infrastructure is envisioned to store Metadata (Section 2) and provide some search functionality. The GRIDS Infrastructure with may be a means to find a set of communications entities with certain associated metadata, provided that they have agreed to be searchable (allow discovery of a designated well-known IDf). E.g., it may be possible to find out current well-known IDfs of a set of deployed devices of particular type. This allows to locate them via [IDf, LOC] mappings and possibly manage them.

IDy also allows to have associated metadata applied, regardless of which IDf is used to refer to the communications entity. This association makes the management of metadata easier, because it does not need to be maintained separately and redundantly for every IDf.

5.4. Access Security and Manageability

As secure registration between a commmunications entity and GRIDS would be an expensive operation, this SHOULD be restricted to IDy and (ephemeral) IDfs can be generated and can be given rather securely using the same secure channel.

IDy allows separation of lifecycle of IDy to be different from Identifiers, which enables to extend the "right-to-be-forgotten" concerning personal data to network identifier data, if required. There are various possible scenarios on why a long-lived IDfs by a communications entity has to be withdrawn. Common cases involved lost/stolen device or misused Identifiers for example.

5.5. Delay-Tolerant Networking (DTN)

Entities may be only temporarily reachable. When they are not reachable, proxies may be used to receive their traffic. To that end, using an IDy, a communications entity MAY register one of the IDfs of its proxy with the GRIDS Infrastructure that this node can, e.g., receive traffic for that node and later forward to it when the node is again online. A major application field may be in the IoT with mobile and intermittently connected devices

6. Acknowledgements

Thanks to Padma Pillay-Esnault for so many conversations around IDy and its potential uses in IDEAS. The authors would like to thank detailed reviews and suggestions from Dino Farinacci, Joel Halpern, Jeff Tantsura, Jim Guichard, Christian Huitema, Dave Meyers, Robert Moskowitz, Georgios Karagiannis, Liu Bingyang and Yangfei. We also acknowledge the constructive and useful feedback from the IDEAS BOF and mailing list.

7. IANA Considerations

This document has no actions for IANA.

8. Security Considerations

This document further abstracts IDy from the Identifier in current Identifier/Locator protocols. This abstraction gives significant security benefits and enables networks to facilitate anonymization of communications on the wire and to allow communications entities to control access to their locator information, as specified in [I-D.padma-ideas-problem-statement]. The IDy concept and data stored in GRIDS are intended for routing and forwarding purposes only. They are in no way indended and must not be used to store human-identifiable information, personal identifiers, and the like. A separate threat analysis detailing security and privacy aspects of the IDy concept and data maintained in GRIDS will be done in a separate document under the IDEAS charter.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses