idnits 2.17.1 draft-li-icnrg-hopauth-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-disaster-07 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Information-Centric Networking Research Group R. Li 3 Internet-Draft H. Asaeda 4 Intended status: Informational NICT 5 Expires: January 9, 2020 July 8, 2019 7 Hop-by-Hop Authentication in Content-Centric Networking/Named Data 8 Networking 9 draft-li-icnrg-hopauth-00 11 Abstract 13 The unpredictability of consumers, routers, copyholders, and 14 publishers for the in-network data retrievals in Content-Centric 15 Networking (CCN) / Named Data Networking (NDN) poses a challenge to 16 design an authentication mechanism to inhibit the malicious consumers 17 to flood data requests and prevent the fake data from being provided. 18 Signature is adopted as the fundamental function in CCN / NDN, which 19 however can only provide publisher authentication with additional 20 certificate acquisition. This document describes the the Hop-by-Hop 21 Authentication mechanism (HopAuth) integrating certificate collection 22 and packet forwarding potentially with the assistance from 23 certificate authority to provide consumer authentication, copyholder 24 authentication and path authentication to enable the in-network data 25 retrieval to be trustworthy, besides the publisher authentication. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. System Descriptions . . . . . . . . . . . . . . . . . . . . . 5 64 4. HopAuth Designs . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Initial Trust Establishment . . . . . . . . . . . . . . . 6 66 4.2. Data-centric Certificate Management . . . . . . . . . . . 8 67 4.2.1. Certificate Exchange . . . . . . . . . . . . . . . . 8 68 4.2.2. Certificate Update and Revocation . . . . . . . . . . 8 69 4.3. Forwarding-Integrated Authenticable Data Retrieval . . . 9 70 4.4. Suspension-Chain Model (SCM) . . . . . . . . . . . . . . 10 71 5. Protocol Message Format . . . . . . . . . . . . . . . . . . . 11 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 7.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 Information-Centric Networks in general, and Content-Centric 81 Networking (CCN) [3] or Named Data Networking (NDN) [4] in 82 particular, are the emerging network architectures enabling in- 83 network caching and data retrievals through their names. In CCN/NDN, 84 data can be cached at the intermediate routers, close to consumers 85 for reducing delay and redundant bandwidth consumption or for the 86 robustness under dynamic network environment. It has been noticed 87 that CCN/NDN is a promising approach for the application scenarios in 88 disaster networking [5], video streaming [6], and Internet of Things 89 (IoT) [7] . 91 In CCN/NDN, the basic network operations and these use scenarios with 92 in-network data caching and retrievals lead the network to be 93 seriously vulnerable under a variety of attacks, such as the 94 impersonation attack, malicious-request attack [8], [9], [10], and 95 the data poisoning attack [11], [12], [13]. The unpredictability of 96 consumers, routers, copy holders, and publishers during data 97 retrievals in CCN/NDN poses the novel challenge to design data- 98 centric authentication to prevent these attacks. This novel 99 authentication should potentially enable the consumer authentication, 100 copyholder authentication to authenticate the identity of the entity 101 providing data, path authentication to authenticate the path from 102 which data are retrieved, in addition to the publisher 103 authentication. 105 On the other hand, signature is already adopted as the fundamental 106 function in CCN/NDN, which promises to achieve the integrity and 107 publisher authentication. It can partially prevent the above attacks 108 and but still is insufficient to protect the unpredictable data 109 retrievals in CCN/NDN. The unpredictability with which copy holders 110 provide data, routers cache data, and consumers request data leads to 111 great difficulty in inhibiting malicious-request attacks and data- 112 poisoning attacks. To prevent data poisoning, consumers and routers 113 need to verify data before caching them. If the data are found to be 114 fake, the copy holder providing the data and the path to retrieve the 115 data also need to be discovered in order to disable the further 116 spread of that fake data. To prevent malicious-request attacks, copy 117 holders need to verify the identities of the consumers. 119 There are many the existing authentication mechanisms with key 120 management schemes in Internet, such as Kerberos [14], MSEC [15], 121 X.509 [16], PGP [17], RPKI [18]. They are designed to achieve 122 different purposes with centralized or decentralized approach based 123 on end-to-end communication paradigm within the Internet. They can 124 only provide the authentications between the consumers and publishers 125 without considering data-centric authentication, and are unable to 126 prevent the malicious-request and data-poisoning attacks. 127 Furthermore, they rely on centralized servers to acquire keys or 128 certificates, thereby increasing authentication delays, which we 129 refer to herein as the delay-enlargement problem. Obviously, they 130 cannot satisfy the requirements for the emerging data-centric 131 communication paradigm in CCN/NDN, because of different security and 132 performance concerns. 134 In this document, we elaborate HopAuth [19], where forwarding- 135 integrated hop-by-hop certificate collection is performed together 136 with the adaptive replacement for parts of chain with highly 137 trustworthy certificates. In HopAuth, a suspension-chain model (SCM) 138 is used as the trust model, where the neighbor-trust-based 139 certificate chain is suspended by certificate authority (CA)-based 140 trust. The HopAuth avoids reliance on centralized server(s) for 141 chain construction and solves the delay-enlargement problem. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [1]. 149 The following terminology is used throughout this document. 151 o Cryptographic key: A string of bits used by a cryptographic 152 algorithm to transform plain-text into cipher-text or vice versa. 154 o Signature: A cryptographic value calculated through public key 155 algorithm from the data and a secret key only known by the signer. 156 It is to validate the authenticity and integrity of a message. 158 o Certificate: A data structure used to verifiably bind an identity 159 to a cryptographic key. 161 o Consumer: A node requesting data. It initiates communication by 162 sending an interest packets. 164 o Publisher: A node providing data. It originally creates or owns 165 the data. 167 o Router: A node forwarding data. It may hold memory to cache the 168 data. 170 o Forwarding Information Base (FIB): A lookup table in a router 171 containing the name prefix and corresponding destination interface 172 to forward the interest packets. 174 o Pending Interest Table (PIT): A lookup table populated by the 175 interest packets containing the name prefix of the requested data, 176 and the outgoing interface used to forward the received data 177 packets. 179 o Content Store (CS): A storage space for a router to cache data 180 objects. It is also known as in-network cache. 182 o Physical entity: an entity that communicates using a physical 183 device. This could be a router or a publisher node (PN) that 184 hosts applications. 186 o Logical entity: an entity that is involved in an application. 187 This can be an authorizer, a sub-authorizer, or a publisher. 189 3. System Descriptions 191 Here we briefly explain the background and basic network operations 192 of CCN/NDN. Different from the end-to-end communications in 193 Internet, CCN/NDN provides data-name-based retrievals as in Fig. 1. 194 It further requires the data-centric authentication, instead of the 195 current end-to-end secure channel establishment. 197 1.Interest 2.Interest 3.Interest 4.Interest 198 +----+ +----+ +----+ +----+ 199 | | | | | | | | 200 | v | v | v | v 201 +--------+ +--------+ +--------+ +--------+ +---------+ 202 |Consumer|----| Router |----| Router |----| Router |----|Copy | 203 | | | A | | B | | C | |Holder | 204 +--------+ +--------+ +--------+ +--------+ +---------+ 205 ^ | ^ | ^ | ^ | 206 | | | | | | | | 207 +----+ +----+ +----+ +----+ 208 8.Data 7.Data 6.Data 5.Data 210 Figure 1: Request and reply messages forwarded by consumer, copy 211 holder and routers. 213 In a CCN/NDN network, each router in a CCN/NDN network has three main 214 data structures: a FIB for forwarding Interests, a CS for caching 215 data, and a PIT for forwarding data. Basically there are two types 216 of packets: interest and data. As in Fig. 1, consumer requests data 217 by throwing an "interest" packet with the name of data to the 218 network. Regarding the difference to note here between CCN [3] and 219 NDN [4] is that in later versions of CCN, interest packet must carry 220 a full data name, while in NDN it may carry a data name prefix. 222 Once a router receives an "interest" packet, it performs a series of 223 the following look-up. 225 The router first checks in the CS to see whether it holds the 226 corresponding data or not. If there is, it returns the data through 227 the reverse path for forwarding interest packet as the copy holder in 228 Fig. 1. If not, it performs a look-up of the PIT. If there is 229 already a PIT entry matching the name of requested data, it is 230 updated with the incoming interface of this new request and the 231 interest is discarded. If there is no matching entry, it creates an 232 entry in the PIT that lists the data name and the interfaces from 233 which it received the interest. Then, the interest undergoes a FIB 234 lookup to discover the outgoing interface. 236 Once a copy of the "data" packet is retrieved, the router sends it 237 back to the data requester(s) using the trail of PIT entries and 238 remove the PIT state every time that an interest is satisfied. 239 Additionally, it may store the data in its CS. 241 However, data retrieval with in-network caching in CCN/NDN has been 242 identified to suffer from malicious data-request attacks [8], [9], 243 [10], and the data poisoning attacks [11], [12], [13]. In the 244 former, adversaries impersonate consumers to create a flood of 245 interests, and in the latter, they impersonate copy holders (e.g., 246 routers or publishers) to provide fake data. These attacks are 247 severe, because data are cached in a distributed manner, and copy 248 holders have no way to verify consumers' identities, consumers/ 249 routers have no way to verify copy holders' identities to avoid 250 caching fake data, and the path to retrieve data cannot be verified. 251 This form of attack can quickly pollute the router caches as the 252 virus spreads, because routers cache the fake data, redistribute 253 them, and other intermediate routers re-cache them. It finally 254 consumes much in-network caches and prevents consumers from 255 retrieving the correct data. 257 4. HopAuth Designs 259 Herein we elaborate the design of HopAuth, which has three phases: 1) 260 initial trust-establishment, 2) data-centric certificate management, 261 and 3) forwarding-integrated authenticable data-retrieval. The trust 262 model for HopAuth is a suspension chain model (SCM). 264 For the first phase, certificates are issued for neighboring entities 265 and the certificate authority (CA) potentially issues certificates to 266 a set of routers to form the highly trusted router group (HTRG). Let 267 CE(A->B) represent the public-key certificate issued from A to B. In 268 the second phase, routers exchange certificates within their 269 neighborhoods, and any compromised entity can be shut down quickly. 270 Finally, the third phase provides a hop-by-hop method for 271 constructing a suspension chain consisting of a physical-entity 272 certificate chain (peCEChain) and a logical-entity certificate chain 273 (leCEChain) for data-centric authentication. 275 4.1. Initial Trust Establishment 277 The initial trust establishment has two components: self-certifiable 278 naming and certificate issuing. 280 Self-certifiable naming defines the rule for naming the principals, 281 including entities, keys, and certificates, to enable the entities to 282 be self-certifiable. As the extension of the cryptographically 283 generated address (CGA), we merge the hash-based self-certifying 284 names with hierarchical naming. It embeds the public key into the 285 name, which is self-certifiable. 287 To issue a certificate, an entity should be convinced that a given 288 public key truly belongs to another entity. Under that situation, it 289 issues a certificate for this entity such that the public key is 290 bound to the entity name by its signature. In HopAuth, certificate 291 issuing is the initial trust establishment among entities having 292 trust relationships, namely as neighbor-based trust for physical 293 entities, CA-based trust, and authorization relationships for logical 294 entities. 296 For neighbor-based trust, a physical entity creates a public key and 297 the corresponding private key locally by itself. It generates the 298 names using the public key based on the self-certifiable naming 299 method. If physical entity B is a neighbor of entity A, B can 300 announce its public key to A with the key name and A generates the 301 certificate for B. 303 CA-based trust between two entities is established using the CA as 304 the ``introducer''. The CA is managed by the network operator, and 305 provides certificates to the owner's entities and the highly trusted 306 physical entities close to them in the HTRG. The entities in the 307 HTRG then confer CA-based trust relationships and issue certificates 308 to each other. 310 All the highly trustable entities register at CA. CA has the whole 311 view of these entities and determines the neighboring relations among 312 the entities in HTRG. After determination of the neighboring 313 relations, an entity, A, sends interest to CA to request the 314 certificates of its neighbors. CA replies with the related 315 certificates to A, such as CE(CA->B). After A receiving the 316 certificates, A verifies them, issues certificates from itself to 317 those neighbors, such as CE(A->B), and sends to CA. CA verifies this 318 certificate and forwards it to B when B requests. 320 In HopAuth, the physical entities pre-keep the certificates and 321 associate certificates with interfaces in FIB. The physical entity 322 knows the next hop of one interface, and it associates the 323 certificate from that entity to itself with the forwarding interface. 324 This mechanism enables the appending of the relevant certificate to 325 the packets as required when forwarding them. 327 For logical entities, the trust relationship is defined by the 328 application. Each logical entity also generates a public/private key 329 pair by itself. If logical entity A authorizes the right for entity 330 B to manage a sub-category or publish data, A should provide a 331 certificate for the true public key of B. 333 4.2. Data-centric Certificate Management 335 4.2.1. Certificate Exchange 337 Certificate exchange allows entities to share the certificates that 338 they issue and hold. Each physical entity has a local repository in 339 which to store certificates securely. In HopAuth, the physical 340 entities request and keep all the certificates issued for or by their 341 nearby highly trusted entities in the HTRG and by common neighboring 342 physical entities. To exchange the information of certificates they 343 hold, each entity hashes the names of certificates and exchange 344 hashes to see if there is one missed in the neighborhood. If there 345 is, the entity will send interest to its neighbor to retrieve that 346 certificate. Finally, the physical entities hold all the 347 certificates within a two-hop distance and the certificates with 348 nearby highly trusted entities in the HTRG. These certificates are 349 used to construct chains hop by hop, shorten certificate chains, and 350 check the certificates appended by an up-stream entity. This 351 certificate check is performed by the next hop of the entity to check 352 whether the certificate appended by this entity is the same as the 353 one stored by it. If the certificates are the same, the certificate 354 passes the check. Otherwise, this packet will be dropped because of 355 the fake certificate. 357 The certificates of the logical entities in an application should be 358 stored in the repository of the PN. When data are published, the 359 trust chain from the PN to the publisher can be automatically formed 360 and appended to the packet. Meanwhile, the neighbors of the PN also 361 keep all the certificates of the PN in order to check them during 362 transmissions. 364 4.2.2. Certificate Update and Revocation 366 To guarantee its validity, each certificate in the network is issued 367 with a certificate expiration time, after which the certificate is 368 invalid. 370 For certificate updates using neighbor-based trust, the subject 371 entity of the certificate should notify the issuer of its interest in 372 updating the certificate. On receiving this interest, the issuer 373 checks whether this entity has been compromised. It then checks 374 whether the mapping between the name and the public key satisfies the 375 naming rule. If all the checks are passed, the issuer considers 376 whether the public key of the subject entity is still trustworthy, 377 generates an updated certificate, and replies with this updated 378 certificate. If any check is failed, the issuer does not provide a 379 certificate update to that entity. For certificate updates using CA- 380 based trust in the HTRG, the subject entity of the certificate 381 requests the CA to issue an updated certificate and provide it to the 382 related nearby highly trusted routers, who can further issue update 383 certificates. 385 If one entity no longer wishes to trust another entity, the former 386 may revoke the certificate that it originally issued. Because 387 certificates are issued over a one-hop distance, it is easy to detect 388 the misbehavior of an entity. To revoke a certificate quickly, the 389 revocation is announced over a two-hop distance. The revocation 390 initiator broadcasts the revocation information to all the entities 391 within a two-hop distance. Each entity receiving this information 392 adds the compromised entity or certificate to its blacklist. All the 393 packets from the compromised entities are dropped for a rapid local 394 shutdown. 396 4.3. Forwarding-Integrated Authenticable Data Retrieval 398 Here, when forwarding interests and data, we define a forwarding- 399 integrated hop-by-hop approach to construct the suspended chain from 400 unpredictable copy holders to a consumer for authenticating interest, 401 and from a consumer or router to data for authenticating copy holders 402 or publishers or path to retrieve data. We let highly trusted 403 routers replace the parts of chain with highly trusted certificates 404 induced by CA's suspended trust to enhance trustworthiness. 406 The steps for data retrieval are as follows. 408 Step 1: The consumer issues an interest appended with its signature. 409 It knows its next hop is the router to which it is connected. It 410 then appends to this interest the certificate from the next-hop 411 router to itself. Finally, it sends out the interest. 413 Step 2: When the interest is received by an router, it checks whether 414 the previous certificates are correct. If the check succeeds and it 415 belongs to the HTRG, this router attempts to find the previous highly 416 trusted router to replace the related part of the certificate chain 417 with one highly trusted certificate in the suspended chain. If this 418 IPE does not belong to the HTRG, it directly finds the interface to 419 the next hop and appends to the interest the relevant certificate 420 from the next-hop router to itself. 422 Step 3: This is executed if an router holds the requested data in its 423 cache. The router checks the suspended chain from it to the consumer 424 through the process described later in the SCM. If the verification 425 succeeds, this router replies with the data packet. In the data 426 packet, the suspended chain from this router to the publisher and the 427 certificate from the next router to this router are appended. This 428 router sends this data packet to the interface in reply as specified 429 in the PIT. 431 Step 4: If the PN receives the interest, it verifies the suspended 432 chain from itself to the consumer. If the verification succeeds, the 433 PN discovers the suspended chain from itself to the publisher in its 434 storage, and appends this certificate chain with the certificate from 435 the first router to itself. Next, the PN replies with these data 436 using the reverse path of the interest. 438 Step 5: After the router receives the data packet, it performs 439 forwarding and possibly caching. When the router intends to cache 440 the data, it first caches them in a temporary cache, which is 441 separated from the data cache. Second, it checks the suspended chain 442 from itself to the publisher. Only if the verification passes, these 443 data can be cached in the data memory and the suspended chain from 444 this router to the publisher will be cached along with the data. The 445 verification is performed offline, which does not affect the speed of 446 data retrieval. At the same time, this router checks the previous 447 certificate. If the check is successful and it belongs to the HTRG, 448 it will discover the previous entity in the suspended chain belonging 449 to the HTRG. If there is a previous entity, the router replaces part 450 of the related certificate path with a highly trusted certificate. 451 Otherwise, the router directly finds the interface to the 452 corresponding certificate from the next hop to itself and appends 453 this certificate to the packet, then forwards this packet to the 454 interface. 456 Step 6: After the consumer receives the data packet, there should be 457 a certificate chain from it to the publisher. It verifies this 458 suspended chain. If the verification passes, it believes that it 459 gets the authentic public key of the publisher, and utilizes the key 460 to verify the signature of the data. The consumer can also verify 461 the copy holder or the routers on the path. 463 4.4. Suspension-Chain Model (SCM) 465 A suspension-chain model (SCM) is the trust model in HopAuth. It is 466 a flexible series of neighbor-trust-based certificates suspended by 467 CA's trust, which form a suspension chain. In SCM, neighbor-based 468 trust forms the certificate chain to realize data-centric 469 authentication, whereas CA-based trust reduces the length of the 470 chain to solve the trust degradation problem for certificate chain. 471 For CA's trust, the CA assigns certificates to highly trusted routers 472 as the suspension points based on CA's trust, which is the pre-trust 473 between these routers and CA. 475 Public-key verification is the process for one entity to verify the 476 authenticity of the public key of another entity. Entity X 477 authenticates the public key of the entity Y by verifying the 478 suspension chain in the following steps. First, X verifies the first 479 certificate by its private key. If it is correct, each intermediate 480 public key is used to verify the next direct associated certificate. 481 This process continues for multiple rounds until the final 482 certificate is verified. Finally, X obtains the true public key of 483 the entity Y. 485 5. Protocol Message Format 487 HopAuth messages are encoded in the CCNx TLV format [2]. An example 488 of HopAuth packet format with a certificate chain from consumer C0 to 489 router R_n, (CE1(C0->R1), ..., CE_n(R_(n-1)->R_n)), is provided in 490 Figure 2. As in Figure 2, the HopAuth message consists HopAuth 491 header, and HopAuth certificate TLVs. 493 1 2 3 494 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 495 +---------------+---------------+---------------+---------------+ 496 | Version | PT_CONTENT | PacketLength | 497 +---------------+---------------+---------------+---------------+ 498 | Reserved | Flags | HeaderLength | 499 +===============+===============+===============+===============+ 500 | T_HOPAUTH | Length(=n) | 501 +---------------+---------------+---------------+---------------+ 502 | Total length of inserted T_HOPAUTH_CERT TLVs | 503 +===============+===============+===============+===============+ 504 | T_Object | Object Message Length | 505 +---------------+---------------+---------------+---------------+ 506 / Object Message / 507 +---------------+---------------+---------------+---------------+ 508 | T_VALIDATION_ALG | Validation Algorithm Length | 509 +---------------+---------------+---------------+---------------+ 510 / Validation Algorithm Data / 511 +---------------+---------------+---------------+---------------+ 512 | T_VALIDATION_PAYLOAD | Signature Length | 513 +---------------+---------------+---------------+---------------+ 514 / Signature Data / 515 +---------------+---------------+---------------+---------------+ 516 | T_HOPAUTH_CERT | CE1 Length | 517 +---------------+---------------+---------------+---------------+ 518 / CE1(C0->R1) / 519 +---------------+---------------+---------------+---------------+ 520 / . / 521 / . / 522 +---------------+---------------+---------------+---------------+ 523 | T_HOPAUTH_CERT | CE_n Length | 524 +---------------+---------------+---------------+---------------+ 525 / CE_n(R_(n-1)->R_n) / 526 +===============+===============+===============+===============+ 528 Figure 2: An Example of HopAuth packet format 530 The HopAuth header is composed of the fields of type, Length, and 531 Total length of inserted T_HOPAUTH_CERT's TLVs. The type is 532 T_HOPAUTH, the Length shows the number of inserted certificates, and 533 Total length of inserted T_HOPAUTH_CERT's TLVs describes the total 534 number of bits occupied by certificate TLVs. In the part of HopAuth 535 certificate TLVs, the certificate name, length and certificate data 536 are included. Take CE1(C0->R1) in Figure 2 as example. The type is 537 T_HOPAUTH_CERT, CE1 Length is the length of certificate CE1(C0->R1), 538 and CE1(C0->R1) is the certificate data for CE1(C0->R1). 540 6. Security Considerations 542 This document is entirely about authentication mechanism in CCN/NDN. 544 7. References 546 7.1. Normative References 548 [1] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, 550 DOI 10.17487/RFC2119, March 1997, 551 . 553 [2] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 554 Format", draft-irtf-icnrg-ccnxmessages-09 (work in 555 progress), January 2019. 557 7.2. Informative References 559 [3] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 560 Briggs, N., and R. Braynard, "Networking Named Content", 561 Proc. CoNEXT, ACM, December 2009. 563 [4] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 564 K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 565 "Named data networking", ACM Comput. Commun. Rev., vol. 566 44, no. 3, July 2014. 568 [5] Seedorf, J., Arumaithurai, M., Tgami, A., Ramakrishnan, 569 K., and N. Melazzi, "Research Directions for Using ICN in 570 Disaster Scenarios", draft-irtf-icnrg-disaster-07 (work in 571 progress), June 2019. 573 [6] Westphal, C., Lederer, S., Posch, D., Timmerer, C., Azgin, 574 A., Liu, W., Mueller, C., Detti, A., Corujo, D., Wang, J., 575 Montpetit, M., and N. Murray, "Adaptive Video Streaming 576 over Information-Centric Networking (ICN)", RFC 7933, 577 August 2016. 579 [7] Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Burke, 580 J., Ahlgren, B., and A. Azgin, "Design Considerations for 581 Applying ICN to IoT", draft-irtf-icnrg-icniot-03 (work in 582 progress), May 2019. 584 [8] Afanasyev, A., Mahadevan, P., Moiseenko, I., Uzun, E., and 585 L. Zhang, "Interest flooding attack and countermeasures in 586 named data networking", Proc. IFIP Networking, IFIP, May 587 2013. 589 [9] Compagno, A., Conti, M., Gasti, P., and G. Tsudik, 590 "Poseidon: mitigating interest flooding ddos attacks in 591 named data networking", Proc. LCN 2013, IEEE, October 592 2013. 594 [10] Nguyen, T., Cogranne, R., and G. Doyen, "An optimal 595 statistical test for robust detection against interest 596 flooding attacks in ccn", Proc. International Symposium on 597 Integrated Network Management (INM), IFIP/IEEE, May 2015. 599 [11] Ghali, C., Tsudik, G., and E. Uzun, "Network-layer trust 600 in named-data networking", ACM SIGCOMM Computer 601 Communication Review, vol.44, no. 5, October 2014. 603 [12] Kim, D., Nam, S., Bi, J., and I. Yeom, "Efficient content 604 verification in named data networking", Proc. ACM 605 Conference on Information-Centric Networking, ACM, 606 September 2015. 608 [13] Gasti, P., Tsudik, G., Uzun, E., and L. Zhang, "Dos and 609 ddos in named data networking", Proc. IEEE ICCCN 610 2013, IEEE, August 2013. 612 [14] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 613 Kerberos Network Authentication Service (V5)", RFC 4120, 614 July 2005. 616 [15] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 617 "Multicast Security (MSEC) Group Key Management 618 Architecture", RFC 4046, April 2005. 620 [16] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 621 Housley, R., and W. Polk, "Internet X.509 Public Key 622 Infrastructure Certificate and Certificate Revocation List 623 (CRL) Profile", RFC 5280, May 2008. 625 [17] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 626 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 628 [18] Bush, R. and R. Austein, "The Resource Public Key 629 Infrastructure (RPKI) to Router Protocol Version 1", 630 RFC 8210, September 2017. 632 [19] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric 633 Authentication for Secure In-Network Big-Data Retrieval", 634 IEEE Transactions on Network Science and Engineering, DOI: 635 10.1109/TNSE.2018.2872049, September 2018. 637 Authors' Addresses 639 Ruidong Li 640 National Institute of Information and Communications Technology 641 4-2-1 Nukui-Kitamachi 642 Koganei, Tokyo 184-8795 643 Japan 645 Email: lrd@nict.go.jp 647 Hitoshi Asaeda 648 National Institute of Information and Communications Technology 649 4-2-1 Nukui-Kitamachi 650 Koganei, Tokyo 184-8795 651 Japan 653 Email: asaeda@nict.go.jp