Internet DRAFT - draft-li-icnrg-km-reqs
draft-li-icnrg-km-reqs
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]
