Information-Centric Networking Research Group R. Li Internet-Draft H. Asaeda Intended status: Informational NICT Expires: May 19, 2020 November 16, 2019 Hop-by-Hop Authentication in Content-Centric Networking/Named Data Networking draft-li-icnrg-hopauth-01 Abstract The unpredictability of consumers, routers, copyholders, and publishers for the in-network data retrievals in Content-Centric Networking (CCN) / Named Data Networking (NDN) poses a challenge to design an authentication mechanism to inhibit the malicious consumers to flood data requests and prevent the fake data from being provided. Signature is adopted as the fundamental function in CCN / NDN, which however can only provide publisher authentication with additional certificate acquisition. This document describes the the Hop-by-Hop Authentication mechanism (HopAuth) integrating certificate collection and packet forwarding potentially with the assistance from certificate authority to provide consumer authentication, copyholder authentication and path authentication to enable the in-network data retrieval to be trustworthy, besides the publisher authentication. 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 May 19, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Li & Asaeda Expires May 19, 2020 [Page 1] Internet-Draft HopAuth in CCN/NDN November 2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. System Descriptions . . . . . . . . . . . . . . . . . . . . . 5 4. HopAuth Designs . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Initial Trust Establishment . . . . . . . . . . . . . . . 7 4.2. Data-centric Certificate Management . . . . . . . . . . . 8 4.2.1. Certificate Exchange . . . . . . . . . . . . . . . . 8 4.2.2. Certificate Update and Revocation . . . . . . . . . . 9 4.3. Forwarding-Integrated Authenticable Data Retrieval . . . 10 4.4. Suspension-Chain Model (SCM) . . . . . . . . . . . . . . 11 5. Protocol Message Format . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Information-Centric Networks in general, and Content-Centric Networking (CCN) [3] or Named Data Networking (NDN) [4] 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 consumers 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 [5], video streaming [6], and Internet of Things (IoT) [8]. 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 [9], [10], [11], and the data poisoning attack [12], [13], [14]. The unpredictability of consumers, routers, copy holders, and publishers during data Li & Asaeda Expires May 19, 2020 [Page 2] Internet-Draft HopAuth in CCN/NDN November 2019 retrievals in CCN/NDN poses the novel challenge to design data- centric authentication to prevent these attacks. This novel authentication should potentially enable the consumer authentication, copyholder authentication to authenticate the identity of the entity providing data, path authentication to authenticate the path from which data are retrieved, in addition to the publisher 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. The unpredictability with which copy holders provide data, routers cache data, and consumers request data leads to great difficulty in inhibiting malicious-request attacks and data- poisoning attacks. To prevent data poisoning, consumers and routers need to verify data before caching them. If the data are found to be fake, the copy holder providing the data and the path to retrieve the data also need to be discovered in order to disable the further spread of that fake data. To prevent malicious-request attacks, copy holders need to verify the identities of the consumers. There are many authentication mechanisms with key management schemes in the Internet, such as Kerberos [15], MSEC [16], X.509 [17], PGP [18], RPKI [19]. They are designed to achieve different purposes with centralized or decentralized approach based on end-to-end communication paradigm in the Internet. They can only provide the authentications of consumers and publishers or the link between them. In other words, they do not consider data-centric authentication, that is aimed to protect data in the networks. For data-centric authentication, the key is to protect or prevent data-poisoning and malicious-request attacks. Regarding the data poisoning attacks, if the fake or corrupted data are cached along the path, consumers who use the path always retrieve the wrong data, because the router does not detect the cached data validity (as it is signed by attacker correctly). The fake or corrupted data are further cached, which pollute the routers as virus spreads. These routers will provide the fake or corrupted data to other potential consumers. Therefore, to inhibit the data poisoning attacks, routers need to verify the data before caching them and consumers need to verify the copyholder and the path to retrieve data. For malicious requests, even malicious Interests can be reduced by restricting sending rate, part of malicious Interests still can reach the copyholder. If copyholders verify the Interests before replying the data, the effect to inhibit the Interest flooding attack can be improved. Hence, the authentication from any consumer or router to Li & Asaeda Expires May 19, 2020 [Page 3] Internet-Draft HopAuth in CCN/NDN November 2019 Interest, data, copyholder, and the data retrieval path plays crucial role to inhibit the data poisoning and malicious-request attacks, besides the identity authentication to the publisher. Another concern is that most of the existing authentication mechanisms 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 cannot satisfy the following performance requirements for the emerging data-centric communication paradigm in CCN/NDN: any consumer or router needs to authenticate Interest, data, copyholder (including publisher), and the data retrieval path without additional messaging delay. In this document, we describe a secure mechanism named HopAuth, where forwarding-integrated hop-by-hop certificate collection is performed together with the adaptive replacement for parts of chain with highly trustworthy certificates. This specification derives directly from the design published in [20]. In HopAuth, a suspension-chain model (SCM) is used as the trust model, where the neighbor-trust-based certificate chain is suspended by certificate authority (CA)-based trust. The HopAuth avoids reliance on centralized server(s) for chain construction and solves the delay-enlargement problem. 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. o Certificate: A data structure used to verifiably bind an identity to a cryptographic key. 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. Li & Asaeda Expires May 19, 2020 [Page 4] Internet-Draft HopAuth in CCN/NDN November 2019 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. o Physical entity: an entity that communicates using a physical device. This could be a router or a publisher node (PN) that hosts applications. o Logical entity: an entity that is involved in an application. This can be an authorizer, a sub-authorizer, or a publisher. 3. System Descriptions Here we briefly explain the background and basic network operations of CCN/NDN. Different from the end-to-end communications in the Internet, CCN/NDN provides data-name-based retrievals as in Fig. 1. It further requires the data-centric authentication, instead of the current end-to-end secure channel establishment. 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. Li & Asaeda Expires May 19, 2020 [Page 5] Internet-Draft HopAuth in CCN/NDN November 2019 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 [3] and NDN [4] 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. 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 [9], [10], [11], and the data poisoning attacks [12], [13], [14]. 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, consumers/ routers have no way to verify copy holders' identities to avoid caching fake data, and the path to retrieve data cannot be verified. 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. Li & Asaeda Expires May 19, 2020 [Page 6] Internet-Draft HopAuth in CCN/NDN November 2019 4. HopAuth Designs Herein we elaborate the basic design of HopAuth, which has three phases: 1) initial trust-establishment, 2) data-centric certificate management, and 3) forwarding-integrated authenticable data- retrieval. The trust model for HopAuth is given by a suspension chain model (SCM) later explained. For the first phase, certificates are issued for neighboring entities and the certificate authority (CA) potentially issues certificates to a set of routers to form the highly trusted router group (HTRG). Let CE(A->B) represent the public-key certificate issued from A to B. In the second phase, routers exchange certificates within their neighborhoods, and any compromised entity can be shut down quickly. Finally, the third phase provides a hop-by-hop method for constructing a chain consisting of a physical-entity certificate chain (peCEChain) and a logical-entity certificate chain (leCEChain) for data-centric authentication. 4.1. Initial Trust Establishment The initial trust establishment has two components: self-certifiable naming and certificate issuing. Self-certifiable naming defines the rule for naming the principals, including entities, keys, and certificates, to enable the entities to be self-certifiable. As the extension of the cryptographically generated address (CGA) [7], we merge the hash-based self-certifying names with hierarchical naming. It embeds the public key into the name, which is self-certifiable. The purpose of self-certifiable naming is to prevent stealing and spoofing of existing names. The public key of the name owner is bound cryptographically to the name. The name owner can use the corresponding private key to assert its ownership and to sign messages sent from the entity with that name. In fact, an attacker can create a new name from an arbitrary public key. However, the attacker cannot impersonate somebody else's name. To issue a certificate, an entity should be convinced that a given public key truly belongs to another entity. Under that situation, it issues a certificate for this entity such that the public key is bound to the entity name by its signature. In HopAuth, certificate issuing is the initial trust establishment among entities having trust relationships, namely as neighbor-based trust for physical entities, CA-based trust, and authorization relationships for logical entities. For neighbor-based trust, a physical entity creates a public key and the corresponding private key locally by itself. It generates the Li & Asaeda Expires May 19, 2020 [Page 7] Internet-Draft HopAuth in CCN/NDN November 2019 names using the public key based on the self-certifiable naming method. If physical entity B is a neighbor of entity A, B can announce its public key to A with the key name and A generates the certificate for B. CA-based trust between two entities is established using the CA as the "introducer". The CA is managed by the network operator, and provides certificates to the owner's entities and the highly trusted physical entities close to them in the HTRG. The entities in the HTRG then confer CA-based trust relationships and issue certificates to each other. All the highly trustable entities register at CA. CA has the whole view of these entities and determines the neighboring relations among the entities in HTRG. After determination of the neighboring relations, an entity, A, sends interest to CA to request the certificates of its neighbors. CA replies with the related certificates to A, such as CE(CA->B). After A receiving the certificates, A verifies them, issues certificates from itself to those neighbors, such as CE(A->B), and sends to CA. CA verifies this certificate and forwards it to B when B requests. In HopAuth, the physical entities pre-keep the certificates and associate certificates with interfaces in FIB. The physical entity knows the next hop of one interface, and it associates the certificate from that entity to itself with the forwarding interface. This mechanism enables the appending of the relevant certificate to the packets as required when forwarding them. For logical entities, the trust relationship is defined by the application. Each logical entity also generates a public/private key pair by itself. If logical entity A authorizes the right for entity B to manage a sub-category or publish data, A should provide a certificate for the true public key of B. 4.2. Data-centric Certificate Management 4.2.1. Certificate Exchange Certificate exchange allows entities to share the certificates that they issue and hold. Each physical entity has a local repository in which to store certificates securely. In HopAuth, the physical entities request and keep all the certificates issued for or by their nearby highly trusted entities in the HTRG and by common neighboring physical entities. To exchange the information of certificates they hold, each entity hashes the names of certificates and exchange hashes to see if there is one missed in the neighborhood. If there is, the entity will send interest to its neighbor to retrieve that Li & Asaeda Expires May 19, 2020 [Page 8] Internet-Draft HopAuth in CCN/NDN November 2019 certificate. Finally, the physical entities hold all the certificates within a two-hop distance and the certificates with nearby highly trusted entities in the HTRG. These certificates are used to construct chains hop by hop, shorten certificate chains, and check the certificates appended by an up-stream entity. This certificate check is performed by the next hop of the entity to check whether the certificate appended by this entity is the same as the one stored by it. If the certificates are the same, the certificate passes the check. Otherwise, this packet will be dropped because of the fake certificate. The certificates of the logical entities in an application should be stored in the repository of the PN. When data are published, the trust chain from the PN to the publisher can be automatically formed and appended to the packet. Meanwhile, the neighbors of the PN also keep all the certificates of the PN in order to check them during transmissions. 4.2.2. Certificate Update and Revocation To guarantee its validity, each certificate in the network is issued with a certificate expiration time, after which the certificate is invalid. For certificate updates using neighbor-based trust, the subject entity of the certificate should notify the issuer of its interest in updating the certificate. On receiving this interest, the issuer checks whether this entity has been compromised. It then checks whether the mapping between the name and the public key satisfies the naming rule. If all the checks are passed, the issuer considers whether the public key of the subject entity is still trustworthy, generates an updated certificate, and replies with this updated certificate. If any check is failed, the issuer does not provide a certificate update to that entity. For certificate updates using CA- based trust in the HTRG, the subject entity of the certificate requests the CA to issue an updated certificate and provide it to the related nearby highly trusted routers, who can further issue update certificates. If one entity no longer wishes to trust another entity, the former may revoke the certificate that it originally issued. Because certificates are issued over a one-hop distance, it is easy to detect the misbehavior of an entity. To revoke a certificate quickly, the revocation is announced over a two-hop distance. The revocation initiator broadcasts the revocation information to all the entities within a two-hop distance. Each entity receiving this information adds the compromised entity or certificate to its blacklist. All the Li & Asaeda Expires May 19, 2020 [Page 9] Internet-Draft HopAuth in CCN/NDN November 2019 packets from the compromised entities are dropped for a rapid local shutdown. 4.3. Forwarding-Integrated Authenticable Data Retrieval Here, when forwarding interests and data, we define a forwarding- integrated hop-by-hop approach to construct the suspended chain from unpredictable copy holders to a consumer for authenticating interest, and from a consumer or router to data for authenticating copy holders or publishers or path to retrieve data. We let highly trusted routers replace the parts of chain with highly trusted certificates induced by CA's suspended trust to enhance trustworthiness. The steps for data retrieval are as follows. Step 1: The consumer issues an interest appended with its signature. It knows its next hop is the router to which it is connected. It then appends to this interest the certificate from the next-hop router to itself. Finally, it sends out the interest. Step 2: When the interest is received by an router, it checks whether the previous certificates are correct. If the check succeeds and it belongs to the HTRG, this router attempts to find the previous highly trusted router to replace the related part of the certificate chain with one highly trusted certificate in the suspended chain. If this IPE does not belong to the HTRG, it directly finds the interface to the next hop and appends to the interest the relevant certificate from the next-hop router to itself. Step 3: This is executed if an router holds the requested data in its cache. The router checks the suspended chain from it to the consumer through the process described later in the SCM. If the verification succeeds, this router replies with the data packet. In the data packet, the suspended chain from this router to the publisher and the certificate from the next router to this router are appended. This router sends this data packet to the interface in reply as specified in the PIT. Step 4: If the PN receives the interest, it verifies the suspended chain from itself to the consumer. If the verification succeeds, the PN discovers the suspended chain from itself to the publisher in its storage, and appends this certificate chain with the certificate from the first router to itself. Next, the PN replies with these data using the reverse path of the interest. Step 5: After the router receives the data packet, it performs forwarding and possibly caching. When the router intends to cache the data, it first caches them in a temporary cache, which is Li & Asaeda Expires May 19, 2020 [Page 10] Internet-Draft HopAuth in CCN/NDN November 2019 separated from the data cache. Second, it checks the suspended chain from itself to the publisher. Only if the verification passes, these data can be cached in the data memory and the suspended chain from this router to the publisher will be cached along with the data. The verification is performed offline, which does not affect the speed of data retrieval. At the same time, this router checks the previous certificate. If the check is successful and it belongs to the HTRG, it will discover the previous entity in the suspended chain belonging to the HTRG. If there is a previous entity, the router replaces part of the related certificate path with a highly trusted certificate. Otherwise, the router directly finds the interface to the corresponding certificate from the next hop to itself and appends this certificate to the packet, then forwards this packet to the interface. Step 6: After the consumer receives the data packet, there should be a certificate chain from it to the publisher. It verifies this suspended chain. If the verification passes, it believes that it gets the authentic public key of the publisher, and utilizes the key to verify the signature of the data. The consumer can also verify the copy holder or the routers on the path. 4.4. Suspension-Chain Model (SCM) A suspension-chain model (SCM) is the trust model in HopAuth. It is a flexible series of neighbor-trust-based certificates suspended by CA's trust, which form a suspension chain. In SCM, neighbor-based trust forms the certificate chain to realize data-centric authentication, whereas CA-based trust reduces the length of the chain to solve the trust degradation problem for certificate chain. For CA's trust, the CA assigns certificates to highly trusted routers as the suspension points based on CA's trust, which is the pre-trust between these routers and CA. Public-key verification is the process for one entity to verify the authenticity of the public key of another entity. Entity X authenticates the public key of the entity Y by verifying the suspension chain in the following steps. First, X verifies the first certificate by its private key. If it is correct, each intermediate public key is used to verify the next direct associated certificate. This process continues for multiple rounds until the final certificate is verified. Finally, X obtains the true public key of the entity Y. Li & Asaeda Expires May 19, 2020 [Page 11] Internet-Draft HopAuth in CCN/NDN November 2019 5. Protocol Message Format HopAuth messages are encoded in the CCNx TLV format [2]. An example of HopAuth packet format with a certificate chain from consumer C0 to router R_n, (CE1(C0->R1), ..., CE_n(R_(n-1)->R_n)), is provided in Figure 2. As in Figure 2, the HopAuth message consists HopAuth header, and HopAuth certificate TLVs. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PT_CONTENT | PacketLength | +---------------+---------------+---------------+---------------+ | Reserved | Flags | HeaderLength | +===============+===============+===============+===============+ | T_HOPAUTH | Length(=n) | +---------------+---------------+---------------+---------------+ | Total length of inserted T_HOPAUTH_CERT TLVs | +===============+===============+===============+===============+ | T_Object | Object Message Length | +---------------+---------------+---------------+---------------+ / Object Message / +---------------+---------------+---------------+---------------+ | T_VALIDATION_ALG | Validation Algorithm Length | +---------------+---------------+---------------+---------------+ / Validation Algorithm Data / +---------------+---------------+---------------+---------------+ | T_VALIDATION_PAYLOAD | Signature Length | +---------------+---------------+---------------+---------------+ / Signature Data / +---------------+---------------+---------------+---------------+ | T_HOPAUTH_CERT | CE1 Length | +---------------+---------------+---------------+---------------+ / CE1(C0->R1) / +---------------+---------------+---------------+---------------+ / . / / . / +---------------+---------------+---------------+---------------+ | T_HOPAUTH_CERT | CE_n Length | +---------------+---------------+---------------+---------------+ / CE_n(R_(n-1)->R_n) / +===============+===============+===============+===============+ Figure 2: An Example of HopAuth packet format The HopAuth header is composed of the fields of type, Length, and Total length of inserted T_HOPAUTH_CERT's TLVs. The type is Li & Asaeda Expires May 19, 2020 [Page 12] Internet-Draft HopAuth in CCN/NDN November 2019 T_HOPAUTH, the Length shows the number of inserted certificates, and Total length of inserted T_HOPAUTH_CERT's TLVs describes the total number of bits occupied by certificate TLVs. In the part of HopAuth certificate TLVs, the certificate name, length and certificate data are included. Take CE1(C0->R1) in Figure 2 as example. The type is T_HOPAUTH_CERT, CE1 Length is the length of certificate CE1(C0->R1), and CE1(C0->R1) is the certificate data for CE1(C0->R1). 6. Security Considerations This document is entirely about an authentication mechanism in CCN/ NDN. 7. References 7.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, . [2] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV Format", RFC 8609, July 2019. 7.2. Informative References [3] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proc. CoNEXT, ACM, December 2009. [4] 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. [5] Seedorf, J., Arumaithurai, M., Tgami, A., Ramakrishnan, K., and N. Melazzi, "Research Directions for Using ICN in Disaster Scenarios", draft-irtf-icnrg-disaster-07 (work in progress), June 2019. [6] 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. Li & Asaeda Expires May 19, 2020 [Page 13] Internet-Draft HopAuth in CCN/NDN November 2019 [7] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [8] Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Burke, J., Ahlgren, B., and A. Azgin, "Design Considerations for Applying ICN to IoT", draft-irtf-icnrg-icniot-03 (work in progress), May 2019. [9] 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. [10] 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. [11] 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. [12] 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. [13] 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. [14] Gasti, P., Tsudik, G., Uzun, E., and L. Zhang, "Dos and ddos in named data networking", Proc. IEEE ICCCN 2013, IEEE, August 2013. [15] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [16] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [17] 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. Li & Asaeda Expires May 19, 2020 [Page 14] Internet-Draft HopAuth in CCN/NDN November 2019 [18] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [19] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol Version 1", RFC 8210, September 2017. [20] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric Authentication for Secure In-Network Big-Data Retrieval", IEEE Transactions on Network Science and Engineering, DOI: 10.1109/TNSE.2018.2872049, September 2018. 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 May 19, 2020 [Page 15]