Information-Centric Networking Research Group R. Li Internet-Draft H. Asaeda Intended status: Informational NICT Expires: September 6, 2018 March 5, 2018 Requirements for Key Management Schemes in Content-Centric Networking/ Named Data Networking draft-li-icnrg-km-reqs-00 Abstract Signature is adopted as the fundamental function in Content-Centric Networking (CCN) / Named Data Networking (NDN). Its service and performance rely heavily on the key management (KM) schemes, which are the processes to generate, deliver, store, protect, update, and revoke cryptographic keys. This document describes the use scenarios and further requirements for KM schemes in CCN/NDN. 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 September 6, 2018. Copyright Notice Copyright (c) 2018 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 Li & Asaeda Expires September 6, 2018 [Page 1]
Internet-Draft Req. for KM in CCN/NDN March 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. KM Basics, CCN/NDN Operations, and Use Scenarios . . . . . . 4 3.1. KM Basic Procedures . . . . . . . . . . . . . . . . . . . 4 3.2. CCN/NDN Operations . . . . . . . . . . . . . . . . . . . 5 3.3. CCN/NDN Use Scenarios . . . . . . . . . . . . . . . . . . 7 4. KM Requirements for CCN/NDN . . . . . . . . . . . . . . . . . 8 4.1. Requirements for Protecting Network Operations . . . . . 8 4.1.1. Functional Requirements . . . . . . . . . . . . . . . 9 4.1.2. Performance Requirements . . . . . . . . . . . . . . 9 4.2. Requirements for Protecting Use Scenarios . . . . . . . . 9 4.2.1. Requirements for Protecting Disaster Networking with CCN/NDN . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Requirements for Protecting Video Streaming over CCN/NDN . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Requirements for Protecting IoT using CCN/NDN . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 5.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Information-Centric Networks (ICN) in general, and Content-Centric Networking (CCN) [2] or Named Data Networking (NDN) [3] in particular, are the emerging network architectures enabling in- network caching and data retrievals through their names. In CCN/NDN, data can be cached at the intermediate routers, close to users for reducing delay and redundant bandwidth consumption or for the robustness under dynamic network environment. It has been noticed that CCN/NDN is a promising approach for the application scenarios in disaster networking [4], video streaming [5], and Internet of Things (IoT) [6]. In CCN/NDN, the basic network operations and these use scenarios with in-network data caching and retrievals lead the network to be seriously vulnerable under a variety of attacks, such as the impersonation attack, malicious-request attack [7][8][9], and the data poisoning attack [10][11][12]. The unpredictability of users, routers, copy holders, and publishers during data retrievals in CCN/ NDN poses the novel challenge to design data-centric authentication to prevent these attacks. The novel authentication should enable the authentication from any entity in the network, who retrieves or Li & Asaeda Expires September 6, 2018 [Page 2]
Internet-Draft Req. for KM in CCN/NDN March 2018 caches data, to another entity, who provides or publishes data, in contrast to the traditional end-to-end authentication. On the other hand, signature is already adopted as the fundamental function in CCN/NDN, which promises to achieve the integrity and publisher authentication. It can partially prevent the above attacks and but still is insufficient to protect the unpredictable data retrievals in CCN/NDN. Providing such data-centric authentications with or without these signatures heavily relies on Key Management (KM) schemes, which manage and protect the cryptographic keys throughout their lifecycles. It comprise the procedures to generate, deliver, store, protect, update, and revoke cryptographic keys. There are many existing proposals of KM schemes in Internet, such as Kerberos [14], MSEC [15], X.509 [16], PGP [17], RPKI [18]. They are designed to achieve different purposes with centralized or decentralized approach based on end-to-end communication paradigm within the Internet. They can only provide the authentications between the users and publishers without considering data-centric authentication, and are unable to prevent the malicious-request and data-poisoning attacks. Furthermore, they rely on centralized servers to acquire keys or certificates, thereby increasing authentication delays, which we refer to herein as the delay- enlargement problem. Obviously, they are not suitable for the emerging data-centric communication paradigm in CCN/NDN, because of different security and performance concerns. In this document, we identify the requirements for KM schemes in CCN/ NDN, which can be built-in to manage the cryptographic keys to protect the CCN/NDN basic operations and use scenarios. Please note that providing specific solutions (e.g., KM methods for data retrievals in CCN/NDN) to protect CCN/NDN communications and applications is out of scope of this document. 2. Terminology 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 RFC 2119 [1]. The following terminology is used throughout this document. o Cryptographic key: A string of bits used by a cryptographic algorithm to transform plain-text into cipher-text or vice versa. o Signature: A cryptographic value calculated through public key algorithm from the data and a secret key only known by the signer. It is to validate the authenticity and integrity of a message. Li & Asaeda Expires September 6, 2018 [Page 3]
Internet-Draft Req. for KM in CCN/NDN March 2018 o Certificate: A data structure used to verifiably bind an identity to a cryptographic key. o Compromise Recovery: The act of recovering a secure operating state after detecting that a member cannot be trusted. This can be accomplished by rekey. o Consumer: A node requesting data. It initiates communication by sending an interest packets. o Publisher: A node providing data. It originally creates or owns the data. o Router: A node forwarding data. It may hold memory to cache the data. o Forwarding Information Base (FIB): A lookup table in a router containing the name prefix and corresponding destination interface to forward the interest packets. o Pending Interest Table (PIT): A lookup table populated by the interest packets containing the name prefix of the requested data, and the outgoing interface used to forward the received data packets. o Content Store (CS): A storage space for a router to cache data objects. It is also known as in-network cache. 3. KM Basics, CCN/NDN Operations, and Use Scenarios In CCN/NDN, a KM scheme should be designed to incorporate with a set of routers, consumers, and publishers to collectively protect the CCN/NDN operations and applications. This section describes the KM basic procedures, the CCN/NDN operations, and the typical use scenarios to be protected. 3.1. KM Basic Procedures A KM scheme provides the foundation for the authentication services in the network operations and applications. A KM scheme should include the procedures for the generation, delivery, storage, protection, update and revocation of cryptographic keys or certificates, which are provided as follows. o P1 (Key Generation): A KM scheme should explicitly identify the involved entities, the trust relations among them, and the responsibilities for them. The cryptographic keys are generated based on the initial trust relations. For the public key Li & Asaeda Expires September 6, 2018 [Page 4]
Internet-Draft Req. for KM in CCN/NDN March 2018 approach, the KM scheme should also define the certificate issuance from the trustworthy entities. o P2 (Key Agreement): It is the procedure to enable more than one entity to create shared key(s), where public key approach is normally used. o P3 (Key/Certificate Delivery): A KM scheme should provide methods to deliver the generated keys or the issued certificates to the corresponding entities, which should follow the pre-defined trust relations in P1. o P4 (Key/Certificate Revocation): A KM scheme should provide the method to revoke the cryptographic key or the certificate, when it is compromised. o P5 (Key Storage): A KM scheme should provide secure method to protect the keys from compromisation when storing them. o P6 (Key/Certificate Update): Keys or certificates are generated and are valid during a period, after which they should be updated for the extension of service. o P7 (Key Backup): A KM scheme should provide method to backup the keys and enable the recovery of them when necessary, such as loss of keys. o P8 (Compromise Recovery): A KM scheme should enable the notification to user for the compromisations and the replacement of the compromised keys. 3.2. CCN/NDN Operations CCN/NDN provides name-based data retrievals as in Fig. 1. It further requires the data-centric authentication, instead of the end-to-end secure channel establishment in the current Internet. Li & Asaeda Expires September 6, 2018 [Page 5]
Internet-Draft Req. for KM in CCN/NDN March 2018 1.Interest 2.Interest 3.Interest 4.Interest +----+ +----+ +----+ +----+ | | | | | | | | | v | v | v | v +--------+ +--------+ +--------+ +--------+ +--------+ |Consumer|----| Router |----| Router |----| Router |----| Copy | | | | A | | B | | C | | Holder | +--------+ +--------+ +--------+ +--------+ +--------+ ^ | ^ | ^ | ^ | | | | | | | | | +----+ +----+ +----+ +----+ 8.Data 7.Data 6.Data 5.Data Figure 1: Request and reply messages forwarded by consumer, copy holder and routers. Regarding the ICN architectures, several typical ICN architectures, including DONA [19], PURSUIT [20], CCN/NDN [2][3], and NetInf [21], have been proposed. Among these work, CCN/NDN mainly focuses on the opportunistic close information copy discovery and retrieval through data-name-based routing. CCN/NDN shows its promising features on the low delay and traffic cost with the expense of in-network cache memories and it is the main focus of this document. In a CCN/NDN network, each router in a CCN/NDN network has three main data structures: a FIB for forwarding Interests, a CS for caching data, and a PIT for forwarding data. Basically there are two types of packets: interest and data. As in Fig. 1, consumer requests data by throwing an "interest" packet with the name of data to the network. Regarding the difference to note here between CCN [2] and NDN [3] is that in later versions of CCN, interest packet must carry a full data name, while in NDN it may carry a data name prefix. Once a router receives an "interest" packet, it performs a series of the following look-up. The router first checks in the CS to see whether it holds the corresponding data or not. If there is, it returns the data through the reverse path for forwarding interest packet as the copy holder in Fig. 1. If not, it performs a look-up of the PIT. If there is already a PIT entry matching the name of requested data, it is updated with the incoming interface of this new request and the interest is discarded. If there is no matching entry, it creates an entry in the PIT that lists the data name and the interfaces from which it received the interest. Then, the interest undergoes a FIB lookup to discover the outgoing interface. Li & Asaeda Expires September 6, 2018 [Page 6]
Internet-Draft Req. for KM in CCN/NDN March 2018 Once a copy of the "data" packet is retrieved, the router sends it back to the data requester(s) using the trail of PIT entries and remove the PIT state every time that an interest is satisfied. Additionally, it may store the data in its CS. However, data retrieval with in-network caching in CCN/NDN has been identified to suffer from malicious data-request attacks [7][8][9], and the data poisoning attacks [10][11][12]. In the former, adversaries impersonate consumers to create a flood of interests, and in the latter, they impersonate copy holders (e.g., routers or publishers) to provide fake data. These attacks are severe, because data are cached in a distributed manner, and copy holders have no way to verify consumers' identities, and consumers/routers have no way to verify copy holders' identities to avoid caching fake data. This form of attack can quickly pollute the router caches as the virus spreads, because routers cache the fake data, redistribute them, and other intermediate routers re-cache them. It finally consumes much in-network caches and prevents consumers from retrieving the correct data. Besides these attacks, the setting of FIB also suffers from the fake router announcement. A KM scheme should be designed to provide efficient authentications among routers, copy holders, and consumers. 3.3. CCN/NDN Use Scenarios There are many promising use scenarios for CCN/NDN. Herein we focus on three typical use scenarios of ICN, disaster networking, video streaming, and Internet of Things (IoT), to explain the security issues for them. For the disaster networking, [13] has already listed the Emergency Support and Disaster Recovery as one of ICN Baseline Scenarios, that can be used as a base for the evaluation of different ICN approaches. Further, [4] has outline the research directions for using ICN in disaster scenario. In the disaster scenario, communication infrastructures in a disaster area are usually fragmented or disconnected. On the other hand, mobile phones and SNS notifications show the importance for safety confirmations, rescue notifications, and message exchanges. In this scenario, the attackers deliberately disseminate or exchange the fake information to common users, which may bring out panic. Especially, in this scenario, the normal authentications relying on centralized servers are usually unworkable and the unpredictable separations of network happens frequently. For the disaster networking with CCN/NDN, the data can be cached by the mobile routers of the attackers to share with different fragmented networks. Thus, the attackers can disseminate the fake data one by one for different Li & Asaeda Expires September 6, 2018 [Page 7]
Internet-Draft Req. for KM in CCN/NDN March 2018 fragmentations. Disaster networking has similar features as other opportunistic networks such as ad hoc network and vehicular networks facing similar security issues when applying CCN/NDN. Video traffic has already occupy much Internet traffic, which should also be an important use scenario for future networks. Real-time communication scenario including video transmission has been listed as one of the ICN base scenarios [13] and further the adaptive video streaming over ICN has been discussed in [5]. In the video streaming scenario, real-time live data transmission and on-demand data downloading are two main use cases. In most times, this scenario has much more stricter requirements on the quality of experiences (QoE) and low delay for the consumer, and the one-to-many group communication paradigm plays fundamental role to provide service for video data transmissions. Additionally, in-network caching video data with CCN/NDN helps to improve the performance for video transmissions. For the video streaming scenario, the digital right management (DRM) is one of the most important functions, which protects the incentive of video industry. However, the attacker can impersonate the consumers to retrieve data. If all the consumers are assigned with the same key for decryption, any one consumer can illegally distribute the key to others, which violates the copyright policy. The consumer can illegally get the previous data when he newly joins a video service. Also, she can illegally continue to retrieve the data even her key has expired or her service has been terminated. In addition, the cryptographic algorithm should be efficient to enable the fluent streaming of video. These attacks can make the system be even worse when targeting at the in-network cached video data. IoT has been identified as one of the most important ICN use scenarios [13][6]. ICN can provide the benefits to IoT from the aspects of naming, caching, optimized transport, efficient data retrieval, mobility, and contextual communication services. For ICN- IoT scenario, energy limitation for the resource-constrained devices and the heterogeneity on the underlay networks and operators should be considered. The attacker can impersonate sensors to provide fake data or impersonate authorized user to collect the sensor data or deliberately inject the fake data into the network. 4. KM Requirements for CCN/NDN 4.1. Requirements for Protecting Network Operations Li & Asaeda Expires September 6, 2018 [Page 8]
Internet-Draft Req. for KM in CCN/NDN March 2018 4.1.1. Functional Requirements o R1 (Data-centric design): Any router or consumer can easily authenticate the data, publisher, and copy holder, and any copy holder can easily authenticate consumers. o R2 (Secure registration): To guarantee that publishers, users, and routers to be securely registered for the binding between name and real world identity. o R3 (Efficient revocation): If a key or certificate becomes compromised or invalid, it should be revoked from use with low cost. o R4 (Efficient key update): Key should be updated periodically, which should keep the security level without causing much overhead. o R5 (Key/certificate storage and caching): In-Network caching can improve the key/certificate distribution efficiency. o R6 (Routing Security): The KM should enable the protection on the information exchanges among the routers. 4.1.2. Performance Requirements o R7 (Low bandwidth consumption): The KM scheme should not increase the packet size substantially and should have a negligible impact on bandwidth consumption. o R8 (Minimal additional delay): The KM scheme should cause minimal (ideally zero) additional delays to data retrieval. 4.2. Requirements for Protecting Use Scenarios 4.2.1. Requirements for Protecting Disaster Networking with CCN/NDN o R9 (Availability): KM should be provided to make the authentications to data originator be possible, even the network is fragmented or disconnected. It also requires the KM service provision among the fragmented or disconnected network partitions to enable cross-fragmentation authentications. o R10 (Energy efficiency): KM should not consume much energy of mobile devices for data exchange. Li & Asaeda Expires September 6, 2018 [Page 9]
Internet-Draft Req. for KM in CCN/NDN March 2018 o R11 (Robustness): KM should provide methods to bind a new name with a real-world identity, because there must be many newly assigned terminals for the refugees. o R12 (Revocation synchronization): The revocation for the identities should be synchronized for the fragmented networks. 4.2.2. Requirements for Protecting Video Streaming over CCN/NDN o R13 (Backward and forward secrecy): KM should be provided to prevent a new consumer from decrypting the data published before it joined the streaming group and prevent a leaving consumer from accessing the further video data, even they are provided by the servers or in-network caches. o R14 (Light-weight): The KM should be light-weight for video data decryption. If it is a heavy burden for users to decrypt the data, the mechanism will not be used. o R15 (Efficient key revocation): The revocation of keys should be efficient and prevent the further in-network cached data from being decrypted using the compromised or expired keys. o R16 (Scalability): The KM should enable thousands or millions of consumers, routers, and publishers. For example, the olympic games or the football games attract huge number of consumers simultaneously. 4.2.3. Requirements for Protecting IoT using CCN/NDN o R17 (Low Energy Consumption): The KM should not consume much energy, especially when running on the constraint devices. o R18 (Heterogeneity): The KM should enable the sensor data to be provided to the devices over heterogeneous platforms managed by different operators . o R19 (Privacy preserving): The KM should protect the privacy of the sensor data, even they are cached in the network. 5. References 5.1. Normative References [1] 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>. Li & Asaeda Expires September 6, 2018 [Page 10]
Internet-Draft Req. for KM in CCN/NDN March 2018 5.2. Informative References [2] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proc. CoNEXT, ACM, December 2009. [3] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, "Named data networking", ACM Comput. Commun. Rev., vol. 44, no. 3, July 2014. [4] Seedorf, J., Arumaithurai, M., Tagami, A., Ramakrishnan, K., and N. Melazzi, "Research Directions for Using ICN in Disaster Scenarios", draft-irtf-icnrg-disaster-03 (work in progress), February 2018. [5] Westphal, C., Lederer, S., Posch, D., Timmerer, C., Azgin, A., Liu, W., Mueller, C., Detti, A., Corujo, D., Wang, J., Montpetit, M., and N. Murray, "Adaptive Video Streaming over Information-Centric Networking (ICN)", RFC 7933, August 2016. [6] Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Raychadhuri, D., Baccelli, E., Burke, J., Wang, G., Ahlgren, B., and O. Schelen, "Design Considerations for Applying ICN to IoT", draft-irtf-icnrg-icniot-01 (work in progress), February 2018. [7] Afanasyev, A., Mahadevan, P., Moiseenko, I., Uzun, E., and L. Zhang, "Interest flooding attack and countermeasures in named data networking", Proc. IFIP Networking, IFIP, May 2013. [8] Compagno, A., Conti, M., Gasti, P., and G. Tsudik, "Poseidon: mitigating interest flooding ddos attacks in named data networking", Proc. LCN 2013, IEEE, October 2013. [9] Nguyen, T., Cogranne, R., and G. Doyen, "An optimal statistical test for robust detection against interest flooding attacks in ccn", Proc. International Symposium on Integrated Network Management (INM), IFIP/IEEE, May 2015. [10] Ghali, C., Tsudik, G., and E. Uzun, "Network-layer trust in named-data networking", ACM SIGCOMM Computer Communication Review, vol.44, no. 5, October 2014. Li & Asaeda Expires September 6, 2018 [Page 11]
Internet-Draft Req. for KM in CCN/NDN March 2018 [11] Kim, D., Nam, S., Bi, J., and I. Yeom, "Efficient content verification in named data networking", Proc. ACM Conference on Information-Centric Networking, ACM, September 2015. [12] Gasti, P., Tsudik, G., Uzun, E., and L. Zhang, "Dos and ddos in named data networking", Proc. IEEE ICCCN 2013, IEEE, August 2013. [13] Pentikousis, K., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, March 2015. [14] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [15] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [16] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [17] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [18] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol Version 1", RFC 8210, September 2017. [19] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, K., Shenker, S., and I. Stoica, "A data-oriented (and beyond) network architecture", Proc. ACM Sigcomm 2007 ACM, August 2007. [20] Jokela, P., Zahemszky, A., Rothenberg, C., Arianfar, S., and P. Nikander, "LIPSIN: Line speed publish/subscribe inter-networking", Proc. ACM Sigcomm 2009 ACM, August 2009. Li & Asaeda Expires September 6, 2018 [Page 12]
Internet-Draft Req. for KM in CCN/NDN March 2018 [21] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and H. Karl, "Network of Information (NetInf) - An information-centric networking architecture", Elsevier Journal of Computer Communications vol. 36, issue 7, April 2013. Authors' Addresses Ruidong Li National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi Koganei, Tokyo 184-8795 Japan Email: lrd@nict.go.jp Hitoshi Asaeda National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi Koganei, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp Li & Asaeda Expires September 6, 2018 [Page 13]