Internet DRAFT - draft-ccm-ideas-identity-use-cases
draft-ccm-ideas-identity-use-cases
Network Working Group U. Chunduri, Ed.
Internet-Draft A. Clemm
Intended status: Informational Huawei
Expires: April 13, 2018 M. Menth
University of Tuebingen
October 10, 2017
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 [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.
Chunduri, et al. Expires April 13, 2018 [Page 1]
Internet-Draft Identity Use Cases in IDEAS October 2017
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
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Uses for IDy . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IDy in IDEAS . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IDy Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Unified Policies . . . . . . . . . . . . . . . . . . . . 7
5.2.1. Access Restriction Policies . . . . . . . . . . . . . 7
5.3. Uses of Metadata . . . . . . . . . . . . . . . . . . . . 8
5.4. Access Security and Manageability . . . . . . . . . . . . 8
5.5. Delay-Tolerant Networking (DTN) . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
[RFC7401] and LISP [RFC6830], 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
Chunduri, et al. Expires April 13, 2018 [Page 2]
Internet-Draft Identity Use Cases in IDEAS October 2017
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.
Chunduri, et al. Expires April 13, 2018 [Page 3]
Internet-Draft Identity Use Cases in IDEAS October 2017
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.
a. 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.
b. 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).
c. 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
Chunduri, et al. Expires April 13, 2018 [Page 4]
Internet-Draft Identity Use Cases in IDEAS October 2017
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].
Chunduri, et al. Expires April 13, 2018 [Page 5]
Internet-Draft Identity Use Cases in IDEAS October 2017
+---------------------------------------------------------------+
| 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.
Chunduri, et al. Expires April 13, 2018 [Page 6]
Internet-Draft Identity Use Cases in IDEAS October 2017
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.
Chunduri, et al. Expires April 13, 2018 [Page 7]
Internet-Draft Identity Use Cases in IDEAS October 2017
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
Chunduri, et al. Expires April 13, 2018 [Page 8]
Internet-Draft Identity Use Cases in IDEAS October 2017
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
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[I-D.ietf-lisp-eid-anonymity]
Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
EID Anonymity", draft-ietf-lisp-eid-anonymity-00 (work in
progress), August 2017.
[I-D.padma-ideas-problem-statement]
Pillay-Esnault, P., Boucadair, M., Fioccola, G.,
Jacquenet, C., and A. Nennker, "Problem Statement for
Identity Enabled Networks", draft-padma-ideas-problem-
statement-03 (work in progress), July 2017.
Chunduri, et al. Expires April 13, 2018 [Page 9]
Internet-Draft Identity Use Cases in IDEAS October 2017
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
Authors' Addresses
Uma Chunduri (editor)
Huawei
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: uma.chunduri@huawei.com
Alexander Clemm
Huawei
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: ludwig@clemm.org
Michael Menth
University of Tuebingen
Germany
Email: menth@uni-tuebingen.de
Chunduri, et al. Expires April 13, 2018 [Page 10]
