idnits 2.17.1 draft-ccm-ideas-identity-use-cases-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 10, 2017) is 2389 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IDy' is mentioned on line 237, but not defined == Missing Reference: 'IDf' is mentioned on line 264, but not defined == Missing Reference: 'LOC' is mentioned on line 264, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-lisp-eid-anonymity-00 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group U. Chunduri, Ed. 3 Internet-Draft A. Clemm 4 Intended status: Informational Huawei 5 Expires: April 13, 2018 M. Menth 6 University of Tuebingen 7 October 10, 2017 9 Identity Use Cases in IDEAS 10 draft-ccm-ideas-identity-use-cases-02 12 Abstract 14 IDentity-EnAbled networkS (IDEAS) introduce the concept of Identity 15 (IDy) into networking. An IDy represents a high-level identifier 16 representing a collection of identifiers of a device, node, or 17 process used for communication purposes. It is used for 18 authentication purposes and never revealed in data plane packets. 19 This document summarizes some conceptual use cases to illustrate the 20 usefulness of IDEAS. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 13, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Uses for IDy . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. IDy in IDEAS . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. IDy Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.2. Unified Policies . . . . . . . . . . . . . . . . . . . . 7 69 5.2.1. Access Restriction Policies . . . . . . . . . . . . . 7 70 5.3. Uses of Metadata . . . . . . . . . . . . . . . . . . . . 8 71 5.4. Access Security and Manageability . . . . . . . . . . . . 8 72 5.5. Delay-Tolerant Networking (DTN) . . . . . . . . . . . . . 8 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 9.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 An Internet Protocol (IP) [RFC0791] address signifies both a 84 Communications Entity's (Section 2) Location and its Identification. 85 Location and Identification separation protocols, for example HIP 86 [RFC7401] and LISP [RFC6830], introduced the concept of Identifier 87 and separated this information from the Locator (IP address in this 88 case). 90 The Location/Identifier split separates Location and Identification 91 function for a specific networking device, i.e., the Identifier 92 denotes a device while the Locator denotes a routable network 93 interface. With Location/Identifier split, multiple benefits in 94 networking can be realized, e.g., in the areas of mobility, network 95 virtualization, traffic engineering, security, software-defined 96 networking, and others. 98 IDEAS goes one step further and makes a distinction between IDy and 99 Identifier, and introduces an IDy/Identifier split. The abstraction 100 of an IDy and the corresponding split from Identifiers can bring 101 additional benefits that can be combined with Location/Identifier 102 separation. The abstraction applies at the network layer, like 103 Locator/Identifier, and is not related to transport or application 104 Identities. Any use of identifiers in the data plane is governed by 105 the respective ID/Locator protocols, such as LISP and HIP. 107 An IDy serves as a collection of identifiers that are associated with 108 the same endpoint. It is used to identify and authenticate the 109 communications entity, but not revealed in packet headers. It is not 110 to be confused with a personal identity, does not represent human- 111 identifiable information, and does not imply an exclusive nor long- 112 lived binding with an endpoint. Its potential benefits are in the 113 areas of privacy i.e., the ability to have multiple identifiers for 114 the same communications entity which can be used for anonymous 115 communication, access controls at the Mapping System (MS) to expose 116 mapping information only to authorized requestors, and application of 117 various policies uniformly across Identifiers pertaining to the same 118 IDy. IDy also enables easier and more efficient management of 119 various aspects at the mapping system, as related Identifiers can be 120 referred to in groups. 122 2. Acronyms 124 Communications Entity: A device, node, or software process 125 used for IP-based (in some case Layer-2 based) data 126 communication 128 GRIDS: GeneRic Identity Services - a mapping and Identity 129 services system that will be defined in the context of IDEAS. 130 This goes beyond traditional mapping of Location/Identifier 131 and can include Identity based services(e.g. policy/metadata/ 132 grouping service). 134 HIP: Host Identity Protocol 136 IDf: Identifier - denotes information to unambiguously 137 identify a communications entity within a given scope. 138 Examples HIP HIT [RFC7401] and LISP EID [RFC6830]. There is 139 no constraint on the format, obfuscation or routability of an 140 Identifier. 142 IDy: Identity - an identifier for a communications entity that 143 MAY be assigned by the GRIDS-provider and that is used by the 144 provider to identify and authenticate the communications 145 entity, but that is not revealed in the packet headers. 147 LOC: Locator, for example, IPv4/IPv6 based 149 LISP: The Locator/ID Separation Protocol 151 Metadata: Metadata is network-related data about an IDy. The 152 metadata may contain information such as the type of the 153 communications entity. 155 MS: Traditional Mapping Server for LOC/IDf protocols (e.g. 156 HIP RVS, LISP-DDT) 158 3. Uses for IDy 160 A communications entity can use multiple Identifiers for anonymous 161 communication in the data plane [I-D.ietf-lisp-eid-anonymity] or for 162 other reasons, for example to representing different locators 163 simultaneously. When multiple Identifiers are in use, the notion of 164 Layer-3 IDy helps in the following ways. 166 a. IDy representing the communications entity enables authentication 167 (AUTH) with the mapping and Identity services infrastructure. 168 While it is possible to do AUTH on Identifiers those are NOT 169 permanently associated to the communications entity. Moreover, 170 AUTH operation is a relatively expensive and inefficient 171 procedure (compared to LOC resolution for example) and can cause 172 excessive startup delays for many applications. 174 b. Data plane anonymization allows entities to communicate 175 anonymously from the outside observers. IDy provides de- 176 anonymization for various data plane ephemeral Identifiers, if 177 required, and enables resolution of which communications entity 178 is behind these identifiers for legitimate users (entities itself 179 in some cases). 181 c. IDy enables managing access restriction policies and metadata in 182 simplified and more efficient manner. An example of metadata is 183 the type of communications entity, such as whether it is an IoT 184 device, a connected vehicle, a server, an end user device. 185 Managing the association between metadata or policy on the basis 186 of IDy (that represents a collection of identifiers used by the 187 communications entity) is greatly simplified and reduces the 188 chances of error and inconsistencies compared to having to 189 enumerate each identifier individually and having to update 190 policies and metadata whenever identifiers are changed. It also 191 allows certain policies (e.g. metadata-based policies) to be 192 applied regardless of which of an IDy's Identifiers happens to be 193 used in data plane communication by the communications entity. 194 Without IDy, any access restrictions kept on Identifiers would be 195 easily defeated if the peer communications entity simply changes 196 the Identifier. 198 The above requirements for having a stable network layer IDy is 199 further detailed in Section 5. Section 5 also shows how another 200 abstraction of IDy from Identifiers help to enable various services 201 in the data communication with in IDEAS. 203 4. IDy in IDEAS 205 An IDy identifies a Communications Entity. IDy MAY be unicoded or an 206 ASCII string, which MAY have a partial structure (depends on the 207 authentication method selected) and MAY be given by the provider of 208 the IDy services. Typically, an IDy SHOULD NOT be revealed 209 unencrypted on the wire or shared with other entities to make IDy a 210 private enclave. 212 IDy is used for authentication of the Communications Entity and it 213 MAY be represented by multiple Identifiers (IDf's) in the data plane. 214 IDy can be seen as a 'first order Identifier' of a communications 215 entity with certain properties (for example not used in data plane) 216 and with certain additional attributes which are common to all 217 Identifiers of a communications entity. In that sense, an IDf can be 218 seen as a 'second order identifier' that is anchored in, and refers 219 to, a first-order identifier. 221 Access to the [IDy, IDf] mapping information may be restricted to a 222 defined set of communication entities. Even when access is 223 authorized, IDy information is not exposed directly but information 224 about the collection of IDfs grouped under the same IDy. For 225 example, given an IDf, a requestor that is authorized to do so (for 226 example, a communications peer) may look up a designated well-known 227 IDf that belongs to the same communications entity. Likewise, using 228 the mapping, given an IDf, policies and metadata associated with 229 IDf's IDy can be accessed. These communication patterns leverage 230 GeneRic ID Services (GRIDS), in which locator/identifier mappings are 231 maintained along with IDf, IDy, and locator associations, and which 232 provide various services associated with those mappings. In the 233 following (Section 5) various IDy use cases point out benefits of IDy 234 in IDEAS. 236 The following diagram Figure 1 illustrates a simplified relation of 237 Identity , Identifier, and Locator [IDy, IDf, LOC]. 239 +---------------------------------------------------------------+ 240 | Identity (IDy) | Policy | Metadata | MI | 241 +---------------------------------------------------------------+ 242 | 243 +---------------------+--------------------+ 244 | | | 245 V V V 246 +------------------------+ +--------------+ +-------------------+ 247 |Identifier(IDf)-1 | LOC1| | IDf-2 | LOC2 |...| IDf-n| LOC1..LOCm | 248 |(long-lived) | | (ephemeral) | | | 249 +------------------------+ +--------------+ +-------------------+ 251 MI - Management and Security Information 253 Figure 1: Identity, Identifier, Locator Relationship 255 5. IDy Use Cases 257 The uses for the IDy concept can be described by a few simple use 258 cases, as specified below. 260 5.1. Privacy 262 To communicate with a device on a network, a LOC is needed. In 263 current [IDf, LOC] protocols, a Mapping Server (MS) stores the 264 [IDf,LOC] mapping. The resolution request or lookup of an IDf to the 265 MS will return the LOC. 267 Generally, a communications entity with a certain IDy may use various 268 Identifiers for communication. Only the Identifier is visible on the 269 wire. Changing the IDf frequently makes it hard to track the 270 communications entity by outside observers and thus improves privacy 271 of the communication entities. 273 While it may be desirable to change the IDf every now and then for 274 privacy purposes, the notion of IDy in addition to IDf can be 275 important for several reasons. For example, it allows to apply the 276 same policy for a communications entity of a given IDy regardless 277 which of IDfs that are associated with the IDy are used. It allows 278 senders to use anonymized and fast-changing identifiers over the wire 279 that make tracking difficult, while still allowing a receiver to look 280 up a known or long-lived identifier or metadata of the same 281 communications entity, if authorized by the sender. 283 It should be noted that a communications entity will never be allowed 284 to look up another communication entity's IDy. However, depending on 285 authorization policy, it may be able to look up another IDf that is 286 designated as a "well known" IDf and associated with the same IDy. 288 This allows a communications entity to reveal "who it is" to the 289 receiver if it chooses to do so, while obfuscating this information 290 to observers. 292 5.2. Unified Policies 294 Networks today treat traffic differently depending on properties such 295 as source or destination. E.g., certain traffic may access the 296 network directly, other traffic may need to pass a firewall, or other 297 traffic is entirely blocked. Likewise, some traffic may be treated 298 with different Quality of Service. 300 Similarly, the use of alternative IDfs for the same system may allow 301 for different treatment of traffic for the same system depending on 302 how the system is referred to, whereas in other cases, the same 303 policy should be applied regardless which of a set of IDfs (related 304 through a common IDy) is used. This can be leveraged by combining 305 the enforcement of network policies with policies that guide 306 selective mapping responses. E.g., some requesting groups may 307 receive an empty response from GRIDS Infrastructure for IDfs 308 referring to a certain IDy, others receive an IDf resulting in strict 309 security treatment of future traffic, and trusted groups receive an 310 IDf resulting in rather loose security treatment. 312 5.2.1. Access Restriction Policies 314 A communications entity may define that it wants to communicate only 315 with certain other entities. To achieve this, a communications 316 entity MAY define a rule regarding who can request and obtain its 317 IDf. The GRIDS Infrastructure will send a negative or empty response 318 when it detects that the combination of resolution query and its 319 initiator does not pass the rule validation test. One example of 320 this policy is, restriction of LOC resolution and hence allowing data 321 traffic from only from the dealer/manufacturer of a vehicular node. 323 Moreover, network-based access control may filter based on IDfs which 324 are visible in the traffic, but this can be done simply through an 325 association related to the IDy, which allows to check (proper 326 authorization assumed) whether an IDf is associated with the same IDy 327 as another, well-known IDf. (The IDy itself is never revealed.) By 328 basing access control on the notion of IDy, respectively an IDy's 329 collection of IDfs, enforcement and maintainability of access control 330 rules is greatly simplified as there is no need to track IDf changes 331 or the introduction of new IDfs for the same IDy. 333 5.3. Uses of Metadata 335 The GRIDS Infrastructure is envisioned to store Metadata (Section 2) 336 and provide some search functionality. The GRIDS Infrastructure with 337 may be a means to find a set of communications entities with certain 338 associated metadata, provided that they have agreed to be searchable 339 (allow discovery of a designated well-known IDf). E.g., it may be 340 possible to find out current well-known IDfs of a set of deployed 341 devices of particular type. This allows to locate them via [IDf, 342 LOC] mappings and possibly manage them. 344 IDy also allows to have associated metadata applied, regardless of 345 which IDf is used to refer to the communications entity. This 346 association makes the management of metadata easier, because it does 347 not need to be maintained separately and redundantly for every IDf. 349 5.4. Access Security and Manageability 351 As secure registration between a commmunications entity and GRIDS 352 would be an expensive operation, this SHOULD be restricted to IDy and 353 (ephemeral) IDfs can be generated and can be given rather securely 354 using the same secure channel. 356 IDy allows separation of lifecycle of IDy to be different from 357 Identifiers, which enables to extend the "right-to-be-forgotten" 358 concerning personal data to network identifier data, if required. 359 There are various possible scenarios on why a long-lived IDfs by a 360 communications entity has to be withdrawn. Common cases involved 361 lost/stolen device or misused Identifiers for example. 363 5.5. Delay-Tolerant Networking (DTN) 365 Entities may be only temporarily reachable. When they are not 366 reachable, proxies may be used to receive their traffic. To that 367 end, using an IDy, a communications entity MAY register one of the 368 IDfs of its proxy with the GRIDS Infrastructure that this node can, 369 e.g., receive traffic for that node and later forward to it when the 370 node is again online. A major application field may be in the IoT 371 with mobile and intermittently connected devices 373 6. Acknowledgements 375 Thanks to Padma Pillay-Esnault for so many conversations around IDy 376 and its potential uses in IDEAS. The authors would like to thank 377 detailed reviews and suggestions from Dino Farinacci, Joel Halpern, 378 Jeff Tantsura, Jim Guichard, Christian Huitema, Dave Meyers, Robert 379 Moskowitz, Georgios Karagiannis, Liu Bingyang and Yangfei. We also 380 acknowledge the constructive and useful feedback from the IDEAS BOF 381 and mailing list. 383 7. IANA Considerations 385 This document has no actions for IANA. 387 8. Security Considerations 389 This document further abstracts IDy from the Identifier in current 390 Identifier/Locator protocols. This abstraction gives significant 391 security benefits and enables networks to facilitate anonymization of 392 communications on the wire and to allow communications entities to 393 control access to their locator information, as specified in 394 [I-D.padma-ideas-problem-statement]. The IDy concept and data stored 395 in GRIDS are intended for routing and forwarding purposes only. They 396 are in no way indended and must not be used to store human- 397 identifiable information, personal identifiers, and the like. A 398 separate threat analysis detailing security and privacy aspects of 399 the IDy concept and data maintained in GRIDS will be done in a 400 separate document under the IDEAS charter. 402 9. References 404 9.1. Normative References 406 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 407 DOI 10.17487/RFC0791, September 1981, 408 . 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 9.2. Informative References 417 [I-D.ietf-lisp-eid-anonymity] 418 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 419 EID Anonymity", draft-ietf-lisp-eid-anonymity-00 (work in 420 progress), August 2017. 422 [I-D.padma-ideas-problem-statement] 423 Pillay-Esnault, P., Boucadair, M., Fioccola, G., 424 Jacquenet, C., and A. Nennker, "Problem Statement for 425 Identity Enabled Networks", draft-padma-ideas-problem- 426 statement-03 (work in progress), July 2017. 428 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 429 Locator/ID Separation Protocol (LISP)", RFC 6830, 430 DOI 10.17487/RFC6830, January 2013, 431 . 433 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 434 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 435 RFC 7401, DOI 10.17487/RFC7401, April 2015, 436 . 438 Authors' Addresses 440 Uma Chunduri (editor) 441 Huawei 442 2330 Central Expressway 443 Santa Clara, CA 95050 444 USA 446 Email: uma.chunduri@huawei.com 448 Alexander Clemm 449 Huawei 450 2330 Central Expressway 451 Santa Clara, CA 95050 452 USA 454 Email: ludwig@clemm.org 456 Michael Menth 457 University of Tuebingen 458 Germany 460 Email: menth@uni-tuebingen.de